Reziliența aplicațiilor: mențineți aplicațiile Windows disponibile

Introducere

Aplicațiile Windows depind adesea de mult mai mult decât serverul care le găzduiește. Bazele de date, serviciile de identitate, stocarea, gateway-urile, rețelele și punctele finale ale utilizatorilor pot afecta dacă o aplicație rămâne utilizabilă în timpul unei întreruperi. Acest articol explică modul în care echipele IT pot evalua aceste dependențe, pot proiecta reziliență în jurul aplicațiilor Windows existente, pot monitoriza straturile corecte și pot testa dacă planurile de recuperare păstrează de fapt funcțiile de afaceri pe care utilizatorii se bazează.

Ce este reziliența aplicațiilor?

Reziliența aplicației este capacitatea unei aplicații și a infrastructurii din jurul ei de a continua să ofere funcții esențiale în timpul unei întreruperi și de a se recupera predictibil după o defecțiune.

Perturbarea poate fi mică sau mare, iar cauzele pot varia de la defecțiuni hardware sau ale sistemului de operare, blocări ale aplicațiilor, actualizări eșuate, întreruperi ale bazei de date, întreruperi de rețea, eșecuri de autentificare, epuizarea resurselor, dependențe indisponibile sau incidente de securitate.

O arhitectură rezistentă recunoaște că eșecurile sunt inevitabile și, în loc să își propună să prevină fiecare incident, organizațiile IT caută să limiteze impactul fiecăruia și să stabilească proceduri de recuperare controlate pentru a menține sau restabili serviciul.

Reziliența aplicației este mai mult decât timpul de funcționare al serverului

O greșeală comună este să folosești disponibilitatea unui server ca un substitut pentru disponibilitatea aplicației, care rulează pe server.

Pentru ca o aplicație de afaceri să fie cu adevărat disponibilă, un număr de componente trebuie să fie disponibile în același timp:

Infrastructură → Sistem de operare → Aplicație → Dependențe → Cale de acces → Sesiune de utilizator → Proces de afaceri

O problemă cu orice element din această lanț poate duce la indisponibilitatea efectivă a aplicației.

De exemplu, un server de aplicații poate fi sănătos în timp ce baza sa de date este inaccesibilă. O aplicație publicată poate funcționa corect, dar o defecțiune a portalului face imposibil ca angajații care lucrează de la distanță să o acceseze. Utilizatorii pot chiar lansa cu succes aplicația, dar pot fi împiedicați să finalizeze o tranzacție din cauza unei licențe, a unui fișier sau a unui serviciu de backend care nu este disponibil.

Reziliența aplicației, prin urmare, ar trebui să fie măsurată în funcție de capacitatea utilizatorului de a efectua sarcina de afaceri necesară, mai degrabă decât de faptul că un server este capabil să răspundă la un control de disponibilitate sau sănătate.

De ce este reziliența aplicațiilor diferită pentru aplicațiile Windows?

Practicile moderne de reziliență sunt din ce în ce mai concentrate pe aplicații native în cloud, containere, microservicii și orchestrare automată. Deși acestea sunt abordări valoroase, ele nu sunt întotdeauna aplicabile fiecărei organizații.

Multe organizații au aplicații de afaceri pe Windows vechi, care au fost dezvoltate înainte ca arhitecturile native în cloud să devină comune. Software-ul ERP, aplicațiile de contabilitate, aplicațiile de producție, aplicațiile de sănătate, aplicațiile de inginerie și aplicațiile dezvoltate intern pot fi toate critice pentru operațiunile unei organizații.

Reproiectarea acestor aplicații ca microservicii poate fi extrem de costisitoare, tehnic provocatoare sau chiar complet imposibilă dacă organizația nu controlează codul sursă.

În astfel de cazuri, poate exista o valoare semnificativă în a face operațiunile din jurul aplicației mai rezistente, mai degrabă decât să încercăm să facem aplicația însăși mai rezistentă. Publicarea aplicațiilor poate face parte din această abordare prin menținerea aplicațiilor Windows existente pe o infrastructură centralizată, în timp ce se schimbă modul în care utilizatorii le accesează. Aceasta poate include modificări ale infrastructurii care găzduiește aplicația, cum ar fi eliminarea constrângerilor infrastructurii, crearea de gazde de aplicație redundante, activarea metodelor alternative de acces și implementarea unor proceduri de recuperare mai responsabile pentru gazda aplicației.

În ce caz disponibilitatea unei aplicații Windows ar putea eșua?

Construirea rezilienței aplicațiilor începe cu descoperirea componentelor necesare pentru a livra cu succes o aplicație de la gazdele sale către utilizatori. Acest proces evidențiază punctele potențiale de eșec care pot duce la căderea unei aplicații întregi.

Gazde de aplicații

O aplicație care rulează pe un singur server Windows are un punct clar unic de eșec.

Problemele hardware, actualizările Windows, corupția sistemului de operare, epuizarea resurselor sau eșecul aplicației pot perturba fiecare utilizator care depinde de acea mașină. Dacă cerințele de disponibilitate o impun, pot fi implementate mai multe gazde de aplicații pentru a reduce dependența de o singură mașină și a oferi capacitate atunci când un server devine indisponibil.

Baze de date, stocare și alte dependențe

Multe aplicații Windows depind de servicii externe gazdei aplicației. Aceste servicii pot include:

• baze de date SQL
• partajări de fișiere
• servere de licențiere
• Active Directory
• Sistemul de nume de domeniu (DNS)
• certificate
• APIs
• middleware
• stocare în rețea
• infrastructură de imprimare

Introducerea unui al doilea server de aplicații oferă o reziliență minimă dacă acestea împărtășesc o bază de date comună sau o dependență de stocare care nu este disponibilă. Devine evident că mappingul dependențelor trebuie să se extindă dincolo de infrastructura vizibilă a aplicației.

Autentificare și Identitate

Utilizatorii nu pot accesa o aplicație sănătoasă dacă infrastructura de autentificare necesară nu este disponibilă.

Echipele IT trebuie să identifice serviciile de identitate de care depind aplicațiile lor critice și să se asigure că au planuri de rezervă în vigoare pentru atunci când aceste resurse sunt inaccesibile. Active Directory, platformele de identitate cloud, serviciile de autentificare multifactorială (MFA) și gateway-urile de autentificare pot fi toate utilizate pentru a oferi o lanț de disponibilitate pentru o aplicație.

Rețele și căi de acces la distanță

Pentru aplicațiile Windows centralizate, conectivitatea între utilizatori și mediul aplicației reprezintă un alt domeniu posibil de eșec.

Să ne imaginăm întreaga lanț:

Dispozitiv utilizator → Internet sau LAN → gateway → gazdă aplicație → servicii backend

O defecțiune în această rețea poate împiedica utilizatorii să își îndeplinească sarcinile, chiar dacă aplicația funcționează corect. Acest lucru este deosebit de relevant pentru organizațiile distribuite, unde aplicația poate fi activă în centrul de date, dar inaccesibilă utilizatorilor dintr-o altă locație.

Endpoint-uri

Reziliența aplicației nu necesită neapărat ca stația de lucru normală a utilizatorului să fie disponibilă.

Oferind utilizatorilor autorizați mijloacele de a accesa aplicații găzduite centralizat de pe un dispozitiv alternativ sau printr-un browser poate asigura accesul, dacă un laptop devine indisponibil, un birou devine inaccesibil sau angajații trebuie să lucreze dintr-o altă locație.

Arhitectura livrării aplicațiilor poate fi un component al unei strategii mai ample de continuitate a afacerii.

Care este procesul de construire a rezilienței aplicațiilor pentru aplicațiile Windows?

Nicio tehnologie singulară nu face aplicația rezistentă. Echipele IT trebuie să reducă numărul de defecțiuni care pot afecta o funcție completă și să se pregătească pentru mecanisme de recuperare controlată pentru cele care rămân.

1. Identificați aplicațiile critice și procesele de afaceri

Nu toate aplicațiile necesită același grad de protecție. Începeți prin a determina care aplicații susțin operațiunile principale, pe care utilizatori se bazează și toleranța lor la timp de nefuncționare.

Două obiective de recuperare traduc cerințele de afaceri în specificații tehnice. Ghidul de planificare a contingenței NIST definează Obiectivul Timpului de Recuperare (RTO) și Obiectivul Punctului de Recuperare (RPO) ca parametri cheie pentru determinarea cerințelor de recuperare:

• Obiectivul Timpului de Recuperare (RTO): o durată de oprire acceptabilă înainte ca serviciul să fie restabilit.
• Obiectivul punctului de recuperare (RPO): un interval de pierdere acceptabilă a datelor, măsurat în timp.

O aplicație utilizată intensiv pentru procesarea comenzilor poate avea un RTO de câteva minute, în timp ce o aplicație de raportare financiară care rulează o dată pe săptămână își poate permite zile de nefuncționare.

RTO și RPO definesc tipul de protecție necesar pentru o aplicație: comutare instantanee, restabilirea rapidă a serviciilor sau pur și simplu o procedură de recuperare documentată.

2. Cartografiați întreaga lanț de dependență a aplicației

Documentați tot ce trebuie să fie acolo pentru ca aplicația să își facă treaba.

Nu te opri la executabil sau serverul Windows. Nu uita de baze de date, stocare, autentificare, DNS, rețele, certificate, sisteme de licențiere, gateway-uri și servicii externe.

Pentru fiecare, întrebați:

Ce se întâmplă cu aplicația dacă aceasta dispare?

Această exercițiu va evidenția punctele unice de eșec ascunse și va stabili secvența de recuperare. Restaurarea mai întâi a unui gazdă de aplicație nu ajută mult dacă baza sa de date, serviciul de identitate sau stocarea nu sunt încă disponibile.

3. Eliminarea punctelor critice unice de eșec

Odată ce arborele de dependență este stabilit, determinați care componente trebuie să fie redundante, pe baza importanței pentru afaceri și a obiectivelor de recuperare.

În cazul livrării aplicațiilor Windows, acest lucru ar putea implica desfășurarea mai multor servere de aplicații în loc să se bazeze pe capacitățile unui singur gazdă. Cu un strat de echilibrare a încărcării, sesiunile pot fi distribuite între instanțele aplicațiilor în timpul operațiunilor normale. În cazul unei defecțiuni a gazdei, conexiunile de intrare pot fi direcționate către instanțele sănătoase ale serverelor de aplicații.

Planificarea redundanței ar trebui să fie informată de analiza dependențelor, totuși. Mai multe servere de aplicații care accesează o singură bază de date critică, un gateway de rețea sau un strat de stocare prezintă în continuare un singur punct de eșec.

Designul de disponibilitate ridicată trebuie, prin urmare, să considere serviciul de aplicație ca o entitate integrată. Pentru medii Windows Server care necesită redundanță la nivel de infrastructură, Documentația Microsoft pentru clustering de failover oferă îndrumări suplimentare cu privire la topologiile de înaltă disponibilitate și recuperare în caz de dezastru.

4. Separarea aplicațiilor de punctele finale individuale

Instalarea unei aplicații critice direct pe stația de lucru a fiecărui angajat poate crea un alt tip de problemă de reziliență. Dacă utilizatorii își pierd accesul la computerul lor obișnuit, este posibil să piardă și accesul la aplicațiile de care au nevoie pentru a continua să lucreze.

Centralizarea aplicațiilor pe gazde Windows gestionate și prezentarea interfeței aplicației utilizatorilor elimină acest risc. Datele și starea aplicației sunt stocate pe gazda Windows gestionată și accesate de punctele finale autorizate.

Prin aceasta, facem aplicația disponibilă utilizatorilor chiar dacă aceștia își schimbă dispozitivele sau locațiile. Deși centralizarea aplicațiilor nu elimină problemele de infrastructură, ajută la mutarea acesteia într-un mediu în care poate fi controlată de IT.

5. Oferiți mai mult de o metodă de acces practică

Reziliența poate fi, de asemenea, realizată prin evitarea dependenței inutile de un singur tip de punct final sau metodă de conexiune.

În funcție de arhitectura livrării aplicațiilor, utilizatorii pot folosi diferite acces la distanță metode, inclusiv un client compatibil RDP, lansator de aplicații dedicat, portal web sau sesiune de browser HTML5.

Metodele alternative de conectare nu ar trebui confundate cu redundanța infrastructurii. Dacă toate se bazează pe același server defect, aplicația rămâne inaccesibilă.

Ei oferă reziliență la acces atunci când o întrerupere afectează dispozitivul normal al unui utilizator, clientul instalat sau locația, mai degrabă decât serviciul aplicației în sine.

6. Monitorizați înainte ca degradarea să devină o întrerupere

Reziliența aplicațiilor nu se referă doar la recuperare, ci o detectare suficient de timpurie poate evita degradarea într-o întrerupere.

Indicatorii utili în medii de aplicații Windows sunt utilizarea CPU, presiunea memoriei, capacitatea discului și I/O, utilizarea rețelei, sesiuni active, procesul aplicației, timpul de răspuns, conexiunea eșuată și disponibilitatea serviciilor dependente.

Monitorizarea tendințelor este crucial, deoarece un server care se apropie repetat de limitele sale poate fi în continuare online în timp ce experiența utilizatorului se deteriorează treptat.

Alertele de prag permit administratorilor să investigheze precursorii unui incident înainte ca utilizatorii să piardă accesul.

7. Planificare pentru vârfuri de capacitate și failover

O aplicație care supraviețuiește defectelor la nivel hardware, dar este complet incapabilă să funcționeze sub cerințe crescute, nu este cu adevărat rezistentă la eșecuri de niciun fel.

Planificarea capacității trebuie să ia în considerare nu doar modelele de utilizare zilnică, ci și să țină cont de vârfuri datorate cerințelor sezoniere, schimbărilor de ture, creșterii sau cerințelor de găzduire pentru alte aplicații.

În special în medii de găzduire cu mai multe servere, pierderea unui singur server trebuie compensată prin asigurarea că celelalte noduri de găzduire au capacitate suplimentară pentru a acomoda orice procese care, în mod normal, ar fi fost executate pe nodul defect.

În caz contrar, procedurile de fail-over pot transforma pur și simplu un incident izolat într-o problemă largă de performanță a sistemului.

8. Protejați datele și configurația

O server Windows de înlocuire este de puțin folos dacă IT-ul nu poate restaura componentele necesare pentru a face aplicația să funcționeze.

Acest lucru ar putea însemna că procedurile de backup trebuie să includă datele aplicației, bazele de date, fișierele de configurare, certificatele, setările aplicației, profilurile utilizatorilor, configurația infrastructurii, scripturile și informațiile de licențiere.

Strategia va varia în funcție de Obiectivul de Timp de Recuperare (RTO) și Obiectivul de Punct de Recuperare (RPO) al aplicației.

În primul rând, asigurați-vă că o copie de rezervă reușită nu este egală cu o recuperare reușită. Echipele IT ar trebui să testeze că este posibil să restaureze întregul serviciu de aplicație din datele și configurația protejate.

9. Reduceți raza de explozie a modificărilor

Nu este întotdeauna vorba despre un dezastru neprevăzut care cauzează întreruperi. Acestea pot fi cauzate și de îmbunătățiri implementate. Astfel, actualizările Windows, upgrade-urile aplicațiilor și driverelor, modificările politicii de securitate și ale configurației pot avea, de asemenea, un impact negativ asupra disponibilității aplicației. Se recomandă evitarea efectuării unor modificări similare la toate gazdele de producție în același timp, dacă este posibil.

Într-o configurație multi-server, este posibil să efectuezi modificările de îmbunătățire în etape, permițând astfel administratorului să se asigure că totul funcționează corect. Capacitatea de a reveni la modificările efectuate este, de asemenea, esențială.

Astfel, atunci când se proiectează proceduri de contingență, opțiunile de revenire ar trebui, de asemenea, să fie luate în considerare. Procesul ar trebui să fie documentat corespunzător, iar personalul ar trebui să știe ce să facă dacă o modificare eșuează, în loc să lase pur și simplu la latitudinea lor.

10. Design pentru degradare grațioasă

Reziliența nu înseamnă să menții 100% din funcțiile normale în funcțiune în permanență.

În unele cazuri, menținerea operațiunilor pentru utilizatorii sau aplicațiile cheie poate fi mai importantă decât menținerea tuturor serviciilor disponibile pentru toți utilizatorii. Prioritățile pot fi stabilite înainte ca un incident să aibă loc de către echipele IT.

Dacă există capacitate disponibilă care poate fi utilizată, ar putea avea sens să o alocăm mai întâi producției, serviciului clienți, finanțelor sau altor funcții.

Aceasta este o degradare grațioasă: păstrarea capacității de a rula funcțiile care generează cea mai mare valoare pentru afacere, în loc să lăsăm eșecul elementelor mai puțin critice să facă întregul sistem să se prăbușească.

Cum ar trebui echipele IT să monitorizeze reziliența aplicațiilor?

Monitorizarea serverelor individuale poate fi utilă, dar monitorizarea rezilienței ar trebui să reflecte serviciul total al aplicației așa cum este perceput de utilizatori.

Un model realist cuprinde mai multe straturi:

Strat	Ce să monitorizăm	Exemplu de eșec
Gazdă	CPU, RAM, disc, disponibilitate OS	Serverul este supraîncărcat sau offline
Aplicație	Starea procesului și a serviciului	Crashes de aplicație
Dependență	Bază de date, DNS, identitate, stocare	Aplicația se lansează, dar nu poate funcționa.
Acces	Gateway, portal, cale de rețea	Utilizatorii nu se pot conecta
Sesiune	Utilizatori activi, eșecuri, latență	Aplicația este online, dar inutilizabilă
Funcție de afaceri	Finalizarea cu succes a fluxului de lucru	Utilizatorul nu poate finaliza sarcina necesară.

Stratul funcțional de afaceri este unul dintre cele mai simple de trecut cu vederea.

Panourile de control ale infrastructurii pot arăta toate serverele, serviciile și căile de rețea ca fiind sănătoase, în timp ce fluxul de lucru al unui utilizator real este compromis. Este important, așadar, ca aplicațiile critice să își monitorizeze sănătatea din perspectiva operațiunii pe care sunt concepute să o susțină.

Cum ar trebui testată reziliența aplicațiilor?

O arhitectură de reziliență care nu a experimentat niciodată o eșec controlat conține presupuneri netestate.

Utilizați testarea pentru a evalua răspunsul sistemului atunci când componentele cheie devin indisponibile. Testele ar trebui să includă scoaterea offline a unui gazdă de aplicație, oprirea unui serviciu de aplicație, simularea pierderii unei rute de rețea, verificarea comportamentului gateway-ului sau al echilibrării sarcinii, restaurarea din backup și accesarea aplicației dintr-un punct final alternativ.

Procesele de testare ar trebui să se extindă dincolo de aspectele tehnice ale recuperării. Echipele IT ar trebui să revizuiască dacă alertele sunt trimise către personalul administrativ corect, pașii de recuperare sunt efectuați în ordinea corectă și utilizatorii sunt capabili să efectueze o sarcină de afaceri reală după ce serviciile au fost restabilite.

Procedurile operaționale sunt esențiale pentru un sistem rezistent. Proceduri de escaladare a alertelor: cine primește alerta? Cine are autoritatea de a iniția comutarea? Unde sunt stocate documentația de recuperare și acreditivele? Ce dependență trebuie să fie activată prima dată?

Redundanța tehnică oferă puțin beneficiu dacă procesele de recuperare a accesului nu au fost testate.

Ce poate fi lista de verificare pentru reziliența aplicației?

Înainte de a se angaja într-o aplicație Windows critică și rezistentă, echipele IT ar trebui să fie capabile să răspundă la următoarele întrebări:

• Care procese de afaceri se bazează pe aplicație?
• Care sunt RTO și RPO-urile sale?
• Ce servere, baze de date și servicii externe necesită?
• Unde sunt punctele sale critice de eșec?
• Poate un alt gazdă de aplicație accepta utilizatori dacă un gazdă eșuează?
• Pot utilizatorii să se conecteze dacă punctul lor final sau locația normală nu este disponibilă?
• Există suficientă capacitate suplimentară pentru funcționare degradată?
• Sunt problemele de infrastructură, dependență și sesiune monitorizate activ?
• Sunt administratorii alertați înainte ca pragurile importante să devină întreruperi?
• Sunt protejate datele și configurația aplicației?
• A fost testată efectiv restaurarea?
• Pot fi anulate modificările problematice?
• Este documentată secvența de recuperare?
• Utilizatorii pot finaliza procesul de afaceri necesar după recuperare?

Nu toate răspunsurile necesită o infrastructură scumpă de înaltă disponibilitate. Nivelul corect de protecție depinde de cost și de impactul operațional al timpului de nefuncționare.

Ceea ce contează este că deciziile privind disponibilitatea, redundanța și recuperarea sunt luate deliberat, mai degrabă decât presupuse.

Cum poate TSplus ajuta la menținerea aplicațiilor Windows disponibile?

Pentru organizațiile care se bazează pe aplicații Windows existente, putem ajuta la îmbunătățirea disponibilității prin centralizarea aplicațiilor pe servere Windows gestionate și livrarea acestora utilizatorilor prin clienți compatibili RDP, acces de tip RemoteApp sau un portal web HTML5. Acest lucru reduce dependența de punctele finale individuale ale utilizatorilor și oferă echipelor IT mai multă flexibilitate atunci când utilizatorii trebuie să se conecteze de pe un alt dispozitiv sau dintr-o altă locație.

TSplus Remote Access poate, de asemenea, să sprijine desfășurările multi-server cu echilibrarea încărcării și accesul bazat pe gateway. Atunci când este combinată cu baze de date reziliente, stocare, servicii de identitate și rețelistică, această arhitectură poate reduce dependența de un singur gazdă de aplicație și ajuta la menținerea accesului la aplicațiile critice Windows în timpul întreruperilor de infrastructură.

Concluzie

Reziliența aplicației depinde de înțelegerea întregului parcurs între infrastructură și utilizarea în afaceri. Redundanța, monitorizarea, backup-ul, planificarea capacității și procedurile de recuperare sunt cele mai eficiente atunci când sunt concepute în jurul dependențelor aplicației și obiectivelor de recuperare clar definite.

Pentru aplicațiile Windows existente, reziliența provine adesea din întărirea mediului din jurul software-ului, mai degrabă decât din reconstruirea aplicației în sine. Testul cheie rămâne simplu: atunci când apare o întrerupere, pot utilizatorii să continue să lucreze sau poate IT-ul să restabilească funcția de afaceri necesară în cadrul feronierului de recuperare convenit?