Aplikační odolnost: Udržujte aplikace Windows dostupné

Úvod

Windows aplikace často závisí na mnohem více než na serveru, který je hostí. Databáze, identity služby, úložiště, brány, sítě a uživatelské koncové body mohou všechny ovlivnit, zda aplikace zůstává použitelná během narušení. Tento článek vysvětluje, jak mohou IT týmy posoudit tyto závislosti, navrhnout odolnost kolem stávajících Windows aplikací, monitorovat správné vrstvy a testovat, zda plány obnovy skutečně zachovávají obchodní funkce, na kterých uživatelé spoléhají.

Co je odolnost aplikací?

Odolnost aplikace je schopnost aplikace a infrastruktury kolem ní pokračovat v poskytování životně důležitých funkcí během narušení a předvídatelně se zotavit po selhání.

Narušení může být malé nebo velké a příčiny se mohou lišit od selhání hardwaru nebo operačního systému, pádu aplikací, neúspěšných aktualizací, výpadků databáze, přerušení sítě, selhání autentizace, vyčerpání zdrojů, nedostupných závislostí nebo bezpečnostních incidentů.

Odolná architektura uznává, že selhání jsou nevyhnutelná, a místo toho, aby se snažila zabránit každé události, se IT organizace snaží omezit dopad každé z nich a zavést kontrolované postupy obnovy, aby udržely nebo obnovily službu.

Odolnost aplikací je více než dostupnost serveru

Běžnou chybou je používat dostupnost serveru jako zástupce dostupnosti aplikace, která běží na serveru.

Aby byla obchodní aplikace skutečně dostupná, je třeba, aby bylo současně k dispozici několik komponentů:

Infrastruktura → Operační systém → Aplikace → Závislosti → Přístupová cesta → Uživatelova relace → Obchodní proces

Problém s jakýmkoli prvkem v tomto řetězci může vést k tomu, že aplikace bude efektivně nedostupná.

Například aplikační server může být funkční, zatímco jeho databáze je nedostupná. Publikovaná aplikace může fungovat správně, ale selhání brány znemožňuje vzdáleným zaměstnancům k ní přistupovat. Uživatelé mohou dokonce úspěšně spustit aplikaci, ale mohou být zablokováni v dokončení transakce, protože licenční, souborová nebo backendová služba není k dispozici.

Odolnost aplikace by se tedy měla měřit na základě schopnosti uživatele vykonat potřebný obchodní úkol, spíše než na tom, zda server dokáže reagovat na kontrolu dostupnosti nebo zdraví.

Proč je odolnost aplikací odlišná pro aplikace Windows?

Moderní praktiky odolnosti se stále více zaměřují na cloudové aplikace, kontejnery, mikroservisy a automatizovanou orchestraci. I když jsou tyto přístupy cenné, ne vždy jsou použitelné pro každou organizaci.

Mnoho organizací má zastaralé aplikace pro podnikání na platformě Windows, které byly vyvinuty předtím, než se běžnými staly architektury nativní pro cloud. ERP software, účetní aplikace, výrobní aplikace, aplikace pro zdravotní péči, inženýrské aplikace a interně vyvinuté aplikace mohou být pro provoz organizace zásadní.

Přepracování těchto aplikací na mikroservisy může být extrémně nákladné, technicky náročné nebo dokonce zcela neproveditelné, pokud organizace nekontroluje zdrojový kód.

V takových případech může mít významnou hodnotu učinit operace kolem aplikace odolnějšími, spíše než se snažit učinit samotnou aplikaci odolnější. Publikování aplikací může být součástí tohoto přístupu tím, že udržuje stávající aplikace Windows na centralizované infrastruktuře, zatímco mění způsob, jakým k nim uživatelé přistupují. To může zahrnovat změny v infrastruktuře hostující aplikaci, jako je odstranění omezení infrastruktury, vytváření redundantních hostitelů aplikací, umožnění alternativních metod přístupu a implementaci pružnějších postupů obnovy pro hostitele aplikace.

V jakém případě by mohla selhat dostupnost aplikace Windows?

Budování odolnosti aplikace začíná objevováním komponent, které jsou potřebné k úspěšnému doručení aplikace z jejich hostitelů k uživatelům. Tento proces zdůrazňuje potenciální místa selhání, která mohou způsobit výpadek celé aplikace.

Aplikační hostitelé

Aplikace běžící na jednom serveru Windows má jasný jediný bod selhání.

Hardwarové problémy, aktualizace Windows, poškození operačního systému, vyčerpání zdrojů nebo selhání aplikace mohou narušit každého uživatele závislého na daném stroji. Pokud jsou požadavky na dostupnost nezbytné, mohou být nasazeny více aplikační hostitele, aby se snížila závislost na jakémkoli jednom stroji a zajistila kapacita, když server není k dispozici.

Databáze, úložiště a další závislosti

Mnoho aplikací Windows závisí na službách externích k hostiteli aplikace. Tyto služby mohou zahrnovat:

• SQL databáze
• soubory sdílení
• licenční servery
• Active Directory
• Systém doménových jmen (DNS)
• certifikáty
• APIs
• middleware
• síťové úložiště
• tisková infrastruktura

Zavedení druhého aplikačního serveru poskytuje minimální odolnost, pokud sdílejí společnou databázi nebo závislost na úložišti, která není k dispozici. Stává se zřejmým, že mapování závislostí musí přesáhnout viditelnou aplikační infrastrukturu.

Autentizace a identita

Uživatelé nemohou přistupovat k funkční aplikaci, pokud není k dispozici potřebná autentizační infrastruktura.

IT týmy musí identifikovat identity služby, na kterých závisí jejich kritické aplikace, a zajistit, aby měly plány pro případ selhání, když budou tyto zdroje nedostupné. Active Directory, cloudové identity platformy, služby vícefaktorové autentizace (MFA) a autentizační brány se mohou spolehnout na zajištění řetězce dostupnosti pro aplikaci.

Síťové a vzdálené přístupové cesty

Pro centralizované aplikace Windows představuje konektivita mezi uživateli a aplikačním prostředím další možnou oblast selhání.

Pojďme si představit celou řetězec:

Uživatelské zařízení → Internet nebo LAN → brána → hostitel aplikace → backendové služby

Porucha kdekoli v tomto řetězci může zabránit uživatelům vykonávat jejich práci, i když aplikace běží bez problémů. To je obzvlášť relevantní pro distribuované organizace, kde může být aplikace v provozu v datovém centru, ale nedostupná pro uživatele na jiném místě.

Koncové body

Aplikovaná odolnost nemusí nutně vyžadovat, aby byla k dispozici běžná pracovní stanice uživatele.

Nabídka autorizovaným uživatelům prostředků pro přístup k centrálně hostovaným aplikacím z alternativního zařízení nebo prostřednictvím prohlížeče může zajistit přístup, pokud se notebook stane nedostupným, kancelář se stane nedostupnou nebo zaměstnanci potřebují pracovat z jiného místa.

Architektura doručování aplikací může být součástí širší strategie kontinuity podnikání.

Jaký je proces budování odolnosti aplikací pro aplikace Windows?

Žádná jednotlivá technologie nedělá aplikaci odolnou. IT týmy se místo toho musí snažit snížit počet selhání, která mohou zcela vyřadit funkci, a připravit se na řízené mechanismy obnovy pro ty, které zůstanou.

1. Identifikujte kritické aplikace a obchodní procesy

Ne všechny aplikace vyžadují stejnou úroveň ochrany. Začněte tím, že určíte, které aplikace podporují primární operace, na kterých uživatelé spoléhají, a jakou toleranci mají k výpadkům.

Dva cíle obnovy překládají obchodní požadavky do technických specifikací. Pokyny NIST pro plánování pohotovostních opatření definuje cíle doby obnovy (RTO) a cíle bodu obnovy (RPO) jako klíčové parametry pro určení požadavků na obnovu:

• Cílová doba obnovy (RTO): doba přijatelných prostojů před obnovením služby.
• Cíl bodu obnovení (RPO): interval přijatelných ztrát dat, měřený v čase.

Aplikace, která se intenzivně používá k zpracování objednávek, může mít RTO v minutách, zatímco aplikace pro finanční reporting, která běží jednou týdně, si může dovolit dny výpadku.

RTO a RPO definují typ ochrany potřebný pro aplikaci: okamžité přepnutí, rychlé obnovení služeb nebo pouze zdokumentovaný postup obnovy.

2. Mapujte celou závislost aplikace

Dokumentujte vše, co musí být přítomno, aby aplikace mohla vykonávat svou práci.

Nehledejte pouze na spustitelném souboru nebo serveru Windows. Nezapomeňte na databáze, úložiště, autentizaci, DNS, síťování, certifikáty, licenční systémy, brány a externí služby.

Pro každého se ptejte:

Co se stane s aplikací, pokud to zmizí?

Tato cvičení odhalí skryté jednotlivé body selhání a stanoví sekvenci obnovy. Obnovení hostitele aplikace jako prvního příliš nepomůže, pokud jeho databáze, identitní služba nebo úložiště ještě nejsou k dispozici.

3. Odstraňte kritické jednotlivé body selhání

Jakmile je strom závislostí vytvořen, určete, které komponenty mají být redundantní, na základě obchodní důležitosti a cílů obnovy.

V případě dodávání aplikací pro Windows by to mohlo zahrnovat nasazení několika aplikačních serverů namísto spoléhání se na schopnosti jednoho hostitele. S vrstvou vyvažování zátěže mohou být relace rozloženy mezi instance aplikací během běžného provozu. V případě selhání hostitele mohou být příchozí připojení směrována na zdravé instance aplikačních serverů.

Plánování redundance by mělo být informováno analýzou závislostí. Více aplikačních serverů přistupujících k jedné kritické databázi, síťové bráně nebo úložné vrstvě stále představuje jediný bod selhání.

Návrh vysoké dostupnosti musí proto považovat aplikační službu za integrovanou entitu. Pro prostředí Windows Server vyžadující redundanci na úrovni infrastruktury, Dokumentace k Microsoft Failover Clustering poskytuje další pokyny k topologiím vysoké dostupnosti a obnovy po havárii.

4. Oddělit aplikace od jednotlivých koncových bodů

Instalace kritické aplikace přímo na pracovní stanici každého zaměstnance může vytvořit jiný typ problému s odolností. Pokud uživatelé ztratí přístup ke svému běžnému počítači, mohou také ztratit přístup k aplikacím, které potřebují k pokračování v práci.

Centralizace aplikací na spravovaných Windows hostitelích a prezentace uživatelského rozhraní aplikace eliminuje toto riziko. Data a stav aplikace jsou uloženy na spravovaném hostiteli Windows a přistupují k nim autorizované koncové body.

Tímto způsobem zpřístupňujeme aplikaci uživatelům, i když změní zařízení nebo umístění. I když centralizace aplikací neodstraňuje problémy s infrastrukturou, pomáhá ji přesunout do prostředí, které může být řízeno IT.

5. Poskytněte více než jednu praktickou metodu přístupu

Odolnost lze také dosáhnout vyhnutím se zbytečné závislosti na jednom typu koncového bodu nebo metodě připojení.

V závislosti na architektuře doručování aplikací mohou uživatelé používat různé vzdálený přístup metody, včetně klienta kompatibilního s RDP, dedikovaného spouštěče aplikací, webového portálu nebo relace prohlížeče HTML5.

Alternativní metody připojení by neměly být zaměňovány s redundancí infrastruktury. Pokud všechny závisí na stejném selhaném serveru, aplikace je stále nedostupná.

Zajišťují odolnost přístupu, když narušení ovlivňuje běžné zařízení uživatele, nainstalovaného klienta nebo místo, spíše než samotnou aplikační službu.

6. Monitorujte, než degradace přejde v výpadek

Odolnost aplikací není pouze o obnově, ale včasné odhalení může zabránit degradaci do výpadku.

Ukazatele užitečné v prostředích aplikací Windows jsou využití CPU, tlak na paměť, kapacita disku a I/O, využití sítě, aktivní relace, proces aplikace, doba odezvy, neúspěšné připojení a dostupnost závislých služeb.

Sledování trendů je zásadní, protože server, který se opakovaně blíží svým limitům, může být stále online, zatímco uživatelský zážitek se postupně zhoršuje.

Prahové upozornění umožňuje správcům vyšetřit předchůdce incidentu, než uživatelé ztratí přístup.

7. Plánování kapacitních špiček a přepnutí na zálohu

Aplikace, která přežije selhání na úrovni hardwaru, ale je zcela neschopná fungovat pod zvýšenými nároky, není skutečně odolná vůči selháním jakéhokoli druhu.

Plánování kapacity musí zohlednit nejen každodenní vzorce používání, ale také brát v úvahu špičky způsobené sezónními požadavky, změnami směn, růstem nebo požadavky na hostování pro jiné aplikace.

Zvláště v prostředích s více servery je třeba zohlednit ztrátu jednoho serveru tím, že se zajistí, aby ostatní hostingové uzly měly rezervní kapacitu pro zpracování jakýchkoli procesů, které by jinak byly prováděny na selhávajícím uzlu.

Jinak mohou postupy pro přepnutí na záložní systém jednoduše proměnit izolovaný incident na široký problém s výkonem systému.

8. Ochrana dat a konfigurace

Náhradní server Windows je málo užitečný, pokud IT nemůže obnovit komponenty potřebné k tomu, aby aplikace fungovala.

To může znamenat, že zálohovací postupy musí zahrnovat data aplikací, databáze, konfigurační soubory, certifikáty, nastavení aplikací, uživatelské profily, konfiguraci infrastruktury, skripty a informace o licencích.

Strategie se bude lišit v závislosti na cíli doby obnovy (RTO) a cíli bodu obnovy (RPO) aplikace.

Nad vším zajistěte, aby úspěšná záloha neznamenala úspěšné obnovení. IT týmy by měly otestovat, zda je možné obnovit celý aplikační servis z chráněných dat a konfigurace.

9. Snižte dosah změn

Není vždy případem nepředvídané katastrofy, která způsobuje přerušení. Mohou být také způsobena implementovanými vylepšeními. Takže opravy systému Windows, aktualizace aplikací a ovladačů, změny bezpečnostní politiky a konfigurace mohou také mít negativní dopad na dostupnost aplikace. Doporučuje se vyhnout se provádění podobných změn na všech produkčních hostitelích současně, pokud je to možné.

V multi-serverovém nastavení je možné provádět zlepšení po etapách, což umožňuje administrátorovi ujistit se, že vše funguje správně. Schopnost vrátit provedené změny je také nezbytná.

Při navrhování postupů pro případ nouze by měly být zvažovány také možnosti návratu. Proces by měl být řádně zdokumentován a zaměstnanci by měli vědět, co dělat, pokud změna selže, místo aby to jednoduše nechali na svém uvážení.

10. Návrh pro elegantní degradaci

Odolnost nespočívá v udržení 100 % normálních funkcí v chodu za všech okolností.

V některých případech může být udržení provozu pro klíčové uživatele nebo aplikace důležitější než zajištění dostupnosti všech služeb pro všechny uživatele. Priority mohou být stanoveny před tím, než k incidentu dojde, IT týmy.

Pokud je k dispozici kapacita, kterou lze využít, může dávat smysl nejprve ji přidělit výrobě, zákaznickému servisu, financím nebo jiným funkcím.

To je elegantní degradace: zachování schopnosti spouštět funkce, které generují největší obchodní hodnotu, místo aby selhání méně kritických prvků způsobilo pád celého systému.

Jak by měly IT týmy monitorovat odolnost aplikací?

Monitorování jednotlivých serverů může být užitečné, ale monitorování odolnosti by mělo odrážet celkovou službu aplikace, jak ji vnímají uživatelé.

Realistický model se skládá z několika vrstev:

Vrstva	Co sledovat	Příklad selhání
Host	CPU, RAM, disk, dostupnost OS	Server je přetížený nebo offline
Aplikace	Stav procesu a služby	Aplikace se zhroutila
Závislost	Databáze, DNS, identita, úložiště	Aplikace se spustí, ale nemůže fungovat.
Přístup	Brána, portál, síťová cesta	Uživatelé se nemohou připojit
Relace	Aktivní uživatelé, selhání, latence	Aplikace je online, ale nepoužitelná
Obchodní funkce	Úspěšné dokončení pracovního postupu	Uživatel nemůže dokončit požadovaný úkol.

Oblast obchodní funkce je jednou z nejjednodušších, které lze přehlédnout.

Infrastrukturní panely mohou zobrazovat všechny servery, služby a síťové cesty jako zdravé, zatímco pracovní postup skutečného uživatele je ohrožen. Je proto důležité, aby kritické aplikace monitorovaly své zdraví z pohledu operace, kterou mají podporovat.

Jak by měla být testována odolnost aplikace?

Architektura odolnosti, která nikdy nezažila řízené selhání, obsahuje netestované předpoklady.

Použijte testování k vyhodnocení reakce systému, když klíčové komponenty nejsou k dispozici. Testy by měly zahrnovat odpojení hostitele aplikace, zastavení služby aplikace, simulaci ztráty síťové trasy, ověření chování brány nebo vyvažování zátěže, obnovení ze zálohy a přístup k aplikaci z alternativního koncového bodu.

Testovací procesy by měly přesahovat technické aspekty obnovy. IT týmy by měly zkontrolovat, zda jsou upozornění zasílána správnému administrativnímu personálu, zda jsou kroky obnovy prováděny ve správném pořadí a zda jsou uživatelé schopni vykonávat skutečný obchodní úkol po obnovení služeb.

Operační postupy jsou nedílnou součástí odolného systému. Postupy eskalace upozornění: kdo přijímá upozornění? Kdo má pravomoc zahájit přepnutí? Kde jsou uloženy dokumentace pro obnovu a přihlašovací údaje? Která závislost musí být nejprve aktivována?

Technická redundance poskytuje malý přínos, pokud nebyly procesy pro obnovení přístupu otestovány.

Jaký může být kontrolní seznam odolnosti aplikace?

Před zahájením práce na kritické aplikaci Windows by měly IT týmy být schopny odpovědět na následující otázky:

• Na které obchodní procesy se aplikace spoléhá?
• Jaké jsou jeho RTO a RPO?
• Jaké servery, databáze a externí služby to vyžaduje?
• Kde jsou její kritické jednotlivé body selhání?
• Může jiný hostitel aplikace přijmout uživatele, pokud jeden hostitel selže?
• Mohou se uživatelé připojit, pokud je jejich běžný koncový bod nebo místo nedostupné?
• Je dostatek rezervní kapacity pro degradovaný provoz?
• Jsou problémy s infrastrukturou, závislostmi a relacemi aktivně monitorovány?
• Jsou administrátoři upozorněni před tím, než důležité prahy přejdou do výpadků?
• Jsou data aplikace a konfigurace chráněny?
• Bylo obnovení skutečně testováno?
• Lze problematické změny vrátit zpět?
• Je sekvence obnovy zdokumentována?
• Mohou uživatelé dokončit požadovaný obchodní proces po obnovení?

Ne všechny odpovědi vyžadují drahou infrastrukturu s vysokou dostupností. Správná úroveň ochrany závisí na nákladech a provozním dopadu výpadků.

Důležité je, aby rozhodnutí o dostupnosti, redundanci a obnově byla činěna záměrně, nikoli předpokládána.

Jak může TSplus pomoci udržet aplikace Windows dostupné?

Pro organizace, které se spoléhají na stávající aplikace Windows, můžeme pomoci zlepšit dostupnost centralizací aplikací na spravovaných serverech Windows a jejich dodáváním uživatelům prostřednictvím klientů kompatibilních s RDP, přístupu ve stylu RemoteApp nebo webového portálu HTML5. To snižuje závislost na jednotlivých uživatelských koncových bodech a poskytuje IT týmům větší flexibilitu, když se uživatelé potřebují připojit z jiného zařízení nebo místa.

TSplus Remote Access může také podporovat nasazení na více serverech s vyvažováním zátěže a přístupem založeným na bráně. Když je kombinována s odolnými databázemi, úložištěm, identitními službami a sítí, může tato architektura snížit závislost na jednom hostiteli aplikace a pomoci udržet přístup k důležitým aplikacím Windows během narušení infrastruktury.

Závěr

Odolnost aplikace závisí na pochopení kompletní cesty mezi infrastrukturou a obchodním využitím. Redundance, monitorování, zálohování, plánování kapacity a postupy obnovy jsou nejúčinnější, když jsou navrženy kolem jasně definovaných závislostí aplikací a cílů obnovy.

Pro stávající aplikace Windows často odolnost pochází z posílení prostředí kolem softwaru, spíše než z přestavby samotné aplikace. Klíčový test zůstává jednoduchý: když dojde k narušení, mohou uživatelé pokračovat v práci, nebo může IT obnovit požadovanou obchodní funkci v rámci dohodnutého časového okna pro obnovu?