फेलओवर परीक्षण: क्या स्थापित TCP स्ट्रीम बची रहती है?

«बैकअप काम करता है» वाक्य में दो नतीजे छिपे हैं। नया अनुरोध सफल होता है, यह पुनर्प्राप्ति है। पहले से चल रहा ट्रांसफ़र जारी रहता है, यह निरंतरता है। ये अलग-अलग वादे हैं, और ज़्यादातर फेलओवर डिज़ाइन पहला देते हैं जबकि दूसरा चुपचाप समय-समाप्त हो जाता है। तंत्र चुनने से पहले तय करें कि आपको कौन-सा चाहिए, और परीक्षण ऐसे लिखें कि वह दोनों में फ़र्क़ कर सके।

दो नतीजे जो एक ही सफलता जैसे दिखते हैं

सोचिए, 10.90.0.42 पर एक क्लाइंट का 198.51.100.20:443 से कनेक्शन है। प्राथमिक एग्ज़िट उसे एक सार्वजनिक पता और पोर्ट में बदलता है, और बैकअप एग्ज़िट उसे दूसरे में। क्लाइंट का भीतरी पता कभी नहीं बदलता, इसीलिए लोग उम्मीद करते हैं कि कनेक्शन बचा रहेगा।

सर्वर भीतरी पता नहीं देखता। वह अनूदित एंडपॉइंट देखता है, और स्विच के बाद वह एंडपॉइंट अलग होता है।

इसलिए पुरानी स्ट्रीम समय-समाप्त हो जाती है जबकि उसी सेवा से नया कनेक्शन तुरंत काम करता है। दोनों अवलोकन एक साथ सच हैं।

एग्ज़िट बदलने पर सर्वर क्या देखता है

TCP कनेक्शन अपने चतुष्क से पहचाना जाता है, और स्रोत पता या पोर्ट बदलने से प्राप्त करने वाले होस्ट के लिए अलग कनेक्शन बनता है। जिस कनेक्शन को सर्वर नहीं जानता, उस पर नए स्रोत से आने वाले पैकेट गिरा दिए जाते हैं या रीसेट से उत्तर दिया जाता है। VPN क्लाइंट के पते में कुछ भी उस बदलाव के पार संबंध नहीं बनाए रखता।

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

किसी को निरंतरता का वादा करने से पहले जाँचें कि जोड़ी वास्तव में स्थिति रखती है या नहीं। नीचे दिए आदेश दोनों ओर की वर्तमान स्थिति दिखाते हैं।

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

एक ही सार्वजनिक पता क्यों पर्याप्त नहीं है

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

RFC 3022 पता अनुवाद का वर्णन करता है और अनुवाद करने वाले उपकरणों के बीच स्थिति के आदान-प्रदान को बैकअप डिज़ाइन का हिस्सा मानता है। तैरता पता या नकल की गई प्रोफ़ाइल कॉन्फ़िगरेशन को खिसकाती है, स्थिति को नहीं।

इसीलिए केवल बैकअप से पिंग करने वाला परीक्षण बहुत कम साबित करता है। पिंग के पास खोने के लिए कोई कनेक्शन स्थिति नहीं है।

तय करें कि आवश्यकता कितनी मज़बूत है

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

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

स्पष्ट कहें कि प्राथमिक लौटने पर क्या होता है, क्योंकि स्वचालित फेलबैक उस कनेक्शन को तोड़ सकता है जो अभी-अभी बैकअप पर पुनर्प्राप्त हुआ था। वह मामला परीक्षण योजना का है, पादटिप्पणी का नहीं।

पुरानी स्ट्रीम और नया अनुरोध जाँचें

प्राथमिक से एक हानिरहित लंबा ट्रांसफ़र शुरू करें, फिर उसी सेवा से एक अलग नया अनुरोध। एप्लिकेशन संदर्भ, देखा गया एग्ज़िट पता और समय दर्ज करें। स्वीकृत तरीके से प्राथमिक तोड़ें और बैकअप से नया अनुरोध भेजते हुए मूल ट्रांसफ़र देखते रहें।

तीन मान बताएँ: पुरानी स्ट्रीम जारी रही, रीसेट हुई या समय-समाप्त हुई; नया ऑपरेशन पहली बार कब काम कर गया; और क्या फेलबैक ने कुछ तोड़ा। वही तीन पंक्तियाँ स्वीकृति रिकॉर्ड हैं।

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

अगर वर्कलोड डेटा लिखता है, तो समय-समाप्ति के बाद अनिश्चित ऑपरेशन को आँख मूँदकर न दोहराएँ। हो सकता है लिखावट उत्तर खोने से पहले पहुँच गई हो। एप्लिकेशन से परिणाम पूछें, या केवल वहीं पुनः प्रयास करें जहाँ ऑपरेशन आइडेम्पोटेंट हो। फिर स्वीकृति वक्तव्य तीन भागों में लिखें: नए ऑपरेशन एग्ज़िट नीति के अंतर्गत पुनर्प्राप्त होते हैं, मौजूदा स्ट्रीम का दस्तावेज़ित व्यवधान व्यवहार है, और एप्लिकेशन सुरक्षित रूप से फिर शुरू होता है। वह वक्तव्य जाँचने योग्य है, और डिज़ाइन क्या वादा नहीं करता, इस बारे में ईमानदार है।