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-व्यवस्थित अद्यावधिकहरू एक पटकमा एउटा टनेलमा लागू गरिन्छ। लक्ष्य गेटवे, ग्राहक गेटवे वा जडान विकल्पहरूमा ग्राहक-सुरु गरिएका परिवर्तनहरूले प्रतिस्थापन इन्डपोइन्ट तयार नभएसम्म दुवै टनेल अनुपलब्ध बनाउँछन्।

एउटै टनेलमा विकल्पहरू परिवर्तन गर्नु आफ्नै घोषित प्रभाव भएको तेस्रो केस हो: त्यो टनेल आफ्नै अद्यावधिकको क्रममा अनुपलब्ध हुन्छ र अर्को चलिरहन्छ।

आवश्यक पर्नुअघि वैकल्पिक प्रमाणित गर्नुहोस्

घटनाको प्रतीक्षा नगरी परीक्षण तालिका बनाउनुहोस्। स्वस्थ टनेललाई मर्मत विन्डोभित्र तल झार्नुहोस्, वैकल्पिक वार्ता गर्छ भनी पुष्टि गर्नुहोस्, त्यसपछि वास्तविक ट्राफिक दुवै दिशामा यसबाट गुज्रन्छ भनी पुष्टि गर्नुहोस्। टनेल स्थितिसँगै फिर्ता राउटिङ पनि जाँच्नुहोस्, किनकि दोस्रो चरणको बेमेलले टनेल माथि र कार्यभार मृत छोड्छ। तपाईं त्यहाँ हुँदा संक्रमणको समय नाप्नुहोस्।

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