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 کے زیرِ انتظام اپ ڈیٹس ایک وقت میں ایک ٹنل پر لاگو ہوتے ہیں۔ گاہک کی جانب سے شروع کردہ تبدیلیاں ہدف گیٹ وے، کسٹمر گیٹ وے یا کنکشن کے اختیارات میں متبادل اینڈ پوائنٹس کی تیاری تک دونوں ٹنل کو دستیاب نہیں رکھتیں۔

ایک ٹنل پر اختیارات تبدیل کرنا اپنے بیان کردہ اثر کے ساتھ تیسرا معاملہ ہے: وہ ٹنل اپنی اپ ڈیٹ کے دوران دستیاب نہیں رہتا اور دوسرا چلتا رہتا ہے۔

ضرورت پڑنے سے پہلے متبادل کو ثابت کریں

واقعے کا انتظار کرنے کے بجائے ٹیسٹ کا شیڈول بنائیں۔ صحت مند ٹنل کو مینٹیننس ونڈو کے اندر نیچے لائیں، تصدیق کریں کہ متبادل گفت و شنید کرتا ہے، پھر تصدیق کریں کہ حقیقی ٹریفک دونوں سمتوں میں اس سے گزرتی ہے۔ ٹنل کی حالت کے ساتھ واپسی کی روٹنگ بھی جانچیں، کیونکہ دوسرے مرحلے کی عدم مطابقت ٹنل کو اوپر اور ورک لوڈ کو مردہ چھوڑ دیتی ہے۔ وہاں موجودگی میں منتقلی کا وقت ناپیں۔

نوٹس، ٹیلی میٹری آؤٹ پٹ اور تبدیلی کا منصوبہ ایک ہی ریکارڈ میں رکھیں۔ وہ ریکارڈ اگلی سہ ماہی کے نوٹس کو اس بحث کے بجائے دو منٹ کے جائزے میں بدل دیتا ہے کہ کسی نے کبھی بیک اپ آزمایا ہے یا نہیں۔