Известување на AWS за еден тунел: кога навистина е важно

Известувањето на AWS Health дека еден тунел е паднат обично пристигнува кога ништо не изгледа расипано. Токму затоа се отфрла. Известувањето не опишува прекин; опишува состојба на резервирање што траела подолго од прозорецот за набљудување на AWS. Дали ќе постапите зависи од тоа што може да го издржи вашиот дизајн, а не од тоа како изгледа контролната табла.

Што всушност измерило известувањето

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

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

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

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

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

Ако сите три се докажливо во ред, запишете зошто е подносливо и продолжете. Таа белешка вреди повеќе од расправата следниот квартал.

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

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

Два физички рутери исто така не го решаваат спротивниот случај. Кога двата тунели завршуваат на еден уред или излегуваат низ еден нагорен канал, резервирањето постои само на хартија.

Усогласете ја промената со нејзиниот радиус на влијание

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

Менувањето опции на еден тунел е трет случај со сопствено наведено влијание: тој тунел е недостапен за време на сопственото ажурирање, а другиот продолжува да работи.

Докажете ја алтернативата пред да ви треба

Закажете го тестот наместо да го чекате настанот. Спуштете го здравиот тунел во сервисен прозорец, потврдете дека алтернативата преговара, потоа потврдете дека вистинскиот сообраќај поминува низ неа во двете насоки. Проверете го повратното насочување како и статусот на тунелот, бидејќи несовпаѓање во втората фаза го остава тунелот подигнат, а работното оптоварување мртво. Измерете го преминот додека сте таму.

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