Migrare servicii: website și alte servicii web

Iată că am ajuns și la ultimul episod din seria “migrarea serviciilor”! Dacă până acum am văzut cum se pot muta de pe un sistem pe altul serviciile DNS și serviciile email, a venit rândul celor mai utilizate și vizibile servicii – serverul web și serviciile conexe.

Datorită specificului (trafic mare, așteptările ca răspunsul să fie instantaneu și nici o metodă de a notifica clientul să reîncerce mai târziu), migrarea serviciilor web este și cea mai dificilă.

În procesul de migrare, în cea mai mare parte a cazurilor nu se mută doar fișierele de configurare ale serverului web și fișierele aplicațiilor, ci și bazele de date.

Cum de foarte multe ori informațiile din bazele de date reflectă starea fișierelor de pe hard-disk, este extrem de important ca migrarea să fie făcută fără a permite datelor să se desincronizeze, iar orice modificare ulterioară pe serverul inițial să se reflecte indentic pe sistemul țintă.

Pentru că efortul poate varia extrem de mult și soluțiile tehnice sunt diferite, am identificat trei situații posibile, în funcție de posibilitatea de a avea downtime:

Cazul 1: ne permitem downtime. Poate fi vorba de un blog personal, un sistem webmail sau un sistem folosit intern de angajați. În aceste cazuri ne permitem de obicei să “stingem” serverul câteva ore, cât timp facem migrarea.

Cazul 2: nu ne permitem downtime, dar ne permitem ceva latență. Avem pe server servicii care trebuie să ruleze permanent, dar nu este o problemă dacă rulează mai lent sau răspund mai greu. Un exemplu pot fi siturile de prezentare cu trafic mic, sistemele de monitorizare care sunt oricum dublate de alerte pe email/sms, aplicații interne folosite de angajați.

Cazul 3: nu ne permitem nimic! Serviciile trebuie să răspundă constant și extrem de repede. Cele mai comune exemple sunt magazinele online cu trafic foarte mare, aplicațiile web 2.0 sau sisteme care exportă date către alte aplicații (news tickere, acțiuni, cursuri valutare).

Să luăm acum fiecare caz în parte și să vedem care sunt pașii care trebuie urmați pentru a efectua migrarea fără probleme și cu cât mai puține efecte vizibile pentru utilizatori:

Cazul 1: ne permitem downtime.

Pazul 1: Se modifică în DNS adresa IP a serverului, astfel încât să indice către noul sistem.

Pasul 2: Se opresc serviciile web de pe ambele sisteme, în acest moment nu mai acceptăm cereri din afară.

Pasul 3: Se face un backup al fișierelor de pe sistemul vechi și un dump al bazei de date.

Pasul 4: Se restaurează fișierele, iar datele se introduc în baza de date pe sistemul nou.

Pasul 5: Se pornește sistemul nou, care va răspunde cererilor.

Pasul 6: Pentru că va dura câteva zile până când informațiile din DNS se propagă, este de preferat să redirectăm cererile care sosesc către serverul vechi către cel nou, prin una din următoarele metode:

• instalarea unei pagini HTML simple pe serverul vechi, care să indice “Serverul X are o nouă adresă, vă rugăm așteptați până se propagă informațiile sau goliți cache-ul DNS-ului”. Este metoda cea mai simplă, dar și cea mai “urâtă”.
• redirectarea din firewall a cererilor primite de portul 80 al serverului vechi. În funcție de configurația rețelei, această metodă poate funcționa foarte bine sau poate fi inutilă.
• configurarea pe portul 80 al serverului vechi a unui reverse proxy, care să primească cererile pentru domeniile deservite de serverul vechi, dar care nu le va rezolva local, ci le va trimite către noul sistem. Este metoda cea mai “frumoasă” și cea recomandată.

Pasul 7: Dacă au trecut 12-14 de ore și vechiul sistem nu a mai primit cereri, se poate considera migrarea încheiată și se poate opri serverul vechi.

Cazul 2: nu ne permitem downtime, dar ne permitem ceva latență.

Pasul 1: Actualizăm informațiile în DNS.

Pasul 2: Configurăm bazele de date astfel încât să facă replicarea datelor de pe sistemul vechi pe cel nou, astfel încât modificările se vor reflecta instantaneu pe ambele sisteme.

Pasul 3: Reconfigurăm aplicațiile web care rulează pe serverul vechi astfel încât să folosească serverul de baze de date de pe sistemul nou.

În acest moment vom avea cereri care sosesc către sistemul vechi, unde vor rula local aplicațiile web, dar bazele de date vor fi stocate pe sistemul nou. Va exista ceva latență pentru query-urile SQL între sisteme, în funcție de cantitatea de date, calitatea conexiunii și utilizarea criptării (recomand un VPN între cele două sisteme!).

Pasul 4: Exportăm de pe serverul nou un filesystem pe care vor fi stocate fișierele aplicațiilor web, astfel încât să putem să accesăm datele simultan de pe ambele servere. Datele se copiază în această locație, iar aplicațiile vor fi configurate să ruleze de aici (de cele mai multe ori este suficientă mutarea vechilor date într-o nouă locație, montarea sistemului exportat în vechea locație și executarea unei simple copieri, de exemplu folosind rsync).

Selecția tipului de sistem de fișiere, a metodei de export și copierea necesită atenție pentru că trebuie ca aplicațiile să poată accesa aceleași date fără a le corupe. Din fericire, majoritatea aplicațiilor web “se așteaptă” să ruleze în paralel și își implementează singure sisteme de locking.

Pentru că acest pas poate totuși să ducă la desincronizări temporare de date pe durata copierii și montării inițiale a datelor, este de preferat ca operațiunile să fie executate la o oră de trafic minim, eventual chiar cu serverul web oprit temporar, mai ales dacă aplicațiile web accesează volume mari de date și nu sunt programate să trateze delicat eventualele erori.

La încheierea acestui pas sistemul nou va avea local atât bazele de date cât și fișierele, iar sistemul vechi va accesa atât fișierele aplicațiilor cât și bazele de date prin rețea, de pe sistemul nou, ceea ce îl va face mai lent.

Pasul 4.5: Dacă accesul fișierelor prin rețea este totuși prea lent, după încheierea cu succes a pasului 4 se poate configura un reverse proxy pe sistemul vechi, care va trimite toate cererile către sistemul nou. Astfel, procesarea datelor (query-uri, calcule) se va muta pe sistemul nou, iar transferul de date dintre cele două sistem se va rezuma la fișierul HTML rezultat.

Dacă aproape întotdeauna fișierul HTML rezultat este mai mic decât fișierele care trebuie accesate pentru a-l produce, acest pas este o idee bună și ar trebui implementat. Contra-exemplu: situri de pe care se face mult download de fișiere binare mari. În acest caz, cantitatea de date pentru transferul direct al fișierului este întotdeauna mai mică decât varianta codată HTML.

Pasul 5: Urmează monitorizarea cererilor care sosesc către sistemul vechi, și dacă au trecut 12-24 de ore de “liniște”, se poate considera migrarea încheiată și se poate deconecta serverul vechi.

Cazul 3: nu ne permitem nimic!

Este cel mai simplu caz de descris, dar cel mai greu de implementat. Pot să îl rezum la trei cuvinte: high-availability cluster.

Nu voi mai descrie pașii care trebuie urmați, pentru că pot varia extrem de mult în funcție de configurația sistemului și software-ul de clustering care va fi folosit.

Voi menționa doar cele două părți importante ale sistemului care trebuie replicate:

• bazele de date. Într-un HA-Cluster, bazele de date vor fi configurate pentru replicare master-master – adică vor suporta scrieri și citiri arbitrare în oricare din cele două noduri, datele fiind mereu sincronizate automat.
• sistemul de fișiere. La fel ca în cazul bazelor de date, sistemul de fișiere replicat va oferi copii identice ale datelor către ambele noduri ale clusterului și va suporta scrieri și citiri arbitrare în ambele noduri.

Ar mai trebui precizat că transformarea unui sistem care a fost conceput să ruleze individual într-un nod de cluster poate fi extrem de dificilă și costisitoare. Dacă nu ai un website cu zeci de mii de hit-uri pe oră din care câștigi extrem de mulți bani, de cele mai multe ori efortul de implementare nu merită și se preferă soluția pe care am oferit-o pentru Situația 2 de mai sus.

Tu ce metodă ai aplicat când ai migrat servicii web de pe un sistem pe altul? Povestește-ne experiența ta într-un comentariu!

Dacă ai nevoie de ajutor pentru a migra servicii de pe un sistem pe altul, NOVIT te poate ajuta! Contactează-ne!

Image credit: danibelle2906.

Related posts:

1. Migrare servicii: DNS În ultimele trei post-uri din categoria IT m-am referit la...
2. Migrare servicii: email În articolul anterior am vorbit despre migrarea serviciului DNS către...
3. Cum te afectează “broken links” pe website Ți s-a întâmplat să vizitezi un sit (urmărind o legătură...
4. www, www2, www3 sau redundanța serviciilor web Voi continua astăzi seria de articole despre redundanța diferitelor servicii...
5. Recomandare echipamente și servicii Oops, nu am scris conținut pentru pagina asta, deocamdată. Revino...