Повідомлення 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 застосовуються до одного тунелю за раз. Зміни, ініційовані клієнтом, у цільовому шлюзі, клієнтському шлюзі або параметрах з'єднання роблять обидва тунелі недоступними, доки готуються замінювальні кінцеві точки.

Зміна параметрів на одному тунелі — це третій випадок із власним заявленим впливом: цей тунель недоступний під час свого оновлення, а інший продовжує працювати.

Доведіть альтернативу, перш ніж вона знадобиться

Заплануйте тест замість очікування події. Вимкніть здоровий тунель у вікні обслуговування, переконайтеся, що альтернатива домовляється, потім переконайтеся, що реальний трафік проходить через неї в обох напрямках. Перевірте зворотну маршрутизацію та стан тунелю, бо невідповідність другої фази залишає тунель піднятим, а робоче навантаження мертвим. Виміряйте час переходу, поки ви там.

Тримайте повідомлення, вивід телеметрії та план змін в одному записі. Цей запис перетворює повідомлення наступного кварталу на двіхвилинний огляд, а не суперечку про те, чи хтось колись тестував резерв.