Cum să rămâi online după un incendiu în datacenter

În această săptămână am avut un exemplu de scenariu-dezastru la un datacenter OVH din Strasbourg, care a distrus un întreg datacenter și a dus offline mai multe datacentere din zonă.

Cu ocazia acestui incident mai multe site-uri, magazine online și aplicații găzduite în acel datacenter au fost complet offline, iar echipele de suport ale acestora se străduiau să readucă site-urile online.

Ca și inginer, primul lucru la care te gândești este cum se poate preveni un scenariu catastrofal ca și acesta.

Deși este ușor să dai vina pe datacenter și să cataloghezi evenimentul ca și un scenariu imposibil de prevenit, realitatea este că aplicațiile pot fi proiectate pentru reziliență chiar și în cazul unui scenariu catastrofal ca și indisponibilitatea unui întreg datacenter.

Multi-server & Multi-AZ

Primul pas este să-ți construiești shop-ul într-un mod care este capabil să ruleze pe o arhitectură multi-server. Dacă magazinul tău nu poate rula distribuit pe mai multe servere simultan, lucruri mult mai simple decât un incendiu de data center vor duce magazinul tău să fie offline.

Odată ce magazinul tău are posibilitatea rulării pe mai multe servere și are o bază de date cu replicare, este timpul să distribui magazinul în multiple datacenter (AZ - availability zones).

Majoritatea companiilor de hosting cloud au multiple AZ-uri în fiecare dintre regiunile lor, iar serviciile sunt pregătite pentru deployment-uri multi-AZ.

La Zento, magazinele online rulează pe AWS, iar clusterul EKS (Elastic Kubernetes Service) și baza de date RDS rulează în deployment-uri multi-AZ. Servicii managed precum Lambda, S3 sau CloudFront sunt multi-AZ în mod nativ. Astfel, magazinele Zento au redundanță pe fiecare dintre componente, iar picarea oricărei componente nu va rezulta într-un downtime.

Backup & Disaster Recovery

Pe lângă arhitectura pentru reziliență, back-up-urile trebuie să fie frecvente, încât recuperarea la o versiune recentă să fie posibilă în cazul unui dezastru.

Back-up-urile trebuie să fie de asemenea stocate separat sau într-un serviciu ca și AWS S3 care are replicare garantată în mai multe datacentere. În caz contrar, un incident ca și incendiul în datacenter poate duce la pierderea back-up-urilor odată cu restul datelor.

Nu în ultimul rând, trebuie creată în avans o procedură de disaster recovery pentru a putea avea o reacție rapidă când este nevoie.

Concluzie

Arhitectura rezilientă cade în sarcina programatorilor și echipei DevOps, care trebuie să pregătească această arhitectură din timp.

Ca și comerciant, trebuie să ceri echipei o astfel de arhitectură și, cel mai important, să ai disponibilitatea să plătești costurile asociate. Prevenirea este mult mai ieftină decât impactul pe care un astfel de incident o poate avea.

Chiar și cu toate măsurile de reziliență, trebuie să te pregătești pentru ce este mai rău și să speri că nu se întâmplă: trebuie să ai back-up-uri multiple back-up-uri disponibile (și să verifici periodic existența și corectitudinea acestora) și proceduri de recuperare în caz de dezastru.