तरंगता पत्ता प्रॉक्सी सेटिंग स्थिर ठेवतो: सक्रिय मशीन बंद पडल्यानंतरही क्लायंट तेच होस्टनाव किंवा IP वापरत राहतात. ही उपयुक्त उपलब्धता आहे. तरीही सुरू असलेले डाउनलोड थांबू शकते.

CONNECT मध्ये आधीच असलेल्या HTTPS विनंतीचा विचार करा. सक्रिय प्रॉक्सी क्लायंटकडील TCP जोडणी आणि वेबसाइटकडील दुसरी जोडणी धारण करते. ती त्या प्रवाहांना जोडणारी ॲप्लिकेशन स्थितीही धारण करते.

पत्ता स्टँडबाय मशीनवर हलवल्याने स्वतःहून TCP नियंत्रण ब्लॉक किंवा ती रिले स्थिती हलत नाही. नवीन मालक नवीन जोडण्या स्वीकारू शकतो, पण जुन्या मालकाने स्थापन केलेला बाइट प्रवाह पुढे नेऊ शकत नाही.

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

VRRP निवडणूक आणि पत्त्याची मालकी परिभाषित करते. तो प्रॉक्सी प्रक्रियेसाठी प्रतिकृती प्रोटोकॉल नाही. दुसरे उच्च-उपलब्धता सॉफ्टवेअर वापरणाऱ्या तैनातीलाही तोच फरक आवश्यक आहे, जोपर्यंत ते स्पष्टपणे अधिक देत नाही.

आरोग्य तपासणी प्रत्यक्षात काय निरीक्षण करते ते पाहा. प्रॉक्सी सेवा, DNS किंवा अपस्ट्रीम मार्ग बंद पडला असतानाही मशीन जाहिरातींना उत्तर देऊ शकते. उलटपक्षी, अतीसंवेदनशील तपासण्या अनावश्यक स्विच घडवू शकतात.

क्लायंटची पुनर्प्राप्तीही महत्त्वाची आहे. नवीन ब्राउझर विनंती सहज पुन्हा जोडली जाऊ शकते; वापरलेल्या बॉडीसह अपलोड किंवा नॉन-आयडेंपोटेंट API क्रियेला ॲप्लिकेशन-विशिष्ट हाताळणी लागू शकते. फक्त स्टँडबायमधून नवीन विनंती यशस्वी झाली म्हणून अदृश्य फेलओव्हरचे वचन देऊ नका.

संबंधित लेख