Stimati clienti,

Pe data de 21.03.2017 00:14 a intervenit o avarie hardware la unul din echipamentele noastre de storage web.

In urma incidentului, site-urile respective nu sunt accesibile afisandu-se dupa caz “Website in mentenanta” sau “Service temporary unavailable“.
Toate celelalte storage-uri web functioneaza in parametrii normali, precum si restul serviciilor Zooku (DNS, Mail, MySQL, etc).
Daca ati fost afectat de aceasta avarie (aprox. 400 siteuri), trebuie sa stiti ca datele web de pe storage au fost corupte (cele de mysql NU au fost afectate) si in acest moment sunt in proces de recuperare din backupul zilei precedente. Avand in vedere numarul foarte mare de fisiere, aceasta operatie poate dura inca 12-14 ore.
Nu este necesara interventia dvs, restore-ul se va face de catre noi, si va vom anunta periodic prin update statusul, ETR-uri mai precise, precum si finalizarea acestuia.
In cazul in care site-ul a fost modificat ieri, 20 Martie, acele modificari s-au pierdut si va rugam sa le refaceti dupa finalizarea restore-ului. Pina atunci va rugam nu folositi serviciul FTP pentru a asigura coerenta datelor.
Ne cerem scuze pentru inconvenienta si va asiguram lucram intensiv la remedierea situatiei.
Vom analiza post-mortem incidentul si vom trage concluziile necesare pentru a preintampina astfel de cazuri.

Zooku Solutions SRL.

 

Update 1:

La ora 00:27 adminul on-call, sesizat de sistemul de monitorizare, a inceput investigarea incidentului.
S-a descoperit ca sistemul de fisiere este corupt iar fs-ul a fost remontat read-only pentru limitarea efectelor negative.
Respectivul storage web este unul legacy, fiind programat sa fie migrat catre noul sistem de storage-uri la jumatatea lunii aprilie.

La ora 00:37 s-a primit prima sesizare de la client, suportul on-call fiind anuntat deja de admini, a deschis un ticket pentru monitorizarea
situatiei

La ora 00:43 a fost contactat adminul raspunzator de clusterul de storage pentru investigatii avansate.
S-a descoperit o problema hardware la controllerul de raid: unul din disk-uri a fost scos afara din raid, reacceptat si in starea de rebuild.
Array-ul respectiv este de tip RAID10 (https://en.wikipedia.org/wiki/Nested_RAID_levels#RAID_10_.28RAID_1.2B0.29), rezistent la pierderea unui disk.
Mai precis, array-ul este format din patru disk-uri (d1…d4) din care d1 cu d2 in mirror (RAID1), d3 cu d4 in mirror (RAID1) iar rezultatul ambelor mirrors in stripes (RAID0).
Cu toate acestea, dintr-un concurs nefericit de imprejurari, au ‘cedat’ simultan ambele discuri d3 si d4.
La ora respectiva, disc-ul d3 a fost dat afara, redescoperit si s-a initiat automat procedura de rebuild. In acest timp, d4 aflat in stress IO de transferul datelor catre d3 (plus tot array-ul in load IO datorita sistemului de backup zilnic care rula la ora respectiva), d4 a dat mai multe time-out-uri afectand procesul de rebuild si provocand initierea de catre controller a unui proces de verificare a tuturor datelor de pe array.
Datorita erorilor de citire de pe d4, sistemul de fisiere de pe subunitul d3+d4 si ulterior de pe intreg array-ul a fost corupt iar controllerul raid a ramas blocat pe verify & rebuild la 11%.

La ora 01:30 a fost anuntat seful departamentului tehnic de situatia existenta, care a adunat toata echipa tehnica pentru remedierea problemei.

In orele urmatoare s-au incercat diferite variante de refacere a array-ului si a corecta sistemul de fisiere dar fara success.
Practic, desi disk-urile in sine sunt functionale (fara erori SMART, se pot citi/sterge de pe ele) si desi avem in magazie inca doua disk-uri noi de rezerva pentru astfel de cazuri, datele de pe d3 si d4 sunt corupte si nu pot fi corectate. Conform legii lui Murphy, in intervalul 1-3 datacenterul avea programata o lucrare de mentenanta, lucru ce a facut ca toate operatiunile de remote-hands efectuate cu aceasta ocazie sa aiba diferite intarzieri.

Incepand cu ora 4, a devenit din ce in ce mai clar ca solutia de recuperare a storage-ului actual nu va avea reusita, astfel incat majoritatea eforturilor au fost indreptate spre instalarea unui nou storage pe noul sistem ( devansand calendarul migrarii datorita incidentului ) si recuperarea datelor din backup. S-a observat ca backupul de astazi nu a avut timp sa se finalizeze a.i. s-a ales backupul de ieri 20 care este intreg si coerent. Se ia decizia sa se faca restore la fisiere in bloc, fara a trata clientii diferentiat. De asemenea, odata ce s-au clarificat task-urile, o parte din echipa se apuca de treaba si restul sunt programati sa preia problema dupa pranz daca este cazul.

La ora 5:30 sistemul nou era pornit si se efectuau primele teste de sincronizare a site-urilor clientilor.
Se observa ca majoritatea site-urilor contin CMS-uri de dimensiune totala relativ mica dar cu un numar impresionant de fisiere. Avand in vedere ca apare un overhead la deschiderea si citirea fiecarui fisier, timpul initial estimativ de copiere se apropia de 48h, lucru inacceptabil din partea noastra.
Se cauta si se implementeaza solutii de optimizare a timpului de restore pina acesta scade estimativ sub un conservator 12h.

In jurul orei 6:20 se da drumul la procesul de restore iar la ~ 6:30 se anunta clientii printr-un post pe blogul oficial.
In paralel cu datele clientilor se lucreaza intensiv la instalarea si configurarea stack-ului web precum si legatura cu sistemul de provizionare.

Multumim celor sapte clienti care ne-au atentionat despre problema in aceasta noapte si care ne-au incurajat si inspirat.
Multumim si celor care nu au sunat, suntem constienti de responsabilitatea pe care o avem fata de voi si asta ne motiveaza si mai tare.

Update 2:

La ora 08:15, procesul de restore continua cu success si in ritm accelerat.
De departe restore-ul este procesul cel mai time-consuming, dupa el urmand cel de testare a functionalitatii site-urilor.
Momentan (8:30) viteza de transfer este oscilanta, un ETR conservator fiind de 8h, iar unul optimist de 4h.

 

Update 3:
Ora 11:00, mai mult de jumatate de site-uri recuperate din backup. Procesul de restore isi urmeaza planul de actiune si continua in acelasi ritm.
S-a luat decizia ca sa se dea drumul la tot storage-ul chiar daca nu toate site-urile au fost recuperate inca. Celor care au site-ul restaurat o sa le functioneze precum ieri. Cei care inca nu au site-ul restaurat, o sa primeasca in continuare o eroare de tip 403/500 (diferita fata de cea de acum
– Mentenanta/503). Decizia este in favoarea clientilor (desi pentru noi complica un pic lucrurile), in scopul de a minimiza time to live si s-a efectuat la 11:07.

Va rugam sa verificati functionalitatea site-ului si in caz de probleme sa ne trimiteti pe mail reclamatiile a.i. sa putem deschide ticket si urmari rezolvarea lor. Vom raspunde probabil cu mici intarzieri, dar vom raspunde la absolut toate emailurile.

Va reamintim ca toate modificarile efectuate ieri din interfata aplicatiei (adica salvate in baza de date) s-au pastrat, in schimb cele efectuate ieri din Filemanager / FTP (adica asupra fisierelor html/php) nu pot fi recuperate.

Pentru restul clientilor, ii rugam sa mai aiba putina rabdare pina se termina procesul de restore. Estimated Time of Repair ~= 1-3h

 Update 4:
La ora 11:56 s-a finalizat restore-ul tuturor site-urilor.
La ora 11:58 s-a dat access la serviciul FTP si primii clienti au inceput sa se conecteze.
Unii au repus modificarile de ieri, altii fac actualizari noi sau isi downloadeaza o copie de siguranta.
Verificam in continuare serviciile, analizam logurile, adaugam teste noi in sistemul de monitorizare, raspundem la cele
cateva tickete legate de quota depasita.

Lucrurile sunt linistite la suport si va multumim pentru asta!
Consideram incidentul incheiat cu success la ora 12:10.

Scrie un comentariu

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.