AWS обавештење о једном тунелу: када је заиста важно

AWS Health обавештење да је један тунел пао обично стиже када ништа не изгледа покварено. Управо зато се одбацује. Обавештење не описује прекид рада; описује стање редунданције које је потрајало дуже од AWS-овог прозора посматрања. Да ли ћете поступити зависи од тога шта ваш дизајн може да преживи, а не од тога како табла изгледа.

Шта је обавештење заиста измерило

Свака Site-to-Site веза има два тунела који завршавају на различитим AWS крајњим тачкама. AWS-ова документација за надзор препоручује конфигурисање оба ради редунданције и подиже обавештење када један остане пао током документованог периода. Тај период је важан јер кратко треперење и трајни губитак изгледају идентично на једном графикону.

Читајте телеметрију по тунелу, а не укупно стање везе. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' враћа статус и поруку за сваки тунел и то су докази на којима се обавештење заснива.

Три услова која одређују вашу реакцију

Прођите кроз сва три пре него што одлучите да ли је ово тикет или слегање раменима.

Прво, може ли преживели тунел да носи терет, укључујући било какав плафон пропусног опсега и префиксе које објављује? Друго, да ли се пребацивање заиста дешава, с обзиром на то да други тунел, пао од успостављања, никада није доказано да се подиже? Треће, да ли би ваша следећа планирана промена оборила оба тунела одједном, што козметичко упозорење претвара у проблем сервисног прозора. Ако је било који одговор не или непознат, обавештење је стварни налаз.

Ако су сва три доказиво у реду, запишите зашто је то подношљиво и наставите. Та белешка вреди више од расправе следећег квартала.

Шта резервни peer не доказује

Кориснички gateway са конфигурисаним резервним peer-ом није доказ да AWS види два здрава тунела. Корисничка страна може да држи хладни peer коме треба ново преговарање, и то може бити легитиман дизајн. То ипак није исто посматрање као два жива тунела.

Два физичка рутера такође не решавају супротан случај. Када оба тунела завршавају на једном уређају или излазе кроз један uplink, редунданција постоји само на папиру.

Ускладите промену са њеним домашајем

AWS-ова документација о замени крајњих тачака раздваја случајеве, а ту разлику је лако превидети. AWS-ом управљана ажурирања примењују се на један тунел одједном. Промене које покрене корисник на циљном gateway-у, корисничком gateway-у или опцијама везе чине оба тунела недоступним док се заменске крајње тачке не припреме.

Промена опција на једном тунелу трећи је случај са сопственим наведеним утицајем: тај тунел је недоступан током властитог ажурирања, а други наставља да ради.

Докажите алтернативу пре него што вам затреба

Закажите тест уместо да чекате догађај. Оборите здрави тунел унутар сервисног прозора, потврдите да се алтернатива преговара, а затим потврдите да стварни саобраћај пролази кроз њу у оба смера. Проверите повратно рутирање као и статус тунела, јер неслагање друге фазе оставља тунел подигнут, а радни терет мртав. Измерите време преласка док сте тамо.

Држите обавештење, излаз телеметрије и план промена у једном запису. Тај запис претвара обавештење следећег квартала у двоминутни преглед уместо расправе о томе је ли ико икада тестирао резерву.