هشدار 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 هر بار روی یک تونل اعمال میشوند. تغییراتی که مشتری آغاز میکند در دروازهٔ مقصد، دروازهٔ مشتری یا گزینههای اتصال، هر دو تونل را تا زمان تأمین نقاط پایانی جایگزین در دسترسناپذیر میکند.
تغییر گزینهها روی یک تونل، مورد سومی با اثر اعلامشدهٔ خودش است: آن تونل در طول بهروزرسانی خودش در دسترس نیست و دیگری به کار ادامه میدهد.
پیش از آنکه لازم شود، جایگزین را اثبات کنید
آزمون را زمانبندی کنید، نه اینکه منتظر رویداد بمانید. تونل سالم را در یک پنجرهٔ نگهداری پایین بیاورید، تأیید کنید که جایگزین مذاکره میکند، سپس تأیید کنید که ترافیک واقعی در هر دو جهت از آن عبور میکند. مسیریابی بازگشتی و وضعیت تونل را با هم بررسی کنید، زیرا ناسازگاری فاز دوم تونل را بالا و بار کاری را مرده باقی میگذارد. زمان انتقال را همانجا که هستید اندازه بگیرید.
هشدار، خروجی تلهمتری و برنامهٔ تغییر را در یک سابقه نگه دارید. آن سابقه هشدار سهماههٔ بعد را به بازبینی دو دقیقهای تبدیل میکند، نه بحثی دربارهٔ اینکه آیا کسی هرگز پشتیبان را آزموده است.