Applikasjonsmotstand: Hold Windows-apper tilgjengelige

Introduksjon

Windows-applikasjoner avhenger ofte av langt mer enn serveren som huser dem. Databaser, identitetstjenester, lagring, porter, nettverk og brukerendepunkter kan alle påvirke om en applikasjon forblir brukbar under forstyrrelser. Denne artikkelen forklarer hvordan IT-team kan vurdere disse avhengighetene, designe motstandskraft rundt eksisterende Windows-applikasjoner, overvåke de riktige lagene og teste om gjenopprettingsplaner faktisk bevarer forretningsfunksjonene brukerne er avhengige av.

Hva er applikasjonsresiliens?

Applikasjonsresiliens er kapasiteten til en applikasjon og infrastrukturen rundt den til å fortsette å tilby viktige funksjoner under en forstyrrelse og å komme seg forutsigbart etter en feil.

Forstyrrelsen kan være liten eller stor, og årsakene kan variere fra maskinvare- eller operativsystemfeil, applikasjonskrasj, mislykkede oppdateringer, databaseutfall, nettverksavbrudd, autentiseringsfeil, ressursutarming, utilgjengelige avhengigheter eller sikkerhetshendelser.

En motstandsdyktig arkitektur anerkjenner at feil er uunngåelige, og i stedet for å sikte på å forhindre hver hendelse, søker IT-organisasjoner å begrense virkningen av hver enkelt og etablere kontrollerte gjenopprettingsprosedyrer for å opprettholde eller gjenopprette tjenesten.

Applikasjonsresiliens er mer enn serveroppehold.

En vanlig feil er å bruke tilgjengeligheten til en server som en proxy for tilgjengeligheten til applikasjonen, som kjører på serveren.

For at en forretningsapplikasjon skal være virkelig tilgjengelig, må en rekke komponenter være tilgjengelige samtidig:

Infrastruktur → Operativsystem → Applikasjon → Avhengigheter → Tilgangssti → Brukersesjon → Forretningsprosess

Et problem med noe element i denne kjeden kan føre til at applikasjonen blir effektivt utilgjengelig.

For eksempel kan en applikasjonsserver være sunn mens databasen er utilgjengelig. En publisert applikasjon kan fungere som den skal, men en gateway-feil gjør det umulig for eksterne ansatte å få tilgang til den. Brukere kan til og med lykkes med å starte applikasjonen, men bli hindret fra å fullføre en transaksjon fordi en lisens, fil eller backend-tjeneste ikke er tilgjengelig.

Applikasjonsresiliens bør derfor måles basert på brukerens evne til å utføre den nødvendige forretningsoppgaven, snarere enn om en server er i stand til å svare på en tilgjengelighets- eller helsesjekk.

Hvorfor er applikasjonsresiliens annerledes for Windows-applikasjoner?

Moderne resilienspraksiser er i økende grad fokusert på skybaserte applikasjoner, containere, mikrotjenester og automatisert orkestrering. Selv om disse er verdifulle tilnærminger, er de ikke alltid anvendelige for hver organisasjon.

Mange organisasjoner har eldre Windows-forretningsapplikasjoner som ble utviklet før skybaserte arkitekturer ble vanlige. ERP-programvare, regnskapsapplikasjoner, produksjonsapplikasjoner, helseapplikasjoner, ingeniørapplikasjoner og internt utviklede applikasjoner kan alle være kritiske for en organisasjons drift.

Rearkitekturering av disse applikasjonene som mikrotjenester kan være ekstremt kostbart, teknisk utfordrende, eller til og med helt urealistisk hvis organisasjonen ikke kontrollerer kildekoden.

I slike tilfeller kan det være betydelig verdi i å gjøre operasjonene rundt applikasjonen mer robuste, i stedet for å prøve å gjøre selve applikasjonen mer robust. Applikasjonspublisering kan være en del av denne tilnærmingen ved å beholde eksisterende Windows-applikasjoner på sentralisert infrastruktur samtidig som man endrer hvordan brukerne får tilgang til dem. Dette kan inkludere endringer i infrastrukturen som huser applikasjonen, for eksempel å eliminere infrastrukturbegrensninger, opprette redundante applikasjonsverter, muliggjøre alternative tilgangsmetoder og implementere mer responsive gjenopprettingsprosedyrer for applikasjonsverten.

I hvilke tilfeller kan tilgjengeligheten av en Windows-applikasjon feile?

Å bygge applikasjonsresiliens begynner med å oppdage komponentene som er nødvendige for å levere en applikasjon fra vertene til brukerne på en vellykket måte. Denne prosessen fremhever potensielle feilpunkt som kan ta ned en hel applikasjon.

Applikasjonsverter

En applikasjon som kjører på en enkelt Windows-server har et klart enkelt feilpunkt.

Maskinvareproblemer, Windows-oppdateringer, korrupsjon av operativsystemet, ressursutarming eller applikasjonsfeil kan forstyrre hver bruker som er avhengig av den maskinen. Hvis tilgjengelighetsbehovene krever det, kan flere applikasjonsverter settes i verk for å redusere avhengigheten av én enkelt maskin og gi kapasitet når en server blir utilgjengelig.

Databaser, lagring og andre avhengigheter

Mange Windows-applikasjoner er avhengige av tjenester utenfor applikasjonsverten. Disse tjenestene kan inkludere:

• SQL-databaser
• filandeler
• lisensservere
• Active Directory
• Domenenavnssystem (DNS)
• sertifikater
• APIs
• middleware
• nettverkslagring
• utskriftsinfrastruktur

Å introdusere en andre applikasjonsserver gir minimal motstandskraft hvis de deler en felles database eller lagringsavhengighet som ikke er tilgjengelig. Det blir tydelig at avhengighetskartlegging må utvides utover den synlige applikasjonsinfrastrukturen.

Autentisering og identitet

Brukere kan ikke få tilgang til en sunn applikasjon hvis den nødvendige autentiseringsinfrastrukturen ikke er tilgjengelig.

IT-team må identifisere identitetstjenestene som deres kritiske applikasjoner er avhengige av, og sørge for at de har beredskapsplaner på plass for når disse ressursene er utilgjengelige. Active Directory, skyidentitetsplattformer, flerfaktorautentisering (MFA) tjenester og autentiseringsportaler kan alle stole på for å gi en kjede av tilgjengelighet for en applikasjon.

Nettverks- og fjernaksessveier

For sentraliserte Windows-applikasjoner representerer tilkoblingen mellom brukere og applikasjonsmiljøet et annet mulig feildomene.

La oss forestille oss den komplette kjeden:

Brukerens enhet → Internett eller LAN → gateway → applikasjonsvert → backend-tjenester

En nedetid hvor som helst i denne kjeden kan hindre brukere i å utføre jobben sin, selv om applikasjonen fungerer som den skal. Dette er spesielt relevant for distribuerte organisasjoner hvor applikasjonen kan være oppe og kjøre i datasenteret, men utilgjengelig for brukere på en annen lokasjon.

Sluttpunkter

Applikasjonsresiliens krever ikke nødvendigvis at en brukers normale arbeidsstasjon er tilgjengelig.

Å tilby autoriserte brukere muligheten til å få tilgang til sentralt hostede applikasjoner fra en alternativ enhet eller via en nettleser kan sikre tilgang, hvis en bærbar datamaskin blir utilgjengelig, et kontor blir utilgjengelig eller ansatte må jobbe fra et annet sted.

Applikasjonsleveringsarkitektur kan være en del av en bredere forretningskontinuitetsstrategi.

Hva er prosessen for å bygge applikasjonsresiliens for Windows-apper?

Ingen enkelt teknologi gjør applikasjonen motstandsdyktig. IT-team må i stedet redusere antallet feil som kan ta en komplett funksjon ned og forberede seg på kontrollerte gjenopprettingsmekanismer for de som forblir.

1. Identifiser kritiske applikasjoner og forretningsprosesser

Ikke alle applikasjoner krever samme grad av beskyttelse. Begynn med å bestemme hvilke applikasjoner som støtter primære operasjoner, hvilke brukere som er avhengige av dem og deres toleranse for nedetid.

To gjenopprettingsmål oversette forretningskrav til tekniske spesifikasjoner. NISTs retningslinjer for beredskapsplanlegging definerer gjenopprettingstidmål (RTO) og gjenopprettingspunktmål (RPO) som nøkkelparametere for å bestemme gjenopprettingskrav:

• Gjenopprettingstidsmål (RTO): en varighet av akseptabel nedetid før tjenesten gjenopprettes.
• Gjenopprettingspunktmål (RPO): et intervall av akseptabel datatap, målt i tid.

En applikasjon som brukes intensivt til å behandle bestillinger kan ha en RTO på minutter, mens en finansiell rapporteringsapplikasjon som kjøres en gang i uken kan tåle dager med nedetid.

RTO og RPO definerer typen beskyttelse som er nødvendig for en applikasjon: øyeblikkelig failover, rask gjenoppretting av tjenester eller bare en dokumentert gjenopprettingsprosedyre.

2. Kartlegg hele applikasjonsavhengighetskjeden

Dokumenter alt som må være der for at applikasjonen skal gjøre jobben sin.

Ikke stopp ved den kjørbare filen eller Windows-serveren. Ikke glem databaser, lagring, autentisering, DNS, nettverk, sertifikater, lisensieringssystemer, porter og eksterne tjenester.

For hver, spør:

Hva skjer med applikasjonen hvis dette forsvinner?

Denne øvelsen vil avdekke skjulte enkeltpunkter for feil og etablere gjenopprettingssekvens. Å gjenopprette en applikasjonsvert først hjelper ikke mye hvis databasen, identitetstjenesten eller lagringen ikke er tilgjengelig ennå.

3. Fjern kritiske enkeltpunkter for feil

Når avhengighetstreet er etablert, bestem hvilke komponenter som skal gjøres overflødige, basert på forretningsmessig viktighet og gjenopprettingsmål.

I tilfelle av Windows-applikasjonslevering kan dette innebære å distribuere flere applikasjonsservere i stedet for å stole på kapasitetene til en enkelt vert. Med et lastbalanseringslag kan økter fordeles over applikasjonsinstanser under normale operasjoner. I tilfelle av en vertsfeil kan innkommende tilkoblinger dirigeres til friske applikasjonsserverinstanser.

Redundansplanlegging bør informeres av avhengighetsanalysen. Flere applikasjonsservere som får tilgang til en enkelt kritisk database, nettverksport eller lagringslag utgjør fortsatt et enkelt feilpunkt.

Høy tilgjengelighetsdesign må derfor vurdere applikasjonstjenesten som en integrert enhet. For Windows Server-miljøer som krever redundans på infrastruktur-nivå, Microsofts dokumentasjon for failover-klynging gir ytterligere veiledning om høy tilgjengelighet og katastrofegjenopprettings-topologier.

4. Separere applikasjoner fra individuelle endepunkter

Å installere en kritisk applikasjon direkte på hver ansatts arbeidsstasjon kan skape en annen type motstandsdyktighetsproblem. Hvis brukerne mister tilgangen til sin vanlige datamaskin, kan de også miste tilgangen til applikasjonene de trenger for å fortsette å jobbe.

Sentralisering av applikasjoner på administrerte Windows-verter og presentere applikasjonsgrensesnittet for brukerne eliminerer denne risikoen. Dataene og applikasjonsstatusen lagres på den administrerte Windows-vert og nås av autoriserte endepunkter.

Ved å gjøre dette gjør vi applikasjonen tilgjengelig for brukere selv om de bytter enheter eller steder. Selv om sentralisering av applikasjoner ikke eliminerer infrastrukturproblemer, hjelper det å flytte den til et miljø hvor den kan kontrolleres av IT.

5. Gi mer enn én praktisk tilgangsmetode

Resiliens kan også oppnås ved å unngå unødvendig avhengighet av en enkelt type sluttpunkt eller tilkoblingsmetode.

Avhengig av applikasjonsleveringsarkitekturen kan brukere bruke forskjellige fjernaksess metoder, inkludert en RDP-kompatibel klient, dedikert applikasjonsstarter, webportal eller HTML5 nettlesersesjon.

Alternative tilkoblingsmetoder bør ikke forveksles med infrastrukturredundans. Hvis alle er avhengige av den samme mislykkede serveren, er applikasjonen fortsatt utilgjengelig.

De gir tilgangsresiliens når forstyrrelser påvirker en brukers normale enhet, installerte klient eller plassering i stedet for applikasjonstjenesten selv.

6. Overvåk før nedgangen blir en avbrudd

Applikasjonsresiliens handler ikke bare om gjenoppretting, men tidlig nok oppdagelse kan unngå forringelse til en nedetid.

Indikatorer som er nyttige i Windows-applikasjonsmiljøer er CPU-utnyttelse, minnepress, disk kapasitet og I/O, nettverksutnyttelse, aktive økter, applikasjonsprosess, responstid, mislykket tilkobling og tilgjengelighet av avhengige tjenester.

Trendovervåking er avgjørende, ettersom en server som gjentatte ganger nærmer seg sine grenser fortsatt kan være online mens brukeropplevelsen gradvis forverres.

Terskelvarsler gjør det mulig for administratorer å undersøke forløperne til en hendelse før brukerne mister tilgang.

7. Plan for kapasitetsøkninger og failover

En applikasjon som overlever maskinvarefeil, men som blir helt ute av stand til å fungere under økte krav, er ikke virkelig motstandsdyktig mot feil av noe slag.

Planleggingen for kapasitet må ta hensyn til ikke bare hverdagsbruksmønstre, men også ta høyde for topper på grunn av sesongmessige krav, skiftendringer, vekst eller vertskrav for andre applikasjoner.

Spesielt i flerserververt hostingmiljøer må tapet av en enkelt server tas i betraktning ved å sikre at andre hostingnoder har ledig kapasitet til å imøtekomme eventuelle prosesser som ellers ville blitt utført på den mislykkede noden.

Ellers kan failover-prosedyrer enkelt gjøre en isolert hendelse til et omfattende systemytelsesproblem.

8. Beskytt data og konfigurasjon

En erstatnings Windows-server er lite nyttig hvis IT ikke kan gjenopprette komponentene som trengs for å få applikasjonen til å fungere.

Dette kan bety at sikkerhetskopieringsprosedyrer må inkludere applikasjonsdata, databaser, konfigurasjonsfiler, sertifikater, applikasjonsinnstillinger, brukerprofiler, infrastrukturkonfigurasjon, skript og lisensinformasjon.

Strategien vil variere avhengig av applikasjonens gjenopprettingstidmål (RTO) og gjenopprettingspunktsmål (RPO)

Fremfor alt, sørg for at en vellykket sikkerhetskopi ikke er lik en vellykket gjenoppretting. IT-team bør teste at det er mulig å gjenopprette hele applikasjonstjenesten fra beskyttede data og konfigurasjon.

9. Reduser blastradiusen av endringer

Det er ikke alltid en uforutsett katastrofe som forårsaker forstyrrelser. De kan også være forårsaket av implementerte forbedringer. Dermed kan Windows-oppdateringer, applikasjons- og driveroppgraderinger, endringer i sikkerhetspolicy og konfigurasjon også ha en negativ innvirkning på applikasjonens tilgjengelighet. Det anbefales å unngå å gjøre lignende endringer på alle produksjonsverter samtidig hvis mulig.

I en fler-serveroppsett er det mulig å utføre forbedringsendringene i trinn, noe som gjør det mulig for administratoren å sikre at alt fungerer som det skal. Evnen til å tilbakestille de utførte endringene er også essensiell.

Dermed, når man utformer beredskapsprosedyrer, bør også tilbakestillingsalternativene vurderes. Prosessen bør være riktig dokumentert, og personalet bør vite hva de skal gjøre hvis en endring mislykkes, i stedet for bare å overlate det til deres skjønn.

10. Design for Graceful Degradation

Resiliens handler ikke om å opprettholde 100 % av normale funksjoner oppe og gå til enhver tid.

I noen tilfeller kan det være viktigere å opprettholde driften for nøkkelbrukere eller applikasjoner enn å holde alle tjenester tilgjengelige for alle brukere. Prioriteringer kan etableres før en hendelse skjer av IT-teamene.

Hvis det er kapasitet tilgjengelig som kan brukes, kan det gi mening å tildele den først til produksjon, kundeservice, økonomi eller andre funksjoner.

Det er elegant nedgradering: å beholde evnen til å kjøre funksjonene som genererer mest forretningsverdi, i stedet for å la svikt i mindre kritiske elementer få hele systemet til å krasje.

Hvordan bør IT-team overvåke applikasjonsmotstand?

Overvåking av individuelle servere kan være nyttig, men overvåking av motstandskraft bør gjenspeile den totale applikasjonstjenesten slik den oppfattes av brukerne.

En realistisk modell består av flere lag:

Lag	Hva som skal overvåkes	Eksempel på feil
Vert vert	CPU, RAM, disk, OS tilgjengelighet	Server overbelastet eller offline
Applikasjon	Prosess- og tjenestestatus	Applikasjonen krasjer
Avhengighet	Database, DNS, identitet, lagring	Applikasjonen starter, men kan ikke operere
Tilgang	Gateway, portal, nettverksbane	Brukere kan ikke koble til
Økt	Aktive brukere, feil, latens	Applikasjonen er online, men ubrukelig
Forretningsfunksjon	Vellykket fullføring av arbeidsflyt	Brukeren kan ikke fullføre den nødvendige oppgaven

Forretningsfunksjonslaget er en av de enkleste å overse.

Infrastrukturdashbord kan vise alle servere, tjenester og nettverksveier som sunne, mens en ekte brukers arbeidsflyt er kompromittert. Det er derfor viktig for kritiske applikasjoner å overvåke helsen sin fra perspektivet til driften de er designet for å støtte.

Hvordan bør applikasjonsresiliens testes?

En motstandsdyktig arkitektur som aldri har opplevd en kontrollert feil inneholder utestede antakelser.

Bruk testing for å evaluere systemets respons når nøkkelkomponenter blir utilgjengelige. Testene bør inkludere å ta en applikasjonsvert offline, stoppe en applikasjonstjeneste, simulere tap av en nettverksrute, verifisere atferd for gateway eller lastbalansering, gjenopprette fra sikkerhetskopi og få tilgang til applikasjonen fra et alternativt sluttpunkt.

Testprosesser bør strekke seg utover de tekniske aspektene ved gjenoppretting. IT-team bør vurdere om varsler sendes til riktig administrativt personell, om gjenopprettingsstegene utføres i riktig rekkefølge, og om brukerne er i stand til å utføre en faktisk forretningoppgave etter at tjenestene er blitt gjenopprettet.

Operasjonelle prosedyrer er en integrert del av et robust system. Varslingseskalering prosedyrer: hvem mottar varslingen? Hvem har myndighet til å iverksette failover? Hvor er gjenopprettingsdokumentasjon og legitimasjon lagret? Hvilken avhengighet må komme online først?

Teknisk redundans gir liten nytte hvis prosessene for å gjenvinne tilgang ikke har blitt testet.

Hva kan være sjekklisten for applikasjonsresiliens?

Før de begynner på en kritisk Windows-applikasjon som er motstandsdyktig, bør IT-team kunne svare på følgende spørsmål:

• Hvilke forretningsprosesser er avhengige av applikasjonen?
• Hva er RTO og RPO?
• Hvilke servere, databaser og eksterne tjenester kreves?
• Hvor er dens kritiske enkeltpunkter for feil?
• Kan en annen vert for applikasjonen akseptere brukere hvis en vert feiler?
• Kan brukere koble til hvis deres normale sluttpunkt eller plassering ikke er tilgjengelig?
• Er det nok ledig kapasitet for redusert drift?
• Blir infrastruktur, avhengighet og sesjonsproblemer aktivt overvåket?
• Blir administratorer varslet før viktige terskler blir til nedetid?
• Er applikasjonsdata og konfigurasjon beskyttet?
• Har gjenoppretting faktisk blitt testet?
• Kan problematiske endringer rulles tilbake?
• Er gjenopprettingssekvensen dokumentert?
• Kan brukere fullføre den nødvendige forretningsprosessen etter gjenoppretting?

Ikke alle svar krever kostbar høytilgjengelighetsinfrastruktur. Det riktige beskyttelsesnivået avhenger av kostnadene og driftsvirkningen av nedetid.

Det som betyr noe er at tilgjengelighet, redundans og gjenopprettingsbeslutninger tas bevisst, snarere enn antatt.

Hvordan kan TSplus bidra til å holde Windows-applikasjoner tilgjengelige?

For organisasjoner som er avhengige av eksisterende Windows-applikasjoner, kan vi hjelpe med å forbedre tilgjengeligheten ved å sentralisere applikasjoner på administrerte Windows-servere og levere dem til brukere gjennom RDP-kompatible klienter, RemoteApp-stil tilgang eller en HTML5-nettportal. Dette reduserer avhengigheten av individuelle brukerendepunkter og gir IT-teamene mer fleksibilitet når brukere trenger å koble til fra en annen enhet eller plassering.

TSplus Remote Access kan også støtte fler-server distribusjoner med lastbalansering og gateway-basert tilgang. Når det kombineres med robuste databaser, lagring, identitetstjenester og nettverksløsninger, kan denne arkitekturen redusere avhengigheten av en enkelt applikasjonsvert og bidra til å opprettholde tilgang til kritiske Windows-applikasjoner under infrastrukturforstyrrelser.

Konklusjon

Applikasjonsresiliens avhenger av å forstå den komplette stien mellom infrastruktur og forretningsbruk. Redundans, overvåking, sikkerhetskopiering, kapasitetsplanlegging og gjenopprettingsprosedyrer er mest effektive når de er utformet rundt klart definerte applikasjonsavhengigheter og gjenopprettingsmål.

For eksisterende Windows-applikasjoner kommer motstandskraft ofte fra å styrke miljøet rundt programvaren i stedet for å gjenoppbygge selve applikasjonen. Den viktigste testen forblir enkel: når forstyrrelser skjer, kan brukerne fortsette å jobbe, eller kan IT gjenopprette den nødvendige forretningsfunksjonen innen det avtalte gjenopprettingsvinduet?