Avviso AWS di un solo tunnel: quando conta davvero

Un avviso AWS Health che segnala un tunnel inattivo di solito arriva quando nulla sembra rotto. È esattamente per questo che viene ignorato. L’avviso non descrive un’interruzione; descrive uno stato di ridondanza che è persistito oltre la finestra di osservazione di AWS. Se intervenite dipende da ciò che la vostra progettazione può sopportare, non da come appare la dashboard.

Che cosa ha misurato davvero l’avviso

Ogni connessione Site-to-Site ha due tunnel, terminati su endpoint AWS diversi. La documentazione di monitoraggio di AWS consiglia di configurare entrambi per la ridondanza e solleva la notifica quando uno resta inattivo per il periodo documentato. Quel periodo conta, perché un tremolio e una perdita permanente appaiono identici in un solo grafico.

Leggete la telemetria per tunnel invece dello stato complessivo della connessione. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' restituisce uno stato e un messaggio per ogni tunnel, ed è la prova su cui si basa l’avviso.

Tre condizioni che decidono la vostra risposta

Esaminatele tutte e tre prima di decidere se si tratta di un ticket o di un’alzata di spalle.

Primo, il tunnel sopravvissuto può portare il carico, compreso qualsiasi tetto di larghezza di banda e i prefissi che annuncia? Secondo, il failover avviene davvero, dato che un secondo tunnel inattivo dalla creazione non è mai stato dimostrato in grado di tornare su? Terzo, la vostra prossima modifica pianificata farebbe cadere entrambi i tunnel insieme, trasformando un avviso estetico in un problema di finestra di manutenzione. Se una risposta è no o sconosciuta, l’avviso è un riscontro reale.

Se tutte e tre sono dimostrabilmente a posto, annotate perché è tollerabile e proseguite. Quella nota vale più della discussione il prossimo trimestre.

Che cosa non dimostra un peer di riserva

Un customer gateway con un peer di riserva configurato non è prova che AWS veda due tunnel sani. Il lato cliente può tenere un peer freddo che richiede una nuova negoziazione, e questa può essere una progettazione legittima. Non è comunque la stessa osservazione di due tunnel attivi.

Due router fisici non risolvono nemmeno il caso opposto. Quando entrambi i tunnel terminano su un solo dispositivo o escono da un solo uplink, la ridondanza esiste solo sulla carta.

Allineate la modifica al suo raggio d’impatto

La documentazione sulla sostituzione degli endpoint di AWS separa i casi, e la distinzione è facile da trascurare. Gli aggiornamenti gestiti da AWS vengono applicati a un tunnel alla volta. Le modifiche avviate dal cliente sul gateway di destinazione, sul customer gateway o sulle opzioni di connessione rendono entrambi i tunnel non disponibili mentre vengono predisposti endpoint sostitutivi.

Cambiare le opzioni su un singolo tunnel è un terzo caso con il proprio impatto dichiarato: quel tunnel non è disponibile durante il proprio aggiornamento e l’altro continua a funzionare.

Dimostrate l’alternativa prima di averne bisogno

Pianificate il test invece di aspettare l’evento. Portate giù il tunnel sano all’interno di una finestra di manutenzione, confermate che l’alternativa negozia, poi confermate che il traffico reale la attraversa in entrambe le direzioni. Controllate l’instradamento di ritorno oltre allo stato del tunnel, perché un disallineamento della seconda fase lascia il tunnel attivo e il carico di lavoro morto. Cronometrate la transizione mentre siete lì.

Conservate l’avviso, l’output della telemetria e il piano di modifica in un unico registro. Quel registro trasforma l’avviso del prossimo trimestre in una revisione di due minuti invece di un dibattito sul fatto che qualcuno abbia mai testato la riserva.