Aplikácia odolnosti: Udržujte aplikácie Windows dostupné

Úvod

Windows aplikácie často závisia na oveľa viac než len na serveri, ktorý ich hostí. Databázy, identity služby, úložiská, brány, siete a používateľské koncové body môžu všetky ovplyvniť, či aplikácia zostane použiteľná počas narušenia. Tento článok vysvetľuje, ako môžu IT tímy posúdiť tieto závislosti, navrhnúť odolnosť okolo existujúcich Windows aplikácií, monitorovať správne vrstvy a testovať, či plány obnovy skutočne zachovávajú obchodné funkcie, na ktorých sa používatelia spoliehajú.

Čo je odolnosť aplikácie?

Odolnosť aplikácie je schopnosť aplikácie a infraštruktúry okolo nej pokračovať v poskytovaní životne dôležitých funkcií počas narušenia a predvídateľne sa zotaviť po zlyhaní.

Prerušenie môže byť malé alebo veľké a príčiny sa môžu líšiť od zlyhania hardvéru alebo operačného systému, pádu aplikácií, neúspešných aktualizácií, výpadkov databáz, prerušenia siete, zlyhania autentifikácie, vyčerpania zdrojov, nedostupných závislostí alebo bezpečnostných incidentov.

Odolná architektúra uznáva, že zlyhania sú nevyhnutné, a namiesto toho, aby sa snažila zabrániť každému incidentu, IT organizácie sa snažia obmedziť dopad každého z nich a zaviesť kontrolované postupy obnovy na udržanie alebo obnovenie služby.

Odolnosť aplikácie je viac než prevádzková doba servera

Bežnou chybou je používať dostupnosť servera ako proxy pre dostupnosť aplikácie, ktorá beží na serveri.

Aby bola obchodná aplikácia skutočne dostupná, je potrebné, aby bolo súčasne k dispozícii niekoľko komponentov:

Infrastruktúra → Operačný systém → Aplikácia → Závislosti → Prístupová cesta → Užívateľská relácia → Obchodný proces

Problém s akýmkoľvek prvkom v tomto reťazci môže viesť k tomu, že aplikácia bude efektívne nedostupná.

Napríklad, aplikačný server môže byť zdravý, zatiaľ čo jeho databáza je nedostupná. Publikovaná aplikácia môže fungovať správne, ale zlyhanie brány znemožňuje vzdialeným zamestnancom k nej pristupovať. Používatelia môžu dokonca úspešne spustiť aplikáciu, ale môžu byť zablokovaní pri dokončovaní transakcie, pretože licencia, súbor alebo backendová služba nie sú k dispozícii.

Odolnosť aplikácie by sa preto mala merať na základe schopnosti používateľa vykonať potrebnú obchodnú úlohu, skôr než na tom, či server dokáže reagovať na kontrolu dostupnosti alebo zdravia.

Prečo je odolnosť aplikácií iná pre aplikácie Windows?

Moderné praktiky odolnosti sú čoraz viac zamerané na aplikácie natívne pre cloud, kontajnery, mikroservisy a automatizovanú orchestráciu. Hoci sú tieto prístupy cenné, nie sú vždy použiteľné pre každú organizáciu.

Mnohé organizácie majú zastarané aplikácie Windows pre podnikanie, ktoré boli vyvinuté predtým, ako sa stali bežnými architektúry založené na cloude. ERP softvér, účtovné aplikácie, výrobné aplikácie, aplikácie pre zdravotnú starostlivosť, inžinierske aplikácie a interné aplikácie môžu byť všetky kritické pre operácie organizácie.

Prearchitektúra týchto aplikácií ako mikroservisov môže byť mimoriadne nákladná, technicky náročná alebo dokonca úplne nefunkčná, ak organizácia nekontroluje zdrojový kód.

V takýchto prípadoch môže mať významnú hodnotu urobiť operácie okolo aplikácie odolnejšími, namiesto toho, aby sme sa snažili urobiť samotnú aplikáciu odolnejšou. Publikovanie aplikácií môže byť súčasťou tohto prístupu tým, že udrží existujúce aplikácie Windows na centralizovanej infraštruktúre, pričom sa zmení spôsob, akým k nim používatelia pristupujú. To môže zahŕňať zmeny v infraštruktúre, ktorá hostí aplikáciu, ako je odstránenie obmedzení infraštruktúry, vytváranie redundantných hostiteľov aplikácií, umožnenie alternatívnych prístupových metód a implementácia flexibilnejších postupov obnovy pre hostiteľa aplikácie.

V ktorých prípadoch by mohla zlyhať dostupnosť aplikácie Windows?

Budovanie odolnosti aplikácie začína objavovaním komponentov, ktoré sú potrebné na úspešné doručenie aplikácie z jej hostiteľov k používateľom. Tento proces zdôrazňuje potenciálne miesta zlyhania, ktoré môžu zničiť celú aplikáciu.

Aplikačné hostiteľské systémy

Aplikácia bežiaca na jednom serveri Windows má jasný jediný bod zlyhania.

Problémy s hardvérom, aktualizácie systému Windows, poškodenie operačného systému, vyčerpanie zdrojov alebo zlyhanie aplikácie môžu narušiť každého používateľa závislého od toho zariadenia. Ak sú požiadavky na dostupnosť potrebné, môžu sa zaviesť viaceré hostiteľské aplikácie, aby sa znížila závislosť od jedného zariadenia a poskytla kapacita, keď server nie je k dispozícii.

Databázy, úložisko a iné závislosti

Mnohé aplikácie Windows sú závislé od služieb externých k hostiteľovi aplikácie. Tieto služby môžu zahŕňať:

• SQL databázy
• súbory zdieľania
• licenčné servery
• Active Directory
• Systém doménových mien (DNS)
• certifikáty
• APIs
• middleware
• sieťové úložisko
• tlačová infraštruktúra

Zavedenie druhého aplikačného servera poskytuje minimálnu odolnosť, ak zdieľajú spoločnú databázu alebo závislosť od úložiska, ktorá nie je dostupná. Stáva sa zrejmým, že mapovanie závislostí musí presahovať viditeľnú aplikačnú infraštruktúru.

Autentifikácia a identita

Používatelia nemôžu pristupovať k zdravej aplikácii, ak nie je k dispozícii potrebná autentifikačná infraštruktúra.

IT tímy musia identifikovať identity služby, na ktorých závisia ich kritické aplikácie, a zabezpečiť, aby mali plány na zálohovanie pre prípad, že tieto zdroje budú nedostupné. Active Directory, cloudové identity platformy, služby viacfaktorovej autentifikácie (MFA) a autentifikačné brány sa môžu všetky spoliehať na to, že poskytnú reťazec dostupnosti pre aplikáciu.

Sieť a cesty vzdialeného prístupu

Pre centralizované aplikácie Windows predstavuje konektivita medzi používateľmi a aplikačným prostredím ďalšiu možnú doménu zlyhania.

Predstavme si kompletný reťazec:

Používateľské zariadenie → Internet alebo LAN → brána → hostiteľ aplikácie → backendové služby

Rozpad kdekoľvek v tomto reťazci môže zabrániť používateľom vykonávať svoju prácu, aj keď aplikácia funguje správne. Obzvlášť relevantné pre distribuované organizácie, kde môže byť aplikácia spustená v dátovom centre, ale pre používateľov na inom mieste nedostupná.

Koncové body

Odolnosť aplikácie nemusí nevyhnutne vyžadovať, aby bola k dispozícii bežná pracovná stanica používateľa.

Poskytovanie oprávneným používateľom prostriedkov na prístup k centrálne hosteným aplikáciám z alternatívneho zariadenia alebo prostredníctvom prehliadača môže zabezpečiť prístup, ak sa prenosný počítač stane nedostupným, kancelária sa stane neprístupnou alebo zamestnanci musia pracovať z inej lokality.

Architektúra dodávky aplikácií môže byť súčasťou širšej stratégie kontinuity podnikania.

Aký je proces budovania odolnosti aplikácií pre aplikácie Windows?

Žiadna jednotlivá technológia nerobí aplikáciu odolnou. IT tímy musia namiesto toho znížiť počet zlyhaní, ktoré môžu úplne znefunkčniť funkciu, a pripraviť sa na kontrolované mechanizmy obnovy pre tie, ktoré zostanú.

1. Identifikujte kritické aplikácie a obchodné procesy

Nie všetky aplikácie vyžadujú rovnakú úroveň ochrany. Začnite určením, ktoré aplikácie podporujú primárne operácie, na ktorých používateľoch závisia a akú toleranciu voči výpadkom majú.

Dva ciele obnovy prekladajú obchodné požiadavky do technických špecifikácií. NIST-ove usmernenia pre plánovanie pohotovosti definuje cieľ obnovy času (RTO) a cieľ obnovy bodu (RPO) ako kľúčové parametre na určenie požiadaviek na obnovu:

• Cieľ obnovy času (RTO): trvanie prijateľného výpadku pred obnovením služby.
• Obdobie obnovy (RPO): interval prijateľnej straty dát, meraný v čase.

Aplikácia, ktorá sa intenzívne používa na spracovanie objednávok, môže mať RTO v minútach, zatiaľ čo aplikácia na finančné reportovanie, ktorá sa spúšťa raz za týždeň, si môže dovoliť dni výpadku.

RTO a RPO definujú typ ochrany potrebnej pre aplikáciu: okamžité prepnúť, rýchle obnovenie služieb alebo len zdokumentovaný postup obnovy.

2. Mapujte celú závislostnú reťazec aplikácie

Dokumentujte všetko, čo musí byť prítomné, aby aplikácia mohla vykonávať svoju prácu.

Nehrajte sa len s vykonateľným súborom alebo serverom Windows. Nezabudnite na databázy, úložisko, autentifikáciu, DNS, sieťovanie, certifikáty, licenčné systémy, brány a externé služby.

Pre každého sa pýtajte:

Čo sa stane s aplikáciou, ak to zmizne?

Tento cvičenie odhalí skryté jednotlivé body zlyhania a stanoví sekvenciu obnovy. Obnovenie hostiteľa aplikácie ako prvého veľmi nepomôže, ak jeho databáza, identitný servis alebo úložisko ešte nie sú k dispozícii.

3. Odstrániť kritické jednotlivé body zlyhania

Akonáhle je stanovený strom závislostí, určte, ktoré komponenty majú byť zbytočné, na základe obchodnej dôležitosti a cieľov obnovy.

V prípade dodávania aplikácií pre Windows to môže zahŕňať nasadenie viacerých aplikačných serverov namiesto spoliehania sa na schopnosti jedného hostiteľa. S vrstvou vyvažovania záťaže môžu byť relácie rozložené medzi aplikačné inštancie počas bežnej prevádzky. V prípade zlyhania hostiteľa môžu byť prichádzajúce pripojenia smerované na zdravé inštancie aplikačných serverov.

Plánovanie redundancie by malo byť informované analýzou závislostí. Viacero aplikačných serverov pristupujúcich k jednému kritickému databázovému, sieťovému bráne alebo úložnej vrstve stále predstavuje jediný bod zlyhania.

Návrh vysokej dostupnosti musí preto považovať aplikačnú službu za integrovanú entitu. Pre prostredia Windows Server, ktoré vyžadujú redundanciu na úrovni infraštruktúry, Dokumentácia o zlyhaní clustrovania spoločnosti Microsoft poskytuje ďalšie usmernenia k topológiám vysokej dostupnosti a obnovy po havárii.

4. Oddeliť aplikácie od jednotlivých koncových bodov

Inštalácia kritickej aplikácie priamo na pracovnej stanici každého zamestnanca môže vytvoriť iný druh problému s odolnosťou. Ak používatelia stratí prístup k svojmu bežnému počítaču, môžu tiež stratiť prístup k aplikáciám, ktoré potrebujú na pokračovanie v práci.

Centralizácia aplikácií na spravovaných Windows hostiteľoch a prezentovanie rozhrania aplikácie používateľom eliminuje toto riziko. Údaje a stav aplikácie sú uložené na spravovanom Windows hostiteľovi a sú prístupné autorizovanými koncovými bodmi.

Týmto spôsobom sprístupňujeme aplikáciu používateľom, aj keď zmenia zariadenia alebo miesta. Hoci centralizácia aplikácií neodstraňuje problémy s infraštruktúrou, pomáha presunúť ju do prostredia, kde ju môže kontrolovať IT.

Poskytnite viac ako jednu praktickú metódu prístupu

Odolnosť sa môže dosiahnuť aj vyhýbaním sa zbytočnej závislosti na jednom type koncového bodu alebo metóde pripojenia.

V závislosti od architektúry dodávania aplikácií môžu používatelia používať rôzne vzdialený prístup metódy, vrátane klienta kompatibilného s RDP, dedikovaného spúšťača aplikácií, webového portálu alebo relácie prehliadača HTML5.

Alternatívne metódy pripojenia by sa nemali zamieňať s redundanciou infraštruktúry. Ak všetci závisia od rovnakého zlyhaného servera, aplikácia je stále nedostupná.

Poskytujú odolnosť prístupu, keď narušenie ovplyvňuje normálne zariadenie používateľa, nainštalovaného klienta alebo miesto, skôr než samotnú aplikačnú službu.

6. Monitor predtým, ako sa degradácia stane výpadkom

Odolnosť aplikácie nie je len o obnove, ale včasné zistenie môže zabrániť degradácii na výpadok.

Ukazovatele užitočné v prostrediach aplikácií Windows sú využitie CPU, tlak na pamäť, kapacita disku a I/O, využitie siete, aktívne relácie, proces aplikácie, čas odozvy, zlyhané pripojenie a dostupnosť závislých služieb.

Sledovanie trendov je kľúčové, pretože server, ktorý sa opakovane blíži svojim limitom, môže byť stále online, zatiaľ čo používateľský zážitok sa postupne zhoršuje.

Práhové upozornenia umožňujú administrátorom preskúmať predchodcov incidentu predtým, ako používatelia stratí prístup.

7. Plánovanie kapacitných špičiek a prechodu na zálohu

Aplikácia, ktorá prežije zlyhania na úrovni hardvéru, ale je úplne neschopná fungovať pri zvýšených nárokoch, nie je skutočne odolná voči zlyhaniam akéhokoľvek druhu.

Plánovanie kapacity musí zohľadniť nielen každodenné vzory používania, ale aj zohľadniť špičky v dôsledku sezónnych požiadaviek, zmien smien, rastu alebo požiadaviek na hosting pre iné aplikácie.

Najmä v prostrediach s viacerými servermi musí byť strata jedného servera zohľadnená zabezpečením, že ostatné hostingové uzly majú rezervnú kapacitu na spracovanie akýchkoľvek procesov, ktoré by inak boli vykonané na zlyhávajúcom uzle.

Inak môžu postupy pre prechod na zálohu jednoducho premeniť izolovaný incident na rozsiahly problém s výkonom systému.

8. Chrániť dáta a konfiguráciu

Náhradný server Windows je málo užitočný, ak IT nemôže obnoviť komponenty potrebné na to, aby aplikácia fungovala.

To môže znamenať, že zálohovacie postupy musia zahŕňať údaje aplikácie, databázy, konfiguračné súbory, certifikáty, nastavenia aplikácie, používateľské profily, konfiguráciu infraštruktúry, skripty a licenčné informácie.

Stratégia sa bude líšiť v závislosti od cieľa obnovy aplikácie (RTO) a cieľa obnovy bodu (RPO)

Nadovšetkým zabezpečte, aby úspešná záloha neznamenala úspešné obnovenie. IT tímy by mali otestovať, či je možné obnoviť celý aplikačný servis z chránených údajov a konfigurácie.

9. Znížte dosah zmien

Nie vždy ide o nepredvídanú katastrofu, ktorá spôsobuje prerušenia. Môžu byť spôsobené aj implementovanými vylepšeniami. Takže opravy systému Windows, aktualizácie aplikácií a ovládačov, zmeny bezpečnostnej politiky a konfigurácie môžu mať tiež negatívny dopad na dostupnosť aplikácie. Odporúča sa vyhnúť sa vykonávaniu podobných zmien na všetkých produkčných hostiteľoch naraz, ak je to možné.

V prostredí s viacerými servermi je možné vykonávať zlepšovacie zmeny po etapách, čím sa umožní administrátorovi zabezpečiť, že všetko funguje správne. Možnosť vrátiť vykonané zmeny je tiež nevyhnutná.

Takže pri navrhovaní postupov pre nepredvídané situácie by sa mali zvážiť aj možnosti vrátenia zmien. Proces by mal byť riadne zdokumentovaný a zamestnanci by mali vedieť, čo robiť, ak zmena zlyhá, namiesto toho, aby to jednoducho nechali na svojom uvážení.

10. Návrh pre elegantné zhoršenie

Odolnosť nie je o udržaní 100 % normálnych funkcií v prevádzke za všetkých okolností.

V niektorých prípadoch môže byť udržanie operácií pre kľúčových používateľov alebo aplikácie dôležitejšie ako zabezpečenie dostupnosti všetkých služieb pre všetkých používateľov. Prioritné úlohy môžu byť stanovené predtým, ako k incidentu dôjde, IT tímami.

Ak je k dispozícii kapacita, ktorá môže byť využitá, môže mať zmysel najprv ju priradiť k výrobe, zákazníckemu servisu, financiám alebo iným funkciám.

To je elegantná degradácia: zachovanie schopnosti vykonávať funkcie, ktoré generujú najväčšiu obchodnú hodnotu, namiesto toho, aby zlyhanie menej kritických prvkov spôsobilo pád celého systému.

Ako by mali IT tímy monitorovať odolnosť aplikácií?

Monitorovanie jednotlivých serverov môže byť užitočné, ale monitorovanie odolnosti by malo odrážať celkovú službu aplikácie, ako ju vnímajú používatelia.

Realistický model sa skladá z niekoľkých vrstiev:

Vrstva	Čo monitorovať	Príklad zlyhania
Host	CPU, RAM, disk, dostupnosť OS	Server je preťažený alebo offline
Aplikácia	Stav procesu a služby	Zlyhanie aplikácie
Závislosť	Databáza, DNS, identita, úložisko	Aplikácia sa spustí, ale nemôže fungovať.
Prístup	Brána, portál, sieťová cesta	Používatelia sa nemôžu pripojiť
Relácia	Aktívni používatelia, zlyhania, latencia	Aplikácia je online, ale nepoužiteľná
Obchodná funkcia	Úspešné dokončenie pracovného postupu	Používateľ nemôže dokončiť požadovanú úlohu.

Oblasť obchodnej funkcie je jednou z najjednoduchších na prehliadanie.

Infrastruktúrne panely môžu zobrazovať všetky servery, služby a sieťové cesty ako zdravé, zatiaľ čo pracovný tok skutočného používateľa je ohrozený. Je preto dôležité, aby kritické aplikácie monitorovali svoju zdravosť z pohľadu operácie, na ktorú sú navrhnuté, aby podporovali.

Ako by sa mala testovať odolnosť aplikácie?

Architektúra odolnosti, ktorá nikdy nezažila kontrolovaný zlyhanie, obsahuje netestované predpoklady.

Použite testovanie na vyhodnotenie reakcie systému, keď sa kľúčové komponenty stanú nedostupnými. Testy by mali zahŕňať odpojenie hostiteľa aplikácie, zastavenie služby aplikácie, simuláciu straty sieťovej trasy, overenie správania brány alebo vyvažovania záťaže, obnovenie zo zálohy a prístup k aplikácii z alternatívneho koncového bodu.

Testovacie procesy by mali presahovať technické aspekty obnovy. IT tímy by mali skontrolovať, či sú upozornenia zasielané správnym administratívnym pracovníkom, či sa kroky obnovy vykonávajú v správnom poradí a či sú používatelia schopní vykonať skutočnú obchodnú úlohu po obnovení služieb.

Prevádzkové postupy sú neoddeliteľnou súčasťou odolného systému. Postupy eskalácie upozornení: kto prijíma upozornenie? Kto má právo iniciovať prechod na záložný systém? Kde sú uložené dokumenty o obnove a poverenia? Ktorá závislosť musí byť online ako prvá?

Technická redundancia poskytuje malý prínos, ak neboli otestované procesy na obnovenie prístupu.

Aký môže byť kontrolný zoznam odolnosti aplikácie?

Predtým, ako sa pustia do kritickej aplikácie Windows odolnej voči chybám, by IT tímy mali byť schopné odpovedať na nasledujúce otázky:

• Na ktorých obchodných procesoch závisí aplikácia?
• Aké sú jeho RTO a RPO?
• Aké servery, databázy a externé služby sú potrebné?
• Kde sú jeho kritické jednotlivé body zlyhania?
• Môže iný hostiteľ aplikácie prijať používateľov, ak jeden hostiteľ zlyhá?
• Môžu sa používatelia pripojiť, ak je ich normálny koncový bod alebo miesto nedostupné?
• Je dostatok voľnej kapacity pre degradovanú prevádzku?
• Sú problémy s infraštruktúrou, závislosťami a reláciami aktívne monitorované?
• Sú administrátori upozornení predtým, ako sa dôležité prahy stanú výpadkami?
• Sú dáta aplikácie a konfigurácia chránené?
• Bola obnova skutočne testovaná?
• Môžu sa problémové zmeny vrátiť späť?
• Je dokumentovaná sekvencia obnovy?
• Môžu používatelia dokončiť požadovaný obchodný proces po obnovení?

Nie všetky odpovede si vyžadujú drahú infraštruktúru s vysokou dostupnosťou. Správna úroveň ochrany závisí od nákladov a prevádzkového dopadu prestojov.

Dôležité je, aby sa rozhodnutia o dostupnosti, redundancii a obnove robili zámerne, nie len predpokladali.

Ako môže TSplus pomôcť udržať aplikácie Windows dostupné?

Pre organizácie, ktoré sa spoliehajú na existujúce aplikácie Windows, môžeme pomôcť zlepšiť dostupnosť centralizovaním aplikácií na spravovaných serveroch Windows a ich poskytovaním používateľom prostredníctvom klientov kompatibilných s RDP, prístupu v štýle RemoteApp alebo webového portálu HTML5. To znižuje závislosť od jednotlivých používateľských koncových bodov a poskytuje IT tímom väčšiu flexibilitu, keď sa používatelia potrebujú pripojiť z iného zariadenia alebo miesta.

TSplus Remote Access môže tiež podporovať nasadenia s viacerými servermi s vyvažovaním záťaže a prístupom založeným na bráne. V kombinácii s odolnými databázami, úložiskom, službami identity a sieťovaním môže táto architektúra znížiť závislosť od jedného hostiteľa aplikácie a pomôcť udržiavať prístup k kritickým aplikáciám Windows počas narušenia infraštruktúry.

Záver

Odolnosť aplikácie závisí od pochopenia celej cesty medzi infraštruktúrou a obchodným využitím. Redundancia, monitorovanie, zálohovanie, plánovanie kapacity a postupy obnovy sú najúčinnejšie, keď sú navrhnuté okolo jasne definovaných závislostí aplikácií a cieľov obnovy.

Pre existujúce aplikácie Windows často spočíva odolnosť v posilnení prostredia okolo softvéru, než v prestavbe samotnej aplikácie. Kľúčový test zostáva jednoduchý: keď dôjde k narušeniu, môžu používatelia pokračovať v práci, alebo môže IT obnoviť požadovanú obchodnú funkciu v rámci dohodnutého časového okna na obnovu?