Toepassingsweerbaarheid: Houd Windows-apps beschikbaar

Introductie

Windows-toepassingen zijn vaak afhankelijk van veel meer dan de server die ze host. Databases, identiteitsdiensten, opslag, gateways, netwerken en gebruikers-eindpunten kunnen allemaal van invloed zijn op de vraag of een toepassing bruikbaar blijft tijdens verstoringen. Dit artikel legt uit hoe IT-teams deze afhankelijkheden kunnen beoordelen, veerkracht kunnen ontwerpen rond bestaande Windows-toepassingen, de juiste lagen kunnen monitoren en kunnen testen of herstelplannen daadwerkelijk de bedrijfsfuncties behouden waarop gebruikers vertrouwen.

Wat is applicatieresilience?

Toepassingsweerbaarheid is de capaciteit van een toepassing en de infrastructuur eromheen om vitale functies te blijven bieden tijdens een verstoring en om voorspelbaar te herstellen na een storing.

De verstoring kan klein of groot zijn, en de oorzaken kunnen variëren van hardware- of besturingssysteemfouten, applicatiecrashes, mislukte updates, database-uitval, netwerkonderbrekingen, authenticatiefouten, uitputting van middelen, niet-beschikbare afhankelijkheden of beveiligingsincidenten.

Een veerkrachtige architectuur erkent dat fouten onvermijdelijk zijn, en in plaats van te proberen elk incident te voorkomen, streven IT-organisaties ernaar de impact van elk incident te beperken en gecontroleerde herstelprocedures vast te stellen om de service te behouden of te herstellen.

Toepassingsweerbaarheid is meer dan serverbeschikbaarheid

Een veelgemaakte fout is om de beschikbaarheid van een server te gebruiken als een proxy voor de beschikbaarheid van de applicatie, die op de server draait.

Om ervoor te zorgen dat een zakelijke applicatie echt beschikbaar is, moeten een aantal componenten tegelijkertijd beschikbaar zijn:

Infrastructuur → Besturingssysteem → Toepassing → Afhankelijkheden → Toegangspad → Gebruikerssessie → Bedrijfsproces

Een probleem met een element in deze keten kan ertoe leiden dat de applicatie effectief niet beschikbaar is.

Bijvoorbeeld, een applicatieserver kan gezond zijn terwijl de database niet toegankelijk is. Een gepubliceerde applicatie kan goed functioneren, maar een fout in de gateway maakt het onmogelijk voor externe medewerkers om er toegang toe te krijgen. Gebruikers kunnen de applicatie zelfs succesvol starten, maar worden verhinderd om een transactie te voltooien omdat een licentie, bestand of backendservice niet beschikbaar is.

Toepassingsweerbaarheid moet daarom worden gemeten op basis van het vermogen van de gebruiker om de noodzakelijke zakelijke taak uit te voeren, in plaats van of een server in staat is om te reageren op een beschikbaarheids- of gezondheidscontrole.

Waarom is applicatieresilience anders voor Windows-toepassingen?

Moderne veerkrachtpraktijken zijn steeds meer gericht op cloud-native applicaties, containers, microservices en geautomatiseerde orkestratie. Hoewel dit waardevolle benaderingen zijn, zijn ze niet altijd toepasbaar op elke organisatie.

Veel organisaties hebben legacy Windows-bedrijfsapplicaties die zijn ontwikkeld voordat cloud-native architecturen gebruikelijk waren. ERP-software, boekhoudapplicaties, productieapplicaties, gezondheidszorgapplicaties, engineeringapplicaties en intern ontwikkelde applicaties kunnen allemaal cruciaal zijn voor de operaties van een organisatie.

Het herstructureren van deze applicaties als microservices kan extreem duur, technisch uitdagend of zelfs volledig onwerkbaar zijn als de organisatie de broncode niet beheert.

In dergelijke gevallen kan het waardevol zijn om de operaties rond de applicatie veerkrachtiger te maken, in plaats van te proberen de applicatie zelf veerkrachtiger te maken. Toepassing publicatie kan deel uitmaken van deze benadering door bestaande Windows-toepassingen op gecentraliseerde infrastructuur te behouden terwijl de manier waarop gebruikers er toegang toe krijgen verandert. Dit kan wijzigingen in de infrastructuur die de toepassing host omvatten, zoals het elimineren van infrastructuurbeperkingen, het creëren van redundante toepassingshosts, het mogelijk maken van alternatieve toegangsmethoden en het implementeren van responsievere herstelprocedures voor de toepassingshost.

In welk geval kan de beschikbaarheid van een Windows-toepassing falen?

Het opbouwen van applicatieresilience begint met het ontdekken van de componenten die nodig zijn om een applicatie succesvol van hun hosts naar gebruikers te leveren. Dit proces benadrukt potentiële faalpunten die een hele applicatie kunnen laten uitvallen.

Toepassingshosts

Een applicatie die op een enkele Windows-server draait, heeft een duidelijk enkel punt van falen.

Hardwareproblemen, Windows-updates, corruptie van het besturingssysteem, uitputting van middelen of applicatiefouten kunnen elke gebruiker die afhankelijk is van die machine verstoren. Als de beschikbaarheidseisen dat vereisen, kunnen meerdere applicatiehosts worden ingezet om de afhankelijkheid van één enkele machine te verminderen en capaciteit te bieden wanneer een server niet beschikbaar is.

Databases, opslag en andere afhankelijkheden

Veel Windows-toepassingen zijn afhankelijk van diensten die extern zijn aan de applicatiehost. Deze diensten kunnen omvatten:

• SQL-databases
• bestanden delen
• licentieservers
• Active Directory
• Domeinnaamsysteem (DNS)
• certificaten
• APIs
• middleware
• netwerkopslag
• afdrukinfrastructuur

Het introduceren van een tweede applicatieserver biedt minimale veerkracht als ze een gemeenschappelijke database of opslagafhankelijkheid delen die niet beschikbaar is. Het wordt duidelijk dat afhankelijkheidsmapping verder moet reiken dan de zichtbare applicatie-infrastructuur.

Authenticatie en Identiteit

Gebruikers kunnen geen gezonde applicatie openen als de noodzakelijke authenticatie-infrastructuur niet beschikbaar is.

IT-teams moeten de identiteitsdiensten identificeren waarop hun kritieke applicaties afhankelijk zijn en ervoor zorgen dat ze failoverplannen hebben voor het geval deze bronnen niet toegankelijk zijn. Active Directory, cloudidentiteitsplatforms, multi-factor authenticatie (MFA) diensten en authenticatiegateways kunnen allemaal worden vertrouwd om een keten van beschikbaarheid voor een applicatie te bieden.

Netwerk- en Remote Access-paden

Voor gecentraliseerde Windows-toepassingen vertegenwoordigt de connectiviteit tussen gebruikers en de toepassingsomgeving een andere mogelijke foutdomein.

Laten we de complete keten voorstellen:

Gebruikersapparaat → Internet of LAN → gateway → applicatiehost → backendservices

Een storing ergens in deze keten kan voorkomen dat gebruikers hun werk kunnen doen, zelfs als de applicatie goed functioneert. Dit is vooral relevant voor gedistribueerde organisaties waar de applicatie mogelijk operationeel is in het datacenter, maar niet toegankelijk voor gebruikers op een andere locatie.

Eindpunten

Toepassingsresilience vereist niet noodzakelijk dat de normale werkstation van een gebruiker beschikbaar is.

Het aanbieden van geautoriseerde gebruikers de middelen om centraal gehoste applicaties te benaderen vanaf een alternatief apparaat of via een browser kan toegang garanderen, als een laptop niet beschikbaar is, een kantoor ontoegankelijk wordt of werknemers vanuit een andere locatie moeten werken.

Toepassingsleveringsarchitectuur kan een onderdeel zijn van een bredere strategie voor bedrijfscontinuïteit.

Wat is het proces voor het opbouwen van applicatieresilience voor Windows-apps?

Geen enkele technologie maakt de applicatie veerkrachtig. IT-teams moeten in plaats daarvan het aantal storingen verminderen dat een volledige functie kan uitschakelen en zich voorbereiden op gecontroleerde herstelmechanismen voor de storingen die blijven.

1. Identificeer Kritieke Toepassingen en Bedrijfsprocessen

Niet alle applicaties vereisen dezelfde mate van bescherming. Begin met het bepalen welke applicaties primaire operaties ondersteunen, op welke gebruikers ze vertrouwen en hun tolerantie voor uitvaltijd.

Twee hersteldoelen vertalen zakelijke vereisten naar technische specificaties. de richtlijnen voor noodplanning van NIST definieert de Hersteltijddoelstelling (RTO) en de Herstelpuntdoelstelling (RPO) als belangrijke parameters voor het bepalen van herstelvereisten:

• Hersteltijddoel (RTO): een duur van acceptabele uitvaltijd voordat de service is hersteld.
• Herstelpuntdoelstelling (RPO): een interval van acceptabel dataverlies, gemeten in tijd.

Een applicatie die intensief wordt gebruikt om bestellingen te verwerken, kan een RTO van enkele minuten hebben, terwijl een financiële rapportage-applicatie die eenmaal per week draait, dagen van uitvaltijd kan veroorloven.

RTO en RPO definiëren het type bescherming dat nodig is voor een applicatie: onmiddellijke failover, snelle herstelling van diensten of slechts een gedocumenteerde herstelprocedure.

2. Kaart de volledige applicatie-afhankelijkheidsketen

Documenteer alles wat er moet zijn zodat de applicatie zijn werk kan doen.

Stop niet bij de uitvoerbare bestanden of Windows-server. Vergeet databases, opslag, authenticatie, DNS, netwerken, certificaten, licentiesystemen, gateways en externe diensten niet.

Voor elk, vraag:

Wat gebeurt er met de applicatie als dit verdwijnt?

Deze oefening zal verborgen enkele punten van falen aan het licht brengen en de herstelvolgorde vaststellen. Het herstellen van een applicatiehost eerst helpt niet veel als de database, identiteitsdienst of opslag nog niet beschikbaar is.

3. Verwijder Kritieke Enkele Foutpunten

Zodra de afhankelijkheidsstructuur is vastgesteld, bepaal welke componenten overbodig moeten worden gemaakt, op basis van zakelijke belangrijkheid en hersteldoelstellingen.

In het geval van de levering van Windows-toepassingen kan dit inhouden dat er meerdere toepassingsservers worden ingezet in plaats van te vertrouwen op de mogelijkheden van een enkele host. Met een load balancing-laag kunnen sessies tijdens normale operaties over toepassingsinstanties worden verspreid. In het geval van een hostfout kunnen binnenkomende verbindingen worden doorgestuurd naar gezonde toepassingsserverinstanties.

Redundantieplanning moet echter worden geïnformeerd door de afhankelijkheidsanalyse. Meerdere applicatieservers die toegang hebben tot een enkele kritieke database, netwerkgateway of opslaglaag vormen nog steeds een enkel punt van falen.

Het ontwerp voor hoge beschikbaarheid moet daarom de applicatieservice beschouwen als een geïntegreerde entiteit. Voor Windows Server-omgevingen die redundantie op infrastructuurniveau vereisen, Microsoft's Failover Clustering-documentatie biedt verdere richtlijnen voor topologieën voor hoge beschikbaarheid en rampenherstel.

4. Scheid applicaties van individuele eindpunten

Het installeren van een kritieke applicatie rechtstreeks op de werkstations van elke werknemer kan een ander soort veerkrachtprobleem creëren. Als gebruikers toegang verliezen tot hun reguliere computer, kunnen ze ook de toegang verliezen tot de applicaties die ze nodig hebben om door te gaan met werken.

Toepassingen centraliseren op beheerde Windows-hosts en het presenteren van de applicatie-interface aan gebruikers elimineert dit risico. De gegevens en de applicatiestatus worden opgeslagen op de beheerde Windows-host en benaderd door geautoriseerde eindpunten.

Door dit te doen, maken we de applicatie beschikbaar voor gebruikers, zelfs als ze van apparaat of locatie veranderen. Hoewel het centraliseren van applicaties infrastructuurproblemen niet oplost, helpt het om het in een omgeving te verplaatsen waar het door IT kan worden beheerd.

Bied meer dan één praktische toegangsmethode aan

Veerkracht kan ook worden bereikt door onnodige afhankelijkheid van een enkel type eindpunt of verbindingsmethode te vermijden.

Afhankelijk van de architectuur voor appliclevering, kunnen gebruikers verschillende gebruiken Externe toegang methoden, waaronder een RDP-compatibele client, een speciale applicatielauncher, een webportaal of HTML5-browser sessie.

Alternatieve verbindingsmethoden moeten niet verward worden met infrastructuurredundantie. Als iedereen afhankelijk is van dezelfde defecte server, is de applicatie nog steeds niet beschikbaar.

Ze bieden toegang veerkracht wanneer verstoringen een normaal apparaat, geïnstalleerde client of locatie van een gebruiker beïnvloeden in plaats van de applicatiedienst zelf.

6. Monitor voordat degradatie een storing wordt

Toepassingsweerbaarheid gaat niet alleen om herstel, maar vroegtijdige detectie kan degradatie naar een storing voorkomen.

Indicatoren die nuttig zijn in Windows-toepassingsomgevingen zijn CPU-gebruik, geheugendruk, schijfcapaciteit en I/O, netwerkgebruik, actieve sessies, applicatieproces, responstijd, mislukte verbinding en beschikbaarheid van afhankelijke services.

Trend monitoring is cruciaal, aangezien een server die herhaaldelijk zijn limieten benadert nog steeds online kan zijn terwijl de gebruikerservaring geleidelijk verslechtert.

Drempelwaarschuwingen stellen beheerders in staat om de voorlopers van een incident te onderzoeken voordat gebruikers toegang verliezen.

7. Plan voor capaciteitspieken en failover

Een applicatie die hardwarematige storingen overleeft maar volledig niet in staat is om te functioneren onder verhoogde eisen, is niet echt veerkrachtig tegen storingen van welke aard dan ook.

De planning voor capaciteit moet niet alleen rekening houden met dagelijkse gebruikspatronen, maar ook pieken in verband met seizoensgebonden vraag, wisselingen van diensten, groei of hostingvereisten voor andere applicaties.

Bijzonder in multi-server hostingomgevingen moet het verlies van een enkele server worden opgevangen door ervoor te zorgen dat andere hostingnodes over reservecapaciteit beschikken om eventuele processen te kunnen uitvoeren die anders op de defecte node zouden worden uitgevoerd.

Anders kunnen fail-overprocedures een geïsoleerd voorval eenvoudig omzetten in een breed systeemperformanceprobleem.

8. Bescherm gegevens en configuratie

Een vervangende Windows-server heeft weinig nut als IT de componenten die nodig zijn om de applicatie te laten werken niet kan herstellen.

Dit kan betekenen dat back-upprocedures applicatiegegevens, databases, configuratiebestanden, certificaten, applicatie-instellingen, gebruikersprofielen, infrastructuurconfiguratie, scripts en licentie-informatie moeten omvatten.

De strategie zal variëren afhankelijk van de Hersteltijddoelstelling (RTO) en Herstelpuntdoelstelling (RPO) van de applicatie.

Bovenal moet ervoor worden gezorgd dat een succesvolle back-up niet gelijkstaat aan een succesvolle herstel. IT-teams moeten testen of het mogelijk is om de gehele applicatieservice te herstellen vanuit beschermde gegevens en configuratie.

9. Verminder de impact van wijzigingen

Het is niet altijd een geval van een onvoorziene ramp die verstoringen veroorzaakt. Ze kunnen ook worden veroorzaakt door geïmplementeerde verbeteringen. Dus, Windows-patches, applicatie- en stuurprogramma-upgrades, wijzigingen in het beveiligingsbeleid en configuratiewijzigingen kunnen ook een negatieve impact hebben op de beschikbaarheid van de applicatie. Het wordt aanbevolen om soortgelijke wijzigingen niet gelijktijdig aan alle productiehosts aan te brengen, indien mogelijk.

In een multi-serveropstelling is het mogelijk om de verbeteringen in fasen door te voeren, zodat de beheerder kan controleren of alles correct werkt. De mogelijkheid om de aangebrachte wijzigingen terug te draaien is ook essentieel.

Dus, bij het ontwerpen van noodprocedures moeten ook de terugrolopties in overweging worden genomen. Het proces moet goed gedocumenteerd zijn, en het personeel moet weten wat te doen als een wijziging mislukt, in plaats van het simpelweg aan hun discretie over te laten.

10. Ontwerp voor elegante degradatie

Veerkracht gaat niet om het te allen tijde 100% van de normale functies operationeel te houden.

In sommige gevallen kan het handhaven van de operaties voor belangrijke gebruikers of applicaties belangrijker zijn dan het beschikbaar houden van alle diensten voor alle gebruikers. Prioriteiten kunnen worden vastgesteld voordat een incident zich voordoet door IT-teams.

Als er capaciteit beschikbaar is die kan worden gebruikt, kan het logisch zijn om deze eerst toe te wijzen aan productie, klantenservice, financiën of andere functies.

Dat is elegante degradatie: het behouden van de mogelijkheid om de functies uit te voeren die de meeste zakelijke waarde genereren, in plaats van de hele systeem te laten crashen door de uitval van minder kritische elementen.

Hoe moeten IT-teams de veerkracht van applicaties monitoren?

Monitoring van individuele servers kan nuttig zijn, maar veerkrachtmonitoring moet de totale applicatieservice weerspiegelen zoals deze door gebruikers wordt waargenomen.

Een realistisch model bestaat uit verschillende lagen:

Laag	Wat te monitoren	Voorbeeld van mislukking
Host	CPU, RAM, schijf, beschikbaarheid van het besturingssysteem	Server overbelast of offline
Toepassing	Proces- en servicestatus	Toepassing crasht
Afhankelijkheid	Database, DNS, identiteit, opslag	Toepassing wordt gestart maar kan niet functioneren
Toegang	Gateway, portal, netwerkpad	Gebruikers kunnen geen verbinding maken
Sessie	Actieve gebruikers, fouten, latentie	Toepassing is online maar onbruikbaar
Bedrijfsfunctie	Succesvolle workflow voltooiing	De gebruiker kan de vereiste taak niet voltooien.

De bedrijfsfunctie-laag is een van de eenvoudigste om over het hoofd te zien.

Infrastructuurdashboards kunnen alle servers, services en netwerkpaden als gezond weergeven, terwijl de workflow van een echte gebruiker in gevaar is. Het is daarom belangrijk dat kritieke applicaties hun gezondheid monitoren vanuit het perspectief van de operatie waarvoor ze zijn ontworpen om ondersteuning te bieden.

Hoe moet de veerkracht van applicaties worden getest?

Een veerkrachtarchitectuur die nooit een gecontroleerde storing heeft ervaren, bevat ongeteste aannames.

Gebruik testen om de reactie van het systeem te evalueren wanneer belangrijke componenten niet beschikbaar zijn. De tests moeten onder andere het offline halen van een applicatiehost, het stoppen van een applicatiedienst, het simuleren van verlies van een netwerkroute, het verifiëren van gateway- of load-balancinggedrag, het herstellen vanaf een back-up en het openen van de applicatie vanaf een alternatief eindpunt omvatten.

Testprocessen moeten verder gaan dan de technische aspecten van herstel. IT-teams moeten controleren of waarschuwingen naar het juiste administratieve personeel worden verzonden, of de herstelstappen in de juiste volgorde worden uitgevoerd en of gebruikers in staat zijn om een daadwerkelijke zakelijke taak uit te voeren nadat de diensten zijn hersteld.

Operationele procedures zijn essentieel voor een veerkrachtig systeem. Escalatieprocedures voor waarschuwingen: wie ontvangt de waarschuwing? Wie heeft de autoriteit om failover te initiëren? Waar worden hersteldocumentatie en inloggegevens opgeslagen? Welke afhankelijkheid moet als eerste online komen?

Technische redundantie biedt weinig voordeel als de processen om toegang te herstellen niet zijn getest.

Wat kan de checklist voor applicatieresilience zijn?

Voordat IT-teams aan een kritieke veerkrachtige Windows-toepassing beginnen, moeten ze in staat zijn de volgende vragen te beantwoorden:

• Welke bedrijfsprocessen zijn afhankelijk van de applicatie?
• Wat zijn de RTO en RPO?
• Welke servers, databases en externe diensten zijn hiervoor nodig?
• Waar zijn de kritieke enkelpunten van falen?
• Kan een andere host van een applicatie gebruikers accepteren als één host faalt?
• Kunnen gebruikers verbinding maken als hun normale eindpunt of locatie niet beschikbaar is?
• Is er voldoende reservecapaciteit voor gedegradeerde werking?
• Worden infrastructuur-, afhankelijkheids- en sessieproblemen actief gemonitord?
• Worden beheerders gewaarschuwd voordat belangrijke drempels uitvallen?
• Zijn applicatiegegevens en configuratie beschermd?
• Is de herstelprocedure daadwerkelijk getest?
• Kunnen problematische wijzigingen worden teruggedraaid?
• Is de herstelvolgorde gedocumenteerd?
• Kunnen gebruikers het vereiste bedrijfsproces na herstel voltooien?

Niet alle antwoorden vereisen dure infrastructuur met hoge beschikbaarheid. Het juiste niveau van bescherming hangt af van de kosten en de operationele impact van downtime.

Wat belangrijk is, is dat beslissingen over beschikbaarheid, redundantie en herstel opzettelijk worden genomen, in plaats van aangenomen.

Hoe kan TSplus helpen om Windows-toepassingen beschikbaar te houden?

Voor organisaties die afhankelijk zijn van bestaande Windows-toepassingen, kunnen we de beschikbaarheid verbeteren door toepassingen te centraliseren op beheerde Windows-servers en deze aan gebruikers te leveren via RDP-compatibele clients, toegang in RemoteApp-stijl of een HTML5-webportaal. Dit vermindert de afhankelijkheid van individuele gebruikers-eindpunten en geeft IT-teams meer flexibiliteit wanneer gebruikers vanaf een ander apparaat of locatie moeten verbinden.

TSplus Remote Access kan ook multi-server implementaties ondersteunen met load balancing en gateway-gebaseerde toegang. Wanneer gecombineerd met veerkrachtige databases, opslag, identiteitsdiensten en netwerken, kan deze architectuur de afhankelijkheid van een enkele applicatiehost verminderen en helpen de toegang tot kritieke Windows-applicaties te behouden tijdens verstoringen van de infrastructuur.

Conclusie

Toepassingsweerbaarheid hangt af van het begrijpen van het volledige pad tussen infrastructuur en zakelijk gebruik. Redundantie, monitoring, back-up, capaciteitsplanning en herstelprocedures zijn het meest effectief wanneer ze zijn ontworpen rond duidelijk gedefinieerde toepassingsafhankelijkheden en hersteldoelstellingen.

Voor bestaande Windows-toepassingen komt veerkracht vaak voort uit het versterken van de omgeving rond de software in plaats van het opnieuw opbouwen van de toepassing zelf. De belangrijkste test blijft eenvoudig: wanneer er een verstoring optreedt, kunnen gebruikers dan doorgaan met werken, of kan IT de vereiste bedrijfsfunctie binnen het afgesproken herstelvenster herstellen?