Azi s-a intamplat perfect shitstorm-ul in materie de cum sa-ti crape toate o data.
Un port dintr-un switch de FC a decis sa se duca pulii de suflet si sa genereze erori si intarzieri. Asta s-a transmis spre un cluster de VMware ca are latente la accesul la disk si a inceput sa initieze tot felul de mutari de masini virtuale astfel incat sa nu mai aiba probleme.
Care au pus si mai mult stres pe duda aia de port, ca intr-un final tot clusterul sa devina suficient de instatabil incat nimic sa nu mai mearga. Si toate request-urile de I/O sa se duca cumva fix pe portul stricat, ca altfel nu se putea.
Pana n-am oprit totul si am inceput sa le pornesc pe rand pana s-a stabilizat treaba nu s-a putut face nimic.
Si peste toate astea, s-a futut si timpul de pe masinile virtuale si nu mai mergea autentificarea in domeniu. Pe langa asta nu mai porneau nici servicii care erau legate de Active Directory si tot asa.
Dupa inca un rand e reboot-uri, totul si-a revenit la normal.
Ocazie cu care trebui sa-mi accelerez planurile pentru o modificare de design astfel incat daca se mai intampla chestii din astea, sa pot sa ma leg remote sa le repar.
Si cred ca un switch e pe cale sa ia drumul RMA-ului, ca totul pare OK, mai putin cand vreau sa trec trafic printr-un port anume prin el.
Pe vremea mea, switch-urile de FC aveau transceivere modulare … care erau modulare tocmai pentru ca optica si diodele LASER erau consumabile. Scoti ala vechi afara, bagi unul nou, pui cablul la loc and move on. Acuma nu mai e asa?
Apoi, ce ai patit tu e o problema clasica de controlul sistemelor inter-dependente:
* switch-ul a facut ce trebuie, daca ar fi fost singur pe masa: a raportat erori pe portul X si poate l-ar fi si inchis pana la urma. Evident, orice configuratie normala are rendundanta, asa ca daca-ti pica doar un port/drum, nu e nici un bai.
* cluster-ul de VM a facut tot ce trebuie: a detectat ca un drum este suboptim si a incercat sa mute resursele si efortul in jur astfel incat sa ocoleasca constrangerea. Iarasi, orice configuratie normala are redundanta, asa ca distrugerea unui singur drum n-ar trebui sa aiba nici un efect.
Problema e ca cele doua *NU* au facut ce trebuie in contextul in care trebuiau sa lucreze impreuna. Ce-i de facut? Pai praftica din domeniu ne invata:
* fail fast and stay down. Daca un port a avut pana acum 10 erori pe luna si in ultimul minut tocmai a numarat 100, atunci se inchide imediat si se da mail/alarma la admin. Nu e treaba switch-ului sa faca singur reflectometrie pe cablu si sa-ti si zica daca e dioda dusa, cablul smuls sau curge apa din tavan pe conector :-) E suficient sa opreasca problema inainte de a ajunge si mai mare.
* make sure it’s you. Daca un cluster de VM brusc observa ca latenta cand discuta cu un LUN este evident mai mare ca de obicei, atunci trebuie sa-si puna intrebarea “is it *really* me?”. Fuga la tabela cu statistici: fac *eu* mai mult trafic catre acel LUN ca de obicei? Nu. Atunci stau naibii cuminte si nu ma apuc sa ma dau mai destept decat mama natura. Mail/alarma la admin cum ca nu-mi mai pot satisface SLA-ul pentru ca una din resursele de care depind (LUN-ul) a devenit nasoala si n-am nici o alternativa.
Acuma, in mod ideal, acele doua evenimente-alarma ar fi prinse de un sistem de alertare care ar aplica reguli de dependenta, si deci care ti-ar trimite tie, omul, doar pe cea de la switch — pentru ca aia este *cauza* celeilalte.
Tot in mod ideal, un produs comercial de virtualizare care are pretentii de “cloud-ready” si alte d’astea, face bine si monitorizeaza infrastructura ca un tot unitar; astfel incat, atunci cand pica portul de pe switch, stie *dinainte* ce LUN-uri vor fi afectate, ce VM-uri, ce aplicatii, ce SLA-uri — si astfel poate lua automat o decizie *informata* vis-a-vis de “ce mutam unde” sau “ce stingem ca sa supravietuiasca alea importante”.
Cam asta merge treaba acolo unde un SLA se masoara in sume cu sase cifre pe minut ;-)
Au si acum SFP-uri :P Doar ca nu pot sa-l schimb remote acum.
Unde s-a supt e ca erorile multe apar pe portul spre storage, nu spre host-uri.
Spre host-uri in 3-4 luni am cam 1-2k erori per port, care par a fi chestii transiente care nu afecteaza transferul de date. Tind sa cred ca host-urile mai raman fara BB credits si fac retry.
Configuratia e full mesh, numai ca s-a stricat unde nu trebuie :(
Legat de latenta pe cai, aici trebuie sa sap sa vad daca VMware are vreo optiune sa-i zic sa nu mai incerce o cale daca latenta end-to-end pe ea e mai mare de X msec. Merci de idee.
Pana apuc sa investighez de ce apar erori (switch, SFP, storage, fibra) am gasit un workaround in care VMware o sa stea cuminte astfel incat sa nu se amplifice problema. Nu e varianta optima, dar e mai bine decat “let’s panic, go berserk and bring everything down” :)
Nu stiu ce fel de VMware folosesti, dar daca era un sistem Linux generic, ala avea optiuni la nivel de driver de HBA pentru faza cu “please try another path before waking me up”. La fel si daca e facut in soft (LVM etc.). Poate poti scoate ceva de acolo desi intuitia imi zice ca ar cam fi trebuit sa fie deja activata aceasta functie.
Acum 1000 de ani si o zi, cand in kernel erau aproape nici unul dintre driver-ele de HBA si fiecare producator de HBA iti dadea driver-ul lui pe care il compilai de manuta etc., Hitachi avea o implementare foarte misto in care driver-ul era facut din doua felii: una se ocupa de vorbit cu placa PCI (de obicei un Emulex LP) si cealalta se ocupa de vorbit cu storage-ul. Asta din urma avea ceva notiuni de topologie si puteai defini chestii misto de genul “LUN-ul 0 nu e important, atata timp cat mai poti ajunge la el cumva e OK; LUN-ul 1 e foarte important, are 8 drumuri redundante si daca ajungi la doar 4, da alarma” etc. Cea din urma era cea care dadea kernel-ului block device-urile asa ca pentru VFS & friends totul era transparent.
VMware-ul meu n-are optiuni din astea :)
Saptamana viitoare o sa pot investiga problema ceva mai in detaliu. Ca am impresia ca ori opticele ori ceva pe portul ala din switch face figuri.