Alkalmazás Ellenállás: Tartsd elérhetően a Windows Alkalmazásokat

Bevezetés

A Windows alkalmazások gyakran sokkal több mindentől függenek, mint a szerver, amely hosztolja őket. Az adatbázisok, az identitás szolgáltatások, a tárolás, a kapuk, a hálózatok és a felhasználói végpontok mind befolyásolhatják, hogy egy alkalmazás használható marad-e a zavarok idején. Ez a cikk elmagyarázza, hogyan értékelhetik az IT csapatok ezeket a függőségeket, hogyan tervezhetik meg a meglévő Windows alkalmazások körüli ellenállóságot, hogyan figyelhetik a megfelelő rétegeket, és hogyan tesztelhetik, hogy a helyreállítási tervek valóban megőrzik-e az üzleti funkciókat, amelyekre a felhasználók támaszkodnak.

Mi az alkalmazásreziliencia?

Az alkalmazás ellenálló képessége az alkalmazás és a körülötte lévő infrastruktúra azon képessége, hogy folytassa a létfontosságú funkciók biztosítását egy zavar idején, és hogy előre jelezhető módon helyreálljon egy hiba után.

A zavar kicsi vagy nagy lehet, és az okok változhatnak hardver- vagy operációs rendszer hibától, alkalmazás összeomlásoktól, sikertelen frissítésektől, adatbázis leállásoktól, hálózati megszakadásoktól, hitelesítési hibáktól, erőforrás kimerüléstől, elérhetetlen függőségektől vagy biztonsági eseményektől.

Egy ellenálló architektúra elismeri, hogy a hibák elkerülhetetlenek, és ahelyett, hogy minden egyes esemény megelőzésére törekedne, az IT szervezetek arra törekednek, hogy korlátozzák mindegyik hatását, és ellenőrzött helyreállítási eljárásokat állítsanak fel a szolgáltatás fenntartása vagy helyreállítása érdekében.

Az alkalmazás ellenállósága több mint a szerver üzemidő.

Gyakori hiba, hogy a szerver elérhetőségét használják az alkalmazás elérhetőségének helyettesítésére, amely a szerveren fut.

Ahhoz, hogy egy üzleti alkalmazás valóban elérhető legyen, számos komponensnek egyidejűleg elérhetőnek kell lennie:

Infrastruktúra → Operációs rendszer → Alkalmazás → Függőségek → Hozzáférési útvonal → Felhasználói munkamenet → Üzleti folyamat

A lánc bármely elemével kapcsolatos probléma az alkalmazás hatékonyan elérhetetlenné válását eredményezheti.

Például egy alkalmazásszerver egészséges lehet, miközben az adatbázisa nem elérhető. Egy közzétett alkalmazás megfelelően működhet, de egy átjáróhiba lehetetlenné teszi a távoli munkavállalók számára a hozzáférést. A felhasználók akár sikeresen elindíthatják az alkalmazást, de megakadályozhatják őket a tranzakció befejezésében, mert egy licenc, fájl vagy háttérszolgáltatás nem elérhető.

Az alkalmazás ellenállóságát tehát a felhasználó képessége alapján kell mérni a szükséges üzleti feladat elvégzésére, nem pedig az alapján, hogy egy szerver képes-e válaszolni egy elérhetőségi vagy egészségügyi ellenőrzésre.

Miért más az alkalmazásellenállás a Windows alkalmazások esetében?

A modern ellenállósági gyakorlatok egyre inkább a felhőalapú alkalmazásokra, konténerekre, mikroszolgáltatásokra és automatizált orchestrációra összpontosítanak. Bár ezek értékes megközelítések, nem mindig alkalmazhatók minden szervezetre.

Sok szervezetnek vannak örökölt Windows üzleti alkalmazásai, amelyeket a felhőalapú architektúrák elterjedése előtt fejlesztettek ki. Az ERP szoftverek, könyvelési alkalmazások, gyártási alkalmazások, egészségügyi alkalmazások, mérnöki alkalmazások és belső fejlesztésű alkalmazások mind kritikusak lehetnek egy szervezet működése szempontjából.

Ezeknek az alkalmazásoknak a mikroszolgáltatásokként való újratervezése rendkívül költséges, technikailag kihívást jelentő, vagy akár teljesen megvalósíthatatlan lehet, ha a szervezet nem ellenőrzi a forráskódot.

Ilyen esetekben jelentős értéke lehet annak, ha az alkalmazás körüli műveleteket ellenállóbbá tesszük, ahelyett, hogy magát az alkalmazást próbálnánk ellenállóbbá tenni. Alkalmazás közzététel része lehet ennek a megközelítésnek azáltal, hogy a meglévő Windows alkalmazásokat központosított infrastruktúrán tartja, miközben megváltoztatja, hogyan férnek hozzá a felhasználók. Ez magában foglalhatja az alkalmazást hosztoló infrastruktúra megváltoztatását, például az infrastruktúra korlátainak megszüntetését, redundáns alkalmazás hosztok létrehozását, alternatív hozzáférési módszerek engedélyezését és a alkalmazás hoszt számára reagálóbb helyreállítási eljárások végrehajtását.

Milyen esetben hiúsulhat meg egy Windows alkalmazás elérhetősége?

Az alkalmazás ellenálló képességének kiépítése azzal kezdődik, hogy felfedezzük azokat az összetevőket, amelyek szükségesek egy alkalmazás sikeres felhasználókhoz való eljuttatásához a gazdáiktól. Ez a folyamat kiemeli azokat a potenciális hibapontokat, amelyek egy egész alkalmazást leállíthatnak.

Alkalmazásgazdák

Egy alkalmazás, amely egyetlen Windows szerveren fut, egyértelmű egyetlen hibaponttal rendelkezik.

Hardverproblémák, Windows-frissítések, operációs rendszer sérülése, erőforrás-kimerülés vagy alkalmazáshiba megzavarhatja az összes felhasználót, aki az adott géptől függ. Ha a rendelkezésre állás igényei megkívánják, több alkalmazásgazda is beállítható, hogy csökkentse a függőséget bármelyik géptől, és kapacitást biztosítson, amikor egy szerver elérhetetlenné válik.

Adatbázisok, tárolás és egyéb függőségek

Sok Windows-alkalmazás külső szolgáltatásokra támaszkodik, amelyek nem az alkalmazás gazdagépén találhatók. Ezek a szolgáltatások a következőket tartalmazhatják:

• SQL adatbázisok
• fájlmegosztások
• licencszerverek
• Active Directory
• Domain Name System (DNS)
• tanúsítványok
• API-k
• köztes szoftver
• hálózati tárolás
• nyomtatási infrastruktúra

A második alkalmazás szerver bevezetése minimális ellenállóságot biztosít, ha közös adatbázis- vagy tárolási függőséggel rendelkeznek, amely nem elérhető. Nyilvánvalóvá válik, hogy a függőségek térképezésének túl kell terjednie a látható alkalmazásinfrastruktúrán.

Hitelesítés és Identitás

A felhasználók nem tudják elérni az egészséges alkalmazást, ha a szükséges hitelesítési infrastruktúra nem elérhető.

Az IT csapatoknak azonosítaniuk kell azokat az identitás szolgáltatásokat, amelyekre kritikus alkalmazásaik támaszkodnak, és biztosítaniuk kell, hogy rendelkezzenek tartaléktervekkel arra az esetre, ha ezek az erőforrások nem elérhetők. Az Active Directory, a felhőalapú identitásplatformok, a többfaktoros hitelesítési (MFA) szolgáltatások és a hitelesítési átjárók mind megbízhatóan biztosíthatják az alkalmazás elérhetőségi láncát.

Hálózati és Távoli Hozzáférési Útvonalak

A központosított Windows alkalmazások esetében a felhasználók és az alkalmazáskörnyezet közötti kapcsolódás egy újabb lehetséges hibaterületet jelent.

Képzeljük el a teljes láncot:

Felhasználói eszköz → Internet vagy LAN → átjáró → alkalmazás hoszt → háttérszolgáltatások

A lánc bármelyik részének meghibásodása megakadályozhatja a felhasználókat abban, hogy végezzék a munkájukat, még akkor is, ha az alkalmazás egészségesen működik. Különösen releváns elosztott szervezetek esetében, ahol az alkalmazás működhet az adatközpontban, de a felhasználók számára egy másik helyszínen nem elérhető.

Végpontok

Az alkalmazás ellenállósága nem feltétlenül igényli a felhasználó normál munkaállomásának elérhetőségét.

Az engedélyezett felhasználók számára biztosított lehetőség, hogy központilag tárolt alkalmazásokhoz férjenek hozzá alternatív eszközről vagy böngészőn keresztül, biztosíthatja a hozzáférést, ha egy laptop nem elérhető, egy iroda hozzáférhetetlenné válik, vagy az alkalmazottaknak más helyről kell dolgozniuk.

Az alkalmazás-átadás architektúrája egy szélesebb üzletmenet-folytonossági stratégia része lehet.

Mi a folyamat a Windows alkalmazások alkalmazásreziliencia építésében?

Egyetlen technológia sem teszi ellenállóvá az alkalmazást. Az IT csapatoknak inkább csökkenteniük kell a teljes funkciót leállító hibák számát, és fel kell készülniük a kontrollált helyreállítási mechanizmusokra azokra, amelyek megmaradnak.

1. Azonosítsa a kritikus alkalmazásokat és üzleti folyamatokat

Nem minden alkalmazás igényel ugyanakkora védelmet. Kezdje azzal, hogy meghatározza, mely alkalmazások támogatják a fő műveleteket, mely felhasználók támaszkodnak rájuk és milyen mértékű leállást tolerálnak.

Két helyreállítási cél üzleti követelményeket fordít technikai specifikációkra. NIST kockázatkezelési irányelvei meghatározza a helyreállítási időcélt (RTO) és a helyreállítási pontcélt (RPO) mint kulcsfontosságú paramétereket a helyreállítási követelmények meghatározásához:

• Helyreállítási időcél (RTO): az a megengedett leállási időtartam, mielőtt a szolgáltatás helyreáll.
• Helyreállítási Pont Cél (RPO): az elfogadható adatvesztés időintervalluma.

Egy alkalmazás, amelyet intenzíven használnak a megrendelések feldolgozására, percekben mérhető RTO-val rendelkezhet, míg egy pénzügyi jelentési alkalmazás, amelyet hetente egyszer futtatnak, napok leállást is elviselhet.

Az RTO és RPO meghatározza az alkalmazás számára szükséges védelem típusát: azonnali átkapcsolás, gyors szolgáltatás-helyreállítás vagy csupán egy dokumentált helyreállítási eljárás.

2. Térképezze fel az egész alkalmazásfüggőségi láncot

Dokumentálja mindazt, aminek ott kell lennie ahhoz, hogy az alkalmazás elvégezze a feladatát.

Ne állj meg az végrehajtható fájl vagy a Windows szerver mellett. Ne felejtsd el az adatbázisokat, tárolást, hitelesítést, DNS-t, hálózatokat, tanúsítványokat, licencelési rendszereket, átjárókat és külső szolgáltatásokat.

Minden egyes esetben kérdezd meg:

Mi történik az alkalmazással, ha ez eltűnik?

Ez a gyakorlat felszínre hozza a rejtett egyedi hibapontokat, és meghatározza a helyreállítási sorrendet. Egy alkalmazás hosztjának első helyreállítása nem sokat segít, ha az adatbázisa, az identitás szolgáltatása vagy a tárolása még nem elérhető.

3. Távolítsa el a kritikus egyedi hibapontokat

Miután a függőségi fa létrejött, határozza meg, hogy mely komponenseket kell redundánssá tenni, az üzleti fontosság és a helyreállítási célok alapján.

A Windows alkalmazás szállítása esetén ez magában foglalhatja több alkalmazás szerver telepítését, ahelyett, hogy egyetlen gazdagép képességeire támaszkodnánk. Egy terheléselosztó réteg segítségével a munkamenetek a normál működés során eloszthatók az alkalmazás példányok között. Gazdagép hiba esetén a bejövő kapcsolatok az egészséges alkalmazás szerver példányokhoz irányíthatók.

A redundancia tervezését azonban a függőségi elemzésnek kell irányítania. Több alkalmazás szerver, amely egyetlen kritikus adatbázist, hálózati átjárót vagy tárolási réteget ér el, továbbra is egyetlen hibapontot jelent.

A magas rendelkezésre állású tervezés ezért figyelembe kell, hogy vegye az alkalmazás szolgáltatást, mint egy integrált egységet. A Windows Server környezetek számára, amelyek infrastrukturális szintű redundanciát igényelnek, Microsoft hibatűrő klaszterezés dokumentációja további útmutatást nyújt a magas rendelkezésre állású és katasztrófa-helyreállítási topológiákról.

4. Válassza el az alkalmazásokat az egyes végpontoktól

A kritikus alkalmazás közvetlen telepítése minden munkavállaló munkaállomására másfajta ellenállósági problémát okozhat. Ha a felhasználók elveszítik a hozzáférést a szokásos számítógépükhöz, akkor az alkalmazásokhoz való hozzáférést is elveszíthetik, amelyekre szükségük van a munka folytatásához.

Alkalmazások központosítása kezelt Windows hosztokon és az alkalmazás felhasználói felületének bemutatása megszünteti ezt a kockázatot. Az adatok és az alkalmazás állapota a kezelt Windows gazdagépen van tárolva, és az arra jogosult végpontok által érhető el.

Ezzel lehetővé tesszük az alkalmazás elérhetőségét a felhasználók számára, még akkor is, ha eszközöket vagy helyszíneket váltanak. Bár az alkalmazások központosítása nem szünteti meg az infrastruktúrával kapcsolatos problémákat, segít abban, hogy egy olyan környezetbe kerüljön, ahol az IT által irányítható.

Több mint egy gyakorlati hozzáférési módszert biztosítson

A rugalmasság elérhető azáltal is, hogy elkerüljük a felesleges függőséget egyetlen végponttípustól vagy kapcsolati módszertől.

A alkalmazás-átviteli architektúrától függően a felhasználók különbözőket használhatnak. távoli hozzáférés módszerek, beleértve egy RDP-kompatibilis klienst, dedikált alkalmazásindítót, webportált vagy HTML5 böngésző munkamenetet.

Az alternatív kapcsolati módszereket nem szabad összekeverni az infrastruktúra redundanciájával. Ha mindannyian ugyanarra a meghibásodott szerverre támaszkodnak, az alkalmazás továbbra is elérhetetlen.

Biztosítanak hozzáférési ellenállást, amikor a zavarás a felhasználó normál eszközét, telepített kliensét vagy helyét érinti, nem pedig magát az alkalmazás szolgáltatást.

6. Monitorálás a degradáció előtt, mielőtt leállásra kerülne sor

Az alkalmazás ellenállósága nemcsak a helyreállításról szól, hanem a korai észlelés elkerülheti a leállásba való degradálódást.

A Windows alkalmazási környezetekben hasznos mutatók a CPU kihasználtság, a memória nyomás, a lemezkapacitás és I/O, a hálózati kihasználtság, az aktív munkamenetek, az alkalmazásfolyamat, a válaszidő, a sikertelen kapcsolatok és a függő szolgáltatások elérhetősége.

Trendfigyelés kulcsfontosságú, mivel egy olyan szerver, amely folyamatosan megközelíti a határait, még mindig online lehet, miközben a felhasználói élmény fokozatosan romlik.

A küszöbértesítések lehetővé teszik az adminisztrátorok számára, hogy megvizsgálják egy esemény előzményeit, mielőtt a felhasználók elveszítenék a hozzáférést.

7. Készítsen tervet a kapacitáscsúcsokra és a hibaátállásra

Egy olyan alkalmazás, amely túléli a hardver szintű hibákat, de teljesen képtelen működni a megnövekedett igények alatt, nem igazán ellenálló a bármilyen típusú hibákkal szemben.

A kapacitás tervezésének figyelembe kell vennie nemcsak a mindennapi használati mintákat, hanem a szezonális igények, a műszakváltások, a növekedés vagy más alkalmazásokhoz szükséges hosztolási követelmények miatti csúcsokat is.

Különösen több szerveres hosztolási környezetekben egyetlen szerver elvesztését úgy kell figyelembe venni, hogy biztosítani kell, hogy a többi hosztoló csomópont rendelkezzen tartalék kapacitással, hogy elhelyezze azokat a folyamatokat, amelyeket egyébként a meghibásodott csomóponton hajtanának végre.

Ellenkező esetben a hibaelhárítási eljárások egyszerűen egy elszigetelt eseményt széleskörű rendszer teljesítményproblémává alakíthatnak.

8. Adatok és konfiguráció védelme

Egy helyettesítő Windows szervernek csekély haszna van, ha az IT nem tudja helyreállítani az alkalmazás működéséhez szükséges összetevőket.

Ez azt jelentheti, hogy a biztonsági mentési eljárásoknak tartalmazniuk kell az alkalmazás adatokat, adatbázisokat, konfigurációs fájlokat, tanúsítványokat, alkalmazásbeállításokat, felhasználói profilokat, infrastruktúra konfigurációt, szkripteket és licencinformációkat.

A stratégia az alkalmazás helyreállítási időcéljától (RTO) és helyreállítási pontcéljától (RPO) függően változik.

Mindenekelőtt győződjön meg arról, hogy a sikeres biztonsági mentés nem egyenlő a sikeres helyreállítással. Az IT csapatoknak tesztelniük kell, hogy lehetséges-e a teljes alkalmazás szolgáltatás helyreállítása a védett adatokból és konfigurációból.

9. Csökkentse a változások robbanási sugarát

Nem mindig előre nem látható katasztrófa okozza a zavarokat. Ezeket a végrehajtott fejlesztések is okozhatják. Így a Windows javítások, az alkalmazás- és illesztőprogram-frissítések, a biztonsági politika és a konfigurációs változások is negatív hatással lehetnek az alkalmazás elérhetőségére. Ajánlott elkerülni, hogy hasonló változtatásokat egyszerre végezzenek el az összes termelési gazdagépen, ha lehetséges.

Több szerverből álló rendszerben lehetséges a fejlesztési változtatásokat lépésről lépésre végrehajtani, így az adminisztrátor biztosíthatja, hogy minden megfelelően működik. A végrehajtott változtatások visszavonásának lehetősége szintén elengedhetetlen.

Így tehát, amikor a vészhelyzeti eljárásokat tervezik, a visszaállítási lehetőségeket is figyelembe kell venni. A folyamatot megfelelően dokumentálni kell, és a személyzetnek tudnia kell, mit tegyen, ha egy változtatás meghiúsul, ahelyett, hogy egyszerűen a saját belátásukra bíznák.

10. Tervezés a fokozatos degradációhoz

A reziliencia nem arról szól, hogy a normál funkciók 100%-át folyamatosan működtessük.

Bizonyos esetekben a kulcsfelhasználók vagy alkalmazások működésének fenntartása fontosabb lehet, mint az összes szolgáltatás elérhetőségének biztosítása minden felhasználó számára. A prioritások az IT csapatok által egy incidens bekövetkezése előtt megállapíthatók.

Ha van rendelkezésre álló kapacitás, amelyet fel lehet használni, érdemes lehet azt először a termelésre, az ügyfélszolgálatra, a pénzügyre vagy más funkciókra allokálni.

Ez a szép degradáció: megőrizni a képességet, hogy futtassuk azokat a funkciókat, amelyek a legnagyobb üzleti értéket termelik, ahelyett, hogy hagynánk, hogy a kevésbé kritikus elemek meghibásodása az egész rendszert összeomlassza.

Hogyan kell az IT csapatoknak figyelni az alkalmazások ellenállóságát?

Az egyes szerverek figyelése hasznos lehet, de a rugalmasság figyelése a felhasználók által észlelt teljes alkalmazás szolgáltatást kell, hogy tükrözze.

Egy reális modell több rétegből áll:

Réteg	Mit kell figyelni	Példa hiba
Gazda	CPU, RAM, lemez, operációs rendszer elérhetőség	A szerver túlterhelt vagy offline
Alkalmazás	Folyamat és szolgáltatás állapot	Alkalmazás összeomlik
Függőség	Adatbázis, DNS, identitás, tárolás	Alkalmazás elindul, de nem tud működni.
Hozzáférés	Kapcsoló, portál, hálózati útvonal	A felhasználók nem tudnak csatlakozni
Munkamenet	Aktív felhasználók, hibák, késleltetés	Az alkalmazás online van, de használhatatlan.
Üzleti funkció	Sikeres munkafolyamat befejezése	A felhasználó nem tudja befejezni a szükséges feladatot.

A vállalati funkciós réteg az egyik legegyszerűbb, amit figyelmen kívül lehet hagyni.

Az infrastruktúra irányítópultok minden szervert, szolgáltatást és hálózati utat egészségesnek mutathatnak, miközben egy valós felhasználó munkafolyamata veszélybe kerül. Ezért fontos, hogy a kritikus alkalmazások az általuk támogatott működés szempontjából figyeljék egészségüket.

Hogyan kell tesztelni az alkalmazás ellenállóságát?

Egy olyan ellenálló architektúra, amely soha nem tapasztalt meg kontrollált hibát, nem tesztelt feltételezéseket tartalmaz.

Használjon tesztelést a rendszer válaszának értékelésére, amikor a kulcsfontosságú összetevők nem állnak rendelkezésre. A teszteknek tartalmazniuk kell egy alkalmazás hoszt offline állapotba helyezését, egy alkalmazás szolgáltatás leállítását, egy hálózati útvonal elvesztésének szimulálását, a kapu vagy a terheléselosztás viselkedésének ellenőrzését, a biztonsági másolatból való helyreállítást és az alkalmazás elérését egy alternatív végponton.

A tesztelési folyamatoknak túl kell mutatniuk a helyreállítás technikai aspektusain. Az IT csapatoknak felül kell vizsgálniuk, hogy az értesítések a megfelelő adminisztratív személyzethez érkeznek-e, a helyreállítási lépéseket a megfelelő sorrendben hajtják-e végre, és a felhasználók képesek-e tényleges üzleti feladatot végezni a szolgáltatások helyreállítása után.

Az operatív eljárások elengedhetetlenek egy ellenálló rendszerhez. Riasztási eszkalációs eljárások: ki kapja a riasztást? Ki jogosult a failover kezdeményezésére? Hol tárolják a helyreállítási dokumentációt és a hitelesítő adatokat? Melyik függőségnek kell először online állapotba kerülnie?

A technikai redundancia kis előnyt nyújt, ha a hozzáférés visszanyerésének folyamatait nem tesztelték.

Mi lehet az alkalmazásellenállósági ellenőrzőlista?

Mielőtt egy kritikus Windows alkalmazásra való felkészülésbe kezdenének, az IT csapatoknak képesnek kell lenniük válaszolni a következő kérdésekre:

• Mely üzleti folyamatok támaszkodnak az alkalmazásra?
• Mik a RTO és RPO értékei?
• Milyen szerverekre, adatbázisokra és külső szolgáltatásokra van szüksége?
• Hol vannak a kritikus egyedi hibapontjai?
• Elfogadhat-e egy másik alkalmazás hoszt felhasználókat, ha az egyik hoszt meghibásodik?
• A felhasználók csatlakozhatnak, ha a normál végpontjuk vagy helyük nem elérhető?
• Van elég tartalék kapacitás a csökkentett működéshez?
• Az infrastruktúra, a függőségek és a munkamenet problémái aktívan figyelemmel kísértek?
• Figyelmeztetik az adminisztrátorokat, mielőtt a fontos küszöbértékek leállássá válnának?
• Az alkalmazásadatok és a konfiguráció védettek?
• Valóban tesztelték a helyreállítást?
• Vissza lehet vonni a problémás változtatásokat?
• A helyreállítási sorrend dokumentálva van?
• A felhasználók be tudják fejezni a szükséges üzleti folyamatot a helyreállítás után?

Nem minden válaszhoz szükséges drága, magas rendelkezésre állású infrastruktúra. A megfelelő védelmi szint a leállás költségétől és működési hatásától függ.

Ami fontos, hogy a rendelkezésre állásra, redundanciára és helyreállításra vonatkozó döntéseket szándékosan hozzák meg, nem pedig feltételezik.

Hogyan segíthet a TSplus a Windows alkalmazások elérhetőségének megőrzésében?

A meglévő Windows alkalmazásokra támaszkodó szervezetek számára segíthetünk a rendelkezésre állás javításában az alkalmazások központosításával kezelt Windows szervereken, és azok felhasználókhoz való eljuttatásával RDP-kompatibilis klienseken, RemoteApp-stílusú hozzáférésen vagy HTML5 webportálon keresztül. Ez csökkenti az egyes felhasználói végpontok iránti függőséget, és nagyobb rugalmasságot biztosít az IT csapatok számára, amikor a felhasználóknak más eszközről vagy helyről kell csatlakozniuk.

TSplus Távhozzáférés támogathatja a több szerveres telepítéseket terheléselosztással és átjáró alapú hozzáféréssel. Ellenálló adatbázisokkal, tárolással, identitás szolgáltatásokkal és hálózati megoldásokkal kombinálva ez az architektúra csökkentheti a függőséget egyetlen alkalmazás hoszttól, és segíthet a kritikus Windows alkalmazásokhoz való hozzáférés fenntartásában az infrastruktúra megszakítása során.

Következtetés

Az alkalmazás ellenállása attól függ, hogy megértsük az infrastruktúra és az üzleti felhasználás közötti teljes utat. A redundancia, a megfigyelés, a biztonsági mentés, a kapacitástervezés és a helyreállítási eljárások a leghatékonyabbak, amikor világosan meghatározott alkalmazásfüggőségek és helyreállítási célok köré vannak tervezve.

A meglévő Windows alkalmazások esetében a rugalmasság gyakran abból fakad, hogy a szoftver körüli környezetet erősítjük meg, nem pedig az alkalmazást magát építjük újjá. A kulcspróba továbbra is egyszerű: amikor zavar lép fel, tudnak-e a felhasználók tovább dolgozni, vagy tudja-e az IT helyreállítani a szükséges üzleti funkciót a megállapodott helyreállítási időkereten belül?