Liste de vérification de la résilience pour des services Azure spécifiques

  • Article

La résilience est la capacité d’un système à récupérer après des défaillances et à continuer de fonctionner. Chaque technologie a ses propres modes d’échec, que vous devez prendre en compte lorsque vous concevez et implémentez votre application. Utilisez cette liste de vérification pour passer en revue les considérations relatives à la résilience de services Azure spécifiques. Pour plus d’informations sur la conception d’applications résilientes, consultez Concevoir des applications Azure résilientes.

App Service

Utilisez le niveau Standard ou Premium. Ces niveaux prennent en charge les emplacements de préproduction et les sauvegardes automatisées. Pour plus d’informations, consultez la rubrique Présentation détaillée des plans Azure App Service

Évitez de monter ou de descendre en puissance. À la place, sélectionnez un niveau et une taille d’instance répondant à vos besoins de performances sous une charge normale, puis effectuez un scale-out des instances pour gérer les changements dans le volume de trafic. Le fait de monter ou de descendre en puissance peut déclencher un redémarrage de l’application.

Stockez la configuration en tant que paramètres de l’application. Utilisez les paramètres de l’application pour conserver les paramètres de configuration en tant que paramètres de l’application. Définissez les paramètres dans vos modèles Resource Manager ou à l’aide de PowerShell afin de pouvoir les appliquer dans le cadre d’un processus de déploiement/mise à jour automatisé, ce qui est plus fiable. Pour plus d’informations, consultez Configurer des applications web dans Azure App Service.

Créez des plans App Service distincts pour la production et les tests. N’utilisez pas les emplacements de votre déploiement de production pour les tests. Toutes les applications qui se trouvent dans un même plan App Service partagent les mêmes instances de machines virtuelles. Si vous placez des déploiements de production et de test dans le même plan, cela peut avoir un impact négatif sur le déploiement de production. Par exemple, des tests de charge peuvent dégrader le site de production réelle. En plaçant les déploiements de test dans un plan séparé, vous les isolez de la version de production.

Séparez les applications web des API web. Si votre solution présente à la fois un serveur web frontal et une API web, envisagez de les décomposer en applications App Service distinctes. Cette conception facilite la décomposition de la solution par charge de travail. Vous pouvez exécuter l’application web et l’API dans des plans App Service distincts et donc les mettre à l’échelle indépendamment l’une de l’autre. Si vous n’avez pas besoin de ce niveau d’extensibilité au départ, vous pouvez déployer les applications dans le même plan et les déplacer ultérieurement dans des plans distincts si nécessaire.

Déployez des plans App Service redondants dans les zones. Dans les régions prises en charge, les plans App Service peuvent être déployés en tant que zones redondantes, ce qui signifie que les instances sont automatiquement distribuées dans les zones de disponibilité. App Service distribue automatiquement le trafic entre les zones et gère le basculement si une zone subit une panne. Pour plus d’informations, consultez l’article Migrer App Service vers la prise en charge des zones de disponibilité.

Évitez d’utiliser la fonctionnalité de sauvegarde d’App Service pour sauvegarder des bases de données Azure SQL. Utilisez les sauvegardes automatisées SQL Database à la place. La fonctionnalité de sauvegarde d’App Service exporte la base de données dans un fichier .bacpac SQL, ce qui consomme des DTU.

Tirez parti d’un emplacement de préproduction pour vos déploiements. Créez un emplacement de déploiement pour la préproduction. Déployez les mises à jour de l’application dans l’emplacement de préproduction et vérifiez le déploiement avant de le basculer en production. Cela réduit le risque de déploiement d’une mise à jour incorrecte en production. De plus, toutes les instances seront ainsi préparées avant d’être basculées en production. Un grand nombre d’applications présentent un temps de préparation et de démarrage à froid important. Pour plus d’informations, consultez Configurer des environnements intermédiaires pour les applications web dans Azure App Service.

Créez un emplacement de déploiement pour stocker le dernier déploiement valide connu. Quand vous déployez une mise à jour en production, déplacez le déploiement de production précédent dans l’emplacement réservé au dernier déploiement valide connu. Vous pourrez ainsi plus facilement effectuer une restauration en cas de déploiement incorrect. Si vous détectez un problème plus tard, vous pourrez rapidement revenir à la dernière version correcte connue. Pour plus d’informations, voir la rubrique Application web de base.

Activez la journalisation des diagnostics, y compris la journalisation d’application la journalisation de serveur web. La journalisation est importante pour la surveillance et les diagnostics. Consultez Activer la journalisation des diagnostics pour les applications web dans Azure App Service.

Effectuez la journalisation dans un stockage Blob. Cela facilite la collecte et l’analyse des données.

Créez un compte de stockage distinct pour les journaux d’activité. N’utilisez pas le même compte de stockage pour les journaux d’activité et les données d’application. Cela permet d’empêcher la journalisation de dégrader les performances de l’application.

Analyser les performances. Utilisez un service d’analyse des performances tel que New Relic ou Application Insights pour analyser les performances et le comportement de l’application sous charge. L’analyse des performances vous offre des renseignements en temps réel sur l’application. Elle vous permet de diagnostiquer les problèmes et d’effectuer une analyse des causes premières des échecs.

Azure Load Balancer

Sélectionnez SKU standard. Standard Load Balancer fournit une dimension de fiabilité que Basic n'offre pas : celle des zones de disponibilité et de la résilience de zone. Cela signifie qu'en cas de défaillance d'une zone, votre instance redondante interzone de Standard Load Balancer ne sera pas affectée. Vos déploiements résisteront ainsi aux défaillances de zone au sein d'une région. En outre, Standard Load Balancer prend en charge l'équilibrage de charge global, ce qui protège également votre application des défaillances régionales.

Approvisionnez au moins deux instances. Déployez Azure LB avec au moins deux instances dans le backend. Une seule instance pourrait constituer un point de défaillance unique. À des fins de mise à l'échelle, vous pouvez associer Load Balancer à Virtual Machine Scale Sets.

Utilisez des règles sortantes. Les règles sortantes garantissent que vous n'êtes pas confronté à des échecs de connexion en raison de l'épuisement du port SNAT. En savoir plus sur la connectivité sortante. Bien que les règles de trafic sortant contribuent à améliorer la solution pour les déploiements de petite taille ou de taille intermédiaire, pour les charges de travail de production, nous recommandons de coupler Standard Load Balancer ou tout déploiement de sous-réseau avec VNet NAT.

Application Gateway

Approvisionnez au moins deux instances. Déployez une passerelle Application Gateway avec au moins deux instances. Une seule instance constitue un point de défaillance unique. Utilisez deux instances ou plus à des fins de redondance et d’extensibilité. Afin d’être éligible au SLA, vous devez approvisionner au moins deux instances moyennes ou grandes.

Azure Cosmos DB

Configurez la redondance de zone. Lorsque vous utilisez la redondance de zone, Azure Cosmos DB réplique de manière synchrone toutes les écritures dans les zones de disponibilité. Il bascule automatiquement en cas de panne de zone. Pour plus d’informations, consultez Obtenir la haute disponibilité avec Azure Cosmos DB.

Répliquez la base de données dans différentes régions. Azure Cosmos DB vous permet d’associer n’importe quel nombre de régions Azure à un compte de base de données Azure Cosmos DB. Une base de données Azure Cosmos DB peut présenter une région d’écriture et plusieurs régions de lecture. En cas de défaillance dans la région d’écriture, vous pouvez lire les données à partir d’un autre réplica. Le Kit de développement logiciel (SDK) client gère cela automatiquement. Vous pouvez également basculer la région d’écriture vers une autre région. Pour en savoir plus, voir Comment distribuer des données mondialement avec Azure Cosmos DB.

Event Hubs

Utilisez des points de contrôle. Un consommateur d’événements doit écrire sa position actuelle sur le stockage persistant selon un intervalle prédéfini. De cette façon, si le consommateur rencontre une erreur (par exemple, blocage du consommateur ou échec de l’hôte), une nouvelle instance peut reprendre la lecture du flux à partir de la dernière position enregistrée. Pour en savoir plus, consultez la section relative aux consommateurs d’événements.

Gérer les messages en double. Si un consommateur d’événements échoue, le traitement des messages reprend à partir du dernier point de contrôle enregistré. Les messages qui ont déjà été traités après le dernier point de contrôle seront traités à nouveau. Par conséquent, votre logique de traitement des messages doit être idempotente, ou l’application doit être en mesure de dédupliquer des messages.

Traiter les exceptions. En règle générale, un consommateur d’événements traite un lot de messages dans une boucle. Vous devez gérer les exceptions au sein de cette boucle de traitement, afin d’éviter de perdre un lot de messages entier lorsqu’un seul message provoque une exception.

Utiliser une file d’attente de lettres mortes. Si le traitement d’un message entraîne une défaillance non temporaire, placez le message dans une file d’attente de lettres mortes, afin de pouvoir suivre l’état. Selon le scénario, vous pourrez ultérieurement essayer de traiter le message une nouvelle fois, appliquer une transaction de compensation ou exécuter une autre action. Notez qu’un hub Event Hubs n’inclut aucune fonctionnalité de file d’attente de lettres mortes intégrée. Vous pouvez utiliser le Stockage File d’attente Azure ou Service Bus pour implémenter une file d’attente de lettres mortes, ou utiliser Azure Functions ou tout autre mécanisme d’événement.

Configurez la redondance de zone. Lorsque la redondance de zone est activée sur votre espace de noms, Event Hubs réplique automatiquement les modifications entre plusieurs zones de disponibilité. Si une zone de disponibilité échoue, le basculement se produit automatiquement. Pour plus d’informations, consultez Zones de disponibilité.

Implémenter la récupération d’urgence via le basculement vers un espace de noms Event Hubs secondaire. Pour en savoir plus, voir Géorécupération d’urgence Azure Event Hubs.

Cache Azure pour Redis

Configurez la redondance de zone. Lorsque la redondance de zone est activée sur votre cache, Azure Cache pour Redis répartit les machines virtuelles qui hébergent votre cache sur plusieurs zones de disponibilité. La redondance de zone offre une haute disponibilité et une tolérance aux pannes en cas de panne du centre de données. Pour plus d'informations, consultez Activer la redondance de zone pour Azure Cache pour Redis.

Configurez la géoréplication. La géo-réplication fournit un mécanisme permettant de lier deux instances de Cache Azure pour Redis de niveau Premium. Les données écrites dans le cache principal sont répliquées dans un cache secondaire en lecture seule. Pour plus d’informations, consultez Comment configurer la géo-réplication pour Azure Cache pour Redis.

Configurez la persistance des données. La persistance Redis vous permet de conserver les données stockées dans Redis. Vous pouvez également prendre des instantanés et sauvegarder les données que vous pouvez charger en cas de défaillance matérielle. Pour plus d’informations, consultez Comment configurer la persistance des données pour Azure Cache pour Redis Premium

Si vous utilisez Azure Cache pour Redis comme un cache de données temporaire et non comme un magasin persistant, ces suggestions peuvent ne pas s’appliquer.

Approvisionnez plusieurs réplicas. Utilisez au moins deux réplicas pour une haute disponibilité en lecture ou trois pour une haute disponibilité en lecture-écriture.

Utilisez la redondance de zone. Vous pouvez déployer des réplicas de recherche cognitive dans plusieurs zones de disponibilité. Cette approche permet à votre service de rester opérationnel même en cas de panne du centre de données. Pour plus d'informations, consultez Fiabilité dans la Recherche cognitive Azure

Configurez des indexeurs pour les déploiements multirégions. Si vous disposez d’un déploiement multirégion, prenez en considération vos options pour la continuité de l’indexation.

  • Si la source de données est géorépliquée, vous devez généralement faire pointer chaque indexeur de chaque service Recherche cognitive Azure régional vers son réplica de source de données local. Cependant, cette approche n’est pas recommandée pour les jeux de données volumineux stockés dans Azure SQL Database. La raison en est que la Recherche cognitive Azure ne peut pas effectuer d'indexation incrémentielle à partir de réplicas de base de données SQL secondaires, uniquement à partir de réplicas principaux. Pointez tous les indexeurs sur le réplica principal à la place. Après un basculement, pointez les indexeurs Recherche cognitive Azure vers le nouveau réplica principal.

  • Si la source de données n'est pas géorépliquée, pointez plusieurs indexeurs sur la même source de données, afin que les services de Recherche cognitive Azure dans plusieurs régions indexent en continu et indépendamment à partir de la source de données. Pour plus d’informations, consultez Considérations sur les performances et l’optimisation de Recherche Azure.

Service Bus

Utilisez le niveau Premium pour les charges de travail de production. Service Bus Premium Messaging met à disposition des ressources de traitement dédiées et réservées, ainsi qu’une capacité mémoire permettant de prendre en charge des performances et des débits prévisibles. Le niveau Premium Messaging donne également accès à de nouvelles fonctionnalités réservées dans un premier temps aux clients Premium. Vous pouvez décider du nombre d’unités de messagerie en fonction de la charge de travail prévue.

Gérer les messages en double. Si un serveur de publication échoue immédiatement après l’envoi d’un message, ou s’il rencontre des problèmes de réseau ou de système, il peut par erreur ne pas enregistrer que le message a été livré et envoyer deux fois le même message au système. La messagerie Service Bus peut gérer ce problème en permettant de détecter les doublons. Pour en savoir plus, consultez Détection des doublons.

Gérer les exceptions. Les API de messagerie génèrent des exceptions lorsqu’une erreur utilisateur, une erreur de configuration ou toute autre erreur se produit. Le code client (expéditeur et destinataire) doit traiter ces exceptions dans son code. Ce point est particulièrement important dans le traitement par lots, où la gestion des exceptions permet d’éviter de perdre la totalité d’un lot de messages. Pour plus d’informations, consultez Exceptions de la messagerie Service Bus.

Stratégie de nouvelle tentative. La messagerie Service Bus permet de choisir la meilleure stratégie de nouvelle tentative pour vos applications. La stratégie par défaut consiste à autoriser un maximum de 9 nouvelles tentatives et à attendre 30 secondes, mais ce délai peut être modifié ultérieurement. Pour en savoir plus, consultez Stratégie de nouvelle tentative : messagerie Service Bus.

Utiliser une file d’attente de lettres mortes. Si un message ne peut pas être traité ou transmis à un destinataire après plusieurs tentatives, il est placé dans une file d’attente de lettres mortes. Implémentez un processus permettant de lire les messages de la file d’attente des lettres mortes, de les inspecter et de remédier au problème. Selon le scénario, vous pouvez effectuer une nouvelle tentative de message tel quel, apporter des modifications et effectuer une nouvelle tentative, ou ignorer le message. Pour en savoir plus, consultez Vue d’ensemble des files d’attente de lettres mortes Service Bus.

Utilisez la redondance de zone. Lorsque la redondance de zone est activée sur votre espace de noms, Service Bus réplique automatiquement les modifications entre plusieurs zones de disponibilité. Si une zone de disponibilité échoue, le basculement se produit automatiquement. Pour plus d’informations, consultez la section Meilleures pratiques pour protéger les applications contre les pannes de Service Bus et les sinistres.

Utiliser la géorécupération d’urgence. La géorécupération d’urgence permet de s’assurer que le traitement des données continue à fonctionner dans une autre région ou un autre centre de données si toute une région Azure ou tout un centre de données Azure n’est plus accessible suite à une urgence. Pour plus d’informations, consultez Géorécupération d’urgence Azure Service Bus.

Stockage

Utilisez un stockage redondant entre les zones. La réplication par stockage redondant interzone (ZRS) copie vos données de façon synchrone dans trois zones de disponibilité Azure au sein de la région primaire. Si une zone de disponibilité subit une panne, Azure Storage bascule automatiquement vers une autre zone. Pour plus d’informations, consultez Redondance de Stockage Azure.

Lorsque vous utilisez la géo-redondance, configurez l'accès en lecture. Si vous utilisez une architecture multirégionale, utilisez un niveau de stockage approprié pour la redondance globale. Avec RA-GRS ou RA-GZRS, vos données sont répliquées dans une région secondaire. RA-GRS utilise un stockage localement redondant (LRS) dans la région primaire, tandis que RA-GZRS utilise un stockage redondant dans une zone (ZRS) dans la région primaire. Les deux configurations fournissent un accès en lecture seule à vos données dans la région secondaire. En cas de panne de stockage dans la région primaire, l’application peut lire les données à partir de la région secondaire si vous l’avez conçue pour cette éventualité. Pour plus d’informations, consultez Redondance de Stockage Azure.

Pour les disques de machine virtuelle, utilisez des disques managés.Les disques managés augmentent la fiabilité des machines virtuelles dans un groupe à haute disponibilité en isolant suffisamment les disques les uns des autres pour éviter les points de défaillance uniques. Par ailleurs, les disques managés ne sont pas soumis aux limites d’IOPS des disques durs virtuels créés dans un compte de stockage. Pour plus d’informations, consultez Gérer la disponibilité des machines virtuelles Windows dans Azure.

Pour le service Stockage File d’attente, créez une file d’attente de sauvegarde dans une autre région. Pour le service Stockage File d’attente, un réplica en lecture seule présente peu d’utilité, car vous ne pouvez pas mettre des éléments en file d’attente ou les en enlever. Créez une file d’attente de sauvegarde dans une autre région à la place. En cas de panne du service Stockage Azure, l’application peut utiliser la file d’attente de sauvegarde jusqu’à ce que la région primaire redevienne disponible. De cette façon, l’application peut continuer à traiter les nouvelles demandes pendant la panne.

SQL Database

Utilisez le niveau Standard ou Premium. Ces niveaux offrent une limite de restauration dans le temps plus importante (35 jours). Pour plus d’informations, consultez les options et performances de SQL Database.

Activez l’audit SQL Database. L’audit peut être utilisé pour identifier les attaques malveillantes et les erreurs humaines. Pour en savoir plus, voir Prise en main de l’audit de base de données SQL.

Utilisez la géoréplication active. Utilisez la géoréplication active pour créer une base de données secondaire accessible en lecture dans une autre région. Si votre base de données primaire échoue ou doit simplement être mise hors connexion, vous pouvez effectuer un basculement manuel vers la base de données secondaire. La base de données secondaire reste en lecture seule jusqu’à ce que vous effectuiez le basculement vers cette dernière. Pour plus d’informations, consultez Géoréplication active de SQL Database.

Utilisez le partitionnement. Envisagez d’utiliser le partitionnement pour partitionner la base de données horizontalement. Le partitionnement peut assurer une isolation des erreurs. Pour plus d’informations, consultez Scale-out avec Azure SQL Database.

Utilisez la limite de restauration dans le temps pour récupérer des erreurs humaines. La limite de restauration dans le temps permet de revenir à un état antérieur de la base de données. Pour plus d’informations, consultez Récupérer une base de données Azure SQL à l’aide des sauvegardes de base de données automatisées.

Utilisez la géorestauration pour récupérer d’une panne de service. La géorestauration assure la restauration d’une base de données à partir d’une sauvegarde géoredondante. Pour plus d’informations, consultez Récupérer une base de données Azure SQL à l’aide des sauvegardes de base de données automatisées.

Azure Synapse Analytics

Ne désactivez pas la géosauvegarde. Par défaut, Synapse Analytics effectue une sauvegarde complète de vos données dans un pool SQL dédié toutes les 24 heures en cas de récupération d’urgence. Nous vous recommandons de ne pas désactiver cette fonctionnalité. Pour plus d’informations, consultez Géosauvegardes.

SQL Server exécuté dans une machine virtuelle

Sauvegardez la base de données. Si vous utilisez déjà le service Sauvegarde Azure pour sauvegarder vos machines virtuelles, envisagez d’utiliser Sauvegarde Azure pour les charges de travail SQL Server à l’aide de DPM. Avec cette approche, il y a un rôle d’administrateur de sauvegarde pour l’organisation et une procédure de récupération unifiée pour les machines virtuelles et SQL Server. Autrement, utilisez la sauvegarde gérée SQL Server dans Microsoft Azure.

Traffic Manager

Effectuez une restauration manuelle. Après un basculement Traffic Manager, effectuez une restauration manuelle plutôt que de recourir à la restauration automatique. Avant d’effectuer la restauration, vérifiez que tous les sous-systèmes de l’application sont intègres. Sinon, l’application risque d’alterner continuellement entre les centres de données. Pour plus d’informations, consultez Exécuter des machines virtuelles Windows dans plusieurs régions à des fins de haute disponibilité.

Créez un point de terminaison de sonde d’intégrité. Créez un point de terminaison personnalisé qui rend compte de l’intégrité globale de l’application. Cela permet à Traffic Manager d’effectuer un basculement en cas d’échec d’un chemin critique, et pas simplement du serveur frontal. Le point de terminaison doit retourner un code d’erreur HTTP si une dépendance critique est défectueuse ou inaccessible. Cependant, ne signalez pas les erreurs liées aux services non critiques. Sinon, la sonde d’intégrité risque de déclencher un basculement inutilement, créant de faux positifs. Pour plus d’informations, consultez Surveillance et basculement des points de terminaison Traffic Manager.

Virtual Machines

Évitez d’exécuter une charge de travail de production sur une machine virtuelle unique. Un déploiement de machine virtuelle unique ne résiste pas aux maintenances planifiées ou non planifiées. Au lieu de cela, placez plusieurs machines virtuelles dans un groupe à haute disponibilité ou un groupe de machines virtuelles identiques, avec un équilibreur de charge à l’avant.

Spécifiez un groupe à haute disponibilité quand vous approvisionnez la machine virtuelle. Actuellement, il n’existe aucun moyen d’ajouter une machine virtuelle à un groupe à haute disponibilité après l’approvisionnement de la machine virtuelle. Quand vous ajoutez une nouvelle machine virtuelle à un groupe à haute disponibilité, veillez à créer une carte réseau pour la machine virtuelle, puis ajoutez cette carte au pool d’adresses principal sur l’équilibreur de charge. Sinon, l’équilibreur de charge n’acheminera pas le trafic vers cette machine virtuelle.

Placez chaque couche Application dans un groupe à haute disponibilité distinct. Dans une application multiniveau, ne placez pas de machines virtuelles de niveaux différents dans le même groupe à haute disponibilité. Les machines virtuelles d’un groupe à haute disponibilité sont réparties dans des domaines d’erreur et des domaines de mise à jour. Toutefois, pour tirer parti de la redondance des domaines d’erreur et des domaines de mise à jour, chaque machine virtuelle du groupe à haute disponibilité doit être en mesure de gérer les mêmes requêtes de clients.

Répliquez les machines virtuelles à l’aide d’Azure Site Recovery. Lorsque vous répliquez des machines virtuelles Azure à l'aide de Site Recovery, tous leurs disques sont répliqués en continu et de manière asynchrone dans la région cible. Les points de récupération sont créés à intervalle de quelques minutes. Cela vous donne un objectif de point de récupération (RPO) de l’ordre de quelques minutes. Vous pouvez effectuer des exercices de reprise d’activité autant de fois que vous le souhaitez sans impacter l’application de production ou la réplication en cours. Pour plus d’informations, consultez Effectuer un exercice de reprise d’activité sur Azure.

Choisissez la taille de machine virtuelle appropriée en fonction des exigences de performances. Quand vous déplacez une charge de travail existante vers Azure, commencez par choisir la taille de machine virtuelle qui correspond le mieux à vos serveurs locaux. Mesurez ensuite les performances de votre charge de travail réelle en termes de processeur, de mémoire et d’IOPS de disque, puis ajustez la taille si nécessaire. Vous aurez ainsi l’assurance que l’application se comportera comme prévu dans un environnement cloud. En outre, si vous avez besoin de plusieurs cartes réseau, tenez compte de la limite de la carte réseau pour chaque taille.

Utilisez des disques managés pour les machines virtuelles.Les disques managés augmentent la fiabilité des machines virtuelles dans un groupe à haute disponibilité en isolant suffisamment les disques les uns des autres pour éviter les points de défaillance uniques. Par ailleurs, les disques managés ne sont pas soumis aux limites d’IOPS des disques durs virtuels créés dans un compte de stockage. Pour plus d’informations, consultez Gérer la disponibilité des machines virtuelles Windows dans Azure.

Installez les applications sur un disque de données plutôt que sur le disque du système d’exploitation. Sinon, il se peut que vous atteigniez la limite de taille du disque.

Utilisez le service Sauvegarde Azure pour sauvegarder les machines virtuelles. Les sauvegardes assurent une protection contre la perte accidentelle de données. Pour plus d’informations, consultez Protéger les machines virtuelles Azure avec un coffre Recovery Services.

Activer les journaux de diagnostics. Incluez les mesures d’intégrité de base, les journaux d’activité d’infrastructure et les diagnostics de démarrage. Les diagnostics de démarrage peuvent vous aider à identifier un problème de démarrage si votre machine virtuelle refuse de démarrer. Pour plus d’informations, consultez Présentation des journaux de diagnostic Azure.

Configurer Azure Monitor. Collectez et analysez les données d’analyse à partir de machines virtuelles Azure, notamment le système d’exploitation invité et les charges de travail qui s’y exécutent, consultez Azure Monitor et Démarrage rapide : Azure Monitor.

Réseau virtuel

Pour autoriser ou bloquer des adresses IP publiques, ajoutez un groupe de sécurité réseau au sous-réseau. Bloquez l’accès aux utilisateurs malveillants ou autorisez l’accès uniquement aux utilisateurs qui disposent du privilège requis pour accéder à l’application.

Créez une sonde d’intégrité personnalisée. Les sondes d’intégrité de Load Balancer peuvent tester le protocole TCP ou HTTP. Si une machine virtuelle exécute un serveur HTTP, la sonde HTTP est un meilleur indicateur de l’état d’intégrité qu’une sonde TCP. Pour une sonde HTTP, utilisez un point de terminaison personnalisé qui signale l’intégrité globale de l’application, y compris toutes les dépendances critiques. Pour plus d’informations, consultez Vue d’ensemble de Azure Load Balancer.

Ne bloquez la sonde d’intégrité. La sonde d’intégrité de Load Balancer est envoyée à partir d’une adresse IP connue, à savoir 168.63.129.16. Ne bloquez le trafic à destination ou en provenance de cette adresse IP dans aucune stratégie de pare-feu ou règle NSG. Si vous bloquez la sonde d’intégrité, l’équilibreur de charge supprimera la machine virtuelle de la rotation.

Activez la journalisation de Load Balancer. Les journaux d’activité indiquent combien de machines virtuelles sur le serveur principal ne reçoivent pas de trafic réseau en raison d’une absence de réponse de la part de la sonde. Pour plus d’informations, consultez Analyse des journaux d’Azure Load Balancer.