ACTUACIÓINCIDÈNCIA: Manteniment switchos edge (2024-07-01 22:30-23:59)
Resum
Tipus | |
Inici | 2024-07-01 20:30 (UTC) |
Final | 2024-07-01 23:59 (UTC) |
Tíquet | #1111 |
Alertes | |
Participen | @evilham, @exopedro (remot), glutec (remot+físic) |
Impacte | S’esperaven únicament microtalls, a causa d’un mal funcionament d’un dels switchos redundats va haver afectació de servei de connectivitat i de màquines virtuals. Traiem sw3 fora de servei, perdent redundància temporalment. |
Reporten | @evilham |
Relacionat amb intervenció 2024-06-12, crearem una VLAN nova als commutadors eXO.
Tot seguit es farà l’actuació equivalent a l’anterior intervenció 2024-06-12, però als switchos edge del rack, en comptes dels commutadors eXO.
Pla d’actuació
Tots els temps en UTC.
(veure desviacions en la línia de temps)
- 20:30: crear VLAN en
sw2
isw3
- acte seguit, reiniciar un per un
sw2
isw3
- 21:00: acompanyar amb monitorització i comprovacions als companys de Glutec
Línia de temps
Tots els temps en UTC.
- 20:30 INICI ACTUACIÓ
- 20:34 export de la config de
sw2
isw3
- 20:35 apliquem configuracions en
sw2
isw3
- revertim algunes desviacions menors de la config per defecte produïdes per actualitzacions de RouterOS (#1112)
- @evilham configura les claus SSH de les persones d’@exo-servers, comprova que es poden fer connexions noves als switchos
- creem la VLAN necessària
- 20:41 export de la config de
sw2
isw3
- 20:42 reinici
sw2
: tot ok - 20:44 reinici
sw3
: sembla que tot OK - 20:45 export de la config de
sw2
isw3
(cap canvi des de 20:41) - 20:46 INCIDÈNCIA
21:00 INICI PROGRAMAT ACTUACIÓ Glutec- 21:00 Actualitzem els companys de Glutec
- @exopedro i @dyangol poden accedir via OOB però no poden entrar als switchos (amb contrasenya)
- @evilham demana l’accés OOB d’@exopedro per fer el relleu i comprovar si tampoc hi pot accedir als switchos
- @evilham sí hi pot accedir
- això fa que lligui caps i conclou que els companys no carreguen les claus SSH necessàriament sempre
- i que RouterOS te alguna config en aquest sentit
- Busca ràpidament i aplica
/ip ssh set always-allow-password-login=yes
als dos switchos per poder comprovar amb els altres i fer un canvi més programat a claus SSH en els switchos
- 21:10 Glutec avorta temporalment actuació en Rack per recuperar servei eXO
- 21:19 veiem el següent a
sw2
en ferexport terse
per comprovar config#error exporting "/interface/bridge/mlag" (timeout) #error exporting "/interface/bridge/port" (timeout)
- 21:20 reiniciem
sw2
i comprovem que l’export dóna les dades correctes - 21:20 roger es comença a desplaçar per anar a CPD
- 21:47 després de comprovar els switchos, apaguem
sw3
perquè es comporta estrany i no ensenya bé les MAC (sw2
sí), @dyangol surt amb roger a CPDsw3
no contestava en fer la comanda export, tampoc ensenyava les MACs de dispositius,sw2
sí
- 21:50 els serveis bàsics es comencen a restaurar, únicament amb haver apagat
sw3
- 22:00 comprovem cluster i analitzem estat de la mar
- ~22:48 desconnectem de la corrent
sw3
perquè no s’engegui si passa quelcom - 22:50 glutec aprofita que estan físicament a CPD per efectuar la seva actuació amb més seguretat
- actualitzant-ne els commutadors edge es produeixen un total de 4 talls curts (< 1min)
- 23:07 comprovem que els canvis no han tingut cap repercussió negativa
- 23:14 finalitzada l’actuació de Glutec, acabem d’engegar tots els serveis eXO de tercers
- 23:53 acabem de restaurar i comprovar tots els serveis propis
- 23:59 FINAL ACTUACIÓ
Detecció
Hem detectat que l’actuació es convertia en incidència ambdós gràcies a alertes i persones.
status.eXO.cat no estava disponible durant l’incident(!)
Possible millora d’alertes
- Podríem intentar agrupar alertes en "Estat de cluster KO (però no necessàriament val la pena fer-ho)
- Tot i tenir un CNAME amb un TTL alt, status.eXO.cat no estava disponible (DNS)
- No és útil tenir severitats
Warning
iCritical
en funció del temps d’incidència, únicament produeix soroll
Conclusions
- El comportament dels switchos redundats ens torna (#1094) a fer pensar en un problema de hardware
- Necessitem prioritzar #490: reforçar o aïllar la connexió intra-cluster (backend) perquè no depengui de la connexió externa (frontend)
- Vam fer bé d’encadenar les dues actuacions independents, tot i tenir una complexitat molt baixa l’actuació de l’eXO; d’aquesta manera hem pogut reaccionar bé i en un temps molt raonable
Què ha anat bé?
- Hem pogut col·laborar sense inconvenients i reaccionar ràpidament
- L’accés OOB funciona molt bé, tant als switchos com IPMI
Què no ha anat bé?
- status.eXO.cat no estava disponible durant la incidència (DNS)
- un fallo de hardware de connectivitat externa ha provocat inestabilitat en el cluster(!)
- no totes les persones involucrades teníem l’accés OOB
- @evilham no va comprovar que l’accés sense clau SSH seguia sent possible, això va costar ~5 minuts de retràs innecessari en un moment de tensió
- no tenim una vista clara de l’estat SHOULD de les màquines virtuals, i una manera fàcil de comparar-ho amb l’estat real per recuperar l’estat de servei
En què hem tingut sort?
- El cluster s’ha recuperat bé i ràpidament tan aviat com hem solucionat l’incident dels switchos (apagant
sw3
i perdent redundància)
Enllaços a documentació rellevant
Accionables
- Gestionar l’accés OOB totes les persones que treballen amb el cluster (fet reunió @exo-servers #1118)
- Recuperar redundància de switchos
- Consensuar la compra i successió de
sw3
(fet reunió @exo-servers #1118) - #1119 reemplaçar
sw3
- Consensuar la compra i successió de
- #490 Avaluar viabilitat tècnica i econòmica d’afegir connectivitat “backend” exclusiva intra-cluster amb switchos redundats exclusius
- #XXX afegir a status.eXO.cat la monitorització de l’anella guifi
- Crear un dump de l’estat SHOULD de les VMs i una manera fàcil de comparar l’estat real (fet a: exo/projectes)