Otpornost aplikacija: Održavanje dostupnosti Windows aplikacija

Uvod

Windows aplikacije često ovise o mnogo više od poslužitelja koji ih hostira. Baze podataka, usluge identiteta, pohrana, pristupne točke, mreže i korisnički krajnji uređaji mogu utjecati na to hoće li aplikacija ostati upotrebljiva tijekom prekida. Ovaj članak objašnjava kako IT timovi mogu procijeniti te ovisnosti, dizajnirati otpornost oko postojećih Windows aplikacija, nadzirati prave slojeve i testirati hoće li planovi oporavka zapravo očuvati poslovne funkcije na koje se korisnici oslanjaju.

Što je otpornost aplikacija?

Otpornost aplikacije je sposobnost aplikacije i infrastrukture oko nje da nastavi pružati vitalne funkcije tijekom prekida i da se predvidivo oporavi nakon kvara.

Poremećaj može biti mali ili veliki, a uzroci mogu varirati od hardverskih ili operativnih sustava, rušenja aplikacija, neuspjelih ažuriranja, prekida rada baze podataka, mrežnih prekida, neuspjeha autentifikacije, iscrpljenosti resursa, nedostupnih ovisnosti ili sigurnosnih incidenata.

Otpornna arhitektura priznaje da su neuspjesi neizbježni, a umjesto da teži sprječavanju svakog incidenta, IT organizacije nastoje ograničiti utjecaj svakog od njih i uspostaviti kontrolirane postupke oporavka kako bi održale ili obnovile uslugu.

Otpornost aplikacija je više od vremena rada poslužitelja

Uobičajena greška je koristiti dostupnost poslužitelja kao zamjenu za dostupnost aplikacije koja radi na poslužitelju.

Da bi poslovna aplikacija bila zaista dostupna, potrebno je da nekoliko komponenti bude dostupno u isto vrijeme:

Infrastruktura → Operacijski sustav → Aplikacija → Ovisnosti → Putanja pristupa → Korisnička sesija → Poslovni proces

Problem s bilo kojim elementom u ovom lancu može rezultirati time da aplikacija postane učinkovito nedostupna.

Na primjer, poslužitelj aplikacija može biti zdrav dok je njegova baza podataka nedostupna. Objavljena aplikacija može ispravno raditi, ali kvar na pristupniku onemogućava udaljenim zaposlenicima pristup. Korisnici čak mogu uspješno pokrenuti aplikaciju, ali im može biti onemogućeno dovršavanje transakcije jer je licenca, datoteka ili usluga u pozadini nedostupna.

Otpornost aplikacije stoga treba mjeriti na temelju sposobnosti korisnika da izvrši potrebni poslovni zadatak, a ne na temelju toga može li poslužitelj odgovoriti na provjeru dostupnosti ili zdravlja.

Zašto je otpornost aplikacija drugačija za Windows aplikacije?

Moderne prakse otpornosti sve više su usmjerene na aplikacije temeljene na oblaku, kontejnere, mikroservise i automatiziranu orkestraciju. Iako su to vrijedni pristupi, nisu uvijek primjenjivi na svaku organizaciju.

Mnoge organizacije imaju naslijeđene Windows aplikacije za poslovanje koje su razvijene prije nego što su arhitekture temeljene na oblaku postale uobičajene. ERP softver, aplikacije za računovodstvo, aplikacije za proizvodnju, aplikacije za zdravstvenu skrb, inženjerske aplikacije i interno razvijene aplikacije mogu biti od ključne važnosti za poslovanje organizacije.

Rekonstrukcija ovih aplikacija kao mikroservisa može biti izuzetno skupa, tehnički izazovna ili čak potpuno neizvediva ako organizacija ne kontrolira izvorni kod.

U takvim slučajevima, može postojati značajna vrijednost u jačanju operacija oko aplikacije, umjesto da se pokušava učiniti samu aplikaciju otpornijom. Objavljivanje aplikacija može biti dio ovog pristupa zadržavanjem postojećih Windows aplikacija na centraliziranoj infrastrukturi dok se mijenja način na koji im korisnici pristupaju. To može uključivati promjene u infrastrukturi koja hosta aplikaciju, kao što su uklanjanje infrastrukturnih ograničenja, stvaranje redundantnih hostova aplikacija, omogućavanje alternativnih metoda pristupa i implementacija responzivnijih postupaka oporavka za host aplikacije.

U kojem slučaju bi dostupnost Windows aplikacije mogla zakazati?

Izgradnja otpornosti aplikacija počinje otkrivanjem komponenti koje su potrebne za uspješno isporučivanje aplikacije od njihovih domaćina do korisnika. Ovaj proces ističe potencijalne točke neuspjeha koje mogu srušiti cijelu aplikaciju.

Aplikacijski poslužitelji

Aplikacija koja radi na jednom Windows poslužitelju ima jasno jedinstveno mjesto kvara.

Problemi s hardverom, ažuriranja sustava Windows, oštećenje operativnog sustava, iscrpljenost resursa ili neuspjeh aplikacije mogu ometati svakog korisnika koji ovisi o toj mašini. Ako su zahtjevi za dostupnost potrebni, može se postaviti više domaćina aplikacija kako bi se smanjila ovisnost o bilo kojoj jednoj mašini i osigurala kapacitet kada server postane nedostupan.

Baze podataka, pohrana i druge ovisnosti

Mnoge Windows aplikacije ovise o uslugama vanjskim za domaćina aplikacije. Ove usluge mogu uključivati:

• SQL baze podataka
• dijeljeni datoteke
• licencni poslužitelji
• Active Directory
• Sustav imena domena (DNS)
• certifikati
• APIs
• posrednik
• mrežno pohranjivanje
• infrastruktura ispisa

Uvođenje drugog aplikacijskog poslužitelja pruža minimalnu otpornost ako dijele zajedničku bazu podataka ili ovisnost o pohrani koja nije dostupna. Postaje očito da mapping ovisnosti treba proširiti izvan vidljive aplikacijske infrastrukture.

Autentifikacija i identitet

Korisnici ne mogu pristupiti zdravoj aplikaciji ako potrebna infrastruktura za autentifikaciju nije dostupna.

IT timovi trebaju identificirati usluge identiteta na kojima se oslanjaju njihove kritične aplikacije i osigurati da imaju planove za prebacivanje kada su ti resursi nedostupni. Active Directory, cloud identitetske platforme, usluge višefaktorske autentifikacije (MFA) i autentifikacijska vrata mogu se smatrati pouzdanim za pružanje lanca dostupnosti za aplikaciju.

Mrežne i udaljene pristupne staze

Za centralizirane Windows aplikacije, povezanost između korisnika i okruženja aplikacije predstavlja još jednu moguću domenu neuspjeha.

Zamislimo cijeli lanac:

Korisnički uređaj → Internet ili LAN → pristupnik → domaćin aplikacije → pozadinske usluge

Poremećaj bilo gdje u ovom lancu može spriječiti korisnike da obavljaju svoje poslove čak i ako aplikacija radi ispravno. Osobito je relevantno za distribuirane organizacije gdje aplikacija može biti aktivna u podatkovnom centru, ali nedostupna korisnicima na drugoj lokaciji.

Krajnje točke

Otpornost aplikacije ne zahtijeva nužno da korisničko normalno radno mjesto bude dostupno.

Nudeći ovlaštenim korisnicima sredstva za pristup centralno hostiranim aplikacijama s alternativnog uređaja ili putem preglednika može osigurati pristup, ako prijenosno računalo postane nedostupno, ured postane nedostupan ili zaposlenici trebaju raditi s druge lokacije.

Arhitektura isporuke aplikacija može biti komponenta šire strategije kontinuiteta poslovanja.

Koji je proces izgradnje otpornosti aplikacija za Windows aplikacije?

Nijedna pojedinačna tehnologija ne čini aplikaciju otpornom. IT timovi umjesto toga moraju smanjiti broj kvarova koji mogu potpuno onemogućiti funkciju i pripremiti mehanizme za kontrolirano oporavak za one koji ostanu.

1. Identificirajte kritične aplikacije i poslovne procese

Nisu sve aplikacije podložne istoj razini zaštite. Započnite određivanjem koje aplikacije podržavaju osnovne operacije, na kojima korisnici ovise i koja je njihova tolerancija na prekide rada.

Dva cilja oporavka prevode poslovne zahtjeve u tehničke specifikacije. NIST-ovo vodstvo za planiranje nepredviđenih situacija definira Cilj vremena oporavka (RTO) i Cilj točke oporavka (RPO) kao ključne parametre za određivanje zahtjeva za oporavak:

• Cilj vremena oporavka (RTO): trajanje prihvatljivog vremena zastoja prije nego što se usluga obnovi.
• Cilj točke oporavka (RPO): interval prihvatljivog gubitka podataka, mjeren u vremenu.

Aplikacija koja se intenzivno koristi za obradu narudžbi može imati RTO od minuta, dok aplikacija za financijsko izvještavanje koja se pokreće jednom tjedno može priuštiti dane zastoja.

RTO i RPO definiraju vrstu zaštite potrebnu za aplikaciju: trenutni prebacivanje, brzo uspostavljanje usluga ili samo dokumentirani postupak oporavka.

2. Mapirajte cijeli lanac ovisnosti aplikacije

Zabilježite sve što mora biti prisutno kako bi aplikacija obavljala svoj posao.

Ne stajte na izvršnoj datoteci ili Windows poslužitelju. Ne zaboravite baze podataka, pohranu, autentifikaciju, DNS, umrežavanje, certifikate, sustave licenciranja, pristupne točke i vanjske usluge.

Za svaki, pitajte:

Što se događa s aplikacijom ako ovo nestane?

Ova vježba će otkriti skrivene jedinstvene točke neuspjeha i uspostaviti redoslijed oporavka. Obnavljanje domaćina aplikacije prvo ne pomaže mnogo ako njezina baza podataka, usluga identiteta ili pohrana još nisu dostupni.

3. Uklonite kritične jedinstvene točke neuspjeha

Jednom kada je stablo ovisnosti uspostavljeno, odredite koji se sastavni dijelovi trebaju učiniti suvišnima, na temelju poslovne važnosti i ciljeva oporavka.

U slučaju isporuke Windows aplikacija, to bi moglo uključivati implementaciju nekoliko poslužitelja aplikacija umjesto oslanjanja na mogućnosti jednog domaćina. S slojem za ravnotežu opterećenja, sesije se mogu rasporediti među instancama aplikacija tijekom normalnog rada. U slučaju kvara domaćina, dolazne veze mogu se usmjeriti na zdrave instance poslužitelja aplikacija.

Planiranje redundancije treba biti informirano analizom ovisnosti, međutim. Više aplikacijskih poslužitelja koji pristupaju jednoj kritičnoj bazi podataka, mrežnom prolazu ili sloju pohrane i dalje predstavljaju jedinstvenu točku neuspjeha.

Dizajn visoke dostupnosti stoga mora uzeti u obzir uslugu aplikacije kao integriranu cjelinu. Za Windows Server okruženja koja zahtijevaju redundanciju na razini infrastrukture, Dokumentacija o klasteriranju za oporavak Microsofta daje daljnje smjernice o topologijama visoke dostupnosti i oporavka od katastrofa.

4. Odvojite aplikacije od pojedinačnih krajnjih točaka

Instalacija kritične aplikacije izravno na radnoj stanici svakog zaposlenika može stvoriti drugačiji oblik problema s otpornosti. Ako korisnici izgube pristup svom redovnom računalu, mogli bi također izgubiti pristup aplikacijama koje su im potrebne za nastavak rada.

Centralizacija aplikacija na upravljanim Windows poslužiteljima i predstavljanje sučelja aplikacije korisnicima eliminira ovaj rizik. Podaci i stanje aplikacije pohranjuju se na upravljanom Windows hostu i pristupaju im ovlašteni krajnji uređaji.

Time to time, we make the application available to users even if they change devices or locations. While centralizing applications doesn't eliminate infrastructure issues, it helps to move it into an environment where it can be controlled by IT.

Pružite više od jednog praktičnog načina pristupa

Otpornost se također može postići izbjegavanjem nepotrebne ovisnosti o jednom tipu krajnje točke ili metodi povezivanja.

Ovisno o arhitekturi isporuke aplikacija, korisnici mogu koristiti različite udaljeni pristup metode, uključujući RDP-kompatibilnog klijenta, namjenski pokretač aplikacija, web portal ili HTML5 pregledničku sesiju.

Alternativne metode povezivanja ne bi se trebale miješati s redundancijom infrastrukture. Ako se svi oslanjaju na isti neispravni poslužitelj, aplikacija i dalje nije dostupna.

Oni pružaju otpornost na pristup kada prekid utječe na normalni uređaj korisnika, instaliranog klijenta ili lokaciju, a ne na samu uslugu aplikacije.

6. Praćenje prije nego što degradacija postane prekid rada

Otpornost aplikacija nije samo o oporavku, već pravovremeno otkrivanje može izbjeći degradaciju u prekid rada.

Pokazatelji korisni u Windows aplikacijskim okruženjima su iskorištenje CPU-a, pritisak na memoriju, kapacitet diska i I/O, iskorištenje mreže, aktivne sesije, proces aplikacije, vrijeme odgovora, neuspjela veza i dostupnost ovisnih usluga.

Praćenje trendova je ključno, jer server koji se neprekidno približava svojim granicama može ostati online dok se iskustvo korisnika postupno pogoršava.

Upozorenja na prag omogućuju administratorima da istraže prekursore incidenta prije nego što korisnici izgube pristup.

7. Planiranje kapaciteta i prebacivanje na rezervu

Aplikacija koja preživljava kvarove na razini hardvera, ali je potpuno nesposobna za rad pod povećanim zahtjevima, nije zaista otporna na kvarove bilo koje vrste.

Planiranje kapaciteta mora uzeti u obzir ne samo svakodnevne obrasce korištenja, već i vrhunce zbog sezonskih zahtjeva, promjene smjena, rasta ili zahtjeva za hosting drugih aplikacija.

Osobito u okruženjima višestrukog hostinga, gubitak jednog poslužitelja mora se uzeti u obzir osiguravanjem da ostali hosting čvorovi imaju rezervni kapacitet za smještaj bilo kojih procesa koji bi inače bili izvršeni na neuspjelom čvoru.

Inače, postupci prebacivanja mogu jednostavno pretvoriti izolirani incident u široki problem s performansama sustava.

8. Zaštita podataka i konfiguracije

Zamjenski Windows poslužitelj je od male koristi ako IT ne može obnoviti komponente potrebne za rad aplikacije.

To bi to moglo značiti da postupci sigurnosne kopije trebaju uključivati podatke o aplikacijama, baze podataka, konfiguracijske datoteke, certifikate, postavke aplikacija, korisničke profile, konfiguraciju infrastrukture, skripte i informacije o licencama.

Strategija će varirati ovisno o cilju vremena oporavka (RTO) i cilju točke oporavka (RPO) aplikacije.

Prije svega, osigurajte da uspješna sigurnosna kopija ne znači uspješno vraćanje. IT timovi trebaju testirati je li moguće obnoviti cijelu uslugu aplikacije iz zaštićenih podataka i konfiguracije.

Smanjite radijus eksplozije promjena

Nije uvijek riječ o nepredviđenoj katastrofi koja uzrokuje prekide. Oni također mogu biti uzrokovani implementiranim poboljšanjima. Tako, Windows zakrpe, nadogradnje aplikacija i upravljačkih programa, promjene sigurnosne politike i konfiguracije također mogu imati negativan utjecaj na dostupnost aplikacije. Preporučuje se izbjegavati slične promjene na svim produkcijskim hostovima u isto vrijeme, ako je to moguće.

U višeserverskoj postavci moguće je provoditi promjene poboljšanja u fazama, čime se administratoru omogućuje da osigura da sve ispravno funkcionira. Mogućnost vraćanja izvršenih promjena također je bitna.

Stoga, prilikom dizajniranja postupaka za nepredviđene situacije, trebali bi se razmotriti i opcije vraćanja. Proces bi trebao biti pravilno dokumentiran, a osoblje bi trebalo znati što učiniti ako promjena ne uspije, umjesto da se jednostavno prepusti njihovoj diskreciji.

10. Dizajn za elegantno degradiranje

Otpornost nije samo održavanje 100% normalnih funkcija u radu u svakom trenutku.

U nekim slučajevima, održavanje operacija za ključne korisnike ili aplikacije može biti važnije od održavanja svih usluga dostupnim svim korisnicima. Prioriteti se mogu uspostaviti prije nego što se incident dogodi od strane IT timova.

Ako postoji dostupna kapacitet koja se može iskoristiti, možda bi imalo smisla prvo je dodijeliti proizvodnji, korisničkoj službi, financijama ili drugim funkcijama.

To je graciozno degradiranje: zadržavanje sposobnosti izvođenja funkcija koje generiraju najveću poslovnu vrijednost, umjesto da se dopusti da neuspjeh manje kritičnih elemenata uzrokuje pad cijelog sustava.

Kako bi IT timovi trebali pratiti otpornost aplikacija?

Praćenje pojedinačnih poslužitelja može biti korisno, ali praćenje otpornosti treba odražavati ukupnu uslugu aplikacije kako je percipiraju korisnici.

Realističan model sastoji se od nekoliko slojeva:

Sloj	Što pratiti	Primjer neuspjeha
Domaćin	CPU, RAM, disk, dostupnost OS-a	Server je preopterećen ili izvan mreže
Aplikacija	Status procesa i usluge	Rušenje aplikacije
Ovisnost	Baza podataka, DNS, identitet, pohrana	Aplikacija se pokreće, ali ne može raditi.
Pristup	Gateway, portal, mrežna staza	Korisnici se ne mogu povezati
Sesija	Aktivni korisnici, neuspjesi, latencija	Aplikacija je online, ali neupotrebljiva
Poslovna funkcija	Uspješno završavanje radnog toka	Korisnik ne može dovršiti traženi zadatak

Sloj poslovne funkcije jedan je od najjednostavnijih za zanemariti.

Nadzorne ploče infrastrukture mogu prikazivati sve poslužitelje, usluge i mrežne putanje kao zdrave, dok je radni tijek stvarnog korisnika ugrožen. Stoga je važno da kritične aplikacije prate svoje zdravlje iz perspektive operacije koju su dizajnirane podržavati.

Kako bi se trebala testirati otpornost aplikacije?

Arhitektura otpornosti koja nikada nije doživjela kontrolirani neuspjeh sadrži neprovjerene pretpostavke.

Koristite testiranje za procjenu odgovora sustava kada ključne komponente postanu nedostupne. Testovi bi trebali uključivati isključivanje hosta aplikacije, zaustavljanje usluge aplikacije, simulaciju gubitka mrežne rute, provjeru ponašanja pristupne točke ili ravnoteže opterećenja, vraćanje iz sigurnosne kopije i pristup aplikaciji s alternativne točke.

Testni procesi trebali bi se proširiti izvan tehničkih aspekata oporavka. IT timovi trebali bi pregledati šalju li se upozorenja pravim administrativnim osobama, jesu li koraci oporavka izvedeni u ispravnom redoslijedu i mogu li korisnici izvršiti stvarni poslovni zadatak nakon što su usluge obnovljene.

Operativne procedure su sastavni dio otpornog sustava. Postupci eskalacije upozorenja: tko prima upozorenje? Tko ima ovlast pokrenuti prebacivanje? Gdje su pohranjeni dokumentacija za oporavak i vjerodajnice? Koja ovisnost treba prvo biti dostupna?

Tehnička redundancija pruža malo koristi ako procesi za ponovno uspostavljanje pristupa nisu testirani.

Što može biti popis provjere otpornosti aplikacije?

Prije nego što započnu s kritičnom Windows aplikacijom otpornom na greške, IT timovi trebaju biti u mogućnosti odgovoriti na sljedeća pitanja:

• Koji poslovni procesi se oslanjaju na aplikaciju?
• Koji su njegovi RTO i RPO?
• Koje poslužitelje, baze podataka i vanjske usluge zahtijeva?
• Gdje su njegovi kritični pojedinačni točke neuspjeha?
• Može li drugi host aplikacije prihvatiti korisnike ako jedan host ne uspije?
• Mogu li se korisnici povezati ako njihov normalni krajnji uređaj ili lokacija nisu dostupni?
• Ima li dovoljno slobodnog kapaciteta za degradirano djelovanje?
• Jesu li problemi s infrastrukturom, ovisnostima i sesijama aktivno praćeni?
• Jesu li administratori obaviješteni prije nego što važni pragovi postanu prekidi?
• Jesu li podaci aplikacije i konfiguracija zaštićeni?
• Je li obnova zapravo testirana?
• Mogu li se problematične promjene vratiti?
• Je li sekvenca oporavka dokumentirana?
• Mogu li korisnici dovršiti potrebni poslovni proces nakon oporavka?

Ne zahtijevaju svi odgovori skupu infrastrukturu visoke dostupnosti. Pravi nivo zaštite ovisi o troškovima i operativnom utjecaju zastoja.

Važno je da se odluke o dostupnosti, redundanciji i oporavku donose namjerno, a ne pretpostavljaju.

Kako može TSplus pomoći u održavanju dostupnosti Windows aplikacija?

Za organizacije koje se oslanjaju na postojeće Windows aplikacije, možemo pomoći poboljšati dostupnost centralizacijom aplikacija na upravljanim Windows poslužiteljima i isporukom korisnicima putem RDP-kompatibilnih klijenata, pristupa u stilu RemoteApp ili HTML5 web portala. To smanjuje ovisnost o pojedinačnim korisničkim krajnjim točkama i daje IT timovima veću fleksibilnost kada korisnici trebaju povezati s drugog uređaja ili lokacije.

TSplus Remote Access može također podržavati višeserijske implementacije s ravnotežom opterećenja i pristupom temeljenim na pristupnim točkama. Kada se kombinira s otpornim bazama podataka, pohranom, uslugama identiteta i umrežavanjem, ova arhitektura može smanjiti ovisnost o jednom domaćinu aplikacije i pomoći u održavanju pristupa kritičnim Windows aplikacijama tijekom prekida infrastrukture.

Zaključak

Otpornost aplikacije ovisi o razumijevanju cjelokupnog puta između infrastrukture i poslovne upotrebe. Redundancija, praćenje, sigurnosne kopije, planiranje kapaciteta i postupci oporavka najefikasniji su kada su osmišljeni oko jasno definiranih ovisnosti aplikacija i ciljeva oporavka.

Za postojeće Windows aplikacije, otpornost često dolazi iz jačanja okruženja oko softvera umjesto ponovne izgradnje same aplikacije. Ključni test ostaje jednostavan: kada dođe do prekida, mogu li korisnici nastaviti raditi ili može li IT obnoviti potrebnu poslovnu funkciju unutar dogovorenog vremenskog okvira oporavka?