WebLogic EJB और लोड बैलेंस
हाल ही में मुझसे WebLogic पर @Remote @EJB इंटरफेस की लोड बैलेंसिंग सुविधा के बारे में पूछा गया था।
क्या रिमोट इंटरफेस लोड-बैलेंस्ड होते हैं? क्या यह संदर्भ पर निर्भर करता है? क्या इनवोकेशन लोड बैलेंस्ड है या केवल लुकअप?
क्लाइंट की ओर से, क्या हम यह पता लगा सकते हैं कि किस क्लस्टर नोड ने अनुरोध को संसाधित किया है?
प्रदर्शन और स्केलेबल प्रक्रियाओं को लागू करने की किसी की क्षमता में सुधार के लिए इन अवधारणाओं को समझना सर्वोपरि है।
स्टेटलेस EJB रिमोट इंटरफेस के लिए लोड बैलेंसिंग विशेषताएँ
इन सवालों के जवाब देने के लिए, आइए पहले WebLogic 14.1.1.0 दस्तावेज़ीकरण (हालांकि आपको पुराने संस्करणों में भी समानताएं मिलेंगी) का संदर्भ लें। यह स्टेटलेस EJB रिमोट इंटरफेस के लिए लोड बैलेंसिंग विशेषताओं का वर्णन करता है। संक्षेप में, आपके पास दो प्रकार के कनेक्शन हो सकते हैं:
- क्लाइंट-से-सर्वर;
- सर्वर-से-सर्वर।
क्लाइंट-से-सर्वर कनेक्शन और इनवोकेशन तीन रणनीतियों में से एक का उपयोग करके लोड-बैलेंस्ड होते हैं: राउंड-रॉबिन (डिफ़ॉल्ट), वेट-बेस्ड, या रैंडम। वैकल्पिक रूप से, सर्वर-एफिनिटी के पक्ष में लोड बैलेंसिंग को बंद किया जा सकता है। सर्वर एफिनिटी के साथ, आप अभी भी लोड बैलेंसिंग के अधीन हैं, लेकिन केवल तभी जब आप मैनेज्ड सर्वर के बजाय क्लस्टर URI का उपयोग करते हैं, और केवल एक नया इनिशियल कॉन्टेक्स्ट बनाने के स्तर पर। ये सभी विकल्प फेलओवर का समर्थन करते हैं।
सर्वर-से-सर्वर कनेक्शन के लिए, यह समझना आवश्यक है कि सर्वर एफिनिटी विकल्प सर्वरों के बीच लोड बैलेंसिंग को प्रभावित नहीं करता है।
इसके अलावा, एक क्लस्टर के भीतर, WLS हमेशा उसी नोड पर स्थित EJB का उपयोग करेगा जिसने अनुरोध प्राप्त किया है, क्योंकि यह बहुत अधिक कुशल है।
तथाकथित ऑब्जेक्ट कोलोकेशन @EJB के भीतर @Remote इंटरफेस के उपयोग को उप-इष्टतम (अनावश्यक सीरियलाइज़ेशन) बनाता है।
संयोग से, क्लाइंट UserTransaction और वैकल्पिक रूप से XA को संभालने के लिए एक समान व्यवहार वर्णित है।
अलग-अलग क्लस्टरों के बीच कोई कोलोकेशन (विपरीत - लोड बैलेंसिंग) नहीं होता है, उदाहरण के लिए, एक मल्टी-टियर वेब एप्लिकेशन सेटअप के प्रति-टियर क्लस्टर कॉन्फ़िगरेशन में। यदि आप कोलोकेशन नहीं चाहते हैं, तो प्रसंस्करण के लिए वैकल्पिक विकल्प लोड-बैलेंस्ड JMS डेस्टिनेशन के माध्यम से है। अन्यथा, मैं कल्पना करता हूं कि आप एक कस्टम क्लासलोडर के माध्यम से लुकअप को प्रॉक्सी कर सकते हैं जो WLS क्लाइंट के रूप में कार्य करता है, लेकिन यह कुछ ऐसा नहीं है जिसका परीक्षण या अनुशंसा की जाती है।
यह पता लगाना कि किस सर्वर ने मेरे (क्लाइंट) अनुरोध को संभाला
कभी-कभी, आप जानना चाह सकते हैं कि कौन से सर्वर कुछ विशिष्ट अनुरोधों को संभालते हैं। मुझे एक बार एक क्लस्टर पर एक नए एप्लिकेशन संस्करण की डीसिंक्रनाइज़्ड तैनाती का सामना करना पड़ा, जिसके परिणामस्वरूप राउंड-रॉबिन तरीके से दो अलग-अलग प्रतिक्रियाएं प्राप्त हुईं। यह पता लगाने से कि प्रतिक्रिया को एक विशिष्ट सर्वर से कैसे जोड़ा जाए, मुझे अनावश्यक पुन: तैनाती या पूरे क्लस्टर को बंद किए बिना समस्या को हल करने में सक्षम बनाया।
एक तरीका अनुरोध/प्रतिक्रिया पहचान योग्य लॉगिंग को लागू करना है।
क्या कुछ ऐसा है जिसे हम तदर्थ रूप से उपयोग कर सकते हैं?
यदि आपने WLS के साथ काम किया है, तो आप पहले से ही जानते होंगे कि ऐसी जानकारी कहीं न कहीं
wlthint3client.jar लाइब्रेरी की वस्तुओं के भीतर मौजूद हो सकती है।
इसका उपयोग WLS से कनेक्ट करने के लिए किया जाता है और इसमें t3 प्रोटोकॉल के लिए लोड-बैलेंसिंग लॉजिक होता है।
लेकिन इसमें और भी बहुत कुछ है। लोड-बैलेंसिंग के लिए, एक विशिष्ट लॉगर है जिसका आप उपयोग कर सकते हैं। इसके बिना, आपको EJB स्टब कॉल के चारों ओर एक कस्टम रैपर बनाने पर भरोसा करना होगा जो संदर्भित लोड बैलेंसर की आंतरिक स्थिति में पहुँचता है।
Wlthint3client लॉगिंग नीचे JUL (Java Util Logging) का उपयोग करता है। एक तृतीय-पक्ष लॉगिंग फ्रेमवर्क एकीकरण के लिए, jul-to-slf4j जैसे ब्रिज की तलाश करें।
लॉगिंग को सक्षम करने के लिए, या तो -Dweblogic.debug.DebugLoadBalancing JVM प्रॉपर्टी के साथ एप्लिकेशन शुरू करें या साझा लॉगर के लिए इसे प्रोग्रामेटिक रूप से करें:
weblogic.diagnostics.debug.DebugLogger
.getDebugLogger("DebugLoadBalancing")
.setDebugEnabled(false);
इसके बाद आपको अपने फ्रेमवर्क के अनुसार लॉगिंग स्तर और अपेंडिंग को कॉन्फ़िगर करना चाहिए।
यहाँ, displayName लॉगर का नाम है जिसमें से Debug उपसर्ग हटा दिया गया है, यानी, JUL लॉगर का नाम LoadBalancing हो जाता है।
इसके साथ, आप नीचे दिए गए जैसी लॉग प्रविष्टियों की अपेक्षा कर सकते हैं:
JUL|FINE|my-exampl-earmy-ejb_jarcom_example_MyBean_MyRemoteBean request routing from 8754691235748961325S:10.90.0.4:[7001,7001,-1,-1,-1,-1,-1]:mydomain:wls1 to 6654312976543210890S:10.90.0.5:[7001,7001,-1,-1,-1,-1,-1]:mydomain:wls2
JUL|FINE|my-exampl-earmy-ejb_jarcom_example_MyBean_MyRemoteBean request routing from 6654312976543210890S:10.90.0.5:[7001,7001,-1,-1,-1,-1,-1]:mydomain:wls2 to 7890564123879561234S:10.90.0.6:[7001,7001,-1,-1,-1,-1,-1]:mydomain:wls3
JUL|FINE|my-exampl-earmy-ejb_jarcom_example_MyBean_MyRemoteBean request routing from 7890564123879561234S:10.90.0.6:[7001,7001,-1,-1,-1,-1,-1]:mydomain:wls3 to 8754691235748961325S:10.90.0.4:[7001,7001,-1,-1,-1,-1,-1]:mydomain:wls1
एक थ्रेड नाम और समय (लॉगिंग प्रारूप), या अन्य संदर्भ-संबंधित जानकारी के साथ संयुक्त, यह प्रत्येक अनुरोध को एक विशिष्ट व्यावसायिक प्रक्रिया और EJB नोड से जोड़ने की अनुमति देता है।
एक और उपयोगी लॉगर DebugFailOver है और उससे कम, DebugMessaging है। अंतिम वाला ज्यादातर अतिरिक्त -Dweblogic.kernel.debug=true के बाद काम करता है और कंसोल में संदेशों को बाइट-प्रेटी प्रारूप में आउटपुट करता है।