Upozornění AWS na jeden tunel: kdy skutečně záleží

Upozornění AWS Health, že jeden tunel je mimo provoz, obvykle dorazí, když nic nevypadá rozbité. Právě proto se odbývá. Upozornění nepopisuje výpadek; popisuje stav redundance, který přetrval déle než pozorovací okno AWS. Zda zasáhnete, závisí na tom, co váš návrh vydrží, ne na tom, jak to působí na dashboardu.

Co upozornění skutečně změřilo

Každé připojení Site-to-Site má dva tunely zakončené na různých koncových bodech AWS. Dokumentace AWS pro monitoring doporučuje nakonfigurovat oba pro redundanci a zvedá oznámení, když jeden zůstane mimo provoz po dokumentovanou dobu. Ta doba je důležitá, protože krátké zakolísání a trvalá ztráta vypadají v jednom grafu stejně.

Čtěte telemetrii jednotlivých tunelů, ne celkový stav připojení. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' vrací stav a zprávu pro každý tunel, a to je důkaz, o který se upozornění opírá.

Tři podmínky, které určují vaši reakci

Projděte všechny tři, než se rozhodnete, zda je to tiket, nebo pokrčení ramen.

Za prvé, unese přežívající tunel zátěž, včetně případného stropu šířky pásma a prefixů, které inzeruje? Za druhé, probíhá přepnutí skutečně, když druhý tunel mimo provoz od vzniku nikdy nebyl prokázán jako funkční? Za třetí, srazila by vaše další plánovaná změna oba tunely najednou, čímž by se kosmetické varování změnilo v problém servisního okna. Pokud je některá odpověď ne nebo neznámá, je upozornění skutečným zjištěním.

Pokud jsou všechny tři prokazatelně v pořádku, zapište, proč je to snesitelné, a jděte dál. Ta poznámka má větší cenu než hádka příští čtvrtletí.

Co záložní peer neprokazuje

Zákaznická brána s nakonfigurovaným záložním peerem není důkazem, že AWS vidí dva zdravé tunely. Strana zákazníka může držet studený peer, který potřebuje nové vyjednání, a to může být legitimní návrh. Pořád to ale není stejné pozorování jako dva živé tunely.

Dva fyzické routery neřeší ani opačný případ. Když oba tunely končí na jednom zařízení nebo vycházejí jedním uplinkem, redundance existuje jen na papíře.

Přizpůsobte změnu jejímu dopadu

Dokumentace AWS k dokumentace k nahrazení koncových bodů případy odděluje a toto rozlišení lze snadno přehlédnout. Aktualizace spravované AWS se aplikují na jeden tunel po druhém. Změny zahájené zákazníkem v cílové bráně, zákaznické bráně nebo v možnostech připojení učiní oba tunely nedostupnými, dokud se nezřídí náhradní koncové body.

Změna možností na jediném tunelu je třetí případ s vlastním uvedeným dopadem: tento tunel je během své aktualizace nedostupný a druhý běží dál.

Prokažte alternativu, než ji budete potřebovat

Naplánujte test místo čekání na událost. Srazte zdravý tunel v rámci servisního okna, potvrďte, že se alternativa vyjedná, a pak potvrďte, že přes ni v obou směrech prochází skutečný provoz. Zkontrolujte zpětný routing i stav tunelu, protože nesoulad druhé fáze nechá tunel nahoru a zátěž mrtvou. Změřte dobu přechodu, když už tam jste.

Uchovejte upozornění, výstup telemetrie a plán změn v jednom záznamu. Ten záznam promění upozornění příštího čtvrtletí ve dvouminutovou revizi místo hádky o tom, zda někdo vůbec záložní tunel testoval.