2026-06-17 12:26-14:40 Incident general a tots els serveis

exopedro · 17 juny 2026 13:20

Resum


Tipus	Incident
Inici	2026-06-17 12:26 (10:20 UTC)
Final	2026-06-17 14:40 (13:00 UTC)
Tíquet	#1265
Alertes	Sí
Participants	pedro, evilham, roger, víctor
Impacte	50% aprox. de tots els serveis la majoria de temps de l’incident, tots els serveis en reestabliment servei
Reporten	@exopedro

Situació espai disc redundat principal ha col·lapsat, algunes màquines han començat a deixar de funcionar, l’alliberament d’espai ha generat corrupció de dades en VMs que ha requerit reiniciar servei d’internet general

Línia de temps

Tots els temps en zona horària CEST.

[ un altre queixa d’un servei de plataformess apunta a ahir per la tarda que un servei donava 502 bad gateway, i que podria estar relacionat, el fil de correu corresponent pedro el rep a les 12:22 ]
12:26 INICI incident
12:26 [ descobert a les 13:25 ] Segons una gràfica proxmox de media.exo.cat comença a fallar
13:16 leandro ens avisa que media.exo.cat no funciona
13:25 pedro reestableix aquest servei, però veu que afecta a altres serveis, i que és degut a problemes espai en vm_nvme, abaixa de 98.89% (4.08 TB of 4.13 TB) a 83.63% (3.45 TB of 4.13 TB). Alguns serveis han quedat una mica degradats o afectats, hi ha un problema general de connectivitat internet, i per tant relacionat amb els IX de sortida, i/o amb glutec.
13:49 pedro truca evilham, evilham diu que fibres funcionen
13:57 pedro truca roger garcia, roger garcia diu que no és problema general glutec, confirma per tant que és un problema d’eXO
14:00 pedro truca a víctor, i fem intervenció urgent de reestabliment ix. Reiniciem ix1, deixem ix2 apagat
14:40 FINAL incident ( status.exo.cat marca tot verd )

Detecció

Veure les diferents fases de detecció del problema explicades a través de la línia de temps

Possible millora d’alertes

Afegir alerta storage proxmox de vm_nvme quan està igual o per sobre de 80%

Conclusions

Es confirma que el problema d’espai que veníem arrossegant pot arribar a ser bastant crític com hem comprovat

Què ha anat bé?

La disponibilitat de l’equip per resoldre el problema ràpid, les eines com status.exo.cat, la interacció tant directa amb glutec

Què no ha anat bé?

El volum d’alertes guifi.net ens ha generat un punt cec de les alertes que rebem; és bo que silenciem aquelles alertes que no som capaces de gestionar per tal de que arribin les importants
Des de wireguard OOB és difícil gestionar proxmox

En què hem tingut sort?

En haver-lo agafat a temps i no haver esperat gaire més

Accionables

Silenciar alertes guifi.net (ens generen punt cec)
Seguir abaixant ús espai en vm_nvme, ara està a 83.63% (3.45 TB of 4.13 TB) fins estar per sota de 80%
Generar alerta si espai és igual o superior a 80%
Idea: calcular espai total assignat a vm_nvme i que aquest no exedeixi 10% de l’espai total, evitant d’aquesta manera overbooking
L’accés OOB no té accés a la VLAN 98
Activar DNS autoritatiu extern (TODO evilham: documentar)

leandro · 18 juny 2026 07:00

Va afectar també a la connectivitat dels servidors, al menys els de Pangea.org una estona.

Hi ha alguna manera de veure la durada exacta del temps de parada dels encaminador(s)? He vist un graphana però no em deixa entrar amb login eXO.

Servei IP: Només hi ha un encaminador o ruta IP, no hi ha redundància?

Tots els serveis, també el de IP, depenen críticament d’un disc redundant compartit i sense separació, un sol servei descontrolat pot tirar avall la resta?

Gràcies per la reacció ràpida, llàstima per la caiguda, ens dona una oportunitat per millorar el servei i la tranquilitat de les persones al voltant de la xarxa.

evilham · 18 juny 2026 15:58

He afegit una gràfica.

Si vols ens reunim ara per comentar coses, era una reunió planejada.

El resum és que si el clúster sencer cau o es degrada, sí que es pot veure afectada la connectivitat per exemple a Pangea.

En principi que el clúster quedi en aquest estat ha de ser força estrany, però fa mesos que estem justos d’emmagatzematge, i per això en assemblea vam aprovar comprar i instal·lar més maquinari, ja tenim coses avençades, però no estan llestes i tampoc comptàvem que s’arribés a aquest punt encara.

exopedro · 19 juny 2026 08:27

Servei IP: Només hi ha un encaminador o ruta IP, no hi ha redundància?

No, tenim dos encaminadors ix1, ix2; de fet, durant la incidència va afectar només la meitat dels serveis ja que l’altre estava funcionant. Sols que en el pitjor moment de la intervenció, doncs vam generar més tall, perquè anàvem amb peus de plom, i perquè feia temps que no ens hi trobàvem amb un incident així. Al cap i a la fi, ho gestionem des del voluntariat, i cadascú té altres coses, llavors en moments així, intentem recordar, i aportem documentació amb pols, etc.

Tots els serveis, també el de IP, depenen críticament d’un disc redundant compartit i sense separació, un sol servei descontrolat pot tirar avall la resta?

Dit així sona com si tinguéssim un sistema bastant dolent, però jo no ho veig així, crec que tenim un sistema molt fiable; tot sistema, per redundat que sigui, té punts febles que s’han de cuidar, el punt feble d’aquest és arribar al límit d’espai, i aquest esdeveniment, per cert, no ens havia passat en tota la història del cluster eXO, una aventura que va començar fa uns 9 anys si no recordo malament.

Prenem nota, no ens agrada que passi, i per cert, tampoc és tant descontrol·lat, tots els discos venen de màquines virtuals tenen una quota d’ús, estem veient un percentatge d’ús, simplement necessitem ser més conservadors amb aquesta dada, i ja hem vist què passa quan ho deixem estar. L’espai havia arribat a 95%, i més o menys ha funcionat així per setmanes i mesos; ara està en un 81%, crec que fora bo, com he posat en els accionables, de tenir-ho sempre per sota de 80%, o sigui que ara seguirem fent neteja i abaixant fins arribar a la cota.

I també fora bo de rebre una alerta quan torna a 80% per tornar a fer neteja, migrar serveis a altres storages, o deixar de mantenir determinats serveis, més projectes, etc. fins resoldre el problema.