Recommandations en matière de fiabilité

Azure Advisor vous aide à garantir et à améliorer la continuité de vos applications stratégiques. Vous pouvez recevoir des recommandations en matière de fiabilité sous l’onglet Fiabilité du tableau de bord Advisor.

1. Connectez-vous au portail Azure.

2. Recherchez et sélectionnez Advisor à partir de n’importe quelle page.

3. Dans le tableau de bord Advisor, sélectionnez l’onglet Fiabilité.

Plateforme AgFood

Effectuer la mise à niveau vers la dernière version du kit SDK ADMA DotNet

Nous avons identifié des appels à une version du kit SDK ADMA DotNet dont l’obsolescence est programmée. Pour garantir un accès ininterrompu à ADMA, aux fonctionnalités les plus récentes et aux améliorations des performances, passez à la dernière version du kit SDK.

Avantages potentiels : garantir un accès ininterrompu à ADMA

Pour plus d’informations, consultez Qu’est-ce qu’Azure Data Manager for Agriculture ?.

Effectuer la mise à niveau vers la dernière version d’ADMA Java SDK

Nous avons identifié des tentatives de contacter une version d’ADMA Java SDK dont l’abandon est planifié. Nous vous recommandons de passer à la dernière version de Sdk pour garantir un accès ininterrompu à ADMA, aux fonctionnalités les plus récentes et aux améliorations des performances.

Avantages potentiels : garantir un accès ininterrompu à ADMA

Pour plus d’informations, consultez Qu’est-ce qu’Azure Data Manager for Agriculture ?.

Effectuer la mise à niveau vers la dernière version du kit SDK ADMA Python

Nous avons identifié des appels à une version du kit SDK ADMA Python dont l’obsolescence est programmée. Pour garantir un accès ininterrompu à ADMA, aux fonctionnalités les plus récentes et aux améliorations des performances, passez à la dernière version du kit SDK.

Avantages potentiels : garantir un accès ininterrompu à ADMA

Pour plus d’informations, consultez Qu’est-ce qu’Azure Data Manager for Agriculture ?.

Effectuer la mise à niveau vers la dernière version kit SDK ADMA JavaScript

Nous avons identifié des appels à une version du kit SDK ADMA JavaScript dont l’obsolescence est programmée. Pour garantir un accès ininterrompu à ADMA, aux fonctionnalités les plus récentes et aux améliorations des performances, passez à la dernière version du kit SDK.

Avantages potentiels : garantir un accès ininterrompu à ADMA

Pour plus d’informations, consultez Qu’est-ce qu’Azure Data Manager for Agriculture ?.

Gestion des API

Migrez la Gestion des API service vers la plate-forme stv2

La prise en charge des instances Gestion des API hébergées sur la plate-forme stv1 sera mise hors service le 31 août 2024. Migrez vers la plateforme basée sur stv2 avant cela pour éviter toute interruption de service.

Avantages potentiels : améliorer la stabilité du service et tirer parti de nouvelles fonctionnalités de plateforme

Pour plus d’informations, consultez Mise hors service de la plateforme Gestion des API stv1 – Cloud Azure global (août 2024)

Échec de la rotation des certificats de nom d’hôte

La défaillance du service de gestion de l’API à actualiser le certificat de nom d’hôte à partir du coffre de clés peut entraîner l’utilisation d’un certificat périmé par le service et le blocage du trafic de l’API de runtime. Assurez-vous que le certificat existe dans le coffre de clés et que l’identité du service Gestion des API bénéficie d’un accès en lecture aux secrets.

Avantages potentiels : garantir la disponibilité du service

Pour plus d’informations, consultez Configurer un nom de domaine personnalisé pour votre instance Gestion des API Azure.

Le portail hérité a été déconseillé il y a 3 ans et mis hors service en octobre 2023. Cependant, nous constatons une utilisation active du portail qui pourrait causer une interruption de service bientôt lorsque nous le désactiverons.

Nous vous recommandons vivement de migrer vers le nouveau portail des développeurs dès que possible pour continuer à bénéficier de nos services et tirer parti des nouvelles fonctionnalités et améliorations.

Avantages potentiels : assurer la continuité de l’activité

Pour plus d’informations, consultez Migrer vers le nouveau portail des développeurs.

Échec de la vérification de l’état du réseau de dépendances

La dépendance du service Gestion des API Azure n’est pas disponible. Vérifiez la configuration du réseau virtuel.

Avantages potentiels : améliorer la stabilité du service

Pour plus d’informations, consultez Déployer votre instance Gestion des API Azure sur un réseau virtuel – mode externe.

Renégociation SSL/TLS bloquée

Tentative de renégociation SSL/TLS bloquée ; la communication sécurisée peut échouer. Pour prendre en charge les scénarios d’authentification de certificat client, activez « Négocier le certificat client » sur les noms d’hôtes listés. Pour les clients basés sur un navigateur, cette option peut entraîner la présentation d’une invite de certificat au client.

Avantages potentiels : garantir la disponibilité du service

Pour plus d’informations, consultez Comment sécuriser les API à l’aide d’une authentification par certificat client dans le service Gestion des API.

Déployer une instance du service Gestion des API Azure dans plusieurs régions Azure pour une disponibilité de service accrue

Le service Gestion des API Azure prend en charge le déploiement multirégion, ce qui permet aux éditeurs d’API d’ajouter des passerelles API régionales à une instance Gestion des API existante. Ce déploiement multirégions permet de réduire la latence de la requête telle qu’elle est perçue par les consommateurs distribués de l’API et améliore la disponibilité du service.

Avantages potentiels : résilience accrue contre les défaillances régionales

Pour plus d’informations, consultez Déployer une instance Gestion des API Azure sur plusieurs régions Azure.

Activez et configurez la mise à l'échelle automatique pour l'instance de gestion des API sur les charges de travail de production.

L'instance de gestion de l'API dans les niveaux de service de production peut être mise à l'échelle en ajoutant et en supprimant des unités. La fonction de mise à l'échelle automatique permet d'ajuster dynamiquement les unités d’une 'instance de gestion des API pour tenir compte d'un changement de charge sans intervention manuelle.

Avantages potentiels : augmenter la scalabilité et optimiser les coûts.

Pour plus d’informations, consultez Mettre automatiquement à l’échelle une instance Gestion des API Azure.

App Service

Évolution du plan d'App Service pour éviter l'épuisement de l'unité centrale

Une utilisation élevée de l'unité centrale peut entraîner des problèmes d'exécution des applications. Votre application a dépassé les 90 % de CPU au cours des derniers jours. Pour réduire l'utilisation de l'unité centrale et éviter les problèmes d'exécution, il convient d'étendre l'application.

Avantages potentiels : maintenir votre application saine

Pour plus d’informations, consultez Meilleures pratiques pour Azure App Service.

Consulter les problèmes d’intégrité de service de votre application

Nous avons une recommandation liée à l’intégrité de service de votre application. Ouvrez le Portail Azure, accédez à l’application, cliquez sur Diagnostiquer et résoudre les problèmes pour voir plus de détails.

Avantages potentiels : maintenir votre application saine

Pour plus d’informations, consultez Meilleures pratiques pour Azure App Service.

Corriger les paramètres de base de données de sauvegarde de votre ressource App Service

Lorsqu'une application a une configuration de base de données invalide, ses sauvegardes échouent. Pour plus de détails, consultez l'historique des sauvegardes de votre application sur la page de gestion de votre application.

Avantages potentiels : assurer la continuité de l’activité

Pour plus d’informations, consultez Meilleures pratiques pour Azure App Service.

Corriger les paramètres de stockage de sauvegarde de votre ressource App Service

Lorsqu'une application a des paramètres de stockage invalides, ses sauvegardes échouent. Pour plus de détails, consultez l'historique des sauvegardes de votre application sur la page de gestion de votre application.

Avantages potentiels : assurer la continuité de l’activité

Pour plus d’informations, consultez Meilleures pratiques pour Azure App Service.

Augmentez votre plan App Service SKU pour éviter les problèmes de mémoire

L'App Service Plan contenant votre application a dépassé 85% d'allocation de mémoire. Une forte consommation de mémoire peut entraîner des problèmes d'exécution de vos applications. Trouvez l'application qui pose problème et passez-la à un plan supérieur avec davantage de ressources mémoire.

Avantages potentiels : maintenir votre application saine

Pour plus d’informations, consultez Meilleures pratiques pour Azure App Service.

Scale-out de votre plan App Service

Effectuez un scale-out de votre plan App Service vers au moins deux instances afin d’éviter les délais dus aux démarrages à froid et les interruptions de service lors de la maintenance de routine.

Avantages potentiels : optimiser l’expérience utilisateur et la disponibilité

Pour plus d’informations, consultez https://aka.ms/appsvcnuminstances.

Correction du code de l'application, un processus de travailleur s'est arrêté à cause d'une exception non gérée

Un processus de travail dans votre application s'est arrêté à cause d'une exception non gérée. Pour identifier la cause première, recueillez des vidages de mémoire et des informations sur la pile d'appels au moment de la panne.

Avantages potentiels : maintenir votre application saine et hautement disponible

Pour plus d’informations, consultez https://aka.ms/appsvcproactivecrashmonitoring.

Changez votre App Service de niveau à un plan standard pour éviter les rejets de demande

Lorsqu'une application fait partie d'un plan App Service partagé et qu'elle atteint son quota plusieurs fois, les demandes entrantes peuvent être rejetées. Votre application web ne peut plus accepter de requêtes entrantes après avoir atteint un quota. Pour supprimer le quota, opérez une mise à niveau vers un plan Standard.

Avantages potentiels : maintenir votre application saine

Pour plus d’informations, consultez Présentation des plans Azure App Service.

Déplacer votre ressource App Service vers la version standard ou une version supérieure et utiliser des emplacements de déploiement

Lorsqu'une application est déployée plusieurs fois par semaine, des problèmes peuvent survenir. Vous avez déployé votre application plusieurs fois la semaine dernière. Pour vous aider à réduire l'impact du déploiement sur votre application web de production, déplacez votre ressource App Service vers le plan Standard (ou supérieur) et utilisez des créneaux de déploiement.

Avantages potentiels : maintenir votre application saine lors de la mise à jour

Pour plus d’informations, consultez Configurer des environnements de préproduction dans Azure App Service.

Envisagez de mettre à niveau le plan d’hébergement du service Static Web Apps de cet abonnement vers la référence SKU Standard.

La bande passante combinée utilisée par tous les services Static Web Apps de la référence SKU Gratuit de cet abonnement dépasse la limite mensuelle de 100 Go. Envisagez de mettre à niveau ces applications vers la référence SKU Standard pour éviter une limitation de bande passante.

Avantages potentiels : une disponibilité plus élevée pour les applications en évitant la limitation.

Pour plus d’informations, consultez Tarification – Static Web Apps.

Utiliser des emplacements de déploiement pour votre ressource App Service

Lorsqu'une application est déployée plusieurs fois par semaine, des problèmes peuvent survenir. Vous déployez votre application plusieurs fois au cours de la semaine dernière. Pour vous aider à gérer les changements et à réduire l'impact du déploiement sur votre application web de production, utilisez les créneaux de déploiement.

Avantages potentiels : maintenir votre application saine lors de la mise à jour

Pour plus d’informations, consultez Configurer des environnements de préproduction dans Azure App Service.

Envisagez de modifier l’architecture de votre application pour passer à une architecture 64 bits

Votre App Service est configuré en 32 bits et sa consommation de mémoire approche la limite de 2 Go. Si votre application l’accepte, envisagez de la recompiler et de modifier la configuration de l’App Service en 64 bits.

Avantages potentiels : améliorer la fiabilité de votre application

Pour plus d’informations, consultez FAQ sur les performances des applications pour Web Apps dans Azure.

Recommandation personnalisée CX Observer

Recommandation personnalisée CX Observer

Avantages potentiels : N/D

App Service Certificates

La vérification du domaine est requise pour émettre le certificat App Service Certificate

Vous disposez d’un certificat App Service Certificate qui se trouve actuellement en attente d’émission et nécessite une vérification de domaine. Si la propriété du domaine n’est pas validée, l’émission du certificat échouera. La vérification du domaine n’est pas automatisée pour les certificats App Service Certificate, une action est requise de votre part. Si vous avez récemment vérifié la propriété du domaine et que vous avez émis un certificat, vous pouvez ignorer ce message.

Avantages potentiels : garantir la réussite de l’émission d’App Service Certificate.

Pour plus d’informations, consultez Ajouter et gérer des certificats TLS/SSL dans Azure App Service.

Application Gateway

Mettez à niveau votre UGS ou ajoutez des instances supplémentaires

Le déploiement de deux ou plusieurs instances moyennes ou grandes garantit la continuité des activités (tolérance aux fautes) pendant les interruptions provoquées par une maintenance planifiée ou non.

Avantages potentiels : garantir la continuité des activités par le biais de la résilience de la passerelle d’application

Pour plus d’informations, consultez Équilibrage de charge multirégion – Architectures de référence Azure.

Éviter le remplacement du nom d’hôte pour garantir l’intégrité du site

Évitez de remplacer le nom d'hôte lors de la configuration de l’Application Gateway. Le fait d'avoir un domaine sur le front-end de la passerelle d'applications différent de celui utilisé pour accéder au back-end peut conduire à des cookies cassés ou à des URL de redirection. Assurez-vous que le back-end peut traiter la différence de problème, ou mettez à jour la configuration d’Application Gateway pour que le nom d’hôte ne doive pas être remplacé par le back-end. Lorsqu’il est utilisé avec App Service, associez un nom de domaine personnalisé à l’application web et évitez d’utiliser le nom d’hôte *.azurewebsites.net vers le serveur principal. Notez qu'un autre domaine front-end n’est pas un problème dans toutes les situations, et certaines catégories de back-ends comme les API REST, sont moins sensibles en général.

Avantages potentiels : garantir l’intégrité du site et éviter les cookies rompus ou rediriger les URL via une configuration Application Gateway résiliente.

Pour plus d’informations, consultez Résoudre les problèmes d’App Service dans Application Gateway.

Implémenter ExpressRoute Monitor sur Network Performance Monitor

Lorsque le circuit ExpressRoute n’est pas surveillé par ExpressRoute Monitor sur les performances du réseau, vous manquez les notifications de perte, de latence et de performances locales sur les ressources Azure et Azure vers les ressources locales. Pour une surveillance de bout en bout, implémentez ExpressRoute Monitor sur Network Performance.

Avantages potentiels : améliorer le délai de détection et d’atténuation des problèmes sur votre réseau, et obtenir des insights sur votre chemin réseau par le biais d’ExpressRoute

Pour plus d’informations, consultez Configurer Network Performance Monitor pour ExpressRoute (déconseillé).

Implémenter plusieurs circuits ExpressRoute dans votre réseau virtuel pour la résilience intersite

Lorsqu’une passerelle ExpressRoute ne possède qu’un seul circuit ExpressRoute associé, des problèmes de résilience peuvent se produire. Pour garantir la redondance et la résilience de l’emplacement de peering, connectez un ou plusieurs circuits supplémentaires à votre passerelle.

Avantages potentiels : améliorer la résilience en cas d’échec de l’emplacement de peering ExpressRoute

Pour plus d’informations, consultez Conception pour une haute disponibilité avec ExpressRoute.

Ajouter au moins un point de terminaison supplémentaire au profil, de préférence dans une autre région Azure

Les profils nécessitent plusieurs points de terminaison pour assurer une disponibilité en cas d’échec de l’un des points de terminaison. Nous recommandons également de placer les points de terminaison dans des régions différentes.

Avantages potentiels : améliorer la résilience en permettant le basculement

Pour plus d’informations, consultez Points de terminaison Traffic Manager.

Ajouter un point de terminaison configuré sur « Tout (international) »

Pour le routage géographique, le trafic est routé vers les points de terminaison dans les zones définies. En cas d’échec d’une région, il n’y a pas de basculement prédéfini. Le fait d'avoir un point de terminaison où le regroupement régional est configuré sur « Tout (international) » pour les profils géographiques permet d'éviter les trous noirs dans le trafic et garantit la disponibilité du service.

Avantages potentiels : améliorer la résilience en évitant les trous noirs de trafic

Pour plus d’informations, consultez Ajouter, désactiver, activer, supprimer ou déplacer des points de terminaison.

Ajouter ou déplacer un point de terminaison vers une autre région Azure

Tous les points de terminaison associés à ce profil de proximité sont dans la même région. Les utilisateurs des autres régions peuvent avoir une latence longue quand ils tentent de se connecter. L’ajout ou le déplacement d’un point de terminaison dans une autre région optimise les performances générales du routage de proximité et améliore la disponibilité en cas d’échec de tous les points de terminaison de la même région.

Avantages potentiels : améliorer la résilience en permettant le basculement vers une autre région

Pour plus d’informations, consultez Configurer la méthode de routage du trafic en fonction des performances.

Passer d’une passerelle de base à une référence SKU de passerelle de production

La référence SKU De base du VPN est conçue pour les scénarios de test ou de développement. Si vous utilisez la passerelle VPN pour la production, passez à une référence SKU de production, qui offre un plus grand nombre de tunnels, le protocole BGP (Border Gateway Protocol), la configuration active-active, des stratégies IPsec/IKE personnalisées et une stabilité et une disponibilité accrues.

Avantages potentiels : fonctionnalités supplémentaires disponibles et meilleures stabilité et disponibilité

Pour plus d’informations, consultez À propos des paramètres de configuration de la passerelle VPN.

Activer les passerelles en mode actif-actif pour la redondance

En configuration active/active, les deux instances de la passerelle VPN établissent des tunnels de site à site (S2S) VPN vers votre appareil VPN local. Quand un événement de maintenance planifié ou non planifié se produit sur une instance de passerelle, le trafic bascule automatiquement sur l'autre tunnel IPsec actif.

Avantages potentiels : garantir la continuité de l’activité via la résilience des connexions

Pour plus d’informations, consultez Concevoir une connectivité de passerelle hautement disponible pour les connexions intersites et de réseau virtuel à réseau virtuel.

Désactiver les sondes d’intégrité lorsqu’il n’existe qu’une seule origine dans un groupe d’origines

Si vous n’avez qu’une seule origine, Front Door route toujours le trafic vers celle-ci, même si sa sonde d’intégrité signale un état non sain. L’état de la sonde d’intégrité ne change en rien le comportement de Front Door. Dans ce scénario, les sondes d’intégrité n’apportent aucun avantage.

Avantages potentiels : garantir la disponibilité du service en réduisant le trafic de sonde d’intégrité inutile

Pour plus d’informations, consultez Meilleures pratiques pour Front Door.

Utiliser des certificats TLS managés

Lorsque Front Door gère vos certificats TLS, il réduit vos coûts opérationnels et vous aide à éviter des pannes coûteuses résultant d’un oubli de renouvellement de certificat. Front Door émet automatiquement des certificats TLS managés et assure leur rotation.

Avantages potentiels : garantir la disponibilité du service en laissant Front Door gérer et faire pivoter vos certificats

Pour plus d’informations, consultez Meilleures pratiques pour Front Door.

Utiliser une passerelle NAT pour la connectivité sortante

Empêchez les défaillances de connectivité dues à l’épuisement des ports de traduction d'adresses réseau source (SNAT) en utilisant la passerelle NAT pour le trafic sortant de vos réseaux virtuels. La passerelle NAT est mise à l’échelle dynamiquement et fournit des connexions sécurisées pour le trafic dirigé vers Internet.

Avantages potentiels : empêcher les échecs de connexion sortante avec la passerelle NAT

Pour plus d’informations, consultez Utiliser SNAT (Source Network Address Translation) pour les connexions sortantes.

Déployer votre application Gateway sur Zones de disponibilité

Obtenez une redondance de zone en déployant Application Gateway sur Zones de disponibilité. La redondance de zone améliore la résilience en permettant à Application Gateway de survivre à différentes pannes, ce qui garantit la continuité même si une zone est affectée et améliore la fiabilité globale.

Avantages potentiels : la résilience des passerelles Application Gateway est considérablement augmentée lors de l’utilisation de zones de disponibilité.

Pour plus d’informations, consultez Mise à l’échelle d’Application Gateway v2 et de WAF v2.

Mettre à jour l’autorisation de réseau virtuel des utilisateurs Application Gateway

Pour améliorer la sécurité et fournir une expérience plus cohérente dans Azure, tous les utilisateurs doivent passer avec succès une vérification d’autorisation pour créer ou mettre à jour une passerelle applicative dans un réseau virtuel. L'autorisation minimale requise pour les utilisateurs ou les responsables de service est Microsoft.Network/virtualNetworks/subnets/join/action.

Avantages potentiels : éviter les interruptions dans la gestion d’une ressource Application Gateway

Pour plus d’informations, consultez Configuration de l’infrastructure Application Gateway.

Utiliser le même nom de domaine sur Front Door et votre origine

Lorsque vous réécrivez l'en-tête de l’hôte, les cookies de requête et les redirections d'URL risquent d'être interrompus. Lorsque vous utilisez des plateformes comme Azure App Service, des caractéristiques telles que l'affinité de session et l'authentification et l'autorisation peuvent ne pas fonctionner correctement. Veillez à vérifier si votre application va fonctionner correctement.

Avantages potentiels : garantir l’intégrité de l’application en préservant le nom d’hôte d’origine

Pour plus d’informations, consultez Meilleures pratiques pour Front Door.

Mettre en œuvre la résilience de site pour ExpressRoute

Pour garantir une résilience maximale, Microsoft vous recommande de vous connecter à deux circuits ExpressRoute à deux emplacements de peering. L’objectif de la résilience maximale est d’améliorer la disponibilité et de garantir le plus haut niveau de résilience pour les charges de travail critiques.

Avantages potentiels : la résilience maximale dans ExpressRoute est conçue pour s’assurer qu’il n’existe pas de point de défaillance unique dans le chemin du réseau Microsoft. Pour ce faire, vous disposez de circuits doubles (2) sur deux emplacements différents et ce pour garantir la diversité des sites dans ExpressRoute. L’objectif de la résilience maximale est d’améliorer la disponibilité et de garantir le plus haut niveau de résilience pour les charges de travail critiques.

Pour plus d’informations, consultez Concevoir et bâtir Azure ExpressRoute pour la résilience.

Implémenter des passerelles ExpressRoute redondantes de zone

Implémentez une passerelle de réseau virtuel redondante dans les zones de disponibilité Azure. Cela apporte de la résilience, de l’extensibilité et une plus grande disponibilité à vos passerelles de réseau virtuel.

Avantages potentiels : offre une résilience et une redondance zonales pour ExpressRoute

Pour plus d’informations, consultez Créer des passerelles de réseau virtuel redondantes interzones dans les zones de disponibilité.

Vérifier que la mise à l’échelle automatique est utilisée pour améliorer les performances et la résilience

Lors de la configuration d’Application Gateway, nous vous recommandons d’approvisionner la mise à l’échelle automatique pour effectuer un scale-in et un scale-out en réponse à l’évolution de la demande. Cela permet de réduire les effets d’un seul composant défaillant.

Avantages potentiels : augmenter les performances et la résilience.

Pour plus d’informations, consultez Mise à l’échelle d’Application Gateway v2 et de WAF v2.

Itinéraires IP ExpressRoute proches de la limite spécifiée

Votre itinéraire ExpressRoute est proche de ses limites d’itinéraire IP. Le dépassement de ces limites perturbera la connectivité. La connectivité est restaurée une fois que les itinéraires sont dans les limites. Suggestions : surveillez régulièrement le nombre d’itinéraires. Examinez Virtual WAN RouteMap pour réduire les itinéraires IP publiés.

Avantages potentiels : la surveillance du nombre d’itinéraires IP permet d’éviter les problèmes de connectivité et garantit la stabilité.

Pour plus d’informations, consultez Questions fréquentes (FAQ) sur Virtual WAN.

Éviter de placer Traffic Manager derrière Front Door

L’utilisation de Traffic Manager en tant qu’une des origines de Front Door n’est pas recommandée, car cela peut entraîner des problèmes de routage. Si vous avez besoin des deux services dans une architecture à haute disponibilité, placez toujours Traffic Manager devant Azure Front Door.

Avantages potentiels : Augmenter la résilience de votre charge de travail

Pour plus d’informations, consultez Meilleures pratiques pour Front Door.

Penser à avoir au moins deux origines

Les origines multiples prennent en charge la redondance en distribuant le trafic entre plusieurs instances de l’application. Si une instance n’est pas disponible, les autres origines de back-end peuvent toujours recevoir du trafic.

Avantages potentiels : Augmenter la résilience de votre charge de travail

Pour plus d’informations, consultez Perspective d’Azure Well-Architected Framework sur Azure Front Door

Changer le sous-réseau de passerelle V1 nommé GatewaySubnet, car il est réservé au VPN/à ExpressRoute

Votre Application Gateway risque d’être supprimée après octobre 2024 en raison d’une mise à niveau interne ayant échoué. Cela est dû au sous-réseau nommé Gatewaysubnet, qui est réservé pour VPN/ExpressRoute. Pour résoudre ce problème, modifiez le sous-réseau ou migrez vers V2. Attendez un jour pour que le message disparaisse une fois le problème résolu

Avantages potentiels : Éviter les perturbations dans la gestion de la ressource Application Gateway V1

Pour plus d’informations, consultez Forum aux questions sur Application Gateway

Modifier le sous-réseau de passerelle V1, car le sous-réseau actuel contient une passerelle NAT

Votre Application Gateway risque d’être supprimée après octobre 2024 en raison d’une mise à niveau interne ayant échoué. Cela est dû au fait qu’elle ne dispose pas d’un sous-réseau dédié et contient une passerelle NAT. Pour résoudre ce problème, modifiez le sous-réseau, supprimez la passerelle NAT ou migrez vers V2. Attendez un jour pour que le message disparaisse une fois le problème résolu

Avantages potentiels : Éviter les perturbations dans la gestion de la ressource Application Gateway V1

Pour plus d’informations, consultez Forum aux questions sur Application Gateway

Réactiver l’abonnement pour débloquer la mise à niveau interne pour la passerelle V1

Votre Application Gateway risque d’être supprimée après octobre 2024 en raison d’une mise à niveau interne ayant échoué. Cela est dû au fait que l’abonnement est dans un état non actif. Pour résoudre ce problème, activez l’abonnement. Attendez un jour pour que ce message disparaisse, une fois le problème résolu.

Avantages potentiels : Éviter les perturbations dans la gestion de la ressource Application Gateway V1

Pour plus d’informations, consultez Réactiver un abonnement Azure désactivé

Passerelle d’application pour conteneurs

Migrer vers une version prise en charge d’AGC

La version de Passerelle d'application pour conteneurs a été approvisionnée avec une préversion et n’est pas prise en charge pour la production. Assurez-vous d’approvisionner une nouvelle passerelle en utilisant la dernière version de l’API.

Avantages potentiels : garantir la prise en charge et la résilience des charges de travail de production

Pour plus d’informations, consultez Qu’est-ce que la Passerelle d’application pour conteneurs ?.

Azure AI Search

Créez un service de recherche standard (2GB)

Les opérations d’indexation cessent de fonctionner lorsque le quota de stockage est dépassé. Vous êtes sur le point de dépasser votre quota de stockage de 2 Go. Si vous avez besoin de plus de stockage, créez un service de recherche standard ou ajoutez des partitions supplémentaires.

Avantages potentiels : capacité à gérer davantage de données

Pour plus d’informations, consultez https://aka.ms/azs/search-limits-quotas-capacity.

Créez un service de recherche standard (50 Mo)

Les opérations d’indexation cessent de fonctionner lorsque le quota de stockage est dépassé. Vous êtes sur le point de dépasser le quota de stockage de 50 Mo. Pour maintenir les opérations, créez un service de recherche de base ou standard.

Avantages potentiels : capacité à gérer davantage de données

Pour plus d’informations, consultez https://aka.ms/azs/search-limits-quotas-capacity.

Éviter de dépasser votre quota de stockage disponible en ajoutant d’autres partitions

En cas de dépassement de votre quota de stockage, l’exécution de requêtes reste possible, mais l’indexation ne fonctionne plus. Vous êtes sur le point de dépasser votre quota de stockage disponible. Ajoutez des partitions supplémentaires si vous avez besoin de davantage de stockage.

Avantages potentiels : possibilité d’indexer des données supplémentaires

Pour plus d’informations, consultez https://aka.ms/azs/search-limits-quotas-capacity.

Kubernetes compatible avec Azure Arc

Effectuer une mise à niveau vers la dernière version de l’agent de Kubernetes avec Azure Arc

Effectuez une mise à niveau vers la dernière version de l’agent pour bénéficier de la meilleure expérience Kubernetes avec Azure Arc, d’une amélioration de la stabilité et de nouvelles fonctionnalités.

Avantages potentiels : version la plus récente de l’agent Kubernetes avec Arc

Pour plus d’informations, consultez Mettre à niveau les agents Kubernetes avec Azure Arc.

Configuration Kubernetes avec Azure Arc

Mettre à niveau l’extension Microsoft Flux vers la version principale la plus récente

L’extension Microsoft Flux bénéficie d’une version principale. Planifiez une mise à niveau manuelle vers la dernière version majeure de Microsoft Flux pour tous les clusters Azure Kubernetes Service (AKS) et Kubernetes avec Azure Arc dans les 6 mois pour bénéficier d’un support continu et de nouvelles fonctionnalités.

Avantages potentiels : prise en charge continue et nouvelles fonctionnalités

Pour plus d’informations, consultez Extensions disponibles pour les clusters Kubernetes avec Azure Arc.

Changements cassants à venir pour l’extension Microsoft Flux

L’extension Microsoft Flux reçoit fréquemment des mises à jour pour la sécurité et la stabilité. La mise à jour à venir, conformément au projet flux OSS, modifie les API HelmRelease et HelmChart en supprimant les champs déconseillés. Pour éviter toute perturbation de votre charge de travail, des mesures s’imposent.

Avantages potentiels : amélioration de la stabilité, de la sécurité et des nouvelles fonctionnalités

Pour plus d’informations, consultez Extensions disponibles pour les clusters Kubernetes avec Azure Arc.

Mettre à niveau l’extension Microsoft Flux vers une version prise en charge

La version actuelle de Microsoft Flux sur un ou plusieurs clusters compatibles avec Azure Arc et clusters Azure Kubernetes n’est pas prise en charge. Pour obtenir des correctifs de sécurité, des correctifs de bogues et le support Microsoft, mettez à niveau vers une version prise en charge.

Avantages potentiels : obtenir les correctifs de sécurité, les correctifs de bogues et le support Microsoft

Pour plus d’informations, consultez Extensions disponibles pour les clusters Kubernetes avec Azure Arc.

Serveurs avec Azure Arc

Effectuer une mise à niveau vers la dernière version d’Azure Connected Machine Agent

Azure Connected Machine Agent est régulièrement mis à jour avec des correctifs de bogues, des améliorations en termes de stabilité et de nouvelles fonctionnalités. Mettez à niveau votre agent vers la dernière version pour bénéficier d’une expérience Azure Arc optimale.

Avantages potentiels : amélioration de la stabilité et des nouvelles fonctionnalités

Pour plus d’informations, consultez Gestion et maintenance de Connected Machine Agent.

Cache Azure pour Redis

Augmentez la réservation de mémoire pour la fragmentation

La fragmentation et la sollicitation de la mémoire peuvent entraîner des incidents de disponibilité. Pour réduire les échecs de cache en cas de sollicitation élevée de la mémoire, augmentez la réservation de mémoire pour la fragmentation par le biais du paramètre maxfragmentationmemory-reserved disponible dans les options des paramètres avancés.

Avantages potentiels : éviter les incidents de disponibilité quand votre cache a une fragmentation élevée de la mémoire

Pour plus d’informations, consultez Comment configurer Azure Cache pour Redis.

Configurer la géoréplication pour les instances de cache pour Redis afin d’augmenter la durabilité des applications

La géoréplication permet la récupération d’urgence pour les données en cache, même dans le cas improbable d’une défaillance régionale généralisée. Cela peut être essentiel pour les applications stratégiques. Nous recommandons de configurer une géoréplication passive pour les instances Azure Cache pour Redis Premium.

Avantages potentiels : la géoréplication permet la récupération d’urgence pour les données mises en cache.

Pour plus d’informations, consultez Configurer la géoréplication passive pour les instances Azure Cache pour Redis Premium.

Azure Container Apps

Recréer votre environnement Container Apps pour éviter les problèmes DNS

Il existe un problème de mise en réseau potentiel avec vos environnements Container Apps susceptibles de provoquer des problèmes DNS. Nous vous recommandons de créer un nouvel environnement Container Apps, recréer votre application conteneur dans le nouvel environnement, et supprimer l’ancien environnement Container Apps

Avantages potentiels : éviter les échecs DNS dans votre environnement Container Apps.

Pour plus d’informations, consultez Démarrage rapide : déployer votre première application de conteneur avec le Portail Azure.

Renouveler un certificat de domaine personnalisé

Le certificat de domaine personnalisé que vous avez chargé est sur le point d’expirer. Pour empêcher un éventuel temps d’arrêt du service, renouvelez votre certificat et chargez le nouveau certificat de vos applications de conteneurs.

Avantages potentiels : votre service échoue en raison d’un certificat expiré.

Pour plus d’informations, consultez Personnaliser les noms de domaine et apporter vos propres certificats dans Azure Container Apps.

Un problème empêche le renouvellement de votre certificat managé.

Nous avons détecté que le certificat managé utilisé par l’application conteneur n’a pas pu être renouvelé automatiquement. Suivez le lien vers la documentation pour vérifier que les paramètres DNS de votre domaine personnalisé sont corrects.

Avantages potentiels : éviter les temps d’arrêt en raison d’un certificat expiré.

Pour plus d’informations, consultez Noms de domaine et certificats gérés gratuits personnalisés dans Azure Container Apps.

Augmenter le nombre minimal de réplicas pour votre application conteneurisée

Le nombre minimal de réplicas défini pour votre application conteneurisée Azure Container App peut être trop faible, ce qui peut entraîner des problèmes de résilience, de scalabilité et d’équilibrage de charge. Envisagez d’augmenter le nombre minimal de réplicas pour une meilleure disponibilité.

Avantages potentiels : meilleure disponibilité pour votre application conteneur.

Pour plus d’informations, consultez Définir des règles de mise à l’échelle dans Azure Container Apps.

Azure Cosmos DB

Configurez les conteneurs Azure Cosmos DB avec une clé de partition

Lorsque les collections non partitionnée Azure Cosmos DB atteignent leur quota de stockage approvisionné, vous perdez la possibilité d’ajouter des données. Vos collections Cosmos DB non partitionnées sont sur le point d’atteindre leur quota de stockage approvisionné. Migrez-les vers de nouvelles collections avec une définition de clé de partition de manière à ce que le service puisse automatiquement effectuer un scale-out.

Avantages potentiels : mettre à l’échelle vos conteneurs de manière fluide avec une augmentation du stockage ou des taux de requête pour ne pas atteindre les limites

Pour plus d’informations, consultez Partitionnement et mise à l’échelle horizontale dans Azure Cosmos DB.

Utilisez les instances statiques du client Cosmos DB dans votre code et mettez en cache les noms des bases de données et des collections

Un nombre élevé d'opérations de métadonnées sur un compte peut entraîner une limitation du débit. Les opérations de métadonnées présentent une limite d’unités de requête réservées par le système. Évitez la limitation de débit par les opérations de métadonnées en utilisant des instances statiques de client Cosmos DB dans votre code et en mettant en cache les noms des bases de données et des collections.

Avantages potentiels : optimiser l’utilisation de vos RU et éviter la limitation du débit

Pour plus d’informations, consultez Conseils sur les performances pour Azure Cosmos DB et .NET SDK v2.

Vérifier l’hébergement de votre clé de chiffrement azure Key Vault liée

Lorsqu’un compte Azure Cosmos DB ne peut pas accéder à son Azure Key Vault lié hébergeant la clé de chiffrement, l’accès aux données et les problèmes de sécurité peuvent se produire. La configuration de votre Azure Key Vault empêche votre compte Cosmos DB de contacter le coffre de clés pour accéder à vos clés de chiffrement gérées. Si vous avez récemment effectué une rotation de clé, assurez-vous que la clé ou version de clé précédente reste activée et disponible jusqu’à ce que Cosmos DB ait terminé la rotation. La clé ou la version de clé précédente peut être désactivée après 24 heures ou une fois que les journaux d’audit Azure Key Vault n’affichent plus aucune activité Azure Cosmos DB sur cette clé ou version de clé.

Avantages potentiels : mettre à jour vos configurations pour continuer à utiliser des clés gérées par le client et accéder à vos données

Pour plus d’informations, consultez Configurer des clés gérées par le client pour votre compte Azure Cosmos DB avec Azure Key Vault.

Configurer le mode d’indexation cohérent sur les conteneurs Azure Cosmos DB

Les conteneurs Azure Cosmos configurés avec le mode d’indexation différé sont mis à jour de façon asynchrone, ce qui améliore les performances d’écriture, mais peut avoir un impact sur l’actualisation des requêtes. Votre conteneur est configuré avec le mode d’indexation différé. Si l’actualisation des requêtes est critique, utilisez le mode d’indexation cohérent pour les mises à jour immédiates de l’index.

Avantages potentiels : améliorer la cohérence et la fiabilité des résultats des requêtes

Pour plus d’informations, consultez Gérer les stratégies d’indexation dans Azure Cosmos DB.

Correctif logiciel - Effectuez une mise à niveau vers la version 2.6.14 du SDK Java Async v2 ou vers Java SDK v4

Il existe un bogue critique dans la version 2.6.13 (et versions antérieures) du kit de développement logiciel (SDK) Java asynchrone v2 d’Azure Cosmos DB qui provoque des erreurs lorsque l’on atteint un numéro LSN (numéro séquentiel dans le journal) global supérieur à la valeur maximale d’un entier. L’erreur est provoquée de manière transparente par le service lorsqu’un grand nombre de transactions ont eu lieu pendant la durée de vie d’un conteneur Azure Cosmos DB. Remarque : Même s’il s’agit d’un correctif critique pour le SDK Java Async v2, il est toujours vivement recommandé de passer au SDK Java v4.

Avantages potentiels : en cas d’inaction, toutes les opérations de création, de lecture, de mise à jour et de suppression peuvent commencer à échouer avec l’exception NumberFormatException

Pour plus d’informations, consultez Kit de développement logiciel (SDK) Java asynchrone Azure Cosmos DB pour l’API pour NoSQL (héritée) : notes de publication et ressources.

Problème critique - Effectuez une mise à niveau vers la version actuelle recommandée du SDK Java v4

Il existe un bogue critique dans la version 4.15 et versions antérieures du kit de développement logiciel (SDK) Java v4 d’Azure Cosmos DB, qui provoque des erreurs lorsque l’on atteint un numéro LSN supérieur à la valeur maximale d’un entier. Cela est effectué de façon transparente par le service lorsqu’un grand nombre de transactions ont eu lieu pendant la durée de vie d’un conteneur Azure Cosmos DB. Évitez ce problème en effectuant une mise à niveau vers la version recommandée actuelle du Kit de développement logiciel (SDK) Java v4

Avantages potentiels : en cas d’inaction, toutes les opérations de création, de lecture, de mise à jour et de suppression peuvent commencer à échouer avec l’exception NumberFormatException

Pour plus d’informations, consultez Kit de développement logiciel (SDK) Java Azure Cosmos DB v4 pour l’API pour NoSQL : notes de publication et ressources.

Utiliser le nouveau point de terminaison 3.6+ pour vous connecter à votre compte d’API Azure Cosmos DB pour MongoDB mis à niveau

Certaines de vos applications se connectent à votre compte d’API Azure Cosmos DB pour MongoDB mis à niveau à l’aide du point de terminaison 3.2 hérité - [accountname].documents.azure.com. Utilisez le nouveau point de terminaison - [accountname].mongo.cosmos.azure.com (ou son équivalent dans les clouds souverains, gouvernementaux ou limités).

Avantages potentiels : tirer parti des dernières fonctionnalités de la version 3.6+ de l’API Azure Cosmos DB pour MongoDB

Pour plus d’informations, consultez Azure Cosmos DB for MongoDB (version serveur 4.0) : fonctionnalités et syntaxe prises en charge.

Mettre à niveau votre compte d’API Azure Cosmos DB pour MongoDB vers la version 4.2 pour réduire les coûts des requêtes/du stockage et utiliser les nouvelles fonctionnalités

Votre compte d’API Azure Cosmos DB pour MongoDB peut être mis à niveau vers la version 4.2. La mise à niveau vers la version 4.2 peut réduire les coûts de stockage de jusqu’à 55 % et les coûts de vos requêtes de jusqu’à 45 % en tirant parti d’un nouveau format de stockage. De nombreuses autres fonctionnalités, comme les transactions multidocuments, sont également présentes dans la version 4.2.

Avantages potentiels : fiabilité améliorée, efficacité des requêtes/du stockage, performances et nouvelles fonctionnalités

Pour plus d’informations, consultez Mettre à niveau la version d’API de votre compte Azure Cosmos DB for MongoDB.

Activer la nouvelle tentative côté serveur (SSR) sur l’API de votre base de données Azure Cosmos DB pour le compte MongoDB

Lorsqu’un compte lève une erreur TooManyRequests avec le code d’erreur 16500, l’activation de la nouvelle tentative côté serveur (SSR) peut aider à atténuer le problème.

Avantages potentiels : empêcher la limitation et améliorer la fiabilité et les performances de vos requêtes

Ajouter une deuxième région à vos charges de travail de production sur Azure Cosmos DB

Les charges de travail de production sur Azure Cosmos DB exécutées dans une seule région peuvent avoir des problèmes de disponibilité, cela semble être le cas avec certains de vos comptes Cosmos DB. Augmentez leur disponibilité en les configurant de façon à ce qu’ils s’étendent sur au moins deux régions Azure. REMARQUE : les régions supplémentaires entraînent des coûts additionnels.

Avantages potentiels : améliorer la disponibilité de vos charges de travail de production

Pour plus d’informations, consultez Haute disponibilité (fiabilité) dans Azure Cosmos DB for NoSQL.

Mettez à niveau l’ancienne version du SDK Azure Cosmos DB vers la dernière version

Un compte Azure Cosmos DB utilisant une ancienne version du Kit de développement logiciel (SDK) ne dispose pas des derniers correctifs et améliorations. Votre compte Azure Cosmos DB utilise une ancienne version du SDK. Pour bénéficier des derniers correctifs, de performances accrues et de nouvelles fonctionnalités, mettez à niveau vers la dernière version.

Avantages potentiels : fiabilité améliorée, performances accrues et nouvelles fonctionnalités

Pour plus d’informations, consultez la documentation Azure Cosmos DB.

Changer de niveau d’un kit SDK Azure Cosmos DB obsolète et passer à la dernière version

Un compte Azure Cosmos DB utilisant une ancienne version du kit de développement logiciel (SDK) ne dispose pas des derniers correctifs et améliorations. Votre compte Azure Cosmos DB utilise une version obsolète du SDK. Nous vous recommandons de le mettre à niveau vers la dernière version pour bénéficier des derniers correctifs, de performances accrues et de nouvelles fonctionnalités.

Avantages potentiels : fiabilité améliorée, performances accrues et nouvelles fonctionnalités

Pour plus d’informations, consultez la documentation Azure Cosmos DB.

Activer le basculement géré par le service pour le compte Cosmos DB

Activer le basculement géré par le service pour le compte Cosmos DB pour garantir une haute disponibilité du compte. Le basculement géré par le service bascule automatiquement la région d’écriture vers la région secondaire en cas de panne de la région principale. Cela assure que l’application continue de fonctionner sans aucun temps d’arrêt.

Avantages potentiels : la fonctionnalité de basculement géré par le service Azure améliore la disponibilité du système en automatisant les processus de basculement, en réduisant les temps d’arrêt et en améliorant la résilience.

Pour plus d’informations, consultez Haute disponibilité (fiabilité) dans Azure Cosmos DB for NoSQL.

Activer la HA pour votre charge de travail de production

De nombreux clusters avec des charges de travail cohérentes n’ont pas la haute disponibilité (HA) activée. Il est recommandé d’activer la haute disponibilité à partir de la page Mise à l’échelle du Portail Azure pour éviter les temps d’arrêt de la base de données en cas de défaillance inattendue des nœuds et pour bénéficier des garanties du SLA.

Avantages potentiels : activer la haute disponibilité pour éviter le temps d’arrêt de la base de données en cas d’échec inattendu d’un nœud

Pour plus d’informations, consultez Mise à l’échelle et configuration de votre cluster Azure Cosmos DB for MongoDB vCore.

Activer la redondance de zone pour les comptes Cosmos DB multirégions

Cette recommandation suggère d’activer la redondance de zone pour les comptes Cosmos DB multirégions afin d’améliorer la haute disponibilité et de réduire le risque de perte de données en cas de panne régionale.

Avantages potentiels : amélioration de la haute disponibilité et réduction du risque de perte de données

Pour plus d’informations, consultez Haute disponibilité (fiabilité) dans Azure Cosmos DB for NoSQL.

Ajoutez au moins un centre de données dans une autre région Azure

Votre cluster Azure Managed Instance pour Apache Cassandra est désigné comme un cluster de production mais est actuellement déployé dans une seule région Azure. Pour les clusters de production, nous recommandons d’ajouter au moins un autre centre de données dans une autre région Azure pour se prémunir contre les scénarios de reprise après sinistre.

Avantages potentiels : vérifier que les applications disposent d’une autre région en cas de récupération d'urgence

Pour plus d’informations, consultez Meilleures pratiques pour la haute disponibilité et la récupération d’urgence.

Éviter une limitation du débit pour l’opération du plan de contrôle

Nous avons trouvé plusieurs opérations du plan de contrôle sur votre compte par le fournisseur de ressources. La requête qui dépasse les limites documentées à des niveaux soutenus sur des périodes consécutives de 5 minutes peut être limitée, ainsi que les opérations incomplètes ou ayant échoué sur des ressources Azure Cosmos DB.

Avantages potentiels : optimiser l’opération du plan de contrôle et éviter l’échec de l’opération en raison de la limitation du débit

Pour plus d’informations, consultez Quotas du service Azure Cosmos DB.

Explorateur de données Azure

Résoudre les problèmes liés aux réseaux virtuels

L’installation ou la reprise du service a échoué en raison de problèmes de réseau virtuel (VNet). Pour résoudre ce problème, suivez les étapes décrites dans le guide de résolution des problèmes.

Avantages potentiels : fiabilité améliorée, disponibilité, performances accrues et nouvelles fonctionnalités

Pour plus d’informations, consultez Résoudre les problèmes d’accès, d’ingestion et de fonctionnement de votre cluster Azure Data Explorer dans votre réseau virtuel.

Ajouter une délégation de sous-réseau pour « Microsoft.Kusto/clusters »

Si un sous-réseau n’est pas délégué, le service Azure associé ne peut pas fonctionner dans celui-ci. Votre sous-réseau ne dispose pas la délégation requise. Déléguer votre sous-réseau pour « Microsoft.Kusto/clusters ».

Avantages potentiels : fiabilité améliorée, disponibilité, performances accrues et nouvelles fonctionnalités

Pour plus d’informations, consultez Qu’est-ce que la délégation de sous-réseau ?.

Azure Database pour MySQL

Haute disponibilité : ajouter une clé primaire à la table qui n’en a pas actuellement

Notre surveillance du système interne a identifié un important décalage de la réplication sur le serveur de secours à haute disponibilité. Ce décalage est principalement dû au fait que le serveur de secours relise des journaux de relais sur une table sans clé primaire. Pour résoudre ce problème et respecter les meilleures pratiques, il est recommandé d'ajouter des clés primaires à toutes les tables. Une fois cette opération effectuée, désactivez puis réactivez la haute disponibilité pour pallier le problème.

Avantages potentiels : en implémentant cette approche, le serveur de secours est protégé des effets négatifs d’un important décalage de la réplication dû à l’absence d’une clé primaire sur n’importe quelle table. Cette approche peut aider à réduire les temps de basculement et, en fin de compte, à contribuer à l’objectif de maintien de la continuité de l’activité.

Pour plus d’informations, consultez Résoudre les problèmes de latence de réplication dans Azure Database pour MySQL – Serveur flexible.

Réplication : ajouter une clé primaire à la table qui n’en a pas actuellement

Notre surveillance interne a permis d’observer un décalage de réplication significatif sur votre serveur réplica, car ce dernier rejoue des journaux de relais sur une table qui ne dispose pas d’une clé primaire. Pour que le serveur réplica puisse se synchroniser efficacement avec le serveur primaire et suivre les modifications, ajoutez des clés primaires aux tables du serveur principal, puis recréez le serveur réplica.

Avantages potentiels : en implémentant cette approche, le serveur réplica atteint un état de synchronisation étroite avec le serveur principal.

Pour plus d’informations, consultez Résoudre les problèmes de latence de réplication dans Azure Database pour MySQL – Serveur flexible.

Azure Database pour PostgreSQL

Supprimer des emplacements de réplication logique inactifs (important)

Les emplacements de réplication logique inactifs peuvent entraîner une dégradation des performances et une indisponibilité du serveur en raison de la rétention de fichiers WAL (write-ahead log) et de la génération de fichiers instantanés. Votre serveur flexible Azure Database pour PostgreSQL peut avoir des emplacements de réplication logique inactifs. CELA NÉCESSITE UNE ATTENTION IMMÉDIATE. Supprimez les emplacements de réplication inactifs ou commencez à consommer les modifications à partir de ces emplacements afin que le numéro séquentiel dans le journal (LSN) des emplacements progresse et soit proche du LSN actuel du serveur.

Avantages potentiels : améliorer la disponibilité de PostgreSQL en supprimant les emplacements de réplication logique inactifs

Pour plus d’informations, consultez Réplication logique et décodage logique dans Azure Database pour PostgreSQL – Serveur flexible.

Supprimer des emplacements de réplication logique inactifs

Lorsqu’un serveur flexible Orcas PostgreSQL possède des emplacements de réplication logique inactifs, une dégradation des performances et une indisponibilité du serveur en raison de la rétention de fichiers WAL (write-ahead log) et de la génération de fichiers instantanés peuvent se produire. CELA NÉCESSITE UNE ATTENTION IMMÉDIATE. Supprimez les emplacements de réplication inactifs ou commencez à consommer les modifications à partir de ces emplacements afin que le numéro séquentiel dans le journal (LSN) des emplacements progresse et soit proche du LSN actuel du serveur.

Avantages potentiels : améliorer la disponibilité de PostgreSQL en supprimant les emplacements de réplication logique inactifs

Pour plus d’informations, consultez Décodage logique.

Configurer le stockage de sauvegarde géoredondant

Configurer le GRS pour garantir que votre base de données répond à ses objectifs de disponibilité et de durabilité, même en cas de défaillance ou de catastrophe.

Avantages potentiels : garantit la récupération après une défaillance régionale ou un sinistre.

Pour plus d’informations, consultez Sauvegarde et restauration dans Azure Database pour PostgreSQL – Serveur flexible.

Définir des fenêtres de maintenance personnalisées pendant les heures creuses

Quand vous spécifiez des préférences de planification de la maintenance, vous pouvez choisir un jour de la semaine et une fenêtre de temps. Si vous n’en spécifiez pas, le système choisit des heures entre 23 h 00 et 7 h dans le fuseau horaire de la région de votre serveur. Choisissez un jour et une heure où l’utilisation est faible.

Avantages potentiels : la fenêtre de maintenance permet d’éviter la maintenance pendant les pics du système.

Pour plus d’informations, consultez Maintenance planifiée dans Azure Database pour PostgreSQL – Serveur flexible.

Azure IoT Hub

Mettre à niveau le runtime des appareils Microsoft Edge vers une version prise en charge pour IoT Hub

L’utilisation de versions obsolètes par les appareils Edge peut entraîner une détérioration des performances. Nous vous recommandons d'effectuer une mise à niveau vers la dernière version prise en charge du runtime Azure IoT Edge.

Avantages potentiels : veiller à la continuité de l’activité avec les dernières versions prises en charge pour vos appareils Edge

Pour plus d’informations, consultez Mettre à jour IoT Edge.

Mettre à niveau le SDK client de l’appareil vers une version prise en charge pour IotHub

Lorsque les appareils utilisent un kit de développement logiciel (SDK) obsolète, une détérioration des performances peut se produire. Certains ou tous vos appareils utilisent un kit de développement logiciel (SDK) obsolète. Nous vous recommandons de procéder à une mise à niveau vers une version prise en charge du kit de développement logiciel (SDK).

Avantages potentiels : veiller à la continuité de l’activité avec un SDK pris en charge pour vos appareils

Pour plus d’informations, consultez Kits de développement logiciel (SDK) Azure IoT Hub.

Tempête potentielle d’appareil IoT Hub détectée

Ce problème peut se produire quand au moins deux appareils tentent de se connecter au hub IoT en utilisant les mêmes informations d’identification (ID d’appareil). Quand le deuxième appareil (B) se connecte, le premier (A) est déconnecté. Puis (A) tente de se reconnecter à nouveau, ce qui entraîne la déconnexion de (B).

Avantages potentiels : améliorer la connectivité de vos appareils

Pour plus d’informations, consultez Comprendre et résoudre les erreurs Azure IoT Hub.

Mettre à niveau le kit de développement logiciel (SDK) Device Update pour IoT Hub vers une version prise en charge

Lorsqu’une instance Device Update pour IoT Hub utilise une version obsolète du kit SDK, elle n’obtient pas les dernières mises à niveau. Pour bénéficier des derniers correctifs, de performances accrues et de nouvelles fonctionnalités, mettez à niveau vers la dernière version du kit de développement logiciel (SDK) Device Update pour IoT Hub.

Avantages potentiels : garantir la continuité de l’activité avec le Kit de développement logiciel (SDK) pris en charge

Pour plus d’informations, consultez Qu’est-ce que Device Update pour IoT Hub ?.

Ajouter des unités hub IoT ou augmenter le niveau de référence SKU

Lorsqu’un hub IoT dépasse son quota de messages quotidien, des problèmes de fonctionnement et de coût peuvent survenir. Pour garantir un fonctionnement fluide à l’avenir, ajoutez des unités ou augmentez le niveau de référence SKU.

Avantages potentiels : IoT Hub peut recevoir à nouveau des messages.

Pour plus d’informations, consultez Comprendre et résoudre les erreurs Azure IoT Hub.

Azure Kubernetes Service (AKS)

Activer la mise à l’échelle automatique pour vos pools de nœuds système

Pour vous assurer que vos pods système sont planifiés même pendant des périodes de charge élevée, activez la mise à l’échelle automatique sur votre pool de nœuds système.

Avantages potentiels : l’activation de l’Autoscaler pour le pool de nœuds système garantit que les pods système sont planifiés et que le cluster peut fonctionner.

Pour plus d’informations, consultez Utiliser le programme de mise à l’échelle automatique de cluster dans Azure Kubernetes Service (AKS).

Avoir au moins 2 nœuds dans votre pool de nœuds système

Vérifiez que vos pools de nœuds système ont au moins 2 nœuds pour la fiabilité de vos pods système. Avec un seul nœud, votre cluster peut échouer en cas de défaillance matérielle ou de nœud.

Avantages potentiels : avoir 2 nœuds garantit la résilience par rapport aux défaillances de nœud.

Pour plus d’informations, consultez Gérer des pools de nœuds système dans Azure Kubernetes Service (AKS).

Créer un pool de nœuds système dédié

Un cluster sans pool de nœuds système dédié est moins fiable. Nous vous recommandons de dédier des pools de nœuds système pour servir uniquement les pods système critiques, ce qui permet d’éviter la pénurie de ressources entre le système et les pods utilisateur concurrents. Appliquer ce comportement à l’aide de l’altération CriticalAddonsOnly=true:NoSchedule sur le pool.

Avantages potentiels : garantit la fiabilité du cluster en empêchant la pénurie de ressources pour les pods système de base

Pour plus d’informations, consultez Gérer des pools de nœuds système dans Azure Kubernetes Service (AKS).

Veillez à ne pas utiliser de machines virtuelles de série B dans des environnements de production.

Lorsqu’un cluster a un ou plusieurs pools de nœuds utilisant une référence SKU de machine virtuelle burstable non recommandée, la capacité complète de processeur virtuel à 100 % n’est pas garantie. Veillez à ne pas utiliser de machines virtuelles de série B dans des environnements de production.

Avantages potentiels : meilleure pratique pour des performances cohérentes

Pour plus d’informations, consultez Série de tailles Bv1.

Azure NetApp Files

Configuration du site AD DS pour Azure Netapp Files AD Connector

Si Azure NetApp Files ne peut pas atteindre les contrôleurs de domaine de site AD DS attribués, le processus de découverte du contrôleur de domaine interrogera alors tous les contrôleurs de domaine. Des contrôleurs de domaine inaccessibles peuvent être utilisés, mais cela entraîne des problèmes de création de volume, de requêtes clientes, d’authentification et de modifications de connexion AD.

Avantages potentiels : optimiser la connectivité DNS avec Azure Netapp Files

Pour plus d’informations, consultez Comprendre les instructions relatives à la conception et à la planification de site Active Directory Domain Services pour Azure NetApp Files.

Vérifier que les rôles affectés au sous-réseau délégué Microsoft.NetApp disposent d’autorisation d'accès en lecture de sous-réseau

Les rôles requis pour la gestion des ressources Azure NetApp Files doivent disposer des autorisations « Microsoft.network/virtualNetworks/subnets/read » sur le sous-réseau délégué à Microsoft.NetApp. Si le rôle, qu’il soit personnalisé ou intégré, ne dispose pas de cette autorisation, les créations de volumes échouent.

Avantages potentiels : empêcher les échecs de création de volume en garantissant des autorisations de sous-réseau/lecture

Passez en revue la configuration SAP pour connaître les valeurs du délai d’expiration utilisées avec Azure NetApp Files

La haute disponibilité de SAP, lorsqu’il est utilisé avec Azure NetApp Files, repose sur la définition de valeurs appropriées du délai d’expiration pour éviter toute interruption de votre application. Consultez le lien « en savoir plus » pour vous assurer du respect par votre configuration des valeurs du délai d’expiration indiquées dans la documentation.

Avantages potentiels : améliorer la résilience de l’application SAP sur ANF

Pour plus d’informations, consultez Utiliser Azure pour héberger et exécuter des scénarios de charge de travail SAP.

Implémenter des stratégies de récupération d’urgence pour vos ressources Azure NetApp Files

Pour éviter la perte de données ou de fonctionnalités en cas de sinistre régional ou zonal, implémentez des techniques de récupération d’urgence courantes telles que la réplication inter-régions ou la réplication interzone pour vos volumes Azure NetApp Files.

Avantages potentiels : gérer facilement la récupération d’urgence avec les fonctionnalités de réplication Azure NetApp Files

Pour plus d’informations, consultez Comprendre les options de protection des données et de récupération d’urgence dans Azure NetApp Files.

Azure Netapp Files - Permet une disponibilité continue des volumes SMB

Pour la disponibilité continue, nous recommandons d'activer le volume de protocole SMB (Server Message Block) pour vos Azure Netapp Files.

Avantages potentiels : empêcher les interruptions d’application en activant la disponibilité continue pour les volumes SMB

Pour plus d’informations, consultez Activer la disponibilité continue sur des volumes SMB existants.

Azure Site Recovery

Activer la suppression réversible pour vos coffres Recovery Services

La suppression réversible vous permet de conserver vos données de sauvegarde dans le coffre Recovery Services pour une durée supplémentaire après la suppression, ce qui vous donne la possibilité de les récupérer avant leur suppression définitive.

Avantages potentiels : permet de récupérer les données de sauvegarde en cas de suppression accidentelle

Pour plus d’informations, consultez Suppression réversible pour la Sauvegarde Azure.

Activer la restauration inter-région pour votre coffre Recovery Services

La restauration inter-région (CRR) peut être utilisée pour restaurer des machines virtuelles Azure dans une région secondaire (une région jumelée Azure), ce qui facilite la récupération d’urgence.

Avantages potentiels : parmi les options de restauration, la restauration entre régions (CRR) vous permet de restaurer des machines virtuelles Azure dans une région secondaire, qui est une région jumelée Azure.

Pour plus d’informations, consultez Comment restaurer des données de machine virtuelle Azure dans le Portail Azure ?.

Azure Spring Apps

Mettre à niveau le service de configuration d’application vers Gen 2

Nous avons remarqué que vous utilisez toujours le service de configuration d’applications Gen1, dont le support prendra fin en avril 2024. Le service de configuration d’applications Gen2 offre de meilleures performances par rapport à Gen1 et la mise à niveau de Gen1 vers Gen2 est zéro temps d’arrêt. Nous vous recommandons donc de mettre à niveau dès que possible.

Avantages potentiels : stabilité et disponibilité plus élevées

Pour plus d’informations, consultez Utiliser le service de configuration d’application pour Tanzu.

Azure SQL Database

Activer la récupération d’urgence inter-région pour SQL Database

Activez la récupération d’urgence inter-région pour la continuité d’activité de la base de données Azure SQL en cas de panne régionale.

Avantages potentiels : l’activation de la récupération d’urgence crée une base de données secondaire lisible en continu pour une base de données primaire.

Pour plus d’informations, consultez Vue d’ensemble de la continuité d’activité avec Azure SQL Database.

Activez la redondance de zone pour la base de données Azure SQL afin d’assurer la haute disponibilité et la résilience.

Pour obtenir une haute disponibilité et une résilience, activez la redondance de zone afin que la SQL Database, ou le pool élastique, utilise des zones de disponibilité et s’assurer que la résilience de la base de données, ou du pool élastique, est résiliente aux défaillances zonales.

Avantages potentiels : l’activation de la redondance de zone garantit qu’Azure SQL Database est résilient aux défaillances matérielles et logicielles zonales et que la récupération est transparente pour les applications.

Pour plus d’informations, consultez Disponibilité via la redondance – Azure SQL Database.

Azure Stack HCI

Mettre à niveau vers la dernière version d’AKS activée par Arc

Passez à la dernière version de l'API/SDK d'AKS activée par Azure Arc pour bénéficier de nouvelles fonctionnalités et d'une meilleure stabilité.

Avantages potentiels : la dernière version d’AKS activée par Azure Arc avec de nouvelles fonctionnalités et une stabilité améliorée.

Pour plus d’informations, consultez https://azure.github.io/azure-sdk/releases/latest/index.html.

Mettre à niveau vers la dernière version d’AKS activée par Arc

Passez à la dernière version de l'API/SDK d'AKS activée par Azure Arc pour bénéficier de nouvelles fonctionnalités et d'une meilleure stabilité.

Avantages potentiels : la dernière version d’AKS activée par Azure Arc avec de nouvelles fonctionnalités et une stabilité améliorée.

Pour plus d’informations, consultez https://azure.github.io/azure-sdk/releases/latest/index.html.

Stockage avec modèle de déploiement classique

Action requise : Migrer les comptes de stockage classiques avant le 30/08/2024.

Migrer vos comptes de stockage classiques vers Azure Resource Manager pour assurer la continuité de vos activités. Azure Resource Manager fournit toutes les mêmes fonctionnalités, ainsi qu’une couche de gestion cohérente, un groupe de ressources et un accès aux nouvelles fonctionnalités et mises à jour.

Avantages potentiels : assurez-vous de pouvoir gérer vos données en migrant votre ou vos comptes de stockage classiques

Machine virtuelle avec modèle de déploiement classique

Migrer hors des Services cloud (classique) avant le 31 août 2024

Cloud Services (classique) est mis hors service. Pour éviter toute perte de données ou de continuité d’activité, migrez avant le 31 août 2024.

Avantages potentiels : continuité de votre service

Pour plus d’informations, consultez Migrer Azure Cloud Services (classique) vers Azure Cloud Services (support étendu).

Cognitive Services

Mettez à niveau votre application pour utiliser la dernière version de l’API à partir d’Azure OpenAI

Une ressource Azure OpenAI avec une ancienne version d’API ne dispose pas des fonctions et fonctionnaliés les plus récentes. Nous vous recommandons d'utiliser la dernière version de l’API REST.

Avantages potentiels : nos nouvelles versions d’API contiennent les fonctionnalités et capacités les meilleures et les plus récentes.

Pour plus d’informations, consultez Informations de référence sur l’API REST Azure OpenAI Service.

Quota dépassé pour cette ressource, attendre ou changer de niveau pour débloquer

Si le quota de votre ressource est dépassé, votre ressource est bloquée. Vous pouvez attendre que le quota soit automatiquement réapprovisionné prochainement. Vous pouvez également changer de niveau et passer à une SKU payante afin d'utiliser la ressource dès maintenant.

Avantages potentiels : si vous effectuez une mise à niveau vers une référence SKU payante, vous pouvez à nouveau utiliser la ressource aujourd’hui.

Pour plus d’informations, consultez Planifier et gérer les coûts liés à Azure AI Studio.

Container Registry

Utilisez le niveau Premium pour les charges de travail de production critiques.

Les registres Premium fournissent la quantité la plus élevée de stockage inclus, d’opérations simultanées et de bande passante réseau, permettant des scénarios impliquant des volumes importants. Le niveau Premium ajoute également des fonctionnalités telles que la géoréplication, la prise en charge des zones de disponibilité, la confiance du contenu, les clés gérées par le client et les points de terminaison privés.

Avantages potentiels : le niveau Premium offre la plus grande quantité d’options de performances, de mise à l’échelle et de résilience

Pour plus d’informations, consultez Niveaux de service Azure Container Registry.

Vérifier que la géoréplication est activée pour la résilience

La géoréplication permet aux charges de travail d’utiliser une seule image, une seule balise et un seul nom de registre dans différentes régions, fournit un accès au registre proche du réseau, des coûts de transfert de données réduits et une résilience régionale du registre si une panne régionale se produit. Cette fonctionnalité est disponible uniquement dans le niveau de service Premium.

Avantages potentiels : amélioration des performances de résilience et d’extraction, gestion simplifiée du Registre et réduction des coûts de transfert de données

Pour plus d’informations, consultez Géoréplication dans Azure Container Registry.

Content Delivery Network

Azure CDN fourni par Edgio, échec du renouvellement de certificat managé. Validation supplémentaire requise.

Azure CDN fourni par Edgio utilise la délégation CNAME pour renouveler les certificats avec DigiCert pour les renouvellements de certificats managés. Il est essentiel que les domaines personnalisés soient résolus en un point de terminaison azureedge.net pour que le processus de renouvellement automatique avec DigiCert réussisse. Vérifiez que les enregistrements CNAME et CAA de votre domaine personnalisé sont configurés correctement. Si vous avez besoin d’aide supplémentaire, envoyez une demande de support à Azure pour une nouvelle tentative de demande de renouvellement.

Avantages potentiels : garantir la disponibilité du service.

Renouveler le certificat client Azure Front Door venant à expiration pour éviter toute interruption de service

Lorsque les certificats clients pour les profils Azure Front Door Standard et Premium expirent, vous risquez d’avoir des interruptions de service. Pour éviter une interruption de service, renouvelez le certificat avant qu’il expire.

Avantages potentiels : garantir la disponibilité du service.

Pour plus d’informations, consultez Configurer HTTPS sur un domaine personnalisé Azure Front Door à l’aide du Portail Azure.

Revalider la propriété du domaine pour le renouvellement du certificat managé Azure Front Door

Azure Front Door (AFD) ne peut pas renouveler automatiquement le certificat managé, car le domaine n’est pas mappé CNAME au point de terminaison AFD. Revalidez la propriété du domaine pour que le certificat managé soit automatiquement renouvelé.

Avantages potentiels : non définis

Pour plus d’informations, consultez Configurer un domaine personnalisé sur Azure Front Door à l’aide du Portail Azure.

Remplacer la version du secret par « La plus récente » pour le certificat client Azure Front Door

Configurez le secret du certificat client Azure Front Door (AFD) sur « La plus récente » pour qu’AFD fasse référence à la version du secret la plus récente dans Azure Key Vault, afin que le secret puisse être automatiquement pivoté.

Avantages potentiels : la dernière version peut être pivotée automatiquement.

Pour plus d’informations, consultez Configurer HTTPS sur un domaine personnalisé Azure Front Door à l’aide du Portail Azure.

Valider la propriété d’un domaine en ajoutant un enregistrement TXT DNS au fournisseur DNS

Valider la propriété d’un domaine en ajoutant un enregistrement TXT DNS à votre fournisseur DNS. La validation de la propriété du domaine par le biais d’enregistrements TXT améliore la sécurité et garantit un contrôle approprié sur votre domaine.

Avantages potentiels : garantir la disponibilité du service.

Pour plus d’informations, consultez Configurer un domaine personnalisé sur Azure Front Door à l’aide du Portail Azure.

Data Factory

Implémenter la stratégie BCDR pour la redondance interrégion dans Azure Data Factory

L’implémentation de la stratégie BCDR améliore la haute disponibilité et réduit le risque de perte de données

Avantages potentiels : améliore la haute disponibilité et réduit le risque de perte de données

Pour plus d’informations, consultez Continuité d’activité et reprise d’activité pour les pipelines Azure Data Factory et Azure Synapse Analytics – Centre des architectures Azure.

Activer la mise à niveau automatique sur votre runtime d’intégration auto-hébergé

La mise à niveau automatique du runtime d’intégration auto-hébergé a été désactivée. Sachez que vous n’obtenez pas les dernières modifications ni les derniers correctifs de bogues sur le runtime d’intégration auto-hébergé. Passez-les en revue pour activer la mise à niveau automatique du runtime d’intégration auto-hébergé

Avantages potentiels : pour obtenir les dernières modifications et correctifs de bogues sur le runtime d’intégration auto-hébergé

Pour plus d’informations, consultez Mise à jour automatique du runtime d’intégration auto-hébergé et notification d’expiration

Relais Fluid

La bibliothèque de client Relais Azure Fluid doit être mise à niveau

Si le service Relais Azure Fluid est invoqué avec une ancienne bibliothèque de client, cela peut entraîner des problèmes d’appplication. Pour que votre application reste opérationnelle, mettez à niveau votre bibliothèque de client Relais Azure Fluid avec la dernière version. La mise à niveau fournit les fonctionnalités les plus récentes et des améliorations en matière de performances et de stabilité.

Avantages potentiels : amélioration de la fiabilité

Pour plus d’informations, consultez Compatibilité des versions avec les versions d’Infrastructure Fluid.

HDInsight

Appliquez les mises à jour critiques en supprimant et en recréant vos clusters HDInsight (rotation de certificat tour 2)

Le service HDInsight a tenté d’appliquer une mise à jour de certificat critique sur tous vos clusters en cours d’exécution. Toutefois, en raison de modifications de configuration personnalisées, nous ne pouvons pas appliquer les mises à jour sur vos clusters. Supprimez et recréez votre cluster pour empêcher qu’il devienne non sain et inutilisable.

Avantages potentiels : garantir l’intégrité et la stabilité du cluster

Pour plus d’informations, consultez Configurer des clusters dans HDInsight avec Apache Hadoop, Apache Spark, Apache Kafka, etc.

Clusters ABFS non-ESP [Autorisations de cluster pour Word Readable]

Prévoyez d’introduire une modification dans les clusters ABFS non-ESP qui empêche l’exécution par les utilisateurs de groupe non Hadoop de commandes Hadoop pour les opérations de stockage. Cette modification permet d’améliorer l’état de la sécurité du cluster. Les clients doivent planifier les mises à jour avant le 30 septembre 2023.

Avantages potentiels : cette modification consiste à améliorer l’état de la sécurité du cluster

Pour plus d’informations, consultez Notes de publication d’Azure HDInsight.

Redémarrer les répartiteurs sur vos disques de cluster Kafka

Lorsque les disques de données utilisés par les répartiteurs Kafka dans les clusters HDInsight sont presque complets, le processus de répartiteur Apache Kafka ne peut pas démarrer et échoue. Pour atténuer les problèmes, recherchez le temps de rétention pour chaque rubrique, sauvegardez les fichiers plus anciens et redémarrez les répartiteurs.

Avantages potentiels : éviter les problèmes liés au répartiteur Kafka

Pour plus d’informations, consultez Scénario : Les répartiteurs ne sont pas sains ou ne peuvent pas redémarrer en raison d’un problème d’espace disque plein.

Mise à jour de la longueur du nom du cluster

La longueur maximale des noms de clusters passe de 59 à 45 caractères dans le but d’améliorer la posture de sécurité des clusters. Cette modification sera implémentée d’ici le 30 septembre 2023.

Avantages potentiels : amélioration de l’état de la sécurité pour HDInsight

Pour plus d’informations, consultez Notes de publication d’Azure HDInsight.

Mettre à niveau votre cluster vers la dernière image HDInsight

Un cluster créé il y a un an ne dispose pas des dernières mises à niveau d’image. Votre cluster a été créé il y a un an. Dans le cadre des meilleures pratiques, nous vous recommandons d’utiliser les dernières images HDInsight, car elles apportent le meilleur des mises à jour open source, des mises à jour Azure et des correctifs de sécurité. La durée maximale recommandée pour les mises à niveau de cluster est inférieure à six mois.

Avantages potentiels : obtenir les derniers correctifs et fonctionnalités

Pour plus d’informations, consultez Prendre en compte les points ci-dessous avant de commencer à créer un cluster.

Mettez à niveau votre cluster HDInsight

Un cluster qui n’utilise pas la dernière image ne dispose pas des dernières mises à niveau. Votre cluster n’utilise pas l’image la plus récente. Nous vous recommandons d’utiliser les dernières versions des images HDInsight, car elles proposent le meilleur des mises à jour open source, des mises à jour Azure et des correctifs de sécurité. Les versions de HDInsight sont publiées tous les 30 à 60 jours.

Avantages potentiels : obtenir les derniers correctifs et fonctionnalités

Pour plus d’informations, consultez Notes de publication d’Azure HDInsight.

Passerelle ou machine virtuelle inaccessible

Nous avons détecté un échec de détection de réseau, il indique une passerelle inaccessible ou une machine virtuelle. Vérifiez la disponibilité de tous les hôtes du cluster. Redémarrez la machine virtuelle à récupérer. Si vous avez besoin d’aide supplémentaire, n’hésitez pas à contacter l’équipe de support Azure.

Avantages potentiels : amélioration de la disponibilité

L’agent VM est 9.9.9.9. Mettez à niveau le cluster.

Nos enregistrements indiquent qu’un ou plusieurs de vos groupements utilisent des images datant de février 2022 ou antérieures (versions d’image 2202xxxxxx ou antérieures). Un problème de fiabilité potentiel se présente pour les groupements HDInsight qui utilisent des images datant de février 2022 ou antérieures. Envisagez de régénérer vos groupements en utilisant la dernière image.

Avantages potentiels : amélioration de la fiabilité de la mise à l’échelle et de la connectivité réseau

Media Services

Augmenter les quotas ou les limites des services multimédia

Lorsqu’un compte multimédia atteint ses limites de quota, le service peut être interrompu. Pour éviter toute interruption du service, passez en revue l’utilisation actuelle des ressources, les stratégies de clé de contenu et les stratégies de flux et augmentez les limites de quota pour les entités proches de la limite. Vous pouvez demander une augmentation des quotas en créant un ticket et en y ajoutant les informations nécessaires. Conseil : ne créez pas d’autres comptes Azure Media Services pour obtenir des limites supérieures.

Avantages potentiels : éviter toute interruption de service due au dépassement du quota.

Pour plus d’informations, consultez Quotas et limites d’Azure Media Services.

Service Bus

Utiliser le niveau Premium Service Bus pour améliorer la résilience

Lors de l’exécution d’applications critiques, le niveau Premium Service Bus offre une meilleure isolation des ressources au niveau du processeur et de la mémoire, ce qui améliore la disponibilité. Il prend également en charge la fonctionnalité de géo-reprise d’activité après sinistre. Cette dernière permet une récupération plus facile des sinistres régionaux sans avoir à modifier les configurations d’application.

Avantages potentiels : le niveau Premium Service Bus offre une meilleure résilience avec l’isolation des ressources processeur et mémoire, ainsi que la géo-reprise d’activité après sinistre

Pour plus d’informations, consultez Niveau de messagerie Service Bus Premium.

Utiliser la fonctionnalité de mise à l’échelle automatique du niveau Premium Service Bus pour améliorer la résilience

Lors de l’exécution d’applications critiques, l’activation de la fonctionnalité de mise à l’échelle automatique vous permet d’avoir suffisamment de capacité pour gérer la charge de votre application. Avoir la bonne quantité de ressources pendant l’exécution peut réduire les limitations et offrir une meilleure expérience utilisateur.

Avantages potentiels : l’activation de la mise à l’échelle automatique évite les contraintes de capacité aux utilisateurs

Pour plus d’informations, consultez Mettre à jour automatiquement les unités de messagerie d’un espace de noms Azure Service Bus.

SQL Server sur les machines virtuelles Azure

Activer la sauvegarde Azure pour SQL sur vos machines virtuelles

Profitez des avantages de la sauvegarde sans infrastructure, de la restauration à un instant dans le passé et de la gestion centralisée avec l’intégration d’un groupe de disponibilité SQL en activant les sauvegardes pour les bases de données SQL sur vos machines virtuelles à l’aide de la sauvegarde Azure.

Avantages potentiels : sauvegardes compatibles SQL sans infrastructure pour la sauvegarde, la gestion centralisée, l’intégration de groupe de disponibilité et la récupération jusqu’à une date et heure

Pour plus d’informations, consultez À propos de la sauvegarde SQL Server dans les machines virtuelles Azure.

Stockage

Utiliser des disques managés pour les comptes de stockage atteignant la limite de capacité

Lorsque les disques SSD Premium non managés dans les comptes de stockage sont sur le point d’atteindre leur limite de capacité de Stockage Premium, des défaillances peuvent se produire. Pour éviter des échecs lorsque cette limite est atteinte, effectuez une migration vers des disques managés sans limite de capacité. Cette migration peut être effectuée via le portail en moins de 5 minutes.

Avantages potentiels : éviter les problèmes de mise à l’échelle lorsque le compte atteint la limite de capacité

Pour plus d’informations, consultez Cibles de scalabilité et de performances pour les comptes de stockage standard.

Configurer une sauvegarde de blob

La sauvegarde des objets blob Azure vous aide à protéger les données contre la suppression accidentelle ou malveillante. Nous vous recommandons de configurer la sauvegarde des objets blob.

Avantages potentiels : protéger les données contre la suppression accidentelle ou malveillante

Pour plus d’informations, consultez Vue d’ensemble du Stockage Blob Azure.

Abonnements

Activez Sauvegarde Azure pour obtenir une protection simple, fiable et rentable pour vos données

Conservez vos informations et vos applications en toute sécurité avec une sauvegarde robuste, en un clic à partir d’Azure. Activez Sauvegarde Azure pour obtenir une protection rentable pour un large éventail de charges de travail, notamment les machines virtuelles, les bases de données SQL, les applications et les partages de fichiers.

Avantages potentiels : assurez-vous que vos applications critiques pour l’entreprise restent protégées

Pour plus d’informations, consultez Documentation Sauvegarde Azure – Sauvegarde Azure.

Créer une alerte d’intégrité du service Azure

Les alertes d’intégrité du service Azure vous permettent de vous informer des problèmes et des avis dans quatre domaines (problèmes de service, maintenance planifiée, avis de sécurité et d’intégrité). Ces alertes sont personnalisées pour vous avertir des interruptions ou des impacts potentiels sur vos régions et services Azure choisis.

Avantages potentiels : restez informé des problèmes et des avis dans 4 domaines (problèmes de service, maintenance planifiée, avis de sécurité et avis de santé)

Pour plus d’informations, consultez Créer des alertes de journal d’activité sur les notifications de service à l’aide du Portail Azure.

Machines Virtuelles

Améliorer la fiabilité des données en utilisant des disques gérés

Les machines virtuelles d’un groupe à haute disponibilité avec des disques partageant des comptes de stockage ou des unités d’échelle de stockage ne sont pas résilientes aux échecs des unités d’échelle de stockage en cas de pannes. Migrez vers la fonctionnalité Azure Disques managés pour vous assurer que les disques des différentes machines virtuelles du groupe à haute disponibilité sont suffisamment isolés pour éviter un point de défaillance unique.

Avantages potentiels : garantir la continuité de l’activité par le biais de la résilience des données

Pour plus d’informations, consultez https://aka.ms/aa_avset_manageddisk_learnmore.

Activer la réplication des machines virtuelles pour protéger vos applications contre une panne régionale

Les machines virtuelles sont résilientes aux pannes régionales lorsque la réplication vers une autre région est activée. Pour réduire l’impact négatif sur l’entreprise lors d’une panne de la région Azure, nous vous recommandons d’activer la réplication de toutes les machines virtuelles vitales pour l’entreprise.

Avantages potentiels : garantir la continuité d’activité en cas de panne d’une région Azure

Pour plus d’informations, consultez Démarrage rapide : configurer la récupération d’urgence dans une région Azure secondaire pour une machine virtuelle Azure.

Mettre à jour votre protocole de connectivité sortante vers des balises de service pour Azure Site Recovery

La mise en liste d’autorisation basée sur les adresses IP est un moyen vulnérable de contrôler la connectivité sortante pour les pare-feu ; les étiquettes de service constituent une bonne alternative. Nous vous recommandons vivement d’utiliser des balises de service pour assurer la connectivité des ordinateurs aux services Azure Site Recovery.

Avantages potentiels : garantit une sécurité, une stabilité et une résilience accrues par rapport aux adresses IP codées en dur

Pour plus d’informations, consultez À propos de la mise en réseau dans la récupération d’urgence de machines virtuelles Azure.

Mettre à niveau les disques standard attachés à votre machine virtuelle compatible Premium vers des disques Premium

L’utilisation de disques SSD Standard avec des machines virtuelles Premium peut entraîner des problèmes de performances sous-optimales et de latence. Nous vous recommandons de mettre à niveau les disques Standard vers le niveau Premium. Pour toute machine virtuelle à une seule instance utilisant le stockage Premium pour tous les disques de système d'exploitation et de données, nous garantissons une connectivité de la machine virtuelle d'au moins 99,9 %. Quand vous choisissez de mettre à niveau, vous devez prendre en compte deux facteurs. Le premier facteur est que la mise à niveau nécessite un redémarrage de la machine virtuelle et que cela prend de 3 à 5 minutes. Le deuxième est que si les machines virtuelles de la liste sont des machines virtuelles en production exécutant des tâches critiques, il faut évaluer la disponibilité améliorée par rapport au coût des disques Premium.

Avantages potentiels : disponibilité améliorée avec le contrat SLA de machine virtuelle unique disponible seulement quand tous les disques sont des disques Premium

Pour plus d’informations, consultez Types de disques managés Azure.

Mettre à niveau une machine virtuelle depuis des disques non managés Premium vers des disques managés sans coût supplémentaire

Disques managés Azure fournit une résilience accrue, une gestion simplifiée du service, une cible de mise à l’échelle plus élevée et plus de choix entre plusieurs types de disques. Votre machine virtuelle utilise des disques non managés Premium qui peuvent être migrés vers des disques managés sans coût supplémentaire via le portail en moins de cinq minutes.

Avantages potentiels : tirer parti d’une résilience accrue et d’autres avantages des disques managés

Pour plus d’informations, consultez Présentation des disques managés Azure.

Mettre à niveau votre image de machine virtuelle dépréciée vers une image plus récente

Les machines virtuelles de votre abonnement s’exécutent sur des images dont la dépréciation est planifiée. Une fois l’image dépréciée, il est impossible de créer des machines virtuelles à partir de celle-ci. Pour éviter une interruption de vos charges de travail, effectuez une mise à niveau vers une version plus récente de l’image. (VMRunningDeprecatedImage)

Avantages potentiels : réduire les interruptions potentielles de vos charges de travail de machine virtuelle

Pour plus d’informations, consultez Images déconseillées de la Place de marché Azure – Machines virtuelles Azure.

Mettre à niveau vers une offre plus récente d’image de machine virtuelle

Les machines virtuelles de votre abonnement s’exécutent sur des images dont la dépréciation est planifiée. Une fois l’image dépréciée, il est impossible de créer des machines virtuelles à partir de celle-ci. Pour éviter une interruption de vos charges de travail, effectuez une mise à niveau vers une version plus récente de l’image. (VMRunningDeprecatedOfferLevelImage)

Avantages potentiels : réduire les interruptions potentielles de vos charges de travail de machine virtuelle

Pour plus d’informations, consultez Images déconseillées de la Place de marché Azure – Machines virtuelles Azure.

Mettre à niveau vers une référence SKU plus récente de l’image de machine virtuelle

Les machines virtuelles de votre abonnement s’exécutent sur des images dont la dépréciation est planifiée. Une fois l’image dépréciée, il est impossible de créer des machines virtuelles à partir de celle-ci. Pour éviter une interruption de vos charges de travail, effectuez une mise à niveau vers une version plus récente de l’image.

Avantages potentiels : réduire les interruptions potentielles de vos charges de travail de machine virtuelle

Pour plus d’informations, consultez Images déconseillées de la Place de marché Azure – Machines virtuelles Azure.

Mettre à niveau votre groupe de machines virtuelles identiques vers une autre version d’image

Les VMSS de votre abonnement s’exécutent sur des images dont la dépréciation a été planifiée. Une fois l’image déconseillée, les charges de travail de votre groupe de machines virtuelles identiques ne font plus l’objet d’un scale-out. Effectuez une mise à niveau vers une version plus récente de l’image pour éviter une interruption de votre charge de travail.

Avantages potentiels : réduire les interruptions potentielles de vos charges de travail de groupe de machines virtuelles identiques

Pour plus d’informations, consultez Images déconseillées de la Place de marché Azure – Machines virtuelles Azure.

Mettre à niveau votre groupe de machines virtuelles identiques vers une autre offre d’image

Les VMSS de votre abonnement s’exécutent sur des images dont la dépréciation a été planifiée. Une fois l’image déconseillée, les charges de travail de votre groupe de machines virtuelles identiques ne font plus l’objet d’un scale-out. Pour éviter toute interruption de votre charge de travail, effectuez une mise à niveau vers une offre plus récente de l’image.

Avantages potentiels : réduire les interruptions potentielles de vos charges de travail de groupe de machines virtuelles identiques

Pour plus d’informations, consultez Images déconseillées de la Place de marché Azure – Machines virtuelles Azure.

Mettre à niveau votre groupe de machines virtuelles identiques vers une autre référence SKU d’image

Les VMSS de votre abonnement s’exécutent sur des images dont la dépréciation a été planifiée. Une fois l’image déconseillée, les charges de travail de votre groupe de machines virtuelles identiques ne font plus l’objet d’un scale-out. Pour éviter toute interruption de votre charge de travail, effectuez une mise à niveau vers une référence SKU plus récente de l’image.

Avantages potentiels : réduire les interruptions potentielles de vos charges de travail de groupe de machines virtuelles identiques

Pour plus d’informations, consultez Images déconseillées de la Place de marché Azure – Machines virtuelles Azure.

Fournir un accès aux URL obligatoires qui font défaut à votre environnement Azure Virtual Desktop

Pour qu’un hôte de session puisse se déployer sur Windows Virtual Desktop (WVD) et s’y inscrire, vous avez besoin d’un ensemble d’URL à la « liste autorisée » au cas où votre machine virtuelle s’exécuterait dans un environnement restreint. Si des URL spécifiques manquent dans la liste autorisée, recherchez l’événement 3702 dans le journal des événements de l’application.

Avantages potentiels : garantir la réussite du déploiement et le bon fonctionnement de l’hôte de session lors de l’utilisation du service Windows Virtual Desktop

Pour plus d’informations, consultez Noms de domaine complets et points de terminaison obligatoires pour Azure Virtual Desktop.

Aligner l’emplacement des ressources et du groupe de ressources

Pour réduire l’impact des pannes régionales, nous vous recommandons de colocaliser les ressources dans la même région que le groupe de ressources. De cette façon, Azure Resource Manager stocke les métadonnées relatives à toutes les ressources au sein du groupe dans une seule région. En colocalisant, vous réduisez le risque d’être affecté par l’indisponibilité de la région.

Avantages potentiels : réduire les échecs d’écriture en raison de pannes de région

Pour plus d’informations, consultez Qu’est-ce qu’Azure Resource Manager ?.

Utilisez les zones de disponibilité pour améliorer la résilience et la disponibilité

Les Zones de disponibilité (AZ) dans Azure contribuent à protéger vos applications et vos données contre des échecs du centre de données. Chaque AZ est composée d’un ou de plusieurs centres de données équipés d’une alimentation, d’un système de refroidissement et d’un réseau indépendants. En concevant des solutions pour utiliser des machines virtuelles zonales, vous pouvez isoler vos machines virtuelles de l’échec dans n’importe quelle autre zone.

Avantages potentiels : l’utilisation de machines virtuelles zonales protège vos applications contre les pannes zonales dans toutes les autres zones.

Pour plus d’informations, consultez Déplacer des machines virtuelles Azure à instance unique d’une zone de disponibilité régionale à une zone cible zonale

Activer le monitoring de l’intégrité de l’application Azure Virtual Machine Scale Set (VMSS)

La configuration du monitoring de l’intégrité d’une application de groupe de machines virtuelles identiques à l’aide de l’extension Intégrité de l’application ou des sondes d’intégrité de l’équilibreur de charge permet à la plateforme Azure d’améliorer la résilience de votre application en répondant aux changements d’intégrité de l’application.

Avantages potentiels : augmenter la résilience en exposant l’intégrité de l’application à Azure

Pour plus d’informations, consultez Utilisation de l’extension Intégrité de l’application avec Virtual Machine Scale Sets.

Activer les sauvegardes sur vos machines virtuelles

Sécurisez vos données en activant les sauvegardes de vos machines virtuelles.

Avantages potentiels : protection de vos machines virtuelles

Pour plus d’informations, consultez Qu’est-ce que le service Sauvegarde Azure ?.

Activer la stratégie de réparation automatique sur les groupes de machines virtuelles identiques (VMSS) Azure

L’activation de la réparation automatique des instances permet d’obtenir une haute disponibilité en maintenant un ensemble d’instances saines. Si une instance non saine est trouvée par l’extension Intégrité de l’application ou la sonde d’intégrité load balancer, les réparations automatiques d’instance tentent de récupérer l’instance en déclenchant des actions de réparation.

Avantages potentiels : augmenter la résilience en automatisant la réparation des instances ayant échoué

Pour plus d’informations, consultez Réparations automatiques d’instances pour Azure Virtual Machine Scale Sets.

Configurer la mise à l’échelle automatisée d’un groupe de machines virtuelles identiques par métriques

Optimisez l’utilisation des ressources, réduisez les coûts et améliorez les performances des applications avec une mise à l’échelle automatique personnalisée basée sur une métrique. Ajoutez automatiquement des instances de machine virtuelle basées sur des métriques en temps réel telles que les opérations de processeur, de mémoire et de disque. Assurez la haute disponibilité tout en maintenant la rentabilité.

Avantages potentiels : garantit une haute disponibilité tout en conservant l’efficacité des coûts

Pour plus d’informations, consultez Vue d’ensemble de la mise à l’échelle automatique avec Azure Virtual Machine Scale Sets.

Utiliser des disques Azure avec stockage redondant interzone (ZRS) pour une résilience et une disponibilité plus élevées

Les disques Azure avec ZRS fournissent une réplication synchrone des données parmi trois zones de disponibilité dans une région, ce qui rend le disque tolérant aux défaillances zonales sans interruptions des applications. Pour une résilience et une disponibilité plus élevées, migrez des disques de LRS vers ZRS.

Avantages potentiels : en concevant vos applications pour utiliser des disques ZRS, vos données sont répliquées sur 3 zones de disponibilité, ce qui rend votre disque résilient en cas de panne zonale

Pour plus d’informations, consultez Convertir un disque de LRS en ZRS.

Les serveurs DNS doivent être configurés au niveau du réseau virtuel

Définissez les serveurs DNS pour l’ordinateur virtuel au niveau du réseau virtuel afin d'assurer la cohérence de l'environnement. Dans la configuration de l'interface réseau primaire, le paramètre Serveurs DNS doit être réglé sur Hériter du réseau virtuel.

Avantages potentiels : Assurez la cohérence et la fiabilité de la résolution des noms

Pour plus d’informations, consultez Résolution de noms des ressources dans les réseaux virtuels Azure

Migrer vers Virtual Machine Scale Sets en mode d’orchestration Flexible

Migrez les charges de travail d’une machine virtuelle vers des groupes de machines virtuelles identiques Flex pour le déploiement entre les zones ou dans la même zone entre différents domaines d’erreur. La plateforme prévoit de déprécier les groupes à haute disponibilité.

Avantages potentiels : disponibilité entre zones ou entre différents domaines d’erreur

Pour plus d’informations, consultez Migration de déploiements et de ressources vers des groupes de machines virtuelles identiques dans une orchestration flexible

Charges de travail

Configurez un groupe de disponibilité Always On pour les serveurs SQL à usage multiple (MPSQL)

Les serveurs MPSQL avec un groupe de disponibilité Always On disposent d’une meilleure disponibilité. Vos serveurs MPSQL ne sont pas configurés dans le cadre d’un groupe de disponibilité Always On dans l’infrastructure partagée de votre système Epic. Les groupes de disponibilité Always On améliorent la disponibilité des bases de données et l’utilisation des ressources.

Avantages potentiels : amélioration de la disponibilité et de l’utilisation des ressources de base de données

Pour plus d’informations, consultez Qu’est-ce qu’un groupe de disponibilité Always On ?.

Configurer le cache d’hôte local sur les serveurs Citrix VDI pour garantir des opérations de répartition de connexions transparentes

Nous avons observé que vos serveurs Citrix VDI ne sont pas configurés pour le cache d’hôte local. Le cache d’hôte local (LHC) est une fonctionnalité de Citrix Virtual Apps and Desktops qui permet aux opérations de répartition de connexion de se poursuivre lorsqu’une panne se produit. Le LHC s’active lorsque la base de données du site est inaccessible pendant 90 secondes.

Avantages potentiels : opérations de répartiteur de connexions transparentes

Déployer des serveurs Hyperspace Web dans le cadre d’un groupe de machines virtuelles identiques Flex configuré pour 3 zones

Nous avons observé que vos serveurs Hyperspace Web dans la configuration Flex du groupe de machines virtuelles identiques ne sont pas répartis sur 3 zones dans la région sélectionnée. Pour les services comme Hyperspace web dans les systèmes Epic qui nécessitent une haute disponibilité et une grande échelle, il est recommandé que les serveurs soient déployés dans le cadre du groupe de machines virtuelles identiques Flex et répartis sur 3 zones. Avec l’orchestration Flexible, Azure offre une expérience unifiée sur tout l’écosystème de machines virtuelles Azure.

Avantages potentiels : haute disponibilité et grande échelle à la demande pour les serveurs web Hyperspace dans Epic DB

Pour plus d’informations, consultez Créer un groupe identique de machines virtuelles qui utilise les zones de disponibilité.

Définir le délai d’inactivité dans Azure Load Balancer sur 30 minutes pour la configuration de la haute disponibilité ASCS dans les charges de travail SAP

Pour éviter l’expiration de l’équilibreur de charge, vérifiez que toutes les règles d’équilibrage de charge Azure ont « Délai d’inactivité (minutes) » défini sur la valeur maximale 30 minutes. Ouvrez l’équilibreur de charge, sélectionnez « Règles d’équilibrage de charge » et ajoutez ou modifiez la règle pour activer les paramètres.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Activer l’adresse IP flottante dans Azure Load Balancer pour la configuration de la haute disponibilité ASCS dans les charges de travail SAP

Pour la réutilisation des ports et une meilleure haute disponibilité, activez l’adresse IP flottante dans les règles d’équilibrage de charge d’Azure Load Balancer pour la configuration de la haute disponibilité d’une instance ASCS dans les charges de travail SAP. Ouvrez l’équilibreur de charge, sélectionnez « Règles d’équilibrage de charge » et ajoutez ou modifiez la règle pour activer.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Activer les ports HA dans Azure Load Balancer pour la configuration de la haute disponibilité ASCS dans les charges de travail SAP

Pour réutiliser les ports et améliorer la haute disponibilité, activez les ports HA dans les règles d'équilibrage de charge pour la configuration HA de l'instance ASCS dans les charges de travail SAP. Ouvrez l’équilibreur de charge, sélectionnez « Règles d’équilibrage de charge » et ajoutez ou modifiez la règle pour activer.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Désactiver les horodatages TCP sur les machines virtuelles placées derrière Azure Load Balancer dans la configuration de la haute disponibilité ASCS dans les charges de travail SAP

Désactiver les horodatages TCP sur les machines virtuelles placées derrière Azure Load Balancer. L’activation des horodatages TCP entraîne l’échec des sondes d’intégrité à cause de la suppression de paquets TCP par la pile TCP du système d’exploitation invité de la machine virtuelle. De ce fait, l’équilibreur de charge marque le point de terminaison comme étant hors service

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez https://launchpad.support.sap.com/#/notes/2382421.

Définir le délai d’inactivité dans Azure Load Balancer sur 30 minutes pour la configuration de la haute disponibilité de base de données HANA dans les charges de travail SAP

Pour éviter que l'équilibreur de charge ne se bloque, assurez-vous que le paramètre « Idle timeout (minutes) » de toutes les règles d'équilibrage de charge Azure est réglé sur la valeur maximale de 30 minutes. Ouvrez l’équilibreur de charge, sélectionnez « Règles d’équilibrage de charge » et ajoutez ou modifiez la règle pour activer les paramètres recommandés.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Activer l’adresse IP flottante dans Azure Load Balancer pour la configuration de la haute disponibilité de base de données HANA dans les charges de travail SAP

Pour un routage plus flexible, activez l’adresse IP flottante dans les règles d’équilibrage de charge d’Azure Load Balancer pour la configuration de la haute disponibilité d’une instance de base de données HANA dans les charges de travail SAP. Ouvrez l’équilibreur de charge, sélectionnez « Règles d’équilibrage de charge » et ajoutez ou modifiez la règle pour activer les paramètres recommandés.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Activer les ports HA dans Azure Load Balancer pour la configuration de la haute disponibilité de base de données HANA dans les charges de travail SAP

Pour une meilleure évolutivité, activez les ports HA dans les règles d’équilibrage de charge pour la configuration de la haute disponibilité d’une instance de base de données HANA dans les charges de travail SAP. Ouvrez l’équilibreur de charge, sélectionnez « Règles d’équilibrage de charge » et ajoutez ou modifiez la règle pour activer les paramètres recommandés.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Désactiver les horodatages TCP sur les machines virtuelles placées derrière Azure Load Balancer dans la configuration de la haute disponibilité de base de données HANA dans les charges de travail SAP

Désactivez les horodatages TCP sur les machines virtuelles placées derrière Azure Load Balancer. L’activation des horodatages TCP entraîne l’échec des sondes d’intégrité à cause de la suppression de paquets TCP par la pile TCP du système d’exploitation invité de la machine virtuelle. De ce fait, l’équilibreur de charge marque le point de terminaison comme étant hors service.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Sondes d’intégrité Load Balancer.

Vérifiez que stonith est activé pour la configuration de Pacemaker dans la configuration de haute disponibilité ASCS dans les charges de travail SAP

Dans un cluster Pacemaker, l’implémentation de l’isolation au niveau du nœud est effectuée à l’aide d’une ressource STONITH (Shoot The Other Node in the Head). Pour faciliter la gestion des nœuds défaillants, assurez-vous que l'option « stonith-enable » est définie sur « true » dans la configuration du cluster HA.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité de SAP HANA sur les machines virtuelles Azure sur Red Hat Enterprise Linux.

Définissez le jeton corosync dans le cluster Pacemaker à 30000 pour la configuration ASCS HA dans les charges de travail SAP (RHEL)

Le paramètre de jeton corosync détermine le délai d’expiration utilisé directement ou comme base pour le calcul du délai d’expiration de jeton réel dans les clusters haute disponibilité. Pour permettre la maintenance avec préservation de la mémoire, définissez le jeton corosync sur 30000 pour SAP sur Azure.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité de SAP HANA sur les machines virtuelles Azure sur Red Hat Enterprise Linux.

Définissez le paramètre des votes attendus sur « 2 » dans la configuration de Pacemaker dans la configuration d’ASCS HA dans les charges de travail SAP (RHEL)

Pour un cluster haute disponibilité à deux nœuds, définissez le paramètre « votes attendus » sur « 2 » comme recommandé pour SAP sur Azure afin de garantir un quorum, une résilience et une cohérence des données appropriés.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité de SAP HANA sur les machines virtuelles Azure sur Red Hat Enterprise Linux.

Activer le paramètre « concurrent-fencing » dans la configuration Pacemaker dans les paramètres de haute disponibilité ASCS dans les charges de travail SAP (ConcurrentFencingHAASCSRH)

L’isolation simultanée permet d’effectuer les opérations de clôture en parallèle, ce qui améliore la haute disponibilité (HA), évite les scénarios de cerveau divisé et contribue à un déploiement SAP robuste. Définissez ce paramètre sur « true » dans la configuration du cluster Pacemaker du programme d’installation HA ASCS.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité de SAP HANA sur les machines virtuelles Azure sur Red Hat Enterprise Linux.

Vérifiez que stonith est activé pour la configuration de cluster dans la configuration de haute disponibilité ASCS dans les charges de travail SAP

Dans un cluster Pacemaker, l’implémentation de l’isolation au niveau du nœud est effectuée à l’aide d’une ressource STONITH (Shoot The Other Node in the Head). Pour faciliter la gestion des nœuds défaillants, assurez-vous que l'option « stonith-enable » est définie sur « true » dans la configuration du cluster HA.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Définissez le délai d'attente stonith à 144 pour la configuration du cluster dans la configuration ASCS HA pour les charges de travail SAP

« stonith-timeout » spécifie la durée pendant laquelle le cluster attend qu’une action STONITH se termine. La définition de la valeur « 144 » secondes permet d’obtenir plus de temps pour que les actions d’isolation se terminent. Nous recommandons ce paramètre pour les clusters HA de SAP sur Azure.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Définissez le jeton corosync dans le cluster Pacemaker à 30000 pour la configuration ASCS HA dans les charges de travail SAP (SUSE)

Le paramètre de jeton corosync détermine le délai d’expiration utilisé directement ou comme base pour le calcul du délai d’expiration de jeton réel dans les clusters haute disponibilité. Pour permettre la maintenance avec préservation de la mémoire, définissez le jeton corosync sur « 30000 » pour SAP sur Azure.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Définir 'token_retransmits_before_loss_const' à 10 dans le cluster Pacemaker dans la configuration ASCS HA dans les charges de travail SAP.

Le corosync token_retransmits_before_loss_const détermine combien de retransmissions de jetons sont tentées avant le délai d’expiration dans des clusters HA. Pour la stabilité et la fiabilité, définissez l’option « totem.token_retransmits_before_loss_const » sur « 10 » pour la configuration ASCS HA.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Le délai d'expiration de la « jointure corosync » spécifie en millisecondes la durée d’attente des messages de jointure dans le protocole d’appartenance afin qu’un nouveau nœud joint le cluster, il a le temps de synchroniser son état avec les nœuds existants. Définissez sur « 60 » dans la configuration du cluster Pacemaker pour la configuration d'ASCS HA.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Définissez le « corosync consensus » dans le cluster Pacemaker à « 36000 » pour la configuration ASCS HA dans les charges de travail SAP

Le paramètre corosync « consensus » spécifie en millisecondes la durée d'attente du consensus avant de commencer un cycle d'adhésion à la configuration du cluster. Définissez « consensus » dans la configuration du cluster Pacemaker pour la configuration du ASCS HA sur 1,2 fois le jeton corosync pour un comportement de basculement fiable.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Définissez le paramètre « corosync max_messages » dans le cluster Pacemaker sur « 20 » pour la configuration ASCS HA dans les charges de travail SAP

La constante corosync « max_messages » spécifie le nombre maximal de messages qui peuvent être envoyés par un processeur à la réception du jeton. Définissez-le sur 20 fois le paramètre de jeton corosync dans la configuration du cluster Pacemaker pour permettre une communication efficace sans surcharger le réseau.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Définissez « votes attendus » sur « 2 » dans la configuration du cluster dans la configuration de la haute disponibilité ASCS dans les charges de travail SAP (SUSE)

Pour un cluster haute disponibilité à deux nœuds, définissez le paramètre « expected_votes » sur 2, comme recommandé pour SAP sur Azure afin de garantir un quorum, une résilience et une cohérence des données appropriés.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Définissez le paramètre two_node sur 1 dans la configuration du cluster dans la configuration de haute disponibilité ASCS dans les charges de travail SAP

Dans un cluster HA à deux nœuds, définissez le paramètre de quorum « two_node » sur 1 conformément aux recommandations pour SAP sur Azure.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Activer « concurrent-fencing » dans la configuration d'ASCS HA dans les charges de travail SAP (ConcurrentFencingHAASCSSLE)

L’isolation simultanée permet d'exécuter les opérations d’isolation en parallèle, ce qui améliore la HA, évite les scénarios de cerveau divisé et contribue à un déploiement SAP robuste. Définissez ce paramètre sur « true » dans la configuration du cluster Pacemaker du programme d’installation HA ASCS.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Vérifiez que le nombre d’instances de « fence_azure_arm » est égal à un dans Pacemaker dans les charges de travail SAP activées pour la haute disponibilité

Si vous utilisez l'agent Azure fence pour la clôture avec une identité managée ou un principal de service, assurez-vous qu'il y a une instance de fence_azure_arm (un agent d’isolation d'E/S pour Azure Resource Manager) dans la configuration Pacemaker pour ASCS HA afin d'assurer la haute disponibilité.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Définissez stonith-timeout sur 900 dans la configuration Pacemaker avec l’agent de clôture Azure pour le programme d’installation HA ASCS

Pour une fonction fiable de Pacemaker dans HA ASCS, définissez « stonith-timeout » sur 900. Ce paramètre est applicable si vous utilisez un agent de clôture Azure pour une clôture avec une identité managée ou un principal de service.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Créer le fichier de configuration softdog dans la configuration Pacemaker pour la configuration de la haute disponibilité ASCS dans les charges de travail SAP

Le minuteur softdog est chargé en tant que module de noyau dans le système d’exploitation Linux. Ce minuteur déclenche une réinitialisation du système s’il détecte que le système a été suspendu. Vérifiez que le fichier de configuration softdog est créé dans le cluster Pacemaker pour la configuration de la haute disponibilité ASCS

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Vérifiez que le module softdog est chargé pour Pacemaker dans la configuration de la haute disponibilité ASCS dans les charges de travail SAP

Le minuteur softdog est chargé en tant que module de noyau dans le système d’exploitation Linux. Ce minuteur déclenche une réinitialisation du système s’il détecte que le système a été suspendu. Tout d’abord, vérifiez que vous avez créé le fichier de configuration softdog, puis chargez le module softdog dans la configuration Pacemaker pour la configuration de la haute disponibilité ASCS

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Définissez le paramètre PREFER_SITE_TAKEOVER sur « true » dans la configuration Pacemaker pour la configuration de la haute disponibilité de base de données HANA

Le paramètre PREFER_SITE_TAKEOVER de SAP HANA définit si l'agent de ressources de réplication du système HANA (SR) préfère reprendre l'instance secondaire plutôt que de redémarrer localement l'instance primaire défaillante. Pour une fonction fiable de l’installation de la haute disponibilité de base de données HANA, définissez PREFER_SITE_TAKEOVER sur « true ».

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité de SAP HANA sur les machines virtuelles Azure sur Red Hat Enterprise Linux.

Activer stonith dans la configuration de cluster dans les charges de travail SAP à haute disponibilité pour les machines virtuelles avec le système d’exploitation Redhat

Dans un cluster Pacemaker, l’implémentation de l’isolation au niveau du nœud est effectuée à l’aide de la ressource STONITH (Shoot The Other Node in the Head). Pour faciliter la gestion des nœuds défaillants, assurez-vous que « stonith-enable » est défini sur « true » dans la configuration de cluster HA de votre charge de travail SAP.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité de SAP HANA sur les machines virtuelles Azure sur Red Hat Enterprise Linux.

Définissez le jeton corosync dans le cluster Pacemaker sur 30000 pour la base de données HANA activée pour la haute disponibilité pour la machine virtuelle avec le SE RHEL

Le paramètre de jeton corosync détermine le délai d’expiration utilisé directement ou comme base pour le calcul du délai d’expiration de jeton réel dans les clusters haute disponibilité. Pour permettre la maintenance avec préservation de la mémoire, définissez le jeton corosync sur 30000 pour SAP sur Azure avec le système d’exploitation Redhat.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité de SAP HANA sur les machines virtuelles Azure sur Red Hat Enterprise Linux.

Définissez le paramètre de votes attendus sur « 2 » dans les charges de travail SAP activées par HA (RHEL)

Pour un cluster haute disponibilité à deux nœuds, définissez les votes de quorum sur « 2 » comme recommandé pour SAP sur Azure afin de garantir un quorum, une résilience et une cohérence des données appropriés.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité de SAP HANA sur les machines virtuelles Azure sur Red Hat Enterprise Linux.

Activer le paramètre « concurrent-fencing » dans la cofiguration Pacemaker pour la configuration de la haute disponibilité de base de données HANA

L’isolation simultanée permet d'effectuer les opérations de clôture en parallèle, ce qui améliore la haute disponibilité (HA), évite les scénarios de cerveau divisé et contribue à un déploiement SAP robuste. Définissez ce paramètre sur « true » dans la configuration du cluster Pacemaker pour le programme d’installation HA de la base de données HANA.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité de SAP HANA sur les machines virtuelles Azure sur Red Hat Enterprise Linux.

Définissez le paramètre PREFER_SITE_TAKEOVER sur 'true' dans la configuration du cluster pour les charges de travail SAP compatibles HA

Le paramètre PREFER_SITE_TAKEOVER dans la topologie SAP HANA définit si l’agent de ressources HANA SR préfère prendre le relais sur l’instance secondaire plutôt que de redémarrer le primaire défaillant localement. Définissez-le sur « true » pour une fonction fiable de la configuration HANA DB HA.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Activer stonith dans la configuration de cluster dans les charges de travail SAP à haute disponibilité pour les machines virtuelles avec le système d’exploitation SUSE

Dans un cluster Pacemaker, l’implémentation de l’isolation au niveau du nœud est effectuée à l’aide de la ressource STONITH (Shoot The Other Node in the Head). Pour faciliter la gestion des nœuds défaillants, assurez-vous que l'option « stonith-enable » est définie sur « true » dans la configuration du cluster HA.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Définissez le délai d’expiration du stonith sur 144 pour la configuration de cluster dans les charges de travail SAP activées pour la haute disponibilité

« stonith-timeout » spécifie la durée pendant laquelle le cluster attend qu’une action STONITH se termine. La définition de la valeur « 144 » secondes permet d’obtenir plus de temps pour que les actions d’isolation se terminent. Nous recommandons ce paramètre pour les clusters HA de SAP sur Azure.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Définissez le jeton corosync dans le cluster Pacemaker sur 30000 pour la base de données HANA activée pour la haute disponibilité pour la machine virtuelle avec le SE SUSE

Le paramètre de jeton corosync détermine le délai d’expiration utilisé directement ou comme base pour le calcul du délai d’expiration de jeton réel dans les clusters haute disponibilité. Pour permettre la maintenance de la conservation de la mémoire, définissez le jeton corosync sur 30000 pour la base de données HANA activée pour la haute disponibilité pour la machine virtuelle avec SUSE OS.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Définissez « token_retransmits_before_loss_const » sur 10 dans le cluster Pacemaker dans les charges de travail SAP activées pour la haute disponibilité

Le corosync token_retransmits_before_loss_const détermine combien de retransmissions de jetons sont tentées avant le délai d’expiration dans des clusters HA. Définissez totem.token_retransmits_before_loss_const sur 10 conformément aux recommandations pour le programme d’installation HA de la base de données HANA.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Définissez la « jointure corosync » dans le cluster Pacemaker sur 60 pour la base de données HANA activée pour la haute disponibilité dans les charges de travail SAP

Le délai d'expiration de la « jointure corosync » spécifie en millisecondes la durée d’attente des messages de jointure dans le protocole d’appartenance afin qu’un nouveau nœud joint le cluster, il a le temps de synchroniser son état avec les nœuds existants. Définissez sur « 60 » dans la configuration du cluster Pacemaker pour la configuration de la haute disponibilité de base de données HANA.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Définir le 'corosync consensus' dans le cluster Pacemaker à 36000 pour HA activé DB HANA dans les charges de travail SAP.

Le paramètre corosync « consensus » spécifie en millisecondes le temps d'attente du consensus avant de commencer un nouveau cycle d'adhésion au cluster. Pour un comportement de basculement fiable, définissez « consensus » dans la configuration du cluster Pacemaker pour la configuration de la haute disponibilité de base de données HANA sur 1,2 fois le jeton corosync.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Définir le 'corosync max_messages’ dans le cluster Pacemaker à 20 pour HA activé DB HANA dans les charges de travail SAP.

La constante corosync « max_messages » spécifie le nombre maximal de messages qui peuvent être envoyés par un processeur à la réception du jeton. Pour permettre une communication efficace sans surcharger le réseau, définissez-le sur 20 fois le paramètre de jeton corosync dans la configuration du cluster Pacemaker.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Définissez le paramètre des votes attendus sur 2 dans les charges de travail SAP activées par HA (SUSE)

Définissez le paramètre de votes attendu sur « 2 » dans la configuration du cluster dans les charges de travail SAP HA pour garantir un quorum, une résilience et une cohérence des données appropriés.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Définissez le paramètre two_node à 1 dans la configuration du cluster dans les charges de travail SAP activées par HA

Dans un cluster HA à deux nœuds, définissez le paramètre de quorum « two_node » sur 1 conformément aux recommandations pour SAP sur Azure.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Activez le paramètre « concurrent-fencing » dans la configuration du cluster pour les charges de travail SAP compatibles HA

L’isolation simultanée permet d'exécuter les opérations d’isolation en parallèle, ce qui améliore la HA, évite les scénarios de cerveau divisé et contribue à un déploiement SAP robuste. Définissez ce paramètre sur « true » dans les charges de travail SAP compatibles haute disponibilité.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Vérifiez qu’il existe une instance de fence_azure_arm dans la configuration Pacemaker pour le programme d’installation HA de la base de données HANA

Si vous utilisez l’agent d’isolation Azure pour l’authentification avec une identité managée ou un principal de service, assurez-vous qu’une instance de fence_azure_arm (un agent d’isolation d’E/S pour Azure Resource Manager) se trouve dans la configuration Pacemaker pour la configuration de la haute disponibilité de la base de données HANA.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Définir stonith-timeout sur 900 dans la configuration Pacemaker avec l’agent de clôture Azure pour la configuration de la haute disponibilité de la base de données HANA

Si vous utilisez l'agent Azure fence pour l’isolation avec une identité managée ou un principal de service, assurez un fonctionnement fiable de la configuration Pacemaker pour HANA DB HA, en définissant « stonith-timeout » sur 900.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Assurez-vous que le fichier config softdog se trouve dans la configuration Pacemaker pour HANA DB dans les charges de travail SAP

Le minuteur softdog est chargé en tant que module de noyau dans le système d’exploitation Linux. Ce minuteur déclenche une réinitialisation du système s’il détecte que le système est suspendu. Vérifiez que le fichier de configuration softdog est créé dans le cluster Pacemaker pour le programme d’installation HA de la base de données HANA.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Vérifiez que le module softdog est chargé dans Pacemaker dans le programme d’installation HA ASCS dans des charges de travail SAP

Le minuteur softdog est chargé en tant que module de noyau dans le système d’exploitation Linux. Ce minuteur déclenche une réinitialisation du système s’il détecte que le système est suspendu. Tout d’abord, vérifiez que vous avez créé le fichier de configuration softdog, puis chargez le module softdog dans la configuration Pacemaker pour le programme d’installation HA de la base de données HANA.

Avantages potentiels : fiabilité de la configuration de haute disponibilité dans les charges de travail SAP

Pour plus d’informations, consultez Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server.

Étapes suivantes

En savoir plus sur la fiabilité – Microsoft Azure Well-Architected Framework