अपाचे प्रॉक्सी लोड संतुलन बैकएंड सर्वर विफलता का पता लगाने

Question

यहाँ मेरी परिदृश्य (मेरे पूर्ववर्ती द्वारा डिजाइन) है:

दो Apache सर्वर मिश्रित बैकएंड वेब सर्वर (अपाचे, आईआईएस, बिलाव, आदि) के एक नंबर के लिए रिवर्स प्रॉक्सी कर्तव्य की सेवा । जिसके लिए हम कई बैकएंड वेब सर्वर है कुछ साइटों रहे हैं, और उन मामलों में, हम जैसे कुछ कार्य करें:

<Proxy balancer://www.example.com> 
    BalancerMember http://192.168.1.40:80 
    BalancerMember http://192.168.1.41:80 
</Proxy> 
<VirtualHost *:80> 
    ServerName www.example.com:80 
    CustomLog /var/log/apache2/www.example.com.log combined 
    <Location /> 
     Order allow,deny 
     Allow from all 
     ProxyPass balancer://www.example.com/ 
     ProxyPassReverse balancer://www.example.com/ 
    </Location> 
</VirtualHost> 

इस उदाहरण में

तो, मैं में एक साइट (www.example.com) मिल गया है प्रॉक्सी सर्वर 'कॉन्फ़िगरेशन, और वह साइट दो बैकएंड सर्वरों में से एक या अन्य के लिए प्रॉक्सी हुई है, 1 9 2.168.1.40 और .41।

मैं यह सुनिश्चित करने के लिए इसका मूल्यांकन कर रहा हूं कि हम अपनी सभी वेब सेवाओं पर गलती सहनशील हैं (मैंने पहले से ही दो रिवर्स प्रॉक्सी सर्वर को इस कारण से साझा आईपी क्लस्टर में रखा है), और मैं यह सुनिश्चित करना चाहता हूं कि भार-संतुलित बैकएंड सर्वर भी गलती सहनशील हैं। लेकिन मुझे यह पता लगाने में परेशानी हो रही है कि बैकएंड विफलता का पता लगाना (और असफल बैकएंड सर्वर से बचने के लिए तर्क) mod_proxy_balancer मॉड्यूल में बनाया गया है ...

तो यदि 1 9 2.168.202.40 नीचे चला जाता है, तो अपाचे इस (I यह समझ जाएगा कि क्या यह पहले विफल विफलता लेता है) और स्वचालित रूप से सभी अनुरोधों को अन्य बैकएंड, 1 9 2.168.202.41 पर रूट करता है? या क्या असफल बैकएंड और परिचालन बैकएंड के बीच अनुरोधों को संतुलित करना जारी रहेगा?

मैं mod_proxy और mod_proxy_balancer के लिए अपाचे दस्तावेज में कुछ सुराग कि संकेत मिलता है कि विफलता पता लगाया जा सकता ("maxattempts = देने से पहले विफलता अधिकतम प्रयासों की संख्या।" "Failonstatus = एक एकल या कॉमा- लग पाया है HTTP स्थिति कोड की अलग सूची। यदि सेट किया गया है तो यह कार्यकर्ता को त्रुटि स्थिति में मजबूर कर देगा जब बैकएंड सूची में कोई स्टेटस कोड देता है। "), लेकिन खोज के कुछ दिनों के बाद, मुझे यह सुनिश्चित करने के लिए कुछ भी निर्णायक कह नहीं मिला है कि यह (या कम से कम "चाहिए") बैकएंड विफलता और वसूली का पता लगाएगा।

मैं कहूंगा कि अधिकांश खोज परिणाम संदर्भ बैकएंड सर्वर पर यातायात को पारित करने के लिए एजेपी प्रोटोकॉल का उपयोग करते हैं, और यह स्पष्ट रूप से विफलता का पता लगाने का समर्थन करता है - लेकिन मेरे बैकएंड अपाचे, आईआईएस, टोमकैट और अन्य का मिश्रण हैं , और मुझे पूरा यकीन है कि उनमें से कई एजेपी का समर्थन नहीं करते हैं। वे विंडोज 2k3/2k8 और लिनक्स (अधिकतर उबंटू ल्यूसिड) बक्से का मिश्रण भी विभिन्न विभिन्न आवश्यकताओं के साथ विभिन्न विभिन्न अनुप्रयोगों को चलाते हैं, इसलिए बैकहैंड और एलवीएस जैसे ऐड-ऑन मॉड्यूल मेरे लिए एक विकल्प नहीं हैं।

मैं भी अनुभव इस सुविधा का परीक्षण करने की कोशिश की है एक नया परीक्षण स्थल इस तरह बनाने के द्वारा:

<Proxy balancer://test.example.com> 
    BalancerMember http://192.168.1.40:80 
    BalancerMember http://192.168.1.200:80 
</Proxy> 
<VirtualHost *:80> 
    ServerName test.example.com:80 
    CustomLog /var/log/apache2/test.example.com.log combined 
    LogLevel debug 
    <Location /> 
     Order allow,deny 
     Allow from all 
     ProxyPass balancer://test.example.com/ 
     ProxyPassReverse balancer://test.example.com/ 
    </Location> 
</VirtualHost> 

कहाँ 192.168.1.200 एक फर्जी पते है कि किसी भी वेब सर्वर नहीं चल रहा है है, अनुकरण करने के लिए एक बैकएंड विफलता। परीक्षण साइट को विभिन्न क्लाइंट मशीनों के समूह के लिए समस्या के बिना सेवा दी गई थी, लेकिन लॉगलेवल सेट को डीबग करने के लिए भी सेट किया गया था, मुझे यह इंगित करने के लिए लॉग इन कुछ भी नहीं मिला था कि यह पता चला है कि बैकएंड सर्वरों में से एक नीचे था ... और मैं 100% सुनिश्चित करना चाहता हूं कि मैं उत्पादन लोड को प्रभावित किए बिना रखरखाव के लिए हमारे भार-संतुलित बैकएंड को नीचे ले जा सकता हूं (एक समय में, एक समय में)।

Answer 1

http://httpd.apache.org/docs/2.4/mod/mod_proxy.html धारा "BalancerMember पैरामीटर", संपत्ति = फिर से प्रयास करें:

बैकएंड सर्वर से कनेक्शन पूल कार्यकर्ता त्रुटि राज्य में है, तो अपाचे httpd कि सर्वर के लिए किसी भी अनुरोध तक नहीं देंगे टाइमआउट समाप्त हो जाता है। यह रखरखाव के लिए बैकएंड सर्वर को बंद करने के लिए [एक] को सक्षम बनाता है, और इसे बाद में ऑनलाइन लाता है।0 का मान हमेशा किसी त्रुटि समय में कार्यकर्ताओं को फिर से प्रयास नहीं करता है।

हालांकि अन्य विफलता स्थितियां हैं जिन्हें mod_whatever का उपयोग करके पकड़ा नहीं जाएगा, उदाहरण के लिए, आईआईएस बैकएंड एक अनुप्रयोग चला रहा है जो नीचे है। आईआईएस ऊपर है इसलिए एक कनेक्शन बनाया जा सकता है और एक पृष्ठ पढ़ा जा सकता है, यह सिर्फ यह है कि पृष्ठ हमेशा 500 आंतरिक सर्वर त्रुटि होगी। यहां आपको इसे पकड़ने के लिए असफलता का उपयोग करना होगा और कार्यकर्ता को एक त्रुटि स्थिति में मजबूर करना होगा।

सभी मामलों में जब कार्यकर्ता एक त्रुटि स्थिति में होता है तो यातायात को निर्देशित नहीं किया जाएगा। मैं पहली विफलता का उपभोग करने और इसे पुनः प्रयास करने के विभिन्न तरीकों का प्रयास कर रहा हूं लेकिन वहां हमेशा ऐसा लगता है जहां एक त्रुटि पृष्ठ क्लाइंट को वापस लाता है।

Answer 2

'BalancerMember मापदंडों'

में एक संपत्ति 'पिंग' प्रलेखन यह पिंग '500ms करने के लिए सेट एक अनुरोध भेजेगा से पहले mod_proxy एक BalancerMember में निर्देशित करता की तरह लगता है पढ़ना नहीं है। mod_proxy बैलेंसर मेम्बर से प्रतिक्रिया के लिए 500ms का इंतजार करेगा, और यदि mod_proxy को कोई प्रतिक्रिया नहीं मिलती है तो यह बैलेंसर मेम्बर को एक त्रुटि स्थिति में रखेगी।

मैं इसे लागू करने में थक गया लेकिन यह लाइव बैलेंसर मेम्बर को निर्देशित करने में सहायता करने में प्रतीत नहीं हुआ।

<Proxy balancer://APICluster> 
    BalancerMember https://api01 route=qa-api1 ttl=5 ping=500ms 
    BalancerMember https://api02 route=qa-api2 ttl=5 ping=500ms 
    ProxySet lbmethod=bybusyness stickysession=ROUTEID 
</Proxy> 

http://httpd.apache.org/docs/2.4/mod/mod_proxy.html

पिंग संपत्ति वेब सर्वर पर "परीक्षण" अनुरोध भेजने से पहले बैकएंड के लिए कनेक्शन बताता है। एजेपी के लिए, यह modpproxy_ajp को AJP13 कनेक्शन पर एक सीपीआईंग अनुरोध भेजने के लिए कारण बनाता है (टॉमकैट 3.3.2+, 4.1.28+ और 5.0.13+ पर लागू)। HTTP के लिए, यह mod_proxy_http को बैकएंड पर 100-जारी रखने के लिए कारण बनाता है (केवल HTTP/1.1 के लिए मान्य - गैर HTTP/1.1 बैकएंड के लिए, इस संपत्ति का कोई प्रभाव नहीं पड़ता है)। दोनों स्थितियों में, पैरामीटर जवाब के लिए प्रतीक्षा करने के लिए सेकंड में देरी है। लटका और व्यस्त बैकएंड के साथ समस्याओं से बचने के लिए यह सुविधा जोड़ा गया है। इससे सामान्य ऑपरेशन के दौरान नेटवर्क यातायात में वृद्धि होगी जो एक मुद्दा हो सकता है, लेकिन कुछ क्लस्टर नोड्स नीचे या व्यस्त होने पर यातायात को कम कर देंगे। एमएस का एक पोस्टफिक्स जोड़कर, देरी भी मिलीसेकंड में सेट की जा सकती है।