Résilience des applications : Gardez les applications Windows disponibles

Introduction

Les applications Windows dépendent souvent de bien plus que du serveur qui les héberge. Les bases de données, les services d'identité, le stockage, les passerelles, les réseaux et les points de terminaison des utilisateurs peuvent tous affecter la capacité d'une application à rester utilisable en cas de perturbation. Cet article explique comment les équipes informatiques peuvent évaluer ces dépendances, concevoir une résilience autour des applications Windows existantes, surveiller les bonnes couches et tester si les plans de récupération préservent réellement les fonctions commerciales sur lesquelles les utilisateurs comptent.

Qu'est-ce que la résilience des applications ?

La résilience des applications est la capacité d'une application et de l'infrastructure qui l'entoure à continuer à fournir des fonctions vitales pendant une interruption et à se rétablir de manière prévisible après une défaillance.

La perturbation peut être petite ou grande, et les causes peuvent varier d'une défaillance matérielle ou du système d'exploitation, de plantages d'applications, de mises à jour échouées, de pannes de base de données, d'interruptions de réseau, d'échecs d'authentification, d'épuisement des ressources, de dépendances non disponibles ou d'incidents de sécurité.

Une architecture résiliente reconnaît que les pannes sont inévitables, et au lieu de viser à prévenir chaque incident, les organisations informatiques cherchent à limiter l'impact de chacun et à établir des procédures de récupération contrôlées pour maintenir ou restaurer le service.

La résilience des applications est plus qu'un temps de disponibilité du serveur

Une erreur courante consiste à utiliser la disponibilité d'un serveur comme un indicateur de la disponibilité de l'application, qui fonctionne sur le serveur.

Pour qu'une application professionnelle soit véritablement disponible, un certain nombre de composants doivent être disponibles en même temps :

Infrastructure → Système d'exploitation → Application → Dépendances → Chemin d'accès → Session utilisateur → Processus métier

Un problème avec un élément de cette chaîne peut entraîner une indisponibilité effective de l'application.

Par exemple, un serveur d'application peut être en bonne santé tandis que sa base de données est inaccessible. Une application publiée peut fonctionner correctement, mais une défaillance de la passerelle empêche les employés à distance d'y accéder. Les utilisateurs peuvent même lancer l'application avec succès mais être empêchés de finaliser une transaction parce qu'un service de licence, de fichier ou de backend est indisponible.

La résilience des applications, par conséquent, devrait être mesurée en fonction de la capacité de l'utilisateur à effectuer la tâche commerciale nécessaire, plutôt que de savoir si un serveur est capable de répondre à un contrôle de disponibilité ou de santé.

Pourquoi la résilience des applications est-elle différente pour les applications Windows ?

Les pratiques modernes de résilience se concentrent de plus en plus sur les applications cloud-native, les conteneurs, les microservices et l'orchestration automatisée. Bien que ces approches soient précieuses, elles ne sont pas toujours applicables à chaque organisation.

De nombreuses organisations ont des applications métiers Windows héritées qui ont été développées avant que les architectures cloud-native ne soient courantes. Les logiciels ERP, les applications de comptabilité, les applications de fabrication, les applications de santé, les applications d'ingénierie et les applications développées en interne peuvent toutes être essentielles aux opérations d'une organisation.

Reconcevoir ces applications en tant que microservices peut être extrêmement coûteux, techniquement difficile, voire complètement impraticable si l'organisation ne contrôle pas le code source.

Dans de tels cas, il peut être très utile de rendre les opérations autour de l'application plus résilientes, plutôt que d'essayer de rendre l'application elle-même plus résiliente. Publication d'applications peut faire partie de cette approche en maintenant les applications Windows existantes sur une infrastructure centralisée tout en modifiant la façon dont les utilisateurs y accèdent. Cela peut inclure des changements à l'infrastructure hébergeant l'application, tels que l'élimination des contraintes d'infrastructure, la création d'hôtes d'application redondants, l'activation de méthodes d'accès alternatives et la mise en œuvre de procédures de récupération plus réactives pour l'hôte d'application.

Dans quel cas la disponibilité d'une application Windows pourrait-elle échouer ?

La construction de la résilience des applications commence par la découverte des composants nécessaires pour livrer avec succès une application de leurs hôtes aux utilisateurs. Ce processus met en évidence les points de défaillance potentiels qui peuvent faire tomber une application entière.

Hôtes d'application

Une application fonctionnant sur un seul serveur Windows a un point de défaillance unique clair.

Des problèmes matériels, des mises à jour de Windows, une corruption du système d'exploitation, une exhaustion des ressources ou une défaillance d'application peuvent perturber chaque utilisateur dépendant de cette machine. Si les besoins de disponibilité l'exigent, plusieurs hôtes d'application peuvent être mis en place pour réduire la dépendance à une seule machine et fournir de la capacité lorsqu'un serveur devient indisponible.

Bases de données, stockage et autres dépendances

De nombreuses applications Windows dépendent de services externes à l'hôte de l'application. Ces services peuvent inclure :

• bases de données SQL
• partages de fichiers
• serveurs de licence
• Active Directory
• Système de noms de domaine (DNS)
• certificats
• APIs
• middleware
• stockage en réseau
• infrastructure d'impression

Introduire un deuxième serveur d'application offre une résilience minimale s'ils partagent une base de données ou une dépendance de stockage commune qui n'est pas disponible. Il devient évident que la cartographie des dépendances doit s'étendre au-delà de l'infrastructure d'application visible.

Authentification et identité

Les utilisateurs ne peuvent pas accéder à une application saine si l'infrastructure d'authentification nécessaire est indisponible.

Les équipes informatiques doivent identifier les services d'identité dont dépendent leurs applications critiques et s'assurer qu'elles disposent de plans de secours en place lorsque ces ressources sont inaccessibles. Active Directory, les plateformes d'identité cloud, les services d'authentification multi-facteurs (MFA) et les passerelles d'authentification peuvent tous être utilisés pour fournir une chaîne de disponibilité pour une application.

Réseau et chemins d'accès à distance

Pour les applications Windows centralisées, la connectivité entre les utilisateurs et l'environnement d'application représente un autre domaine de défaillance possible.

Imaginons la chaîne complète :

Appareil utilisateur → Internet ou LAN → passerelle → hôte d'application → services backend

Une panne à n'importe quel endroit de cette chaîne peut empêcher les utilisateurs d'effectuer leur travail même si l'application fonctionne correctement. Cela est particulièrement pertinent pour les organisations distribuées où l'application peut être opérationnelle dans le centre de données mais inaccessible aux utilisateurs à un autre emplacement.

Points de terminaison

La résilience des applications ne nécessite pas nécessairement que le poste de travail normal d'un utilisateur soit disponible.

Offrir aux utilisateurs autorisés les moyens d'accéder à des applications hébergées de manière centralisée depuis un appareil alternatif ou via un navigateur peut garantir l'accès, si un ordinateur portable devient indisponible, qu'un bureau devient inaccessible ou que des employés doivent travailler depuis un autre emplacement.

L'architecture de livraison d'applications peut être un élément d'une stratégie de continuité des activités plus large.

Quel est le processus de construction de la résilience des applications pour les applications Windows ?

Aucune technologie unique ne rend l'application résiliente. Les équipes informatiques doivent plutôt réduire le nombre de pannes pouvant entraîner l'arrêt complet d'une fonction et se préparer à des mécanismes de récupération contrôlée pour celles qui restent.

1. Identifier les applications critiques et les processus métier

Toutes les applications ne nécessitent pas le même degré de protection. Commencez par déterminer quelles applications soutiennent les opérations principales, sur lesquelles les utilisateurs comptent et leur tolérance aux temps d'arrêt.

Deux objectifs de récupération traduisent les exigences commerciales en spécifications techniques. Les directives de planification de contingence du NIST définit l'objectif de temps de récupération (RTO) et l'objectif de point de récupération (RPO) comme des paramètres clés pour déterminer les exigences de récupération :

• Objectif de Temps de Récupération (RTO) : une durée d'interruption acceptable avant que le service ne soit rétabli.
• Objectif de point de récupération (RPO) : un intervalle de perte de données acceptable, mesuré dans le temps.

Une application utilisée intensivement pour traiter des commandes peut avoir un RTO de quelques minutes, tandis qu'une application de reporting financier exécutée une fois par semaine peut se permettre des jours d'interruption.

RTO et RPO définissent le type de protection nécessaire pour une application : basculement instantané, rétablissement rapide des services ou simplement une procédure de récupération documentée.

2. Cartographier l'ensemble de la chaîne de dépendance de l'application

Documentez tout ce qui doit être présent pour que l'application puisse faire son travail.

Ne vous arrêtez pas à l'exécutable ou au serveur Windows. N'oubliez pas les bases de données, le stockage, l'authentification, le DNS, le réseau, les certificats, les systèmes de licence, les passerelles et les services externes.

Pour chacun, demandez :

Que se passe-t-il pour l'application si cela disparaît ?

Cet exercice mettra en évidence des points de défaillance uniques cachés et établira une séquence de récupération. Restaurer un hôte d'application en premier ne sert pas à grand-chose si sa base de données, son service d'identité ou son stockage n'est pas encore disponible.

3. Supprimer les points de défaillance critiques uniques

Une fois l'arbre de dépendance établi, déterminez quels composants doivent être rendus redondants, en fonction de l'importance commerciale et des objectifs de récupération.

Dans le cas de la livraison d'applications Windows, cela pourrait impliquer le déploiement de plusieurs serveurs d'applications plutôt que de s'appuyer sur les capacités d'un seul hôte. Avec une couche d'équilibrage de charge, les sessions peuvent être réparties entre les instances d'applications pendant les opérations normales. En cas de défaillance d'un hôte, les connexions entrantes peuvent être redirigées vers des instances de serveurs d'applications saines.

La planification de la redondance doit être informée par l'analyse de dépendance, cependant. Plusieurs serveurs d'application accédant à une seule base de données critique, passerelle réseau ou couche de stockage présentent toujours un point de défaillance unique.

La conception de haute disponibilité doit donc considérer le service d'application comme une entité intégrée. Pour les environnements Windows Server nécessitant une redondance au niveau de l'infrastructure, Documentation de la mise en cluster de basculement de Microsoft fournit des conseils supplémentaires sur les topologies de haute disponibilité et de récupération après sinistre.

4. Séparer les applications des points de terminaison individuels

Installer une application critique directement sur le poste de travail de chaque employé peut créer un autre type de problème de résilience. Si les utilisateurs perdent l'accès à leur ordinateur habituel, ils pourraient également perdre l'accès aux applications dont ils ont besoin pour continuer à travailler.

Centraliser les applications sur des hôtes Windows gérés et la présentation de l'interface de l'application aux utilisateurs élimine ce risque. Les données et l'état de l'application sont stockés sur l'hôte Windows géré et accessibles par des points de terminaison autorisés.

En faisant cela, nous rendons l'application disponible aux utilisateurs même s'ils changent d'appareils ou de lieux. Bien que la centralisation des applications n'élimine pas les problèmes d'infrastructure, elle aide à les déplacer dans un environnement où ils peuvent être contrôlés par l'informatique.

5. Fournir plus d'une méthode d'accès pratique

La résilience peut également être obtenue en évitant une dépendance inutile à un seul type de point de terminaison ou méthode de connexion.

Selon l'architecture de livraison des applications, les utilisateurs peuvent utiliser différents remote access méthodes, y compris un client compatible RDP, un lanceur d'application dédié, un portail web ou une session de navigateur HTML5.

Les méthodes de connexion alternatives ne doivent pas être confondues avec la redondance de l'infrastructure. Si tous dépendent du même serveur défaillant, l'application reste indisponible.

Ils fournissent une résilience d'accès lorsque la perturbation affecte l'appareil normal d'un utilisateur, le client installé ou l'emplacement plutôt que le service d'application lui-même.

6. Surveiller avant que la dégradation ne devienne une panne

La résilience des applications ne concerne pas seulement la récupération, mais une détection suffisamment précoce peut éviter la dégradation en une panne.

Les indicateurs utiles dans les environnements d'applications Windows sont l'utilisation du CPU, la pression mémoire, la capacité disque et I/O, l'utilisation du réseau, les sessions actives, le processus d'application, le temps de réponse, la connexion échouée et la disponibilité des services dépendants.

Surveillance des tendances est crucial, car un serveur qui approche constamment de ses limites peut rester en ligne tandis que l'expérience utilisateur se détériore progressivement.

Les alertes de seuil permettent aux administrateurs d'examiner les précurseurs d'un incident avant que les utilisateurs ne perdent l'accès.

7. Planifiez les pics de capacité et la bascule

Une application qui survit aux pannes au niveau matériel mais qui est complètement incapable de fonctionner sous des demandes accrues n'est pas vraiment résiliente aux pannes de quelque nature que ce soit.

La planification de la capacité doit prendre en compte non seulement les modèles d'utilisation quotidiens, mais aussi tenir compte des pics dus aux demandes saisonnières, aux changements de quarts, à la croissance ou aux exigences d'hébergement pour d'autres applications.

Particulièrement dans les environnements d'hébergement multi-serveurs, la perte d'un seul serveur doit être compensée en s'assurant que d'autres nœuds d'hébergement disposent d'une capacité supplémentaire pour accueillir tout processus qui serait autrement exécuté sur le nœud défaillant.

Sinon, les procédures de basculement peuvent simplement transformer un incident isolé en un large problème de performance du système.

8. Protéger les données et la configuration

Un serveur Windows de remplacement est peu utile si le service informatique ne peut pas restaurer les composants nécessaires pour faire fonctionner l'application.

Cela pourrait signifier que les procédures de sauvegarde doivent inclure les données d'application, les bases de données, les fichiers de configuration, les certificats, les paramètres d'application, les profils d'utilisateur, la configuration de l'infrastructure, les scripts et les informations de licence.

La stratégie variera en fonction de l'objectif de temps de récupération (RTO) et de l'objectif de point de récupération (RPO) de l'application.

Avant tout, assurez-vous qu'une sauvegarde réussie ne signifie pas une récupération réussie. Les équipes informatiques doivent tester qu'il est possible de restaurer l'ensemble du service d'application à partir des données et de la configuration protégées.

9. Réduire le rayon d'impact des changements

Il ne s'agit pas toujours d'un désastre imprévu qui cause des interruptions. Celles-ci peuvent également être causées par des améliorations mises en œuvre. Ainsi, les correctifs Windows, les mises à jour d'applications et de pilotes, ainsi que les modifications de politiques de sécurité et de configuration peuvent également avoir un impact négatif sur la disponibilité de l'application. Il est recommandé d'éviter d'apporter des modifications similaires à tous les hôtes de production en même temps si possible.

Dans une configuration multi-serveur, il est possible d'effectuer les modifications d'amélioration par étapes, permettant ainsi à l'administrateur de s'assurer que tout fonctionne correctement. La capacité de revenir sur les modifications apportées est également essentielle.

Ainsi, lors de la conception des procédures de contingence, les options de retour en arrière doivent également être prises en compte. Le processus doit être correctement documenté, et le personnel doit savoir quoi faire en cas d'échec d'un changement, au lieu de simplement laisser cela à leur discrétion.

10. Conception pour une dégradation élégante

La résilience ne consiste pas à maintenir 100 % des fonctions normales en fonctionnement à tout moment.

Dans certains cas, maintenir les opérations pour les utilisateurs ou applications clés peut être plus important que de garder tous les services disponibles pour tous les utilisateurs. Les priorités peuvent être établies avant qu'un incident ne se produise par les équipes informatiques.

S'il y a de la capacité disponible qui peut être utilisée, il peut être judicieux de l'allouer en premier à la production, au service client, aux finances ou à d'autres fonctions.

C'est une dégradation gracieuse : conserver la capacité d'exécuter les fonctions qui génèrent le plus de valeur commerciale, au lieu de laisser l'échec d'éléments moins critiques faire planter l'ensemble du système.

Comment les équipes informatiques devraient-elles surveiller la résilience des applications ?

La surveillance des serveurs individuels peut être utile, mais la surveillance de la résilience doit refléter le service d'application total tel que perçu par les utilisateurs.

Un modèle réaliste comprend plusieurs couches :

Couche	Ce qu'il faut surveiller	Échec d'exemple
Hôte	CPU, RAM, disque, disponibilité du système d'exploitation	Serveur surchargé ou hors ligne
Application	État des processus et des services	Les applications se bloquent
Dépendance	Base de données, DNS, identité, stockage	L'application se lance mais ne peut pas fonctionner.
Accès	Passerelle, portail, chemin réseau	Les utilisateurs ne peuvent pas se connecter
Session	Utilisateurs actifs, échecs, latence	L'application est en ligne mais inutilisable
Fonction commerciale	Achèvement réussi du flux de travail	L'utilisateur ne peut pas accomplir la tâche requise.

La couche fonctionnelle de l'entreprise est l'une des plus simples à négliger.

Les tableaux de bord d'infrastructure peuvent montrer tous les serveurs, services et chemins réseau comme étant sains, tandis que le flux de travail d'un utilisateur réel est compromis. Il est donc important que les applications critiques surveillent leur santé du point de vue de l'opération qu'elles sont conçues pour soutenir.

Comment la résilience des applications doit-elle être testée ?

Une architecture de résilience qui n'a jamais connu d'échec contrôlé contient des hypothèses non testées.

Utilisez des tests pour évaluer la réponse du système lorsque des composants clés deviennent indisponibles. Les tests doivent inclure la mise hors ligne d'un hôte d'application, l'arrêt d'un service d'application, la simulation de la perte d'un itinéraire réseau, la vérification du comportement de la passerelle ou de l'équilibrage de charge, la restauration à partir d'une sauvegarde et l'accès à l'application depuis un point de terminaison alternatif.

Les processus de test devraient s'étendre au-delà des aspects techniques de la récupération. Les équipes informatiques devraient vérifier si des alertes sont envoyées au bon personnel administratif, si les étapes de récupération sont effectuées dans le bon ordre, et si les utilisateurs sont capables d'effectuer une tâche commerciale réelle après que les services ont été rétablis.

Les procédures opérationnelles sont essentielles à un système résilient. Procédures d'escalade des alertes : qui reçoit l'alerte ? Qui a l'autorité pour initier le basculement ? Où sont stockés la documentation de récupération et les identifiants ? Quelle dépendance doit être mise en ligne en premier ?

La redondance technique offre peu d'avantages si les processus pour retrouver l'accès n'ont pas été testés.

Quelle peut être la liste de contrôle de la résilience des applications ?

Avant de se lancer dans une application Windows critique résiliente, les équipes informatiques devraient être en mesure de répondre aux questions suivantes :

• Quels processus commerciaux dépendent de l'application ?
• Quels sont ses RTO et RPO ?
• Quels serveurs, bases de données et services externes cela nécessite-t-il ?
• Où se trouvent ses points de défaillance critiques ?
• Une autre application hôte peut-elle accepter des utilisateurs si un hôte échoue ?
• Les utilisateurs peuvent-ils se connecter si leur point de terminaison ou leur emplacement normal n'est pas disponible ?
• Y a-t-il suffisamment de capacité de réserve pour un fonctionnement dégradé ?
• Les problèmes d'infrastructure, de dépendance et de session sont-ils activement surveillés ?
• Les administrateurs sont-ils alertés avant que des seuils importants ne deviennent des pannes ?
• Les données d'application et la configuration sont-elles protégées ?
• La restauration a-t-elle réellement été testée ?
• Les changements problématiques peuvent-ils être annulés ?
• La séquence de récupération est-elle documentée ?
• Les utilisateurs peuvent-ils compléter le processus commercial requis après la récupération ?

Toutes les réponses ne nécessitent pas une infrastructure coûteuse à haute disponibilité. Le bon niveau de protection dépend du coût et de l'impact opérationnel des temps d'arrêt.

Ce qui importe, c'est que les décisions concernant la disponibilité, la redondance et la récupération soient prises délibérément, plutôt que supposées.

Comment TSplus peut-il aider à maintenir les applications Windows disponibles ?

Pour les organisations qui s'appuient sur des applications Windows existantes, nous pouvons aider à améliorer la disponibilité en centralisant les applications sur des serveurs Windows gérés et en les livrant aux utilisateurs via des clients compatibles RDP, un accès de type RemoteApp ou un portail web HTML5. Cela réduit la dépendance aux points de terminaison individuels des utilisateurs et offre aux équipes informatiques plus de flexibilité lorsque les utilisateurs doivent se connecter depuis un autre appareil ou emplacement.

TSplus Remote Access peut également prendre en charge des déploiements multi-serveurs avec équilibrage de charge et accès basé sur un portail. Lorsqu'elle est combinée avec des bases de données résilientes, du stockage, des services d'identité et des réseaux, cette architecture peut réduire la dépendance à un seul hôte d'application et aider à maintenir l'accès aux applications Windows critiques pendant une interruption de l'infrastructure.

Conclusion

La résilience des applications dépend de la compréhension du chemin complet entre l'infrastructure et l'utilisation commerciale. La redondance, la surveillance, la sauvegarde, la planification de la capacité et les procédures de récupération sont les plus efficaces lorsqu'elles sont conçues autour de dépendances d'application et d'objectifs de récupération clairement définis.

Pour les applications Windows existantes, la résilience provient souvent du renforcement de l'environnement autour du logiciel plutôt que de la reconstruction de l'application elle-même. Le test clé reste simple : lorsque la perturbation se produit, les utilisateurs peuvent-ils continuer à travailler, ou l'informatique peut-elle restaurer la fonction commerciale requise dans la fenêtre de récupération convenue ?