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.
Connectez-vous au portail Azure.
Recherchez et sélectionnez Advisor à partir de n’importe quelle page.
Dans le tableau de bord Advisor, sélectionnez l’onglet Fiabilité.
Services IA
Vous êtes sur le point de dépasser le quota de stockage de 2 Go. Créez un service de recherche standard
Vous êtes sur le point de dépasser le quota de stockage de 2 Go. Créez un service de recherche standard. Les opérations d'indexation cessent de fonctionner lorsque le quota de stockage est dépassé.
En savoir plus sur Limites de service Azure AI Search.
Vous êtes sur le point de dépasser le quota de stockage de 50 Mo. Créez un service de recherche de base ou standard
Vous êtes sur le point de dépasser le quota de stockage de 50 Mo. Créez un service de recherche De base ou Standard. Les opérations d'indexation cessent de fonctionner lorsque le quota de stockage est dépassé.
En savoir plus sur Limites de service Azure AI Search.
Vous êtes sur le point de dépasser votre quota de stockage disponible. Ajoutez davantage de partitions si vous avez besoin de davantage de stockage
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. En cas de dépassement du quota de stockage, l'exécution de requêtes reste possible, mais l'indexation ne fonctionne plus.
En savoir plus sur Limites de service Azure AI Search
Quota dépassé pour cette ressource
Nous avons détecté que le quota de votre ressource a été dépassé. Vous pouvez attendre qu’elle soit bientôt automatiquement réapprovisionnée, ou pour obtenir le déblocage de la ressource et l’utiliser à nouveau, vous pouvez la mettre à niveau vers une référence SKU payante.
En savoir plus sur Service cognitif - CognitiveServiceQuotaExceeded (Quota dépassé pour cette ressource).
Mettez à niveau votre application pour utiliser la dernière version de l’API à partir d’Azure OpenAI
Nous avons détecté que vous disposiez d’une ressource Azure OpenAI qui est utilisée avec une version antérieure de l’API. Utilisez la dernière version de l’API REST pour tirer parti des dernières fonctionnalités.
En savoir plus sur Service cognitif - CogSvcApiVersionOpenAI (Mettre à niveau votre application pour utiliser la dernière version de l’API à partir d’Azure OpenAI).
Mettez à niveau votre application pour utiliser la dernière version de l’API à partir d’Azure OpenAI
Nous avons détecté que vous disposiez d’une ressource Azure OpenAI qui est utilisée avec une version antérieure de l’API. Utilisez la dernière version de l’API REST pour tirer parti des dernières fonctionnalités.
En savoir plus sur Service cognitif - Version de l’API : OpenAI (Mettre à niveau votre application pour utiliser la dernière version de l’API à partir d’Azure OpenAI).
Analyse
Votre cluster exécutant Ubuntu 16.04 n’est plus pris en charge
Nous avons détecté que votre cluster HDInsight utilise toujours Ubuntu 16.04 LTS. La fin de la prise en charge des clusters Azure HDInsight sur Ubuntu 16.04 LTS a commencé le 30 novembre 2022. Les clusters existants s'exécutent en l'état sans support de Microsoft. Envisagez de reconstruire votre cluster avec les dernières images.
En savoir plus sur Cluster HDInsight - ubuntu1604HdiClusters (Votre cluster exécutant Ubuntu 16.04 n’est pas pris en charge).
Mettre à niveau votre cluster HDInsight
Nous avons détecté que votre cluster n’utilise pas l’image la plus récente. Nous recommandons aux clients 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é. La version HDInsight se produit tous les 30 à 60 jours. Envisagez une mise à niveau vers la dernière version.
En savoir plus sur Cluster HDInsight - upgradeHDInsightCluster (Mettre à niveau votre cluster HDInsight).
La date de création de votre cluster remonte à un an
Nous avons détecté que 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.
En savoir plus sur Cluster HDInsight - clusterOlderThanAYear (Votre cluster a été créé il y a un an).
Les disques du cluster Kafka sont presque pleins
Les disques de données, utilisés par les répartiteurs Kafka dans votre cluster HDInsight, sont presque pleins. Lorsque cela se produit, le processus du répartiteur Apache Kafka ne peut pas démarrer et échoue en raison d’une erreur de disque plein. Pour atténuer les problèmes, recherchez le temps de rétention pour chaque rubrique Kafka, sauvegardez les fichiers plus anciens et redémarrez les répartiteurs.
En savoir plus sur Cluster HDInsight - KafkaDiskSpaceFull (Les disques de votre cluster Kafka sont presque pleins).
La création de clusters sous un réseau virtuel personnalisé nécessite plus d’autorisations
Vos clusters avec un réseau virtuel personnalisé ont été créés sans autorisation de jointure de réseau virtuel. Assurez-vous que les utilisateurs qui effectuent des opérations de création disposent des autorisations sur l’action Microsoft.Network/virtualNetworks/subnets/join avant le 30 septembre 2023.
En savoir plus sur Cluster HDInsight - EnforceVNetJoinPermissionCheck (La création de clusters sous un réseau virtuel personnalisé nécessite davantage d’autorisations).
Dépréciation de Kafka 1.1 dans le cluster Kafka HDInsight 4.0
Depuis le 1er juillet 2020, vous ne pouvez plus créer des clusters Kafka avec Kafka 1.1 sur HDInsight 4.0. Les clusters existants s'exécutent en l'état sans support de Microsoft. Envisagez de migrer vers Kafka 2.1 sur HDInsight 4.0 d’ici le 30 juin 2020 pour éviter une éventuelle interruption du système ou du support.
En savoir plus sur le cluster HDInsight : KafkaVersionRetirement (Dépréciation de Kafka 1.1 dans le cluster Kafka HDInsight 4.0).
Dépréciation des anciennes versions de Spark dans le cluster HDInsight Spark
Depuis le 1er juillet 2020, vous ne pouvez plus créer des clusters Spark avec Spark 2.1 et 2.2 sur HDInsight 3.6, et Spark 2.3 sur HDInsight 4.0. Les clusters existants s'exécutent en l'état sans support de Microsoft.
En savoir plus sur le cluster HDInsight : SparkVersionRetirement (Dépréciation des anciennes versions de Spark dans le cluster HDInsight Spark).
Permettre l’application des mises à jour critiques à vos clusters HDInsight
Le service HDInsight applique une mise à jour de certificat importante à votre cluster. Toutefois, une ou plusieurs stratégies de votre abonnement empêchent le service HDInsight de créer ou de modifier des ressources réseau associées à vos clusters et d’appliquer cette mise à jour. Prenez des mesures pour permettre au service HDInsight de créer ou de modifier des ressources réseau, comme l’équilibreur de charge, l’interface réseau et l’adresse IP publique, associées à vos clusters avant le 13 janvier 2021 17:00 UTC. L’équipe HDInsight effectue des mises à jour entre le 13 janvier 2021 17:00 UTC et le 16 janvier 2021 17:00 UTC. Si vous n’appliquez pas cette mise à jour, vos clusters risquent de devenir non sains et inutilisables.
En savoir plus sur le cluster HDInsight : GCSCertRotation (Permettre l’application des mises à jour critiques sur vos clusters HDInsight).
Supprimer et recréer vos clusters HDInsight pour appliquer des mises à jour critiques
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 de certificat sur certains de vos clusters.
En savoir plus sur le cluster HDInsight : GCSCertRotationRound2 (Supprimer et recréer vos clusters HDInsight pour appliquer des mises à jour critiques).
Supprimer et recréer vos clusters HDInsight pour appliquer des mises à jour critiques
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 de certificat sur certains de vos clusters. Supprimez et recréez votre cluster avant le 25 janvier 2021 pour empêcher qu’il devienne non sain et inutilisable.
En savoir plus sur le cluster HDInsight : GCSCertRotationR3DropRecreate (Supprimer et recréer vos clusters HDInsight pour appliquer des mises à jour critiques).
Appliquer les mises à jour critiques sur vos clusters HDInsight
Le service HDInsight a tenté d’appliquer une mise à jour de certificat critique sur tous vos clusters en cours d’exécution. Toutefois, une ou plusieurs stratégies de votre abonnement empêchent le service HDInsight de créer ou de modifier des ressources réseau associées à vos clusters et d’appliquer la mise à jour. Supprimez ou mettez à jour votre affectation de stratégie pour autoriser le service HDInsight à créer ou modifier des ressources réseau associées à vos clusters. Modifiez votre affectation de stratégie avant le 21 janvier 2021 17:00 UTC car l’équipe HDInsight effectue des mises à jour entre le 21 janvier 2021 17:00 UTC et le 23 janvier 2021 17:00 UTC. Pour vérifier la mise à jour de la stratégie, vous pouvez essayer de créer des ressources réseau dans le même groupe de ressources et le même sous-réseau que ceux où se trouve votre cluster. Si vous n’appliquez pas cette mise à jour, vos clusters risquent de devenir non sains et inutilisables. Vous pouvez également supprimer puis recréer votre cluster avant le 25 janvier 2021 pour empêcher qu’il ne devienne non sain et inutilisable. Le service HDInsight envoie une autre notification si nous n'arrivons pas à appliquer la mise à jour à vos clusters.
En savoir plus sur le cluster HDInsight : GCSCertRotationR3PlanPatch (Appliquer les mises à jour critiques sur vos clusters HDInsight).
Action requise : Migrer votre cluster HDInsight A8-A11 avant le 1er mars 2021
Vous recevez cette notification car vous avez un ou plusieurs clusters HDInsight A8, A9, A10 ou A11 actifs. Les machines virtuelles A8-A11 sont mises hors service dans toutes les régions le 1er mars 2021. Après cette date, tous les clusters utilisant A8-A11 sont libérés. Migrez vos clusters concernés vers une autre machine virtuelle prise en charge par HDInsight (https://azure.microsoft.com/pricing/details/hdinsight/) avant cette date. Pour plus d’informations, consultez le lien « En savoir plus » ou contactez-nous à l’adresse askhdinsight@microsoft.com
En savoir plus sur le cluster HDInsight : VM Deprecation (Action requise : Migrer votre cluster HDInsight A8-A11 avant le 1er mars 2021).
Compute
Cloud Services (classique) est mis hors service. Migrez avant le 31 août 2024
Cloud Services (classique) est mis hors service. Migrez avant le 31 août 2024 pour éviter les pertes de données ou de continuité d’activité.
En savoir plus sur Ressource - Mise hors service des services cloud (les services cloud (classiques) sont en cours de mise hors service. Migrez avant le 31 août 2024).
Mettre à niveau les disques standard attachés à votre machine virtuelle compatible Premium vers des disques Premium
Nous avons identifié que vous utilisez des disques standard avec vos machines virtuelles compatibles premium et nous vous recommandons d’envisager de les mettre à niveau vers des disques premium. Pour les machines virtuelles à une seule instance utilisant un stockage premium, pour les disques de système d’exploitation et les disque de données, nous garantissons une connectivité de la machine virtuelle d’au moins 99,9 %. Tenez compte de ces facteurs lors de la prise de décision de mise à niveau. Le premier est que la mise à niveau nécessite un redémarrage de la machine virtuelle et que ce processus 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.
En savoir plus sur la machine virtuelle : MigrateStandardStorageAccountToPremium (Mettre à niveau les disques standard attachés à votre machine virtuelle compatible Premium vers des disques Premium).
Activer la réplication des machines virtuelles pour protéger vos applications contre une panne régionale
Les machines virtuelles pour lesquelles la réplication n’est pas activée vers une autre région ne sont pas résilientes face aux pannes régionales. La réplication des machines réduit considérablement les effets négatifs sur l’activité pendant la durée de la panne d’une région Azure. Nous recommandons vivement d’activer la réplication des machines virtuelles vitales pour l’entreprise de la liste suivante. Ainsi, en cas de panne, vous pouvez rapidement refaire fonctionner vos machines dans une région Azure distante. En savoir plus sur la machine virtuelle : ASRUnprotectedVMs (Activer la réplication des machines virtuelles pour protéger vos applications contre une panne régionale).
Mettre à niveau une machine virtuelle depuis des disques non managés Premium vers des disques managés sans coût supplémentaire
Nous avons identifié que 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. 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. Cette mise à niveau peut être effectuée via le portail en moins de 5 minutes.
Mettre à jour votre protocole de connectivité sortante vers des balises de service pour Azure Site Recovery
L’utilisation du filtrage basé sur l’adresse IP a été identifiée comme un moyen vulnérable de contrôler la connectivité sortante pour les pare-feu. Nous conseillons d’utiliser des étiquettes de service comme alternative au contrôle de la connectivité. Nous vous recommandons vivement d’utiliser des balises de service pour assurer la connectivité des ordinateurs aux services Azure Site Recovery.
Mettre à jour configurations de votre pare-feu pour autoriser les nouvelles IP RHUI 4.
Vos Virtual Machine Scale Sets commenceront à recevoir le contenu du package des serveurs RHUI4 le 12 octobre 2023. Si vous autorisez les adresses IP RHUI 3 [https://aka.ms/rhui-server-list] via le pare-feu et le proxy, autorisez les nouvelles adresses IP RHUI 4 [https://aka.ms/rhui-server-list] à continuer de recevoir les mises à jour du package RHEL.
En savoir plus sur Machine virtuelle - Rhui3ToRhui4MigrationV2 (Mettre à jour les configurations de votre pare-feu pour autoriser les nouvelles adresses IP RHUI 4).
Les machines virtuelles de votre abonnement s’exécutent sur des images dont la dépréciation a été planifiée
Les machines virtuelles de votre abonnement s’exécutent sur des images dont la dépréciation a été planifiée. Une fois l’image dépréciée, il est impossible de créer des machines virtuelles à partir de celle-ci. Effectuez une mise à niveau vers une version plus récente de l’image pour éviter une interruption de vos charges de travail.
En savoir plus sur Machine virtuelle - VMRunningDeprecatedOfferLevelImage (Les machines virtuelles de votre abonnement s’exécutent sur des images dont la dépréciation a été planifiée).
Les machines virtuelles de votre abonnement s’exécutent sur des images dont la dépréciation a été planifiée
Les machines virtuelles de votre abonnement s’exécutent sur des images dont la dépréciation a été planifiée. Une fois l’image dépréciée, il est impossible de créer des machines virtuelles à partir de celle-ci. Effectuez une mise à niveau vers une référence SKU plus récente de l’image pour éviter une interruption de vos charges de travail.
En savoir plus sur Machine virtuelle - VMRunningDeprecatedPlanLevelImage (Les machines virtuelles de votre abonnement s’exécutent sur des images dont la dépréciation a été planifiée).
Les machines virtuelles de votre abonnement s’exécutent sur des images dont la dépréciation a été planifiée
Les machines virtuelles de votre abonnement s’exécutent sur des images dont la dépréciation a été planifiée. Une fois l’image dépréciée, il est impossible de créer des machines virtuelles à partir de celle-ci. Effectuez une mise à niveau vers une version plus récente de l’image pour éviter toute interruption de vos charges de travail.
En savoir plus sur Machine virtuelle - VMRunningDeprecatedImage (Les machines virtuelles de votre abonnement s’exécutent sur des images dont la dépréciation a été planifiée).
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.
En savoir plus sur Machine virtuelle - AvailabilityZoneVM (Utiliser des zones de disponibilité pour une meilleure résilience et disponibilité).
Utiliser la fonctionnalité Disques managés pour améliorer la fiabilité des données
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.
En savoir plus sur le groupe à haute disponibilité : ManagedDisksAvSet (Utiliser la fonctionnalité Disques managés pour améliorer la fiabilité des données).
Accéder aux URL obligatoires qui font défaut à votre environnement Azure Virtual Desktop
Pour qu’un hôte de session se déploie et s’inscrive correctement sur Azure Virtual Desktop, vous devez ajouter un ensemble d’URL à la liste autorisée, au cas où votre machine virtuelle s’exécute dans un environnement restreint. Après avoir visité le lien « En savoir plus », vous voyez la liste minimale des URL que vous devez débloquer pour que le déploiement réussisse et pour que l'hôte de session soit fonctionnel. Si des URL spécifiques manquent dans la liste autorisée, vous pouvez également rechercher l’événement 3702 dans le journal des événements de l’application.
En savoir plus sur la machine virtuelle : SessionHostNeedsAssistanceForUrlCheck (Accéder aux URL obligatoires qui font défaut à votre environnement Azure Virtual Desktop).
Mettre à jour configurations de votre pare-feu pour autoriser les nouvelles IP RHUI 4.
Vos Virtual Machine Scale Sets commenceront à recevoir le contenu du package des serveurs RHUI4 le 12 octobre 2023. Si vous autorisez les adresses IP RHUI 3 [https://aka.ms/rhui-server-list] via le pare-feu et le proxy, autorisez les nouvelles adresses IP RHUI 4 [https://aka.ms/rhui-server-list] à continuer de recevoir les mises à jour du package RHEL.
En savoir plus sur Groupe de machines virtuelles identiques - Rhui3ToRhui4MigrationVMSS (Mettre à jour vos configurations de pare-feu pour autoriser les nouvelles adresses IP RHUI 4).
Les Virtual Machine Scale Sets de votre abonnement s’exécutent sur des images dont la dépréciation a été planifiée
Les Virtual Machine Scale Sets de votre abonnement s’exécutent sur des images dont la dépréciation a été planifiée. Une fois l’image dépréciée, les charges de travail de vos Virtual Machine Scale Sets ne seront plus mises à l’échelle. Effectuez une mise à niveau vers une version plus récente de l’image pour éviter une interruption de votre charge de travail.
Les Virtual Machine Scale Sets de votre abonnement s’exécutent sur des images dont la dépréciation a été planifiée
Les Virtual Machine Scale Sets de votre abonnement s’exécutent sur des images dont la dépréciation a été planifiée. Une fois l’image dépréciée, les charges de travail de vos Virtual Machine Scale Sets ne seront plus mises à l’échelle. Effectuez une mise à niveau vers une version plus récente de l’image pour éviter une interruption de votre charge de travail.
Les Virtual Machine Scale Sets de votre abonnement s’exécutent sur des images dont la dépréciation a été planifiée
Les Virtual Machine Scale Sets de votre abonnement s’exécutent sur des images dont la dépréciation a été planifiée. Une fois l’image dépréciée, les charges de travail de vos Virtual Machine Scale Sets ne seront plus mises à l’échelle. Effectuez une mise à niveau vers un plan plus récent de l’image pour éviter une interruption de votre charge de travail.
Containers
Augmenter le nombre minimal de réplicas pour votre application conteneur
Nous avons détecté que le nombre minimal de réplicas défini pour votre application de conteneur peut être inférieur au nombre optimal. Envisagez d’augmenter le nombre minimal de réplicas pour une meilleure disponibilité.
En savoir plus sur Application Container Apps Microsoft - ContainerAppMinimalReplicaCountTooLow (Augmenter le nombre minimal de réplicas de votre application de conteneur).
Renouveler un certificat de domaine personnalisé
Nous avons détecté que le certificat de domaine personnalisé que vous avez chargé est sur le point d’expirer. Renouvelez votre certificat et chargez le nouveau certificat de vos applications de conteneurs.
En savoir plus sur Microsoft App Application de conteneur - ContainerAppCustomDomainCertificateNearExpiration (Renouveler un certificat de domaine personnalisé).
Un problème potentiel de réseau a été identifié sur l’environnement de vos applications de conteneurs qui nécessite qu’il soit recréé pour éviter des problèmes DNS
Un problème potentiel de réseau a été identifié sur les environnements de vos applications de conteneurs. Pour éviter ce problème potentiel de réseau, créez un nouvel environnement pour vos applications de conteneurs, recréez vos applications de conteneurs dans le nouvel environnement et supprimez l’ancien environnement de vos applications de conteneurs
La vérification du domaine est requise pour renouveler votre App Service Certificate
Vous disposez d’un certificat App Service qui se trouve actuellement dans un état d’Émission en attente et nécessite une vérification de domaine. L’échec de la validation de la propriété du domaine entraîne l’échec de l’émission de certificat. La vérification de domaine n’est pas automatisée pour les certificats App Service et nécessite une action de votre part.
En savoir plus sur App Service Certificate - ASCDomainVerificationRequired (Vérification de domaine requise pour renouveler votre App Service Certificate).
Clusters ayant des pools de nœuds utilisant la série B non recommandée
Le cluster a un ou plusieurs pools de nœuds utilisant une référence SKU de machine virtuelle burstable non recommandée. Avec les machines virtuelles burstables, la capacité totale du processeur virtuel à 100 % n’est pas garantie. Assurez-vous de ne pas utiliser de machines virtuelles de série B dans un environnement de production.
En savoir plus sur Service Kubernetes - ClustersUsingBSeriesVMs (Clusters ayant des pools de nœuds utilisant la série B non recommandée).
Mettre à niveau des clusters stratégiques et de production vers le niveau Standard
Ce cluster a plus de 10 nœuds et n’a pas activé le niveau standard. Le plan de contrôle Kubernetes du niveau Gratuit est fourni avec des ressources limitées et n’est pas destiné à un usage en production ou à un cluster comportant au moins 10 nœuds.
En savoir plus sur Service Kubernetes - UseStandardpricingtier (Mise à niveau vers le niveau standard des clusters stratégiques et de production).
Budgets d’interruption de pod recommandés
Budgets d’interruption de pod recommandés. Améliorer la haute disponibilité du service.
En savoir plus sur le service Kubernetes : PodDisruptionBudgetsRecommended (Budgets d’interruption de pod recommandés).
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.
En savoir plus sur Kubernetes avec Azure Arc : Mise à niveau de la version de l’agent K8s avec Arc (Effectuer une mise à niveau vers la dernière version de l’agent de Kubernetes avec Azure Arc).
Bases de données
Réplication : ajouter une clé primaire à la table qui n’en a pas actuellement
Sur la base de notre supervision interne, nous avons observé un décalage important de la réplication sur votre serveur réplica. Ce décalage se produit parce que le serveur réplica relit les journaux de relais sur une table sans clé primaire. Pour vous assurer que le réplica peut se synchroniser avec le principal et suivre les modifications, ajoutez des clés primaires aux tables du serveur principal. Une fois les clés primaires ajoutées, recréez le serveur réplica.
En savoir plus sur Serveur flexible Azure Database pour MySQL - MySqlFlexibleServerReplicaMissingPKfb41 (Réplication - Ajouter une clé primaire à la table qui n’en a pas actuellement).
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é. Le serveur de secours relisant des journaux de relais et se connectant à une table sans clé primaire est la principale cause du décalage. Pour résoudre ce problème et respecter les meilleures pratiques, nous vous recommandons d’ajouter des clés primaires à toutes les tables. Une fois les clés primaires ajoutées, désactivez puis réactivez la haute disponibilité pour atténuer le problème.
En savoir plus sur Serveur flexible Azure Database pour MySQL - MySqlFlexibleServerHAMissingPKcf38 (Haute disponibilité - Ajouter une clé primaire à la table qui n’en a pas actuellement.).
La disponibilité peut être impactée par une fragmentation élevée de la mémoire. Augmentez la réservation de mémoire pour la fragmentation pour éviter
La fragmentation et la sollicitation de la mémoire peuvent entraîner des incidents de disponibilité pendant une opération de basculement ou de gestion. L’augmentation de la réservation de mémoire pour la fragmentation aide à réduire les échecs de cache en cas de sollicitation élevée de la mémoire. La mémoire pour la fragmentation peut être augmentée avec le paramètre maxfragmentationmemory-reserved disponible dans la zone d’option des paramètres avancés.
Activer la sauvegarde Azure pour SQL sur vos machines virtuelles
Activez les sauvegardes pour les bases de données SQL sur vos machines virtuelles à l’aide de la sauvegarde Azure et 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 savoir plus sur Machine virtuelle SQL - EnableAzBackupForSQL (Activer la sauvegarde Azure pour SQL sur vos machines virtuelles).
Améliorer la disponibilité de PostgreSQL en supprimant les emplacements de réplication logique inactifs
Notre système interne indique que votre serveur PostgreSQL peut avoir des emplacements de réplication logique inactifs. CELA NÉCESSITE UNE ATTENTION IMMÉDIATE. Une réplication logique inactive peut entraîner une dégradation des performances et une indisponibilité du serveur en raison de la rétention de fichiers WAL et de la génération de fichiers instantanés. Pour améliorer les performances et la disponibilité, nous vous recommandons VIVEMENT de prendre IMMÉDIATEMENT des mesures. 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.
En savoir plus sur le serveur PostgreSQL : OrcasPostgreSqlLogicalReplicationSlots (Améliorer la disponibilité de PostgreSQL en supprimant les emplacements de réplication logique inactifs).
Améliorer la disponibilité de PostgreSQL en supprimant les emplacements de réplication logique inactifs
Notre système interne indique que votre serveur flexible PostgreSQL peut avoir des emplacements de réplication logique inactifs. CELA NÉCESSITE UNE ATTENTION IMMÉDIATE. 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 et de la génération de fichiers instantanés. Pour améliorer les performances et la disponibilité, nous vous recommandons VIVEMENT de prendre IMMÉDIATEMENT des mesures. 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.
Configurer le mode d’indexation cohérent sur votre conteneur Azure Cosmos DB
Nous avons remarqué que votre conteneur Azure Cosmos DB est configuré en mode d’indexation différée, ce qui peut avoir un effet sur l’actualisation des résultats des requêtes. Nous vous recommandons de passer au mode cohérent.
En savoir plus sur le compte Azure Cosmos DB : CosmosDBLazyIndexing (Configurer le mode d’indexation cohérent sur votre conteneur Azure Cosmos DB).
Mettre à niveau votre ancienne version du SDK Azure Cosmos DB vers la dernière version
Votre compte Azure Cosmos DB utilise une ancienne version 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.
En savoir plus sur le compte Azure Cosmos DB : CosmosDBUpgradeOldSDK (Mettre à niveau votre ancienne version du SDK Azure Cosmos DB vers la dernière version).
Mettre à niveau le SDK Azure Cosmos DB obsolète vers la dernière version
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.
En savoir plus sur le compte Azure Cosmos DB : CosmosDBUpgradeOutdatedSDK (Mettre à niveau le SDK Azure Cosmos DB obsolète vers la dernière version).
Configurer vos conteneurs Azure Cosmos DB avec une clé de partition
Vos collections Azure Cosmos DB non partitionnées sont sur le point d’atteindre leur quota de stockage approvisionné. Migrez ces collections vers de nouvelles collections ayant une définition de clé de partition de manière à ce que le service puisse automatiquement les mettre à l’échelle.
En savoir plus sur le compte Azure Cosmos DB : CosmosDBFixedCollections (Configurer vos conteneurs Azure Cosmos DB avec une clé de partition).
Mettre à niveau votre compte Azure Cosmos DB for MongoDB vers la version 4.0 pour réduire les coûts des requêtes/du stockage et utiliser les nouvelles fonctionnalités
Votre compte Azure Cosmos DB for MongoDB peut être mis à niveau vers la version 4.0. Réduisez vos coûts de stockage jusqu’à 55 % et les coûts de vos requêtes jusqu’à 45 % en effectuant une mise à niveau vers le nouveau format de stockage v4.0. De nombreuses autres fonctionnalités, comme les transactions multidocuments, sont également incluses dans la version 4.0.
Ajouter une deuxième région à vos charges de travail de production sur Azure Cosmos DB
En fonction de leurs noms et de leur configuration, nous avons détecté des comptes Azure Cosmos DB répertoriés comme étant potentiellement utilisés pour des charges de travail de production. Ces comptes sont actuellement exécutés dans une seule région Azure. Vous pouvez augmenter leur disponibilité en les configurant de façon à ce qu’ils s’étendent sur au moins deux régions Azure.
Remarque
Des régions supplémentaires entraînent des frais supplémentaires.
En savoir plus sur le compte Azure Cosmos DB : CosmosDBSingleRegionProdAccounts (Ajouter une deuxième région à vos charges de travail de production sur Azure Cosmos DB).
Activer la nouvelle tentative côté serveur (SSR) sur votre compte Azure Cosmos DB for MongoDB
Nous avons observé que votre 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 ce problème.
En savoir plus sur le compte Azure Cosmos DB : CosmosDBMongoServerSideRetries (Activer la nouvelle tentative côté serveur [SSR] sur votre compte Azure Cosmos DB for MongoDB).
Migrer votre compte Azure Cosmos DB for MongoDB vers la version 4.0 pour réduire les coûts des requêtes/du stockage et utiliser les nouvelles fonctionnalités
Migrez votre compte de base de données vers un nouveau compte de base de données afin de tirer parti d’Azure Cosmos DB for MongoDB v4.0. Réduisez vos coûts de stockage jusqu’à 55 % et les coûts de vos requêtes jusqu’à 45 % en effectuant une mise à niveau vers le nouveau format de stockage v4.0. De nombreuses autres fonctionnalités, comme les transactions multidocuments, sont également incluses dans la version 4.0. Lors de la mise, vous devez également migrer les données de votre compte existant vers un nouveau compte créé en utilisant la version 4.0. Azure Data Factory ou Studio 3T peuvent vous aider à migrer vos données.
Votre compte Azure Cosmos DB ne peut pas accéder à son coffre de clés Azure lié qui héberge votre clé de chiffrement
Il semble que la configuration de votre coffre de clés empêche votre compte Azure 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é, vérifiez que la clé ou version de clé précédente reste activée et disponible jusqu’à ce qu’Azure 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 d’activité Azure Cosmos DB sur cette clé ou version de clé.
En savoir plus sur le compte Azure Cosmos DB : CosmosDBKeyVaultWrap (Votre compte Azure Cosmos DB ne peut pas accéder à son coffre de clés Azure lié qui héberge votre clé de chiffrement).
Éviter la limitation de débit par les opérations de métadonnées
Nous avons observé un nombre élevé d’opérations de métadonnées sur votre compte. Vos données dans Azure Cosmos DB, dont les métadonnées relatives à vos bases de données et collections, sont réparties sur plusieurs partitions. Les opérations de métadonnées présentent une limite d’unités de requête réservées par le système. Un nombre élevé d’opérations de métadonnées peut entraîner une limitation de débit. Évitez la limitation de débit en utilisant des instances clientes Azure Cosmos DB statiques dans votre code et en mettant en cache les noms des bases de données et des collections.
En savoir plus sur le compte Azure Cosmos DB : CosmosDBHighMetadataOperations (Éviter la limitation de débit par les opérations de métadonnées).
Utiliser le nouveau point de terminaison 3.6+ pour vous connecter à votre compte Azure Cosmos DB for MongoDB mis à niveau
Nous avons observé que certaines de vos applications se connectent à votre compte Azure Cosmos DB for 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).
En savoir plus sur le compte Azure Cosmos DB : CosmosDBMongoNudge36AwayFrom32 (Utiliser le nouveau point de terminaison 3.6+ pour vous connecter à votre compte Azure Cosmos DB for MongoDB mis à niveau).
Effectuer une mise à niveau vers la version 2.6.14 du SDK Java Async v2 pour éviter un problème critique ou effectuer une mise à niveau vers le SDK Java v4 car le SDK Java Async v2 est déprécié
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. Ces erreurs de service se produisent lorsqu’un grand nombre de transactions ont lieu au cours de la durée de vie d’un conteneur Azure Cosmos DB. Remarque : Il s’agit d’un correctif logiciel critique pour le kit de développement logiciel (SDK) Java asynchrone v2. Toutefois, nous vous recommandons vivement de migrer vers le kit de développement logiciel (SDK) Java v4.
Effectuer une mise à niveau vers la version recommandée du SDK Java v4 pour éviter un problème critique
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. Ces erreurs de service se produisent lorsqu’un grand nombre de transactions ont lieu au cours de la durée de vie d’un conteneur Azure Cosmos DB.
En savoir plus sur le compte Azure Cosmos DB : CosmosDBMaxGlobalLSNReachedV4 (Effectuer une mise à niveau vers la version recommandée du SDK Java v4 pour éviter un problème critique).
Intégration
Mettre à niveau vers la dernière version de l’API FarmBeats
Nous avons identifié des appels à une version de l’API FarmBeats dont la dépréciation est planifiée. Nous vous recommandons de passer à la dernière version de l’API FarmBeats pour garantir un accès ininterrompu à FarmBeats, aux fonctionnalités les plus récentes et aux améliorations des performances.
En savoir plus sur Azure FarmBeats : FarmBeatsApiVersion (Mettre à niveau vers la dernière version de l’API FarmBeats).
Effectuer la mise à niveau vers la dernière version ADMA Java du kit SDK
Nous avons identifié les appels à une version du Kit de développement logiciel (SDK) Java Azure Data Manager for Agriculture (ADMA) dont l'obsolescence est programmée. Nous vous recommandons de passer à la dernière version du kit SDK pour garantir un accès ininterrompu à ADMA, aux fonctionnalités les plus récentes et aux améliorations des performances.
En savoir plus sur Azure FarmBeats – FarmBeatsJavaSdkVersion (Mise à niveau vers la dernière version du kit SDK Java ADMA).
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. Nous vous recommandons de passer à la dernière version du kit SDK pour garantir un accès ininterrompu à ADMA, aux fonctionnalités les plus récentes et aux améliorations des performances.
En savoir plus sur Azure FarmBeats – FarmBeatsDotNetSdkVersion (Mise à niveau vers la dernière version du kit SDK ADMA DotNet).
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. Nous vous recommandons de passer à la dernière version du kit SDK pour garantir un accès ininterrompu à ADMA, aux fonctionnalités les plus récentes et aux améliorations des performances.
En savoir plus sur Azure FarmBeats – FarmBeatsJavaScriptSdkVersion (Mise à niveau vers la dernière version du kit SDK ADMA JavaScript).
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. Nous vous recommandons de passer à la dernière version du kit SDK pour garantir un accès ininterrompu à ADMA, aux fonctionnalités les plus récentes et aux améliorations des performances.
En savoir plus sur Azure FarmBeats – FarmBeatsPythonSdkVersion (Mise à niveau vers la dernière version du kit SDK ADMA Python).
Renégociation SSL/TLS bloquée
La tentative de renégociation SSL/TLS est bloquée. Une renégociation se produit quand un certificat client est demandé sur une connexion déjà établie. Lorsqu’elle est bloquée, la lecture de « context.Request.Certificate » dans les expressions de stratégie retourne la valeur « null». 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, l’activation de cette option peut à la présentation d’une demande de certificat au client.
En savoir plus sur Gestion des API : TlsRenegotiationBlocked (Renégociation SSL/TLS bloquée).
Échec de la rotation des certificats de nom d’hôte
Le service Gestion des API n’a pas pu actualiser le certificat de nom d’hôte à partir de Key Vault. Vérifiez que le certificat existe dans Key Vault et que l’identité du service Gestion des API bénéficie d’un accès en lecture aux secrets. Dans le cas contraire, le service de Gestion des API ne peut pas récupérer les mises à jour de certificats à partir de Key Vault, ce qui peut amener le service à utiliser un certificat périmé et entraîner le blocage du trafic des API de runtime.
En savoir plus sur Gestion des API : HostnameCertRotationFail (Échec de la rotation des certificats de nom d’hôte).
Internet des Objets
Mettre à niveau le SDK client de l’appareil vers une version prise en charge pour IotHub
Certains ou l’ensemble de vos appareils utilisent un SDK obsolète et nous vous recommandons de le mettre à niveau vers une version prise en charge. Consultez les détails dans la recommandation.
En savoir plus sur le hub IoT : UpgradeDeviceClientSdk (Mettre à niveau le SDK client de l’appareil vers une version prise en charge pour IotHub).
Tempête potentielle d’appareil IoT Hub détectée
Une tempête d’appareil se produit quand au moins deux appareils tentent de se connecter au IoT Hub 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).
En savoir plus sur IoT Hub - IoTHubDeviceStorm (Tempête potentielle d’appareil IoT Hub détectée).
Mettre à niveau le kit de développement logiciel (SDK) Device Update pour IoT Hub vers une version prise en charge
Votre instance Device Update pour IoT Hub utilise une version obsolète du kit de développement logiciel (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.
En savoir plus sur IoT Hub - DU_SDK_Advisor_Recommendation (Mettre à niveau le kit de développement logiciel (SDK) Device Update pour IoT Hub vers une version prise en charge).
Détection d’un dépassement de quota IoT Hub
Nous avons détecté que votre IoT Hub avait dépassé son quota quotidien de messages. Pour empêcher votre IoT Hub de dépasser son quota de messages quotidiens à l’avenir, ajoutez des unités ou augmentez le niveau de référence SKU.
En savoir plus sur IoT Hub - IoTHubQuotaExceededAdvisor (Dépassement du quota IoT Hub détecté).
Mettre à niveau le kit de développement logiciel (SDK) client de l’appareil vers une version prise en charge par IotHub
Certains ou l’ensemble de vos appareils utilisent un SDK obsolète et nous vous recommandons de le mettre à niveau vers une version prise en charge. Consultez les détails dans le lien donné.
En savoir plus sur le hub IoT : UpgradeDeviceClientSdk (Mettre à niveau le SDK client de l’appareil vers une version prise en charge pour IotHub).
Mettre à niveau le runtime des appareils Microsoft Edge vers une version prise en charge pour IoT Hub
Certains ou l’ensemble de vos appareils Microsoft Edge utilisent des versions obsolètes et nous vous recommandons de les mettre à niveau vers la dernière version prise en charge du runtime. Consultez les détails dans le lien donné.
En savoir plus sur IoT Hub : UpgradeEdgeSdk (Mettre à niveau le runtime des appareils Microsoft Edge vers une version prise en charge par IoT Hub).
Média
Augmenter les quotas ou limites de Media Services pour garantir la continuité du service
Votre compte média est sur le point d’atteindre sa limite de quota. Vérifiez l’utilisation actuelle des ressources, ainsi que les stratégies de clés de contenu et les stratégies de flux pour le compte Media Services. Pour éviter une interruption de service, demandez une augmentation des limites de quotas des entités qui sont sur le point d’atteindre la limite de quota. Vous pouvez demander une augmentation des quotas en créant un ticket et en y ajoutant les informations nécessaires. Ne créez pas de comptes Azure Media supplémentaires pour tenter d’obtenir des limites plus élevées.
En savoir plus sur Media Services : AccountQuotaLimit (Augmenter les quotas et les limites Media Services pour garantir la continuité du service).
Mise en réseau
Il se peut que la machine virtuelle Check Point perde la connectivité réseau
Nous avons identifié qu’il est possible que votre machine virtuelle exécute une version de l’image Check Point susceptible de perdre la connectivité réseau pendant une opération de maintenance de la plateforme. Nous vous recommandons de mettre à niveau vers une version plus récente de l’image. Pour obtenir des instructions supplémentaires sur la façon de mettre à niveau votre image, contactez Check Point.
En savoir plus sur Machine virtuelle - CheckPointPlatformServicingKnownIssueA (La machine virtuelle Check Point est susceptible de perdre la connectivité réseau.).
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.
En savoir plus sur Agent Connected Machine - Azure Arc - ArcServerAgentVersion (Mettre à niveau vers la dernière version de l’agent Azure Connected Machine).
Remplacer la version du secret par « La plus récente » pour le certificat client Azure Front Door
Nous recommandons de configurer le secret du certificat client Azure Front Door (AFD) sur « version la plus récente » pour qu’AFD se réfère à la version du secret la plus récente dans Azure Key Vault, afin que le secret puisse être automatiquement pivoté.
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 au fournisseur DNS.
En savoir plus sur Profil Front Door - ValidateDomainOwnership (Valider la propriété d’un domaine en ajoutant un enregistrement TXT DNS au fournisseur DNS.).
Revalider la propriété du domaine pour le renouvellement du certificat managé Azure Front Door
Azure Front Door 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é.
En savoir plus sur Profil Front Door - RevalidateDomainOwnership (Revalider la propriété du domaine pour le renouvellement du certificat managé Azure Front Door).
Renouveler le certificat client Azure Front Door venant à expiration pour éviter toute interruption de service
Certains certificats client pour des profils Azure Front Door Standard et Premium ont expiré. Renouvelez le certificat à temps pour éviter une interruption de service.
En savoir plus sur Profil Front Door - RenewExpiredBYOC (Renouveler le certificat client Azure Front Door expiré pour éviter une interruption de service.).
Mettre à niveau votre référence SKU ou ajouter d’autres instances pour assurer la tolérance de panne
Le déploiement de deux ou plusieurs instances moyennes ou grandes garantit la continuité des activités pendant les interruptions provoquées par une maintenance planifiée ou non.
En savoir plus sur l’amélioration de la fiabilité de votre application à l’aide d’Azure Advisor : garantir la tolérance de panne de la passerelle d’application).
Éviter le remplacement du nom d’hôte pour garantir l’intégrité du site
Dans la mesure du possible, évitez de remplacer le nom d’hôte lors de la configuration d’Application Gateway. Le fait d’avoir un domaine sur le front-end d’Application Gateway différent de celui utilisé pour accéder au back-end peut éventuellement entraîner des cookies ou des URL de redirection cassées. 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. 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 back-end.
En savoir plus sur la passerelle applicative : AppGatewayHostOverride (Éviter le remplacement du nom d’hôte pour garantir l’intégrité du site).
Azure WAF RuleSet CRS 3.1/3.2 a été mis à jour avec la règle de vulnérabilité Log4j 2
En réponse à la vulnérabilité Log4j 2 (CVE-2021-44228), Azure Web Application Firewall (WAF) RuleSet CRS 3.1/3.2 a été mis à jour sur votre Application Gateway pour aider à fournir une protection supplémentaire contre cette vulnérabilité. Les règles sont disponibles sous la règle 944240 et aucune action n’est nécessaire pour les activer.
En savoir plus sur la passerelle applicative : AppGwLog4JCVEPatchNotification (L’ensemble de règles CRS 3.1/3.2 du WAF Azure a été mis à jour avec la règle de vulnérabilité log4j2).
Protection supplémentaire pour atténuer la vulnérabilité Log4j 2 (CVE-2021-44228)
Pour atténuer l’effet de la vulnérabilité Log4j 2, nous vous recommandons d’effectuer les étapes suivantes :
- Mettez à niveau Log4j 2 vers la version 2.15.0 sur vos serveurs principaux. Si la mise à niveau n’est pas possible, suivez le lien de l’aide sur les propriétés système fourni.
- Tirez parti des ensembles de règles de base (CRS) WAF en mettant à niveau vers la référence SKU du pare-feu d’applications web.
En savoir plus sur la passerelle applicative : AppGwLog4JCVEGenericNotification (Protection supplémentaire pour atténuer la vulnérabilité Log4j (CVE-2021-44228)).
Mettre à jour l’autorisation de réseau virtuel des utilisateurs d’Application Gateway
Pour améliorer la sécurité et fournir une expérience plus cohérente dans Azure, tous les utilisateurs doivent passer une vérification d’autorisation avant la création ou la mise à jour d’une passerelle applicative dans un réseau virtuel. Les utilisateurs ou principaux de service doivent inclure au moins l’autorisation Microsoft.Network/virtualNetworks/subnets/join/action.
En savoir plus sur Application Gateway - AppGwLinkedAccessFailureRecmmendation (Mettre à jour l’autorisation de réseau virtuel des utilisateurs Application Gateway).
Utilisez l’identifiant Key Vault sans version pour référencer les certificats
Nous vous recommandons vivement d’utiliser un identifiant secret sans version pour permettre à votre ressource de passerelle d’application de récupérer automatiquement la nouvelle version du certificat, chaque fois qu’elle est disponible. Exemple : https://myvault.vault.azure.net/secrets/mysecret/
En savoir plus sur Application Gateway - AppGwAdvisorRecommendationForCertificateUpdate (Utiliser l’identificateur de secret Key Vault sans version pour référencer les certificats).
Implémenter plusieurs circuits ExpressRoute dans votre réseau virtuel pour la résilience intersite
Nous avons détecté que la passerelle ExpressRoute est associée à un seul circuit ExpressRoute. Connectez au moins un circuit supplémentaire à votre passerelle pour assurer la redondance et la résilience de l’emplacement de peering
En savoir plus sur la passerelle de réseau virtuel : ExpressRouteGatewayRedundancy (Implémenter plusieurs circuits ExpressRoute dans votre réseau virtuel pour la résilience intersite).
Implémenter ExpressRoute Monitor sur Network Performance Monitor pour une supervision de bout en bout de votre circuit ExpressRoute
Nous avons détecté qu’ExpressRoute Monitor sur Network Performance Monitor ne surveille actuellement pas votre circuit ExpressRoute. Le moniteur ExpressRoute fournit des fonctionnalités de supervision de bout en bout, y compris la perte, la latence et les performances d’un environnement local vers Azure et d’Azure vers un environnement local
Utiliser ExpressRoute Global Reach pour améliorer la conception de la reprise d’activité
Il semble que les circuits ExpressRoute sont appairés à au moins deux emplacements différents. Connectez-les entre eux à l’aide d’ExpressRoute Global Reach pour permettre au trafic de continuer à circuler entre votre réseau local et des environnements Azure en cas de perte de connectivité d’un circuit. Vous pouvez établir des connexions Global Reach entre les circuits situés dans différents emplacements d’appairage au sein du même métro ou entre plusieurs métros.
En savoir plus sur le circuit ExpressRoute : UseGlobalReachForDR (Utiliser ExpressRoute Global Reach pour améliorer la conception de la récupération d’urgence).
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.
En savoir plus sur le profil Traffic Manager : GeneralProfile (Ajouter au moins un point de terminaison supplémentaire au profil, de préférence dans une autre région Azure).
Ajouter un point de terminaison configuré sur « Tout (international) »
Pour le routage géographique, le trafic est routé vers les points de terminaison selon des zones définies. En cas d’échec d’une région, aucun basculement n’est 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 trafic.
En savoir plus sur le profil Traffic Manager : GeographicProfile (Ajouter un point de terminaison configuré sur « Tout (international) »).
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 lorsqu’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.
En savoir plus sur le profil Traffic Manager : ProximityProfile (Ajouter ou déplacer un point de terminaison vers une autre région Azure).
Passer d’une passerelle de base à une référence SKU de passerelle de production
La référence SKU De base de passerelle VPN est conçue pour les scénarios de test ou de développement. Passez à une référence SKU de production si vous utilisez la passerelle VPN à des fins de production. Les références SKU de production offrent un plus grand nombre de tunnels, une prise en charge BGP, un mode actif-actif, une stratégie IPsec/IKE personnalisée en plus d’une meilleure stabilité et d’une meilleure disponibilité.
En savoir plus sur la passerelle de réseau virtuel : BasicVPNGateway (Passer d’une passerelle De base à des SKU de passerelle de production).
Utiliser une passerelle NAT pour la connectivité sortante
Empêchez les défaillances de connectivité dues à l’épuisement des ports 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.
En savoir plus sur le réseau virtuel - natGateway (Utiliser la passerelle NAT pour la connectivité sortante).
Mettre à jour l’autorisation de réseau virtuel des utilisateurs d’Application Gateway
Pour améliorer la sécurité et fournir une expérience plus cohérente dans Azure, tous les utilisateurs doivent passer une vérification d’autorisation avant la création ou la mise à jour d’une passerelle applicative dans un réseau virtuel. Les utilisateurs ou principaux de service doivent inclure au moins l’autorisation Microsoft.Network/virtualNetworks/subnets/join/action.
En savoir plus sur Application Gateway - AppGwLinkedAccessFailureRecmmendation (Mettre à jour l’autorisation de réseau virtuel des utilisateurs Application Gateway).
Utilisez l’identifiant Key Vault sans version pour référencer les certificats
Nous vous recommandons vivement d’utiliser un identifiant secret sans version pour permettre à votre ressource de passerelle d’application de récupérer automatiquement la nouvelle version du certificat, chaque fois qu’elle est disponible. Exemple : https://myvault.vault.azure.net/secrets/mysecret/
En savoir plus sur Application Gateway - AppGwAdvisorRecommendationForCertificateUpdate (Utiliser l’identificateur de secret Key Vault sans version pour référencer les certificats).
Activer les passerelles en mode actif-actif pour la redondance
En configuration active/active, les deux instances d'une passerelle VPN établissent des tunnels S2S VPN vers votre périphérique 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.
En savoir plus sur la passerelle de réseau virtuel : VNetGatewayActiveActive (Activer les passerelles en mode actif-actif pour la redondance).
Utiliser des certificats TLS managés
La gestion Front Door de vos certificats TLS réduit vos coûts opérationnels et vous aide à éviter des pannes coûteuses résultant d’un oubli de renouvellement de certificat.
En savoir plus sur l’utilisation de certificats TLS managés.
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 pas d’avantage et vous devez les désactiver pour réduire le trafic sur votre origine.
En savoir plus sur les meilleures pratiques de sonde d’intégrité.
Utiliser le même nom de domaine sur Azure Front Door et votre origin
Nous vous recommandons de conserver le nom d’hôte HTTP d’origine quand vous utilisez un proxy inverse devant une application web. Si le nom d’hôte au niveau du proxy inverse est différent de celui fourni au serveur d’applications de back-end, les cookies ou les URL de redirection risquent de ne pas fonctionner correctement. Par exemple, l’état de session peut être perdu, l’authentification peut échouer ou les URL de back-end peuvent être exposées par inadvertance aux utilisateurs finaux. Vous pouvez éviter ces problèmes en conservant le nom d’hôte de la demande initiale pour que le serveur d’applications puisse voir le même domaine que le navigateur web.
En savoir plus sur l’utilisation du même nom de domaine sur Azure Front Door et votre origin.
SAP pour Azure
Activer le paramètre « concurrent-fencing » dans la configuration Pacemaker dans les paramètres de haute disponibilité ASCS dans les charges de travail SAP
Le paramètre de clôture simultanée lorsqu’il est défini sur true permet aux opérations de clôture d’être effectuées en parallèle. Définissez ce paramètre sur « true » dans la configuration du cluster Pacemaker du programme d’installation HA ASCS.
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 de la ressource STONITH (Shoot The Other Node in the Head). Vérifiez que « stonith-enable » est défini sur « true » dans la configuration de cluster HA de votre charge de travail SAP.
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.
Définissez le délai d’expiration de Stonith sur 144 pour un cluster HA conformément aux recommandations pour SAP sur Azure.
Définissez le jeton corosync dans le cluster Pacemaker à 30000 pour la configuration ASCS HA dans les charges de travail SAP
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é. Définissez le jeton corosync sur 30 000 conformément aux recommandations pour SAP sur Azure afin d’autoriser la maintenance de conservation de la mémoire.
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
Dans un cluster HA à deux nœuds, définissez les votes de quorum sur 2 conformément aux recommandations pour SAP sur Azure.
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 tente le système 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 ASCS.
Définissez le jeton corosync dans le cluster Pacemaker à 30000 pour la configuration ASCS HA dans les charges de travail SAP
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é. Définissez le jeton corosync sur 30 000 conformément aux recommandations pour SAP sur Azure afin d’autoriser la maintenance de conservation de la mémoire.
Définissez le paramètre 'corosync max_messages' dans le cluster Pacemaker à 20 pour la configuration ASCS HA dans les charges de travail SAP
La constante corosync max_messages spécifie le nombre maximal de messages autorisés à être envoyés par un processeur une fois le jeton reçu. Nous vous recommandons de définir 20 fois le paramètre du jeton corosync dans la configuration du cluster Pacemaker.
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 combien de temps attendre que le consensus soit atteint avant de commencer une nouvelle série d’appartenances dans la configuration du cluster. Nous vous recommandons de définir 1,2 fois le jeton corosync dans la configuration du cluster Pacemaker pour le programme d’installation HA ASCS.
Définissez le paramètre des votes attendus sur 2 dans la configuration du cluster dans la configuration d'ASCS HA dans les charges de travail SAP
Dans un cluster HA à deux nœuds, définissez le paramètre de quorum expected_votes sur 2 conformément aux recommandations pour SAP sur Azure.
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.
Définissez le paramètre 'corosync join' dans le cluster Pacemaker à 60 pour la configuration ASCS HA dans les charges de travail SAP
Le délai d’expiration de jointure corosync spécifie en millisecondes la durée d’attente des messages de jointure dans le protocole d’appartenance. Nous vous recommandons de définir 60 dans la configuration du cluster Pacemaker pour le programme d’installation HA ASCS.
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 de la ressource STONITH (Shoot The Other Node in the Head). Vérifiez que « stonith-enable » est défini sur « true » dans la configuration du cluster HA.
Définissez stonith-timeout sur 900 dans la configuration Pacemaker avec l’agent de clôture Azure pour le programme d’installation HA ASCS
Définissez stonith-timeout sur 900 pour une fonction fiable de Pacemaker dans le programme d’installation HA ASCS. Ce paramètre stonith-timeout s’applique si vous utilisez un agent de clôture Azure pour une clôture avec l’identité managée ou le principal de service.
Activer le paramètre « concurrent-fencing » dans la configuration Pacemaker dans les paramètres de haute disponibilité ASCS dans les charges de travail SAP
Le paramètre de clôture simultanée lorsqu’il est défini sur true permet aux opérations de clôture d’être effectuées en parallèle. Définissez ce paramètre sur « true » dans la configuration du cluster Pacemaker du programme d’installation HA ASCS.
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 le programme d’installation HA ASCS.
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 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 le programme d’installation HA ASCS.
Vérifier qu’il existe une instance de fence_azure_arm dans la configuration Pacemaker pour le programme d’installation HA ASCS
L’agent fence_azure_arm est un agent de clôture d’E/S d’Azure Resource Manager. Vérifiez qu’il existe une instance de fence_azure_arm dans votre configuration Pacemaker pour le programme d’installation HA ASCS. L’exigence fence_azure_arm s’applique si vous utilisez un agent de clôture Azure pour une clôture avec l’identité managée ou le principal de service.
Activer les ports HA dans Azure Load Balancer pour la configuration de la haute disponibilité ASCS dans les charges de travail SAP
Activez les ports HA dans des règles d’équilibrage de charge 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/modifiez la règle pour activer les paramètres recommandés.
En savoir plus sur Instance de serveur central - ASCSHAEnableLBPorts (Activer les ports HA dans Azure Load Balancer pour le programme d’installation HA ASCS dans des charges de travail SAP).
Activer l’adresse IP flottante dans Azure Load Balancer pour la configuration de la haute disponibilité ASCS dans les charges de travail SAP
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/modifiez la règle pour activer les paramètres recommandés.
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/modifiez la règle pour activer les paramètres recommandés.
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ésactivez les horodatages TCP sur les machines virtuelles placées derrière Azure Load Balancer. Des timestamps TCP activés provoquent l’échec des sondes d’intégrité en raison de l’annulation des paquets TCP par la pile TCP du système d’exploitation invité de la machine virtuelle. Des paquets annulés font en sorte que l’équilibreur de charge marque le point de terminaison comme inactif.
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). Vérifiez que « stonith-enable » est défini sur « true » dans la configuration de cluster HA de votre charge de travail SAP.
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é
Définissez le délai d’expiration de Stonith sur 144 pour un cluster HA conformément aux recommandations pour SAP sur Azure.
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). Vérifiez que « stonith-enable » est défini sur « true » dans la configuration du cluster HA.
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
Définissez stonith-timeout sur 900 pour un fonctionnement fiable de Pacemaker pour le programme d’installation HA de la base de données HANA. Ce paramètre est important si vous utilisez un agent de clôture Azure pour une clôture avec une identité managée ou un principal de service.
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 Redhat
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é. Définissez le jeton corosync sur 30 000 conformément aux recommandations pour SAP sur Azure afin d’autoriser la maintenance de conservation de la mémoire.
Définissez le paramètre de votes attendus sur 2 dans la configuration du cluster dans les charges de travail SAP compatibles haute disponibilité
Dans un cluster HA à deux nœuds, définissez les votes de quorum sur 2 conformément aux recommandations pour SAP sur Azure.
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é. Définissez le jeton corosync sur 30 000 conformément aux recommandations pour SAP sur Azure afin d’autoriser la maintenance de conservation de la mémoire.
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 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.
Activer le paramètre « concurrent-fencing » dans la cofiguration Pacemaker pour la configuration de la haute disponibilité de base de données HANA
Le paramètre de clôture concurrent, lorsqu'il a la valeur true, permet aux opérations de clôture d'être effectuées en parallèle. 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.
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.
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.
Définir 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.
Activez le paramètre "concurrent-fencing" dans la configuration du cluster pour les charges de travail SAP compatibles HA
Le paramètre de clôture concurrent, lorsqu'il a la valeur true, permet aux opérations de clôture d'être effectuées en parallèle. 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.
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 jointure corosync spécifie en millisecondes la durée d’attente des messages de jointure dans le protocole d’appartenance. Nous vous recommandons de définir 60 dans la configuration du cluster Pacemaker pour le programme d’installation HA de la base de données HANA.
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 autorisés à être envoyés par un processeur une fois le jeton reçu. Nous vous recommandons de définir 20 fois le paramètre du jeton corosync dans la configuration du cluster Pacemaker.
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 combien de temps attendre que le consensus soit atteint avant de commencer une nouvelle série d’appartenances dans la configuration du cluster. Nous vous recommandons de définir 1,2 fois le jeton corosync dans la configuration du cluster Pacemaker pour le programme d’installation HA de la base de données HANA.
Créer le fichier de configuration softdog dans la configuration Pacemaker pour activer la haute disponibilité de la base de données HANA 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 le programme d’installation HA de la base de données HANA.
Vérifier 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
L’agent fence_azure_arm est un agent de clôture d’E/S d’Azure Resource Manager. Vérifiez qu’il existe une instance de fence_azure_arm dans votre configuration Pacemaker pour le programme d’installation HA de la base de données HANA. L’exigence d’instance fence_azure_arm s’applique si vous utilisez un agent de clôture Azure pour une clôture avec une identité managée ou un principal de service.
Vérifiez que le module softdog est chargé dans Pacemaker dans la base de données HANA à haute disponibilité 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 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 le programme d’installation HA de la base de données HANA.
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 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/modifiez la règle pour activer les paramètres recommandés.
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
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/modifiez la règle pour activer les paramètres recommandés.
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
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/modifiez la règle pour activer les paramètres recommandés.
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. Des timestamps TCP activés provoquent l’échec des sondes d’intégrité en raison de l’annulation des paquets TCP par la pile TCP du système d’exploitation invité de la machine virtuelle. Des paquets annulés font en sorte que l’équilibreur de charge marque le point de terminaison comme inactif.
Il doit y avoir une instance de fence_azure_arm dans la configuration Pacemaker pour la configuration de la haute disponibilité de la base de données HANA
L’agent fence_azure_arm est un agent de clôture d’E/S d’Azure Resource Manager. 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. Le fence_azure_arm est nécessaire si vous utilisez un agent de clôture Azure pour une clôture avec l’identité managée ou le principal de service.
Stockage
Activer la suppression réversible pour vos coffres Recovery Services
L’option de suppression réversible vous permet de conserver vos données de sauvegarde dans le coffre Recovery Services pendant une durée supplémentaire après la suppression. La durée supplémentaire vous donne la possibilité de récupérer les données avant de les supprimer définitivement.
En savoir plus sur le coffre Recovery Services : AB-SoftDeleteRsv (Activer la suppression réversible pour vos coffres Recovery Services).
Activer la restauration inter-région pour votre coffre Recovery Services
Activation de la restauration inter-région pour vos coffres géoredondants.
En savoir plus sur Coffre Recovery Services : Activer CRR (Activer la restauration interrégion de votre coffre Recovery Services).
Activer le sauvegardes sur vos machines virtuelles
Activer les sauvegardes de vos machines virtuelles et sécuriser vos données.
En savoir plus sur Machine virtuelle (classique) : EnableBackup (Activer les sauvegardes sur vos machines virtuelles).
Configurer une sauvegarde de blob
Configurez une sauvegarde de blob.
En savoir plus sur Compte de stockage - ConfigureBlobBackup (Configurer la sauvegarde de blob).
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 une sélection à 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.
En savoir plus sur Abonnement - AzureBackupService (Activer la Sauvegarde Azure pour obtenir une protection simple, fiable et rentable de vos données).
Vous avez des comptes ADLS Gen1 qui doivent être migrés vers ADLS Gen2
Comme annoncé précédemment, Azure Data Lake Storage Gen1 sera mis hors service le 29 février 2024. Nous vous recommandons vivement de migrer votre lac de données vers Azure Data Lake Storage Gen2. Azure Data Lake Storage Gen2 offre des fonctionnalités avancées conçues pour l’analytique Big Data des entreprises et s’appuie sur le stockage Blob Azure.
En savoir plus sur Compte Data Lake Store - ADLSGen1_Deprecation (Vous avez des comptes ADLS Gen1 qui doivent être migrés vers ADLS Gen2).
Vous avez des comptes ADLS Gen1 qui doivent être migrés vers ADLS Gen2
Comme annoncé précédemment, Azure Data Lake Storage Gen1 sera mis hors service le 29 février 2024. Nous vous recommandons vivement de migrer votre lac de données vers Azure Data Lake Storage Gen2, qui offre des fonctionnalités avancées conçues pour l’analytique du Big Data. Azure Data Lake Storage Gen2 s’appuie sur le stockage d’objets blob Azure.
En savoir plus sur Compte Data Lake Store - ADLSGen1_Deprecation (Vous avez des comptes ADLS Gen1 qui doivent être migrés vers ADLS Gen2).
Activer la suppression réversible pour protéger vos données d’objets blob
Après avoir activé l’option de suppression réversible, les données supprimées passent à un état de suppression réversible plutôt qu’à un état de suppression définitive. Quand les données sont remplacées, un instantané du blob supprimé de manière réversible est généré pour enregistrer l’état des données remplacées. Vous pouvez configurer la durée pendant laquelle les données supprimées de manière réversible sont récupérables avant leur expiration définitive.
En savoir plus sur le compte de stockage : StorageSoftDelete (Activer la suppression réversible pour protéger vos données blob).
Utiliser des disques managés pour les comptes de stockage atteignant la limite de capacité
Nous avons identifié que vous utilisez des disques SSD Premium non managés sur des comptes de stockage qui sont sur le point d’atteindre la limite de capacité de stockage Premium. Pour éviter des échecs lorsque la limite est atteinte, nous recommandons d’effectuer 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.
En savoir plus sur le compte de stockage : StoragePremiumBlobQuotaLimit (Utiliser des disques managés pour les comptes de stockage atteignant la limite de capacité).
Utiliser des disques Azure avec stockage redondant interzone 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. Migrez des disques de LRS vers ZRS pour une résilience et une disponibilité plus élevées.
En savoir plus sur Modification du type de disque d’un disque managé Azure.
Utiliser la fonctionnalité Disques managés pour améliorer la fiabilité des données
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.
En savoir plus sur le groupe à haute disponibilité : ManagedDisksAvSet (Utiliser la fonctionnalité Disques managés pour améliorer la fiabilité des données).
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
En savoir plus sur Volume - ANFCRRCZRRecommendation (Implémenter des stratégies de récupération d’urgence pour vos ressources Azure NetApp Files).
Azure NetApp Files active la disponibilité continue des volumes SMB
Recommandation pour activer le volume SMB pour la disponibilité continue.
En savoir plus sur Volume - anfcaenablement (Azure NetApp Files active la disponibilité continue des volumes SMB).
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 la documentation pour vous assurer du respect par votre configuration des valeurs du délai d’expiration indiquées dans la documentation.
En savoir plus sur Volume - SAPTimeoutsANF (Passer en revue la configuration SAP pour connaître les valeurs du délai d’expiration utilisées avec Azure NetApp Files).
web
Envisager d’augmenter l’échelle votre plan App Service pour éviter l’épuisement du processeur
Votre application a atteint une utilisation de l’UC supérieure à 90 % au cours des deux derniers jours. Une utilisation élevée du processeur peut entraîner des problèmes d’exécution de vos applications. Pour résoudre ce problème, vous pouvez effectuer un scale-out de votre application.
En savoir plus sur le service d’application : AppServiceCPUExhaustion (Envisager d’effectuer un scale-out de votre plan App Service pour éviter l’épuisement de l’UC).
Corriger les paramètres de base de données de sauvegarde de votre ressource App Service
Les sauvegardes de votre application échouent systématiquement en raison d’une configuration de base de données non valide. Recherchez des détails dans l’historique des sauvegardes.
En savoir plus sur le service d’application : AppServiceFixBackupDatabaseSettings (Corriger les paramètres de base de données de sauvegarde de votre ressource App Service).
Envisager d’augmenter l’échelle votre référence SKU de plan App Service pour éviter l’épuisement de mémoire
Le plan App Service contenant votre application a atteint une allocation de mémoire supérieure à 85 %. Une consommation de mémoire élevée peut entraîner des problèmes d’exécution avec vos applications. Recherchez l’application dans le plan App Service qui épuise la mémoire et passez à un plan supérieur avec davantage de ressources de mémoire si nécessaire.
En savoir plus sur le service d’application : AppServiceMemoryExhaustion (Envisager d’effectuer un scale-up du niveau tarifaire de votre plan App Service pour éviter l’épuisement de la mémoire).
Augmentez l’échelle de votre ressource de App Service pour supprimer la limite de quota
Votre application fait partie d’un plan App Service partagé et a atteint son quota plusieurs fois. Une fois le quota atteint, votre application web ne peut pas accepter de demandes entrantes. Pour supprimer le quota, opérez une mise à niveau vers un plan Standard.
En savoir plus sur le service d’application : AppServiceRemoveQuota (Effectuer un scale-up de votre ressource App Service pour supprimer la limite de quota).
Utiliser des emplacements de déploiement pour votre ressource App Service
Vous avez déployé votre application plusieurs fois au cours de la semaine dernière. Les emplacements de déploiement vous aident à gérer les modifications et à réduire l’effet du déploiement sur votre application web de production.
En savoir plus sur le service d’application : AppServiceUseDeploymentSlots (Utiliser des emplacements de déploiement pour votre ressource App Service).
Corriger les paramètres de stockage de sauvegarde de votre ressource App Service
Les sauvegardes de votre application échouent systématiquement en raison de paramètres de stockage non valides. Pour des détails supplémentaires, voir l’historique des sauvegardes.
En savoir plus sur le service d’application : AppServiceFixBackupStorageSettings (Corriger les paramètres de stockage de sauvegarde de votre ressource App Service).
Déplacer votre ressource App Service vers la version standard ou une version supérieure et utiliser des emplacements de déploiement
Vous avez déployé votre application plusieurs fois au cours de la semaine dernière. Les emplacements de déploiement vous aident à gérer les modifications et à réduire l’effet du déploiement sur votre application web de production.
Effectuez un scale-out de votre plan App Service afin d’optimiser l’expérience utilisateur et la disponibilité
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.
En savoir plus sur le plan App Service : AppServiceNumberOfInstances (Envisager d’effectuer un scale-out de votre plan App Service afin d’optimiser l’expérience utilisateur et la disponibilité).
Le code de l’application nécessite une correction car le processus Worker a subi un incident en raison d’une exception non prise en charge
Nous avons identifié que le thread suivant qui a généré une exception non prise en charge pour votre application et le code de l’application doivent être corrigés pour éviter un effet sur la disponibilité de l’application. Un incident se produit lorsqu’une exception dans votre code met fin au processus.
Envisagez de modifier la configuration de votre App Service pour passer à 64 bits
Nous avons identifié que votre application s’exécute en 32 bits et que la mémoire atteint la limite de 2 Go. Envisagez de basculer vers des processus 64 bits pour tirer parti de la mémoire supplémentaire disponible dans votre rôle de travail web. Comme cette action déclenche un redémarrage de l’application web, vous devez la planifier en conséquence.
En savoir plus sur les limitations du service d’application 32 bits.
Mettre à niveau votre bibliothèque cliente Relais Azure Fluid
Vous avez récemment appelé le service Relais Azure Fluid avec une ancienne bibliothèque cliente. Votre bibliothèque cliente Relais Azure Fluid doit maintenant être mise à niveau vers la dernière version pour garantir que votre application reste opérationnelle. La mise à niveau fournit les fonctionnalités les plus récentes et des améliorations en matière de performances et de stabilité. Pour plus d’informations sur la version la plus récente à utiliser et sur la mise à niveau, reportez-vous à l’article suivant.
En savoir plus sur le serveur FluidRelay : UpgradeClientLibrary (Mettre à niveau votre bibliothèque de client Relais Azure Fluid).
Envisagez de mettre à niveau le plan d’hébergement des applications web statiques 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.
Étapes suivantes
En savoir plus sur la fiabilité – Microsoft Azure Well-Architected Framework