Powiadomienie AWS o jednym tunelu: kiedy naprawdę ma znaczenie

Powiadomienie AWS Health, że jeden tunel jest niedostępny, zwykle przychodzi, gdy nic nie wygląda na zepsute. Właśnie dlatego bywa ignorowane. Powiadomienie nie opisuje awarii; opisuje stan nadmiarowości, który trwa dłużej niż okno obserwacji AWS. To, czy zareagujesz, zależy od tego, co wytrzyma twoja konstrukcja, a nie od tego, jak wygląda panel.

Co powiadomienie faktycznie zmierzyło

Każde połączenie Site-to-Site ma dwa tunele, kończące się na różnych punktach końcowych AWS. Dokumentacja monitorowania AWS zaleca skonfigurowanie obu dla nadmiarowości i podnosi powiadomienie, gdy jeden pozostaje niedostępny przez udokumentowany okres. Ten okres ma znaczenie, ponieważ krótkie drganie i trwała utrata wyglądają identycznie na jednym wykresie.

Czytaj telemetrię poszczególnych tuneli, a nie ogólny stan połączenia. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' zwraca status i komunikat dla każdego tunelu, i to są dowody, na których opiera się powiadomienie.

Trzy warunki, które decydują o reakcji

Przejdź przez wszystkie trzy, zanim zdecydujesz, czy to zgłoszenie, czy wzruszenie ramionami.

Po pierwsze, czy ocalały tunel udźwignie obciążenie, w tym ewentualny limit przepustowości i ogłaszane prefiksy? Po drugie, czy przełączenie faktycznie następuje, skoro drugi tunel niedostępny od chwili utworzenia nigdy nie został udowodniony jako działający? Po trzecie, czy twoja następna planowana zmiana wyłączy oba tunele naraz, co zamienia kosmetyczne ostrzeżenie w problem okna serwisowego. Jeśli którakolwiek odpowiedź brzmi nie lub nie wiadomo, powiadomienie jest realnym ustaleniem.

Jeśli wszystkie trzy są udowodnione jako dobre, zapisz, dlaczego jest to dopuszczalne, i idź dalej. Ta notatka jest warta więcej niż dyskusja w następnym kwartale.

Czego nie dowodzi peer zapasowy

Brama klienta ze skonfigurowanym peerem zapasowym nie jest dowodem, że AWS widzi dwa zdrowe tunele. Strona klienta może trzymać zimny peer wymagający nowej negocjacji, i to może być uzasadniona konstrukcja. To nadal nie jest ta sama obserwacja co dwa działające tunele.

Dwa fizyczne routery też nie naprawiają odwrotnego przypadku. Gdy oba tunele kończą się na jednym urządzeniu albo wychodzą jednym łączem uplink, nadmiarowość istnieje tylko na papierze.

Dopasuj zmianę do jej promienia rażenia

Dokumentacja AWS dotycząca dokumentacja dotycząca wymiany punktów końcowych rozdziela przypadki, a tę różnicę łatwo przeoczyć. Aktualizacje zarządzane przez AWS są stosowane do jednego tunelu naraz. Zmiany inicjowane przez klienta w bramie docelowej, bramie klienta lub opcjach połączenia czynią oba tunele niedostępnymi, dopóki nie zostaną przygotowane zastępcze punkty końcowe.

Zmiana opcji na pojedynczym tunelu to trzeci przypadek z własnym, zadeklarowanym wpływem: ten tunel jest niedostępny podczas własnej aktualizacji, a drugi działa dalej.

Udowodnij alternatywę, zanim jej potrzebujesz

Zaplanuj test zamiast czekać na zdarzenie. Wyłącz zdrowy tunel w oknie serwisowym, potwierdź, że alternatywa negocjuje, a następnie potwierdź, że rzeczywisty ruch przechodzi przez nią w obu kierunkach. Sprawdź routing powrotny oraz status tunelu, ponieważ niezgodność drugiej fazy zostawia tunel w górze, a obciążenie martwe. Zmierz czas przejścia, póki tam jesteś.

Trzymaj powiadomienie, wynik telemetrii i plan zmian w jednym zapisie. Ten zapis zmienia powiadomienie w następnym kwartale w dwuminutowy przegląd, a nie spór o to, czy ktokolwiek kiedykolwiek testował zapas.