Zuverlässigkeitsempfehlungen

Der Azure Advisor hilft Ihnen, die ununterbrochene Verfügbarkeit Ihrer unternehmenskritischen Anwendungen zu gewährleisten und zu verbessern. Sie können Empfehlungen zur Zuverlässigkeit auf der Registerkarte Zuverlässigkeit im Advisor-Dashboard anzeigen.

1. Melden Sie sich am Azure-Portal an.

2. Suchen Sie auf einer beliebigen Seite nach dem Eintrag Advisor, und wählen Sie ihn aus.

3. Wählen Sie im Advisor-Dashboard die Registerkarte Zuverlässigkeit aus.

KI Services

Sie sind kurz davor, das Speicherkontingent von 2 GB zu überschreiten. Erstellen eines Standard-Suchdiensts

Sie sind kurz davor, das Speicherkontingent von 2 GB zu überschreiten. Erstellen Sie einen Standard-Suchdienst. Indizierungsvorgänge funktionieren nach dem Überschreiten des Speicherkontingents nicht mehr.

Weitere Informationen finden Sie unter Dienstgrenzwerte in Azure KI Search.

Sie sind kurz davor, das Speicherkontingent von 50 MB zu überschreiten. Erstellen eines Basic- oder Standard-Suchdiensts

Sie sind kurz davor, das Speicherkontingent von 50 MB zu überschreiten. Erstellen Sie einen Basic- oder Standard-Suchdienst. Indizierungsvorgänge funktionieren nach dem Überschreiten des Speicherkontingents nicht mehr.

Weitere Informationen finden Sie unter Dienstgrenzwerte in Azure KI Search.

Sie sind kurz davon, Ihr verfügbares Speicherkontingent zu überschreiten. Hinzufügen weiterer Partitionen, wenn Sie mehr Speicher benötigen

Sie sind kurz davon, Ihr verfügbares Speicherkontingent zu überschreiten. Fügen Sie zusätzliche Partitionen hinzu, wenn Sie mehr Speicherplatz benötigen. Nach Überschreitung des Speicherkontingents können weiterhin Abfragen durchgeführt werden. Indizierungsvorgänge sind jedoch nicht mehr möglich.

Weitere Informationen finden Sie unter Dienstgrenzwerte in Azure KI Search

Kontingent für diese Ressource überschritten

Wir haben festgestellt, dass das Kontingent für Ihre Ressource überschritten wurde. Sie können darauf warten, dass das Kontingent bald automatisch wieder aufgefüllt wird, oder Sie können es auf eine kostenpflichtige SKU upgraden, um die Blockierung aufzuheben und die Ressource jetzt wieder nutzen zu können.

Weitere Informationen finden Sie unter Cognitive Service – CognitiveServiceQuotaExceeded (Kontingent für diese Ressource überschritten).

Upgrade Ihrer Anwendung auf die Verwendung der neuesten API-Version von Azure OpenAI

Wir haben festgestellt, dass Sie über eine Azure OpenAI-Ressource verfügen, die mit einer älteren API-Version verwendet wird. Verwenden Sie die neueste REST-API-Version, um die neuesten Features und Funktionen zu nutzen.

Weitere Informationen finden Sie unter Cognitive Service – CogSvcApiVersionOpenAI (Upgrade Ihrer Anwendung auf die Verwendung der neuesten API-Version von Azure OpenAI).

Upgrade Ihrer Anwendung auf die Verwendung der neuesten API-Version von Azure OpenAI

Wir haben festgestellt, dass Sie über eine Azure OpenAI-Ressource verfügen, die mit einer älteren API-Version verwendet wird. Verwenden Sie die neueste REST-API-Version, um die neuesten Features und Funktionen zu nutzen.

Weitere Informationen finden Sie unter Cognitive Service – API-Version: OpenAI (Upgrade Ihrer Anwendung auf die Verwendung der neuesten API-Version von Azure OpenAI).

Analyse

Ihr Cluster, auf dem Ubuntu 16.04 ausgeführt wird, wird nicht unterstützt

Wir haben festgestellt, dass Ihr HDInsight-Cluster noch Ubuntu 16.04 LTS verwendet. Der Support für Azure HDInsight-Cluster unter Ubuntu 16.04 LTS wird seit 30. November 2022 eingestellt. Vorhandene Cluster werden unverändert ohne Unterstützung durch Microsoft ausgeführt. Es empfiehlt sich, Ihr Cluster mit den aktuellen Images neu zu erstellen.

Weitere Informationen finden Sie unter HDInsight-Cluster - ubuntu1604HdiClusters (Ihr Cluster mit Ubuntu 16.04 wird nicht mehr unterstützt).

Durchführen eines Upgrades für Ihr HDInsight-Cluster

Wir haben festgestellt, dass Ihr Cluster nicht das neueste Image verwendet. Wir empfehlen Kunden, die neuesten Versionen von HDInsight-Images zu verwenden, da sie die Vorteile aus Open-Source-Updates, Azure-Updates und Sicherheitsfixes bieten. Ein HDInsight-Release erfolgt alle 30 bis 60 Tage. Erwägen Sie einen Wechsel zum neuesten Release.

Weitere Informationen finden Sie unter HDInsight-Cluster – upgradeHDInsightCluster (Upgrade Ihres HDInsight-Clusters).

Ihr Cluster wurde vor einem Jahr erstellt.

Wir haben festgestellt, dass Ihr Cluster vor einem Jahr erstellt wurde. Im Rahmen der bewährten Methoden empfehlen wir Ihnen, die neuesten HDInsight-Images zu verwenden, da sie die Vorteile aus Open-Source-Updates, Azure-Updates und Sicherheitsfixes bieten. Der maximale Zeitumfang für Clusterupgrades sollte weniger als sechs Monate betragen.

Weitere Informationen finden Sie unter HDInsight-Cluster - clusterOlderThanAYear (Ihr Cluster wurde vor einem Jahr erstellt).

Ihre Kafka-Clusterdatenträger sind fast voll

Die Datenträger für Daten, die von Kafka-Brokern in Ihrem HDInsight-Cluster verwendet werden, sind fast voll. Wenn dies geschieht, kann der Apache Kafka-Broker-Prozess nicht gestartet werden und schlägt aufgrund des Fehlers "Festplatte voll" fehl. Ermitteln Sie zur Entschärfung die Aufbewahrungszeit für jedes Kafka-Thema, sichern Sie die älteren Dateien, und starten Sie die Broker neu.

Weitere Informationen finden Sie unter HDInsight-Cluster - KafkaDiskSpaceFull (Ihre Kafka-Clusterdatenträger sind fast voll).

Das Erstellen von Clustern in einem benutzerdefinierten virtuellen Netzwerk erfordert mehr Berechtigungen

Ihre Cluster im benutzerdefinierten virtuellen Netzwerk wurden ohne Berechtigung für das Beitreten zu einem virtuellen Netzwerk erstellt. Stellen Sie vor dem 30. September 2023 sicher, dass die Benutzer, die Erstellungsvorgänge ausführen, über Berechtigungen für die Aktion Microsoft.Network/virtualNetworks/subnets/join verfügen.

Weitere Informationen finden Sie unter HDInsight-Cluster – EnforceVNetJoinPermissionCheck (Erstellung von Clustern unter benutzerdefiniertem VNet erfordert mehr Berechtigungen).

Einstellung von Kafka 1.1 für Kafka-Cluster in HDInsight 4.0

Ab dem 1. Juli 2020 können Sie in HDInsight 4.0 keine neuen Kafka-Cluster mit Kafka 1.1 mehr erstellen. Vorhandene Cluster werden unverändert ohne Unterstützung durch Microsoft ausgeführt. Es empfiehlt sich, in HDInsight 4.0 bis zum 30. Juni 2020 auf Kafka 2.1 umzustellen, um potenzielle System-/Supportunterbrechungen zu vermeiden.

Weitere Informationen finden Sie unter HDInsight-Cluster: KafkaVersionRetirement (Einstellung der Unterstützung von Kafka 1.1 für Kafka-Cluster in HDInsight 4.0).

Einstellung der Unterstützung älterer Spark-Versionen in HDInsight Spark-Clustern

Ab dem 1. Juli 2020 können Sie keine neuen Spark-Cluster mit Spark 2.1 und 2.2 in HDInsight 3.6 oder mit Spark 2.3 in HDInsight 4.0 mehr erstellen. Vorhandene Cluster werden unverändert ohne Unterstützung durch Microsoft ausgeführt.

Weitere Informationen finden Sie unter HDInsight-Cluster: SparkVersionRetirement (Einstellung der Unterstützung älterer Spark-Versionen in HDInsight Spark-Clustern).

Ermöglichen der Anwendung kritischer Updates auf Ihre HDInsight-Cluster

Vom HDInsight-Dienst wird ein wichtiges zertifikatbezogenes Update auf Ihren Cluster angewendet. Mindestens eine Richtlinie Ihres Abonnements verhindert aber, dass vom HDInsight-Dienst Netzwerkressourcen erstellt oder geändert werden, die Ihren Clustern zugeordnet sind, und dass dieses Update angewendet wird. Ergreifen Sie vor dem 13. Januar 2021, 17:00 Uhr UTC entsprechende Maßnahmen, damit der HDInsight-Dienst Netzwerkressourcen, wie Lastenausgleich, Netzwerkschnittstelle und öffentliche IP-Adresse, die Ihren Clustern zugeordnet sind, erstellen oder ändern kann. Das HDInsight-Team führt zwischen dem 13. Januar 2021 (17 Uhr UTC) und dem 16. Januar 2021 (17 Uhr UTC) Updates durch. Wenn dieses Update nicht angewendet wird, kann dies dazu führen, dass Ihre Cluster fehlerhaft und nicht mehr verwendbar sind.

Weitere Informationen finden Sie unter HDInsight-Cluster: GCSCertRotation (Ermöglichen der Anwendung kritischer Updates auf Ihre HDInsight-Cluster).

Löschen und Neuerstellen Ihrer HDInsight-Cluster zum Anwenden von kritischen Updates

Der HDInsight-Dienst hat versucht, ein kritisches Zertifikatupdate auf Ihre gesamten ausgeführten Cluster anzuwenden. Aufgrund einiger benutzerdefinierten Konfigurationsänderungen war das Anwenden der Zertifikatupdates für einige Ihrer Cluster aber nicht möglich.

Weitere Informationen finden Sie unter HDInsight-Cluster: GCSCertRotationRound2 (Löschen und Neuerstellen Ihrer HDInsight-Cluster zum Anwenden von kritischen Updates).

Löschen und Neuerstellen Ihrer HDInsight-Cluster zum Anwenden von kritischen Updates

Der HDInsight-Dienst hat versucht, ein kritisches Zertifikatupdate auf Ihre gesamten ausgeführten Cluster anzuwenden. Aufgrund einiger benutzerdefinierten Konfigurationsänderungen war das Anwenden der Zertifikatupdates für einige Ihrer Cluster aber nicht möglich. Löschen und erstellen Sie Ihren Cluster vor dem 25. Januar 2021 neu, um zu verhindern, dass der Cluster fehlerhaft und unbrauchbar wird.

Weitere Informationen finden Sie unter HDInsight-Cluster: GCSCertRotationR3DropRecreate (Löschen und Neuerstellen Ihrer HDInsight-Cluster zum Anwenden von kritischen Updates).

Anwenden von kritischen Updates auf Ihre HDInsight-Cluster

Der HDInsight-Dienst hat versucht, ein kritisches Zertifikatupdate auf Ihre gesamten ausgeführten Cluster anzuwenden. Mindestens eine Richtlinie Ihres Abonnements verhindert aber, dass vom HDInsight-Dienst Netzwerkressourcen erstellt oder geändert werden, die Ihren Clustern zugeordnet sind, und dass das Update angewendet wird. Entfernen oder aktualisieren Sie Ihre Richtlinienzuweisung, damit der HDInsight-Dienst Netzwerkressourcen, die Ihren Clustern zugeordnet sind, erstellen oder ändern kann. Ändern Sie die Richtlinienzuweisung vor dem 21. Januar 2021, 17:00 Uhr UTC, weil das HDInsight-Team zwischen dem 21. Januar 2021, 17:00 Uhr UTC und dem 23. Januar 2021, 17:00 Uhr UTC Updates durchführt. Um die Richtlinienaktualisierung zu überprüfen, können Sie versuchen, Netzwerkressourcen in derselben Ressourcengruppe und im Subnetz zu erstellen, in dem sich Ihr Cluster befindet. Wenn dieses Update nicht angewendet wird, kann dies dazu führen, dass Ihre Cluster fehlerhaft und nicht mehr verwendbar sind. Sie können Ihren Cluster auch vor dem 25. Januar 2021 löschen und neu erstellen, um zu verhindern, dass der Cluster fehlerhaft und unbrauchbar wird. Vom HDInsight-Dienst wird eine weitere Benachrichtigung gesendet, falls das Update nicht auf Ihre Cluster angewendet werden konnte.

Weitere Informationen finden Sie unter HDInsight-Cluster: GCSCertRotationR3PlanPatch (Anwenden von kritischen Updates auf Ihre HDInsight-Cluster).

Aktion erforderlich: Migrieren Sie Ihren HDInsight-Cluster vom Typ A8 - A11 vor dem 1. März 2021

Sie erhalten diesen Hinweis, weil Sie über einen oder mehrere aktive HDInsight-Cluster vom Typ A8, A9, A10 oder A11 verfügen. Die virtuellen Computer (VMs) vom Typ A8 – A11 werden in allen Regionen am 1. März 2021 eingestellt. Nach diesem Datum wird die Zuordnung für alle Cluster mit den Typen A8 – A11 aufgehoben. Migrieren Sie Ihre betroffenen Cluster vor diesem Datum zu einer anderen von HDInsight unterstützten VM (https://azure.microsoft.com/pricing/details/hdinsight/). Weitere Details finden Sie unter dem Link „Weitere Informationen“, oder kontaktieren Sie uns unter askhdinsight@microsoft.com

Weitere Informationen finden Sie unter HDInsight-Cluster: VMDeprecation (Aktion erforderlich: Migrieren Sie Ihren HDInsight-Cluster des Typs A8–A11 vor dem 1. März 2021).

Compute

Cloud Services (klassisch) wird eingestellt. Migrieren vor dem 31. August 2024

Cloud Services (klassisch) wird eingestellt. Migrieren Sie vor dem 31. August 2024, um den Verlust von Daten oder der Geschäftskontinuität zu vermeiden.

Weitere Informationen finden Sie unter Ressource – Cloud Services-Einstellung (Cloud Services (klassisch) wird eingestellt. Migration Sie vor dem 31. August 2024).

Die an Ihre Premium-fähige VM angefügten Standard-Datenträger auf Premium-Datenträger aktualisieren

Wir haben ermittelt, dass Sie Standard-Datenträger bei Ihren premiumfähigen Virtual Machines verwenden und wir empfehlen Ihnen, ein Upgrade der Standard-Datenträger auf Premium-Datenträger zu erwägen. Wir garantieren für jeden virtuellen Einzelinstanzcomputer, bei dem Premium-Speicher für alle Betriebssystemdatenträger und regulären Datenträger verwendet wird, eine Konnektivität von mindestens 99,9 %. Berücksichtigen Sie bei Ihrer Upgrade-Entscheidung die folgenden Faktoren. Erstens: Für ein Upgrade ist ein Neustart der VM erforderlich. Dieser Vorgang dauert drei bis fünf Minuten. Zweitens: Wenn es sich bei den VMs in der Liste um unternehmenskritische VMs für die Produktion handelt, sollten Sie die verbesserte Verfügbarkeit gegen die Kosten für Premium-Datenträger abwägen.

Weitere Informationen finden Sie unter VM: MigrateStandardStorageAccountToPremium (Die an Ihre Premium-fähige VM angefügten Standard-Datenträger auf Premium-Datenträger aktualisieren).

Aktivieren der Replikation von virtuellen Computern zum Schützen Ihrer Anwendungen vor regionalen Ausfällen

Virtuelle Computer, für die die Replikation in eine andere Region nicht aktiviert ist, sind gegenüber regionalen Ausfällen nicht resilient. Durch eine Replikation der Computer werden negative Auswirkungen auf das Geschäft während des Ausfalls einer Azure-Region drastisch reduziert. Wir empfehlen Ihnen dringend, die Replikation aller unternehmenskritischen virtuellen Computer aus der folgenden Liste zu aktivieren, damit Sie Ihre Computer bei einem Ausfall in der Azure-Remoteregion schnell wieder bereitstellen können. Weitere Informationen finden Sie unter VM: ASRUnprotectedVMs (Aktivieren der Replikation von VMs zum Schützen Ihrer Anwendungen vor regionalen Ausfällen).

Upgrade einer VM von nicht verwalteten Premium-Datenträgern auf verwaltete Datenträger ohne zusätzliche Kosten

Wir haben ermittelt, dass für Ihre VM nicht verwaltete Premium-Datenträger genutzt werden, die ohne zusätzliche Kosten zu verwalteten Datenträgern migriert werden können. Azure Managed Disks bietet eine höhere Resilienz, eine vereinfachte Dienstverwaltung, ein höheres Skalierungsziel und eine größere Auswahl von Datenträgertypen. Sie können dieses Upgrade in weniger als fünf Minuten über das Portal durchführen.

Weitere Informationen finden Sie unter VM: UpgradeVMToManagedDisksWithoutAdditionalCost (Upgrade einer VM von nicht verwalteten Premium-Datenträgern auf verwaltete Datenträger ohne zusätzliche Kosten).

Aktualisieren Ihres Protokolls für ausgehende Konnektivität auf Diensttags für Azure Site Recovery

Die Verwendung der auf IP-Adressen basierenden Filterung wurde als potenziell gefährliche Methode zum Steuern der ausgehenden Konnektivität für Firewalls identifiziert. Wir empfehlen die Verwendung von Diensttags als Alternative zur Steuerung der Konnektivität. Wir empfehlen Ihnen dringend, Diensttags zu verwenden, um die Konnektivität mit Azure Site Recovery-Diensten für die Computer zu ermöglichen.

Weitere Informationen finden Sie unter VM: ASRUpdateOutboundConnectivityProtocolToServiceTags (Aktualisieren Ihres Protokolls für ausgehende Konnektivität auf Diensttags für Azure Site Recovery).

Aktualisieren Ihrer Firewallkonfigurationen, um neue RHUI 4-IP-Adressen zuzulassen

Ihre Virtual Machine Scale Sets werden ab dem 12. Oktober 2023 Paketinhalte von RHUI4-Servern erhalten. Wenn Sie RHUI 3-IP-Adressen [https://aka.ms/rhui-server-list] über Firewall und Proxy zulassen, erlauben Sie den neuen RHUI 4-IP-Adressen [https://aka.ms/rhui-server-list], weiterhin RHEL-Paketupdates zu erhalten.

Weitere Informationen finden Sie unter VM – Rhui3ToRhui4MigrationV2 (Aktualisieren Ihrer Firewallkonfigurationen, um neue RHUI 4-IP-Adressen zuzulassen).

Virtuelle Computer in Ihrem Abonnement basieren auf Images, deren Unterstützung eingestellt wird

Virtuelle Computer in Ihrem Abonnement basieren auf Images, deren Unterstützung eingestellt wird. Nachdem das Image veraltet ist, können keine neuen VMs mehr aus dem veralteten Image erstellt werden. Upgraden Sie auf eine neuere Version des Images, um Störungen bei Ihren Workloads zu vermeiden.

Weitere Informationen finden Sie unter VM – VMRunningDeprecatedOfferLevelImage (Virtual Machines in Ihrem Abonnement laufen auf Images, deren Unterstützung eingestellt wird).

Virtuelle Computer in Ihrem Abonnement basieren auf Images, deren Unterstützung eingestellt wird

Virtuelle Computer in Ihrem Abonnement basieren auf Images, deren Unterstützung eingestellt wird. Nachdem das Image veraltet ist, können keine neuen VMs mehr aus dem veralteten Image erstellt werden. Upgraden Sie auf eine neuere SKU des Images, um Störungen bei Ihren Workloads vorzubeugen.

Weitere Informationen finden Sie unter VM – VMRunningDeprecatedPlanLevelImage (Virtual Machines in Ihrem Abonnement laufen auf Images, deren Unterstützung eingestellt wird).

Virtuelle Computer in Ihrem Abonnement basieren auf Images, deren Unterstützung eingestellt wird

Virtuelle Computer in Ihrem Abonnement basieren auf Images, deren Unterstützung eingestellt wird. Nachdem das Image veraltet ist, können keine neuen VMs mehr aus dem veralteten Image erstellt werden. Upgraden Sie auf eine neuere Version des Images, um Störungen bei Ihren Workloads vorzubeugen.

Weitere Informationen finden Sie unter VM – VMRunningDeprecatedImage (Virtual Machines in Ihrem Abonnement laufen auf Images, deren Unterstützung eingestellt wird).

Verwenden von Verfügbarkeitszonen für bessere Resilienz und Verfügbarkeit

Verfügbarkeitszonen (VZ) in Azure tragen dazu bei, Ihre Anwendungen und Daten vor Rechenzentrumsausfällen zu schützen. Jede VZ besteht aus mindestens einem Rechenzentrum mit unabhängiger Stromversorgung, Kühlung und Netztechnologie. Durch das Entwerfen von Lösungen für die Verwendung zonaler VMs können Sie Ihre VMs vor einem Ausfall in anderen Zonen isolieren.

Weitere Informationen finden Sie unter VM – AvailabilityZoneVM (Verwenden von Verfügbarkeitszonen für bessere Resilienz und Verfügbarkeit).

Verwenden von Managed Disks zur Erhöhung der Datenzuverlässigkeit

VMs in einer Verfügbarkeitsgruppe mit Datenträgern, die entweder Speicherkonten oder Speicherskalierungseinheiten gemeinsam nutzen, sind nicht resilient gegen Fehler einzelner Speicherskalierungseinheiten während Ausfällen. Stellen Sie mit einer Migration zu Azure Managed Disks sicher, dass die Datenträger verschiedener virtueller Computer in der Verfügbarkeitsgruppe ausreichend isoliert sind, um einen Single Point of Failure zu vermeiden.

Weitere Informationen finden Sie unter Verfügbarkeitsgruppe: ManagedDisksAvSet (Verwenden von Managed Disks zur Erhöhung der Datenzuverlässigkeit).

Kein Zugriff auf obligatorische URLs für Ihre Azure Virtual Desktop-Umgebung vorhanden

Damit ein Sitzungshost die Bereitstellung und Registrierung in Azure Virtual Desktop richtig durchführen kann, müssen Sie der Zulassungsliste eine Gruppe mit URLs hinzufügen, falls Ihre VM in einer eingeschränkten Umgebung ausgeführt wird. Nach dem Klicken auf den Link „Weitere Informationen“ wird die Liste mit den URLs angezeigt, für die Sie die Blockierung mindestens aufheben müssen, damit die Bereitstellung erfolgreich ist und der Sitzungshost funktioniert. Für bestimmte URLs, die in der Zulassungsliste fehlen, können Sie auch in Ihrem Protokoll mit den Anwendungsereignissen nach Ereignis 3702 suchen.

Weitere Informationen finden Sie unter VM: SessionHostNeedsAssistanceForUrlCheck (Kein Zugriff auf obligatorische URLs für Ihre Azure Virtual Desktop-Umgebung vorhanden).

Aktualisieren Ihrer Firewallkonfigurationen, um neue RHUI 4-IP-Adressen zuzulassen

Ihre Virtual Machine Scale Sets werden ab dem 12. Oktober 2023 Paketinhalte von RHUI4-Servern erhalten. Wenn Sie RHUI 3-IP-Adressen [https://aka.ms/rhui-server-list] über Firewall und Proxy zulassen, erlauben Sie den neuen RHUI 4-IP-Adressen [https://aka.ms/rhui-server-list], weiterhin RHEL-Paketupdates zu erhalten.

Weitere Informationen finden Sie unter VM-Skalierungsgruppe – Rhui3ToRhui4MigrationVMSS (Aktualisieren Ihrer Firewallkonfigurationen, um neue RHUI 4-IP-Adressen zuzulassen).

Virtual Machine Scale Sets in Ihrem Abonnement laufen auf Images, die für die Veralterung geplant wurden

Virtual Machine Scale Sets in Ihrem Abonnement laufen auf Images, die für die Veralterung geplant wurden. Sobald das Image veraltet ist, würde ihre VM Scale Sets-Workloads nicht mehr skalieren. Upgraden Sie auf eine neuere Version des Images, um Störungen bei Ihren Workloads zu vermeiden.

Weitere Informationen finden Sie unter VM-Skalierungsgruppe – VMScaleSetRunningDeprecatedOfferImage (Virtual Machine Scale Sets in Ihrem Abonnement laufen auf Images, die für die Veralterung geplant wurden).

Virtual Machine Scale Sets in Ihrem Abonnement laufen auf Images, die für die Veralterung geplant wurden

Virtual Machine Scale Sets in Ihrem Abonnement laufen auf Images, die für die Veralterung geplant wurden. Nachdem das Image veraltet ist, werden Ihre VMSS-Workloads nicht mehr aufskaliert. Upgraden Sie auf eine neuere Version des Images, um Störungen bei Ihrer Workload vorzubeugen.

Weitere Informationen finden Sie unter VM-Skalierungsgruppe – VMScaleSetRunningDeprecatedImage (Virtual Machine Scale Sets in Ihrem Abonnement laufen auf Images, die für die Veralterung geplant wurden).

Virtual Machine Scale Sets in Ihrem Abonnement laufen auf Images, die für die Veralterung geplant wurden

Virtual Machine Scale Sets in Ihrem Abonnement laufen auf Images, die für die Veralterung geplant wurden. Sobald das Image veraltet ist, würde ihre VM Scale Sets-Workloads nicht mehr skalieren. Upgraden Sie auf eine neueres Abonnement des Images, um Störungen bei Ihren Workloads zu vermeiden.

Weitere Informationen finden Sie unterVM-Skalierungsgruppe – VMScaleSetRunningDeprecatedPlanImage (Virtual Machine Scale Sets in Ihrem Abonnement laufen auf Images, die für die Veralterung geplant wurden).

Container

Erhöhen der minimalen Replikatanzahl für Ihre Container-App

Wir haben festgestellt, dass die minimale Replikatanzahl für Ihre Container-App möglicherweise niedriger als optimal ist. Erwägen Sie, die minimale Replikatanzahl zu erhöhen, um eine bessere Verfügbarkeit zu erzielen.

Weitere Informationen finden Sie unter Microsoft-App Container-App – ContainerAppMinimalReplicaCountTooLow (Erhöhen der minimalen Replikatanzahl für Ihre Container-App).

Verlängern des benutzerdefinierten Domänenzertifikats

Wir haben festgestellt, dass das von Ihnen hochgeladene benutzerdefinierte Domänenzertifikat bald abläuft. Verlängern Sie Ihr Zertifikat, und laden Sie das neue Zertifikat für Ihre Container-Apps hoch.

Weitere Informationen finden Sie unter Microsoft-App Container-App – ContainerAppCustomDomainCertificateNearExpiration (Verlängern des benutzerdefinierten Domänenzertifikats).

Es wurde ein potenzielles Netzwerkproblem bei Ihrer Container Apps-Umgebung identifiziert, das deren Neuerstellung erfordert, um DNS-Probleme zu vermeiden.

Für Ihre Container Apps-Umgebungen wurde ein potenzielles Netzwerkproblem erkannt. Um dieses potenzielle Netzwerkproblem zu verhindern, erstellen Sie eine neue Container Apps-Umgebung, erstellen Sie Ihre Container Apps in der neuen Umgebung erneut und löschen Sie die alte Container Apps-Umgebung.

Weitere Informationen finden Sie unter Verwaltete Umgebung – CreateNewContainerAppsEnvironment (Ein potenzielles Netzwerkproblem wurde mit Ihrer Container Apps-Umgebung identifiziert, das eine Neuerstellung erfordert, um DNS-Probleme zu vermeiden).

Domänenüberprüfung erforderlich, um Ihr App Service Certificate zu verlängern

Sie verfügen über ein App Service Certificate, das sich derzeit im Status „Ausstehende Ausstellung“ befindet und eine Domänenüberprüfung erfordert. Fehler beim Überprüfen des Domäneneigentums führen zu einer nicht erfolgreichen Zertifikatausstellung. Die Domänenüberprüfung ist für das App Service Certificates nicht automatisiert und erfordert Ihr Handeln.

Weitere Informationen finden Sie unter App Service Certificate – ASCDomainVerificationRequired (Domänenüberprüfung erforderlich, um Ihr App Service Certificate zu verlängern).

Cluster mit Knotenpools, welche die nicht empfohlene B-Serie verwenden

Das Cluster enthält einen oder mehrere Knotenpools, die eine nicht empfohlene burstfähige VM-SKU verwenden. Bei burstfähigen VMs ist die zu 100 % vollständige vCPU-Kapazität nicht garantiert. Stellen Sie sicher, dass VMs der B-Serie nicht in einer Produktionsumgebung verwendet werden.

Weitere Informationen finden Sie unter Kubernetes-Dienst – ClustersUsingBSeriesVMs (Cluster mit Knotenpools, welche die nicht empfohlene B-Serie verwenden).

Upgrade auf den Tarif „Standard“ für unternehmenskritische und Produktionscluster

Dieses Cluster hat mehr als 10 Knoten und ist nicht für den Standardtarif aktiviert. Die Kubernetes-Steuerungsebene im kostenlosen Tarif bietet begrenzte Ressourcen und ist nicht für den Produktionseinsatz oder die Verwendung mit 10 oder mehr Knoten vorgesehen.

Weitere Informationen finden Sie unter Kubernetes-Dienst – UseStandardpricingtier (Upgrade auf den Standard-Tarif für unternehmenskritische Cluster und Produktionscluster).

Budgets für die Unterbrechung von Pods empfohlen

Es werden Budgets für die Unterbrechung von Pods empfohlen. Verbessern der Hochverfügbarkeit von Diensten

Weitere Informationen finden Sie unter Kubernetes Service: PodDisruptionBudgetsRecommended (Budgets für die Unterbrechung von Pods empfohlen).

Upgraden auf die neueste Agent-Version von Kubernetes mit Azure Arc-Unterstützung

Führen Sie ein Upgrade auf die neueste Agent-Version durch, um Kubernetes mit Azure Arc-Unterstützung optimal nutzen zu können und von verbesserter Stabilität und neuen Funktionalität zu profitieren.

Weitere Informationen finden Sie unter Kubernetes – Azure Arc: Upgrade auf die K8s-Agent-Version mit Azure Arc-Unterstützung (Upgraden auf die neueste Agent-Version von Kubernetes mit Azure Arc-Unterstützung).

Datenbanken

Replikation: Fügen Sie einen Primärschlüssel zu einer Tabelle hinzu, die derzeit keinen hat.

Aufgrund unserer internen Überwachung haben wir eine erhebliche Verzögerung bei der Replikation auf Ihrem Replikatserver festgestellt. Diese Verzögerung tritt auf, da der Replikatserver Relayprotokolle für eine Tabelle ohne Primärschlüssel wiedergibt. Um sicherzustellen, dass das Replikat mit dem Primären und mit Änderungen synchronisiert werden kann, fügen Sie den Tabellen auf dem primären Server Primärschlüssel hinzu. Nachdem die Primärschlüssel hinzugefügt wurden, erstellen Sie den Replikatserver neu.

Weitere Informationen finden Sie unter Azure Database for MySQL flexibler Server – MySqlFlexibleServerReplicaMissingPKfb41 (Replikation – Hinzufügen eines Primärschlüssels zur Tabelle, die derzeit keinen hat).

Hochverfügbarkeit: Fügen Sie einen Primärschlüssel zu einer Tabelle hinzu, die derzeit keinen hat.

Unser internes Überwachungssystem hat eine erhebliche Verzögerung bei der Replikation auf dem Hochverfügbarkeits-Standbyserver festgestellt. Der Standbyserver, auf dem Relayprotokolle in einer Tabelle wiedergegeben werden, die keinen Primärschlüssel enthält, ist die Hauptursache der Verzögerung. Um dieses Problem zu beheben und die bewährten Methoden einzuhalten, wird empfohlen, dass Sie allen Tabellen Primärschlüssel hinzuzufügen. Nachdem Sie die Primärschlüssel hinzugefügt haben, fahren Sie mit der Deaktivierung fort, und aktivieren Sie dann die hohe Verfügbarkeit erneut, um das Problem zu beheben.

Weitere Informationen finden Sie unter Azure Database for MySQL flexibler Server – MySqlFlexibleServerHAMissingPKcf38 (Hochverfügbarkeit – Hinzufügen eines Primärschlüssels zur Tabelle, die derzeit keinen hat).

Die Verfügbarkeit kann durch eine hohe Speicherfragmentierung beeinträchtigt werden. Erhöhen der Speicherreservierung für die Fragmentierung zum Vermeiden möglicher Auswirkungen

Fragmentierung und hohe Arbeitsspeicherauslastung können bei Failover- oder Verwaltungsvorgängen zu Verfügbarkeitsproblemen führen. Durch Erhöhen der Speicherreservierung für die Fragmentierung lassen sich Cachefehler bei hoher Arbeitsspeicherauslastung verringern. Der Arbeitsspeicher für die Fragmentierung kann im Bereich mit den erweiterten Einstellungen über die Einstellung „maxfragmentationmemory-reserved“ erhöht werden.

Weitere Informationen zu Redis Cache Server – RedisCacheMemoryFragmentation (Verfügbarkeit kann durch eine hohe Speicherfragmentierung beeinträchtigt werden. Erhöhen Sie die Speicherreservierung für die Fragmentierung, um mögliche Auswirkungen zu vermeiden.)

Aktivieren von Azure Backup für SQL auf Ihren virtuellen Computern

Aktivieren von Sicherungen für SQL-Datenbanken auf Ihren virtuellen Computern mithilfe von Azure Backup und Nutzen der Vorteile der Sicherung ohne Infrastruktur, der Zeitpunktwiederherstellung (Point-in-Time) und der zentralen Verwaltung mit SQL AG-Integration.

Weitere Informationen finden Sie unter virtueller SQL-Computer – EnableAzBackupForSQL (Aktivieren der Azure-Sicherung für SQL auf Ihren virtuellen Computern).

Verbessern der PostgreSQL-Verfügbarkeit durch das Entfernen von inaktiven logischen Replikationsslots

Unser interne System zeigt, dass Ihr PostgreSQL-Server ggf. über inaktive logische Replikationsslots verfügt. IN DIESEM ZUAMMENHANG SIND SOFORTIGE MASSNAHMEN ERFORDERLICH. Inaktive Protokollreplikation kann aufgrund der WAL-Dateiaufbewahrung und Ansammlung von Momentaufnahmedateien zu einer Verschlechterung der Serverleistung und zu Nichtverfügbarkeit führen. Um die Leistung und Verfügbarkeit zu verbessern, empfehlen wir DRINGEND, SOFORT Maßnahmen zu ergreifen. Löschen Sie entweder die inaktiven Replikationsplätze, oder beginnen Sie mit der Nutzung der Änderungen aus diesen Slots, damit die Log Sequence Number (LSN) der Slots voranschreitet und sich in der Nähe des aktuellen LSN des Servers befindet.

Weitere Informationen finden Sie unter PostgreSQL-Server: OrcasPostgreSqlLogicalReplicationSlots (Verbessern der PostgreSQL-Verfügbarkeit durch das Entfernen von inaktiven logischen Replikationsslots).

Verbessern der PostgreSQL-Verfügbarkeit durch das Entfernen von inaktiven logischen Replikationsslots

Unser interne System zeigt, dass Ihr flexibler PostgreSQL-Server ggf. über inaktive logische Replikationsslots verfügt. IN DIESEM ZUAMMENHANG SIND SOFORTIGE MASSNAHMEN ERFORDERLICH. Inaktive Protokollreplikationsslots können aufgrund der WAL-Dateiaufbewahrung und Ansammlung von Momentaufnahmedateien zu einer Verschlechterung der Serverleistung und zu Nichtverfügbarkeit führen. Um die Leistung und Verfügbarkeit zu verbessern, empfehlen wir DRINGEND, SOFORT Maßnahmen zu ergreifen. Löschen Sie entweder die inaktiven Replikationsplätze, oder beginnen Sie mit der Nutzung der Änderungen aus diesen Slots, damit die Log Sequence Number (LSN) der Slots voranschreitet und sich in der Nähe des aktuellen LSN des Servers befindet.

Weitere Informationen finden Sie unter Flexibler Azure Database for PostgreSQL-Server: OrcasPostgreSqlFlexibleServerLogicalReplicationSlots (Verbessern der PostgreSQL-Verfügbarkeit durch das Entfernen von inaktiven logischen Replikationsslots).

Konfigurieren eines konsistenten Indizierungsmodus für Ihren Azure Cosmos DB-Container

Wir haben festgestellt, dass Ihr Azure Cosmos DB-Container mit dem verzögerten Indizierungsmodus konfiguriert ist. Dadurch wird die Aktualität der Abfrageergebnisse möglicherweise beeinträchtigt. Es wird empfohlen, zum konsistenten Modus zu wechseln.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBLazyIndexing (Konfigurieren eines konsistenten Indizierungsmodus für Ihren Azure Cosmos DB-Container).

Aktualisieren Ihres alten Azure Cosmos DB SDK auf die neueste Version

Ihr Azure Cosmos DB-Konto verwendet eine ältere Version des SDK. Es wird empfohlen, dass Sie ein Upgrade auf die neueste Version durchzuführen, um aktuelle Fixes, Leistungsverbesserungen und neue Funktionen zu erhalten.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBUpgradeOldSDK (Aktualisieren Ihres alten Azure Cosmos DB SDK auf die neueste Version).

Aktualisieren Ihres veralteten Azure Cosmos DB SDK auf die neueste Version

Für Ihr Azure Cosmos DB-Konto wird eine veraltete Version des SDK verwendet. Es wird empfohlen, dass Sie ein Upgrade auf die neueste Version durchzuführen, um aktuelle Fixes, Leistungsverbesserungen und neue Funktionen zu erhalten.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBUpgradeOutdatedSDK (Aktualisieren Ihres veralteten Azure Cosmos DB SDK auf die neueste Version).

Konfigurieren Ihres Azure Cosmos DB-Containers mit einem Partitionsschlüssel

Ihre nicht partitionierten Azure Cosmos DB-Sammlungen haben ihr bereitgestelltes Speicherkontingent nahezu erschöpft. Migrieren Sie diese Sammlungen zu neuen Sammlungen mit einer Partitionsschlüsseldefinition, um das automatische Skalieren durch den Dienst zu ermöglichen.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBFixedCollections (Konfigurieren Ihres Azure Cosmos DB-Containers mit einem Partitionsschlüssel).

Aktualisieren Ihres Azure Cosmos DB for MongoDB-Kontos auf die Version 4.0, um Abfrage-/Speicherkosten zu sparen und neue Features zu nutzen

Ihr Azure Cosmos DB for MongoDB-Konto kann auf die Version 4.0 aktualisiert werden. Dank eines neuen Speicherformats können Sie durch das Upgrade auf die Version 4.0 Ihre Speicherkosten um bis zu 55 Prozent und Ihre Abfragekosten um bis zu 45 Prozent senken. Die Version 4.0 enthält zudem zahlreiche andere Features wie etwa Transaktionen mit mehreren Dokumenten.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBMongoSelfServeUpgrade (Aktualisieren Ihres Azure Cosmos DB for MongoDB-Kontos auf die Version 4.0, um Abfrage-/Speicherkosten zu sparen und neue Features zu nutzen).

Hinzufügen einer zweiten Region zu Ihren Produktionsworkloads in Azure Cosmos DB

Wir haben basierend auf ihren Namen und Konfigurationen festgestellt, dass die aufgeführten Azure Cosmos DB-Konten möglicherweise für Produktions-Workloads verwendet werden. Diese Konten werden zurzeit in einer einzelnen Azure-Region ausgeführt. Sie können ihre Verfügbarkeit erhöhen, indem Sie sie so konfigurieren, dass sie mindestens zwei Azure-Regionen umfassen.

Hinweis

Für zusätzliche Regionen entstehen zusätzliche Kosten.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBSingleRegionProdAccounts (Hinzufügen einer zweiten Region zu Ihren Produktionsworkloads in Azure Cosmos DB).

Aktivieren der serverseitigen Wiederholung für das Azure Cosmos DB for MongoDB-Konto

Wir haben festgestellt, dass Ihr Konto den Fehler TooManyRequests mit dem Code 16500 auslöst. Wenn Sie die serverseitige Wiederholung aktivieren, können Sie dieses Problem beheben.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBMongoServerSideRetries (Aktivieren der serverseitigen Wiederholung für das Azure Cosmos DB for MongoDB-Konto).

Migrieren Ihres Azure Cosmos DB for MongoDB-Kontos zu Version 4.0, um Abfrage-/Speicherkosten zu sparen und neue Features zu nutzen

Migrieren Sie Ihr Datenbankkonto zu einem neuen Datenbankkonto, um von den Vorteilen von Azure Cosmos DB for MongoDB v4.0 zu profitieren. Dank eines neuen Speicherformats können Sie durch das Upgrade auf die Version 4.0 Ihre Speicherkosten um bis zu 55 Prozent und Ihre Abfragekosten um bis zu 45 Prozent senken. Die Version 4.0 enthält zudem zahlreiche andere Features wie etwa Transaktionen mit mehreren Dokumenten. Bei einem Upgrade müssen Sie auch die Daten in Ihrem vorhandenen Konto zu einem neuen Konto migrieren, das mit Version 4.0 erstellt wurde. Azure Data Factory oder Studio 3T können Sie bei der Migration Ihrer Daten unterstützen.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBMongoMigrationUpgrade (Migrieren Ihres Azure Cosmos DB for MongoDB-Kontos zu Version 4.0, um Abfrage-/Speicherkosten zu sparen und neue Features zu nutzen).

Von Ihrem Azure Cosmos DB-Konto kann nicht auf die verknüpfte Azure Key Vault-Instanz zugegriffen werden, in der Ihr Verschlüsselungsschlüssel gehostet wird.

Anscheinend verhindert die Konfiguration Ihres Schlüsseltresors, dass von Ihrem Azure Cosmos DB-Konto eine Verbindung mit dem Schlüsseltresor hergestellt wird, um den Zugriff auf Ihre verwalteten Verschlüsselungsschlüssel zu ermöglichen. Wenn Sie vor Kurzem eine Schlüsselrotation vorgenommen haben, sollten Sie sicherstellen, dass der vorherige Schlüssel bzw. die Schlüsselversion aktiviert bleibt und so lange verfügbar ist, bis Azure Cosmos DB die Rotation abgeschlossen hat. Der vorherige Schlüssel oder die vorherige Schlüsselversion kann nach 24 Stunden oder dann deaktiviert werden, wenn in den Azure Key Vault-Überwachungsprotokollen keine Aktivitäten mehr von Azure Cosmos DB für diesen Schlüssel oder diese Schlüsselversion angezeigt werden.

Weitere Informationen finden Sie unter Cosmos DB-Konto: CosmosDBKeyVaultWrap (Von Ihrem Cosmos DB-Konto kann nicht auf die verknüpfte Azure Key Vault-Instanz zugegriffen werden, in der Ihr Verschlüsselungsschlüssel gehostet wird.).

Vermeiden eines Ratenlimits bei Metadatenvorgängen

Wir haben eine hohe Anzahl von Metadatenvorgängen in Ihrem Konto festgestellt. Ihre Daten in Azure Cosmos DB, einschließlich der Metadaten zu Ihren Datenbanken und Sammlungen, werden auf verschiedene Partitionen verteilt. Für Metadatenvorgänge gilt ein Limit in Bezug auf vom System reservierte Anforderungseinheiten (Request Units, RUs). Eine hohe Anzahl von Metadatenvorgängen kann zu einer Einschränkung der Rate führen. Vermeiden Sie das Einschränken des Tempos, indem Sie statische Azure Cosmos DB-Clientinstanzen in Ihrem Code verwenden und die Namen von Datenbanken und Sammlungen zwischenspeichern.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBHighMetadataOperations (Vermeiden eines Ratenlimits bei Metadatenvorgängen).

Verwenden Sie den neuen 3.6+-Endpunkt, um eine Verbindung mit dem aktualisierten Azure Cosmos DB for MongoDB-Konto herzustellen.

Wir haben festgestellt, dass einige Ihrer Anwendungen über den Legacyendpunkt 3.2 [accountname].documents.azure.com eine Verbindung mit dem aktualisierten Azure Cosmos DB for MongoDB-Konto herstellen. Verwenden Sie den neuen Endpunkt [accountname].mongo.cosmos.azure.com (oder dessen Entsprechung in Sovereign Clouds, Clouds für Behörden oder eingeschränkten Clouds).

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBMongoNudge36AwayFrom32 (Verwenden Sie den neuen 3.6+-Endpunkt, um eine Verbindung mit dem aktualisierten Azure Cosmos DB for MongoDB-Konto herzustellen).

Führen Sie ein Upgrade auf Version 2.6.14 des Async Java SDK v2 durch, um ein kritisches Problem zu vermeiden, oder auf Java SDK v4, da Async Java SDK v2 als veraltet eingestuft wird.

Bis Version 2.6.13 des Azure Cosmos DB Async Java SDK v2 ist ein kritischer Fehler enthalten, der zu Problemen führt, wenn eine globale logische Sequenznummer (LSN) erreicht wird, die den Wert für das maximal zulässige Integer überschreitet. Diese Dienstfehler treten auf, nachdem eine große Anzahl von Transaktionen während der Lebensdauer eines Azure Cosmos DB-Containers aufgetreten ist. Hinweis: Dies ist ein kritischer Hotfix für das Async Java-SDK v2. Wir empfehlen Ihnen aber trotzdem dringend die Migration zum Java-SDK v4 durchzuführen.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBMaxGlobalLSNReachedV2 (Führen Sie ein Upgrade auf Version 2.6.14 des Async Java SDK v2 durch, um ein kritisches Problem zu vermeiden, oder auf Java SDK v4, da Async Java SDK v2 als veraltet eingestuft wird).

Upgraden auf die aktuelle empfohlene Version des Java SDK v4 zur Vermeidung eines kritischen Problems

Bis Version 4.15 des Azure Cosmos DB Java SDK v4 und früher ist ein kritischer Fehler enthalten, der zu Problemen führt, wenn eine globale logische Sequenznummer (LSN) erreicht wird, die den Wert für das maximal zulässige Integer überschreitet. Diese Dienstfehler treten auf, nachdem eine große Anzahl von Transaktionen während der Lebensdauer eines Azure Cosmos DB-Containers aufgetreten ist.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBMaxGlobalLSNReachedV4 (Upgraden auf die aktuelle empfohlene Version des Java SDK v4 zur Vermeidung eines kritischen Problems).

Integration

Upgrade auf die aktuelle FarmBeats-API-Version

Wir haben Aufrufe einer FarmBeats-API-Version identifiziert, die als veraltet eingestuft werden soll. Es wird empfohlen, zur neuesten FarmBeats-API-Version zu wechseln, um unterbrechungsfreien Zugriff auf FarmBeats, die neuesten Features und Leistungsverbesserungen sicherzustellen.

Weitere Informationen finden Sie unter Azure FarmBeats: FarmBeatsApiVersion (Upgrade auf die aktuelle FarmBeats-API-Version).

Upgrade auf die neueste Version des ADMA Java SDK

Wir haben Aufrufe einer ADMA Java SDK-Version (Azure Data Manager for Agriculture) identifiziert, die als veraltet eingestuft werden soll. Es wird empfohlen, auf die neueste SDK-Version umzustellen, um unterbrechungsfreien Zugriff auf ADMA, die neuesten Features und Leistungsverbesserungen sicherzustellen.

Weitere Informationen finden Sie unter Azure FarmBeats: FarmBeatsJavaSdkVersion (Upgrade auf die aktuelle ADMA Java SDK-Version).

Upgrade auf die neueste Version des ADMA DotNet SDK

Wir haben Aufrufe einer ADMA DotNet SDK-Version identifiziert, die als veraltet eingestuft werden soll. Es wird empfohlen, auf die neueste SDK-Version umzustellen, um unterbrechungsfreien Zugriff auf ADMA, die neuesten Features und Leistungsverbesserungen sicherzustellen.

Weitere Informationen finden Sie unter Azure FarmBeats: FarmBeatsDotNetSdkVersion (Upgrade auf die aktuelle ADMA DotNet SDK-Version).

Upgrade auf die neueste Version des ADMA JavaScript SDK

Wir haben Aufrufe einer ADMA JavaScript SDK-Version identifiziert, die als veraltet eingestuft werden soll. Es wird empfohlen, auf die neueste SDK-Version umzustellen, um unterbrechungsfreien Zugriff auf ADMA, die neuesten Features und Leistungsverbesserungen sicherzustellen.

Weitere Informationen finden Sie unter Azure FarmBeats: FarmBeatsJavaScriptSdkVersion (Upgrade auf die aktuelle ADMA JavaScript SDK-Version).

Upgrade auf die neueste Version des ADMA Python SDK

Wir haben Aufrufe einer ADMA Python SDK-Version identifiziert, die als veraltet eingestuft werden soll. Es wird empfohlen, auf die neueste SDK-Version umzustellen, um unterbrechungsfreien Zugriff auf ADMA, die neuesten Features und Leistungsverbesserungen sicherzustellen.

Weitere Informationen finden Sie unter Azure FarmBeats: FarmBeatsPythonSdkVersion (Upgrade auf die aktuelle ADMA Python SDK-Version).

SSL-/TLS-Neuverhandlung blockiert

Versuch zur SSL-/TLS-Neuverhandlung blockiert. Eine Neuverhandlung erfolgt, wenn ein Clientzertifikat über eine bereits hergestellte Verbindung angefordert wird. Wenn es blockiert ist, lesen Sie „context.Request.Certificate“ in Richtlinienausdrücken gibt „NULL“ zurück. Aktivieren Sie zur Unterstützung von Szenarien zur Clientzertifikatauthentifizierung die Option „Clientzertifikat aushandeln“ für aufgelistete Hostnamen. Bei browserbasierten Clients kann die Aktivierung dieser Option dazu führen, dass dem Client eine Zertifikataufforderung angezeigt wird.

Weitere Informationen finden Sie unter API Management: TlsRenegotiationBlocked (SSL-/TLS-Neuverhandlung blockiert).

Fehler bei Rotation von Hostnamenzertifikaten

Vom API Management-Dienst konnte das Hostnamenzertifikat aus Key Vault nicht aktualisiert werden. Stellen Sie sicher, dass das Zertifikat in Key Vault vorhanden ist und dass für die Identität des API Management-Diensts der Lesezugriff für Geheimnisse gewährt wurde. Andernfalls kann der API Management-Dienst keine Zertifikatupdates aus Key Vault abrufen, was dazu führen kann, dass für den Dienst veraltete Zertifikate verwendet werden und als Ergebnis der Runtime-API-Datenverkehr blockiert wird.

Weitere Informationen finden Sie unter API Management: HostnameCertRotationFail (Fehler bei Rotation von Hostnamenzertifikaten).

Internet der Dinge

Upgrade des Geräteclient-SDK auf eine unterstützte Version für IoT Hub

Einige oder alle Ihre Geräte verwenden ein veraltetes SDK, und es wird empfohlen, ein Upgrade auf eine unterstützte Version des SDK durchzuführen. Siehe die Details in der Empfehlung.

Weitere Informationen finden Sie unter IoT-Hub: UpgradeDeviceClientSdk (Upgrade des Geräteclient-SDK auf eine unterstützte Version für IoT Hub).

IoT Hub: potenzieller Gerätesturm erkannt

Dieser Fall kann eintreten, wenn zwei oder mehr Geräte versuchen, mit den gleichen Geräte-ID-Anmeldeinformationen eine Verbindung zur IoT Hub-Instanz herzustellen. Wenn das zweite Gerät (B) eine Verbindung herstellt, wird die Verbindung des ersten Geräts (A) getrennt. Anschließend versucht (A) wiederum, eine Verbindung herzustellen, sodass (B) getrennt wird.

Weitere Informationen finden Sie unter IoT Hub – IoTHubDeviceStorm (IoT Hub potenzieller Gerätesturm erkannt).

Aktualisieren von Device Update for IoT Hub SDK auf eine unterstützte Version

Ihre Device Update for IoT Hub-Instanz verwendet eine veraltete Version des SDK. Es wird empfohlen, dass Sie ein Upgrade auf die neueste Version durchzuführen, um aktuelle Fixes, Leistungsverbesserungen und neue Funktionen zu erhalten.

Weitere Informationen finden Sie unter IoT Hub – DU_SDK_Advisor_Recommendation (Upgrade des Device Update for IoT Hub-SDKs auf eine unterstützte Version).

Überschreitung des IoT Hub-Kontingents erkannt

Wir haben festgestellt, dass Ihre IoT Hub-Instanz das tägliche Nachrichtenkontingent überschritten hat. Um zu verhindern, dass Ihr IoT Hub sein tägliches Nachrichtenkontingent in der Zukunft überschreitet, fügen Sie Einheiten hinzu oder erhöhen sie die SKU-Ebene.

Weitere Informationen finden Sie unter IoT Hub – IoTHubQuotaExceededAdvisor (Überschreitung des IoT Hub-Kontingents erkannt).

Upgrade des Geräteclient-SDK auf eine unterstützte Version für IoT Hub

Einige oder alle Ihre Geräte verwenden ein veraltetes SDK, und es wird empfohlen, ein Upgrade auf eine unterstützte Version des SDK durchzuführen. Details finden Sie im angegebenen Link.

Weitere Informationen finden Sie unter IoT-Hub: UpgradeDeviceClientSdk (Upgrade des Geräteclient-SDK auf eine unterstützte Version für IoT Hub).

Upgrade der Runtime von Microsoft Edge-Geräten auf eine unterstützte Version für IoT Hub

Einige oder alle Ihrer Microsoft Edge-Geräte verwenden veraltete Versionen. Wir empfehlen Ihnen ein Upgrade auf die neueste unterstützte Version der Runtime durchzuführen. Details finden Sie im angegebenen Link.

Weitere Informationen finden Sie unter IoT Hub – UpgradeEdgeSdk (Upgrade der Microsoft Edge-Gerät-Runtime auf eine unterstützte Version für Iot Hub).

Medien

Erhöhen von Media Services-Kontingenten oder -Grenzwerten, um die Dienstkontinuität sicherzustellen

Die Kontingentgrenzen Ihres Medienkontos werden in Kürze erreicht. Überprüfen Sie die aktuelle Nutzung von Medienobjekten, Richtlinien für Inhaltsschlüssel und Stream-Richtlinien für das Medienkonto. Zur Vermeidung von Dienstunterbrechungen empfiehlt es sich, für die Entitäten, bei denen die Kontingentgrenze früher erreicht wird, eine Erhöhung der Kontingentgrenzen anzufordern. Zur Anforderung einer Erhöhung der Kontingentgrenzen können Sie ein Ticket mit den relevanten Angaben erstellen. Erstellen Sie keine zusätzlichen Azure Media-Konten, um höhere Grenzwerte zu erhalten.

Weitere Informationen finden Sie unter Media Services: AccountQuotaLimit (Erhöhen Sie Media Services-Kontingente oder -Grenzwerte, um die Dienstkontinuität sicherzustellen.).

Netzwerk

Für den virtuellen Check Point-Computer geht ggf. die Netzwerkkonnektivität verloren.

Wir haben ermittelt, dass für Ihren virtuellen Computer ggf. eine Version des Check Point-Images ausgeführt wird, für die möglicherweise das Problem besteht, dass bei einem Wartungsvorgang für die Plattform die Netzwerkkonnektivität verloren geht. Wir empfehlen Ihnen, ein Upgrade auf eine neuere Version des Images durchzuführen. Wenden Sie sich an Check Point, um weitere Informationen zum Upgrade Ihres Images zu erhalten.

Weitere Informationen finden Sie unter VM: CheckPointPlatformServicingKnownIssueA (Für die Check Point-VM geht möglicherweise die Netzwerkkonnektivität verloren.).

Upgrade auf die aktuelle Version des Azure Connected Machine-Agents

Der Azure Connected Machine-Agent wird in Bezug auf Fehlerbehebungen, Stabilitätsverbesserungen und neue Funktionen regelmäßig aktualisiert. Aktualisieren Sie Ihren Agent auf die aktuelle Version, um für Azure Arc die höchste Benutzerfreundlichkeit zu erzielen.

Weitere Informationen finden Sie unter Connected Machine-Agent – Azure Arc: ArcServerAgentVersion (Upgrade auf die aktuelle Version des Azure Connected Machine-Agents).

Umstellen der Geheimnisversion auf „Neuestes“ für das Azure Front Door-Kundenzertifikat

Wir empfehlen, die Geheimnisversion des Azure Front Door (AFD)-Kundenzertifikats auf „Neueste“ festzulegen, damit Front Door auf die neueste Geheimnisversion in Azure Key Vault verweist, sodass das Geheimnis automatisch rotiert werden kann.

Weitere Informationen finden Sie unter Front Door-Profil: SwitchVersionBYOC (Umstellen der Geheimnisversion für das Azure Front Door-Kundenzertifikat auf „Neueste“).

Bestätigen Sie den Domänenbesitz durch Hinzufügen eines DNS-TXT-Eintrags zum DNS-Anbieter.

Bestätigen Sie den Domänenbesitz durch Hinzufügen eines DNS-TXT-Eintrags zum DNS-Anbieter.

Weitere Informationen finden Sie unter Front Door-Profile – ValidateDomainOwnership (Überprüfen des Domäneneigentums durch Hinzufügen eines DNS TXT-Eintrags zum DNS-Anbieter.).

Erneutes Bestätigen des Domäneneigentums für die Verlängerung des verwalteten Azure Front Door-Zertifikats

Azure Front Door kann das verwaltete Zertifikat nicht automatisch verlängern, da die Domäne nicht per CNAME dem AFD-Endpunkt zugeordnet ist. Bestätigen Sie erneut das Domäneneigentum für das verwaltete Zertifikat, das automatisch verlängert werden soll.

Weitere Informationen finden Sie unter Front Door-Profil – RevalidateDomainOwnership (Erneutes Überprüfen des Domäneneigentums für die Erneuerung des verwalteten Azure Front Door-Zertifikats).

Verlängern des abgelaufenen Azure Front Door-Kundenzertifikats zur Vermeidung von Dienstunterbrechungen

Einige der Kundenzertifikate für Azure Front Door Standard- und Premium-Profile sind abgelaufen. Verlängern Sie das Zertifikat rechtzeitig, um Dienstunterbrechungen zu vermeiden.

Weitere Informationen finden Sie unter Front Door-Profil – RenewExpiredBYOC (Verlängern des abgelaufenen Azure Front Door-Kundenzertifikat, um Dienstunterbrechungen zu vermeiden.).

Durchführen eines Upgrades Ihrer SKU oder Hinzufügen weiterer Instanzen, um Fehlertoleranz sicherzustellen

Mit der Bereitstellung von mindestens zwei mittelgroßen oder großen Instanzen wird die Geschäftskontinuität bei Ausfällen sichergestellt, zu denen es aufgrund von geplanten oder ungeplanten Wartungsmaßnahmen kommt.

Erfahren Sie mehr über das Verbessern der Zuverlässigkeit Ihrer Anwendung mithilfe von Azure Advisor – Sicherstellen der Fehlertoleranz des Anwendungsgateways.

Vermeiden der Außerkraftsetzung des Hostnamens zur Sicherstellung der Websiteintegrität

Versuchen Sie, bei der Application Gateway-Konfiguration die Außerkraftsetzung des Hostnamens zu vermeiden. Die Verwendung einer anderen Domäne auf dem Application Gateway-Front-End als die, die für den Zugriff auf das Back-End genutzt wird, kann möglicherweise zur Beschädigung von Cookies oder Umleitungs-URLs führen. Eine andere Front-End-Domäne ist nicht immer ein Problem und bestimmte Kategorien von Back-Ends wie REST-APIs sind generell weniger anfällig. Vergewissern Sie sich, dass das Back-End diesen Unterschied in der Domäne verarbeiten kann, oder aktualisieren Sie die Application Gateway-Konfiguration, damit der Hostname für das Back-End nicht überschrieben werden muss. Fügen Sie bei Verwendung von App Service einen benutzerdefinierten Domänennamen an die Web-App an, und vermeiden Sie die Nutzung des Hostnamens *.azurewebsites.net für das Back-End.

Weitere Informationen finden Sie unter Anwendungsgateway: AppGatewayHostOverride (Vermeiden der Außerkraftsetzung des Hostnamens zur Sicherstellung der Websiteintegrität).

Azure WAF-Regelsatz CRS 3.1/3.2 wurde mit der Sicherheitsrisikoregel für Log4j 2 aktualisiert.

Als Reaktion auf das Log4j 2-Sicherheitsrisiko (CVE-2021-44228) wurde der Regelsatz CRS 3.1/3.2 von Azure Web Application Firewall (WAF) für Ihre Application Gateway-Instanz aktualisiert, um zusätzlichen Schutz vor diesem Sicherheitsrisiko zu bieten. Die Regeln sind unter Regel 944240 verfügbar, und für die Aktivierung ist keine Aktion erforderlich.

Weitere Informationen finden Sie unter Anwendungsgateway: AppGwLog4JCVEPatchNotification (Azure WAF-Regelsatz CRS 3.1/3.2 wurde mit der Sicherheitsrisikoregel für log4j2 aktualisiert).

Zusätzlicher Schutz zur Entschärfung des Log4j 2-Sicherheitsrisikos (CVE-2021-44228)

Zum Abmildern der Auswirkungen des Log4j 2-Sicherheitsrisikos empfehlen wir die folgenden Schritte:

1. Aktualisieren Sie Log4j 2 auf Ihren Back-End-Servern auf Version 2.15.0. Wenn ein Upgrade nicht möglich ist, folgen Sie dem zur Verfügung gestellten Anleitungslink zur Systemeigenschaft.
2. Nutzen Sie WAF Core-Regelsätze (CRS), indem Sie ein Upgrade auf die WAF-SKU durchführen.

Weitere Informationen finden Sie unter Anwendungsgateway: AppGwLog4JCVEGenericNotification (Zusätzlicher Schutz zur Entschärfung des Log4j 2-Sicherheitsrisikos (CVE-2021-44228)).

Aktualisieren der Berechtigung für virtuelle Netzwerke von Application Gateway-Benutzern

Um die Sicherheit zu verbessern und eine einheitlichere Erfahrung in Azure bereitzustellen, müssen alle Benutzer eine Berechtigungsprüfung bestehen, bevor sie eine Application Gateway-Instanz in einem Virtual Network erstellen oder aktualisieren. Die Benutzer oder Dienstprinzipale müssen mindestens die Berechtigung „Microsoft.Network/virtualNetworks/subnets/join/action“ enthalten.

Weitere Informationen finden Sie unter Anwendungsgateway – AppGwLinkedAccessFailureRecmmendation (Aktualisieren der VNet-Berechtigung von Anwendungsgateway-Benutzern).

Versionslose geheime Kennung des Key Vault verwenden, um auf die Zertifikate zu verweisen

Es wird dringend empfohlen, eine versionlose geheime ID zu verwenden, damit Ihre Anwendungsgatewayressource die neue Zertifikatversion automatisch abrufen kann, wenn verfügbar. Beispiel: https://myvault.vault.azure.net/secrets/mysecret/

Weitere Informationen finden Sie unter Anwendungsgateway – AppGwAdvisorRecommendationForCertificateUpdate (Verwenden des versionslosen geheimen Key Vault-Bezeichners um auf die Zertifikate zu verweisen).

Implementieren mehrerer ExpressRoute-Leitungen in Ihrem virtuellen Netzwerk zur Erzielung von standortübergreifender Resilienz

Wir haben ermittelt, dass Ihrem ExpressRoute-Gateway nur eine ExpressRoute-Leitung zugeordnet ist. Verbinden mindestens einer weiteren Leitung mit Ihrem Gateway, um die Redundanz und Resilienz des Peeringstandorts sicherzustellen

Weitere Informationen finden Sie unter Gateway des virtuellen Netzwerks: ExpressRouteGatewayRedundancy (Implementieren mehrerer ExpressRoute-Leitungen in Ihrem virtuellen Netzwerk zur Erzielung von standortübergreifender Resilienz).

Implementieren des ExpressRoute-Monitors im Netzwerkleistungsmonitor zur End-to-End-Überwachung Ihrer ExpressRoute-Leitung

Wir haben festgestellt, dass ExpressRoute Monitor auf dem Netzwerkleistungsmonitor zurzeit Ihre ExpressRoute-Leitung nicht überwacht. ExpressRoute-Monitor bietet End-to-End-Überwachungsfunktionen: Verlust, Latenz und Leistung von lokal zu Azure und Azure bis lokal

Weitere Informationen finden Sie unter Gateway des virtuellen Netzwerks: ExpressRouteGatewayE2EMonitoring (Implementieren des ExpressRoute-Monitors im Netzwerkleistungsmonitor zur End-to-End-Überwachung Ihrer ExpressRoute-Leitung).

Verwenden von ExpressRoute Global Reach, um Ihren Entwurf für die Notfallwiederherstellung zu verbessern

Sie scheinen ExpressRoute-Leitungen an mindestens zwei verschiedenen Standorten gepeert zu haben. Verbinden Sie diese mithilfe von ExpressRoute Global Reach miteinander, um den Datenverkehrsfluss zwischen Ihrem lokalen Netzwerk und Azure-Umgebungen weiter zu ermöglichen, wenn eine Leitung die Konnektivität verliert. Sie können Global Reach-Verbindungen zwischen Leitungen an verschiedenen Peeringstandorten innerhalb derselben Stadt oder über Stadtgrenzen hinweg herstellen.

Weitere Informationen finden Sie unter ExpressRoute-Leitung: UseGlobalReachForDR (Verwenden von ExpressRoute Global Reach, um Ihren Entwurf für die Notfallwiederherstellung zu verbessern).

Hinzufügen von mindestens einem weiteren Endpunkt zum Profil, vorzugsweise in einer anderen Azure-Region

Profile erfordern mehr als einen Endpunkt, um bei einem Ausfall eines Endpunkts Verfügbarkeit zu gewährleisten. Außerdem empfehlen wir, Endpunkte in verschiedenen Regionen zu platzieren.

Weitere Informationen finden Sie unter Traffic Manager-Profil: GeneralProfile (Hinzufügen von mindestens einem weiteren Endpunkt zum Profil, vorzugsweise in einer anderen Azure-Region).

Hinzufügen eines für „Alle (Welt)“ konfigurierten Endpunkts

Für das geografische Routing wird Datenverkehr basierend auf definierten Regionen an Endpunkte geleitet. Falls eine Region ausfällt, ist kein vordefiniertes Failover verfügbar. Durch das Konfigurieren eines Endpunkts mit der regionalen Gruppierung „Alle (Welt)“ für geografische Profile werden „schwarze Löcher“ im Datenverkehr vermieden, und es wird Dienstverfügbarkeit gewährleistet.

Weitere Informationen finden Sie unter Traffic Manager-Profil: GeographicProfile (Hinzufügen eines für „Alle (Welt)“ konfigurierten Endpunkts).

Hinzufügen eines Endpunkts zu einer anderen Azure-Region oder Verschieben eines Endpunkts in eine andere Azure-Region

Alle diesem Näherungsprofil zugeordneten Endpunkte befinden sich in derselben Region. Für Benutzer aus anderen Regionen führt dies möglicherweise zu einer hohen Latenz bei der Verbindungsherstellung. Das Hinzufügen oder Verschieben eines Endpunkts in eine andere Region verbessert die Gesamtleistung für das Näherungsrouting und bietet höhere Verfügbarkeit, falls alle Endpunkte in einer Region ausfallen.

Weitere Informationen finden Sie unter Traffic Manager-Profil: ProximityProfile (Hinzufügen eines Endpunkts zu einer anderen Azure-Region oder Verschieben eines Endpunkts in eine andere Azure-Region).

Umstellen von Basic-Gateways auf Gateway-SKUs für die Produktion

Die Basic-SKU des VPN-Gateways ist für Entwicklungs- oder Testszenarien konzipiert. Wechseln Sie zu einer Produktions-SKU, wenn Sie das VPN-Gateway zu Produktionszwecken verwenden. SKUs für die Produktion bieten eine höhere Anzahl von Tunneln, BGP-Unterstützung, Aktiv-Aktiv, kundenspezifische IPsec-/IKE-Richtlinien sowie höhere Stabilität und Verfügbarkeit.

Weitere Informationen finden Sie unter Gateway des virtuellen Netzwerks: BasicVPNGateway (Umstellen von Basic-Gateways auf Gateway-SKUs für die Produktion).

Verwenden eines NAT-Gateways für ausgehende Konnektivität

Verhindern Sie das Risiko von Konnektivitätsausfällen aufgrund der Erschöpfung von SNAT-Ports, indem Sie ein NAT-Gateway für den ausgehenden Datenverkehr Ihrer virtuellen Netzwerke verwenden. NAT-Gateway wird dynamisch skaliert und bietet sichere Verbindungen für den Internet-Datenverkehr.

Weitere Informationen finden Sie unter Virtuelles Netzwerk: natGateway (Verwenden des NAT-Gateways für ausgehende Konnektivität).

Aktualisieren der Berechtigung für virtuelle Netzwerke von Application Gateway-Benutzern

Um die Sicherheit zu verbessern und eine einheitlichere Erfahrung in Azure bereitzustellen, müssen alle Benutzer eine Berechtigungsprüfung bestehen, bevor sie eine Application Gateway-Instanz in einem Virtual Network erstellen oder aktualisieren. Die Benutzer oder Dienstprinzipale müssen mindestens die Berechtigung „Microsoft.Network/virtualNetworks/subnets/join/action“ enthalten.

Weitere Informationen finden Sie unter Anwendungsgateway – AppGwLinkedAccessFailureRecmmendation (Aktualisieren der VNet-Berechtigung von Anwendungsgateway-Benutzern).

Versionslose geheime Kennung des Key Vault verwenden, um auf die Zertifikate zu verweisen

Es wird dringend empfohlen, eine versionlose geheime ID zu verwenden, damit Ihre Anwendungsgatewayressource die neue Zertifikatversion automatisch abrufen kann, wenn verfügbar. Beispiel: https://myvault.vault.azure.net/secrets/mysecret/

Weitere Informationen finden Sie unter Anwendungsgateway – AppGwAdvisorRecommendationForCertificateUpdate (Verwenden des versionslosen geheimen Key Vault-Bezeichners um auf die Zertifikate zu verweisen).

Aktivieren von Aktiv/Aktiv-Gateways für Redundanz

In der Aktiv-Aktiv-Konfiguration richten beide Instanzen des VPN-Gateways S2S-VPN-Tunnel zu Ihrem lokalen VPN-Gerät ein. Wenn eine geplante Wartung oder ein ungeplantes Ereignis für eine Gatewayinstanz eintritt, wird der Datenverkehr automatisch auf den anderen aktiven IPsec-Tunnel umgeschaltet.

Weitere Informationen finden Sie unter Gateway des virtuellen Netzwerks: VNetGatewayActiveActive (Aktivieren von Aktiv/Aktiv-Gateways für Redundanz).

Verwenden von verwalteten TLS-Zertifikaten

Da Front Door Ihre TLS-Zertifikate verwaltet, reduziert dies Ihre Betriebskosten und hilft Ihnen, kostspielige Ausfalle zu vermeiden, die durch vergessene Verlängerung eines Zertifikats verursacht werden.

Erfahren Sie mehr über das Verwenden von verwalteten TLS-Zertifikaten.

Deaktivieren von Integritätstests, wenn eine Ursprungsgruppe nur einen Ursprung enthält

Wenn nur ein einziger Ursprung verwendet wird, leitet Front Door den Datenverkehr immer zu diesem Ursprung weiter, auch wenn sein Integritätstest einen fehlerhaften Status meldet. Der Status des Integritätstests nimmt keinerlei Änderungen am Verhalten von Front Door vor. In diesem Szenario bieten Integritätstests keinen Vorteil und sollten deaktiviert werden, um den Datenverkehr auf Ihrem Ursprung zu verringern.

Erfahren Sie mehr über bewährte Methoden bei Integritätstests.

Verwenden desselben Domänennamens in Azure Front Door und an Ihrem Ursprung

Es wird empfohlen, den ursprünglichen HTTP-Hostnamen beizubehalten, wenn Sie einen Reverseproxy vor einer Webanwendung verwenden. Wird auf dem Reverseproxy ein anderer Hostname verwendet als der, der gegenüber dem Back-End-Anwendungsserver angegeben wird, kann das dazu führen, dass Cookies oder Umleitungs-URLs nicht ordnungsgemäß funktionieren. Beispielsweise kann der Sitzungszustand verloren gehen, es können Authentifizierungsfehler auftreten, oder Back-End-URLs können versehentlich für Endbenutzer verfügbar gemacht werden. Sie können diese Probleme vermeiden, indem Sie den Hostnamen der ursprünglichen Anforderung beibehalten, sodass der Anwendungsserver die gleiche Domäne wie der Webbrowser sieht.

Erfahren Sie mehr über das Verwenden desselben Domänennamens in Azure Front Door und an Ihrem Ursprung.

SAP für Azure

Aktivieren des Parameters „concurrent-fencing“ in der Pacemaker-Konfiguration für das ASCS HA-Setup in SAP-Workloads

Der Parameter „concurrent-fencing“ ermöglicht die gleichzeitige Durchführung von Fencingvorgängen, wenn er auf „true“ festgelegt ist. Legen Sie diesen Parameter in der Pacemaker-Clusterkonfiguration für das ASCS Hochverfügbarkeitsssetup auf „true“ fest.

Weitere Informationen finden Sie unter Zentrale Serverinstanz – ConcurrentFencingHAASCSRH (Aktivieren Sie den Parameter "concurrent-fencing" in der Pacemaker-Konfiguration im ASCS HA-Setup in SAP-Workloads).

Sicherstellen, dass stonith für die Pacemaker-Konfiguration im ASCS HA-Setup in SAP-Workloads aktiviert ist

In einem Pacemaker-Cluster erfolgt die Implementierung des Fencing auf Knotenebene mithilfe der Ressource STONITH (Shoot The Other Node in the Head). Stellen Sie sicher, dass „stonith-enable“ in der Hochverfügbarkeit-Clusterkonfiguration Ihrer SAP-Workload auf „true“ gesetzt ist.

Weitere Informationen finden Sie unter Central Server Instance - StonithEnabledHAASCSRH (Stellen Sie sicher, dass Stonith für die Pacemaker-Konfigurierung in ASCS HA-Setup in SAP-Workloads aktiviert ist).

Legen Sie für die Clusterkonfiguration im ASCS HA-Setup in SAP-Workloads das stonith-Timeout auf 144 fest.

Legen Sie das Stonith-Timeout für Hochverfügbarkeit-Cluster gemäß der Empfehlung für SAP in Azure auf 144 fest.

Weitere Informationen finden Sie unter Central Server Instance - StonithTimeOutHAASCS (Festlegen des Stonith Timeouts auf 144 für die Clusterkonfiguration in ASCS HA-Setup in SAP-Workloads).

Festlegen des corosync-Tokens im Pacemaker-Cluster auf 30000 für das ASCS HA-Setup in SAP-Workloads

Die Corosync-Token-Einstellung bestimmt das Timeout, das direkt oder als Grundlage für die Timeout-Berechnung des echten Tokens in Hochverfügbarkeit-Clustern verwendet wird. Legen Sie das Corosync-Token gemäß der Empfehlung für SAP in Azure auf 30000 fest, um eine speichererhaltende Wartung zu ermöglichen.

Weitere Informationen finden Sie unter Zentrale Serverinstanz – CorosyncTokenHAASCSRH (Legen Sie das Corosync-Token im Pacemaker-Cluster auf 30000 für ASCS HA-Setup in SAP-Workloads fest).

Festlegen des Parameters für erwartete Stimmen in der Pacemaker-Konfiguration im ASCS HA-Setup in SAP-Workloads auf 2

Legen Sie für ein Hochverfügbarkeit-Clusters mit zwei Knoten die Quorum-Stimmen gemäß der Empfehlung für SAP in Azure auf 2 fest.

Weitere Informationen finden Sie unter Zentrale Serverinstanz – ExpectedVotesHAASCSRH (Legen Sie den Parameter für die erwartete Abstimmung in der Pacemaker-Konfiguration in ASCS HA-Setup in SAP-Workloads auf 2 fest).

Festlegen von „token_retransmits_before_loss_const“ auf 10 im Pacemaker-Cluster im ASCS HA-Setup in SAP-Workloads

Der Corosync token_retransmits_before_loss_const bestimmt, wie viele erneute Tokenübertragungen das System in Hochverfügbarkeits-Clustern vor dem Timeout versuchen soll. Festlegen von totem.token_retransmits_before_loss_const auf 10 gemäß der Empfehlung für das ASCS Hochverfügbarkeitsssetup.

Weitere Informationen finden Sie unter Zentrale Serverinstanz – TokenRestransmitsHAASCSSLE (Set 'token_retransmits_before_loss_const' auf 10 im Pacemaker-Cluster im ASCS HA-Setup in SAP-Workloads).

Festlegen des corosync-Tokens im Pacemaker-Cluster auf 30000 für das ASCS HA-Setup in SAP-Workloads

Die Corosync-Token-Einstellung bestimmt das Timeout, das direkt oder als Grundlage für die Timeout-Berechnung des echten Tokens in Hochverfügbarkeit-Clustern verwendet wird. Legen Sie das Corosync-Token gemäß der Empfehlung für SAP in Azure auf 30000 fest, um eine speichererhaltende Wartung zu ermöglichen.

Weitere Informationen finden Sie unter Zentrale Serverinstanz – CorosyncTokenHAASCSSLE (Legen Sie das Corosync-Token im Pacemaker-Cluster auf 30000 für ASCS HA-Setup in SAP-Workloads fest).

Festlegen von „corosync max_messages“ im Pacemaker-Cluster auf 20 für das ASCS HA-Setup in SAP-Workloads

Die Konstante corosync max_messages gibt die maximale Anzahl von Nachrichten an, die von einem Prozessor bei Erhalt des Tokens gesendet werden dürfen. Wir empfehlen, den Parameter corosync token in der Clusterkonfiguration vom Pacemaker auf 20 Mal festzulegen.

Weitere Informationen finden Sie unter Zentrale Serverinstanz - CorosyncMaxMessagesHAASCSSLE (Legen Sie den corosync max_messages im Pacemaker-Cluster auf 20 für ASCS HA-Setup in SAP-Workloads fest).

Festlegen von „corosync consensus“ im Pacemaker-Cluster auf 36000 für das ASCS HA-Setup in SAP-Workloads

Der corosync-Parameter „consensus“ gibt in Millisekunden an, wie lange gewartet werden soll, bis ein Konsens erreicht ist, bevor eine neue Runde der Mitgliedschaft in der Clusterkonfiguration gestartet wird. Wir empfehlen, in der Pacemaker-Clusterkonfiguration für das ASCS Hochverfügbarkeitssetup das 1,2-fache des Corosync-Tokens festzulegen.

Weitere Informationen finden Sie unter Zentrale Serverinstanz – CorosyncConsensusHAASCSSLE (Festlegen des „Corosync-Konsenses“ im Pacemaker-Cluster auf 36000 für ASCS HA-Setup in SAP-Workloads).

Festlegen des Parameters für erwartete Stimmen in der Clusterkonfiguration im ASCS HA-Setup in SAP-Workloads auf 2

Legen Sie für ein Hochverfügbarkeits-Cluster mit zwei Knoten den Quorumparameter expected_votes gemäß der Empfehlung für SAP in Azure auf 2 fest.

Weitere Informationen finden Sie unter Zentrale Serverinstanz – ExpectedVotesHAASCSSLE (Legen Sie den Parameter für die erwartete Abstimmung in der Clusterkonfiguration in ASCS HA-Setup in SAP-Workloads auf 2 fest).

Legen Sie den Parameter „two_node“ in der Clusterkonfiguration für das ASCS HA-Setup in SAP-Workloads auf 1 fest.

Legen Sie für ein Hochverfügbarkeits-Cluster mit zwei Knoten den Quorum-Parameter „two_node“ gemäß der Empfehlung für SAP in Azure auf 1 fest.

Weitere Informationen finden Sie unter Zentrale Serverinstanz – TwoNodesParametersHAASCSSLE (Legen Sie den Parameter two_node in der Clusterkonfiguration in ASCS HA-Setup in SAP-Workloads auf 1 fest).

Festlegen des corosync-Joins im Pacemaker-Cluster auf 60 für das ASCS HA-Setup in SAP-Workloads

Der Timeout für den corosync-Join gibt in Millisekunden an, wie lange auf Join-Nachrichten im Mitgliedschaftsprotokoll gewartet werden soll. Wir empfehlen, in der Pacemaker-Clusterkonfiguration für das ASCS HA-Setup den Wert 60 festzulegen.

Weitere Informationen finden Sie unter Zentrale Serverinstanz – CorosyncJoinHAASCSSLE (Legen Sie das „Corosync-Join“ im Pacemaker-Cluster auf 60 für das ASCS HA-Setup in SAP-Workloads fest).

Sicherstellen, dass stonith für die Clusterkonfiguration im ASCS HA-Setup in SAP-Workloads aktiviert ist

In einem Pacemaker-Cluster erfolgt die Implementierung des Fencing auf Knotenebene mithilfe der Ressource STONITH (Shoot The Other Node in the Head). Stellen Sie sicher, dass „stonith-enable“ in der Hochverfügbarkeit-Clusterkonfiguration auf „true“ gesetzt ist.

Weitere Informationen finden Sie unter Zentrale Serverinstanz - StonithEnabledHAASCS (Stellen Sie sicher, dass Stonith für die Clusterkofigurierung in ASCS HA-Setup in SAP-Workloads aktiviert ist).

Festlegen von „stonith-timeout“ auf 900 in der Pacemaker-Konfiguration mit Azure-Fence-Agent für ein ASCS-Hochverfügbarkeitssetup

Das „stonith-timeout“ muss auf 900 festgelegt werden, damit Pacemaker für ein ASCS-Hochverfügbarkeitssetup zuverlässig funktioniert. Diese „stonith-timeout“-Einstellung gilt, wenn Sie den Azure-Fence-Agent für das Fencing mit verwalteter Identität oder Dienstprinzipal verwenden.

Weitere Informationen finden Sie unter Zentrale Serverinstanz - StonithTimeOutHAASCSSLE (Set „stonith-timeout“ auf 900 in der Pacemaker-Konfiguration mit Azure-Fence-Agent für ASCS HA-Setup).

Aktivieren des Parameters „concurrent-fencing“ in der Pacemaker-Konfiguration für das ASCS HA-Setup in SAP-Workloads

Der Parameter „concurrent-fencing“ ermöglicht die gleichzeitige Durchführung von Fencingvorgängen, wenn er auf „true“ festgelegt ist. Legen Sie diesen Parameter in der Pacemaker-Clusterkonfiguration für das ASCS Hochverfügbarkeitsssetup auf „true“ fest.

Weitere Informationen finden Sie unter Zentrale Serverinstanz - ConcurrentFencingHAASCSSLE (Aktivieren des Parameters „concurrent-fencing“ in der Pacemaker-Konfiguration in ASCS HA-Setup in SAP-Workloads).

Erstellen der Softdog-Konfigurationsdatei in der Pacemaker-Konfiguration für ein ASCS-Hochverfügbarkeitssetup in SAP-Workloads

Der Softdog-Timer wird als Kernelmodul im Linux-Betriebssystem geladen. Dieser Timer löst einen Systemzurücksetzung aus, wenn er erkennt, dass das System hängen geblieben ist. Stellen Sie sicher, dass die Softdog-Konfigurationsdatei im Pacemaker-Cluster für ein ASCS-Hochverfügbarkeitssetup erstellt wird.

Weitere Informationen finden Sie unter Zentrale Serverinstanz – SoftdogConfigHAASCSSLE (Erstellen der Softdog-Konfigurationsdatei in der Pacemaker-Konfiguration für ASCS HA-Setup in SAP-Workloads).

Sicherstellen, dass das Softdog-Modul für Pacemaker im ASCS-Hochverfügbarkeitssetup in SAP-Workloads geladen ist

Der Softdog-Timer wird als Kernelmodul im Linux-Betriebssystem geladen. Dieser Timer löst einen Systemzurücksetzung aus, wenn er erkennt, dass das System hängen geblieben ist. Stellen Sie zunächst sicher, dass Sie die Softdog-Konfigurationsdatei erstellt haben, und laden Sie dann das Softdog-Modul in der Pacemaker-Konfiguration für das ASCS-Hochverfügbarkeitssetup.

Weitere Informationen finden Sie unter Zentrale Serverinstanz - softdogmoduleloadedHAASCSSLE (Stellen Sie sicher, dass das Softdog-Modul für Pacemaker im ASCS HA-Setup in SAP-Workloads geladen wird).

Sicherstellen, dass in der Pacemaker-Konfiguration für das ASCS-Hochverfügbarkeitssetup genau eine Instanz von „fence_azure_arm“ vorhanden ist

Der „fence_azure_arm“ ist ein E/A-Fencing-Agent für Azure Resource Manager. Stellen Sie sicher, dass in Ihrer Pacemaker-Konfiguration für das ASCS-Hochverfügbarkeitssetup genau eine Instanz von „fence_azure_arm“ vorhanden ist. Die „fence_azure_arm“-Anforderung gilt, wenn Sie Azure-Fence-Agent für das Fencing mit verwalteter Identität oder Dienstprinzipal verwenden.

Weitere Informationen finden Sie unter Zentrale Serverinstanz – FenceAzureArmHAASCSSLE (Stellen Sie sicher, dass genau eine Instanz von „fence_azure_arm“ in Ihrer Pacemaker-Konfiguration für das ASCS-Hochverfügbarkeitssetup vorhanden ist).

Aktivieren von Hochverfügbarkeitsports in Azure Load Balancer für ASCS-Hochverfügbarkeitssetup in SAP-Workloads

Aktivieren Sie Hochverfügbarkeitsports in den Lastenausgleichsregeln für das Hochverfügbarkeitssetup der ASCS-Instanz in SAP-Workloads. Öffnen Sie den Lastenausgleich, wählen Sie „Lastenausgleichsregeln“ aus, und fügen Sie die Regel zum Aktivieren der empfohlenen Einstellungen hinzu, bzw. bearbeiten Sie sie.

Weitere Informationen finden Sie unter Zentrale Serverinstanz – ASCSHAEnableLBPorts (Aktivieren von HA-Ports im Azure Load Balancer für das ASCS HA-Setup in SAP-Workloads).

Aktivieren von Floating IP in Azure Load Balancer für ASCS-Hochverfügbarkeitssetup in SAP-Workloads

Aktivieren Sie Floating IP in den Lastenausgleichsregeln für Azure Load Balancer für das Hochverfügbarkeitssetup der ASCS-Instanz in SAP-Workloads. Öffnen Sie den Lastenausgleich, wählen Sie „Lastenausgleichsregeln“ aus, und fügen Sie die Regel zum Aktivieren der empfohlenen Einstellungen hinzu, bzw. bearbeiten Sie sie.

Weitere Informationen finden Sie unter Zentrale Serverinstanz – ASCSHAEnableFloatingIpLB (Aktivieren der Floating IP im Azure Load Balancer für das ASCS HA-Setup in SAP-Workloads).

Festlegen des Leerlauftimeouts in Azure Load Balancer auf 30 Minuten für ASCS-Hochverfügbarkeitssetup in SAP-Workloads

Um ein Timeout des Lastenausgleichs zu verhindern, stellen Sie sicher, dass für alle Azure-Lastenausgleichsregeln „Leerlauftimeout (Minuten)“ auf den maximalen Wert von 30 Minuten festgelegt ist. Öffnen Sie den Lastenausgleich, wählen Sie „Lastenausgleichsregeln“ aus, und fügen Sie die Regel zum Aktivieren der empfohlenen Einstellungen hinzu, bzw. bearbeiten Sie sie.

Weitere Informationen finden Sie unter Zentrale Serverinstanz – ASCSHASetIdleTimeOutLB (Festlegen des Leerlaufzeittimeouts in Azure Load Balancer auf 30 Minuten für das ASCS HA-Setup in SAP-Workloads).

Deaktivieren von TCP-Zeitstempeln auf virtuellen Computern, die im ASCS-Hochverfügbarkeitssetup in SAP-Workloads hinter Azure Load Balancer platziert werden

Deaktivieren Sie TCP-Zeitstempel auf virtuellen Computern, die sich hinter Azure Load Balancer befinden. Aktivierte TCP-Zeitstempel führen dazu, dass Integritätstests fehlschlagen, weil TCP-Pakete vom TCP-Stapel des VM-Gastbetriebssystems verworfen werden. Die verworfenen TCP-Pakete können dazu führen, dass der Lastenausgleich den Endpunkt als ausgefallen markiert.

Weitere Informationen finden Sie unter Zentrale Serverinstanz – ASCSLBHADisableTCP (TCP-Zeitstempel für VMs deaktivieren, die hinter Azure Load Balancer in ASCS HA-Setup in SAP-Workloads platziert wurden).

Aktivieren Sie stonith in der Clusterkonfiguration in Hochverfügbarkeit-fähigen SAP-Workloads für VMs mit Redhat OS

In einem Pacemaker-Cluster erfolgt die Implementierung des Fencing auf Knotenebene mithilfe der Ressource STONITH (Shoot The Other Node in the Head). Stellen Sie sicher, dass „stonith-enable“ in der Hochverfügbarkeit-Clusterkonfiguration Ihrer SAP-Workload auf „true“ gesetzt ist.

Weitere Informationen finden Sie unter Datenbankinstanz - StonithEnabledHARH (Aktivieren von Stonith in der Clusterkonfiguration in HA-fähigen SAP-Workloads für VMs mit Redhat OS).

Legen Sie das stonith-Timeout für die Clusterkonfiguration in Hochverfügbarkeit-aktivierten SAP-Workloads auf 144 fest

Legen Sie das Stonith-Timeout für Hochverfügbarkeit-Cluster gemäß der Empfehlung für SAP in Azure auf 144 fest.

Weitere Informationen finden Sie unter Datenbankinstanz – StonithTimeoutHASLE (Festlegen des Stonith-Timeouts auf 144 für die Clusterkonfiguration in HA-fähigen SAP-Workloads).

Aktivieren Sie stonith in der Cluster-Konfiguration in Hochverfügbarkeit-aktivierten SAP-Workloads für VMs mit SUSE OS

In einem Pacemaker-Cluster erfolgt die Implementierung des Fencing auf Knotenebene mithilfe der Ressource STONITH (Shoot The Other Node in the Head). Stellen Sie sicher, dass „stonith-enable“ in der Hochverfügbarkeit-Clusterkonfiguration auf „true“ gesetzt ist.

Weitere Informationen finden Sie unter Datenbankinstanz - StonithEnabledHASLE (Aktivieren von Stonith in der Clusterkonfiguration in HA-fähigen SAP-Workloads für VMs mit SUSE OS).

Festlegen von „stonith-timeout“ auf „900“ in der Pacemaker-Konfiguration mit Azure-Fence-Agent für ein HANA DB-Hochverfügbarkeitssetup

Legen Sie das „stonith-timeout“ auf „900“ fest, damit Pacemaker für ein HANA DB-Hochverfügbarkeitssetup zuverlässig funktioniert. Diese Einstellung ist wichtig, wenn Sie den Azure-Fence-Agent für das Fencing mit verwalteter Identität oder dem Dienstprinzipal verwenden.

Weitere Informationen finden Sie unter Datenbankinstanz - StonithTimeOutSuseHDB (Festlegen des „stonith-timeout“ auf 900 in der Pacemaker-Konfiguration mit Azure-Fence-Agent für das HANA DB HA-Setup).

Legen Sie das Corosync-Token im Pacemaker-Cluster auf 30000 für Hochverfügbarkeit-aktivierte HANA DB für VM mit Redhat OS fest

Die Corosync-Token-Einstellung bestimmt das Timeout, das direkt oder als Grundlage für die Timeout-Berechnung des echten Tokens in Hochverfügbarkeit-Clustern verwendet wird. Legen Sie das Corosync-Token gemäß der Empfehlung für SAP in Azure auf 30000 fest, um eine speichererhaltende Wartung zu ermöglichen.

Weitere Informationen finden Sie unter Datenbankinstanz – CorosyncTokenHARH (Festlegen des Corosync-Tokens im Pacemaker-Cluster auf 30000 für HA aktivierte HANA DB für VM mit Redhat OS).

Setzen Sie den Parameter Erwartete Stimmen in der Clusterkonfiguration in Hochverfügbarkeit-aktivierten SAP-Workloads auf 2

Legen Sie für ein Hochverfügbarkeit-Clusters mit zwei Knoten die Quorum-Stimmen gemäß der Empfehlung für SAP in Azure auf 2 fest.

Weitere Informationen finden Sie unter Datenbankinstanz – ExpectedVotesParamtersHARH (Legen Sie den Parameter für die erwartete Abstimmung in der Clusterkonfiguration in HA-fähigen SAP-Workloads auf 2 fest).

Setzen Sie das Corosync-Token im Pacemaker-Cluster auf 30000 für Hochverfügbarkeit-aktivierte HANA DB für VM mit SUSE OS

Die Corosync-Token-Einstellung bestimmt das Timeout, das direkt oder als Grundlage für die Timeout-Berechnung des echten Tokens in Hochverfügbarkeit-Clustern verwendet wird. Legen Sie das Corosync-Token gemäß der Empfehlung für SAP in Azure auf 30000 fest, um eine speichererhaltende Wartung zu ermöglichen.

Weitere Informationen finden Sie unter Datenbankinstanz – CorosyncTokenHASLE (Festlegen des Corosync-Tokens im Pacemaker-Cluster auf 30000 für HA-fähige HANA DB für VM mit SUSE OS).

Festlegen des Parameters PREFER_SITE_TAKEOVER auf „true“ in der Pacemaker-Konfiguration für das HANA DB HA-Setup

Der Parameter PREFER_SITE_TAKEOVER in der SAP HANA-Topologie legt fest, ob der HANA SR-Ressourcen-Agent die Übernahme auf die sekundäre Instanz vorzieht, anstatt die ausgefallene primäre Instanz lokal neu zu starten. Für eine zuverlässige Funktion des HANA DB HA-Setups legen Sie den Wert auf „true“ fest.

Weitere Informationen finden Sie unter Datenbankinstanz - PreferSiteTakeOverHARH (Festlegen des Parameters PREFER_SITE_TAKEOVER auf „true“ in der Pacemaker-Konfiguration für das HANA DB HA-Setup).

Aktivieren des Parameters „concurrent-fencing“ in der Pacemaker-Konfiguration für das HANA DB HA-Setup

Der Parameter „concurrent-fencing“ ermöglicht die gleichzeitige Durchführung von Fencingvorgängen, wenn er auf „true“ festgelegt ist. Legen Sie diesen Parameter in der Pacemaker-Clusterkonfiguration für das HANA DB Hochverfügbarkeitsssetup auf „true“ fest.

Weitere Informationen finden Sie unter Datenbankinstanz – ConcurrentFencingHARH (Aktivieren des Parameters "concurrent-fencing" in der Pacemaker-Konfiguration für das HANA DB HA-Setup).

Festlegen des Parameters PREFER_SITE_TAKEOVER auf „true“ in der Clusterkonfiguration bei HA-fähigen SAP-Workloads

Der Parameter PREFER_SITE_TAKEOVER in der SAP HANA-Topologie legt fest, ob der HANA SR-Ressourcen-Agent die Übernahme auf die sekundäre Instanz vorzieht, anstatt die ausgefallene primäre Instanz lokal neu zu starten. Für eine zuverlässige Funktion des HANA DB HA-Setups legen Sie den Wert auf „true“ fest.

Weitere Informationen finden Sie unter Datenbankinstanz - PreferSiteTakeoverHDB (Festlegen des Parameters PREFER_SITE_TAKEOVER auf „true“ in der Clusterkonfiguration in HA-fähigen SAP-Workloads).

Festlegen von „token_retransmits_before_loss_const“ auf 10 im Pacemaker-Cluster in HA-fähigen SAP-Workloads

Der corosync token_retransmits_before_loss_const bestimmt, wie viele erneute Tokenübertragungen in Hochverfügbarkeits-Clustern vor dem Timeout versucht werden. Legen Sie das totem.token_retransmits_before_loss_const auf 10 gemäß der Empfehlung für das HANA DB Hochverfügbarkeitsssetup fest.

Weitere Informationen finden Sie unter Datenbankinstanz – TokenRetransmitsHDB (Festlegen des „token_retransmits_before_loss_const“ auf 10 in dem Pacemaker-Cluster in HA-fähigen SAP-Workloads).

Legen Sie den Parameter „two_node“ in der Clusterkonfiguration bei SAP-Workloads mit aktivierter Hochverfügbarkeit auf 1 fest.

Legen Sie für ein Hochverfügbarkeits-Cluster mit zwei Knoten den Quorum-Parameter „two_node“ gemäß der Empfehlung für SAP in Azure auf 1 fest.

Weitere Informationen finden Sie unter Datenbankinstanz – TwoNodeParameterSuseHDB (Festlegen des two_node-Parameters auf 1 in der Clusterkonfiguration in HA-fähigen SAP-Workloads).

Aktivieren des Parameters „concurrent-fencing“ in der Clusterkonfiguration in HA-fähigen SAP-Workloads

Der Parameter „concurrent-fencing“ ermöglicht die gleichzeitige Durchführung von Fencingvorgängen, wenn er auf „true“ festgelegt ist. Legen Sie diesen Parameter in der Pacemaker-Clusterkonfiguration für das HANA DB Hochverfügbarkeitsssetup auf „true“ fest.

Weitere Informationen finden Sie unter Datenbankinstanz – ConcurrentFencingSuseHDB (Aktivieren des Parameters „concurrent-fencing“ in der Clusterkonfiguration in HA-fähigen SAP-Workloads).

Festlegen von „corosync join“ im Pacemaker-Cluster auf 60 für HA-fähige HANA DB in SAP-Workloads

Der Timeout für den corosync-Join gibt in Millisekunden an, wie lange auf Join-Nachrichten im Mitgliedschaftsprotokoll gewartet werden soll. Es wird empfohlen, dass der Wert in der Pacemaker-Clusterkonfiguration für das HANA DB Hochverfügbarkeitsssetup auf 60 festgelegt wird.

Weitere Informationen finden Sie unter Datenbankinstanz - CorosyncHDB (Festlegen des „corosync join“ im Pacemaker-Cluster auf 60 für HA-fähige HANA DB in SAP-Workloads).

Festlegen von „corosync max_messages“ im Pacemaker-Cluster auf 20 für HA-fähige HANA DB in SAP-Workloads

Die Konstante corosync max_messages gibt die maximale Anzahl von Nachrichten an, die von einem Prozessor bei Erhalt des Tokens gesendet werden dürfen. Es wird empfohlen, den Parameter Corosync-Token in der Clusterkonfiguration des Pacemakers auf 20 Mal festzulegen.

Weitere Informationen finden Sie unter Datenbankinstanz - CorosyncMaxMessageHDB (Festlegen des "corosync max_messages" im Pacemaker-Cluster auf 20 für HA-fähige HANA DB in SAP-Workloads).

Festlegen von „corosync consensus“ im Pacemaker-Cluster auf 36000 für HA-fähige HANA DB in SAP-Workloads

Der corosync-Parameter „consensus“ gibt in Millisekunden an, wie lange gewartet werden soll, bis ein Konsens erreicht ist, bevor eine neue Runde der Mitgliedschaft in der Clusterkonfiguration gestartet wird. Wir empfehlen, in der Pacemaker-Clusterkonfiguration für das HANA DVB Hochverfügbarkeitsssetup das 1,2-fache des Corosync-Tokens festzulegen.

Weitere Informationen finden Sie unter Datenbankinstanz – CorosyncConsensusHDB (Festlegen des „corosync consensus“ im Pacemaker-Cluster auf 36000 für HA-fähige HANA DB in SAP-Workloads).

Erstellen der Softdog-Konfigurationsdatei in der Pacemaker-Konfiguration für eine HANA-Datenbank mit Hochverfügbarkeitsunterstützung in SAP-Workloads

Der Softdog-Timer wird als Kernelmodul im Linux-Betriebssystem geladen. Dieser Timer löst einen Systemzurücksetzung aus, wenn er erkennt, dass das System hängen geblieben ist. Stellen Sie sicher, dass die Softdog-Konfigurationsdatei im Pacemaker-Cluster für ein HANA DB-Hochverfügbarkeitssetup erstellt wird.

Weitere Informationen finden Sie unter Datenbankinstanz – SoftdogConfigSuseHDB (Erstellen der Softdog-Konfigurationsdatei in der Pacemaker-Konfiguration für HA-fähige HANA DB in SAP-Workloads).

Sicherstellen, dass in der Pacemaker-Konfiguration für das HANA DB-Hochverfügbarkeitssetup genau eine Instanz von „fence_azure_arm“ vorhanden ist

Der „fence_azure_arm“ ist ein E/A-Fencing-Agent für Azure Resource Manager. Stellen Sie sicher, dass in Ihrer Pacemaker-Konfiguration für das HANA DB-Hochverfügbarkeitssetup genau eine Instanz von „fence_azure_arm“ vorhanden ist. Die fence_azure-arm-Instanzanforderung gilt, wenn Sie Azure-Fence-Agent zum Fencing mit verwalteter Identität oder Dienstprinzipal verwenden.

Weitere Informationen finden Sie unter Datenbankinstanz – FenceAzureArmSuseHDB (Sicherstellen, dass eine Instanz von fence_azure_arm in der Pacemaker-Konfiguration für HANA DB HA-Setup vorhanden ist).

Sicherstellen, dass das Softdog-Modul für Pacemaker in der HANA-Datenbank mit Hochverfügbarkeitsunterstützung in SAP-Workloads geladen ist

Der Softdog-Timer wird als Kernelmodul im Linux-Betriebssystem geladen. Dieser Timer löst einen Systemzurücksetzung aus, wenn er erkennt, dass das System hängen geblieben ist. Stellen Sie zunächst sicher, dass Sie die Softdog-Konfigurationsdatei erstellt haben, und laden Sie dann das Softdog-Modul in der Pacemaker-Konfiguration für ein HANA DB-Hochverfügbarkeitssetup.

Weitere Informationen finden Sie unter Datenbankinstanz - SoftdogModuleSuseHDB (Sicherstellen, dass das Softdog-Modul für Pacemaker in HA-fähiger HANA DB in SAP-Workloads geladen wird).

Festlegen des Leerlauftimeouts in Azure Load Balancer auf 30 Minuten für HANA DB-Hochverfügbarkeitssetup in SAP-Workloads

Um ein Timeout des Lastenausgleichs zu verhindern, stellen Sie sicher, dass für alle Azure-Lastenausgleichsregeln „Leerlauftimeout (Minuten)“ auf den maximalen Wert von 30 Minuten festgelegt ist. Öffnen Sie den Lastenausgleich, wählen Sie „Lastenausgleichsregeln“ aus, und fügen Sie die Regel zum Aktivieren der empfohlenen Einstellungen hinzu, bzw. bearbeiten Sie sie.

Weitere Informationen finden Sie unter Datenbankinstanz – DBHASetIdleTimeOutLB (Festlegen des Leerlaufzeittimeouts in Azure Load Balancer auf 30 Minuten für das HANA DB HA-Setup in SAP-Workloads).

Aktivieren von Floating IP in Azure Load Balancer für HANA DB-Hochverfügbarkeitssetup in SAP-Workloads

Aktivieren Sie Floating IP in den Lastenausgleichsregeln für Azure Load Balancer für das Hochverfügbarkeitssetup der HANA DB-Instanz in SAP-Workloads. Öffnen Sie den Lastenausgleich, wählen Sie „Lastenausgleichsregeln“ aus, und fügen Sie die Regel zum Aktivieren der empfohlenen Einstellungen hinzu, bzw. bearbeiten Sie sie.

Weitere Informationen finden Sie unter Datenbankinstanz – DBHAEnableFloatingIpLB (Aktivieren der Floating IP im Azure Load Balancer für HANA DB im HA-Setup in SAP-Workloads).

Aktivieren von Hochverfügbarkeitsports in Azure Load Balancer für HANA DB-Hochverfügbarkeitssetup in SAP-Workloads

Aktivieren Sie Hochverfügbarkeitsports in den Lastenausgleichsregeln für das Hochverfügbarkeitssetup der HANA DB-Instanz in SAP-Workloads. Öffnen Sie den Lastenausgleich, wählen Sie „Lastenausgleichsregeln“ aus, und fügen Sie die Regel zum Aktivieren der empfohlenen Einstellungen hinzu, bzw. bearbeiten Sie sie.

Weitere Informationen finden Sie unter Datenbankinstanz – DBHAEnableLBPorts (Aktivieren von HA-Ports im Azure Load Balancer für HANA DB im HA-Setup in SAP-Workloads).

Deaktivieren von TCP-Zeitstempeln auf virtuellen Computern, die im HANA DB-Hochverfügbarkeitssetup in SAP-Workloads hinter Azure Load Balancer platziert werden

Deaktivieren Sie TCP-Zeitstempel auf virtuellen Computern, die sich hinter Azure Load Balancer befinden. Aktivierte TCP-Zeitstempel führen dazu, dass Integritätstests fehlschlagen, weil TCP-Pakete vom TCP-Stapel des VM-Gastbetriebssystems verworfen werden. Die verworfenen TCP-Pakete können dazu führen, dass der Lastenausgleich den Endpunkt als ausgefallen markiert.

Weitere Informationen finden Sie unter Datenbankinstanz – DBLBHADisableTCP (TCP-Zeitstempel auf VMs deaktivieren, die hinter dem Azure Load Balancer in HANA DB HA-Setup in SAP-Workloads platziert wurden).

In der Pacemaker-Konfiguration für das HANA DB-Hochverfügbarkeitssetup muss eine Instanz von „fence_azure_arm“ vorhanden sein.

Der „fence_azure_arm“ ist ein E/A-Fencing-Agent für Azure Resource Manager. Stellen Sie sicher, dass in der Pacemaker-Konfiguration für das HANA DB-Hochverfügbarkeitssetup genau eine Instanz von „fence_azure_arm“ vorhanden ist. Die „fence_azure_arm“ ist erforderlich, wenn Sie Azure-Fence-Agent für das Fencing mit verwalteter Identität oder Dienstprinzipal verwenden.

Weitere Informationen finden Sie unter Datenbankinstanz – FenceAzureArmSuseHDB (Es sollte nur eine Instanz von „fence_azure_arm“ in der Pacemaker-Konfiguration für das HANA DB-Hochverfügbarkeitssetup vorhanden sein).

Storage

Aktivieren des vorläufigen Löschens für Ihre Recovery Services-Tresore

Mit der Option des vorläufigem Löschens können Sie Ihre Sicherungsdaten im Tresor der Wiederherstellungsdienste für eine zusätzliche Dauer nach dem Löschen aufbewahren. Die zusätzliche Dauer bietet Ihnen die Möglichkeit, die Daten abzurufen, bevor sie endgültig gelöscht wird.

Weitere Informationen finden Sie unter Recovery Services-Tresor: AB-SoftDeleteRsv (Aktivieren des vorläufigen Löschens für Ihre Recovery Services-Tresore).

Aktivieren der regionsübergreifenden Wiederherstellung für Ihren Recovery Services-Tresor

Aktivieren der regionsübergreifenden Wiederherstellung für Ihre georedundanten Tresore.

Weitere Informationen finden Sie unter Recovery Services Vault: CRR Aktivieren (Aktivieren der regionsübergreifenden Wiederherstellung für Ihren Recovery Services Vault).

Aktivieren von Sicherungen auf virtuellen Computern

Aktivieren Sie Sicherungen für Ihre virtuellen Computer, und schützen Sie Ihre Daten.

Weitere Informationen finden Sie unter VM (klassisch): EnableBackup (Aktivieren von Sicherungen auf VMs).

Konfigurieren einer Blobsicherung

Konfigurieren Sie die Blobsicherung.

Weitere Informationen finden Sie unter Speicherkonto – ConfigureBlobBackup (Blob-Sicherungskopie konfigurieren).

Aktivieren Sie Azure Backup, um einfachen, zuverlässigen und kostengünstigen Schutz für Ihre Daten zu erhalten.

Schützen Sie Ihre Daten und Anwendungen mit der robusten Ein-Klick-Sicherung von Azure. Aktivieren Sie Azure Backup, um einen kostengünstigen Schutz für eine Vielzahl von Workloads wie VMs, SQL-Datenbanken, Anwendungen und Dateifreigaben zu erhalten.

Weitere Informationen finden Sie unter Abonnement – AzureBackupService (Aktivieren Sie Azure Backup, um einfachen, zuverlässigen und kostengünstigen Schutz für Ihre Daten zu erhalten).

Sie haben ADLS Gen1-Konten, die zu ADLS Gen2 migriert werden müssen

Wie bereits angekündigt, wird Azure Data Lake Storage Gen1 am. 29 Februar 2024 eingestellt. Wir empfehlen dringend, Ihren Data Lake zu Azure Data Lake Storage Gen2 zu migrieren. Azure Data Lake Storage Gen2 bietet erweiterte Funktionen für Big Data Analytics und basiert auf Azure Blob Storage.

Weitere Informationen finden Sie unter Data Lake-Speicherkonto – ADLSGen1_Deprecation (Sie verfügen über ADLS Gen1-Konten, die zu ADLS Gen2 migriert werden müssen).

Sie haben ADLS Gen1-Konten, die zu ADLS Gen2 migriert werden müssen

Wie bereits angekündigt, wird Azure Data Lake Storage Gen1 am. 29 Februar 2024 eingestellt. Es wird dringend empfohlen, Ihren Data Lake zu Azure Data Lake Storage Gen2 zu migrieren. Diese Version bietet erweiterte Funktionen, die speziell für Big Data-Analysen entwickelt wurden. Azure Data Lake Storage Gen2 baut auf Azure Blob Storage auf.

Weitere Informationen finden Sie unter Data Lake-Speicherkonto – ADLSGen1_Deprecation (Sie verfügen über ADLS Gen1-Konten, die zu ADLS Gen2 migriert werden müssen).

Aktivieren der Funktion „Vorläufiges Löschen“, um Ihre Blobdaten zu schützen

Nach dem Aktivieren des vorläufigen Löschens werden gelöschte Daten in den Status „vorläufig gelöscht“ versetzt und nicht endgültig gelöscht. Wenn Daten überschrieben werden, wird eine vorläufig gelöschte Momentaufnahme generiert, um den Zustand der überschriebenen Daten zu speichern. Sie können den Zeitraum konfigurieren, in dem vorläufig gelöschte Daten noch wiederhergestellt werden können, bevor sie dauerhaft ablaufen.

Weitere Informationen finden Sie unter Speicherkonto: StorageSoftDelete (Aktivieren der Funktion „Vorläufiges Löschen“, um Ihre Blobdaten zu schützen).

Verwenden von verwalteten Datenträgern für Speicherkonten, für die die Kapazitätsgrenze erreicht wird

Wir haben ermittelt, dass Sie nicht verwaltete SSD Premium-Datenträger in Speicherkonten nutzen, für die in Kürze die Kapazitätsgrenze für Storage Premium erreicht wird. Um beim Erreichen des Grenzwerts Fehler zu vermeiden, empfehlen wir Ihnen die Migration zu verwalteten Datenträgern, für die kein Grenzwert für die Kontokapazität besteht. Sie können diese Migration in weniger als fünf Minuten über das Portal durchführen.

Weitere Informationen finden Sie unter Speicherkonto: StoragePremiumBlobQuotaLimit (Verwenden von verwalteten Datenträgern für Speicherkonten, für die die Kapazitätsgrenze erreicht wird).

Verwenden von Azure-Datenträgern mit zonenredundantem Speicher für höhere Resilienz und Verfügbarkeit

Azure-Datenträger mit ZRS bieten eine synchrone Replikation von Daten über drei Verfügbarkeitszonen in einer Region, wodurch der Datenträger unempfindlich gegen Zonenausfälle wird und Unterbrechungen bei Anwendungen verhindert. Migrieren Sie Datenträger von LRS zu ZRS für höhere Resilienz und Verfügbarkeit.

Weitere Informationen finden Sie unter Ändern des Datenträgertyps eines von Azure verwalteten Datenträgers.

Verwenden von Managed Disks zur Erhöhung der Datenzuverlässigkeit

VMs in einer Verfügbarkeitsgruppe mit Datenträgern, die entweder Speicherkonten oder Speicherskalierungseinheiten gemeinsam nutzen, sind nicht resilient gegen Fehler einzelner Speicherskalierungseinheiten während Ausfällen. Stellen Sie mit einer Migration zu Azure Managed Disks sicher, dass die Datenträger verschiedener virtueller Computer in der Verfügbarkeitsgruppe ausreichend isoliert sind, um einen Single Point of Failure zu vermeiden.

Weitere Informationen finden Sie unter Verfügbarkeitsgruppe: ManagedDisksAvSet (Verwenden von Managed Disks zur Erhöhung der Datenzuverlässigkeit).

Implementieren von Strategien zur Notfallwiederherstellung für Ihre Azure NetApp Dateien-Ressourcen

Implementieren Sie gängige Techniken zur Notfallwiederherstellung, wie regionsübergreifende Replikation oder zonenübergreifende Replikation für Ihre Azure NetApp Files-Volumes, um Daten- oder Funktionsverluste zu vermeiden.

Weitere Informationen finden Sie unter Volume – ANFCRRCZRRecommendation (Implementieren von Notfallwiederherstellungsstrategien für Ihre Azure NetApp Files Resourcen).

Azure NetApp Files ermöglichen kontinuierliche Verfügbarkeit für SMB-Volumes

Empfehlung zur Aktivierung von SMB-Volumes für Continuous Availability.

Weitere Informationen finden Sie unter Volume – anfcaenablement (Azure NetApp Files ermöglichen kontinuierliche Verfügbarkeit für SMB-Volumes).

Überprüfen der SAP-Konfiguration auf Timeoutwerte, die mit Azure NetApp Files verwendet werden

Hochverfügbarkeit von SAP bei Verwendung mit Azure NetApp Files erfordert das Festlegen geeigneter Timeoutwerte, um Unterbrechungen Ihrer Anwendung zu verhindern. Überprüfen Sie die Dokumentation, um sicherzustellen, dass Ihre Konfiguration die in der Dokumentation beschriebenen Timeoutwerte erfüllt.

Weitere Informationen finden Sie unter Volume – SAPTimeoutsANF (Überprüfen der SAP-Konfiguration für Timeoutwerte, die mit Azure NetApp Files verwendet werden).

Web

Erwägen einer horizontalen Skalierung Ihres App Service-Plans zur Vermeidung einer Erschöpfung der CPU-Kapazität

Für Ihre App wurde in den letzten Tagen eine CPU-Auslastung von >90 % erreicht. Eine hohe CPU-Auslastung kann zu Laufzeitproblemen mit Ihren Apps führen. Um dieses Problem zu beheben, können Sie Ihre App aufskalieren.

Weitere Informationen finden Sie unter App Service: AppServiceCPUExhaustion (Erwägen einer horizontalen Skalierung Ihres App Service-Plans zur Vermeidung einer Erschöpfung der CPU-Kapazität).

Korrigieren der Sicherungsdatenbank-Einstellungen Ihrer App Service-Ressource

Bei den Sicherungen Ihrer App treten aufgrund einer ungültigen Datenbankkonfiguration ständig Fehler auf. Ausführlichere Informationen finden Sie im Sicherungsverlauf.

Weitere Informationen finden Sie unter App Service: AppServiceFixBackupDatabaseSettings (Korrigieren der Sicherungsdatenbank-Einstellungen Ihrer App Service-Ressource).

Erwägen des zentralen Hochskalierens Ihrer App Service Plan-SKU zur Vermeidung einer Erschöpfung der Arbeitsspeicherkapazität

Der App Service-Plan, der Ihre App enthält, hat einen Wert von >85 % des Arbeitsspeichers erreicht. Ein hoher Arbeitsspeicherverbrauch kann zu Laufzeitproblemen mit Ihren Apps führen. Untersuchen Sie, welche App im App Service-Plan eine Erschöpfung des Arbeitsspeichers bewirkt, und führen Sie bei Bedarf das zentrale Hochskalieren auf einen höheren Plan mit mehr Arbeitsspeicherressourcen durch.

Weitere Informationen finden Sie unter App Service: AppServiceMemoryExhaustion (Erwägen des zentralen Hochskalierens Ihrer App Service Plan-SKU zur Vermeidung einer Erschöpfung der Arbeitsspeicherkapazität).

Zentrales Hochskalieren Ihrer App Service-Ressource zum Entfernen des Kontingentlimits

Ihre App ist Teil eines gemeinsam genutzten App Service-Plans und hat ihr Kontingent mehrere Male erreicht. Sobald ein Kontingent erreicht wurde, kann Ihre Web-App keine eingehenden Anforderungen mehr akzeptieren. Führen Sie zum Entfernen des Kontingentlimits ein Upgrade auf einen Standard-Plan durch.

Weitere Informationen finden Sie unter App Service: AppServiceRemoveQuota (Hochskalieren Ihrer App Service-Ressource zum Entfernen des Kontingentlimits).

Verwenden von Bereitstellungsslots für Ihre App Service-Ressource

Sie haben Ihre Anwendung in der letzten Woche mehrmals bereitgestellt. Mit Bereitstellungsslots können Sie Änderungen verwalten und die Bereitstellungsauswirkungen auf Ihre Web-App für die Produktion verringern.

Weitere Informationen finden Sie unter App Service: AppServiceUseDeploymentSlots (Verwenden von Bereitstellungsslots für Ihre App Service-Ressource).

Korrigieren der Sicherungsspeicher-Einstellungen Ihrer App Service-Ressource

Bei den Sicherungen Ihrer App treten aufgrund von ungültigen Speichereinstellungen ständig Fehler auf. Ausführlichere Informationen finden Sie im Sicherungsverlauf.

Weitere Informationen finden Sie unter App Service: AppServiceFixBackupStorageSettings (Korrigieren der Sicherungsspeicher-Einstellungen Ihrer App Service-Ressource).

Umstellen Ihrer App Service-Ressource auf „Standard“ oder höher und Verwenden von Bereitstellungsslots

Sie haben Ihre Anwendung in der letzten Woche mehrmals bereitgestellt. Mit Bereitstellungsslots können Sie Änderungen verwalten und die Bereitstellungsauswirkungen auf Ihre Web-App für die Produktion verringern.

Weitere Informationen finden Sie unter App Service: AppServiceStandardOrHigher (Umstellen Ihrer App Service-Ressource auf „Standard“ oder höher und Verwenden von Bereitstellungsslots).

Erwägen Sie ein Hochskalieren Ihres App Service-Plans, um die Benutzerfreundlichkeit und Verfügbarkeit zu optimieren

Erwägen Sie ein Hochskalieren Ihres App Service-Plans auf mindestens zwei Instanzen, um Kaltstartverzögerungen und Dienstunterbrechungen während routinemäßiger Wartung zu vermeiden.

Weitere Informationen finden Sie unter App Service-Plan: AppServiceNumberOfInstances (Erwägen Sie ein Hochskalieren Ihres App Service-Plans, um die Benutzerfreundlichkeit und Verfügbarkeit zu optimieren.).

Der Anwendungscode muss korrigiert werden, wenn der Arbeitsprozess aufgrund einer Unhandled Exception abstürzt

Wir haben festgestellt, dass der folgende Thread zu einer nicht behandelten Ausnahme für Ihre App geführt hat, und der Anwendungscode korrigiert werden muss, um Auswirkungen auf die Anwendungsverfügbarkeit zu verhindern. Es kommt zu einem Absturz, wenn eine Ausnahme in Ihrem Code den Prozess beendet.

Weitere Informationen finden Sie unter App Service: AppServiceProactiveCrashMonitoring (Anwendungscode muss korrigiert werden, wenn der Arbeitsprozess aufgrund einer nicht behandelten Ausnahme abgestürzt ist).

Erwägen, die App Service-Konfiguration zu „64 Bit“ zu ändern

Wir haben festgestellt, dass Ihre Anwendung als 32-Bit-Anwendung ausgeführt wird und der Arbeitsspeicher das Limit von 2 GB erreicht. Erwägen Sie einen Wechsel zu 64-Bit-Prozessen, damit Sie den zusätzlichen Arbeitsspeicher nutzen können, der in Ihrer Web-Worker-Rolle verfügbar ist. Diese Aktion löst einen Neustart der Web-App aus; planen Sie diese Aktion also entsprechend.

Erfahren Sie mehr über die Einschränkungen von 32-Bit-Umgebungen für App-Services.

Aktualisieren Ihrer Azure Fluid Relay-Clientbibliothek

Sie haben vor Kurzem den Azure Fluid Relay-Dienst mit einer alten Clientbibliothek aufgerufen. Ihre Azure Fluid Relay-Clientbibliothek sollte jetzt auf die neueste Version aktualisiert werden, um sicherzustellen, dass Ihre Anwendung funktionsfähig bleibt. Durch das Upgrade werden die neuesten Funktionen sowie Verbesserungen in Bezug auf Leistung und Stabilität bereitgestellt. Weitere Informationen zu der zu verwendenden aktuellen Version und zum Upgrade finden Sie im folgenden Artikel.

Weitere Informationen finden Sie unter FluidRelay-Server: UpgradeClientLibrary (Aktualisieren Ihrer Azure Fluid Relay-Clientbibliothek).

Erwägen eines Upgrades des Hostingplans für statische Web-Apps in diesem Abonnement auf die Standard-SKU

Die von allen Static Web Apps mit Free-SKU in diesem Abonnement verwendete kombinierte Bandbreite überschreitet das monatliche Limit von 100 GB. Erwägen Sie ein Upgrade dieser Apps auf die Standard-SKU, um eine Drosselung zu vermeiden.

Weitere Informationen finden Sie unter Statische Web-App: StaticWebAppsUpgradeToStandardSKU (Erwägen Sie ein Upgrade des Hostingplans für statische Web-Apps in diesem Abonnement auf die Standard-SKU.).

Nächste Schritte

Erfahren Sie mehr über Zuverlässigkeit: Microsoft Azure Well-Architected Framework.