La fine del primo e l’inizio del secondo mese dell’estate 2019 si sono rivelate difficili e sono state caratterizzate da diversi forti cali dei servizi IT globali. Tra i più notevoli: due gravi incidenti nell'infrastruttura CloudFlare (il primo - con mani storte e atteggiamento negligente nei confronti di BGP da parte di alcuni ISP statunitensi; il secondo - con un'implementazione disonesta degli stessi CF, che ha colpito tutti coloro che utilizzavano CF , e questi sono molti servizi degni di nota) e il funzionamento instabile dell'infrastruttura CDN di Facebook (ha interessato tutti i prodotti FB, inclusi Instagram e WhatsApp). Abbiamo dovuto impegnarci anche nella distribuzione, sebbene la nostra interruzione sia stata molto meno evidente nel contesto globale. Qualcuno ha già iniziato a coinvolgere elicotteri neri e cospirazioni “sovrane”, quindi stiamo pubblicando un’autopsia pubblica del nostro incidente.
03.07.2019, 16: 05
Si iniziarono a registrare problemi con le risorse, simili a un'interruzione della connettività della rete interna. Non avendo controllato tutto, hanno iniziato a criticare le prestazioni del canale esterno verso DataLine, poiché è diventato chiaro che il problema riguardava l'accesso della rete interna a Internet (NAT), al punto da mettere la sessione BGP verso DataLine.
03.07.2019, 16: 35
Era evidente che l’apparecchiatura che forniva la traduzione degli indirizzi di rete e l’accesso dalla rete locale del sito a Internet (NAT) era guasta. I tentativi di riavviare l'apparecchiatura non hanno portato a nulla, la ricerca di opzioni alternative per organizzare la connettività è iniziata prima di ricevere una risposta dal supporto tecnico, poiché per esperienza questo molto probabilmente non avrebbe aiutato.
Il problema era in qualche modo aggravato dal fatto che queste apparecchiature interrompevano anche le connessioni in entrata dei dipendenti della VPN del client e il lavoro di ripristino remoto diventava più difficile da eseguire.
03.07.2019, 16: 40
Abbiamo provato a far rivivere uno schema NAT di backup esistente che aveva funzionato molto bene prima. Ma divenne chiaro che una serie di ristrutturazioni della rete rendevano questo schema quasi completamente inoperante, poiché il suo ripristino avrebbe potuto, nella migliore delle ipotesi, non funzionare o, nella peggiore, rompere ciò che già funzionava.
Abbiamo iniziato a lavorare su un paio di idee per trasferire il traffico a una serie di nuovi router che servono la dorsale, ma sembravano impraticabili a causa delle peculiarità della distribuzione dei percorsi nella rete centrale.
03.07.2019, 17: 05
Allo stesso tempo, è stato identificato un problema nel meccanismo di risoluzione dei nomi sui name server, che ha portato a errori nella risoluzione degli endpoint nelle applicazioni, e hanno iniziato a riempire rapidamente i file host con record di servizi critici.
03.07.2019, 17: 27
La funzionalità limitata di Habr è stata ripristinata.
03.07.2019, 17: 43
Ma alla fine è stata trovata una soluzione relativamente sicura per organizzare il traffico attraverso uno dei router di confine, che è stata installata rapidamente. La connettività Internet è stata ripristinata.
Nei minuti successivi dai sistemi di monitoraggio sono arrivate numerose notifiche sul ripristino della funzionalità degli agenti di monitoraggio, ma alcuni servizi si sono rivelati inutilizzabili perché il meccanismo di risoluzione dei nomi sui name server (DNS) era rotto.
03.07.2019, 17: 52
NS è stato riavviato e la cache è stata svuotata. La risoluzione è stata ripristinata.
03.07.2019, 17: 55
Tutti i servizi hanno iniziato a funzionare tranne MK, Freelansim e Toaster.
03.07.2019, 18: 02
MK e Freelansim hanno iniziato a lavorare.
03.07.2019, 18: 07
Ripristina una sessione BGP innocente con DataLine.
03.07.2019, 18: 25
Hanno iniziato a registrare problemi con le risorse, dovuti al cambiamento dell'indirizzo esterno del pool NAT e alla sua assenza nell'ACL di una serie di servizi, che sono stati prontamente corretti. Il tostapane ha iniziato a funzionare subito.
03.07.2019, 20: 30
Abbiamo notato errori relativi ai bot di Telegram. Si è scoperto che si erano dimenticati di registrare l'indirizzo esterno in un paio di acl (server proxy), cosa che è stata prontamente corretta.
risultati
- L'attrezzatura, che in precedenza aveva suscitato dubbi sulla sua idoneità, si è guastata. Si pensava di eliminarlo dal lavoro, poiché interferiva con lo sviluppo della rete e presentava problemi di compatibilità, ma allo stesso tempo svolgeva una funzione critica, motivo per cui qualsiasi sostituzione era tecnicamente difficile senza interrompere i servizi. Ora puoi andare avanti.
- Il problema DNS può essere evitato spostandoli più vicino alla nuova rete dorsale al di fuori della rete NAT e mantenendo la piena connettività alla rete grigia senza traduzione (che era il piano prima dell'incidente).
- Non utilizzare nomi di dominio durante l'assemblaggio di cluster RDBMS, poiché la comodità di modificare in modo trasparente l'indirizzo IP non è particolarmente necessaria, poiché tali manipolazioni richiedono comunque la ricostruzione del cluster. Questa decisione è stata dettata da ragioni storiche e, prima di tutto, dall'ovvietà degli endpoint per nome nelle configurazioni RDBMS. In generale, una trappola classica.
- In linea di principio sono stati condotti esercizi paragonabili alla “sovranizzazione della Runet”, c’è qualcosa a cui pensare in termini di rafforzamento delle capacità di sopravvivenza autonoma.
Fonte: habr.com