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.
Melden Sie sich am Azure-Portal an.
Suchen Sie auf einer beliebigen Seite nach dem Eintrag Advisor, und wählen Sie ihn aus.
Wählen Sie im Advisor-Dashboard die Registerkarte Zuverlässigkeit aus.
AgFood-Plattform
Upgrade auf die neueste Version des ADMA DotNet SDK
Wir haben Aufrufe einer ADMA DotNet-SDK-Version identifiziert, die eingestellt werden soll. Wechseln Sie zur neuesten SDK-Version, um unterbrechungsfreien Zugriff auf ADMA zu gewährleisten und die neuesten Features sowie Leistungsverbesserungen zu erhalten.
Potenzielle Vorteile: Sicherstellen des unterbrechungsfreien Zugriffs auf ADMA
Weitere Informationen finden Sie unter Was ist Azure Data Manager for Agriculture?.
Upgrade auf die neueste Version des ADMA Java SDK
Wir haben Aufrufe einer ADMA Java SDK Version identifiziert, die als veraltet eingestuft werden soll. Es wird empfohlen, auf die neueste Version des SDK umzustellen, um unterbrechungsfreien Zugriff auf ADMA, die neuesten Features und Leistungsverbesserungen sicherzustellen.
Potenzielle Vorteile: Sicherstellen des unterbrechungsfreien Zugriffs auf ADMA
Weitere Informationen finden Sie unter Was ist Azure Data Manager for Agriculture?.
Upgrade auf die neueste Version des ADMA Python SDK
Wir haben Aufrufe einer ADMA Python-SDK-Version identifiziert, die eingestellt werden soll. Wechseln Sie zur neuesten SDK-Version, um unterbrechungsfreien Zugriff auf ADMA zu gewährleisten und die neuesten Features sowie Leistungsverbesserungen zu erhalten.
Potenzielle Vorteile: Sicherstellen des unterbrechungsfreien Zugriffs auf ADMA
Weitere Informationen finden Sie unter Was ist Azure Data Manager for Agriculture?.
Upgrade auf die neueste Version des ADMA JavaScript SDK
Wir haben Aufrufe einer ADMA JavaScript-SDK-Version identifiziert, die eingestellt werden soll. Wechseln Sie zur neuesten SDK-Version, um unterbrechungsfreien Zugriff auf ADMA zu gewährleisten und die neuesten Features sowie Leistungsverbesserungen zu erhalten.
Potenzielle Vorteile: Sicherstellen des unterbrechungsfreien Zugriffs auf ADMA
Weitere Informationen finden Sie unter Was ist Azure Data Manager for Agriculture?.
API Management
Migrieren des API Management Service zur stv2-Plattform
Die Unterstützung für API Management-Instanzen, die auf der stv1-Plattform gehostet werden, wird zum 31. August 2024 eingestellt. Migrieren Sie zu einer stv2-basierten Plattform, um Dienstunterbrechungen zu vermeiden.
Potenzielle Vorteile: Verbessern der Dienststabilität und Nutzen neuer Plattformfeatures
Weitere Informationen finden Sie unter Einstellung der stv1-Plattform von API Management: globale Azure-Cloud (August 2024).
Fehler bei Rotation von Hostnamenzertifikaten
Wenn der API-Verwaltungsdienst das Hostnamen-Zertifikat aus dem Schlüsseltresor nicht aktualisiert, kann dies dazu führen, dass der Dienst ein veraltetes Zertifikat verwendet und der API-Laufzeitverkehr blockiert wird. Stellen Sie sicher, dass das Zertifikat in Schlüsseltresor vorhanden ist und dass für die Identität des API Management-Diensts der Lesezugriff für Geheimnisse gewährt wurde.
Potenzielle Vorteile: Sicherstellen der Dienstverfügbarkeit
Weitere Informationen finden Sie unter Konfigurieren eines benutzerdefinierten Domänennamens für Ihre Azure API Management-Instanz.
Das Portal der Vorversion wurde vor 3 Jahren als veraltet eingstuft und im Oktober 2023 eingestellt. Wir sehen jedoch, dass das Portal aktiv genutzt wird, was bei seiner Deaktivierung zu Dienstunterbrechungen führen kann.
Wir empfehlen Ihnen dringend, so bald wie möglich zum neuen Entwicklerportal zu migrieren, damit Sie weiterhin in den Genuss unserer Dienste kommen und die neuen Features und Verbesserungen nutzen können.
Potenzielle Vorteile: Sicherstellen der Geschäftskontinuität
Weitere Informationen finden Sie unter Migrieren zum neuen Entwicklerportal.
Fehler bei der Überprüfung des Abhängigkeitsnetzwerkstatus
Azure API Management-Dienstabhängigkeit nicht verfügbar. Überprüfen Sie die Konfiguration des virtuellen Netzwerks.
Potenzielle Vorteile: Verbessern der Dienststabilität
Weitere Informationen finden Sie unter Bereitstellen Ihrer Azure API Management-Instanz in einem virtuellen Netzwerk: externer Modus.
SSL-/TLS-Neuverhandlung blockiert
SSL/TLS-Neuverhandlungsversuch blockiert; Sichere Kommunikation schlägt möglicherweise fehl. Aktivieren Sie zur Unterstützung von Szenarien zur Clientzertifikatauthentifizierung die Option „Clientzertifikat aushandeln“ für aufgelistete Hostnamen. Bei browserbasierten Clients kann diese Option dazu führen, dass dem Client eine Zertifikatsaufforderung angezeigt wird.
Potenzielle Vorteile: Sicherstellen der Dienstverfügbarkeit
Weitere Informationen finden Sie unter Sichern von APIs mithilfe der Clientzertifikatsauthentifizierung in API Management.
Bereitstellen einer Azure API Management-Instanz für mehrere Azure-Regionen für verbesserte Serviceverfügbarkeit
Azure API Management unterstützt die Bereitstellung in mehreren Regionen. Dadurch haben API-Herausgeber die Möglichkeit, regionale API-Gateways zu einer vorhandenen API Management-Instanz hinzuzufügen. Die Bereitstellung in mehreren Regionen trägt dazu bei, die Anforderungslatenz bei geografisch verteilten API-Nutzern zu verringern, und verbessert die Serviceverfügbarkeit.
Potenzielle Vorteile: Erhöhte Resilienz gegen regionale Fehler
Weitere Informationen finden Sie unter Bereitstellen einer Azure API Management-Instanz in mehreren Azure-Regionen.
Aktivieren und konfigurieren Sie die Autoskalierung für die API Management-Instanz für Produktionsworkloads.
Die API Management-Instanz in Produktionsdienstebenen kann durch Hinzufügen und Entfernen von Einheiten skaliert werden. Die Autoskalierungsfunktion kann die Einheiten einer API Management-Instanz dynamisch an eine Änderung der Last anpassen, ohne dass manuelle Eingriffe erforderlich sind.
Potenzielle Vorteile: Steigerung der Skalierbarkeit und Kostenoptimierung.
Weitere Informationen finden Sie unter Automatisches Skalieren einer Azure API Management-Instanz.
App Service
Skalieren Sie Ihren App Service-Plan aus, um eine CPU-Erschöpfung zu vermeiden
Eine hohe CPU-Auslastung kann zu Laufzeitproblemen bei Anwendungen führen. Für Ihre Anwendung wurde in den letzten Tagen eine CPU-Auslastung von 90 % überschritten. Um die CPU-Auslastung zu reduzieren und Laufzeitprobleme zu vermeiden, können Sie die Anwendung horizontal skalieren.
Potenzielle Vorteile: Erhalten der Integrität Ihrer App
Weitere Informationen finden Sie unter Bewährte Methoden für Azure App Service.
Überprüfen von Problemen mit der Dienstintegrität für Ihre App
Wir haben eine Empfehlung im Zusammenhang mit der Dienstintegrität Ihrer App. Öffnen Sie das Azure-Portal, navigieren Sie zu der App, und klicken Sie auf „Diagnostizieren und lösen“, um weitere Details anzuzeigen.
Potenzielle Vorteile: Erhalten der Integrität Ihrer App
Weitere Informationen finden Sie unter Bewährte Methoden für Azure App Service.
Korrigieren der Sicherungsdatenbank-Einstellungen Ihrer App Service-Ressource
Wenn eine Anwendung eine ungültige Datenbankkonfiguration hat, schlagen die Sicherungen fehl. Ausführliche Informationen finden Sie im Sicherungsverlauf Ihrer Anwendung auf der App-Verwaltungsseite.
Potenzielle Vorteile: Sicherstellen der Geschäftskontinuität
Weitere Informationen finden Sie unter Bewährte Methoden für Azure App Service.
Korrigieren der Sicherungsspeicher-Einstellungen Ihrer App Service-Ressource
Wenn eine Anwendung ungültige Speichereinstellungen hat, schlagen die Sicherungen fehl. Ausführliche Informationen finden Sie im Sicherungsverlauf Ihrer Anwendung auf der App-Verwaltungsseite.
Potenzielle Vorteile: Sicherstellen der Geschäftskontinuität
Weitere Informationen finden Sie unter Bewährte Methoden für Azure App Service.
Skalieren Sie Ihren App Service-Plan hoch, um eine CPU-Erschöpfung zu vermeiden
Der App Service-Plan, der Ihre Anwendung enthält, hat den Wert von 85 % für die Speicherzuordnung erreicht. Ein hoher Arbeitsspeicherverbrauch kann zu Laufzeitproblemen bei Ihren Anwendungen führen. Ermitteln Sie die Anwendung, die Probleme bereitet, und skalieren Sie sie auf einen höheren Plan mit mehr Speicherressourcen.
Potenzielle Vorteile: Erhalten der Integrität Ihrer App
Weitere Informationen finden Sie unter Bewährte Methoden für Azure App Service.
Horizontale Skalierung Ihres App-Service-Plans
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.
Potenzielle Vorteile: Optimieren von Benutzererlebnis und Verfügbarkeit
Weitere Informationen finden Sie unter https://aka.ms/appsvcnuminstances.
Anwendungscode korrigieren, ein Workerprozess ist aufgrund einer unbehandelten Ausnahme abgestürzt
Ein Workerprozess in Ihrer Anwendung ist aufgrund einer unbehandelten Ausnahme abgestürzt. Erfassen Sie zum Ermitteln der Grundursache Speicherabbilder und Informationen zur Aufrufliste zum Zeitpunkt des Absturzes.
Potenzielle Vorteile: Erhalten der Integrität und Hochverfügbarkeit Ihrer App
Weitere Informationen finden Sie unter https://aka.ms/appsvcproactivecrashmonitoring.
Aktualisieren Sie Ihren App Service auf einen Standard-Plan, um das Ablehnen von Anfragen zu vermeiden
Wenn eine Anwendung Teil eines freigegebenen App-Service-Plans ist und das Kontingent mehrfach erreicht, werden eingehende Anforderungen möglicherweise abgelehnt. Ihre Webanwendung kann keine eingehenden Anforderungen mehr akzeptieren, wenn ein Kontingent erreicht ist. Führen Sie zum Entfernen des Kontingentlimits ein Upgrade auf einen Standard-Plan durch.
Potenzielle Vorteile: Erhalten der Integrität Ihrer App
Weitere Informationen finden Sie in der Übersicht über Azure App Service-Pläne.
Umstellen Ihrer App Service-Ressource auf „Standard“ oder höher und Verwenden von Bereitstellungsslots
Wenn eine Anwendung mehrmals in einer Woche bereitgestellt wird, können Probleme auftreten. Sie haben Ihre Anwendung letzte Woche mehrmals bereitgestellt. Um die Auswirkungen der Bereitstellung auf Ihre Produktionswebanwendung zu verringern, können Sie Ihre App Service-Ressource in den Standardplan (oder höher) verschieben und Bereitstellungsslots verwenden.
Potenzielle Vorteile: Erhalten der Integrität Ihrer App während des Updates
Weitere Informationen finden Sie unter Einrichten von Stagingumgebungen in Azure App Service.
Erwägen Sie ein Upgrade des Hostingplans für Static 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 Anwendungen auf die Standard-SKU, um eine Drosselung zu vermeiden.
Potenzielle Vorteile: Höhere Verfügbarkeit für die Apps durch Vermeiden von Drosselung.
Weitere Informationen finden Sie in der Preisübersicht für Static Web Apps .
Verwenden von Bereitstellungsslots für Ihre App Service-Ressource
Wenn eine Anwendung mehrmals in einer Woche bereitgestellt wird, können Probleme auftreten. 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.
Potenzielle Vorteile: Erhalten der Integrität Ihrer App während des Updates
Weitere Informationen finden Sie unter Einrichten von Stagingumgebungen in Azure App Service.
Erwägen Sie, Ihre Anwendungsarchitektur auf 64-Bit zu ändern.
Ihr App-Dienst ist als 32-Bit-Version konfiguriert, und der Speicherverbrauch nähert sich dem Grenzwert von 2 GB. Wenn Ihre Anwendung Folgendes unterstützt, sollten Sie die Anwendung neu kompilieren und stattdessen die App Service-Konfiguration auf 64-Bit ändern.
Potenzielle Vorteile: Verbessern der Zuverlässigkeit Ihrer Anwendung
Weitere Informationen finden Sie unter Häufig gestellte Fragen zur Anwendungsleistung von Web-Apps in Azure.
Personalisierte Empfehlung für CX Observer
Personalisierte Empfehlung für CX Observer
Potenzielle Vorteile: NA
App Service Certificate
Domain-Verifizierung für die Ausstellung Ihres App Service Certificate erforderlich
Sie verfügen über ein App Service Certificate, das sich derzeit im Status "Ausstellung steht aus" befindet und eine Domänenüberprüfung erfordert. Eine fehlgeschlagene Überprüfung des Domänenbesitzes führt zu einer erfolglosen Zertifikatausstellung. Die Domänenüberprüfung ist für App Service Certificates nicht automatisiert und erfordert Handeln. Wenn Sie vor kurzem den Besitz der Domain verifiziert haben und ein Zertifikat erhalten haben, können Sie diese Meldung ignorieren.
Potenzielle Vorteile: Sicherstellen, dass das App-Dienstzertifikat erfolgreich ausgestellt wird.
Weitere Informationen finden Sie unter Hinzufügen und Verwalten eines TLS-/SSL-Zertifikats in Azure App Service.
Application Gateway
Aktualisieren Sie Ihre SKU oder fügen Sie weitere Instanzen hinzu
Mit der Bereitstellung von mindestens zwei mittelgroßen oder großen Instanzen wird die Geschäftskontinuität (Fehlertoleranz) bei Ausfällen sichergestellt, zu denen es aufgrund von geplanten oder ungeplanten Wartungsmaßnahmen kommt.
Potenzielle Vorteile: Sicherstellen von Geschäftskontinuität durch Resilienz des Anwendungsgateways
Weitere Informationen finden Sie unter Lastenausgleich für mehrere Regionen: Azure-Referenzarchitekturen .
Vermeiden der Außerkraftsetzung des Hostnamens zur Sicherstellung der Websiteintegrität
Vermeiden Sie bei der Application Gateway-Konfiguration die Außerkraftsetzung des Hostnamens. 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 zur Beschädigung von Cookies oder Umleitungs-URLs führen. 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. Beachten Sie, dass eine andere Front-End-Domäne nicht immer ein Problem ist und bestimmte Kategorien von Back-Ends wie REST-APIs generell weniger anfällig sind.
Potenzielle Vorteile: Sicherstellen der Websiteintegrität und Vermeiden der Beschädigung von Cookies oder Umleitungs-URLs durch eine resiliente Application Gateway-Konfiguration.
Weitere Informationen finden Sie unter Behandeln von App Service-Problemen in Application Gateway.
Implementieren von ExpressRoute-Monitor im Netzwerkleistungsmonitor
Wenn die ExpressRoute-Verbindung von ExpressRoute-Monitor nicht hinsichtlich der Netzwerkleistung überwacht wird, erhalten Sie keine Benachrichtigungen über Verluste, Wartezeiten und Leistung zwischen lokalen Ressourcen und Azure-Ressourcen sowie zwischen Azure-Ressourcen und lokalen Ressourcen. Implementieren Sie ExpressRoute-Monitor in der Netzwerkleistung für eine durchgängige Überwachung.
Potenzielle Vorteile: Schnelleres Erkennen und Beheben von Problemen in Ihrem Netzwerk und Gewinnen von Erkenntnissen zu Ihrem Netzwerkpfad per ExpressRoute
Weitere Informationen finden Sie unter Konfigurieren des Netzwerkleistungsmonitors für ExpressRoute (veraltet).
Implementieren mehrerer ExpressRoute-Leitungen in Ihrem virtuellen Netzwerk zur Erzielung von standortübergreifender Resilienz
Wenn einem ExpressRoute-Gateway nur eine ExpressRoute-Leitung zugeordnet ist, können Probleme mit der Resilienz auftreten. Verbinden Sie mindestens eine weitere Leitung mit dem Gateway, um die Redundanz und Resilienz des Peeringstandorts zu gewährleisten.
Potenzielle Vorteile: Verbessern der Resilienz bei einem Ausfall des ExpressRoute-Peeringstandorts
Weitere Informationen finden Sie unter Entwurf für Hochverfügbarkeit mit ExpressRoute.
Hinzufügen von mindestens einem weiteren Endpunkt zum Profil, vorzugsweise in einer anderen Azure-Region
Profile benötigen 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.
Potenzielle Vorteile: Verbesserte Resilienz durch das Zulassen eines Failovers
Weitere Informationen finden Sie unter Traffic Manager-Endpunkte.
Hinzufügen eines für „Alle (Welt)“ konfigurierten Endpunkts
Beim geografischen Routing wird der Datenverkehr an Endpunkte in definierten Regionen weitergeleitet. Wenn 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 dadurch Dienstverfügbarkeit gewährleistet.
Potenzielle Vorteile: Verbesserte Resilienz durch das Vermeiden von „schwarzen Löchern“ im Datenverkehr
Weitere Informationen finden Sie unter Hinzufügen, Deaktivieren, Aktivieren, Löschen oder Verschieben von Endpunkten.
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 eine höhere Verfügbarkeit, wenn alle Endpunkte in einer Region ausfallen.
Potenzielle Vorteile: Verbesserte Resilienz durch das Zulassen eines Failovers auf eine andere Region
Weitere Informationen finden Sie unter Konfigurieren der leistungsorientierten Routingmethode für Datenverkehr.
Umstellen von Basic-Gateways auf Gateway-SKUs für die Produktion
Die Basic-VPN-SKU ist für Entwicklungs- oder Testszenarien gedacht. Wenn Sie das VPN-Gateway für die Produktion nutzen, sollten Sie zu einer Produktions-SKU wechseln. Diese bietet eine höhere Anzahl von Tunneln, Border Gateway Protocol (BGP), eine Aktiv-Aktiv-Konfiguration, eine benutzerdefinierte IPsec/IKE-Richtlinie und erhöhte Stabilität und Verfügbarkeit.
Potenzielle Vorteile: Zusätzlich verfügbare Features und höhere Stabilität und Verfügbarkeit
Weitere Informationen finden Sie unter Informationen zu VPN Gateway-Einstellungen.
Aktivieren von Aktiv/Aktiv-Gateways für Redundanz
In der Aktiv-Aktiv-Konfiguration richten beide Instanzen des VPN-Gateways S2S-VPN-Tunnel (Site-to-Site) 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.
Potenzielle Vorteile: Gewährleistung von Geschäftskontinuität durch Verbindungsresilienz
Weitere Informationen finden Sie unter Entwerfen hochverfügbarer Gatewaykonnektivität für standortübergreifende Verbindungen und VNet-zu-VNet-Verbindungen.
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 sind Integritätstests nicht hilfreich.
Potenzielle Vorteile: Sicherstellen der Dienstverfügbarkeit durch Verringerung von unnötigem Integritätstestdatenverkehr
Weitere Informationen finden Sie unter Bewährte Methoden für Front Door.
Verwenden von verwalteten TLS-Zertifikaten
Wenn 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. Azure Front Door übernimmt die automatische Ausstellung und Ritation verwalteter TLS-Zertifikate.
Potenzielle Vorteile: Sicherstellen der Dienstverfügbarkeit durch Verwalten und Rotieren Ihrer Zertifikate durch Front Door
Weitere Informationen finden Sie unter Bewährte Methoden für Front Door.
Verwenden eines NAT-Gateways für ausgehende Konnektivität
Verhindern Sie Verbindungsausfälle aufgrund der Erschöpfung von SNAT-Ports (Source Network Address Translation), indem Sie ein NAT-Gateway für den ausgehenden Datenverkehr der virtuellen Netzwerke verwenden. NAT-Gateway wird dynamisch skaliert und bietet sichere Verbindungen für den Internet-Datenverkehr.
Potenzielle Vorteile: Verhindern von Fehlern bei ausgehenden Verbindungen mit NAT Gateway
Weitere Informationen finden Sie unter Verwenden der Quell-Netzwerkadressenübersetzung (Source Network Address Translation, SNAT) für ausgehende Verbindungen.
Bereitstellen Ihrer Application Gateway über Verfügbarkeitszonen
Erzielen Sie Zonenredundanz, indem Sie Application Gateway über Verfügbarkeitszonen hinweg bereitstellen. Die Zonenredundanz erhöht die Resilienz, indem das Application Gateway verschiedene Ausfälle überleben kann, wodurch die Kontinuität auch dann gewährleistet wird, wenn eine Zone betroffen ist, und die Gesamtzulässigkeit verbessert wird.
Potenzielle Vorteile: Deutliche Steigerung der Resilienz von Anwendungsgateways bei Verwendung von Verfügbarkeitszonen.
Weitere Informationen finden Sie unter Skalierung von Application Gateway v2 und WAF v2.
Aktualisieren der VNet-Berechtigung von Application Gateway-Benutzern
Um die Sicherheit zu verbessern und eine einheitlichere Erfahrung in Azure bereitzustellen, müssen alle Benutzer eine Berechtigungsprüfung bestehen, um eine Application Gateway-Instanz in einem Virtual Network zu erstellen oder zu aktualisieren. Die Mindestberechtigung der Benutzer oder Dienstprinzipale ist „Microsoft.Network/virtualNetworks/subnets/join/action“.
Potenzielle Vorteile: Vermeiden von Unterbrechungen bei der Verwaltung der Application Gateway-Ressource
Weitere Informationen finden Sie unter Konfiguration der Application Gateway-Infrastruktur.
Verwenden desselben Domänennamens auf Frontdoor und auf Ihrem Ursprung
Wenn Sie den Hostheader neu schreiben, kann es vorkommen, dass Anforderungscookies und URL-Umleitungen nicht mehr funktionieren. Wenn Sie Plattformen wie Azure App Service verwenden, funktionieren Features wie Sitzungsaffinität und Authentifizierung und Autorisierung möglicherweise nicht ordnungsgemäß. Überprüfen Sie, ob Ihre Anwendung ordnungsgemäß funktioniert.
Potenzielle Vorteile: Sicherstellen der Anwendungsintegrität durch Beibehaltung des ursprünglichen Hostnamens
Weitere Informationen finden Sie unter Bewährte Methoden für Front Door.
Implementieren der Resilienz von Standorten für ExpressRoute
Um maximale Resilienz zu gewährleisten, empfiehlt Microsoft, dass Sie sich mit zwei ExpressRoute-Schaltungen an zwei Peering-Standorten verbinden. Ziel der maximaler Resilienz ist es, die Verfügbarkeit zu verbessern und die höchste Resilienz für kritische Workloads sicherzustellen.
Potenzielle Vorteile: Durch die maximale Resilienz in ExpressRoute soll sichergestellt werden, dass es keinen Single Point of Failure innerhalb des Microsoft-Netzwerkpfads gibt. Dies wird erreicht, indem zwei (2) Schaltkreise an zwei verschiedenen Standorten für die Standortvielfalt in ExpressRoute angeboten werden. Ziel der maximaler Resilienz ist es, die Verfügbarkeit zu verbessern und die höchste Resilienz für kritische Workloads sicherzustellen.
Weitere Informationen finden Sie unter Entwerfen und Ausrichten von Azure ExpressRoute für Resilienz.
Implementieren Sie Zonenredundante ExpressRoute-Gateways
Implementieren Sie zonenredundante Gateways für das virtuelle Netzwerk in Azure-Verfügbarkeitszonen. So erzielen Sie Resilienz, Skalierbarkeit und eine höhere Verfügbarkeit für Ihre Gateways des virtuellen Netzwerks.
Potenzielle Vorteile: Bietet zonale Resilienz und Redundanz für ExpressRoute
Weitere Informationen finden Sie unter Erstellen zonenredundanter Gateways für das virtuelle Netzwerk in Verfügbarkeitszonen.
Sicherstellen, dass die automatische Skalierung für erhöhte Leistung und Resilienz verwendet wird
Beim Konfigurieren von Application Gateway empfiehlt es sich, eine automatische Skalierung bereitzustellen, um durch Ab- und Aufskalieren auf Bedarfsänderungen zu reagieren. Das trägt dazu bei, die Auswirkungen einer einzelnen fehlerhaften Komponente zu minimieren.
Potenzielle Vorteile: Leistungs- und Resilienzsteigerung.
Weitere Informationen finden Sie unter Skalierung von Application Gateway v2 und WAF v2.
ExpressRoute-IP-Routen in der Nähe des angegebenen Grenzwerts
Ihr ExpressRoute-Schaltkreis ist nahe bei der Erreichung seiner IP-Routengrenzwerte. Wenn diese Grenzwerte überschritten werden, wird die Verbindung unterbrochen. Die Konnektivität wird wiederhergestellt, sobald Routen innerhalb von Grenzwerten liegen Vorschläge: Überwachen Sie die Routenanzahl regelmäßig. Erkunden Sie Virtual WAN RouteMap, um angekündigte IP-Routen zu reduzieren.
Potenzielle Vorteile: Die Überwachungs-IP-Route verhindert Konnektivitätsprobleme und sorgt für Stabilität.
Weitere Informationen finden Sie unter Virtual WAN – Häufig gestellte Fragen.
Vermeiden der Platzierung von Traffic Manager hinter Front Door
Die Verwendung von Traffic Manager als einer der Ursprünge für Front Door wird nicht empfohlen, da dies zu Routingproblemen führen kann. Wenn Sie beide Dienste in einer Hochverfügbarkeitsarchitektur benötigen, platzieren Sie Traffic Manager immer vor Azure Front Door.
Potenzielle Vorteile: Steigerung der Resilienz von Workloads
Weitere Informationen finden Sie unter Bewährte Methoden für Front Door.
Erwägen von mindestens zwei Ursprüngen
Mehrere Ursprünge unterstützen Redundanz, indem Datenverkehr über mehrere Instanzen der Anwendung verteilt wird. Wenn eine Instanz nicht verfügbar ist, können andere Back-End-Ursprünge weiterhin Datenverkehr empfangen.
Potenzielle Vorteile: Steigerung der Resilienz von Workloads
Weitere Informationen finden Sie unter Azure Well-Architected Framework-Perspektive auf Azure Front Door.
Ändern des Subnetzes des V1-Gateways mit dem Namen „GatewaySubnet“, da es für VPN/Express Route reserviert ist
Es besteht die Gefahr, dass Ihr Application Gateway nach Oktober 2024 aufgrund eines fehlgeschlagenen internen Upgrades gelöscht wird. Dies ist auf Subnetz mit dem Namen Gatewaysubnet zurückzuführen, das für VPN/ExpressRoute reserviert ist. Um dies zu beheben, ändern Sie bitte das Subnetz oder migrieren Sie zu V2. Es dauert einen Tag, bis die Nachricht verschwindet, sobald sie behoben ist
Potenzielle Vorteile: Vermeiden von Unterbrechungen bei der Verwaltung der Application Gateway V1-Ressource
Weitere Informationen finden Sie in den häufig gestellten Fragen zu Application Gateway.
Ändern des Subnetzes des V1-Gateways, da das aktuelle Subnetz ein NAT-Gateway enthält
Ihr Application Gateway kann aufgrund eines fehlgeschlagenen internen Upgrades nach Oktober 2024 gelöscht werden. Dies liegt daran, dass ein dediziertes Subnetz fehlt und ein NAT-Gateway enthält. Ändern Sie zum Auflösen entweder das Subnetz, entfernen Sie das NAT-Gateway oder migrieren Sie zu V2. Es dauert einen Tag, bis die Nachricht verschwindet, sobald sie behoben ist
Potenzielle Vorteile: Vermeiden von Unterbrechungen bei der Verwaltung der Application Gateway V1-Ressource
Weitere Informationen finden Sie in den häufig gestellten Fragen zu Application Gateway.
Reaktivieren des Abonnements zum Freigeben des internen Upgrades für das V1-Gateway
Es besteht die Gefahr, dass Ihr Application Gateway nach Oktober 2024 aufgrund eines fehlgeschlagenen internen Upgrades gelöscht wird. Dies liegt daran, dass sich das Abonnement in einem nicht aktiven Zustand befindet. Um dies zu beheben, aktivieren Sie das Abonnement. Nachdem das Problem behoben wurde, kann es einen Tag dauern, bis diese Meldung verschwindet.
Potenzielle Vorteile: Vermeiden von Unterbrechungen bei der Verwaltung der Application Gateway V1-Ressource
Weitere Informationen finden Sie unter Reaktivieren eines deaktivierten Azure-Abonnements.
Application Gateway für Container
Zu einer unterstützten AGC-Version migrieren.
Die Version von Application Gateway für Container wurde mit einer Vorschauversion bereitgestellt und wird für die Produktion nicht unterstützt. Achten Sie darauf, ein neues Gateway mit der aktuellen API-Version bereitzustellen.
Potenzielle Vorteile: Sicherstellen der Unterstützbarkeit und Resilienz für Produktionsworkloads
Weitere Informationen finden Sie unter Was ist Application Gateway für Container?.
Azure KI Search
Erstellen eines Standard-Suchdiensts (2 GB)
Wenn Ihr Speicherkontingent überschritten wird, funktionieren Indizierungsvorgänge nicht mehr. Sie sind kurz davor, Ihr Speicherkontingent von 2 GB zu überschreiten. Wenn Sie mehr Speicherplatz benötigen, erstellen Sie einen Standard-Suchdienst, oder fügen Sie zusätzliche Partitionen hinzu.
Potenzielle Vorteile: Fähigkeit zum Verarbeiten von mehr Daten
Weitere Informationen finden Sie unter https://aka.ms/azs/search-limits-quotas-capacity.
Erstellen eines Standard-Suchdiensts (50 MB)
Wenn Sie Ihr Speicherkontingent überschritten haben, funktionieren Indizierungsvorgänge funktionieren nicht mehr. Sie sind kurz davor, Ihr Speicherkontingent von 50 MB zu überschreiten. Erstellen Sie zum Aufrechterhalten des Betriebs einen Basic- oder Standard-Suchdienst.
Potenzielle Vorteile: Fähigkeit zum Verarbeiten von mehr Daten
Weitere Informationen finden Sie unter https://aka.ms/azs/search-limits-quotas-capacity.
Vermeiden der Überschreitung Ihres verfügbaren Speicherkontingents durch Hinzufügen weiterer Partitionen
Wenn Sie Ihr Speicherkontingent überschritten haben, sind Abfragen weiterhin möglich, aber Indizierungsvorgänge funktionieren nicht mehr. Sie sind kurz davon, Ihr verfügbares Speicherkontingent zu überschreiten. Fügen Sie weitere Partitionen hinzu, wenn Sie mehr Speicher brauchen.
Potenzielle Vorteile: Möglichkeit zur Indizierung weiterer Daten
Weitere Informationen finden Sie unter https://aka.ms/azs/search-limits-quotas-capacity.
Azure Arc-fähiges Kubernetes
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.
Potenzielle Vorteile: Neueste Agent-Version von K8s mit Arc-Unterstützung
Weitere Informationen finden Sie unter Upgraden von Azure Arc-fähigen Kubernetes-Agents.
Konfiguration von Kubernetes mit Azure Arc-Unterstützung
Aktualisieren der Microsoft Flux-Erweiterung auf die neueste Hauptversion
Die Microsoft Flux-Erweiterung hat eine neue Hauptversion veröffentlicht. Planen Sie für alle Kubernetes-Cluster mit Azure Arc-Unterstützung und für alle AKS-Cluster (Azure Kubernetes Service) mit Azure Arc-Unterstützung innerhalb der nächsten sechs Monate ein manuelles Upgrade auf die neueste Hauptversion von Microsoft Flux ein, um weiterhin Support und neue Funktionen zu erhalten.
Potenzielle Vorteile: Fortgesetzte Unterstützung und neue Funktionen
Weitere Informationen finden Sie unter Verfügbare Erweiterungen für Kubernetes-Cluster mit Azure Arc-Unterstützung.
Bevorstehende Breaking Changes für die Microsoft Flux-Erweiterung
Die Microsoft Flux-Erweiterung erhält häufig Sicherheits- und Stabilitätsupdates. Das bevorstehende Update gemäß OSS-Flux-Projekt wird die HelmRelease- und HelmChart-APIs ändern, indem veraltete Felder entfernt werden. Um Unterbrechungen ihrer Workloads zu vermeiden, werden erforderliche Aktionen benötigt.
Potenzielle Vorteile: Verbesserte Stabilität, Sicherheit und neue Funktionalität
Weitere Informationen finden Sie unter Verfügbare Erweiterungen für Kubernetes-Cluster mit Azure Arc-Unterstützung.
Aktualisieren Sie die Microsoft Flux-Erweiterung auf eine unterstützte Version
Die aktuelle Version von Microsoft Flux auf einem oder mehreren Azure Arc-aktivierten Clustern und Azure Kubernetes-Clustern wird nicht mehr unterstützt. Um Sicherheitsupdates, Programmfehlerbehebungen und Microsoft-Support zu erhalten, aktualisieren Sie auf eine unterstützte Version.
Potenzielle Vorteile: Erhalten von Sicherheitspatches, Fehlerbehebungen und Microsoft-Support
Weitere Informationen finden Sie unter Verfügbare Erweiterungen für Kubernetes-Cluster mit Azure Arc-Unterstützung.
Server mit Azure Arc-Unterstützung
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 Azure Arc bestmöglich nutzen zu können.
Potenzielle Vorteile: Verbesserte Stabilität und neue Funktionalität
Weitere Informationen finden Sie unter Verwalten des Connected Machine-Agent.
Azure Cache for Redis
Erhöhen der Speicherreservierung für die Fragmentierung
Fragmentierung und hohe Speicherauslastung können zu Verfügbarkeitsvorfällen führen. Um Cachefehler bei der Ausführung unter hoher Speicherauslastung zu reduzieren, erhöhen Sie die Speicherreservierung für die Fragmentierung über die Einstellung „maxfragmentationmemory-reserved“, die in den erweiterten Einstellungsoptionen verfügbar ist.
Potenzielle Vorteile: Vermeiden von Verfügbarkeitsproblemen bei hoher Speicherfragmentierung des Caches
Weitere Informationen finden Sie unter Konfigurieren von Azure Cache for Redis.
Konfigurieren der Georeplikation für Cache for Redis-Instanzen zur Erhöhung der Dauerhaftigkeit von Anwendungen
Die Georeplikation ermöglicht die Notfallwiederherstellung für zwischengespeicherte Daten, selbst im unwahrscheinlichen Fall eines großflächigen Ausfalls in einer Region. Dies kann für unternehmenskritische Anwendungen extrem wichtig sein. Es wird empfohlen, die passive Georeplikation für Premium-Azure Cache for Redis-Instanzen zu konfigurieren.
Potenzielle Vorteile: Georeplikation ermöglicht die Notfallwiederherstellung für zwischengespeicherte Daten.
Weitere Informationen finden Sie unter Konfigurieren der Georeplikation für Azure Cache for Redis-Instanzen (Premium-Tarif).
Azure Container Apps
Erstellen Sie Ihre Container Apps-Umgebung neu, um DNS-Probleme zu vermeiden
Es gibt ein potenzielles Netzwerkproblem mit Ihren Container Apps-Umgebungen, das DNS-Probleme hervorrufen könnte. Wir empfehlen Ihnen, eine Container Apps-Umgebung zu erstellen, Ihre Container Apps in der neuen Umgebung neu einzurichten und die alte Container Apps-Umgebung zu löschen.
Potenzielle Vorteile: Vermeiden von DNS-Fehlern in Ihrer Container Apps-Umgebung.
Weitere Informationen finden Sie unter Schnellstart: Bereitstellen Ihrer ersten Container-App über das Azure-Portal.
Verlängern des benutzerdefinierten Domänenzertifikats
Das von Ihnen hochgeladene benutzerdefinierte Domänenzertifikat läuft bald ab. Verlängern Sie Ihr Zertifikat, und laden Sie das neue Zertifikat für Ihre Container-Apps hoch, um eine mögliche Dienstdowntime zu verhindern.
Potenzielle Vorteile: Ihr Dienst wird aufgrund eines abgelaufenen Zertifikats nicht fehlschlagen.
Weitere Informationen finden Sie unter Benutzerdefinierte Domänennamen und Verwenden eigener Zertifikate (Bring Your Own Certificate, BYOC) in Azure Container Apps.
Es wurde ein Problem erkannt, das die Verlängerung Ihres verwalteten Zertifikats verhindert.
Wir haben festgestellt, dass das von der Container-App verwendete verwaltete Zertifikat nicht automatisch verlängert wurde. Folgen Sie dem Dokumentationslink, um sicherzustellen, dass die DNS-Einstellungen Ihrer benutzerdefinierten Domäne korrekt sind.
Potenzielle Vorteile: Vermeiden von Ausfallzeiten aufgrund eines abgelaufenen Zertifikats.
Weitere Informationen finden Sie unter Benutzerdefinierte Domänennamen und kostenlose verwaltete Zertifikate in Azure Container Apps.
Erhöhen der minimalen Replikatanzahl für Ihre containerisierte Anwendung
Die minimale Replikatanzahl für Ihre containerisierte Azure Container App-Anwendung ist möglicherweise zu niedrig. Das kann Probleme mit der Resilienz, der Skalierbarkeit und dem Lastenausgleich verursachen. Erhöhen Sie die minimale Replikatanzahl, um eine bessere Verfügbarkeit zu erzielen.
Potenzielle Vorteile: Bessere Verfügbarkeit für Ihre Container-App.
Weitere Informationen finden Sie unter Festlegen von Skalierungsregeln in Azure Container Apps.
Azure Cosmos DB
Konfigurieren Sie Azure Cosmos DB-Containers mit einem Partitionsschlüssel
Wenn nicht partitionierte Azure Cosmos DB-Sammlungen ihr bereitgestelltes Speicherkontingent erreichen, verlieren Sie die Möglichkeit, Daten hinzuzufügen. Ihre nicht partitionierten Cosmos DB-Sammlungen haben ihr bereitgestelltes Speicherkontingent nahezu erschöpft. Migrieren Sie diese Sammlungen zu neuen Sammlungen mit einer Partitionsschlüsseldefinition, um das automatische horizontale Skalieren durch den Dienst zu ermöglichen.
Potenzielle Vorteile: Skalieren Sie Ihre Container nahtlos mit erhöhten Speicher- oder Anforderungsraten, ohne auf Grenzwerte zu stoßen.
Weitere Informationen finden Sie unter Partitionieren und horizontales Skalieren in Azure Cosmos DB.
Verwenden Sie statische Cosmos DB-Clientinstanzen in Ihrem Code und führen Sie eine Zwischenspeicherung der Namen von Datenbanken und Sammlungen durch.
Eine hohe Anzahl von Metadatenvorgängen auf einem Konto kann zu einer Ratenbegrenzung führen. Für Metadatenvorgänge gilt ein Limit in Bezug auf vom System reservierte Anforderungseinheiten (Request Units, RUs). Vermeiden Sie ein Ratenlimit für Metadatenvorgänge, indem Sie statische Cosmos DB-Clientinstanzen in Ihrem Code verwenden und die Namen von Datenbanken und Sammlungen zwischenspeichern.
Potenzielle Vorteile: Optimieren Ihrer RU-Nutzung und Vermeiden von Ratenbegrenzung
Weitere Informationen finden Sie unter Leistungstipps für Azure Cosmos DB und .NET SDK v2.
Überprüfen Sie den verknüpften Azure Key Vault, der Ihren Schlüssel hostet
Wenn ein Azure Cosmos DB-Konto auf den zugehörigen verknüpften Azure Key Vault mit dem Verschlüsselungsschlüssel nicht zugreifen kann, können Datenzugriffs- und Sicherheitsprobleme auftreten. Die Konfiguration Ihres Azure Key Vault verhindert, dass von Ihrem 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, müssen Sie sicherstellen, dass der vorherige Schlüssel bzw. die Schlüsselversion aktiviert bleibt und so lange verfügbar ist, bis 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.
Potenzielle Vorteile: Aktualisieren Ihrer Konfigurationen, um weiterhin kundenseitig verwaltete Schlüssel verwenden und auf Ihre Daten zugreifen zu können
Weitere Informationen finden Sie unter Konfigurieren von kundenseitig verwalteten Schlüsseln für Ihr Azure Cosmos DB-Konto mit Azure Key Vault.
Konfigurieren eines konsistenten Indizierungsmodus für Azure Cosmos DB-Container
Azure Cosmos-Container, die mit dem verzögerten Indizierungsmodus konfiguriert sind, werden asynchron aktualisiert, wodurch die Schreibleistung verbessert wird, sich jedoch auf die Aktualität der Abfrage auswirken kann. Ihr Container ist mit dem verzögerten Indizierungsmodus konfiguriert. Wenn die Aktualität der Abfrage kritisch ist, verwenden Sie den konsistenten Indizierungsmodus für sofortige Indexaktualisierungen.
Potenzielle Vorteile: Verbesserte Abfrageergebniskonsistenz und -zuverlässigkeit
Weitere Informationen finden Sie unter Verwalten von Indizierungsrichtlinien in Azure Cosmos DB.
Hotfix - Upgrade auf Version 2.6.14 des Async Java SDK v2 oder auf Java SDK v4
Bis Version 2.6.13 des Async Java-SDK v2 von Azure Cosmos DB 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. Im Dienst ist dieser Fehler für Sie sichtbar, nachdem während der Lebensdauer eines Azure Cosmos DB-Containers eine große Menge von Transaktionen aufgetreten ist. Hinweis: Wenngleich dies ein kritischer Hotfix für das Async Java-SDK v2 ist, sollten Sie trotzdem unbedingt zum Java-SDK v4 migrieren.
Potenzielle Vorteile: Wenn keine entsprechenden Maßnahmen ergriffen werden, treten ggf. für alle Erstellungs-, Lese-, Aktualisierungs- und Löschvorgänge Fehler vom Typ „NumberFormatException“ auf.
Weitere Informationen finden Sie unter Azure Cosmos DB Async Java SDK für die API für NoSQL (Legacy): Versionshinweise und Ressourcen.
Kritisches Problem – Upgraden auf die aktuelle empfohlene Version des Java-SDK v4
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. Im Dienst ist dies für Sie sichtbar, nachdem während der Lebensdauer eines Azure Cosmos DB-Containers eine große Menge von Transaktionen aufgetreten ist. Vermeiden Sie dieses Problem, indem Sie auf die aktuelle empfohlene Version des Java-SDK v4 upgraden.
Potenzielle Vorteile: Wenn keine entsprechenden Maßnahmen ergriffen werden, treten ggf. für alle Erstellungs-, Lese-, Aktualisierungs- und Löschvorgänge Fehler vom Typ „NumberFormatException“ auf.
Weitere Informationen finden Sie unter Azure Cosmos DB Java SDK v4 für die API für NoSQL: Versionshinweise und Ressourcen.
Verwenden Sie den neuen 3.6+-Endpunkt, um eine Verbindung mit der aktualisierten Azure Cosmos DB-API für das MongoDB-Konto herzustellen.
Einige Ihrer Anwendungen stellen über den Legacyendpunkt 3.2 ([Kontoname].documents.azure.com) eine Verbindung mit der aktualisierten Azure Cosmos DB-API für das MongoDB-Konto her. Verwenden Sie den neuen Endpunkt „[Kontoname].mongo.cosmos.azure.com“ (oder dessen Entsprechung in Sovereign Clouds, Clouds für Behörden oder eingeschränkten Clouds).
Potenzielle Vorteile: Nutzen der neuesten Features in Version 3.6+ der Azure Cosmos DB-API für MongoDB
Weitere Informationen finden Sie unter Azure Cosmos DB for MongoDB (Serverversion 4.0): unterstützte Features und Syntax.
Upgraden Ihrer Azure Cosmos DB-API für das MongoDB-Konto auf die Version 4.2, um Abfrage-/Speicherkosten zu sparen und neue Features zu nutzen
Ihre Azure Cosmos DB-API für das MongoDB-Konto kann auf die Version 4.2 aktualisiert werden. Dank eines neuen Speicherformats können Sie durch das Upgrade auf die Version 4.2 Ihre Speicherkosten um bis zu 55 Prozent und Ihre Abfragekosten um bis zu 45 Prozent senken. Die Version 4.2 enthält zudem zahlreiche zusätzliche Features wie etwa Transaktionen mit mehreren Dokumenten.
Potenzielle Vorteile: Verbesserte Zuverlässigkeit, Abfrage-/Speichereffizienz und Leistung sowie neue Funktionen
Weitere Informationen finden Sie unter Upgrade der API-Version Ihres Azure Cosmos DB for MongoDB-Kontos.
Aktivieren der serverseitigen Wiederholung für die API von Azure Cosmos DB für das MongoDB-Konto
Wenn ein Konto einen TooManyRequests-Fehler mit dem Fehlercode 16500 auslöst, kann das Aktivieren von Server Side Retry (SSR) dazu beitragen, das Problem zu beheben.
Potenzielle Vorteile: Vermeiden einer Drosselung und Verbessern der Zuverlässigkeit und Leistung von Abfragen
Hinzufügen einer zweiten Region zu Ihren Produktionsworkloads in Azure Cosmos DB
Produktions-Workloads in Azure Cosmos DB, die in einer einzigen Region ausgeführt werden, können zu Verfügbarkeitsproblemen führen. Dies scheint bei einigen Ihrer Cosmos DB-Konten der Fall zu sein. Erhöhen Sie ihre Verfügbarkeit, indem Sie sie so konfigurieren, dass sie mindestens zwei Azure-Regionen umfassen. HINWEIS: Für zusätzliche Regionen fallen zusätzliche Kosten an.
Potenzielle Vorteile: Verbessern der Verfügbarkeit Ihrer Produktionsworkloads
Weitere Informationen finden Sie unter Hochverfügbarkeit (Zuverlässigkeit) in Azure Cosmos DB for NoSQL.
Aktualisieren der alten Azure Cosmos DB SDK auf die neueste Version
Ein Azure Cosmos DB-Konto mit einer alten Version des SDK, verfügt nicht über die aktuellen Korrekturen und Verbesserungen. Ihr Azure Cosmos DB-Konto verwendet eine ältere Version des SDK. Führen Sie ein Upgrade auf die aktuelle Version durch, um aktuelle Korrekturen, Leistungsverbesserungen und neue Funktionen zu erhalten.
Potenzielle Vorteile: Verbesserte Zuverlässigkeit, Leistung und neue Funktionen
Weitere Informationen finden Sie in der Dokumentation zu Azure Cosmos DB.
Aktualisieren des veralteten Azure Cosmos DB SDK auf die neueste Version
Ein Azure Cosmos DB-Konto mit einer alten Version des SDK, verfügt nicht über die aktuellen Korrekturen und Verbesserungen. Für Ihr Azure Cosmos DB-Konto wird eine veraltete Version des SDK verwendet. Es wird empfohlen, ein Upgrade auf die neueste Version durchzuführen, um aktuelle Fixes, Leistungsverbesserungen und neue Funktionen zu erhalten.
Potenzielle Vorteile: Verbesserte Zuverlässigkeit, Leistung und neue Funktionen
Weitere Informationen finden Sie in der Dokumentation zu Azure Cosmos DB.
Aktivieren des dienstseitig verwalteten Failovers für ein Cosmos DB-Konto
Aktivieren Sie das dienstseitig verwaltete Failover für Cosmos DB-Konten, um Hochverfügbarkeit für das Konto sicherzustellen. Bei einem dienstseitig verwalteten Failover wird die Schreibregion im Falle eines Ausfalls der primären Region automatisch in die sekundäre Region verlagert. Dadurch wird sichergestellt, dass die Anwendung ganz ohne Downtime weiter funktioniert.
Potenzielle Vorteile: Das vom Dienst verwaltete Failover-Feature von Azure verbessert die Systemverfügbarkeit, indem Failoverprozesse automatisiert und Ausfallzeiten reduziert werden und die Resilienz verbessert wird.
Weitere Informationen finden Sie unter Hochverfügbarkeit (Zuverlässigkeit) in Azure Cosmos DB for NoSQL.
Hochverfügbarkeit für Ihre Produktions-Workload aktivieren
Viele Cluster mit konsistenten Workloads haben keine hohe Verfügbarkeit (HA) aktiviert. Es empfiehlt sich, Hochverfügbarkeit über die Skalierungsseite im Azure-Portal zu aktivieren, um Datenbankausfällen bei unerwarteten Knotenfehlern vorzubeugen und sich für SLA-Garantien zu qualifizieren.
Potenzielle Vorteile: Aktivieren von Hochverfügbarkeit, um Datenbankausfälle zu vermeiden, wenn ein unerwarteter Knotenfehler auftritt
Weitere Informationen finden Sie unter Skalieren und Konfigurieren Ihres Azure Cosmos DB for MongoDB-vCore-Clusters.
Aktivieren der Zonenredundanz für multiregionale Cosmos DB-Konten
Diese Empfehlung schlägt vor, die Zonenredundanz für multiregionale Cosmos DB-Konten zu aktivieren, um hohe Verfügbarkeit zu verbessern und das Risiko von Datenverlust bei einem regionalen Ausfall zu verringern.
Potenzielle Vorteile: Verbesserte Hochverfügbarkeit und verringertes Risiko von Datenverlust
Weitere Informationen finden Sie unter Hochverfügbarkeit (Zuverlässigkeit) in Azure Cosmos DB for NoSQL.
Hinzufügen mindestens eines Rechenzentrums in einer anderen Azure-Region
Ihr Cluster vom Typ „Azure Managed Instance for Apache Cassandra“ ist als Produktionscluster festgelegt, wird aber derzeit nur in einer einzelnen Azure-Region bereitgestellt. Bei Produktionsclustern empfiehlt es sich, mindestens ein weiteres Rechenzentrum in einer anderen Azure-Region hinzuzufügen, um vor Notfallwiederherstellungsszenarien geschützt zu sein.
Potenzielle Vorteile: Sicherstellen, dass Anwendungen im Fall einer Notfallwiederherstellung über eine andere Region verfügen
Weitere Informationen finden Sie unter Bewährte Methoden für Hochverfügbarkeit und Notfallwiederherstellung.
Vermeiden von Ratenbegrenzungen für Vorgänge auf der Steuerungsebene
Wir haben eine hohe Anzahl von Vorgängen auf der Steuerungsebene durch den Ressourcenanbieter in Ihrem Konto gefunden. Bei Anforderungen, die die dokumentierten Grenzwerte auf anhaltendem Niveau in aufeinanderfolgenden 5-Minuten-Zeiträumen überschreiten, kann es zu einer Drosselung von Anforderungen sowie fehlerhaften oder unvollständigen Vorgängen für Azure Cosmos DB-Ressourcen kommen.
Potenzielle Vorteile: Optimieren der Vorgänge auf der Steuerungsebene und Vermeiden von Betriebsfehlern aufgrund von Ratenbegrenzungen
Weitere Informationen finden Sie unter Kontingente im Azure Cosmos DB-Dienst.
Azure-Daten-Explorer
Beheben von Virtual Network-Problemen
Fehler beim Installieren oder Fortsetzen des Diensts aufgrund von Problemen mit dem virtuellen Netzwerk (VNet). Beachten Sie zum Lösen dieses Problems die Schritte im Leitfaden zur Problembehandlung.
Potenzielle Vorteile: Erhöhen der Zuverlässigkeit, Verfügbarkeit und Leistung und Profitieren von neuen Funktionen
Weitere Informationen finden Sie unter Behandlung von Problemen im Zusammenhang mit dem Zugriff, der Erfassung und dem Betrieb Ihres Azure Data Explorer-Clusters in Ihrem virtuellen Netzwerk.
Hinzufügen der Subnetzdelegierung für „Microsoft.Kusto/clusters“
Wenn ein Subnetz nicht delegiert wird, kann der zugeordnete Azure-Dienst nicht darin arbeiten. Ihr Subnetz verfügt nicht über die erforderliche Delegierung. Delegieren des Subnetzes für „Microsoft.Kusto/clusters“.
Potenzielle Vorteile: Erhöhen der Zuverlässigkeit, Verfügbarkeit und Leistung und Profitieren von neuen Funktionen
Weitere Informationen finden Sie unter Was ist die Subnetzdelegierung?.
Azure Database for MySQL
Hochverfügbarkeit: Fügen Sie einen Primärschlüssel zu einer Tabelle hinzu, die aktuell über keinen verfügt.
Unser internes Überwachungssystem hat eine erhebliche Verzögerung bei der Replikation auf dem Hochverfügbarkeits-Standbyserver festgestellt. Diese Verzögerung wird in erster Linie dadurch verursacht, dass der Standbyserver Relayprotokolle in einer Tabelle wiedergibt, der ein Primärschlüssel fehlt. Um dieses Problem zu beheben und die bewährten Methoden einzuhalten, wird empfohlen, allen Tabellen Primärschlüssel hinzuzufügen. Sobald dies erfolgt ist, deaktivieren Sie die Hochverfügbarkeit und aktivieren sie anschließend wieder, um das Problem zu entschärfen.
Potenzielle Vorteile: Durch Implementierung dieses Ansatzes wird der Standbyserver vor den negativen Auswirkungen einer hohen Replikationsverzögerung geschützt, die durch das Fehlen eines Primärschlüssels in einer Tabelle verursacht wird. Dieser Ansatz kann zu einer Verkürzung der Failoverzeiten beitragen, was letztlich das Ziel der Aufrechterhaltung der Geschäftskontinuität unterstützt.
Weitere Informationen finden Sie unter Behandeln von Problemen mit der Replikationswartezeit in Azure Database for MySQL – Flexible Server.
Replikation: Fügen Sie einen Primärschlüssel zu einer Tabelle hinzu, die derzeit keinen hat.
Bei unserer internen Überwachung wurden erhebliche Replikationsverzögerungen auf Ihrem Replikatserver beobachtet, da der Replikatserver Vermittlungsprotokolle für eine Tabelle ohne Primärschlüssel wiedergibt. Damit der Replikatserver effektiv mit dem primären Server synchronisiert werden kann und mit den Änderungen Schritt hält, müssen Sie den Tabellen auf dem primären Server Primärschlüssel hinzuzufügen und anschließend den Replikatserver neu erstellen.
Potenzielle Vorteile: Durch die Implementierung dieses Ansatzes erreicht der Replikatserver einen Zustand der engen Synchronisierung mit dem primären Server.
Weitere Informationen finden Sie unter Behandeln von Problemen mit der Replikationswartezeit in Azure Database for MySQL – Flexible Server.
Azure Database for PostgreSQL
Entfernen von inaktiven logischen Replikationsslots (wichtig)
Inaktive Protokollreplikationsslots können aufgrund der Aufbewahrung von WAL-Dateien (Write Ahead Log) und der Ansammlung von Momentaufnahmedateien zu einer Verschlechterung der Serverleistung und zu Nichtverfügbarkeit führen. Ihr flexibler Server für Azure Database for PostgreSQL weist möglicherweise inaktive logische Replikationsslots auf. IN DIESEM ZUAMMENHANG SIND SOFORTIGE MASSNAHMEN ERFORDERLICH. Löschen Sie entweder die inaktiven Replikationsplätze, oder beginnen Sie mit der Nutzung der Änderungen über diese Slots, damit die Protokollfolgenummer (Log Sequence Number, LSN) der Slots voranschreitet und sich in der Nähe der aktuellen LSN des Servers befindet.
Potenzielle Vorteile: Verbessern der PostgreSQL-Verfügbarkeit durch das Entfernen von inaktiven logischen Replikationsslots
Weitere Informationen finden Sie unter Logische Replikation und Decodierung in Azure Database for PostgreSQL – Flexible Server.
Entfernen von inaktiven logischen Replikationsslots
Wenn ein flexibler Orcas PostgreSQL-Server inaktive logische Replikationsslots hat, kann es aufgrund der Aufbewahrung von WAL-Dateien (Write Ahead Log) und der Ansammlung von Momentaufnahmedateien zu einer Verschlechterung der Serverleistung und zu Nichtverfügbarkeit kommen. IN DIESEM ZUAMMENHANG SIND SOFORTIGE MASSNAHMEN ERFORDERLICH. Löschen Sie entweder die inaktiven Replikationsplätze, oder beginnen Sie mit der Nutzung der Änderungen über diese Slots, damit die Protokollfolgenummer (Log Sequence Number, LSN) der Slots voranschreitet und sich in der Nähe der aktuellen LSN des Servers befindet.
Potenzielle Vorteile: Verbessern der PostgreSQL-Verfügbarkeit durch das Entfernen von inaktiven logischen Replikationsslots
Weitere Informationen finden Sie unter Logische Decodierung.
Konfigurieren Sie den georedundanten Sicherungsspeicher
Konfigurieren Sie GRS, um sicherzustellen, dass Ihre Datenbank ihre Verfügbarkeits- und Lebensdauerziele auch bei Ausfällen oder Katastrophen erfüllt.
Potenzielle Vorteile: Sicherstellung der Wiederherstellung nach einem regionalem Ausfall oder Notfall.
Weitere Informationen finden Sie unter Sicherung und Wiederherstellung in Azure Database for PostgreSQL – Flexible Server.
Definieren benutzerdefinierter Wartungsfenster außerhalb von Spitzenzeiten
Beim Konfigurieren der Einstellungen für den Wartungszeitplan können Sie einen Wochentag und ein Zeitfenster auswählen. Wenn Sie nichts angeben, wird vom System je nach Zeitzone des Servers ein Zeitfenster zwischen 23:00 und 7:00 Uhr ausgewählt. Wählen Sie einen Tag und eine Uhrzeit mit geringer Nutzung.
Potenzielle Vorteile: Die Konfiguration des Wartungsfensters ermöglicht die Vermeidung von Wartungen während der Systemspitzen.
Weitere Informationen finden Sie unter Geplante Wartung in Azure Database for PostgreSQL – Flexible Server.
Azure IoT Hub
Upgraden der Runtime von Microsoft Edge-Geräten auf eine unterstützte Version für IoT-Hub
Wenn Edge-Geräte veraltete Versionen verwenden, kann es zu Leistungsbeeinträchtigungen kommen. Wir empfehlen, ein Upgrade auf die neueste unterstützte Version der Azure IoT Edge-Runtime durchzuführen.
Potenzielle Vorteile: Sicherstellen der Geschäftskontinuität mit der neuesten unterstützten Version für Ihre Edge-Geräte
Weitere Informationen finden Sie unter Aktualisieren von IoT Edge.
Upgrade des Geräteclient-SDK auf eine unterstützte Version für IoT Hub
Wenn Geräte ein veraltetes SDK verwenden, kann dies zu einer Leistungsbeeinträchtigung führen. Einige oder alle Ihre Geräte verwenden ein veraltetes SDK. Wir empfehlen, ein Upgrade auf eine unterstützte SDK-Version durchzuführen.
Potenzielle Vorteile: Sicherstellen der Geschäftskontinuität mit unterstütztem SDK für Ihre Geräte
Weitere Informationen finden Sie unter Azure IoT Hub-SDKs.
IoT Hub: potenzieller Gerätesturm erkannt
Dieser Fall kann eintreten, wenn zwei oder mehr Geräten 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.
Potenzielle Vorteile: Verbessern der Konnektivität Ihrer Geräte
Weitere Informationen finden Sie unter Grundlegendes und Beheben von Azure IoT Hub-Fehlern.
Aktualisieren von Device Update for IoT Hub SDK auf eine unterstützte Version
Wenn eine Instanz von Device Update for IoT Hub eine veraltete Version des SDK verwendet, erhält sie nicht die neuesten Upgrades. Führen Sie ein Upgrade auf die aktuelle Device Update for IoT Hub SDK-Version durch, um aktuelle Korrekturen, Leistungsverbesserungen und neue Funktionen zu erhalten.
Potenzielle Vorteile: Sicherstellen der Geschäftskontinuität mit unterstütztem SDK
Weitere Informationen finden Sie unter Was ist Device Update for IoT Hub?.
Hinzufügen von IoT-Hub-Einheiten oder Erhöhen der SKU-Ebene
Wenn das tägliche Nachrichtenkontingent eines IoT-Hubs überschritten wird, kann es zu Betriebs- und Kostenproblemen kommen. Um in Zukunft einen reibungslosen Betrieb sicherzustellen, fügen Sie Einheiten hinzu oder erhöhen Sie die SKU-Ebene.
Potenzielle Vorteile: IoT Hub kann wieder Nachrichten empfangen.
Weitere Informationen finden Sie unter Grundlegendes und Beheben von Azure IoT Hub-Fehlern.
Azure Kubernetes Service (AKS)
Aktivieren der automatischen Skalierung für Systemknotenpools
Aktivieren Sie die automatische Skalierung im Systemknotenpool, damit die System-Pods auch bei hoher Auslastung geplant werden.
Potenzielle Vorteile: Das Aktivieren von Autoscaler für den Systemknotenpool stellt sicher, dass Systempods geplant sind und der Cluster funktionieren kann.
Weitere Informationen finden Sie unter Verwenden der Autoskalierung für Cluster in Azure Kubernetes Service (AKS).
Mindestens 2 Knoten in Ihrem Systemknotenpool
Stellen Sie sicher, dass Ihre Systemknotenpools mindestens zwei Knoten für die Zuverlässigkeit Ihrer System-Pods haben. Bei einem einzelnen Knoten kann in Ihrem Cluster bei einem Knoten- oder Hardwarefehler ein Fehler auftreten.
Potenzielle Vorteile: Durch die Verwendung von 2 Knoten wird die Resilienz gegenüber Knotenfehlern sichergestellt.
Weitere Informationen finden Sie unter Verwalten von Systemknotenpools in Azure Kubernetes Service (AKS).
Erstellen eines dedizierten Systemknotenpools
Ein Cluster ohne dedizierten Systemknotenpool ist weniger zuverlässig. Es wird empfohlen, Systemknotenpools nur für kritische System-Pods bereitzustellen, um eine Ressourcenverknappung zwischen System- und konkurrierenden Benutzer-Pods zu verhindern. Erzwingen Sie dieses Verhalten mit dem Taint „CriticalAddonsOnly=true:NoSchedule“ im Pool.
Potenzielle Vorteile: Stellt die Zuverlässigkeit des Clusters sicher, indem Ressourcenknappheit für Kernsystempods verhindert wird
Weitere Informationen finden Sie unter Verwalten von Systemknotenpools in Azure Kubernetes Service (AKS).
Sicherstellen, dass virtuelle Computer (Virtual Machines, VMs) der B-Serie nicht in einer Produktionsumgebung verwendet werden
Wenn ein Cluster einen oder mehrere Knotenpools enthält, die eine nicht empfohlene burstfähige VM-SKU verwenden, wird eine vollständige vCPU-Kapazität von 100 % nicht garantiert. Stellen Sie sicher, dass VMs der B-Serie nicht in einer Produktionsumgebung verwendet werden.
Potenzielle Vorteile: Bewährte Methode für konsistente Leistung
Weitere Informationen finden Sie unter Bv1-Seriengrößen.
Azure NetApp Files
Konfigurieren der AD DS-Website für Azure Netapp Files AD-Connector
Wenn Azure NetApp Files zugewiesene AD DS-Standortdomänencontroller nicht erreichen kann, fragt der Domänencontrollerermittlungsprozess alle Domänencontroller ab. Nicht erreichbare Domänencontroller können verwendet werden, was zu Problemen bei der Volumenerstellung, Clientabfragen, Authentifizierung und AD-Verbindungsänderungen führt.
Potenzielle Vorteile: Optimieren der DNS-Konnektivität mit Azure Netapp Files
Weitere Informationen finden Sie unter Grundlegendes zu Richtlinien für Active Directory Domain Services-Websitedesign und -planung für Azure NetApp Files.
Stellen Sie sicher, dass die dem delegierten Microsoft.NetApp Subnetz Rollenzuweisung über Leseberechtigungen für das Subnetz verfügen.
Rollen, die für das Management von Azure NetApp Files-Ressourcen erforderlich sind, müssen über die Berechtigung "Microsoft.network/virtualNetworks/subnets/read" für das Subnetz verfügen, das an Microsoft.NetApp delegiert wird. Wenn die Rolle, egal ob benutzerdefiniert oder integriert, nicht über diese Berechtigung verfügt, schlägt die Volume-Erstellung fehl.
Potenzielle Vorteile: Verhindern von Volumeerstellungsfehlern durch Sicherstellen von Subnetz-/Leseberechtigungen
Ü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 den Link „Weitere Informationen“, um sicherzustellen, dass Ihre Konfiguration die in der Dokumentation beschriebenen Timeoutwerte erfüllt.
Potenzielle Vorteile: Verbessern der Resilienz von SAP-Anwendungen in ANF
Weitere Informationen finden Sie unter Verwenden von Azure zum Hosten und Ausführen von SAP-Workloadszenarien.
Implementieren von Strategien zur Notfallwiederherstellung für Ihre Azure NetApp Files-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.
Potenzielle Vorteile: Einfaches Verwalten der Notfallwiederherstellung mit den Replikationsfeatures von Azure NetApp Files
Weitere Informationen finden Sie unter Grundlegendes zu Datenschutz- und Notfallwiederherstellungsoptionen in Azure NetApp Files.
Azure Netapp-Dateien - ermöglichen kontinuierliche Verfügbarkeit für SMB-Volumes
Für die kontinuierliche Verfügbarkeit empfehlen wir, das SMB-Volume (Server Message Block) für Ihre Azure NetApp Files zu aktivieren.
Potenzielle Vorteile: Verhindern von Anwendungsunterbrechungen durch Aktivieren der kontinuierlichen Verfügbarkeit für SMB-Volumes
Weitere Informationen finden Sie unter Aktivieren der fortlaufenden Verfügbarkeit auf vorhandenen SMB-Volumes.
Azure Site Recovery
Aktivieren des vorläufigen Löschens für Ihre Recovery Services-Tresore
Mit der Funktion „vorläufiges Löschen“ können Sie Ihre Sicherungsdaten nach dem Löschen für eine zusätzliche Dauer im Recovery Services-Tresor aufbewahren, sodass Sie die Möglichkeit haben, sie abzurufen, bevor sie endgültig gelöscht werden.
Potenzielle Vorteile: Hilft bei der Wiederherstellung von Sicherungsdaten bei versehentlichem Löschen
Weitere Informationen finden Sie unter Vorläufiges Löschen für Azure Backup.
Aktivieren der regionsübergreifenden Wiederherstellung für Ihren Recovery Services-Tresor
Die regionsübergreifende Wiederherstellung (Cross-Region Restore, CRR) ermöglicht Ihnen, Azure-VMs in einer sekundären Region wiederherzustellen (einer gekoppelten Azure-Region). Das erleichtert die Notfallwiederherstellung.
Potenzielle Vorteile: Als eine der Wiederherstellungsoptionen ermöglicht die regionsübergreifende Wiederherstellung (CRR) die Wiederherstellung von Azure-VMs in einer sekundären Region, bei der es sich um eine gekoppelte Azure-Region handelt.
Weitere Informationen finden Sie unter Wiederherstellen von Azure-VM-Daten im Azure-Portal.
Azure Spring Apps
Anwendungskonfigurationsdienst auf Gen 2 upgraden
Wir stellen fest, dass Sie noch den Anwendungskonfigurationsdienst Gen1 verwenden, dessen Support im April 2024 beendet wird. Der Anwendungskonfigurationsdienst Gen2 bietet im Vergleich zu Gen1 eine bessere Leistung. Das Upgrade von Gen1 auf Gen2 ist ohne Downtime möglich, so dass wir empfehlen, das Upgrade so bald wie möglich durchzuführen.
Potenzielle Vorteile: Höhere Stabilität und Verfügbarkeit
Weitere Informationen finden Sie unter Verwenden des Anwendungskonfigurationsdiensts für Tanzu.
Azure SQL-Datenbank
Aktivieren der regionsübergreifenden Notfallwiederherstellung für SQL-Datenbank
Aktivieren Sie die regionsübergreifende Notfallwiederherstellung für Azure SQL-Datenbank für Geschäftskontinuität bei einem regionalen Ausfall.
Potenzielle Vorteile: Das Aktivieren der Notfallwiederherstellung erstellt eine fortlaufend synchronisierte lesbare sekundäre Datenbank für eine primäre Datenbank.
Weitere Informationen finden Sie in der Übersicht über die Geschäftskontinuität mit Azure SQL-Datenbank.
Aktivieren Sie Zonenredundanz für Azure SQL-Datenbank, um hohe Verfügbarkeit und Resilienz zu erzielen.
Um eine hohe Verfügbarkeit und Resilienz zu erreichen, aktivieren Sie die Zonenredundanz für die SQL-Datenbank oder den Pool für elastische Datenbanken, um Verfügbarkeitszonen zu verwenden und sicherzustellen, dass die Datenbank oder der Pool für elastische Datenbanken für Zonalfehler widerstandsfähig ist.
Potenzielle Vorteile: Durch die Aktivierung der Zonenredundanz wird sichergestellt, dass die Azure SQL-Datenbank resilient gegenüber zonalen Hardware- und Softwarefehlern ist und die Wiederherstellung für Anwendungen transparent ist.
Weitere Informationen finden Sie unter Verfügbarkeit durch Redundanz – Azure SQL-Datenbank.
Azure Stack HCI
Aktualisieren Sie auf die neueste Version von AKS, die von Arc aktiviert wurde
Aktualisieren Sie auf die neueste Version der API/SDK von AKS, die von Azure Arc aktiviert wurde, um neue Funktionen und verbesserte Stabilität zu erhalten.
Potenzielle Vorteile: Die neueste Version von AKS mit Azure Arc-Unterstützung mit neuer Funktionalität und verbesserter Stabilität.
Weitere Informationen finden Sie unter https://azure.github.io/azure-sdk/releases/latest/index.html.
Aktualisieren Sie auf die neueste Version von AKS, die von Arc aktiviert wurde
Aktualisieren Sie auf die neueste Version der API/SDK von AKS, die von Azure Arc aktiviert wurde, um neue Funktionen und verbesserte Stabilität zu erhalten.
Potenzielle Vorteile: Die neueste Version von AKS mit Azure Arc-Unterstützung mit neuer Funktionalität und verbesserter Stabilität.
Weitere Informationen finden Sie unter https://azure.github.io/azure-sdk/releases/latest/index.html.
Klassisches Bereitstellungsmodell für Speicher
Aktion erforderlich: Migrieren Sie klassische Speicherkonten bis zum 30.08.2024.
Migrieren Sie Ihre klassischen Speicherkonten zu Azure Resource Manager, um die Geschäftskontinuität sicherzustellen. Azure Resource Manager stellt die gleichen Funktionen sowie eine konsistente Verwaltungsebene, Ressourcengruppierung und Zugriff auf neue Features und Updates bereit.
Potenzielle Vorteile: Sicherstellen der Möglichkeit zum Verwalten Ihrer Daten durch Migrieren der klassischen Speicherkonten
Klassisches Bereitstellungsmodell für virtuelle Computer
Migrieren von Cloud Services (klassisch) vor dem 31. August 2024
Cloud Services (klassisch) wird eingestellt. Um den Verlust von Daten oder Geschäftskontinuität zu vermeiden, sollten Sie vor dem 31. August 2024 migrieren.
Potenzielle Vorteile: Kontinuität Ihres Diensts
Weitere Informationen finden Sie unter Migrieren von Azure Cloud Services (klassisch) zu Azure Cloud Services (erweiterter Support).
Cognitive Services
Upgrade Ihrer Anwendung auf die Verwendung der neuesten API-Version von Azure OpenAI
Bei einer Azure OpenAI-Ressource mit einer älteren API-Version fehlen die neuesten Features und Funktionen. Es empfiehlt sich, die neueste REST API-Version zu verwenden.
Potenzielle Vorteile: Unsere neuen API-Versionen enthalten die neuesten und besten Features und Funktionen.
Weitere Informationen finden Sie in der Referenz zur REST-API von Azure OpenAI Service.
Kontingent für diese Ressource ist überschrittenen, zum Aufheben der Blockierung bitte warten oder ein Upgrade vornehmen
Wenn das Kontingent für Ihre Ressource überschritten wird, wird die Ressource blockiert. 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 Ressource jetzt wieder nutzen zu können.
Potenzielle Vorteile: Bei einem Upgrade auf eine kostenpflichtige SKU können Sie die Ressource noch heute wieder verwenden.
Weitere Informationen finden Sie unter Planen und Verwalten von Kosten für Azure KI Studio.
Container Registry
Verwenden der Premium-Ebene für kritische Produktionsworkloads
Premium-Registrierungen bieten den größten Umfang an Speicher, an gleichzeitigen Vorgängen und an Netzwerkbandbreite, sodass Szenarien mit großen Volumen möglich sind. Auf der Premium-Ebene kommen außerdem Features wie Georeplikation, Unterstützung für Verfügbarkeitszonen, Content-Trust, kundenseitig verwaltete Schlüssel und private Endpunkte hinzu.
Potenzielle Vorteile: Die Premium-Stufe bietet die höchste Anzahl an Leistungs-, Skalierungs- und Resilienzoptionen.
Weitere Informationen finden Sie unter Azure Container Registry-Tarife.
Sicherstellen, dass die Georeplikation für Resilienz aktiviert ist
Die Georeplikation ermöglicht Workloads die Nutzung eines einzelnen Images, Tags und Registrierungsnamens in allen Regionen. Außerdem bietet sie netzwerknahen Registrierungszugriff, geringere Kosten für Datenübertragungen und regionale Resilienz von Registrierungen bei einem regionalen Ausfall. Dieses Feature ist nur auf der Premium-Dienstebene verfügbar.
Potenzielle Vorteile: Verbesserte Resilienz und Pullleistung, vereinfachtes Registrierungsmanagement und reduzierte Datenübertragungskosten
Weitere Informationen finden Sie unter Georeplikation in Azure Container Registry.
Content Delivery Network
Azure CDN von Edgio, Verlängerung des verwalteten Zertifikats fehlgeschlagen. Zusätzliche Validierung nötig.
Azure CDN von Edgio nutzt die CNAME-Delegierung, um verwaltete Zertifikate mit DigiCert zu verlängern. Es ist wichtig, dass benutzerdefinierte Domänen zu einem Endpunkt vom Typ „azureedge.net“ aufgelöst werden, damit der automatische Verlängerungsprozess mit DigiCert erfolgreich ist. Stellen Sie sicher, dass der CNAME-Eintrag und der CAA-Eintrag Ihrer benutzerdefinierten Domäne ordnungsgemäß konfiguriert sind. Wenn Sie weitere Unterstützung benötigen, öffnen Sie einen Supportfall bei Azure, um die Verlängerung erneut anzufordern.
Potenzielle Vorteile: Sicherstellen der Dienstverfügbarkeit.
Verlängern des abgelaufenen Azure Front Door-Kundenzertifikats zur Vermeidung von Dienstunterbrechungen
Wenn Kundenzertifikate für Azure Front Door Standard- und Premium-Profile ablaufen, treten möglicherweise Dienstunterbrechungen auf. Um eine Unterbrechung des Dienstes zu vermeiden, erneuern Sie das Zertifikat, bevor es abläuft.
Potenzielle Vorteile: Sicherstellen der Dienstverfügbarkeit.
Weitere Informationen finden Sie unter Konfigurieren von HTTPS in einer benutzerdefinierten Azure Front Door-Domäne mithilfe des Azure-Portals.
Erneutes Bestätigen des Domänenbesitzes für die Verlängerung des verwalteten Azure Front Door-Zertifikats
Azure Front Door (AFD) kann das verwaltete Zertifikat nicht automatisch verlängern, da die Domäne nicht per CNAME dem AFD-Endpunkt zugeordnet ist. Damit das verwaltete Zertifikat automatisch erneuert wird, müssen Sie die Domäneneigentümerschaft erneut validieren.
Potenzielle Vorteile: undefiniert
Weitere Informationen finden Sie unter Konfigurieren einer benutzerdefinierten Domäne auf Azure Front Door mithilfe des Azure-Portals.
Umstellen der Geheimnisversion auf „Neueste“ für das Azure Front Door-Kundenzertifikat
Konfigurieren Sie das Geheimnis des Azure Front Door-Kundenzertifikats mit „Neuestes“, damit Azure Front Door auf die neueste Geheimnisversion in Azure Key Vault verweist, damit das Geheimnis automatisch rotiert werden kann.
Potenzielle Vorteile: Die neueste Version kann automatisch rotiert werden.
Weitere Informationen finden Sie unter Konfigurieren von HTTPS in einer benutzerdefinierten Azure Front Door-Domäne mithilfe des Azure-Portals.
Bestätigen des Domänenbesitzes durch Hinzufügen eines DNS-TXT-Eintrags zum DNS-Anbieter
Bestätigen Sie den Domänenbesitz durch Hinzufügen des DNS-TXT-Eintrags zu Ihrem DNS-Anbieter. Die Validierung des Domänenbesitzes durch TXT-Einträge erhöht die Sicherheit und gewährleistet die ordnungsgemäße Kontrolle über Ihre Domäne.
Potenzielle Vorteile: Sicherstellen der Dienstverfügbarkeit.
Weitere Informationen finden Sie unter Konfigurieren einer benutzerdefinierten Domäne auf Azure Front Door mithilfe des Azure-Portals.
Data Factory
Implementieren der BCDR-Strategie für regionsübergreifende Redundanz in Azure Data Factory
Die Implementierung der BCDR-Strategie verbessert hohe Verfügbarkeit und verringertes Risiko von Datenverlust
Potenzielle Vorteile: Verbesserte Hochverfügbarkeit und verringertes Risiko von Datenverlust
Weitere Informationen finden Sie unter BCDR für Azure Data Factory- und Azure Synapse Analytics-Pipelines: Azure Architecture Center .
Automatische Upgrades auf der SHIR aktivieren
Das automatische Upgrade der selbstgehosteten Integration Runtime wurde deaktiviert. Beachten Sie, dass Sie nicht die neuesten Änderungen und Fehlerbehebungen für die selbstgehostete Integration Runtime erhalten. Überprüfe die Einstellungen, um automatische SHIR-Upgrades zu aktivieren.
Potenzielle Vorteile: Erhalten der neuesten Änderungen und Fehlerbehebungen für die selbstgehostete Integration Runtime
Weitere Informationen finden Sie unter Benachrichtigung zur automatischen Aktualisierung und zum Ablauf der selbstgehosteten Integration Runtime.
Azure Fluid Relay
Azure Fluid Relay-Clientbibliothek sollte aktualisiert werden
Wenn der Azure Fluid Relay-Dienst mit einer alten Clientbibliothek aufgerufen wird, kann das Probleme mit der Anwendung zur Folge haben. Damit Ihre Anwendung funktionsfähig bleibt, sollten Sie Ihre Azure Fluid Relay-Clientbibliothek auf die neueste Version aktualisieren. Durch das Upgrade werden die neuesten Funktionen sowie Verbesserungen in Bezug auf Leistung und Stabilität bereitgestellt.
Potenzielle Vorteile: Verbesserte Zuverlässigkeit
Weitere Informationen finden Sie unter Versionskompatibilität mit Fluid Framework-Versionen.
HDInsight
Wichtige Updates anwenden, indem Sie Ihre HDInsight-Cluster löschen und neu erstellen (Runde 2 der Zertifikatrotation)
Der HDInsight-Dienst hat versucht, ein kritisches Zertifikatupdate auf Ihre ausgeführten Cluster anzuwenden. Aufgrund von benutzerdefinierten Konfigurationsänderungen war das Anwenden der Updates für alle Ihre Cluster aber nicht möglich. Löschen und erstellen Sie Ihre Cluster neu, um zu verhindern, dass sie fehlerhaft und unbrauchbar werden.
Potenzielle Vorteile: Sicherstellen der Integrität und Stabilität des Clusters
Weitere Informationen finden Sie unter Einrichten von Clustern in HDInsight mit Apache Hadoop, Apache Spark, Apache Kafka usw..
ABFS-Cluster ohne ESP [Clusterberechtigungen für World Readable]
Planen Sie die Einführung einer Änderung in Nicht-ESP-ABFS-Clustern, die Benutzer von Nicht-Hadoop-Gruppen daran hindert, Hadoop-Befehle für Speichervorgänge auszuführen. Mit dieser Änderung soll die Cluster-Sicherheitslage verbessert werden. Kunden müssen die Updates vor dem 30. September 2023 einplanen.
Potenzielle Vorteile: Diese Änderung dient dazu, den Sicherheitsstatus des Clusters zu verbessern.
Weitere Informationen finden Sie in den Versionshinweisen zu Azure HDInsight.
Broker auf Ihren Kafka-Clusterdatenträgern neu starten
Wenn Datenträger, die von Kafka-Brokern in HDInsight-Clustern verwendet werden, fast voll sind, kann der Apache Kafka-Brokerprozess nicht gestartet werden und schlägt fehl. Ermitteln Sie die Aufbewahrungszeit für jedes Thema, sichern Sie die älteren Dateien, und starten Sie die Broker neu, um das Problem zu beheben.
Potenzielle Vorteile: Vermeiden von Kafka-Brokerproblemen
Weitere Informationen finden Sie unter Szenario: Broker sind nicht funktionsfähig oder können nicht neu gestartet werden, weil die Festplatte voll ist.
Aktualisierung der Länge des Clusternamens
Die maximale Länge des Clusternamens wird von 59 auf 45 Zeichen geändert, um den Sicherheitsstatus von Clustern zu verbessern. Diese Änderung wird bis zum 30. September 2023 implementiert.
Potenzielle Vorteile: Verbesserung des Sicherheitsstatus für HDInsight
Weitere Informationen finden Sie in den Versionshinweisen zu Azure HDInsight.
Upgraden Ihres Clusters auf das neueste HDInsight-Image
Ein vor einem Jahr erstellter Cluster verfügt nicht über die neuesten Imageupgrades. Ihr Cluster wurde vor einem Jahr erstellt. 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.
Potenzielle Vorteile: Erhalten der neuesten Fixes und Features
Weitere Informationen finden Sie unter Berücksichtigen Sie die folgenden Punkte, bevor Sie mit dem Erstellen eines Clusters beginnen..
Durchführen eines Upgrades für Ihren HDInsight-Cluster
Ein Cluster, der nicht das neueste Image verwendet, verfügt nicht über die neuesten Upgrades. Ihr Cluster verwendet nicht das neueste Image. Wir empfehlen Ihnen, die neuesten Versionen von HDInsight-Images zu verwenden, da sie die Vorteile aus Open-Source-Updates, Azure-Updates und Sicherheitsfixes bieten. Neue HDInsight-Versionen erscheinen alle 30 bis 60 Tage.
Potenzielle Vorteile: Erhalten der neuesten Fixes und Features
Weitere Informationen finden Sie in den Versionshinweisen zu Azure HDInsight.
Gateway oder virtuelle Maschine nicht erreichbar
Wir haben einen Netzwerkfehler entdeckt, der auf ein unerreichbares Gateway oder eine virtuelle Maschine hinweist. Überprüfen Sie die Verfügbarkeit aller Clusterhosts. Starten Sie die virtuelle Maschine zur Wiederherstellung neu. Wenn Sie weitere Hilfe benötigen, zögern Sie nicht, sich an den Azure-Support zu wenden.
Potenzielle Vorteile: Verbesserte Verfügbarkeit
Der VM-Agent ist 9.9.9.9. Upgraden Sie den Cluster.
Unsere Aufzeichnungen deuten darauf hin, dass mindestens ein Cluster Images vom Februar 2022 oder älter verwendet (Bildversionen 2202xxxxxx oder älter). Es gibt ein potenzielles Zuverlässigkeitsproblem auf HDInsight-Clustern, die Images von Februar 2022 oder älter verwenden. Erwägen Sie, Ihre Cluster mit dem neuesten Image neu zu erstellen.
Potenzielle Vorteile: Verbesserte Zuverlässigkeit bei Skalierung und Netzwerkkonnektivität
Media Services
Erhöhen von Kontingenten oder Grenzwerten für Media Services
Wenn die Kontingentgrenzen eines Medienkontos erreicht werden, kann es zu Dienstunterbrechungen kommen. Deshalb sollten Sie den aktuellen Ressourcenverbrauch, die Richtlinien für Inhaltsschlüssel und die Streamrichtlinien überprüfen und die Kontingentgrenzen für Entitäten erhöhen, die nahe am Grenzwert liegen. Zur Anforderung einer Erhöhung der Kontingentgrenzen können Sie ein Ticket mit den relevanten Angaben erstellen. Tipp: Erstellen Sie keine zusätzlichen Azure Media-Konten, um höhere Grenzwerte zu erhalten.
Potenzielle Vorteile: Vermeiden von Dienstunterbrechungen infolge der Überschreitung von Kontingentgrenzen durch Kunden.
Weitere Informationen finden Sie unter Azure Media Services-Kontingente und -Grenzwerte.
Service Bus
Verwenden des Service Bus Premium-Tarifs für bessere Resilienz
Bei der Ausführung kritischer Anwendungen sorgt der Service Bus Premium-Tarif für eine bessere Ressourcenisolation auf CPU- und Arbeitsspeicherebene und verbessert so die Verfügbarkeit. Er unterstützt außerdem das Feature für die georedundante Notfallwiederherstellung und erleichtert damit die Wiederherstellung bei regionalen Ausfällen, ohne dass Anwendungskonfigurationen geändert werden müssen.
Potenzielle Vorteile: Die Service Bus Premium-Stufe bietet bessere Resilienz mit CPU- und Speicherressourcenisolation sowie georedundanter Notfallwiederherstellung
Weitere Informationen finden Sie unter Service Bus Premium-Messaging Ebene.
Verwenden der automatischen Skalierung von Service Bus im Premium-Tarif für bessere Resilienz
Beim Ausführen wichtiger Anwendungen können Sie durch Aktivierung der automatischen Skalierung sicherstellen, dass Sie über genügend Kapazität zur Bewältigung der Lasten für die Anwendungen verfügen. Die richtige Menge an Ressourcen kann die Drosselung verringern und ein besseres Benutzererlebnis bieten.
Potenzielle Vorteile: Das Aktivieren von Autoscale verhindert Kapazitätsbeschränkungen für Benutzer
Weitere Informationen finden Sie unter Automatisches Aktualisieren von Messagingeinheiten eines Azure Service Bus-Namespace.
SQL Server auf virtuellen Azure-Computern
Aktivieren von Azure Backup für SQL auf Ihren virtuellen Computern
Aktivieren Sie Sicherungen für SQL-Datenbanken auf Ihren virtuellen Maschinen mit Azure Backup, um von den Vorteilen der Sicherung ohne Infrastruktur, der Zeitpunktwiederherstellung (Point-in-Time) und der zentralen Verwaltung mit SQL AG-Integration zu profitieren.
Potenzielle Vorteile: SQL-fähige Sicherungen ohne Infrastruktur für Sicherung, zentrale Verwaltung, AG-Integration und Zeitpunktwiederherstellung
Weitere Informationen finden Sie unter Informationen zur SQL Server-Sicherung auf virtuellen Azure-Computern.
Storage
Verwenden von verwalteten Datenträgern für Speicherkonten, für die die Kapazitätsgrenze erreicht wird
Wenn nicht verwaltete SSD Premium-Datenträger in Speicherkonten sich ihrer Storage Premium-Kapazitätsgrenze nähern, können Fehler auftreten. Um beim Erreichen der Grenze Fehler zu vermeiden, sollten Sie zu verwalteten Datenträgern ohne Obergrenze für die Kontokapazität migrieren. Sie können diese Migration in weniger als fünf Minuten über das Portal durchführen.
Potenzielle Vorteile: Vermeiden von Skalierungsproblemen bei Erreichen der Kapazitätsgrenze für ein Konto
Weitere Informationen finden Sie unter Skalierbarkeits- und Leistungsziele für Storage Standard-Konten.
Konfigurieren einer Blobsicherung
Die Sicherung von Azure-Blobs schützt Daten vor versehentlicher oder böswilliger Löschung. Es wird empfohlen, die Blobsicherung zu konfigurieren.
Potenzielle Vorteile: Schützen von Daten vor versehentlicher oder böswilliger Löschung
Weitere Informationen finden Sie in der Übersicht über die Sicherung von Azure-Blobs.
Abonnements
Aktivieren Sie Azure Backup, um einfachen, zuverlässigen und kostengünstigen Schutz für Ihre Daten zu erhalten.
Schützen Sie Ihre Informationen und Anwendungen mit einem Klick sicher in 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.
Potenzielle Vorteile: Sicherstellen, dass Ihre geschäftskritischen Anwendungen geschützt bleiben
Weitere Informationen finden Sie in der Dokumentation zu Azure Backup: Azure Backup .
Erstellen Sie eine Azure Service Health-Warnung
Azure Service Health-Warnungen halten Sie über Probleme und Hinweise in vier Bereichen (Dienstprobleme, geplante Wartung, Hinweise zu Sicherheit und Gerätezustand) auf dem Laufenden. Diese Warnungen sind personalisiert, um Sie über Störungen oder mögliche Auswirkungen auf die von Ihnen ausgewählten Azure-Regionen und -Dienste zu informieren.
Potenzielle Vorteile: Bleiben Sie über Probleme und Empfehlungen in 4 Bereichen auf dem Laufenden (Serviceprobleme, geplante Wartung, Sicherheitshinweise und Integritätshinweise).
Weitere Informationen finden Sie unter Erstellen von Aktivitätsprotokollwarnungen zu Dienstbenachrichtigungen über das Azure-Portal.
Virtual Machines
Verbessern Sie die Datenzuverlässigkeit, indem Sie Managed Disks verwenden
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.
Potenzielle Vorteile: Gewährleistung von Geschäftskontinuität durch Datenresilienz
Weitere Informationen finden Sie unter https://aka.ms/aa_avset_manageddisk_learnmore.
Aktivieren der Replikation von virtuellen Computern zum Schützen Ihrer Anwendungen vor regionalen Ausfällen
VMs sind gegenüber regionalen Ausfällen resilient, wenn Replikation in eine andere Region aktiviert ist. Um negative geschäftliche Auswirkungen während eines Ausfalls der Azure-Region zu verringern, wird empfohlen, die Replikation aller geschäftskritischen VMs zu aktivieren.
Potenzielle Vorteile: Sicherstellen der Geschäftskontinuität beim Ausfall einer Azure-Region
Weitere Informationen finden Sie unter Schnellstart: Einrichten der Notfallwiederherstellung in einer sekundären Azure-Region für einen virtuellen Azure-Computer.
Aktualisieren Ihres Protokolls für ausgehende Konnektivität auf Diensttags für Azure Site Recovery
IP-adressbasierte Positivlisten sind eine anfällige Möglichkeit, die ausgehende Konnektivität für Firewalls zu steuern. Diensttags stellen eine gute Alternative dar. Wir empfehlen Ihnen dringend, Diensttags zu verwenden, um die Konnektivität mit Azure Site Recovery-Diensten für die Computer zu ermöglichen.
Potenzielle Vorteile: Höhere Sicherheit, Stabilität und Resilienz als hartcodierte IP-Adressen
Weitere Informationen finden Sie unter Informationen zu Netzwerken für die Notfallwiederherstellung für virtuelle Azure-Computer.
Die an Ihre Premium-fähige VM angefügten Standard-Datenträger auf Premium-Datenträger aktualisieren
Der Einsatz von SSD Standard-Datenträgern mit Premium-VMs kann zu Problemen aufgrund einer suboptimalen Leistung und Latenz führen. Sie sollten das Upgrade der Standard- auf Premium-Datenträger in Erwägung ziehen. Wir garantieren für jeden virtuellen Einzelinstanzcomputer, bei dem Storage Premium für alle Betriebssystem-Datenträger und regulären Datenträger verwendet wird, eine Konnektivität von mindestens 99,9 %. Bei der Entscheidung für ein Upgrade sind zwei Faktoren zu berücksichtigen. 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.
Potenzielle Vorteile: Verbesserte Verfügbarkeit mit einer Vereinbarung zum Servicelevel für eine einzelne VM ist nur verfügbar, wenn es sich bei allen Datenträgern um Premium-Datenträger handelt.
Weitere Informationen finden Sie unter Azure verwaltete Festplattentypen.
Aktualisieren einer VM von nicht verwalteten Premium-Datenträgern auf verwaltete Datenträger ohne zusätzliche Kosten
Azure Managed Disks bietet eine höhere Resilienz, eine vereinfachte Dienstverwaltung, ein höheres Skalierungsziel und eine größere Auswahl von Datenträgertypen. Ihre VM nutzt nicht verwaltete Premium-Datenträger, die ohne zusätzliche Kosten in weniger als 5 Minuten zu verwalteten Datenträgern migriert werden können.
Potenzielle Vorteile: Nutzen der höheren Resilienz und anderer Vorteile von Managed Disks
Weitere Informationen finden Sie in der Einführung in verwaltete Azure-Datenträger.
Aktualisieren Sie Ihr veraltetes Image der virtuellen Maschine auf ein neueres Image
Virtuelle Maschinen (VMs) 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. Um eine Unterbrechung Ihrer Workloads zu vermeiden, sollten Sie ein Upgrade auf ein neueres Image durchführen. (VMRunningDeprecatedImage)
Potenzielle Vorteile: Minimieren potenzieller Störungen für Ihre VM-Workloads
Weitere Informationen finden Sie unter Veraltete Azure Marketplace-Images: Azure Virtual Machines .
Upgrade auf ein neueres Angebot des Images für virtuelle Maschinen
Virtuelle Maschinen (VMs) 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. Um eine Unterbrechung Ihrer Workloads zu vermeiden, sollten Sie ein Upgrade auf ein neueres Image durchführen. (VMRunningDeprecatedOfferLevelImage)
Potenzielle Vorteile: Minimieren potenzieller Störungen für Ihre VM-Workloads
Weitere Informationen finden Sie unter Veraltete Azure Marketplace-Images: Azure Virtual Machines .
Upgrade auf eine neuere SKU des Images für virtuelle Maschinen
Virtuelle Maschinen (VMs) 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. Um eine Unterbrechung Ihrer Workloads zu vermeiden, sollten Sie ein Upgrade auf ein neueres Image durchführen.
Potenzielle Vorteile: Minimieren potenzieller Störungen für Ihre VM-Workloads
Weitere Informationen finden Sie unter Veraltete Azure Marketplace-Images: Azure Virtual Machines .
Upgraden Ihrer VM-Skalierungsgruppe auf eine alternative Imageversion
VM-Skalierungsgruppen in Ihrem Abonnement basieren auf Images, deren Unterstützung eingestellt wird. Wenn das Image veraltet ist, werden Ihre VM-Skalierungsgruppenworkloads nicht mehr aufskaliert. Upgraden Sie auf eine neuere Version des Images, um Störungen bei Ihrer Workload vorzubeugen.
Potenzielle Vorteile: Minimieren potenzieller Störungen für Ihre VMSS-Workloads
Weitere Informationen finden Sie unter Veraltete Azure Marketplace-Images: Azure Virtual Machines .
Upgraden Ihrer VM-Skalierungsgruppe auf ein alternatives Imageangebot
VM-Skalierungsgruppen in Ihrem Abonnement basieren auf Images, deren Unterstützung eingestellt wird. Wenn das Image veraltet ist, werden Ihre VM-Skalierungsgruppenworkloads nicht mehr aufskaliert. Upgraden Sie auf ein neueres Angebot des Images, um Störungen bei Ihrer Workload vorzubeugen.
Potenzielle Vorteile: Minimieren potenzieller Störungen für Ihre VMSS-Workloads
Weitere Informationen finden Sie unter Veraltete Azure Marketplace-Images: Azure Virtual Machines .
Upgraden Ihrer VM-Skalierungsgruppe auf eine alternative Image-SKU
VM-Skalierungsgruppen in Ihrem Abonnement basieren auf Images, deren Unterstützung eingestellt wird. Wenn das Image veraltet ist, werden Ihre VM-Skalierungsgruppenworkloads nicht mehr aufskaliert. Upgraden Sie auf eine neuere SKU des Images, um Störungen bei Ihrer Workload vorzubeugen.
Potenzielle Vorteile: Minimieren potenzieller Störungen für Ihre VMSS-Workloads
Weitere Informationen finden Sie unter Veraltete Azure Marketplace-Images: Azure Virtual Machines .
Ermöglichen Sie den Zugriff auf obligatorische URLs, die für Ihre Azure Virtual Desktop-Umgebung fehlen
Damit ein Sitzungshost ordnungsgemäß bereitgestellt und bei Windows Virtual Desktop (WVD) registriert werden kann, benötigen Sie eine Reihe von URLs in der „zulässigen Liste“, falls Ihre VM in einer eingeschränkten Umgebung läuft. Für bestimmte URLs, die in der Zulassungsliste fehlen, suchen Sie in Ihrem Protokoll mit den Anwendungsereignissen nach Ereignis 3702.
Potenzielle Vorteile: Sicherstellen einer erfolgreichen Bereitstellung und Sitzungshostfunktionalität bei Verwendung des Windows Virtual Desktop-Diensts
Weitere Informationen finden Sie unter Erforderliche FQDNs und Endpunkte für Azure Virtual Desktop.
Abgleich des Standorts von Ressource und Ressourcengruppe
Um die Auswirkungen von Ausfällen in einer Region zu verringern, sollten Sie Ihre Ressourcen zusammen mit ihrer Ressourcengruppe in derselben Region unterbringen. Auf diese Weise speichert Azure Resource Manager Metadaten für alle Ressourcen innerhalb der Gruppe in einer Region. Durch die gemeinsame Nutzung eines Standorts verringern Sie das Risiko, von der Nichtverfügbarkeit einer Region betroffen zu sein.
Potenzielle Vorteile: Reduzieren von Schreibfehlern aufgrund von Regionsausfällen
Weitere Informationen finden Sie unter Was ist Azure Resource Manager?.
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.
Potenzielle Vorteile: Die Nutzung von zonalen VMs schützt Ihre Apps vor zonalen Ausfällen in allen anderen Zonen.
Weitere Informationen finden Sie unter Verschieben virtueller Azure-Computer mit einer einzelnen Instanz von regionalen zu zonalen Verfügbarkeitszonen.
Aktivieren der Überwachung des Zustands der Azure Virtual Machine Scale Set (VMSS) Anwendung
Wenn Sie die Anwendungsintegritätsüberwachung von VM-Skalierungsgruppen unter Verwendung der Application Health-Erweiterung oder unter Verwendung von Lastenausgleichs-Integritätstests konfigurieren, kann die Azure-Plattform die Resilienz Ihrer Anwendung verbessern, indem sie auf Veränderungen bei der Anwendungsintegrität reagiert.
Potenzielle Vorteile: Erhöhen der Resilienz durch die Bereitstellung des Anwendungsstatus für Azure
Weitere Informationen finden Sie unter Verwenden der Application Health-Erweiterung mit Virtual Machine Scale Sets.
Aktivieren von Sicherungen auf virtuellen Computern
Schützen Sie Ihre Daten durch Aktivierung von Backups für Ihre virtuellen Maschinen.
Potenzielle Vorteile: Schutz von virtuellen Computern
Weitere Informationen finden Sie unter Worum handelt es sich beim Azure Backup-Dienst?.
Aktivieren der Richtlinie zur automatischen Reparatur in Azure Virtual Machine Scale Sets (VMSS)
Durch das Aktivieren der automatischen Reparatur von Instanzen können Sie Hochverfügbarkeit erreichen, indem Sie eine Gruppe von fehlerfreien Instanzen aufrechterhalten. Wenn von der Erweiterung zur Anwendungsintegrität oder beim Integritätstest für Load Balancer eine fehlerhafte Instanz gefunden wird, wird im Rahmen automatischer Instanzreparaturen versucht, die Instanz durch Reparaturmaßnahmen wiederherzustellen.
Potenzielle Vorteile: Erhöhen der Resilienz durch die Automatisierung der Reparatur fehlgeschlagener Instanzen
Weitere Informationen finden Sie unter Automatische Instanzreparaturen für Azure Virtual Machine Scale Sets.
Konfigurieren der automatisierten Skalierung von VM-Skalierungsgruppen anhand von Metriken
Optimieren Sie die Ressourcenauslastung, verringern Sie die Kosten, und verbessern Sie die Anwendungsleistung mithilfe einer benutzerdefinierten metrikbasierten Autoskalierung. Fügen Sie basierend auf Echtzeitmetriken wie CPU-Auslastung, Arbeitsspeicherauslastung und Datenträgervorgängen automatisch Instanzen virtueller Computer hinzu. Gewährleisten Sie gleichzeitig Hochverfügbarkeit und Kosteneffizienz.
Potenzielle Vorteile: Gewährleisten von Hochverfügbarkeit bei gleichzeitiger Kosteneffizienz
Weitere Informationen finden Sie in der Übersicht über die automatische Skalierung mit Azure-VM-Skalierungsgruppen.
Verwenden von Azure-Datenträgern mit zonenredundantem Speicher (ZRS) 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. Für höhere Resilienz und Verfügbarkeit sollten Sie Datenträger von LRS zu ZRS migrieren.
Potenzielle Vorteile: Indem Sie Ihre Anwendungen für die Verwendung von ZRS-Datenträgern entwerfen, werden Ihre Daten in 3 Verfügbarkeitszonen repliziert, wodurch Ihr Datenträger gegenüber einem zonalen Ausfall resilienter ist.
Weitere Informationen finden Sie unter Konvertieren eines Datenträgers von LRS zu ZRS.
Workloads (Arbeitslasten)
Konfigurieren einer Always On-Verfügbarkeitsgruppe für MPSQL-Server (Multi-Purpose SQL)
MPSQL-Server mit einer Always On-Verfügbarkeitsgruppe haben eine bessere Verfügbarkeit. Ihre MPSQL-Server sind nicht als Teil einer Always On-Verfügbarkeitsgruppe in der freigegebenen Infrastruktur in Ihrem Epic-System konfiguriert. Always On-Verfügbarkeitsgruppen verbessern die Datenbankverfügbarkeit und die Ressourcenverwendung.
Potenzielle Vorteile: Verbesserte Datenbankverfügbarkeit und Ressourcennutzung
Weitere Informationen finden Sie unter Was ist eine Always On-Verfügbarkeitsgruppe?.
Konfigurieren des lokalen Hostcaches auf Citrix VDI-Servern, um nahtlose Verbindungsbrokervorgänge sicherzustellen
Wir haben festgestellt, dass Ihre Citrix-VDI-Server nicht für lokalen Hostcache konfiguriert sind. Der lokale Hostcache (LHC) ist ein Feature in Citrix Virtual Apps und Desktops, mit dem Verbindungsbrokeroperationen fortgesetzt werden können, wenn ein Ausfall auftritt. LHC wird aktiviert, wenn auf die Websitedatenbank 90 Sekunden nicht zugegriffen werden kann.
Potenzielle Vorteile: Nahtlose Verbindungsbrokervorgänge
Bereitstellen von Hyperspace-Webservern als Teil einer VM-Skalierungsgruppe vom Typ „Flex“, die für drei Zonen konfiguriert ist
Wir haben festgestellt, dass Ihre Hyperspace Web-Server im VM-Skalierungsgruppen-Setup vom Typ „Flex“ nicht auf drei Zonen in der ausgewählten Region verteilt sind. Für Dienste wie Hyperspace Web in Epic-Systemen, die Hochverfügbarkeit und einen großen Umfang erfordern, wird empfohlen, Server als Teil von VM-Skalierungsgruppen vom Typ „Flex“ bereitzustellen und sie auf drei Zonen zu verteilen. Im Orchestrierungsmodus „Flexibel“ können Sie im gesamten Azure-VM-Ökosystem eine einheitliche Benutzeroberfläche nutzen
Potenzielle Vorteile: Hochverfügbarkeit und Skalierung im großen Umfang bei Bedarf für Hyperspace-Webserver in Epic DB
Weitere Informationen finden Sie unter Erstellen einer VM-Skalierungsgruppe, die Verfügbarkeitszonen verwendet.
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 Einstellungen hinzu oder bearbeiten Sie sie.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Aktivieren von Floating IP in Azure Load Balancer für ASCS-Hochverfügbarkeitssetup in SAP-Workloads
Für die Wiederverwendung von Ports und eine bessere Hochverfügbarkeit, 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 hinzu oder bearbeiten Sie sie.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Aktivieren von Hochverfügbarkeitsports in Azure Load Balancer für ASCS-Hochverfügbarkeitssetup in SAP-Workloads
Für die Wiederverwendung von Ports und eine bessere Hochverfügbarkeit, 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 hinzu oder bearbeiten Sie sie.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
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. Die Aktivierung von TCP-Zeitstempeln führt zu Fehlern bei den Integritätstests, da TCP-Pakete vom TCP-Stapel des virtuellen Gastbetriebssystems des virtuellen Computers gelöscht werden, was wiederum dazu führt, dass der Lastenausgleich den Endpunkt als ausgefallen markiert.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter https://launchpad.support.sap.com/#/notes/2382421.
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 oder bearbeiten Sie sie.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Aktivieren von Floating IP in Azure Load Balancer für HANA DB-Hochverfügbarkeitssetup in SAP-Workloads
Für ein flexibleres Routing, 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 oder bearbeiten Sie sie.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Aktivieren von Hochverfügbarkeitsports in Azure Load Balancer für HANA DB-Hochverfügbarkeitssetup in SAP-Workloads
Zur verbesserten Skalierbarkeit, 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 oder bearbeiten Sie sie.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
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. Die Aktivierung von TCP-Zeitstempeln führt zu Fehlern bei den Integritätstests, da TCP-Pakete vom TCP-Stapel des virtuellen Gastbetriebssystems des virtuellen Computers gelöscht werden, was wiederum dazu führt, dass der Lastenausgleich den Endpunkt als ausgefallen markiert.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Azure Load Balancer-Integritätstests.
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). Um die Verwaltung ausgefallener Knoten zu erleichtern, stellen Sie sicher, dass „stonith-enable“ in der Hochverfügbarkeit-Clusterkonfiguration auf „true“ gesetzt ist.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit von SAP HANA auf Azure-VMs unter Red Hat Enterprise Linux.
Festlegen des corosync-Tokens im Pacemaker-Cluster auf 30000 für das ASCS HA-Setup in SAP-Workloads (RHEL)
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. Um eine speichererhaltende Wartung zu ermöglichen, legen Sie das Corosync-Token für SAP in Azure auf 30000 fest.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit von SAP HANA auf Azure-VMs unter Red Hat Enterprise Linux.
Festlegen des Parameters für erwartete Stimmen in der Pacemaker-Konfiguration im ASCS HA-Setup in SAP-Workloads (RHEL) auf „2“
Für einen HA-Cluster mit zwei Knoten setzen Sie den Quorum-Parameter „expected_votes“ auf „2“, wie für SAP in Azure empfohlen, um ein angemessenes Quorum, Resilienz und Datenkonsistenz zu gewährleisten.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit von SAP HANA auf Azure-VMs unter Red Hat Enterprise Linux.
Aktivieren des Parameters „concurrent-fencing“ in der Pacemaker-Konfiguration für das ASCS HA-Setup in SAP-Workloads (ConcurrentFencingHAASCSRH)
Gleichzeitige Umgrenzung ermöglicht die parallele Durchführung der Fencing-Vorgänge, was hohe Verfügbarkeit (HA) verbessert, Split-Brain-Szenarien verhindert und zu einer robusten SAP-Bereitstellung beiträgt. Legen Sie diesen Parameter in der Pacemaker-Clusterkonfiguration für das ASCS Hochverfügbarkeitssetup auf „true“ fest.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit von SAP HANA auf Azure-VMs unter Red Hat Enterprise Linux.
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). Um die Verwaltung ausgefallener Knoten zu erleichtern, stellen Sie sicher, dass „stonith-enable“ in der Hochverfügbarkeit-Clusterkonfiguration auf „true“ gesetzt ist.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Legen Sie für die Clusterkonfiguration im ASCS HA-Setup in SAP-Workloads das stonith-Timeout auf 144 fest.
„Stonith-Timeout“ gibt an, wie lange der Cluster auf den Abschluss einer STONITH-Aktion wartet. Das Festlegen auf „144“ Sekunden ermöglicht mehr Zeit zum Abschließen von Fencing-Aktionen. Wir empfehlen diese Einstellung für HA-Cluster für SAP in Azure.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Festlegen des corosync-Tokens im Pacemaker-Cluster auf 30000 für das ASCS HA-Setup in SAP-Workloads (SUSE)
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. Um eine speichererhaltende Wartung zu ermöglichen, setzen Sie das corosync-Token auf „30000“ für SAP in Azure.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
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 in Hochverfügbarkeits-Clustern vor dem Timeout versucht werden. Legen Sie für Stabilität und Zuverlässigkeit den „totem.token_retransmits_before_loss_const“ auf „10“ für die ASCS HA-Einrichtung fest.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Das Timeout "corosync join" gibt in Millisekunden an, wie lange auf Join-Nachrichten im Mitgliedschaftsprotokoll gewartet werden soll, damit ein neuer Knoten, der dem Cluster beitritt, Zeit hat, seinen Status mit den bestehenden Knoten zu synchronisieren. In der Pacemaker-Clusterkonfiguration für das ASCS HA-Setup den Wert auf „60“ festlegen.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Festlegen von „corosync consensus“ im Pacemaker-Cluster auf „36000“ für das ASCS HA-Setup in SAP-Workloads
Der corosync „consensus“ Parameter 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. Legen Sie „consensus“ in der Pacemaker-Clusterkonfiguration für ASCS HA-Setup auf das 1,2-fache des corosync-Tokens für ein zuverlässiges Failover-Verhalten.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
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 können. Setzen Sie ihn auf das 20-fache des corosync-Token-Parameters in der Pacemaker-Cluster-Konfiguration, um eine effiziente Kommunikation zu ermöglichen, ohne das Netzwerk zu überlasten.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Setzen Sie in der Clusterkonfiguration bei der Einrichtung von ASCS HA in SAP-Workloads (SUSE) „erwartete Stimmen“ auf „2“.
Für einen HA-Cluster mit zwei Knoten setzen Sie den Quorum-Parameter „expected_votes“ auf 2, wie für SAP in Azure empfohlen, um ein angemessenes Quorum, Resilienz und Datenkonsistenz zu gewährleisten.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
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.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Aktivieren von „gleichzeitiger Umgrenzung“ in Pacemaker ASCS HA Setup in SAP-Workloads (ConcurrentFencingHAASCSSLE)
Gleichzeitige Umgrenzung ermöglicht die parallele Durchführung der Fencing-Vorgänge, was Hochverfügbarkeit verbessert, Split-Brain-Szenarien verhindert und zu einer robusten SAP-Bereitstellung beiträgt. Legen Sie diesen Parameter in der Pacemaker-Clusterkonfiguration für das ASCS Hochverfügbarkeitssetup auf „true“ fest.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Sicherstellen, dass die Anzahl der Instanzen von „fence_azure_arm“ im Pacemaker in SAP-Workloads mit Hochverfügbarkeitsunterstützung eins ist.
Wenn Sie den Azure-Fence-Agent für die Umgrenzung mit verwalteter Identität oder Dienstprinzipal verwenden, stellen Sie sicher, dass eine Instanz von fence_azure_arm (ein E/A-Umgrenzungs-Agent für Azure Resource Manager) in der Pacemaker-Konfiguration für ASCS HA-Setup für hohe Verfügbarkeit vorhanden ist.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
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 ASCS-HA Festlegung zuverlässig funktioniert. Diese Einstellung gilt, wenn Sie den Azure-Fence-Agent für das Fencing mit verwalteter Identität oder dem Dienstprinzipal verwenden.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
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. Sicherstellen, dass die Softdog-Konfigurationsdatei im Pacemaker-Cluster für ein ASCS-Hochverfügbarkeitssetup erstellt wird
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
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.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
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 SAP HANA legt fest, ob der HANA System–Replikation (SR) Ressourcen-Agent die Übernahme der sekundären Instanz vorzieht, anstatt die ausgefallene primäre Instanz lokal neu zu starten. Legen Sie für eine zuverlässige Funktion der HANA DB hohe Verfügbarkeit (HA)-Einrichtung PREFER_SITE_TAKEOVER auf „true“ fest.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit von SAP HANA auf Azure-VMs unter Red Hat Enterprise Linux.
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). Um die Verwaltung ausgefallener Knoten zu erleichtern, stellen Sie sicher, dass „stonith-enable“ in der Hochverfügbarkeit-Clusterkonfiguration Ihrer SAP-Workload auf „true“ gesetzt ist.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit von SAP HANA auf Azure-VMs unter Red Hat Enterprise Linux.
Setzen Sie das Corosync-Token im Pacemaker-Cluster auf 30000 für Hochverfügbarkeit-aktivierte HANA DB für VM mit RHEL 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. Um eine speichererhaltende Wartung zu ermöglichen, legen Sie das Corosync-Token für SAP in Azure mit Redhat OS auf 30000 fest.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit von SAP HANA auf Azure-VMs unter Red Hat Enterprise Linux.
Setzen Sie den Parameter Erwartete Stimmen in HA-fähigen SAP-Workloads (RHEL) auf „2“
Für einen HA-Cluster mit zwei Knoten setzen Sie den Quorum-Parameter Abstimmungen auf „2“, wie für SAP in Azure empfohlen, um ein angemessenes Quorum, Resilienz und Datenkonsistenz zu gewährleisten.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit von SAP HANA auf Azure-VMs unter Red Hat Enterprise Linux.
Aktivieren des Parameters „concurrent-fencing“ in der Pacemaker-Konfiguration für das HANA DB HA-Setup
Gleichzeitige Umgrenzung ermöglicht die parallele Durchführung der Fencing-Vorgänge, was hohe Verfügbarkeit (HA) verbessert, Split-Brain-Szenarien verhindert und zu einer robusten SAP-Bereitstellung beiträgt. Legen Sie diesen Parameter in der Pacemaker-Clusterkonfiguration für das HANA DB Hochverfügbarkeitssetup auf „true“ fest.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit von SAP HANA auf Azure-VMs unter Red Hat Enterprise Linux.
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 der sekundären 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.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
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). Um die Verwaltung ausgefallener Knoten zu erleichtern, stellen Sie sicher, dass „stonith-enable“ in der Hochverfügbarkeit-Clusterkonfiguration auf „true“ gesetzt ist.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Legen Sie das stonith-Timeout für die Clusterkonfiguration in Hochverfügbarkeit-aktivierten SAP-Workloads auf 144 fest
„Stonith-Timeout“ gibt an, wie lange der Cluster auf den Abschluss einer STONITH-Aktion wartet. Das Festlegen auf „144“ Sekunden ermöglicht mehr Zeit zum Abschließen von Fencing-Aktionen. Wir empfehlen diese Einstellung für HA-Cluster für SAP in Azure.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
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 auf 30000 für HA-aktivierte HANA DB für VM mit SUSE OS fest, um die speichererhaltende Wartung zu ermöglichen.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
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 HA Setup fest.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Festlegen von „corosync join“ im Pacemaker-Cluster auf 60 für HA-fähige HANA DB in SAP-Workloads
Das Timeout "corosync join" gibt in Millisekunden an, wie lange auf Join-Nachrichten im Mitgliedschaftsprotokoll gewartet werden soll, damit ein neuer Knoten, der dem Cluster beitritt, Zeit hat, seinen Status mit den bestehenden Knoten zu synchronisieren. In der Pacemaker-Clusterkonfiguration für das HANA DB HA-Setup den Wert „60“ festlegen.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Festlegen von „corosync consensus“ im Pacemaker-Cluster auf 36000 für HA-fähige HANA DB in SAP-Workloads
Der corosync „consensus“-Parameter gibt in Millisekunden an, wie lange gewartet werden soll, bis ein Konsens erreicht ist, bevor eine neue Runde der Mitgliedschaft im Cluster gestartet wird. Für ein zuverlässiges Failover-Verhalten, legen Sie „consensus“ in der Pacemaker-Clusterkonfiguration für HANA HA-Setup auf das 1,2-fache des corosync-Tokens.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
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 können. Um eine effiziente Kommunikation zu ermöglichen, ohne das Netzwerk zu überlasten, setzen Sie ihn auf das 20-fache des corosync-Token-Parameters in der Pacemaker-Cluster-Konfiguration.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Setzen Sie den Parameter Erwartete Stimmen in Hochverfügbarkeit-aktivierten SAP-Workloads (SUSE) auf 2
Legen Sie den erwarteten Abstimmungsparameter in der Clusterkonfiguration in HA-fähigen SAP-Workloads auf „2“ fest, um ein ordnungsgemäßes Quorum, Resilienz und Datenkonsistenz sicherzustellen.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
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.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Aktivieren des Parameters „concurrent-fencing“ in der Clusterkonfiguration in HA-fähigen SAP-Workloads
Gleichzeitige Umgrenzung ermöglicht die parallele Durchführung der Fencing-Vorgänge, was Hochverfügbarkeit verbessert, Split-Brain-Szenarien verhindert und zu einer robusten SAP-Bereitstellung beiträgt. Legen Sie diesen Parameter in HA-fähigen SAP-Workloads auf „true“ fest.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Stellen Sie sicher, dass in der Pacemaker-Konfiguration für das HANA DB-Hochverfügbarkeitssetup genau eine Instanz von „fence_azure_arm“ vorhanden ist.
Wenn Sie den Azure-Fence-Agent für die Umgrenzung mit verwalteter Identität oder Dienstprinzipal verwenden, stellen Sie sicher, dass eine Instanz von fence_azure_arm (ein E/A-Umgrenzungs-Agent für Azure Resource Manager) in der Pacemaker-Konfiguration für HANA DB HA-Setup für hohe Verfügbarkeit vorhanden ist.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Festlegen von „stonith-timeout“ auf „900“ in der Pacemaker-Konfiguration mit Azure-Fence-Agent für ein HANA DB-Hochverfügbarkeitssetup
Wenn Sie den Azure-Fence-Agent zur Umgrenzung mit verwalteter Identität oder Dienstprinzipal verwenden, stellen Sie eine zuverlässige Funktion des Pacemaker für HANA DB HA-Setups sicher, indem Sie das „Stonith-Timeout“ auf 900 festlegen.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Sicherstellen, dass die Softdog-Konfigurationsdatei in der Pacemaker-Konfiguration für HANA DB in SAP-Workloads vorhanden 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 sicher, dass die Softdog-Konfigurationsdatei im Pacemaker-Cluster für ein HANA DB-Hochverfügbarkeitssetup erstellt wird.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Sicherstellen, dass das Softdog-Modul in 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 ein HANA DB-Hochverfügbarkeitssetup.
Potenzielle Vorteile: Zuverlässigkeit des Hochverfügbarkeits-Setups in SAP-Workloads
Weitere Informationen finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server.
Nächste Schritte
Erfahren Sie mehr über Zuverlässigkeit: Microsoft Azure Well-Architected Framework.