AWS का एक-टनल नोटिस: यह वास्तव में कब मायने रखता है

एक टनल के डाउन होने की AWS Health सूचना अक्सर तब आती है जब कुछ भी टूटा हुआ नहीं दिखता। ठीक इसीलिए उसे नज़रअंदाज़ किया जाता है। सूचना किसी आउटेज का वर्णन नहीं करती; वह उस रिडंडेंसी स्थिति का वर्णन करती है जो AWS की अवलोकन विंडो से आगे बनी हुई है। आप कार्रवाई करते हैं या नहीं, यह इस पर निर्भर है कि आपका डिज़ाइन क्या सहन कर सकता है, न कि डैशबोर्ड कैसा लगता है।

सूचना ने वास्तव में क्या मापा

हर Site-to-Site कनेक्शन में दो टनल होते हैं, जो अलग-अलग AWS एंडपॉइंट पर समाप्त होते हैं। AWS का मॉनिटरिंग दस्तावेज़ दोनों को रिडंडेंसी के लिए कॉन्फ़िगर करने की सलाह देता है और सूचना तब उठाता है जब एक दस्तावेज़ीकृत अवधि तक डाउन रहता है। वह अवधि मायने रखती है, क्योंकि छोटा उतार-चढ़ाव और स्थायी हानि एक ही ग्राफ़ में एक जैसे दिखते हैं।

कनेक्शन की समग्र स्थिति के बजाय प्रति-टनल टेलीमेट्री पढ़ें। aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' हर टनल के लिए स्थिति और संदेश लौटाता है, और सूचना जिस साक्ष्य पर आधारित है वह यही है।

तीन शर्तें जो आपकी प्रतिक्रिया तय करती हैं

यह टिकट है या अनदेखी, यह तय करने से पहले तीनों पर गौर करें।

पहला, क्या बचा हुआ टनल भार उठा सकता है, जिसमें कोई भी बैंडविड्थ सीमा और वह जो प्रीफ़िक्स घोषित करता है वे शामिल हैं? दूसरा, क्या फेलओवर वास्तव में होता है, यह देखते हुए कि निर्माण से डाउन दूसरा टनल कभी ऊपर आने के लिए सिद्ध नहीं हुआ? तीसरा, क्या आपका अगला नियोजित बदलाव दोनों टनल को एक साथ नीचे ले आएगा, जो एक सौंदर्यपरक चेतावनी को रखरखाव विंडो की समस्या में बदल देता है। यदि कोई भी उत्तर नहीं या अज्ञात है, तो सूचना एक वास्तविक निष्कर्ष है।

यदि तीनों प्रमाणित रूप से ठीक हैं, तो लिखें कि यह क्यों सह्य है और आगे बढ़ें। वह नोट अगली तिमाही की बहस से अधिक मूल्यवान है।

स्टैंडबाय पीयर क्या सिद्ध नहीं करता

कॉन्फ़िगर किए गए बैकअप पीयर वाला कस्टमर गेटवे इस बात का प्रमाण नहीं है कि AWS दो स्वस्थ टनल देखता है। कस्टमर पक्ष एक ठंडा पीयर रख सकता है जिसे नई बातचीत चाहिए, और वह वैध डिज़ाइन हो सकता है। फिर भी यह दो जीवित टनल जैसा अवलोकन नहीं है।

दो भौतिक राउटर भी विपरीत स्थिति को ठीक नहीं करते। जब दोनों टनल एक ही डिवाइस पर समाप्त होते हैं या एक ही अपलिंक से बाहर जाते हैं, तो रिडंडेंसी केवल कागज़ पर होती है।

बदलाव को उसकी प्रभाव-त्रिज्या से मिलाएँ

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

एक टनल पर विकल्प बदलना अपने स्वयं के घोषित प्रभाव वाला तीसरा मामला है: वह टनल अपने ही अपडेट के दौरान अनुपलब्ध रहता है और दूसरा चलता रहता है।

आवश्यकता से पहले विकल्प को सिद्ध करें

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

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