Applikationsresiliens: Hold Windows-apps tilgængelige

Introduktion

Windows-applikationer afhænger ofte af langt mere end den server, der hoster dem. Databaser, identitetstjenester, lagring, gateways, netværk og brugerendepunkter kan alle påvirke, om en applikation forbliver brugbar under forstyrrelser. Denne artikel forklarer, hvordan IT-teams kan vurdere disse afhængigheder, designe modstandsdygtighed omkring eksisterende Windows-applikationer, overvåge de rigtige lag og teste, om genopretningsplaner faktisk bevarer de forretningsfunktioner, som brugerne er afhængige af.

Hvad er applikationsresiliens?

Applikationsresiliens er kapaciteten for en applikation og den infrastruktur, der omgiver den, til fortsat at levere vitale funktioner under en forstyrrelse og til at komme sig forudsigeligt efter en fejl.

Forstyrrelsen kan være lille eller stor, og årsagerne kan variere fra hardware- eller operativsystemfejl, applikationsnedbrud, mislykkede opdateringer, databaseudfald, netværksafbrydelser, autentifikationsfejl, ressourceudtømning, utilgængelige afhængigheder eller sikkerhedshændelser.

En modstandsdygtig arkitektur anerkender, at fejl er uundgåelige, og i stedet for at sigte mod at forhindre hver enkelt hændelse, søger IT-organisationer at begrænse virkningen af hver enkelt og etablere kontrollerede genopretningsprocedurer for at opretholde eller genskabe tjenesten.

Applikationsresiliens er mere end serverdriftstid

En almindelig fejl er at bruge tilgængeligheden af en server som en proxy for tilgængeligheden af applikationen, der kører på serveren.

For at en forretningsapplikation kan være virkelig tilgængelig, skal en række komponenter være tilgængelige på samme tid:

Infrastruktur → Operativsystem → Applikation → Afhængigheder → Adgangssti → Brugersession → Forretningsproces

Et problem med et hvilket som helst element i denne kæde kan resultere i, at applikationen effektivt bliver utilgængelig.

For eksempel kan en applikationsserver være sund, mens dens database er utilgængelig. En offentliggjort applikation kan fungere korrekt, men en gateway-fejl gør det umuligt for fjernmedarbejdere at få adgang til den. Brugere kan endda med succes starte applikationen, men blive forhindret i at fuldføre en transaktion, fordi en licens, fil eller backend-tjeneste ikke er tilgængelig.

Applikationsresiliens bør derfor måles ud fra brugerens evne til at udføre den nødvendige forretningopgave, snarere end om en server er i stand til at svare på en tilgængeligheds- eller sundhedstjek.

Hvorfor er applikationsresiliens anderledes for Windows-applikationer?

Moderne resilienspraksisser er i stigende grad fokuseret på cloud-native applikationer, containere, mikrotjenester og automatiseret orkestrering. Selvom disse er værdifulde tilgange, er de ikke altid anvendelige for hver organisation.

Mange organisationer har ældre Windows-forretningsapplikationer, som blev udviklet, før cloud-native arkitekturer blev almindelige. ERP-software, regnskabsapplikationer, produktionsapplikationer, sundhedsapplikationer, ingeniørapplikationer og internt udviklede applikationer kan alle være kritiske for en organisations drift.

At omstrukturere disse applikationer som mikrotjenester kan være ekstremt dyrt, teknisk udfordrende eller endda helt uarbejdsdygtigt, hvis organisationen ikke har kontrol over kildekoden.

I sådanne tilfælde kan der være betydelig værdi i at gøre operationerne omkring applikationen mere modstandsdygtige, snarere end at forsøge at gøre selve applikationen mere modstandsdygtig. Applikationsudgivelse kan være en del af denne tilgang ved at holde eksisterende Windows-applikationer på centraliseret infrastruktur, mens man ændrer, hvordan brugerne får adgang til dem. Dette kan inkludere ændringer i infrastrukturen, der hoster applikationen, såsom at fjerne infrastrukturbegrænsninger, oprette redundante applikationsværter, muliggøre alternative adgangsmetoder og implementere mere responsive genoprettelsesprocedurer for applikationsværten.

I hvilke tilfælde kan tilgængeligheden af en Windows-applikation fejle?

At opbygge applikationsresiliens begynder med at opdage de komponenter, der er nødvendige for at levere en applikation fra deres værter til brugerne med succes. Denne proces fremhæver potentielle fejlpunkter, der kan nedlægge en hel applikation.

Applikationsværter

En applikation, der kører på en enkelt Windows-server, har et klart enkelt fejlpunk.

Hardwareproblemer, Windows-opdateringer, korruption af operativsystemet, ressourceudtømning eller applikationsfejl kan forstyrre enhver bruger, der er afhængig af den maskine. Hvis tilgængelighedskravene kræver det, kan flere applikationsværter implementeres for at reducere afhængigheden af en enkelt maskine og give kapacitet, når en server bliver utilgængelig.

Databaser, opbevaring og andre afhængigheder

Mange Windows-applikationer er afhængige af tjenester, der er eksterne for applikationsværten. Disse tjenester kan inkludere:

• SQL-databaser
• filandele
• licenseringsservere
• Active Directory
• Domænenavnesystem (DNS)
• certifikater
• API'er
• middleware
• netværkslagring
• printinfrastruktur

At introducere en anden applikationsserver giver minimal modstandsdygtighed, hvis de deler en fælles database eller lagringsafhængighed, som ikke er tilgængelig. Det bliver tydeligt, at afhængighedskortlægning skal strække sig ud over den synlige applikationsinfrastruktur.

Godkendelse og identitet

Brugere kan ikke få adgang til en sund applikation, hvis den nødvendige autentifikationsinfrastruktur ikke er tilgængelig.

IT-teams skal identificere de identitetstjenester, som deres kritiske applikationer er afhængige af, og sikre, at de har failover-planer på plads for når disse ressourcer er utilgængelige. Active Directory, cloud identitetsplatforme, multifaktorautentifikation (MFA) tjenester og autentificeringsgateways kan alle påregnes at levere en kæde af tilgængelighed for en applikation.

Netværk og Remote Access Stier

For centraliserede Windows-applikationer repræsenterer forbindelsen mellem brugere og applikationsmiljøet et andet muligt fejldomæne.

Lad os forestille os den komplette kæde:

Brugerens enhed → Internet eller LAN → gateway → applikationsvært → backend-tjenester

En nedbrud hvor som helst i denne kæde kan forhindre brugerne i at udføre deres arbejde, selvom applikationen kører sundt. Især relevant for distribuerede organisationer, hvor applikationen muligvis kører i datacentret, men er utilgængelig for brugere på en anden placering.

Slutpunkter

Applikationsresiliens kræver ikke nødvendigvis, at en brugers normale arbejdsstation er tilgængelig.

At tilbyde autoriserede brugere midlerne til at få adgang til centralt hostede applikationer fra en alternativ enhed eller via en browser kan sikre adgang, hvis en bærbar computer bliver utilgængelig, et kontor bliver utilgængeligt, eller medarbejdere har brug for at arbejde fra en anden placering.

Applikationsleveringsarkitektur kan være en del af en bredere forretningskontinuitetsstrategi.

Hvad er processen for at opbygge applikationsresiliens for Windows-apps?

Ingen enkelt teknologi gør applikationen modstandsdygtig. IT-teams skal i stedet reducere antallet af fejl, der kan nedlægge en fuld funktion, og forberede sig på kontrollerede genopretningsmekanismer for dem, der forbliver.

1. Identificer kritiske applikationer og forretningsprocesser

Ikke alle applikationer kræver den samme grad af beskyttelse. Begynd med at bestemme, hvilke applikationer der understøtter primære operationer, hvilke brugere der er afhængige af dem, og deres tolerance over for nedetid.

To recovery objectives oversætte forretningskrav til tekniske specifikationer. NIST's beredskabsplanlægningsvejledning definerer Recovery Time Objective (RTO) og Recovery Point Objective (RPO) som nøgleparametre for at bestemme genopretningskrav:

• Genopretningstidsmål (RTO): en varighed af acceptabel nedetid, før tjenesten genoprettes.
• Recovery Point Objective (RPO): et interval for acceptabel datatab, målt i tid.

En applikation, der bruges intensivt til at behandle ordrer, kan have en RTO på minutter, mens en finansiel rapporteringsapplikation, der kører en gang om ugen, kan tåle dages nedetid.

RTO og RPO definerer den type beskyttelse, der er nødvendig for en applikation: øjeblikkelig failover, hurtig genoprettelse af tjenester eller blot en dokumenteret genoprettelsesprocedure.

2. Kortlæg hele applikationens afhængighedskæde

Dokumentér alt, hvad der skal være der for, at applikationen kan udføre sit arbejde.

Stop ikke ved den eksekverbare fil eller Windows-serveren. Glem ikke databaser, lagring, godkendelse, DNS, netværk, certifikater, licenssystemer, gateways og eksterne tjenester.

For hver, spørg:

Hvad sker der med applikationen, hvis dette forsvinder?

Denne øvelse vil afdække skjulte enkeltpunkter af fejl og etablere genoprettelsesrækkefølge. At gendanne en applikationsvært først hjælper ikke meget, hvis dens database, identitetstjeneste eller lager endnu ikke er tilgængeligt.

3. Fjern kritiske enkeltpunkter for fejl

Når afhængighedstræet er etableret, skal du bestemme, hvilke komponenter der skal gøres overflødige, baseret på forretningsmæssig betydning og genopretningsmål.

I tilfælde af levering af Windows-applikationer kan dette involvere implementering af flere applikationsservere i stedet for at stole på kapaciteterne fra en enkelt vært. Med et load balancing-lag kan sessioner fordeles over applikationsinstanser under normale operationer. I tilfælde af en værtfejl kan indkommende forbindelser dirigeres til sunde applikationsserverinstanser.

Redundansplanlægning bør informeres af afhængighedsanalysen. Flere applikationsservere, der tilgår en enkelt kritisk database, netværksgateway eller lagringslag, præsenterer stadig et enkelt fejlpunk.

Høj tilgængelighedsdesign skal derfor betragte applikationstjenesten som en integreret enhed. For Windows Server-miljøer, der kræver redundans på infrastruktur-niveau, Microsofts Failover Clustering dokumentation giver yderligere vejledning om højtilgængelighed og katastrofegenopretnings-topologier.

4. Adskil applikationer fra individuelle slutpunkter

At installere en kritisk applikation direkte på hver medarbejders arbejdsstation kan skabe en anden form for modstandsdygtighedsproblem. Hvis brugerne mister adgangen til deres almindelige computer, kan de også miste adgangen til de applikationer, de har brug for for at fortsætte arbejdet.

Centralisering af applikationer på administrerede Windows-værter og præsenterer applikationsgrænsefladen for brugerne fjerner denne risiko. Dataene og applikationens tilstand gemmes på den administrerede Windows-vært og tilgås af autoriserede slutpunkter.

Ved at gøre dette gør vi applikationen tilgængelig for brugerne, selvom de skifter enheder eller placeringer. Selvom centralisering af applikationer ikke fjerner infrastrukturproblemer, hjælper det med at flytte det til et miljø, hvor det kan kontrolleres af IT.

5. Tilbyde mere end én praktisk adgangsmetode

Modstandsdygtighed kan også opnås ved at undgå unødvendig afhængighed af en enkelt endpoint-type eller forbindelsesmetode.

Afhængigt af applikationsleveringsarkitekturen kan brugere bruge forskellige fjernadgang metoder, herunder en RDP-kompatibel klient, dedikeret applikationsstarter, webportal eller HTML5-browser session.

Alternative forbindelsesmetoder bør ikke forveksles med infrastrukturredundans. Hvis alle er afhængige af den samme fejlede server, er applikationen stadig utilgængelig.

De giver adgangsresiliens, når forstyrrelser påvirker en brugers normale enhed, installerede klient eller placering snarere end selve applikationstjenesten.

6. Overvågning før nedbrud bliver en afbrydelse

Applikationsresiliens handler ikke kun om genopretning, men tidlig nok opdagelse kan undgå forringelse til en nedetid.

Indikatorer, der er nyttige i Windows-applikationsmiljøer, er CPU-udnyttelse, hukommelsesbelastning, diskkapacitet og I/O, netværksudnyttelse, aktive sessioner, applikationsproces, svartid, mislykket forbindelse og tilgængelighed af afhængige tjenester.

Trendovervågning er afgørende, da en server, der gentagne gange nærmer sig sine grænser, stadig kan være online, mens brugeroplevelsen gradvist forringes.

Tærskelalarmer gør det muligt for administratorer at undersøge forløberne til en hændelse, før brugerne mister adgangen.

7. Plan for kapacitetsstigninger og failover

En applikation, der overlever hardwarefejl, men som bliver helt ude af stand til at fungere under øgede krav, er ikke virkelig modstandsdygtig over for fejl af nogen art.

Planlægningen af kapacitet skal tage højde for ikke kun hverdagens brugsmønstre, men også tage højde for spidser på grund af sæsonbestemte krav, skiftændringer, vækst eller hostingkrav til andre applikationer.

Især i multi-server hostingmiljøer skal tabet af en enkelt server tages i betragtning ved at sikre, at andre hostingnoder har ledig kapacitet til at rumme eventuelle processer, der ellers ville blive udført på den fejlede node.

Ellers kan failover-procedurer simpelthen forvandle en isoleret hændelse til et bredt systemydelsesproblem.

8. Beskyt data og konfiguration

En erstatnings Windows-server er af ringe nytte, hvis IT ikke kan gendanne de komponenter, der er nødvendige for at få applikationen til at fungere.

Dette kan betyde, at backupprocedurer skal inkludere applikationsdata, databaser, konfigurationsfiler, certifikater, applikationsindstillinger, brugerprofiler, infrastrukturkonfiguration, scripts og licensoplysninger.

Strategien vil variere afhængigt af applikationens Recovery Time Objective (RTO) og Recovery Point Objective (RPO)

Frem for alt, skal du sikre dig, at en vellykket backup ikke er lig med en vellykket gendannelse. IT-teams bør teste, at det er muligt at gendanne hele applikationstjenesten fra beskyttede data og konfiguration.

9. Reducer blastradiusen af ændringer

Det er ikke altid en uforudset katastrofe, der forårsager forstyrrelser. De kan også være forårsaget af implementerede forbedringer. Således kan Windows-opdateringer, opgraderinger af applikationer og drivere, ændringer i sikkerhedspolitik og konfiguration også have en negativ indvirkning på applikationens tilgængelighed. Det anbefales at undgå at foretage lignende ændringer på alle produktionsværter på samme tid, hvis det er muligt.

I en multi-server opsætning er det muligt at udføre forbedringsændringer i faser, hvilket giver administratoren mulighed for at sikre, at alt fungerer korrekt. Muligheden for at rulle ændringerne tilbage er også essentiel.

Så når man designer beredskabsprocedurer, bør tilbageføringsmulighederne også overvejes. Processen bør være korrekt dokumenteret, og personalet bør vide, hvad de skal gøre, hvis en ændring mislykkes, i stedet for blot at overlade det til deres skøn.

10. Design for Graceful Degradation

Modstandsdygtighed handler ikke om at holde 100% af normale funktioner kørende hele tiden.

I nogle tilfælde kan det være vigtigere at opretholde driften for nøglebrugere eller applikationer end at holde alle tjenester tilgængelige for alle brugere. Prioriteter kan fastlægges, før en hændelse opstår, af IT-teams.

Hvis der er kapacitet tilgængelig, som kan bruges, kan det give mening at tildele den først til produktion, kundeservice, økonomi eller andre funktioner.

Det er en elegant nedbrydning: at bevare evnen til at køre de funktioner, der genererer den største forretningsværdi, i stedet for at lade fejlen i mindre kritiske elementer få hele systemet til at gå ned.

Hvordan skal IT-teams overvåge applikationsresiliens?

Overvågning af individuelle servere kan være nyttigt, men resiliensovervågning bør afspejle den samlede applikationstjeneste, som brugerne oplever.

Et realistisk model består af flere lag:

Lag	Hvad skal overvåges	Eksempel på fejl
Vært	CPU, RAM, disk, OS tilgængelighed	Server overbelastet eller offline
Applikation	Proces- og servicestatus	Applikationen går ned
Afhængighed	Database, DNS, identitet, opbevaring	Applikationen starter, men kan ikke fungere
Adgang	Gateway, portal, netværkssti	Brugere kan ikke oprette forbindelse
Session	Aktive brugere, fejl, latenstid	Applikationen er online, men ubrugelig
Forretningsfunktion	Succesfuld arbejdsprocesafslutning	Brugeren kan ikke fuldføre den krævede opgave

Forretningsfunktionslaget er en af de simpleste at overse.

Infrastruktur dashboards kan vise alle servere, tjenester og netværksveje som sunde, mens en rigtig brugers arbejdsgang er kompromitteret. Det er derfor vigtigt for kritiske applikationer at overvåge deres sundhed fra det perspektiv, de er designet til at støtte.

Hvordan skal applikationsresiliens testes?

En resiliensarkitektur, der aldrig har oplevet en kontrolleret fejl, indeholder uafprøvede antagelser.

Brug testning til at evaluere systemets respons, når nøglekomponenter bliver utilgængelige. Testene bør inkludere at tage en applikationsvært offline, stoppe en applikationstjeneste, simulere tab af en netværksrute, verificere gateway- eller load-balanceringsadfærd, gendanne fra backup og få adgang til applikationen fra et alternativt endpoint.

Testprocesser bør strække sig ud over de tekniske aspekter af genopretning. IT-teams bør gennemgå, om advarsler sendes til det korrekte administrative personale, om genopretningstrinene udføres i den rigtige rækkefølge, og om brugerne er i stand til at udføre en faktisk forretningopgave, efter at tjenesterne er blevet gendannet.

Driftsprocedurer er en integreret del af et robust system. Alarm eskalationsprocedurer: hvem modtager alarmen? Hvem har myndighed til at igangsætte failover? Hvor opbevares genopretningsdokumentation og legitimationsoplysninger? Hvilken afhængighed skal komme online først?

Teknisk redundans giver lidt fordel, hvis processerne for at genvinde adgang ikke er blevet testet.

Hvad kan være tjeklisten for applikationsresiliens?

Før de påbegynder en kritisk Windows-applikation, bør IT-teams være i stand til at besvare følgende spørgsmål:

• Hvilke forretningsprocesser er afhængige af applikationen?
• Hvad er dets RTO og RPO?
• Hvilke servere, databaser og eksterne tjenester kræver det?
• Hvor er dens kritiske enkeltpunkter for fejl?
• Kan en anden vært acceptere brugere, hvis en vært fejler?
• Kan brugere oprette forbindelse, hvis deres normale endpoint eller placering ikke er tilgængelig?
• Er der nok ledig kapacitet til nedsat drift?
• Overvåges infrastruktur, afhængighed og sessionsproblemer aktivt?
• Bliver administratorer advaret, før vigtige grænser bliver til nedbrud?
• Er applikationsdata og konfiguration beskyttet?
• Har gendannelse faktisk været testet?
• Kan problematiske ændringer rulles tilbage?
• Er genopretningssekvensen dokumenteret?
• Kan brugere fuldføre den nødvendige forretningsproces efter genopretning?

Ikke alle svar kræver dyr infrastruktur med høj tilgængelighed. Det rette beskyttelsesniveau afhænger af omkostningerne og den operationelle indvirkning af nedetid.

Det, der betyder noget, er, at beslutninger om tilgængelighed, redundans og genopretning træffes bevidst snarere end antaget.

Hvordan kan TSplus hjælpe med at holde Windows-applikationer tilgængelige?

For organisationer, der er afhængige af eksisterende Windows-applikationer, kan vi hjælpe med at forbedre tilgængeligheden ved at centralisere applikationer på administrerede Windows-servere og levere dem til brugerne gennem RDP-kompatible klienter, RemoteApp-stil adgang eller en HTML5-webportal. Dette reducerer afhængigheden af individuelle brugerendepunkter og giver IT-teams mere fleksibilitet, når brugerne har brug for at oprette forbindelse fra en anden enhed eller placering.

TSplus Remote Access kan også understøtte multi-server implementeringer med belastningsbalancering og gateway-baseret adgang. Når det kombineres med robuste databaser, lagring, identitetstjenester og netværk, kan denne arkitektur reducere afhængigheden af en enkelt applikationsvært og hjælpe med at opretholde adgangen til kritiske Windows-applikationer under infrastrukturforstyrrelser.

Konklusion

Applikationsresiliens afhænger af at forstå den komplette vej mellem infrastruktur og forretningsbrug. Redundans, overvågning, backup, kapacitetsplanlægning og genopretningsprocedurer er mest effektive, når de er designet omkring klart definerede applikationsafhængigheder og genopretningsmål.

For eksisterende Windows-applikationer kommer modstandsdygtighed ofte fra at styrke miljøet omkring softwaren snarere end at genopbygge selve applikationen. Den centrale test forbliver simpel: når der opstår forstyrrelser, kan brugerne så fortsætte med at arbejde, eller kan IT gendanne den nødvendige forretningsfunktion inden for det aftalte genoprettelsesvindue?