Activ-activ sau activ-pasiv: care este necesar?

Într-o dimineață de luni, sistemul de comandă răspunde lent și apoi devine inaccesibil. Magazinul online continuă să primească comenzi, dar depozitul nu le poate vedea, serviciul de asistență clienți nu poate oferi un statut precis, iar facturarea se oprește. În astfel de momente, devine o problemă de afaceri dacă arhitectura sistemului este activ-activ sau activ-pasiv pentru a proteja serviciile critice.

Cele două abordări sunt adesea tratate doar ca o decizie de infrastructură. De fapt, ele determină ce se întâmplă cu operațiunile atunci când un server, aplicație, conexiune de rețea sau chiar un întreg site cade. Alegerea corectă nu depinde de care sună mai avansat, ci de care procese de afaceri nu se pot opri, câtă pierdere de date este acceptabilă și cât de capabilă este organizația să opereze în siguranță soluția aleasă.

Ce înseamnă funcționarea activ-activ și activ-pasiv?

Într-o configurație activ-activ, două sau mai multe instanțe de sistem lucrează simultan. De exemplu, două servere de aplicații deservesc în paralel utilizatorii magazinului online, iar un distribuitor de sarcină împarte cererile între ele. Dacă una dintre instanțe cade, cealaltă continuă să funcționeze, de obicei fără a fi observat sau cu o întrerupere scurtă.

Într-o configurație activ-pasiv, sistemul primar lucrează, iar cel secundar este în așteptare. Sistemul de rezervă primește datele sistemului primar continuu sau la intervale de timp stabilite, dar nu deserveste utilizatorii în mod normal. În caz de eroare, preia rolul. Acest lucru se numește failover, adică comutare automată sau manuală.

La prima vedere, activ-activ poate părea soluția evident mai bună: două sisteme funcționale sunt mai bune decât unul funcțional și unul în așteptare. Totuși, acest lucru este adevărat doar dacă aplicația, gestionarea datelor, rețeaua și procesele operaționale pot gestiona funcționarea paralelă. Un mediu activ-activ proiectat greșit nu doar că este mai scump, dar poate provoca și erori mai greu de diagnosticat.

Disponibilitatea nu este egală cu mai multe servere

Multe companii au un al doilea server, backup sau chiar o conexiune de internet de rezervă, dar nu putem vorbi despre o disponibilitate reală ridicată. Motivul este simplu: cauza căderii nu este adesea serverul în sine.

Dacă magazinul online și gestionarea stocurilor depind de aceeași bază de date, dispozitiv de rețea sau furnizor extern, atunci două servere de aplicații nu vor rezolva cauza comună a erorii. Același lucru este valabil atunci când sistemul funcționează, dar fișierul Excel unic necesar pentru procesarea comenzilor primite este disponibil doar pe computerul unui angajat.

De aceea, disponibilitatea trebuie interpretată ca un serviciu de afaceri. Nu este întrebarea dacă o mașină virtuală rulează, ci dacă depozitul poate livra bunurile, dacă avizul de expediere este pregătit, dacă comanda ajunge la facturare și dacă managementul primește informații autentice despre operațiuni.

Începeți cu punctele critice ale procesului

Este util să clarificați mai întâi cât timp pot suporta procesele o oprire. O întrerupere de câteva ore a unui depozit intern de documente poate fi neplăcută, dar gestionabilă. Un sistem de control al producției, un proces de plată online sau o conexiune de procesare a comenzilor poate cauza pierderi directe de venituri și încredere a clienților după doar zece minute.

La fel de important este și pragul de pierdere a datelor. Dacă un sistem poate fi restaurat cu date de acum o oră, aceasta înseamnă o altă soluție tehnică și costuri decât atunci când se permite doar o pierdere de date de câteva secunde. Aceste niveluri sunt de obicei descrise prin obiectivele RTO și RPO. RTO indică cât timp trebuie să dureze restaurarea serviciului. RPO indică cât de multe date pot fi pierdute comparativ cu starea anterioară erorii.

În spatele numerelor trebuie să existe întotdeauna o consecință de afaceri concretă. Scopul nu trebuie să fie ca „disponibilitatea ridicată” să apară în plan, ci, de exemplu, ca procesarea comenzilor să nu se oprească mai mult de 15 minute și nicio comandă plătită să nu fie pierdută.

Când este justificat modelul activ-pasiv?

Arhitectura activ-pasiv este o alegere rațională și eficientă pentru multe companii în creștere. În special atunci când gestionarea stării aplicației este complexă, se bazează pe un singur scriitor de baze de date sau software-ul nu suportă în mod implicit serviciul paralel.

Imaginați-vă o companie de producție unde datele de producție sunt gestionate de un sistem central. La sistem sunt conectate mai multe stații de lucru, dar consistența bazei de date este primordială. Aici, o bază de date primară-rezervă bine construită, cu proceduri de comutare documentate, teste regulate și monitorizare adecvată poate fi mai de încredere decât o configurație activ-activ forțată.

Avantajul modelului activ-pasiv este complexitatea operațională mai mică. Există mai puține conflicte de date din cauza scrierii paralele, depanarea poate fi mai simplă, iar echipa de operare are o idee mai clară despre care sistem este primar. Dezavantajul este că comutarea poate dura timp, mai ales dacă necesită o decizie manuală, modificare DNS, pornire de servicii sau verificare de date.

„Pasiv” nu trebuie să însemne că a fost uitat. Mediul de rezervă trebuie actualizat, monitorizat și testat. Un plan de urgență care există doar pe hârtie eșuează de obicei atunci când organizația are cea mai mare nevoie de el. plan de urgență de obicei eșuează atunci când organizația are cea mai mare nevoie de el.

Când aduce valoare reală modelul activ-activ?

Configurația activ-activ este justificată acolo unde disponibilitatea continuă a serviciului este direct legată de venituri, producție sau obligații contractuale. Acesta poate fi un magazin online cu trafic mare, un portal pentru clienți, un sistem logistic care funcționează continuu sau o aplicație a cărei încărcare crește semnificativ periodic.

Modelul nu oferă doar toleranță la erori, ci și capacitate. Dacă cele două servere de aplicații active împart traficul, resursele pot fi utilizate chiar și în regim normal. În cazul în care o instanță cade, capacitatea rămasă trebuie totuși să suporte sarcina critică. Acest lucru lipsește din multe planuri: există două servere, dar ambele funcționează deja la o utilizare de 70-80% într-o zi normală. Prin urmare, în caz de cădere, sistemul rămâne tehnic accesibil, dar din punct de vedere al afacerii devine inutilizabil de lent.

Într-un mediu activ-activ, cea mai dificilă problemă este de obicei datele. Dacă două locații sau două instanțe de baze de date primesc modificări simultan, trebuie reglementat care date sunt valabile în caz de conflict. Ultima piesă dintr-un stoc nu poate fi vândută de două canale independent unul de celălalt. Sistemul are nevoie de reguli de afaceri uniforme, gestionare a tranzacțiilor și sincronizare controlată.

De aceea, nu toate aplicațiile pot sau ar trebui să fie făcute activ-activ. Adesea, soluția corectă este ca serviciul web să fie activ-activ, în timp ce baza de date sau un proces de fundal critic rămâne activ-pasiv. Disponibilitatea ridicată este adesea o combinație de straturi diferite, nu o singură etichetă.

Comutarea funcționează doar dacă este practicată regulat

Majoritatea riscurilor nu apar în desenul arhitecturii, ci în operare. Cine este autorizat să inițieze comutarea? Cum se vede că a avut loc o eroare reală, nu doar o încetinire temporară? Cum se verifică dacă sistemul secundar este cu adevărat actualizat? Cine informează utilizatorii dacă serviciul este parțial disponibil?

O atenție deosebită necesită situația de split-brain. Aceasta apare atunci când două instanțe de sistem se consideră reciproc defecte și ambele încep să funcționeze ca primare. Dacă ambele pot scrie în aceleași date de afaceri, inconsistența datelor poate deveni rapid o problemă serioasă. Fără mecanisme de cvorum adecvate, design de rețea și strategie de baze de date, redundanța însăși poate deveni o sursă de eroare.

Trebuie examinată și întreținerea planificată. Un model bun de disponibilitate nu este valoros doar în cazul unei opriri neașteptate. Este valoros și atunci când este necesară o actualizare de securitate, o înlocuire de hardware sau o schimbare de versiune. Dacă fiecare modificare necesită o oprire nocturnă și intervenție manuală, riscul operațional pe termen lung al sistemului rămâne ridicat.

Decizia corectă începe cu procesul

O companie nu are nevoie de o soluție activ-activ doar pentru că este folosită de marile companii tehnologice. Și nu trebuie să aleagă o configurație activ-pasiv doar pentru că pare mai ieftină. Decizia trebuie să fie condusă de modul în care informația curge de la comandă la livrare, de la instrucțiunile de producție la produsul finit sau de la cerința clientului la factură.

Înainte de proiectarea sistemului, trebuie identificate dependențele: din ce aplicație provin datele, unde are loc introducerea manuală a datelor, care sistem este singura sursă autentică și unde se blochează munca în caz de cădere. În abordarea CGAT, arhitectura tehnologică este un răspuns la aceste întrebări operaționale, nu o listă de produse independentă.

Cel mai bun design nu este neapărat cel mai complex. Un sistem bun este acela al cărui comportament în caz de cădere este cunoscut, a cărui comutare este controlată, ale cărui date sunt protejate și care poate fi operat în siguranță pe termen lung de echipa proprie sau de un partener desemnat. Dacă înainte de următoarea oprire planificată sau eroare neașteptată acest lucru nu poate fi afirmat clar, atunci nu este nevoie de încă un server, ci de un plan operațional mai clar.