Известие на 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 актуализации се прилагат към един тунел наведнъж. Промените, инициирани от клиента, в целевия шлюз, клиентския шлюз или опциите на връзката правят двата тунела недостъпни, докато се подготвят заместващи крайни точки.

Промяната на опции на един тунел е трети случай със собствено заявено въздействие: този тунел е недостъпен по време на своята актуализация, а другият продължава да работи.

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

Планирайте теста вместо да чакате събитието. Спуснете здравия тунел в прозорец за поддръжка, потвърдете, че алтернативата договаря, след което потвърдете, че реален трафик преминава през нея в двете посоки. Проверете обратното маршрутизиране, както и статуса на тунела, защото несъответствие във втората фаза оставя тунела вдигнат, а работният товар мъртъв. Измерете времето за преход, докато сте там.

Пазете известието, изхода от телеметрията и плана за промяна в един запис. Този запис превръща известието следващото тримесечие в двуминутен преглед вместо спор дали някой някога е тествал резерва.