Empfehlungen für optimalen Betrieb
Empfehlungen zum optimalen Betrieb in Azure Advisor können Sie bei folgenden Aspekten unterstützen:
- Effizienz von Prozess und Workflow
- Verwaltbarkeit von Ressourcen
- Best Practices für die Bereitstellung
Diese Empfehlungen stehen Ihnen auf der Registerkarte Erstklassige Betriebsprozesse des Advisor-Dashboards zur Verfügung.
- 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 auf dem Dashboard Advisor die Registerkarte Optimaler Betrieb aus.
KI und Machine Learning
Upgrade auf die neueste Version des SDK des plastischen Readers
Wir haben unter diesem Abonnement Ressourcen mit veralteten Versionen des Azure Immersive Reader-SDKs identifiziert. Die neueste Version des Immersive Reader SDK bietet aktualisierte Sicherheit, Leistung und einen erweiterten Satz von Features, mit denen Sie Ihre Integrationsmöglichkeiten anpassen und verbessern können.
Weitere Informationen zu Azure KI Plastischer Reader (Azure KI Immersive Reader)
Upgrade auf die neueste Version des SDK des plastischen Readers
Wir haben unter diesem Abonnement Ressourcen mit veralteten Versionen des Azure Immersive Reader-SDKs identifiziert. Die neueste Version des Immersive Reader SDK bietet aktualisierte Sicherheit, Leistung und einen erweiterten Satz von Features, mit denen Sie Ihre Integrationsmöglichkeiten anpassen und verbessern können.
Analyse
Reduzieren der Cacherichtlinie für die Data Explorer-Tabellen
Reduzieren Sie die Richtlinie für Tabellenzwischenspeicherung, um sie an die Verbrauchsmuster anzupassen (Abfragerückblickzeitraum).
Compute
Aktualisieren Ihres veralteten Azure Spring Apps SDK auf die aktuelle Version
Wir haben API-Aufrufe von einem veralteten Azure Spring Apps-SDK erkannt. Es wird empfohlen, ein Upgrade auf die neueste Version durchzuführen, um aktuelle Fixes, Leistungsverbesserungen und neue Funktionen zu erhalten.
Weitere Informationen zum Azure Spring Apps-Dienst.
Aktualisieren der Spring Apps-API-Version
Wir haben API-Aufrufe von einer veralteten Azure Spring Apps-API für Ressourcen unter diesem Abonnement identifiziert. Es wird empfohlen, zur neuesten Versionen der Azure Spring Apps-API zu wechseln. Sie müssen Ihren vorhandenen Code aktualisieren, um die neueste API-Version zu verwenden. Sie müssen außerdem das Azure SDK und die Azure CLI auf die neueste SDK-Version aktualisieren, um die neuesten Features und Leistungsverbesserungen sicherzustellen.
Weitere Informationen zum Azure Spring Apps-Dienst.
Neue HCX-Version für Upgrade verfügbar
Ihre HCX-Version ist nicht aktuell. Eine neue HCX-Version ist für ein Upgrade verfügbar. Beim Aktualisieren eines VMware HCX-Systems werden die neuesten Features, Problembehebungen und Sicherheitspatches installiert.
Erfahren Sie mehr über AVS Private Cloud – HCXVersion (neue HCX-Version zum Upgrade verfügbar).
Neuerstellen Ihres Pools, um die neuesten Features und Fixes für den Knoten-Agent zu erhalten
Der Knoten-Agent Ihres Pools ist nicht auf dem neuesten Stand. Es empfiehlt sich gegebenenfalls, den Pool neu zu erstellen, um die neuesten Updates und Fehlerbehebungen für den Knoten-Agent zu erhalten.
Löschen und erneutes Erstellen Ihres Pools, um eine veraltete interne Komponente zu entfernen
Von Ihrem Pool wird eine veraltete interne Komponente verwendet. Löschen Sie Ihren Pool, und erstellen Sie ihn neu, um die Stabilität und Leistung zu verbessern.
Upgraden auf die aktuelle API-Version, um sicherzustellen, dass Ihr Batch-Konto weiterhin verwendet werden kann
In den letzten 14 Tagen haben Sie eine Version der Batchverwaltungs- oder Dienst-API aufgerufen, die für die Veralterung vorgesehen ist. Führen Sie ein Upgrade auf die aktuelle API-Version durch, um sicherzustellen, dass Ihr Batch-Konto weiterhin verwendet werden kann.
Löschen und erneutes Erstellen Ihres Pools mit einer anderen VM-Größe
In Ihrem Pool werden VMs vom Typ „A8“ bis „A11“ genutzt, deren Verwendung im März 2021 eingestellt wird. Löschen Sie den Pool, und erstellen Sie ihn mit einer anderen VM-Größe neu.
Weitere Informationen finden Sie unter Batch-Konto: RemoveA8_A11Pools (Löschen und erneutes Erstellen Ihres Pools mit einer anderen VM-Größe.)
Neuerstellen Ihres Pools mit einem neuen Image
Ihr Pool verwendet ein Image, dessen Ablaufdatum bevorsteht. Um mögliche Unterbrechungen zu vermeiden, sollten Sie den Pool mit einem neuen Image neu erstellen. Eine Liste neuerer Images können Sie über die ListSupportedImages-API abrufen.
Weitere Informationen zu Batch-Konto: EolImage (Neuerstellen Ihres Pools mit einem neuen Image)
Erhöhen Sie die Anzahl von Computeressourcen, die Sie bereitstellen können, um 10 vCPUs.
Wenn Kontingentgrenzen überschritten werden, werden neue VM-Bereitstellungen so lange blockiert, bis das Kontingent erhöht wird. Um die Bereitstellung von mehr Ressourcen zu ermöglichen, sollten Sie Ihr Kontingent erhöhen.
Hinzufügen von Azure Monitor zu Ihrem für die Produktion bestimmten virtuellen Computer (VM)
Azure Monitor für VMs überwacht Ihre virtuellen Azure-Computer (VM) und VM-Skalierungsgruppen im großen Stil. Der Dienst analysiert die Leistung und Integrität Ihrer Windows- und Linux-VMs und überwacht deren Prozesse und Abhängigkeiten von anderen Ressourcen und externen Prozessen. Er beinhaltet Unterstützung für die Überwachung von Leistung und Anwendungsabhängigkeiten für virtuelle Computer, die lokal oder bei einem anderen Cloudanbieter gehostet werden.
Übermäßig hoher NTP-Clientdatenverkehr, der durch häufige DNS-Lookupvorgänge und NTP-Synchronisierungen für neue Server verursacht wird. Dies tritt für einige globale NTP-Server häufig auf.
Übermäßig hoher NTP-Clientdatenverkehr, der durch häufige DNS-Lookupvorgänge und NTP-Synchronisierungen für neue Server verursacht wird. Dies tritt für einige globale NTP-Server häufig auf. Häufige DNS-Lookupvorgänge und NTP-Synchronisierungen können als bösartiger Datenverkehr angesehen und durch den DDoS-Dienst in der Azure-Umgebung blockiert werden.
Ein Azure-Umgebungsupdate wurde eingeführt, das sich auf Ihre Check Point-Firewall auswirken kann.
Die Imageversion der installierten Check Point-Firewall wurde möglicherweise durch das neueste Azure-Umgebungsupdate beeinträchtigt. Unter bestimmten Umständen kann eine Kernel Panic ausgegeben werden, die zu einem Neustart mit zurückgesetzten Werkseinstellungen führt.
Weitere Informationen finden Sie unter Virtueller Computer: NvaCheckpointNicServicing (Ein Azure-Umgebungsupdate wurde eingeführt, das sich auf Ihre Check Point-Firewall auswirken kann).
Bei der iControl-REST-Schnittstelle liegt ein Sicherheitsrisiko im Zusammenhang mit nicht authentifizierten Remotebefehlsausführungen vor.
Ein Sicherheitsrisiko bei nicht authentifizierter Remote-Befehlsausführung ermöglicht es Angreifern mit Netzwerkzugriff auf die iControl REST-Schnittstelle zuzugreifen, um beliebige Systembefehle auszuführen. Sie können auch Dateien erstellen oder löschen und Dienste über die BIG-IP-Verwaltungsschnittstelle deaktivieren und sich eigene IP-Adressen zuweisen. Dieses Sicherheitsrisiko kann nur über die Steuerungsebene und nicht über die Datenebene ausgenutzt werden. Die Ausnutzung kann zu einer umfassenden Gefährdung des Systems führen. Das BIG-IP-System im Appliance-Modus ist ebenfalls anfällig.
Der beschleunigte Netzwerkbetrieb für virtuelle Netzwerkappliances ist aktiviert, aber möglicherweise nicht funktionsfähig.
Der gewünschte Zustand für den beschleunigten Netzwerkbetrieb ist für mindestens eine Schnittstelle Ihrer VM auf true festgelegt, aber tatsächlich ist der beschleunigte Netzwerkbetrieb nicht aktiviert.
Virtuelle Computer mit Citrix Application Delivery Controller (ADC) und aktiviertem beschleunigtem Netzwerkbetrieb werden während des Wartungsvorgangs möglicherweise getrennt.
Wir haben ermittelt, dass Sie ein virtuelles Netzwerkgerät (Network Virtual Appliance, NVA) namens Citrix Application Delivery Controller (ADC) ausführen und dass der beschleunigte Netzwerkbetrieb für das NVA aktiviert ist. Auf dem virtuellen Computer, auf dem dieses virtuelle Netzwerkgerät bereitgestellt wird, kann es während eines Plattformwartungsvorgangs zu Konnektivitätsproblemen kommen. Wir empfehlen, dem vom Anbieter bereitgestellten Artikel zu folgen.
Weitere Informationen finden Sie unter Virtueller Computer – GetCitrixVFRevokeError (Virtuelle Computer mit Citrix Application Delivery Controller (ADC) und aktiviertem beschleunigtem Netzwerkbetrieb werden während des Wartungsvorgangs möglicherweise getrennt).
Aktualisieren Ihres veralteten Azure Spring Cloud SDK auf die aktuelle Version
Wir haben API-Aufrufe von einem veralteten Azure Spring Cloud-SDK erkannt. Es wird empfohlen, ein Upgrade auf die neueste Version durchzuführen, um aktuelle Fixes, Leistungsverbesserungen und neue Funktionen zu erhalten.
Aktualisieren der Spring Cloud-API-Version
Wir haben API-Aufrufe von einer veralteten Azure Spring Cloud-API für Ressourcen unter diesem Abonnement identifiziert. Es wird empfohlen, zur neuesten Versionen der Spring Cloud-API zu wechseln. Sie müssen Ihren vorhandenen Code aktualisieren, um die neueste API-Version zu verwenden. Sie müssen außerdem das Azure SDK und die Azure CLI auf die neueste SDK-Version aktualisieren, um die neuesten Features und Leistungsverbesserungen sicherzustellen.
Container
Die API-Version, die Sie für Microsoft.App verwenden, ist veraltet. Verwenden Sie die aktuelle API-Version.
Die API-Version, die Sie für Microsoft.App verwenden, ist veraltet. Verwenden Sie die aktuelle API-Version.
Weitere Informationen finden Sie unter Microsoft App-Container-App – UseLatestApiVersion (Die API-Version, die Sie für Microsoft.App verwenden, ist veraltet, verwenden Sie die aktuelle API-Version).
Aktualisieren des Clusterdienstprinzipals
Der Dienstprinzipal dieses Clusters ist abgelaufen, und der Cluster ist erst wieder fehlerfrei, wenn der Dienstprinzipal aktualisiert wird.
Arbeitsbereich des Überwachungs-Add-Ons gelöscht
Der Arbeitsbereich des Überwachungs-Add-Ons wurde gelöscht. Beheben Sie Probleme, um das Überwachungs-Add-On einrichten zu können.
Veraltete Kubernetes-API in 1.16 gefunden
In 1.16 wurde eine veraltete Kubernetes-API gefunden. Vermeiden Sie die Verwendung einer veralteten API.
Aktivieren der Autoskalierung für Cluster
Für diesen Cluster wurde die Autoskalierung für AKS-Cluster nicht aktiviert, und er kann sich nicht an sich ändernde Lastbedingungen anpassen, sofern Sie keine anderen Möglichkeiten für die Autoskalierung Ihres Clusters haben.
Das Subnetz des AKS-Knotenpools ist voll.
Einige der Subnetze für die Knotenpools dieses Clusters sind voll und können keine weiteren Workerknoten mehr aufnehmen. Für die Verwendung des Azure CNI-Plug-Ins müssen während der Knotenbereitstellung IP-Adressen für jeden Knoten und alle Pods eines Knotens reserviert werden. Falls der IP-Adressraum im Subnetz nicht ausreicht, können keine Workerknoten bereitgestellt werden. Darüber hinaus kann der AKS-Cluster nicht aktualisiert werden, wenn das Knotensubnetz voll ist.
Abgelaufenes ETCD-Zertifikat
Abgelaufenes ETCD-Zertifikat. Aktualisieren Sie das Zertifikat.
Weitere Informationen finden Sie unter Kubernetes-Dienst – ExpiredETCDCertPre03012022 (Abgelaufenes ETCD-Zertifikat).
Deaktivieren des Add-Ons für Anwendungsrouting
Für diesen Cluster sind Pod-Sicherheitsrichtlinien aktiviert, die eingestellt und durch Azure Policy für AKS ersetzt werden.
Verwenden eines kurzlebigen Betriebssystemdatenträgers
Dieser Cluster verwendet keine kurzlebigen Betriebssystemdatenträger, die eine geringere Lese-/Schreiblatenz sowie schnellere Knotenskalierung und Clusterupgrades ermöglichen können.
Veraltete Betriebssystem-SKUs für Azure Linux (Mariner) gefunden
Es wurden veraltete Betriebssystem-SKUs für Azure Linux (Mariner) gefunden. Die SKU „CBL-Mariner“ wird nicht unterstützt. Die Mariner-SKU entspricht AzureLinux, allerdings wird empfohlen, für zukünftige Updates und zukünftigen Support zur SKU „AzureLinux“ zu wechseln, da AzureLinux die GA- (allgemein verfügbare) Version ist.
Weitere Informationen finden Sie unter Kubernetes-Dienst – ClustersWithDeprecatedMarirSKU (Veraltete Betriebssystem-SKUs für Azure Linux (Mariner) gefunden).
Tarife „Free“ und „Standard“ für die Verwaltung der AKS-Steuerungsebene
Für diesen Cluster ist die Standardebene, die standardmäßig das Feature „Uptime-SLA“ enthält, nicht aktiviert, und er ist auf ein SLO von 99,5 % beschränkt.
Weitere Informationen finden Sie unter Tarife „Free“ und „Standard“ für die AKS-Clusterverwaltung (Azure Kubernetes Service).
Veraltete Kubernetes-API in 1.22 gefunden
In 1.22 wurde eine veraltete Kubernetes-API gefunden. Vermeiden Sie die Verwendung veralteter APIs.
Datenbanken
Azure SQL-IaaS-Agent muss im Vollmodus installiert werden.
Der vollständige Modus installiert den SQL-IaaS-Agent auf der VM, um vollständige Funktionen bereitzustellen. Verwenden Sie diesen Modus zum Verwalten einer SQL Server-VM mit einer einzelnen Instanz. Mit der Verwendung des vollständigen Verwaltbarkeitsmodus sind keine Kosten verbunden. Es sind Systemadministratorberechtigungen erforderlich. Die Installation des bzw. das Upgrade auf den vollständigen Modus ist ein Onlinevorgang, für den kein Neustart erforderlich ist.
Weitere Informationen finden Sie unter Virtueller SQL-Computer: UpgradeToFullMode (SQL-IaaS-Agent muss im Vollmodus installiert werden.).
Installieren der SQL-Best-Practices-Bewertung auf Ihrem virtuellen SQL-Computer
Die SQL-Best-Practices-Bewertung bietet einen Mechanismus zum Auswerten der Konfiguration Ihres virtuellen Azure SQL-Computers hinsichtlich bewährter Methoden wie Indizes, veralteten Features, Verwendung von Ablaufverfolgungsflags, Statistiken usw. Die Bewertungsergebnisse werden mithilfe des Azure Monitoring-Agents (AMA) in Ihren Log Analytics-Arbeitsbereich hochgeladen.
Weitere Informationen finden Sie unter Virtueller SQL-Computer: SqlAssessmentAdvisorRec (Installieren der SQL-Best-Practices-Bewertung auf Ihrem virtuellen SQL-Computer).
Migrieren von Azure Cosmos DB-Anlagen zu Azure Blob Storage
Wir haben festgestellt, dass Ihre Azure Cosmos DB-Sammlung das Legacyfeature für Anlagen verwendet. Es wird empfohlen, Anlagen zu Azure Blob Storage zu migrieren, um die Resilienz und Skalierbarkeit Ihrer Blobdaten zu verbessern.
Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBAttachments (Migrieren von Azure Cosmos DB-Anlagen zu Azure Blob Storage).
Verbessern der Resilienz durch Migrieren Ihrer Azure Cosmos DB-Konten zur fortlaufenden Sicherung
Ihre Azure Cosmos DB-Konten sind mit regelmäßigen Sicherungen konfiguriert. Die fortlaufende Sicherung mit Zeitpunktwiederherstellung ist jetzt für diese Konten verfügbar. Mit fortlaufender Sicherung können Sie den Stand Ihrer Daten zu einem beliebigen Zeitpunkt innerhalb der letzten 30 Tage wiederherstellen. Die fortlaufende Sicherung kann auch kostengünstiger sein, da eine einzelne Kopie Ihrer Daten beibehalten wird.
Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBMigrateToContinuousBackup (Verbessern der Resilienz durch Migrieren Ihrer Azure Cosmos DB-Konten zur fortlaufenden Sicherung).
Aktivieren der Partitionszusammenführung zum Konfigurieren eines optimalen Datenbankpartitionslayouts
Ihr Konto verfügt über Sammlungen, die von der Aktivierung der Partitionszusammenführung profitieren können. Durch die Minimierung der Partitionsanzahl wird die Ratenbegrenzung reduziert, und Probleme mit der Speicherfragmentierung werden behoben. Container profitieren wahrscheinlich von einer Partitionszusammenführung, wenn die RU/s pro physischer Partition < 3000 RUs und der Speicher < 20 GB beträgt.
Weitere Informationen finden Sie unter Cosmos DB-Konto – CosmosDBPartitionMerge (Aktivieren der Partitionszusammenführung zum Konfigurieren eines optimalen Datenbankpartitionslayouts).
Ihre Instanz von Azure Database for MySQL – Flexibler Server ist aufgrund der Verwendung von schwachen, veralteten TLSv1- oder TLSv1.1-Protokollen gefährdet.
Zur Unterstützung moderner Sicherheitsstandards hat die MySQL Community-Edition die Unterstützung der Kommunikation über die TLS-Protokolle (Transport Layer Security) 1.0 und 1.1 eingestellt. Microsoft wird außerdem bald die Unterstützung von Verbindungen mit Azure Database for MySQL – Flexibler Server über TLSv1 und TLSv1.1 einstellen, um moderne Sicherheitsstandards zu erfüllen. Wir empfehlen Ihnen, ein Upgrade für Ihren Clienttreiber durchzuführen, um TLSv1.2 zu unterstützen.
Optimieren oder Partitionieren von Tabellen in Ihrer Datenbank, die einen großen Tabellenbereich aufweisen
Die maximal unterstützte Tabellenbereichsgröße in Azure Database for MySQL – Flexibler Server beträgt 4 TB. Für die effektive Verwaltung großer Tabellen empfiehlt es sich, die Tabelle zu optimieren oder Partitionierung zu implementieren. Dies trägt dazu bei, die Daten über mehrere Dateien zu verteilen und das Erreichen der festen Limite von 4 TB im Tabellenbereich zu verhindern.
Weitere Informationen finden Sie unter Azure Database for MySQL – Flexibler Server: MySqlFlexibleServerSingleTablespace4TBLimit2bf9 (Optimieren oder Partitionieren von Tabellen in Ihrer Datenbank, die einen großen Tabellenbereich aufweisen).
Aktivieren der automatischen Speichervergrößerung für MySQL Flexibler Server
Die automatische Speichervergrößerung verhindert, dass einem Server der Speicher ausgeht und er schreibgeschützt wird.
Weitere Informationen finden Sie unter Azure Database for MySQL – Flexibler Server: MySqlFlexibleServerStorageAutogrow43b64 (Aktivieren der automatischen Speichervergrößerung für den flexiblen MySQL-Server).
Anwenden der Löschsperre für Ressourcen
Sperren Sie Ihren MySQL – Flexibler Server, um ihn vor versehentlichen Löschungen und Änderungen durch Benutzer zu schützen.
Weitere Informationen finden Sie unter Azure Database for MySQL – Flexibler Server: MySqlFlexibleServerResourceLockbe19e (Anwenden der Löschsperre für Ressourcen).
Hinzufügen von Firewallregeln für MySQL Flexibler Server
Fügen Sie Firewallregeln zum Schutz Ihres Servers vor nicht autorisiertem Zugriff hinzu.
Weitere Informationen finden Sie unter Azure Database for MySQL – Flexibler Server: MySqlFlexibleServerNoFirewallRule6e523 (Hinzufügen von Firewallregeln für den flexiblen MySQL-Server).
Das Einfügen eines Caches in ein virtuelles Netzwerk bedeutet komplexe Anforderungen für Ihre Netzwerkkonfiguration. Dies ist eine häufige Quelle von Incidents, die sich auf Kundenanwendungen auswirken.
Das Einfügen eines Caches in ein virtuelles Netzwerk (VNet) geht mit komplexen Anforderungen an Ihre Netzwerkkonfiguration einher. Es ist schwierig, das Netzwerk korrekt zu konfigurieren und Auswirkungen auf die Cachefunktion zu vermeiden. Konfigurationsänderungen für andere Netzwerkressourcen können schnell dazu führen, dass der Cache nicht mehr funktioniert. Dies ist eine häufige Quelle von Vorfällen, die sich auf Kundenanwendungen auswirken.
Die Unterstützung für die TLS-Versionen 1.0 und 1.1 wird am 30. September 2024 eingestellt.
Die Unterstützung für TLS 1.0/1.1 wird am 30. September 2024 eingestellt. Konfigurieren Sie Ihren Cache für die ausschließliche Verwendung von TLS 1.2 und Ihre Anwendung für die Verwendung von TLS 1.2 oder höher. Weitere Informationen finden Sie unter Entfernen der Verwendung von TLS 1.0 und 1.1 mit Azure Cache for Redis.
Weitere Informationen finden Sie unter Redis Cache-Server – TLSVersion (Die Unterstützung für die TLS-Versionen 1.0 und 1.1 wird am 30. September 2024 eingestellt.).
Die TLS-Versionen 1.0 und 1.1 sind bekanntermaßen anfällig für Sicherheitsangriffe und weisen andere allgemeine Sicherheitslücken und Schwachstellen (CVE, Common Vulnerabilities and Exposures) auf.
Die TLS-Versionen 1.0 und 1.1 sind bekanntermaßen anfällig für Sicherheitsangriffe und weisen andere allgemeine Sicherheitslücken und Schwachstellen (CVE, Common Vulnerabilities and Exposures) auf. Es wird dringend empfohlen, Ihren Cache für die ausschließliche Verwendung von TLS 1.2 und Ihre Anwendung für die Verwendung von TLS 1.2 oder höher zu konfigurieren. Weitere Informationen finden Sie unter Entfernen der Verwendung von TLS 1.0 und 1.1 mit Azure Cache for Redis.
Erfahren Sie mehr über Redis Cache Server – TLSVersion (TLS-Versionen 1.0 und 1.1 sind bekanntermaßen anfällig für Sicherheitsangriffe und haben weitere Schwachstellen und Risiken).
Clouddienstcaches werden im August 2024 eingestellt. Migrieren Sie vor diesem Datum, um Probleme zu vermeiden.
Diese Instanz von Azure Cache for Redis ist von Cloud Services (klassisch) abhängig. Dieses Angebot wird im August 2024 eingestellt. Um auf eine Instanz ohne diese Abhängigkeit zu migrieren, folgen Sie den Anweisungen unter dem folgenden Link. Wenn Sie Ihren Cache auf Redis 6 upgraden müssen, beachten Sie, dass das Upgraden eines Caches, der von Clouddiensten abhängig ist, nicht unterstützt wird. Sie sollten Ihre Cache-Instanz vor dem Upgrade zur VM-Skalierungsgruppe migrieren. Weitere Informationen finden Sie unter dem folgenden Link: Hinweis: Wenn Sie ihre Migration weg von Cloud Services abgeschlossen haben, kann es bis zu 24 Stunden dauern, bis diese Empfehlung entfernt wird.
Erfahren Sie mehr über Redis Cache Server – MigrateFromCloudService (Clouddienstcaches werden im August 2024 eingestellt. Migrieren Sie vor diesem Datum, um Probleme vermeiden).
Redis-Persistenz ermöglicht es Ihnen, in einem Cache gespeicherte Daten dauerhaft zu speichern, sodass Sie Daten aus einem Ereignis erneut laden können, das Datenverluste verursacht hat.
Mithilfe der Redis-Persistenz können Sie die in Redis gespeicherten Daten dauerhaft speichern. Sie können auch Momentaufnahmen erstellen und die Daten sichern. Bei einem Hardwarefehler werden die persistenten Daten automatisch in Ihre Cache-Instanz geladen. Datenverlust ist möglich, wenn ein Fehler auftritt, bei dem Cacheknoten ausfallen.
Weitere Informationen finden Sie unter Redis Cache-Server – Persistence (Redis-Persistenz ermöglicht es Ihnen, in einem Cache gespeicherte Daten dauerhaft zu speichern, sodass Sie Daten aus einem Ereignis erneut laden können, das Datenverluste verursacht hat.).
Wenn Sie Persistenz mit aktiviertem vorläufigem Löschen verwenden, kann dies zu höheren Speicherkosten führen.
Prüfen Sie, ob für Ihr Speicherkonto vorläufiges Löschen aktiviert ist, bevor Sie die Datenpersistenzfunktion verwenden. Die Verwendung von Datenpersistenz mit vorläufigem Löschen verursacht sehr hohe Speicherkosten. Weitere Informationen finden Sie unter dem folgenden Link:
Weitere Informationen finden Sie unter Redis Cache-Server – PersistenceSoftEnable (Wenn Sie Persistenz mit aktiviertem vorläufigem Löschen verwenden, kann dies zu höheren Speicherkosten führen.).
Möglicherweise profitieren Sie von der Verwendung einer Cache-Instanz der Enterprise-Ebene.
Diese Instanz von Azure Cache for Redis verwendet ein oder mehrere erweiterte Funktionen aus der Liste – mehr als 6 Shards, Georeplikation, Zonenredundanz oder Persistenz. Erwägen Sie, zu einem Cache der Enterprise-Ebene zu wechseln, um Ihre Redis-Umgebung optimal zu nutzen. Caches der Enterprise-Ebene bieten höhere Verfügbarkeit, bessere Leistung und leistungsstärkere Features wie aktive Georeplikation.
Weitere Informationen finden Sie unter Redis Cache-Server – ConsiderUsingRedisEnterprise (Möglicherweise profitieren Sie von der Verwendung einer Cache-Instanz der Enterprise-Ebene.).
Integration
Verwenden der Azure AD-basierten Authentifizierung für eine differenziertere Steuerung und vereinfachte Verwaltung
Sie können die Azure AD-basierte Authentifizierung anstelle von Gatewaytoken verwenden, wodurch Sie Standardprozeduren zum Erstellen, Zuweisen und Verwalten von Berechtigungen sowie zum Steuern von Ablaufzeiten verwenden können. Darüber hinaus erhalten Sie eine differenzierte Steuerung über Gatewaybereitstellungen hinweg und können den Zugriff einfach widerrufen, wenn eine Sicherheitsverletzung auftritt.
Weitere Informationen finden Sie unter API Management – ShgwUseAdAuth (Verwenden der Azure AD-basierten Authentifizierung für eine differenziertere Steuerung und vereinfachte Verwaltung).
Die Richtlinie "JWT validieren" wird mit Sicherheitsschlüsseln verwendet, die eine unsichere Schlüsselgröße für die Validierung von Json-Web-Tokens (JWT) haben.
Die Richtlinie "JWT validieren" wird mit Sicherheitsschlüsseln verwendet, die eine unsichere Schlüsselgröße für die Validierung von Json-Web-Tokens (JWT) haben. Wir empfehlen die Verwendung längerer Schlüssel, um die Sicherheit für die JWT-basierte &-Autorisierung Authentifizierung zu verbessern.
Weitere Informationen finden Sie unter API Management – validate-jwt-with-insecure-key-size (Richtlinie „JWT validieren“ wird mit Sicherheitsschlüsseln mit unsicherer Schlüsselgröße für die Überprüfung von JSON Web Token (JWT) verwendet.).
Verwenden des selbstgehosteten Gateways v2
Wir haben mindestens eine Instanz Ihrer selbstgehosteten Gateways identifiziert, die eine veraltete Version des selbstgehosteten Gateways (v0.x und/oder v1.x) verwendet.
Weitere Informationen finden Sie unter API Management – shgw-legacy-image-usage (Verwenden des selbstgehosteten Gateways v2).
Verwenden der Konfigurations-API v2 für selbstgehostete Gateways
Wir haben mindestens eine Instanz Ihrer selbstgehosteten Gateways identifiziert, die eine veraltete Konfigurations-API v1 verwendet.
Weitere Informationen finden Sie unter API Management – shgw-config-api-v1-usage (Verwenden der Konfigurations-API v2 für selbstgehostete Gateways).
Lassen Sie die Ablaufverfolgung nur für Abonnements zu, die für Debugzwecke vorgesehen sind. Die Freigabe von Abonnementschlüsseln mit Ablaufverfolgung, die für nicht autorisierte Benutzer zulässig ist, kann zu Offenlegung vertraulicher Informationen führen, die in Ablaufverfolgungsprotokollen enthalten sind, wie Schlüssel, Zugriffstoken, Kennwörter, interne Hostnamen und IP-Adressen.
Vom Azure API Management-Dienst generierte Ablaufverfolgungen können vertrauliche Informationen enthalten, die für den*die Dienstbesitzer*in bestimmt sind und nicht für Clients verfügbar gemacht werden dürfen, die den Dienst verwenden. Die Verwendung von ablaufverfolgungsfähigen Abonnementschlüsseln in Produktions- oder automatisierten Szenarien führt zu einem Risiko der Offenlegung vertraulicher Informationen, wenn ein Client, der den Dienst aufruft, eine Ablaufverfolgung anfordert.
Es wurden Instanzen selbstgehosteter Gateways identifiziert, deren Gatewaytoken demnächst ablaufen.
Es wurde mindestens eine bereitgestellte Instanz selbstgehosteter Gateways identifiziert, deren Gatewaytoken in den nächsten sieben Tagen abläuft. Um sicherzustellen, dass eine Verbindung mit der Steuerungsebene hergestellt werden kann, generieren Sie ein neues Gatewaytoken und aktualisieren Ihre bereitgestellten selbstgehosteten Gateways (wirkt sich nicht auf den Datenverkehr auf Datenebene aus).
Weitere Informationen finden Sie unter API Management – ShgwGatewayTokenNearExpiry (Es wurden Instanzen selbstgehosteter Gateways erkannt, deren Gatewaytoken demnächst ablaufen).
Internet der Dinge
IoT Hub-Fallbackroute deaktiviert
Wir haben festgestellt, dass die Fallbackroute Ihres IoT Hub deaktiviert wurde. Wenn die Fallbackroute deaktiviert ist, werden Nachrichten nicht mehr an den Standardendpunkt weitergeleitet. Wenn Sie Telemetriedaten nicht mehr nachgeschaltet erfassen können, sollten Sie erwägen, die Fallbackroute erneut zu aktivieren.
Weitere Informationen finden Sie unter IoT-Hub – IoTHubFallbackDisabledAdvisor (IoT Hub-Fallbackroute deaktiviert).
Verwaltung und Governance
Upgrade auf „VMs starten/beenden v2“
Die neue Version von „VMs starten/beenden v2 (Vorschau)“ ist eine dezentralisierte kostengünstige Automatisierungsoption für Kunden, die Ihre VM-Kosten optimieren möchten. Sie bietet die gleiche Funktionalität wie die mit Azure Automation verfügbare ursprüngliche Version, ist aber darauf ausgelegt, neuere Technologie in Azure zu nutzen.
Weitere Informationen zu Automation-Konto: SSV1_Upgrade (Upgrade auf „VMs starten/beenden v2“)
Reparieren Ihrer Protokollwarnungsregel
Wir haben festgestellt, dass eine oder mehrere Ihrer Warnungsregeln ungültige Abfragen in ihrem Bedingungsabschnitt enthalten. Protokollwarnungsregeln werden in Azure Monitor erstellt und verwendet, um in regelmäßigen Abständen Analytics-Abfragen durchzuführen. Anhand der Ergebnisse der Abfrage wird ermittelt, ob eine Warnung ausgelöst werden muss. Es kann vorkommen, dass Analytics-Abfragen aufgrund von Änderungen an referenzierten Ressourcen, Tabellen oder Befehlen im Laufe der Zeit ungültig werden. Wir empfehlen Ihnen, die Abfrage in der Warnungsregel zu korrigieren, um ihre automatische Deaktivierung zu verhindern und die Überwachungsabdeckung für Ihre Ressourcen in Azure sicherzustellen.
Protokollwarnungsregel wurde deaktiviert
Die Warnungsregel wurde durch Azure Monitor deaktiviert, da sie Dienstprobleme verursacht hat. Wenden Sie sich an den Support, um die Warnungsregel zu aktivieren.
Aktualisieren der Azure Managed Grafana SDK-Version
Wir haben festgestellt, dass eine ältere SDK-Version verwendet wurde, um Ihren Grafana-Arbeitsbereich zu verwalten oder darauf zuzugreifen. Um Zugriff auf alle neuesten Funktionalitäten zu erhalten, empfehlen wir, zur aktuellen SDK-Version zu wechseln.
Weitere Informationen finden Sie unter Grafana-Dashboard – UpdateAzureManagedGrafanaSDK (Aktualisieren der Azure Managed Grafana SDK-Version).
Wechseln zu Azure Monitor-basierten Warnungen für die Sicherung
Wechseln Sie zu Azure Monitor-basierten Warnungen für Backup, um verschiedene Vorteile zu nutzen, z. B. standardisierte, von Azure angebotene Erfahrungen bei der Warnungsverwaltung im großen Stil, die Möglichkeit, Warnungen an verschiedene Benachrichtigungskanäle Ihrer Wahl weiterzuleiten, und größere Flexibilität bei der Konfiguration von Warnungen.
Weitere Informationen finden Sie unter Recovery Services-Tresor – SwitchToAzureMonitorAlerts (Wechseln zu Azure Monitor-basierten Warnungen für die Sicherung).
Netzwerk
Beheben eines Problems bei der Zertifikataktualisierung für Ihre Application Gateway-Instanz
Wir haben festgestellt, dass mindestens eine Ihrer Application Gateway-Instanzen nicht in der Lage ist, die aktuelle Version des Zertifikats in Ihrer Key Vault-Instanz abzurufen. Wenn eine bestimmte Version des Zertifikats verwendet werden soll, ignorieren Sie diese Meldung.
Weitere Informationen finden Sie unter Anwendungsgateway: AppGwAdvisorRecommendationForCertificateUpdateErrors (Beheben eines Problems bei der Zertifikataktualisierung für Ihre Application Gateway-Instanz).
Beheben eines Azure Key Vault-Problems für Ihre Application Gateway-Instanz
Wir haben festgestellt, dass mindestens eine Ihrer Application Gateway-Instanzen aufgrund einer falsch konfigurierten Key Vault-Instanz kein Zertifikat erhalten kann. Sie müssen diese Konfiguration sofort korrigieren, um Betriebsprobleme mit Ihrem Gateway zu vermeiden.
Application Gateway verfügt nicht über genügend Kapazität zum Aufskalieren
Wir haben festgestellt, dass Ihr Application Gateway-Subnetz nicht über genügend Kapazität verfügt, um eine horizontale Skalierung bei hohem Datenverkehrsaufkommen zu ermöglichen, was zu Downtime führen kann.
Weitere Informationen finden Sie unter Anwendungsgateway – AppgwRestrictedSubnetSpace (Application Gateway verfügt nicht über genügend Kapazität zum Aufskalieren).
Aktivieren von Traffic Analytics zum Anzeigen von Erkenntnissen zu Datenverkehrsmustern für Azure-Ressourcen
Traffic Analytics ist eine cloudbasierte Lösung, die Einblick in Benutzer- und Anwendungsaktivitäten in Azure bietet. Traffic Analytics analysiert Flussprotokolle von Network Watcher für Netzwerksicherheitsgruppen (NSGs), um Einblicke in den Datenfluss zu ermöglichen. Mit Datenverkehrsanalyse können Sie „Top Talkers“ für Azure- und Nicht-Azure-Bereitstellungen anzeigen, geöffnete Ports, Protokolle und bösartige Datenflüsse in Ihrer Umgebung untersuchen und Ihre Netzwerkbereitstellung in Bezug auf die Leistung optimieren. Sie können Datenflussprotokolle mit Verarbeitungsintervallen von 10 und 60 Minuten verarbeiten, um schnellere Analysen für Ihren Datenverkehr zu erhalten.
Einrichten von Stagingumgebungen in Azure App Service
Stellen Sie sicher, dass alle Instanzen des Slots vor dem Austausch hochgefahren werden und Downtime verhindert wird. Stellen Sie zuerst eine App auf einem Slot bereit, und wechseln Sie es dann in die Produktion. Die Datenverkehrsumleitung ist nahtlos. Aufgrund von Swap-Vorgängen werden keine Anforderungen verworfen.
Erzwingen von „Tag für Ressourcen hinzufügen oder ersetzen“ mithilfe von Azure Policy
Azure Policy ist ein Dienst in Azure, mit dem Sie Richtlinien erstellen, zuweisen und verwalten können, die verschiedene Regeln und Effekte für Ihre Ressourcen durchsetzen. Setzen Sie eine Richtlinie durch, die das angegebene Tag und den zugehörigen Wert hinzufügt oder ersetzt, wenn eine Ressource erstellt oder aktualisiert wird. Vorhandene Ressourcen können korrigiert werden, indem eine Wartungsaufgabe ausgelöst wird, wodurch keine Tags für Ressourcengruppen geändert werden.
Erzwingen von „Zulässige Standorte“ mit Azure Policy
Azure Policy ist ein Dienst in Azure, mit dem Sie Richtlinien erstellen, zuweisen und verwalten können, die verschiedene Regeln und Effekte für Ihre Ressourcen durchsetzen. Setzen Sie eine Richtlinie durch, mit der Sie die Speicherorte einschränken können, die Ihre Organisation beim Bereitstellen von Ressourcen angeben kann. Verwenden Sie die Richtlinie zur Erzwingung Ihrer Geokonformitätsanforderungen.
Erzwingen von „VMs überwachen, die keine verwalteten Datenträger verwenden“ mittels Azure Policy
Azure Policy ist ein Dienst in Azure, mit dem Sie Richtlinien erstellen, zuweisen und verwalten können, die verschiedene Regeln und Effekte für Ihre Ressourcen durchsetzen. Erzwingen Sie eine Richtlinie, die VMs überwacht, die keine verwalteten Datenträger verwenden.
Weitere Informationen finden Sie unter Abonnement – AuditForManagedDisksPolicy (Erzwingen von „VMs überwachen, die keine verwalteten Datenträger verwenden“ mittels Azure Policy).
Erzwingen von „Zulässige SKUs für virtuelle Computer“ mithilfe von Azure Policy
Azure Policy ist ein Dienst in Azure, mit dem Sie Richtlinien erstellen, zuweisen und verwalten können, die verschiedene Regeln und Effekte für Ihre Ressourcen durchsetzen. Setzen Sie eine Richtlinie durch, mit der Sie einen Satz von SKUs für virtuelle Computer angeben können, die Ihre Organisation bereitstellen kann.
Erzwingen von „Tag von der Ressourcengruppe erben“ mithilfe von Azure Policy
Azure Policy ist ein Dienst in Azure, mit dem Sie Richtlinien erstellen, zuweisen und verwalten können, die verschiedene Regeln und Effekte für Ihre Ressourcen durchsetzen. Setzen Sie eine Richtlinie durch, die zum Hinzufügen oder Ersetzen des angegebenen Tags aus der übergeordneten Ressourcengruppe und des zugehörigen Werts dient, wenn eine Ressource erstellt oder aktualisiert wird. Bereits vorhandene Ressourcen können durch Auslösen eines Wartungstasks gewartet werden.
Nutzen von Azure Lighthouse zum einfachen und sicheren Verwalten von Kundenabonnements im großen Stil
Durch die Nutzung von Azure Lighthouse wird die Sicherheit erhöht, und unnötige Zugriffsmöglichkeiten auf Ihre Kundenmandanten werden reduziert, indem präzisere Berechtigungen für Ihre Benutzer gewährt werden. Darüber hinaus wird auch eine bessere Skalierbarkeit ermöglicht, da Ihre Benutzer mit nur einer Anmeldung bei Ihrem Mandanten mehrere Kundenabonnements verwenden können.
Ein Abonnement mit mehr als 10 VNets muss mithilfe von AVNM verwaltet werden.
Ein Abonnement mit mehr als 10 VNets muss mithilfe von AVNM verwaltet werden. Azure Virtual Network Manager ist ein Verwaltungsdienst, mit dem Sie virtuelle Netzwerke global und abonnementübergreifend gruppieren, konfigurieren, bereitstellen und verwalten können.
Weitere Informationen finden Sie unter Abonnement – ManageVNetsUsingAVNM (Ein Abonnement mit mehr als 10 VNets muss mithilfe von AVNM verwaltet werden.).
Ein VNet mit mehr als 5 Peerings muss mithilfe der AVNM-Konnektivitätskonfiguration verwaltet werden
Ein VNet mit mehr als 5 Peerings muss mithilfe der AVNM-Konnektivitätskonfiguration verwaltet werden. Azure Virtual Network Manager ist ein Verwaltungsdienst, mit dem Sie virtuelle Netzwerke global und abonnementübergreifend gruppieren, konfigurieren, bereitstellen und verwalten können.
Weitere Informationen finden Sie unter Virtuelles Netzwerk – ManagePeeringsUsingAVNM (Ein VNet mit mehr als 5 Peerings muss mithilfe der AVNM-Konnektivitätskonfiguration verwaltet werden).
Upgrade der NSG-Datenflussprotokolle auf VNet-Datenflussprotokolle
Mit dem Flussprotokoll für virtuelle Netzwerke können Sie den IP-Verkehr in einem virtuellen Netzwerk aufzeichnen. Dies bietet mehrere Vorteile gegenüber dem Datenflussprotokoll der Netzwerksicherheitsgruppe, wie z. B. vereinfachte Aktivierung, verbesserte Abdeckung, Genauigkeit, Leistung und Einblick in die Regeln des Virtual Network Manager und des Verschlüsselungsstatus.
Weitere Informationen finden Sie unter Ressource – UpgradeNSGToVnetFlowLog (Aktualisieren von NSG-Datenflussprotokollen auf VNet-Datenflussprotokolle).
Migrieren von Azure Front Door (klassisch) zur Dienstebene Standard/Premium
Am 31. März 2027 wird Azure Front Door (klassisch) für die öffentliche Cloud eingestellt und Sie müssen bis zu diesem Datum zu Front Door Standard oder Premium migrieren.
Ab dem 1. April 2025 können Sie keine neuen Front Door-Ressourcen mehr über das Azure-Portal, Terraform oder beliebige Befehlszeilentools erstellen. Sie können jedoch weiterhin Änderungen an vorhandenen Ressourcen vornehmen, bis Front Door (klassisch) vollständig eingestellt ist.
Azure Front Door Standard und Premium kombinieren die Funktionen der statischen und dynamischen Inhaltsbereitstellung mit schlüsselfertiger Sicherheit, verbesserten DevOps-Erfahrungen, vereinfachten Preisen und besseren Azure-Integrationen.
Weitere Informationen zu Azure Front Door (klassisch) werden am 31. März 2027 eingestellt.
Migrieren von Azure CDN Standard von Microsoft (klassisch) zur Dienstebene „Standard“ oder „Premium“ von Azure Front Door
Azure CDN Standard von Microsoft (klassisch) wird am 30. September 2027 eingestellt. Es wird empfohlen, das Zero-Downtime-Migrationstool für die Migration zu den Azure Front Door-SKUs Standard und Premium zu verwenden, die dieselben Features wie Azure CDN Standard von Microsoft (klassisch) sowie neue Features und Sicherheitsverbesserungen enthalten.
Weitere Informationen finden Sie unter Migrieren von Azure CDN von Microsoft (klassisch) zur Dienstebene „Standard“/„Premium“.
SAP für Azure
Sicherstellen, dass der Typ für HANA DB-VMs das HANA-Szenario in Ihrer SAP-Workload unterstützt
Für das spezifische HANA-Szenario muss der richtige VM-Typ ausgewählt werden. Die HANA-Szenarien können OLAP, OLTP, OLAP: Scaleup und OLTP: Scaleup sein. Informationen zum korrekten VM-Typ für Ihre SAP-Workload finden Sie im SAP-Hinweis 1928533. Der richtige VM-Typ trägt zur Verbesserung der Leistung und Unterstützung für Ihre SAP-Systeme bei.
Weitere Informationen finden Sie unter Datenbankinstanz – HanaDBSupport (Sicherstellen, dass der Typ für HANA DB-VMs das HANA-Szenario in Ihrer SAP-Workload unterstützt).
Sicherstellen, dass das Betriebssystem auf der App-VM in Kombination mit dem Datenbanktyp in Ihrer SAP-Workload unterstützt wird
Das Betriebssystem auf den virtuellen Computern in Ihrer SAP-Workload muss für den ausgewählten Datenbanktyp unterstützt werden. Im SAP-Hinweis 1928533 finden Sie Informationen zu den richtigen Kombinationen aus Betriebssystem und Datenbank für ASCS-, Datenbank- und Anwendungs-VMs, um eine bessere Leistung und Unterstützung für Ihre SAP-Systeme zu gewährleisten.
Weitere Informationen finden Sie unter App-Serverinstanz – AppOSDBSupport (Sicherstellen, dass das Betriebssystem auf der App-VM in Kombination mit dem Datenbanktyp in Ihrer SAP-Workload unterstützt wird).
Festlegen des Parameters „net.ipv4.tcp_keepalive_time“ auf „300“ im Betriebssystem der Anwendungs-VM in SAP-Workloads
Um nach einem ASCS-Failover eine schnellere erneute Verbindungsherstellung zu ermöglichen, bearbeiten Sie die Datei /etc/sysctl.conf im Betriebssystem der Anwendungs-VM, und fügen Sie net.ipv4.tcp_keepalive_time = 300 hinzu. Diese Einstellung wird für alle Betriebssysteme auf Anwendungs-VMs in SAP-Workloads empfohlen.
Weitere Informationen finden Sie unter App-Serverinstanz – AppIPV4TCPKeepAlive (Festlegen des Parameters „net.ipv4.tcp_keepalive_time“ auf „300“ im Betriebssystem der Anwendungs-VM in SAP-Workloads).
Sicherstellen, dass das Betriebssystem des virtuellen Datenbankcomputers (virtual machine, VM) für den Datenbanktyp in Ihrer SAP-Workload unterstützt wird
Das Betriebssystem auf den virtuellen Computern in Ihrer SAP-Workload muss für den ausgewählten Datenbanktyp unterstützt werden. Im SAP-Hinweis 1928533 finden Sie Informationen zu den richtigen Kombinationen aus Betriebssystem und Datenbank für ASCS-, Datenbank- und Anwendungs-VMs, um eine bessere Leistung und Unterstützung für Ihre SAP-Systeme zu gewährleisten.
Weitere Informationen finden Sie unter Datenbankinstanz – DBOSDBSupport (Sicherstellen, dass das Betriebssystem des virtuellen Datenbankcomputers für den Datenbanktyp in Ihrer SAP-Workload unterstützt wird).
Festlegen des Parameters „net.ipv4.tcp_retries2“ auf „15“ im Betriebssystem des virtuellen Anwendungscomputers in SAP-Workloads
Um nach einem ASCS-Failover eine schnellere erneute Verbindungsherstellung zu ermöglichen, bearbeiten Sie die Datei /etc/sysctl.conf im Betriebssystem der Anwendungs-VM, und fügen Sie net.ipv4.tcp_retries2 = 15 hinzu. Dies wird für alle Betriebssysteme auf Anwendungs-VMs in SAP-Workloads empfohlen.
Weitere Informationen finden Sie unter App-Serverinstanz – AppIpv4Retries2 (Festlegen des Parameters „net.ipv4.tcp_retries2“ auf „15“ im Betriebssystem der Anwendungs-VM in SAP-Workloads).
Festlegen des Parameters „net.ipv4.tcp_keepalive_probes“ auf „9“ im Betriebssystem des virtuellen Anwendungscomputers in SAP-Workloads
Um nach einem ASCS-Failover eine schnellere erneute Verbindungsherstellung zu ermöglichen, bearbeiten Sie die Datei /etc/sysctl.conf im Betriebssystem der Anwendungs-VM, und fügen Sie net.ipv4.tcp_keepalive_probes = 9 hinzu. Diese Einstellung wird für alle Betriebssysteme auf Anwendungs-VMs in SAP-Workloads empfohlen.
Weitere Informationen finden Sie unter App-Serverinstanz – AppIPV4Probes (Festlegen des Parameters „net.ipv4.tcp_keepalive_probes“ auf „9“ im Betriebssystem der Anwendungs-VM in SAP-Workloads).
Festlegen des Parameters „net.ipv4.tcp_tw_recycle“ auf „0“ im Betriebssystem des virtuellen Anwendungscomputers in SAP-Workloads
Um nach einem ASCS-Failover eine schnellere erneute Verbindungsherstellung zu ermöglichen, bearbeiten Sie die Datei /etc/sysctl.conf im Betriebssystem der Anwendungs-VM, und fügen Sie net.ipv4.tcp_tw_recycle = 0 hinzu. Diese Einstellung wird für alle Betriebssysteme auf Anwendungs-VMs in SAP-Workloads empfohlen.
Weitere Informationen finden Sie unter App-Serverinstanz – AppIpv4Recycle (Festlegen des Parameters „net.ipv4.tcp_tw_recycle“ auf „0“ im Betriebssystem der Anwendungs-VM in SAP-Workloads).
Sicherstellen, dass das Betriebssystem auf der ASCS-VM in Kombination mit dem Datenbanktyp in Ihrer SAP-Workload unterstützt wird
Das Betriebssystem auf den virtuellen Computern in Ihrer SAP-Workload muss für den ausgewählten Datenbanktyp unterstützt werden. Informationen zu den korrekten Kombinationen von Betriebssystem und Datenbank für die ASCS-, Datenbank- und Anwendungs-VMs finden Sie im SAP-Hinweis 1928533. Die richtigen Kombinationen von Betriebssystem und Datenbank tragen zur Verbesserung der Leistung und Unterstützung für Ihre SAP-Systeme bei.
Weitere Informationen finden Sie unter Zentrale Serverinstanz – ASCSOSDBSupport (Sicherstellen, dass das Betriebssystem auf der ASCS-VM in Kombination mit dem Datenbanktyp in Ihrer SAP-Workload unterstützt wird).
Azure Center for SAP-Empfehlung: Alle VMs im SAP-System müssen für SAP zertifiziert sein.
Azure Center for SAP solutions-Empfehlung: Alle VMs im SAP-System müssen für SAP zertifiziert sein.
Weitere Informationen finden Sie unter App-Serverinstanz – VM_0001 (Azure Center for SAP-Empfehlung: Alle VMs im SAP-System müssen für SAP zertifiziert sein.).
Festlegen des Parameters „net.ipv4.tcp_retries1“ auf „3“ im Betriebssystem des virtuellen Anwendungscomputers in SAP-Workloads
Um nach einem ASCS-Failover eine schnellere erneute Verbindungsherstellung zu ermöglichen, bearbeiten Sie die Datei /etc/sysctl.conf im Betriebssystem der Anwendungs-VM, und fügen Sie net.ipv4.tcp_retries1 = 3 hinzu. Diese Einstellung wird für alle Betriebssysteme auf Anwendungs-VMs in SAP-Workloads empfohlen.
Weitere Informationen finden Sie unter App-Serverinstanz – AppIpv4Retries1 (Festlegen des Parameters „net.ipv4.tcp_retries1“ auf „3“ im Betriebssystem der Anwendungs-VM in SAP-Workloads).
Festlegen des Parameters „net.ipv4.tcp_tw_reuse“ auf „0“ im Betriebssystem des virtuellen Anwendungscomputers in SAP-Workloads
Um nach einem ASCS-Failover eine schnellere erneute Verbindungsherstellung zu ermöglichen, bearbeiten Sie die Datei /etc/sysctl.conf im Betriebssystem der Anwendungs-VM, und fügen Sie net.ipv4.tcp_tw_reuse = 0 hinzu. Diese Einstellung wird für alle Betriebssysteme auf Anwendungs-VMs in SAP-Workloads empfohlen.
Weitere Informationen finden Sie unter App-Serverinstanz – AppIpv4TcpReuse (Festlegen des Parameters „net.ipv4.tcp_tw_reuse“ auf „0“ im Betriebssystem der Anwendungs-VM in SAP-Workloads).
Festlegen des Parameters „net.ipv4.tcp_keepalive_intvl“ auf „75“ im Betriebssystem des virtuellen Anwendungscomputers in SAP-Workloads
Um nach einem ASCS-Failover eine schnellere erneute Verbindungsherstellung zu ermöglichen, bearbeiten Sie die Datei /etc/sysctl.conf im Betriebssystem der Anwendungs-VM, und fügen Sie net.ipv4.tcp_keepalive_intvl = 75 hinzu. Diese Einstellung wird für alle Betriebssysteme auf Anwendungs-VMs in SAP-Workloads empfohlen.
Weitere Informationen finden Sie unter App-Serverinstanz – AppIPV4intvl (Festlegen des Parameters „net.ipv4.tcp_keepalive_intvl“ auf „75“ im Betriebssystem der Anwendungs-VM in SAP-Workloads).
Stellen Sie sicher, dass beschleunigter Netzwerkbetrieb auf allen NICs aktiviert ist, um die Leistung von SAP-Workloads zu verbessern.
Die Netzwerklatenz zwischen App-VMs und DB-VMs für SAP-Workloads muss bei 0,7 ms oder tiefer liegen. Wenn der beschleunigte Netzwerkbetrieb nicht aktiviert ist, kann die Netzwerklatenz über den Schwellenwert von 0,7 ms hinaus erhöht werden.
Weitere Informationen finden Sie unter Datenbankinstanz – NIC_0001_DB (Stellen Sie sicher, dass beschleunigter Netzwerkbetrieb auf allen NICs aktiviert ist, um die Leistung von SAP-Workloads zu verbessern.).
Stellen Sie sicher, dass beschleunigter Netzwerkbetrieb auf allen NICs aktiviert ist, um die Leistung von SAP-Workloads zu verbessern.
Die Netzwerklatenz zwischen App-VMs und DB-VMs für SAP-Workloads muss bei 0,7 ms oder tiefer liegen. Wenn der beschleunigte Netzwerkbetrieb nicht aktiviert ist, kann die Netzwerklatenz über den Schwellenwert von 0,7 ms hinaus erhöht werden.
Weitere Informationen finden Sie unter App-Serverinstanz – NIC_0001 (Stellen Sie sicher, dass beschleunigter Netzwerkbetrieb auf allen NICs aktiviert ist, um die Leistung von SAP-Workloads zu verbessern.).
Azure Center für SAP-Empfehlung: Sicherstellen, dass beschleunigte Netzwerke auf allen Schnittstellen aktiviert sind
Azure Center für SAP-Lösungsempfehlung: Sicherstellen, dass beschleunigte Netzwerke auf allen Schnittstellen aktiviert sind
Erfahren Sie mehr über Datenbankinstanz – NIC_0001_DB (Azure Center für SAP-Empfehlung: Sicherstellen, dass der beschleunigte Netzwerkbetrieb in allen Schnittstellen aktiviert ist).
Azure Center für SAP-Empfehlung: Sicherstellen, dass beschleunigte Netzwerke auf allen Schnittstellen aktiviert sind
Azure Center für SAP-Lösungsempfehlung: Sicherstellen, dass beschleunigte Netzwerke auf allen Schnittstellen aktiviert sind
Erfahren Sie mehr über App-Server-Instanz – NIC_0001 (Azure Center für SAP-Empfehlung: Sicherstellen, dass der beschleunigte Netzwerkbetrieb in allen Schnittstellen aktiviert ist).
Azure Center für SAP-Empfehlung: Sicherstellen, dass beschleunigte Netzwerke auf allen Schnittstellen aktiviert sind
Azure Center für SAP-Lösungsempfehlung: Sicherstellen, dass beschleunigte Netzwerke auf allen Schnittstellen aktiviert sind
Erfahren Sie mehr über Central-Server-Instanz – NIC_0001_ASCS (Azure Center für SAP-Empfehlung: Sicherstellen, dass der beschleunigte Netzwerkbetrieb in allen Schnittstellen aktiviert ist).
Azure Center for SAP-Empfehlung: Alle VMs im SAP-System müssen für SAP zertifiziert sein.
Azure Center for SAP solutions-Empfehlung: Alle VMs im SAP-System müssen für SAP zertifiziert sein.
Weitere Informationen finden Sie unter Zentrale Serverinstanz – VM_0001_ASCS (Azure Center for SAP-Empfehlung: Alle VMs im SAP-System müssen für SAP zertifiziert sein.).
Azure Center for SAP-Empfehlung: Alle VMs im SAP-System müssen für SAP zertifiziert sein.
Azure Center for SAP solutions-Empfehlung: Alle VMs im SAP-System müssen für SAP zertifiziert sein.
Weitere Informationen finden Sie unter Datenbankinstanz – VM_0001_DB (Azure Center for SAP-Empfehlung: Alle VMs im SAP-System müssen für SAP zertifiziert sein.).
Deaktivieren von fstrim im Betriebssystem SUSE Linux Enterprise Server (SLES), um eine Beschädigung von XFS-Metadaten in SAP-Workloads zu vermeiden
fstrim überprüft das Dateisystem und sendet UNMAP-Befehle für jeden gefundenen nicht verwendeten Block. Dies ist bei einem System mit schlanker Speicherzuweisung hilfreich, wenn das System überdimensioniert ist. Die Ausführung von SAP HANA in einem überdimensionierten Speicherarray wird nicht empfohlen. Die Aktivierung von fstrim kann zu einer Beschädigung von XFS-Metadaten führen, siehe SAP-Hinweis 2205917.
Weitere Informationen finden Sie unter App-Serverinstanz – GetFsTrimForApp (Deaktivieren von fstrim im Betriebssystem SUSE Linux Enterprise Server (SLES), um eine Beschädigung von XFS-Metadaten in SAP-Workloads zu vermeiden).
Deaktivieren von fstrim im Betriebssystem SUSE Linux Enterprise Server (SLES), um eine Beschädigung von XFS-Metadaten in SAP-Workloads zu vermeiden
fstrim überprüft das Dateisystem und sendet UNMAP-Befehle für jeden gefundenen nicht verwendeten Block. Dies ist bei einem System mit schlanker Speicherzuweisung hilfreich, wenn das System überdimensioniert ist. Die Ausführung von SAP HANA in einem überdimensionierten Speicherarray wird nicht empfohlen. Die Aktivierung von fstrim kann zu einer Beschädigung von XFS-Metadaten führen, siehe SAP-Hinweis 2205917.
Weitere Informationen finden Sie unter Zentrale Serverinstanz – GetFsTrimForAscs (Deaktivieren von fstrim im Betriebssystem SUSE Linux Enterprise Server (SLES), um eine Beschädigung von XFS-Metadaten in SAP-Workloads zu vermeiden).
Deaktivieren von fstrim im Betriebssystem SUSE Linux Enterprise Server (SLES), um eine Beschädigung von XFS-Metadaten in SAP-Workloads zu vermeiden
fstrim überprüft das Dateisystem und sendet UNMAP-Befehle für jeden gefundenen nicht verwendeten Block. Dies ist bei einem System mit schlanker Speicherzuweisung hilfreich, wenn das System überdimensioniert ist. Die Ausführung von SAP HANA in einem überdimensionierten Speicherarray wird nicht empfohlen. Die Aktivierung von fstrim kann zu einer Beschädigung von XFS-Metadaten führen, siehe SAP-Hinweis 2205917.
Weitere Informationen finden Sie unter Datenbankinstanz – GetFsTrimForDb (Deaktivieren von fstrim im Betriebssystem SUSE Linux Enterprise Server (SLES), um eine Beschädigung von XFS-Metadaten in SAP-Workloads zu vermeiden).
Stellen Sie für eine bessere Leistung und Unterstützung sicher, dass der HANA-Datendateisystemtyp für HANA DB unterstützt wird
Für verschiedene Volumes von SAP HANA, bei denen asynchrone E/A verwendet wird, unterstützt SAP nur Dateisysteme, die im Rahmen einer SAP-HANA-Appliance-Zertifizierung validiert wurden. Die Verwendung eines nicht unterstützten Dateisystems kann zu verschiedenen Betriebsproblemen führen, beispielsweise zu nicht reagierenden Wiederherstellungen und Abstürzen des Indexservers. Siehe SAP-Hinweis 2972496.
Weitere Informationen finden Sie unter Datenbankinstanz – HanaDataFileSystemSupported (Stellen Sie für eine bessere Leistung und Unterstützung sicher, dass der HANA-Datendateisystemtyp für HANA DB unterstützt wird.).
Stellen Sie für eine bessere Leistung und Unterstützung sicher, dass der freigegebene HANA-Dateisystemtyp für HANA DB unterstützt wird
Für verschiedene Volumes von SAP HANA, bei denen asynchrone E/A verwendet wird, unterstützt SAP nur Dateisysteme, die im Rahmen einer SAP-HANA-Appliance-Zertifizierung validiert wurden. Die Verwendung eines nicht unterstützten Dateisystems kann zu verschiedenen Betriebsproblemen führen, beispielsweise zu nicht reagierenden Wiederherstellungen und Abstürzen des Indexservers. Siehe SAP-Hinweis 2972496.
Weitere Informationen finden Sie unter Datenbankinstanz – HanaSharedFileSystem (Stellen Sie für eine bessere Leistung und Unterstützung sicher, dass der freigegebene HANA-Dateisystemtyp für HANA DB unterstützt wird.).
Stellen Sie für eine bessere Leistung und Unterstützung sicher, dass der HANA-Protokolldateisystemtyp für HANA DB unterstützt wird
Für verschiedene Volumes von SAP HANA, bei denen asynchrone E/A verwendet wird, unterstützt SAP nur Dateisysteme, die im Rahmen einer SAP-HANA-Appliance-Zertifizierung validiert wurden. Die Verwendung eines nicht unterstützten Dateisystems kann zu verschiedenen Betriebsproblemen führen, beispielsweise zu nicht reagierenden Wiederherstellungen und Abstürzen des Indexservers. Siehe SAP-Hinweis 2972496.
Weitere Informationen finden Sie unter Datenbankinstanz – HanaLogFileSystemSupported (Stellen Sie für eine bessere Leistung und Unterstützung sicher, dass der HANA-Protokolldateisystemtyp für HANA DB unterstützt wird.).
Azure Center für SAP-Empfehlung: Stellen Sie sicher, dass alle NICs für ein System an dasselbe VNet angefügt sind.
Azure Center for SAP-Empfehlung: Alle NICs für ein System müssen an dasselbe VNet angefügt sein.
Erfahren Sie mehr über App-Server-Instanz – AllVmsHaveSameVnetApp (Azure Center für SAP-Empfehlung: Sicherstellen, dass alle NICs für ein System an dasselbe VNet angefügt sind).
Azure Center for SAP-Empfehlung: Der Auslagerungsbereich für HANA-Systeme muss 2 GB betragen
Azure Center for SAP solutions-Empfehlung: Der Auslagerungsbereich für HANA-Systeme muss 2 GB betragen.
Weitere Informationen finden Sie unter Datenbankinstanz – SwapSpaceForSap (Azure Center for SAP-Empfehlung: Der Auslagerungsbereich für HANA-Systeme muss 2 GB betragen).
Azure Center für SAP-Empfehlung: Stellen Sie sicher, dass alle NICs für ein System an dasselbe VNet angefügt sind.
Azure Center for SAP-Empfehlung: Alle NICs für ein System müssen an dasselbe VNet angefügt sein.
Erfahren Sie mehr über Central-Server-Instanz – AllVmsHaveSameVnetAscs (Azure Center für SAP-Empfehlung: Sicherstellen, dass alle NICs für ein System an dasselbe VNet angefügt sind).
Azure Center für SAP-Empfehlung: Stellen Sie sicher, dass alle NICs für ein System an dasselbe VNet angefügt sind.
Azure Center for SAP-Empfehlung: Alle NICs für ein System müssen an dasselbe VNet angefügt sein.
Erfahren Sie mehr über Datenbankinstanz – AllVmsHaveSameVnetDb (Azure Center für SAP-Empfehlung: Sicherstellen, dass alle NICs für ein System an dasselbe VNet angefügt sind).
Azure Center für SAP-Empfehlung: Sicherstellen, dass die Netzwerkkonfiguration für HANA und das Betriebssystem optimiert ist
Azure Center for SAP solutions-Empfehlung: Stellen Sie sicher, dass die Netzwerkkonfiguration für HANA und das Betriebssystem optimiert ist.
Erfahren Sie mehr über Datenbankinstanz – NetworkConfigForSap (Azure Center für SAP-Empfehlung: Sicherstellen, dass die Netzwerkkonfiguration für HANA und OS optimiert ist).
Storage
Erstellen einer Sicherung eines HSM
Erstellen Sie eine regelmäßige HSM-Sicherung, um Datenverluste zu verhindern und das HSM im Notfall wiederherstellen zu können.
Empfehlung für Anwendungsvolumegruppen-SDK
Die API-Mindestversion für das Azure NetApp Files-Feature der Anwendungsvolumegruppen muss 2022-01-01 sein. Wir empfehlen, wenn möglich 2022-03-01 zu verwenden, um die API vollständig nutzen zu können.
Weitere Informationen finden Sie unter Volume – Empfehlung für die Version des Application Volume Group SDK (Empfehlung für das Application Volume Group SDK).
SDK-Empfehlung für Verfügbarkeitszonenvolumes
Für das Feature Azure NetApp Files Verfügbarkeitszonenvolume-Platzierung wird die SDK-Mindestversion 2022-05-01 empfohlen, um die Bereitstellung neuer Azure NetApp Files-Volumes in der von Ihnen angegebenen Azure-Verfügbarkeitszone (VZ) zu ermöglichen.
Weitere Informationen finden Sie unter Volume – Empfehlung für die Version des Azure NetApp Files AZ Volume SDK (Empfehlung für das Availability Zone Volumes SDK).
SDK-Empfehlung für die zonenübergreifende Replikation
Für das Feature zonenübergreifende Replikation von Azure NetApp Files wird die SDK-Mindestversion 2022-05-01 empfohlen, damit Sie Volumes innerhalb derselben Region über Verfügbarkeitszonen hinweg replizieren können.
Weitere Informationen finden Sie unter Volume – Empfehlung für das Azure NetApp Files Cross Zone Replication SDK.
Volumeverschlüsselung mithilfe von kundenseitig verwalteten Schlüsseln mit Empfehlung für das Azure Key Vault SDK
Die API-Mindestversion für kundenseitig verwaltete Azure NetApp Files-Schlüssel mit dem Azure Key Vault-Feature ist 2022-05-01.
Weitere Informationen finden Sie unter Volume – CMK mit Empfehlung für das AKV SDK (Volumeverschlüsselung mithilfe von kundenseitig verwalteten Schlüsseln mit Empfehlung für das Azure Key Vault SDK).
SDK-Empfehlung für kalten Zugriff
Für die Standarddienstebene mit dem Feature kalter Zugriff wird die SDK-Mindestversion 2022-03-01 empfohlen, um das Verschieben inaktiver Daten in ein Azure-Speicherkonto (die kalte Ebene) zu ermöglichen und Speicher innerhalb von Azure NetApp Files-Volumes freizugeben, was zu Gesamtkosteneinsparungen führt.
Weitere Informationen finden Sie unter Kapazitätspool – Empfehlung für die Version des Azure NetApp Files Cool Access SDK (Empfehlung für das Cool Access SDK).
SDK-Empfehlung für große Volumes
Für die Automatisierung der Erstellung, Größenänderung und Löschung großer Volumes wird die SDK-Mindestversion 2022-xx-xx empfohlen.
Weitere Informationen finden Sie unter Volume – Empfehlung für das Large Volumes SDK.
Verhindern der Erreichung des Abonnementgrenzwerts für Speicherkonten
In einer Region können maximal 250 Speicherkonten pro Abonnement unterstützt werden. Sie haben diesen Grenzwert bereits erreicht oder werden ihn in Kürze erreichen. Wenn Sie dieses Limit erreichen, können Sie keine weiteren Speicherkonten in dieser Kombination aus Abonnement und Region anlegen. Sehen Sie sich die unten empfohlene Vorgehensweise an, mit der vermieden werden kann, dass der Grenzwert erreicht wird.
Führen Sie zur Verbesserung der Zuverlässigkeit ein Update auf neuere Releases des Storage Java v12 SDK durch.
Wir haben festgestellt, dass für mindestens eine Ihrer Anwendungen eine ältere Version des Azure Storage Java v12 SDK verwendet wird, um Daten in Azure Storage zu schreiben. Leider besteht für die Version des verwendeten SDK ein kritisches Problem, bei dem bei Wiederholungsversuchen (beispielsweise aufgrund von HTTP 500-Fehlern) fehlerhafte Daten hochgeladen werden, was dazu führt, dass ein ungültiges Objekt geschrieben wird. Das Problem wurde in neueren Versionen des Java v12 SDK behoben.
Virtuelle Desktopinfrastruktur
Fehlende Berechtigungen für „VM bei Verbindung starten“
Wir haben festgestellt, dass Sie „VM bei Verbindung starten“ aktiviert haben, Azure Virtual Desktop aber nicht die Rechte für die Energieverwaltung von VMs in Ihrem Abonnement erteilt haben. Daher erhalten Ihre Benutzer, die eine Verbindung mit Hostpools herstellen, keine Remotedesktopsitzung. Informationen zu den Anforderungen finden Sie in der Featuredokumentation.
Keine Überprüfungsumgebung aktiviert
Wir haben festgestellt, dass in Ihrem aktuellen Abonnement keine Validierungsumgebung aktiviert ist. Beim Erstellen Ihrer Hostpools haben Sie auf der Registerkarte „Eigenschaften“ unter „Validierungsumgebung“ die Option „Nein“ ausgewählt. Die Aktivierung von mindestens einem Hostpool mit einer Validierungsumgebung stellt die Geschäftskontinuität sicher durch Azure Virtual Desktop-Dienstbereitstellungen mit frühzeitiger Erkennung potenzieller Probleme.
Weitere Informationen zu Hostpool: ValidationEnvHostPools (Keine Überprüfungsumgebung aktiviert)
Nicht genügend Produktionsumgebungen aktiviert
Wir haben ermittelt, dass zu viele Ihrer Hostpools eine Validierungsumgebung aktiviert haben. Damit Überprüfungsumgebungen ihren Zweck am besten erfüllen, müssen Sie mindestens eine Umgebung dieser Art nutzen. Die Anzahl von Überprüfungsumgebungen sollte aber niemals die Hälfte Ihrer Anzahl von Hostpools überschreiten. Indem Sie eine ausgewogene Anzahl von Hostpools mit aktivierter und mit deaktivierter Überprüfungsumgebung nutzen, können Sie am besten von den Vorteilen der mehrstufigen Bereitstellungen profitieren, über die Azure Virtual Desktop im Rahmen bestimmter Updates verfügt. Öffnen Sie zum Beheben dieses Problems die Eigenschaften Ihres Hostpools, und wählen Sie neben der Einstellung „Überprüfungsumgebung“ die Option „Nein“ aus.
Web
Einrichten von Stagingumgebungen in Azure App Service
Stellen Sie zuerst eine App auf einem Slot bereit, und wechseln Sie es dann in die Produktion. Dies stellt sicher, dass alle Instanzen des Slots vor dem Austausch hochgefahren werden und beseitigt Ausfallzeiten. Die Datenverkehrsumleitung ist nahtlos. Aufgrund von Swap-Vorgängen werden keine Anforderungen verworfen.
Weitere Informationen finden Sie unter App Service – AzureAppService-StagingEnv (Einrichten von Stagingumgebungen in Azure App Service).
Aktualisieren der Dienstconnector-API-Version
Wir haben API-Aufrufe aus veralteten Dienstconnector-APIs für Ressourcen unter diesem Abonnement identifiziert. Wir empfehlen, zur neuesten Version der Dienstconnector-API zu wechseln. Sie müssen Ihren vorhandenen Code oder Tools aktualisieren, um die neueste API-Version zu verwenden.
Weitere Informationen finden Sie unter App Service – UpgradeServiceConnectorAPI (Aktualisieren der Dienstconnector-API-Version).
Aktualisieren des Dienstconnector-SDK auf die neueste Version
Wir haben API-Aufrufe von einem veralteten Dienstconnector-SDK identifiziert. Es wird empfohlen, ein Upgrade auf die neueste Version durchzuführen, um aktuelle Fixes, Leistungsverbesserungen und neue Funktionen zu erhalten.
Weitere Informationen finden Sie unter App Service – UpgradeServiceConnectorSDK (Aktualisieren des Dienstconnector-SDK auf die aktuelle Version).
Nächste Schritte
Informieren Sie sich ausführlicher über Optimaler Betrieb: Microsoft Azure Well-Architected Framework.