Applikationsresiliens: Håll Windows-appar tillgängliga

Introduktion

Windows-applikationer beror ofta på mycket mer än den server som värdar dem. Databaser, identitetstjänster, lagring, gateways, nätverk och användarändpunkter kan alla påverka om en applikation förblir användbar under störningar. Denna artikel förklarar hur IT-team kan bedöma dessa beroenden, utforma motståndskraft kring befintliga Windows-applikationer, övervaka rätt lager och testa om återhämtningsplaner faktiskt bevarar de affärsfunktioner som användarna är beroende av.

Vad är applikationsresiliens?

Applikationsresiliens är kapaciteten hos en applikation och infrastrukturen runt den att fortsätta tillhandahålla viktiga funktioner under en störning och att återhämta sig förutsägbart efter ett fel.

Störningen kan vara liten eller stor, och orsakerna kan variera från hårdvaru- eller operativsystemfel, applikationskrascher, misslyckade uppdateringar, databasavbrott, nätverksavbrott, autentiseringsfel, resursutarmning, otillgängliga beroenden eller säkerhetsincidenter.

En motståndskraftig arkitektur erkänner att misslyckanden är oundvikliga, och istället för att sträva efter att förhindra varje incident, söker IT-organisationer att begränsa påverkan av varje enskild och etablera kontrollerade återhämtningsprocedurer för att upprätthålla eller återställa tjänsten.

Applikationsresiliens är mer än serverdrifttid

Ett vanligt misstag är att använda tillgängligheten av en server som en proxy för tillgängligheten av applikationen, som körs på servern.

För att en affärsapplikation ska vara verkligt tillgänglig måste ett antal komponenter vara tillgängliga samtidigt:

Infrastruktur → Operativsystem → Applikation → Beroenden → Åtkomstväg → Användarsession → Affärsprocess

Ett problem med något element i denna kedja kan resultera i att applikationen blir effektivt otillgänglig.

Till exempel kan en applikationsserver vara frisk medan dess databas är otillgänglig. En publicerad applikation kan fungera korrekt men ett gateway-fel gör det omöjligt för fjärranställda att få åtkomst till den. Användare kan till och med framgångsrikt starta applikationen men hindras från att slutföra en transaktion eftersom en licens, fil eller backend-tjänst är otillgänglig.

Applikationsresiliens bör därför mätas utifrån användarens förmåga att utföra den nödvändiga affärsuppgiften, snarare än om en server kan svara på en tillgänglighets- eller hälsokontroll.

Varför är applikationsresiliens annorlunda för Windows-applikationer?

Moderna motståndskraftspraxis fokuserar alltmer på molnbaserade applikationer, containrar, mikrotjänster och automatiserad orkestrering. Även om dessa är värdefulla tillvägagångssätt, är de inte alltid tillämpliga på varje organisation.

Många organisationer har äldre Windows-lösningar för affärsapplikationer som utvecklades innan molnbaserade arkitekturer blev vanliga. ERP-programvara, redovisningsapplikationer, tillverkningsapplikationer, hälso- och sjukvårdsapplikationer, ingenjörsapplikationer och internt utvecklade applikationer kan alla vara avgörande för en organisations verksamhet.

Att omstrukturera dessa applikationer som mikrotjänster kan vara extremt kostsamt, tekniskt utmanande eller till och med helt orealistiskt om organisationen inte kontrollerar källkoden.

I sådana fall kan det finnas ett betydande värde i att göra operationerna kring applikationen mer motståndskraftiga, snarare än att försöka göra applikationen själv mer motståndskraftig. Applikationspublicering kan vara en del av detta tillvägagångssätt genom att behålla befintliga Windows-applikationer på centraliserad infrastruktur samtidigt som man ändrar hur användare får åtkomst till dem. Detta kan inkludera förändringar av infrastrukturen som värdar applikationen, såsom att eliminera infrastrukturella begränsningar, skapa redundanta applikationsvärdar, möjliggöra alternativa åtkomstmetoder och implementera mer responsiva återhämtningsprocedurer för applikationsvärden.

I vilket fall kan tillgängligheten för en Windows-applikation misslyckas?

Att bygga applikationsresiliens börjar med att upptäcka de komponenter som behövs för att framgångsrikt leverera en applikation från sina värdar till användare. Denna process belyser potentiella felpunkter som kan ta ner en hel applikation.

Applikationsvärdar

En applikation som körs på en enda Windows-server har en tydlig enskild felpunkt.

Hårdvaruproblem, Windows-uppdateringar, korruption av operativsystemet, resursutarmning eller applikationsfel kan störa varje användare som är beroende av den maskinen. Om tillgänglighetskrav krävs kan flera applikationsvärdar sättas på plats för att minska beroendet av en enda maskin och ge kapacitet när en server blir otillgänglig.

Databaser, lagring och andra beroenden

Många Windows-applikationer är beroende av tjänster som är externa till applikationsvärden. Dessa tjänster kan inkludera:

• SQL-databaser
• filandelar
• licensservrar
• Active Directory
• Domännamnssystem (DNS)
• certifikat
• APIs
• mellanprogram
• nätverkslagring
• utskriftsinfrastruktur

Att introducera en andra applikationsserver ger minimal motståndskraft om de delar en gemensam databas eller lagringsberoende som inte är tillgängligt. Det blir uppenbart att beroendekartläggning behöver sträcka sig bortom den synliga applikationsinfrastrukturen.

Autentisering och identitet

Användare kan inte få tillgång till en fungerande applikation om den nödvändiga autentiseringsinfrastrukturen inte är tillgänglig.

IT-team behöver identifiera de identitetstjänster som deras kritiska applikationer är beroende av och säkerställa att de har beredskapsplaner på plats för när dessa resurser är otillgängliga. Active Directory, molnidentitetsplattformar, flerfaktorsautentisering (MFA) tjänster och autentisering gateways kan alla litas på för att tillhandahålla en kedja av tillgänglighet för en applikation.

Nätverks- och fjärråtkomstvägar

För centraliserade Windows-applikationer representerar anslutningen mellan användare och applikationsmiljön ett annat möjligt felområde.

Låt oss föreställa oss den kompletta kedjan:

Användarens enhet → Internet eller LAN → gateway → applikationsvärd → backend-tjänster

Ett avbrott var som helst i denna kedja kan förhindra användare från att utföra sina arbetsuppgifter även om applikationen fungerar som den ska. Särskilt relevant för distribuerade organisationer där applikationen kan vara igång i datacentret men otillgänglig för användare på en annan plats.

Slutpunkter

Applikationsresiliens kräver inte nödvändigtvis att en användares normala arbetsstation är tillgänglig.

Att erbjuda auktoriserade användare möjligheten att få åtkomst till centralt hostade applikationer från en alternativ enhet eller via en webbläsare kan säkerställa åtkomst, om en bärbar dator blir otillgänglig, ett kontor blir oåtkomligt eller anställda behöver arbeta från en annan plats.

Applikationsleveransarkitektur kan vara en del av en bredare strategi för affärskontinuitet.

Vad är processen för att bygga applikationsresiliens för Windows-appar?

Ingen enskild teknik gör applikationen motståndskraftig. IT-team måste istället minska antalet fel som kan ta en komplett funktion offline och förbereda sig för kontrollerade återhämtningsmekanismer för de som förblir.

1. Identifiera kritiska applikationer och affärsprocesser

Inte alla applikationer kräver samma grad av skydd. Börja med att fastställa vilka applikationer som stöder primära operationer, vilka användare som är beroende av dem och deras tolerans för driftstopp.

Två återhämtningsmål översätter affärskrav till tekniska specifikationer. NIST:s vägledning för beredskapsplanering definierar återställningstidens mål (RTO) och återställningspunktsmål (RPO) som nyckelparametrar för att bestämma återställningskrav:

• Återställningstidsmål (RTO): en acceptabel nedetid innan tjänsten återställs.
• Återställningspunktmål (RPO): ett intervall av acceptabel dataloss, mätt i tid.

En applikation som används intensivt för att behandla beställningar kan ha en RTO på minuter, medan en finansiell rapporteringsapplikation som körs en gång i veckan kan ha dagar av driftstopp.

RTO och RPO definierar den typ av skydd som är nödvändig för en applikation: omedelbar övergång, snabb återställning av tjänster eller bara en dokumenterad återhämtningsprocedur.

2. Kartlägg hela applikationens beroendekedja

Dokumentera allt som måste finnas för att applikationen ska kunna utföra sitt arbete.

Sluta inte vid den körbara filen eller Windows-servern. Glöm inte databaser, lagring, autentisering, DNS, nätverk, certifikat, licenssystem, gateways och externa tjänster.

För varje, fråga:

Vad händer med applikationen om detta försvinner?

Denna övning kommer att avslöja dolda enskilda felpunkter och fastställa återställningssekvens. Att återställa en applikationsvärd först hjälper inte mycket om dess databas, identitetstjänst eller lagring inte är tillgänglig än.

3. Ta bort kritiska enskilda felpunkter

När beroendeträdet har etablerats, bestäm vilka komponenter som ska göras överflödiga, baserat på affärsvikt och återhämtningsmål.

Vid leverans av Windows-applikationer kan detta innebära att flera applikationsservrar distribueras istället för att förlita sig på kapaciteten hos en enda värd. Med ett lastbalanseringslager kan sessioner spridas över applikationsinstanser under normala driftförhållanden. Vid en värdfel kan inkommande anslutningar dirigeras till friska applikationsserverinstanser.

Redundansplanering bör informeras av beroendeanalysen, men flera applikationsservrar som får åtkomst till en enda kritisk databas, nätverksgateway eller lagringslager utgör fortfarande en enda felpunkt.

Hög tillgänglighet design måste därför betrakta applikationstjänsten som en integrerad enhet. För Windows Server-miljöer som kräver redundans på infrastruktur-nivå, Microsofts dokumentation för failoverklustring ger ytterligare vägledning om hög tillgänglighet och katastrofåterställningstopologier.

4. Separera applikationer från individuella slutpunkter

Att installera en kritisk applikation direkt på varje anställds arbetsstation kan skapa en annan typ av motståndskraftproblem. Om användare förlorar tillgång till sin vanliga dator kan de också förlora tillgång till de applikationer de behöver för att fortsätta arbeta.

Centralisering av applikationer på hanterade Windows-värdar och att presentera applikationsgränssnittet för användare eliminerar denna risk. Data och applikationstillstånd lagras på den hanterade Windows-värden och nås av auktoriserade slutpunkter.

Genom att göra detta gör vi applikationen tillgänglig för användare även om de byter enheter eller platser. Även om centralisering av applikationer inte eliminerar infrastrukturproblem, hjälper det att flytta den till en miljö där den kan kontrolleras av IT.

5. Erbjuda mer än en praktisk åtkomstmetod

Resiliens kan också uppnås genom att undvika onödig beroende av en enda typ av slutpunkt eller anslutningsmetod.

Beroende på applikationsleveransarkitekturen kan användare använda olika fjärråtkomst metoder, inklusive en RDP-kompatibel klient, dedikerad applikationsstartare, webbportal eller HTML5-webbläsarsession.

Alternativa anslutningsmetoder bör inte förväxlas med infrastrukturredundans. Om alla förlitar sig på samma misslyckade server är applikationen fortfarande otillgänglig.

De ger tillgång till motståndskraft när störningar påverkar en användares normala enhet, installerade klient eller plats snarare än själva applikationstjänsten.

6. Övervaka innan nedgradering blir ett avbrott

Applikationsresiliens handlar inte bara om återställning, utan tidig nog upptäckte kan undvika nedgradering till ett avbrott.

Indikatorer som är användbara i Windows-applikationsmiljöer är CPU-användning, minnestryck, diskens kapacitet och I/O, nätverksanvändning, aktiva sessioner, applikationsprocess, svarstid, misslyckad anslutning och tillgänglighet av beroende tjänster.

Trendövervakning är avgörande, eftersom en server som upprepade gånger närmar sig sina gränser fortfarande kan vara online medan användarupplevelsen gradvis försämras.

Tröskelvarningar gör det möjligt för administratörer att undersöka föregångarna till en incident innan användare förlorar åtkomst.

7. Planera för kapacitetsökningar och failover

En applikation som överlever hårdvarunivåfel men som blir helt oförmögen att fungera under ökade krav är inte verkligen motståndskraftig mot fel av något slag.

Planeringen för kapacitet måste ta hänsyn till inte bara vardagliga användningsmönster utan också beakta toppar på grund av säsongsbetonade krav, förändrade skift, tillväxt eller värdkrav för andra applikationer.

Särskilt i fler-server hostingmiljöer måste förlusten av en enda server beaktas genom att säkerställa att andra hostingnoder har reservkapacitet för att rymma eventuella processer som annars skulle utföras på den misslyckade noden.

Annars kan failoverprocedurer helt enkelt förvandla en isolerad incident till ett omfattande systemprestandaproblem.

8. Skydda data och konfiguration

En ersättnings-Windows-server är av liten nytta om IT inte kan återställa de komponenter som behövs för att få applikationen att fungera.

Detta kan innebära att säkerhetskopieringsrutiner behöver inkludera applikationsdata, databaser, konfigurationsfiler, certifikat, applikationsinställningar, användarprofiler, infrastrukturkonfiguration, skript och licensinformation.

Strategin kommer att variera beroende på applikationens återställningstidmål (RTO) och återställningspunktsmål (RPO)

Över allt, se till att en lyckad säkerhetskopiering inte är detsamma som en lyckad återställning. IT-team bör testa att det är möjligt att återställa hela applikationstjänsten från skyddade data och konfiguration.

Minska blast-radien av förändringar

Det är inte alltid en fråga om en oförutsedd katastrof som orsakar störningar. De kan också orsakas av genomförda förbättringar. Således kan Windows-patchar, uppgraderingar av applikationer och drivrutiner, säkerhetspolicyer och konfigurationsändringar också ha en negativ inverkan på applikationens tillgänglighet. Det rekommenderas att undvika att göra liknande ändringar på alla produktionsvärdar samtidigt om möjligt.

I en fler-serverkonfiguration är det möjligt att genomföra förbättringarna i etapper, vilket gör att administratören kan säkerställa att allt fungerar korrekt. Möjligheten att återställa de gjorda ändringarna är också avgörande.

Därför bör återställningsalternativen också beaktas när man utformar beredskapsprocedurer. Processen bör dokumenteras ordentligt, och personalen bör veta vad de ska göra om en ändring misslyckas, istället för att helt enkelt överlåta det till deras eget omdöme.

10. Design för smidig nedgradering

Resiliens handlar inte om att hålla 100 % av normala funktioner igång hela tiden.

I vissa fall kan det vara viktigare att upprätthålla driften för nyckelanvändare eller applikationer än att hålla alla tjänster tillgängliga för alla användare. Prioriteringar kan fastställas innan en incident inträffar av IT-team.

Om det finns kapacitet tillgänglig som kan användas, kan det vara meningsfullt att först tilldela den till produktion, kundservice, ekonomi eller andra funktioner.

Det är en graciös nedgradering: att behålla förmågan att köra de funktioner som genererar mest affärsvärde, istället för att låta misslyckandet av mindre kritiska element få hela systemet att krascha.

Hur bör IT-team övervaka applikationsresiliens?

Övervakning av individuella servrar kan vara användbart, men övervakning av motståndskraft bör återspegla den totala applikationstjänsten som uppfattas av användarna.

En realistisk modell består av flera lager:

Skikt	Vad man ska övervaka	Exempel på misslyckande
Värd	CPU, RAM, disk, OS tillgänglighet	Server överbelastad eller offline
Applikation	Process och tjänstestatus	Applikationen kraschar
Beroende	Databas, DNS, identitet, lagring	Applikationen startar men kan inte fungera
Åtkomst	Gateway, portal, nätverksväg	Användare kan inte ansluta
Session	Aktiva användare, fel, latens	Applikationen är online men oanvändbar
Affärsfunktion	Framgångsrik slutförande av arbetsflöde	Användaren kan inte slutföra den nödvändiga uppgiften

Affärsfunktionslagret är en av de enklaste att förbise.

Infrastrukturpaneler kan visa alla servrar, tjänster och nätverksvägar som friska, medan en verklig användares arbetsflöde är komprometterat. Det är därför viktigt för kritiska applikationer att övervaka sin hälsa ur perspektivet av den verksamhet de är avsedda att stödja.

Hur ska applikationsresiliens testas?

En resiliensarkitektur som aldrig har upplevt ett kontrollerat fel innehåller otestade antaganden.

Använd testning för att utvärdera systemets respons när nyckelkomponenter blir otillgängliga. Tester bör inkludera att ta en applikationsvärd offline, stoppa en applikationstjänst, simulera förlust av en nätverksrutt, verifiera gateway- eller lastbalanseringsbeteende, återställa från säkerhetskopia och få åtkomst till applikationen från en alternativ slutpunkt.

Testprocesser bör sträcka sig bortom de tekniska aspekterna av återställning. IT-team bör granska om aviseringar skickas till rätt administrativ personal, om återställningsstegen utförs i rätt ordning och om användare kan utföra en faktisk affärsuppgift efter att tjänsterna har återställts.

Operativa procedurer är en integrerad del av ett motståndskraftigt system. Alertupptrappningsprocedurer: vem tar emot alerten? Vem har befogenhet att initiera omkoppling? Var lagras återställningsdokumentation och autentiseringsuppgifter? Vilken beroende behöver komma online först?

Teknisk redundans ger liten nytta om processerna för att återfå åtkomst inte har testats.

Vad kan vara checklistan för applikationsresiliens?

Innan de påbörjar en kritisk Windows-applikation som är motståndskraftig, bör IT-team kunna svara på följande frågor:

• Vilka affärsprocesser är beroende av applikationen?
• Vad är dess RTO och RPO?
• Vilka servrar, databaser och externa tjänster krävs?
• Var är dess kritiska enskilda felpunkter?
• Kan en annan värd för applikationen acceptera användare om en värd misslyckas?
• Kan användare ansluta om deras vanliga slutpunkt eller plats inte är tillgänglig?
• Finns det tillräckligt med reservkapacitet för försämrad drift?
• Övervakas infrastruktur-, beroende- och sessionsproblem aktivt?
• Blir administratörer varnade innan viktiga trösklar blir driftstopp?
• Är applikationsdata och konfiguration skyddade?
• Har återställning faktiskt testats?
• Kan problematiska ändringar rullas tillbaka?
• Är återhämtningssekvensen dokumenterad?
• Kan användare slutföra den nödvändiga affärsprocessen efter återställning?

Inte alla svar kräver dyr infrastruktur med hög tillgänglighet. Rätt skyddsnivå beror på kostnaden och den operationella påverkan av driftstopp.

Det som är viktigt är att beslut om tillgänglighet, redundans och återställning fattas medvetet, snarare än att antas.

Hur kan TSplus hjälpa till att hålla Windows-applikationer tillgängliga?

För organisationer som är beroende av befintliga Windows-applikationer kan vi hjälpa till att förbättra tillgängligheten genom att centralisera applikationer på hanterade Windows-servrar och leverera dem till användare via RDP-kompatibla klienter, RemoteApp-stilåtkomst eller en HTML5-webbportal. Detta minskar beroendet av individuella användarändpunkter och ger IT-team mer flexibilitet när användare behöver ansluta från en annan enhet eller plats.

TSplus Remote Access kan också stödja fler-serverutplaceringar med lastbalansering och gateway-baserad åtkomst. När den kombineras med motståndskraftiga databaser, lagring, identitetstjänster och nätverk kan denna arkitektur minska beroendet av en enda applikationsvärd och hjälpa till att upprätthålla åtkomst till kritiska Windows-applikationer under infrastrukturavbrott.

Slutsats

Applikationsresiliens beror på att förstå den kompletta vägen mellan infrastruktur och affärsanvändning. Redundans, övervakning, backup, kapacitetsplanering och återhämtningsprocedurer är mest effektiva när de är utformade kring tydligt definierade applikationsberoenden och återhämtningsmål.

För befintliga Windows-applikationer kommer motståndskraft ofta från att stärka miljön runt programvaran snarare än att återbygga själva applikationen. Det centrala testet förblir enkelt: när störningar inträffar, kan användarna fortsätta arbeta, eller kan IT återställa den nödvändiga affärsfunktionen inom det överenskomna återställningsfönstret?