तैरता पता प्रॉक्सी सेटिंग को स्थिर रखता है: सक्रिय मशीन के विफल होने के बाद भी क्लाइंट वही होस्टनेम या IP उपयोग करते रहते हैं। यह उपयोगी उपलब्धता है। फिर भी चल रहा डाउनलोड रुक सकता है।

CONNECT के भीतर पहले से मौजूद HTTPS अनुरोध की कल्पना करें। सक्रिय प्रॉक्सी क्लाइंट की ओर वाला TCP कनेक्शन और वेबसाइट की ओर दूसरा कनेक्शन रखता है। वह उन स्ट्रीमों को जोड़ने वाली एप्लिकेशन अवस्था भी रखता है।

पते को स्टैंडबाई मशीन पर ले जाने से अपने आप न तो TCP नियंत्रण ब्लॉक जाता है और न ही वह रिले अवस्था। नया स्वामी नए कनेक्शन स्वीकार कर सकता है, पर पुराने स्वामी द्वारा स्थापित बाइट स्ट्रीम आगे नहीं बढ़ा सकता।

अपेक्षाक्या सामान्य पता फ़ेलओवर यह देता है?
एक विन्यस्त प्रवेश बनाए रखनायही इच्छित लाभ है
स्थापित CONNECT स्ट्रीम जारी रखनाअतिरिक्त अवस्था-आधारित तंत्र चाहिए होगा
वही आउटबाउंड सार्वजनिक IP रखनाआउटबाउंड रूटिंग और NAT पर निर्भर
बाधित एप्लिकेशन क्रिया को सुरक्षित रूप से दोहरानाक्रिया और क्लाइंट पर निर्भर

VRRP चुनाव और पते का स्वामित्व परिभाषित करता है। यह प्रॉक्सी प्रक्रिया के लिए प्रतिकृति प्रोटोकॉल नहीं है। किसी अन्य उच्च-उपलब्धता सॉफ़्टवेयर वाले परिनियोजन को भी वही अंतर चाहिए, जब तक कि वह स्पष्ट रूप से अधिक न दे।

जाँचें कि स्वास्थ्य जाँच वास्तव में क्या देखती है। प्रॉक्सी सेवा, DNS या अपस्ट्रीम मार्ग विफल होने पर भी मशीन घोषणाओं का उत्तर दे सकती है। इसके विपरीत, अत्यधिक संवेदनशील जाँचें अनावश्यक स्विच उत्पन्न कर सकती हैं।

क्लाइंट की वापसी भी मायने रखती है। नया ब्राउज़र अनुरोध आसानी से फिर जुड़ सकता है; खपत हो चुके बॉडी वाला अपलोड या गैर-इडेम्पोटेंट API क्रिया के लिए एप्लिकेशन-विशिष्ट प्रबंधन चाहिए हो सकता है। केवल इसलिए अदृश्य फ़ेलओवर का वादा न करें कि स्टैंडबाई से नया अनुरोध सफल होता है।

संबंधित लेख