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-व्यवस्थापित अद्यतने एका वेळी एका टनेलवर लागू होतात. लक्ष्य गेटवे, ग्राहक गेटवे किंवा कनेक्शन पर्यायांमधील ग्राहक-सुरू केलेले बदल, बदली एंडपॉइंट तयार होईपर्यंत दोन्ही टनेल अनुपलब्ध करतात.

एका टनेलवर पर्याय बदलणे हे स्वतःच्या घोषित प्रभावासह तिसरे प्रकरण आहे: ती टनेल स्वतःच्या अद्यतनादरम्यान अनुपलब्ध असते आणि दुसरी चालू राहते.

गरज पडण्यापूर्वी पर्याय सिद्ध करा

घटनेची वाट न पाहता चाचणी नियोजित करा. निरोगी टनेल मेंटेनन्स विंडोमध्ये खाली आणा, पर्याय वाटाघाटी करतो याची खात्री करा, नंतर प्रत्यक्ष रहदारी दोन्ही दिशांनी त्यातून जाते याची खात्री करा. टनेल स्थितीसह परतीचे राउटिंगही तपासा, कारण दुसऱ्या टप्प्यातील विसंगती टनेल वर ठेवते आणि कामाचा भार मृत करते. तिथे असताना संक्रमणाचा वेळ मोजा.

सूचना, टेलिमेट्री आउटपुट आणि बदल योजना एका नोंदीत ठेवा. ती नोंद पुढील तिमाहीच्या सूचनेला, कोणीतरी कधी बॅकअप तपासला आहे का या वादाऐवजी दोन मिनिटांच्या आढाव्यात बदलते.