Empfehlungen für optimalen Betrieb
Empfehlungen zum optimalen Betrieb in Azure Advisor können Sie bei folgenden Aspekten unterstützen:
- Effizienz von Prozessen und Workflows.
- Verwaltbarkeit von Ressourcen.
- Bewährte Methoden 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 SDK des plastischen Readers 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 SDK des plastischen Readers 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 der Tabellencacherichtlinie, um sie an die Nutzungsmuster anzupassen (Rückblickzeitraum für Abfrage)
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 aus 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 Verwaltungs- oder Dienst-API für Batch aufgerufen, die als veraltet markiert 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. Erstellen Sie den Pool mit einem neuen Image neu, um mögliche Unterbrechungen zu vermeiden. 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. Erhöhen Sie jetzt Ihr Kontingent, um die Bereitstellung von mehr Ressourcen zu ermöglichen. Weitere Informationen
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 schädlicher 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 im Zusammenhang mit nicht authentifizierten Remotebefehlsausführungen ermöglicht nicht authentifizierten Angreifer*innen mit Netzwerkzugriff auf die iControl-REST-Schnittstelle, über die BIG-IP-Verwaltungsschnittstelle und eigene IP-Adressen, um beliebige Systembefehle auszuführen, Dateien zu erstellen oder zu löschen und Dienste zu deaktivieren. 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 Gerätemodus 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 virtuelle Netzwerkgerät aktiviert ist. Auf dem virtuellen Computer, auf dem dieses virtuelle Netzwerkgerät bereitgestellt wird, kann es während eines Plattformwartungsvorgangs zu Konnektivitätsproblemen kommen. Es wird empfohlen, den Artikel des Anbieters zu befolgen: https://aka.ms/Citrix_CTX331516
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 aus 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 neueste API-Version.
Die API-Version, die Sie für Microsoft.App verwenden, ist veraltet. Verwenden Sie die neueste 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 neueste API-Version.).
Aktualisieren des Clusterdienstprinzipals
Der Dienstprinzipal dieses Clusters ist abgelaufen, und der Cluster ist erst fehlerfrei, wenn der Dienstprinzipal aktualisiert wurde.
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. Eine Anpassung an sich ändernde Lastbedingungen wird nicht durchgeführt, sofern Sie keine anderen Verfahren für die Autoskalierung Ihres Clusters nutzen.
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 Podsicherheitsrichtlinien aktiviert, die demnächst 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-/Schreibwartezeit 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 SKU „Mariner“ entspricht „AzureLinux“. Allerdings wird empfohlen, für zukünftige Updates und zukünftigen Support zur SKU „AzureLinux“ zu wechseln, da „AzureLinux“ die 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 der Tarif „Standard“, der 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 Verwaltbarkeitsmodus „Vollständig“ sind keine Kosten verbunden. Es sind Systemadministratorberechtigungen erforderlich. Beachten Sie, dass die Installation des bzw. das Upgrade auf den vollständigen Modus ein Onlinevorgang ist. Es ist kein Neustart erforderlich.
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. Davon profitieren wahrscheinlich solche Container, bei denen die RU/s pro physischer Partition < 3.000 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 – Flexible 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 Grenze 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 dass 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 flexiblen MySQL-Server, um ihn vor versehentlichen Löschungen und Änderungen durch Benutzer*innen 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
Hinzufügen von Firewallregeln zum Schutz Ihres Servers vor nicht autorisiertem Zugriff
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 Incidents, 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 https://aka.ms/TLSVersions.
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 https://aka.ms/TLSVersions.
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).
Cloud Services-Caches 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. Folgen Sie den Anweisungen unter dem folgenden Link, um mehr über die Migration zu einer Instanz ohne diese Abhängigkeit zu erfahren. Wenn Sie Ihren Cache auf Redis 6 aktualisieren müssen, beachten Sie, dass die Aktualisierung eines Cache, 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 außerhalb von Cloud Services abgeschlossen haben, kann es bis zu 24 Stunden dauern, bis diese Empfehlung entfernt wird.
Weitere Informationen finden Sie unter Redis Cache-Server – MigrateFromCloudService (Cloud Services-Caches werden im August 2024 eingestellt. Migrieren Sie vor diesem Datum, um Probleme zu 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 Features 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 Kontrolle über Gatewaybereitstellungen hinweg und können den Zugriff im Falle einer Sicherheitsverletzung ganz einfach widerrufen.
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 überprüfen“ 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 veralteter 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 Version (v1) der Konfigurations-API 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 Sie 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 identifiziert, 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 die Fallbackroute erneut 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 ermittelt, dass für mindestens eine Ihrer Warnungsregeln im Bedingungsabschnitt ungültige Abfragen angegeben sind. 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 die 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 aktuellen Funktionen zu erhalten, empfiehlt es sich, zur neuesten 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 die Sicherung, um verschiedene Vorteile zu nutzen, z. B. standardisierte, von Azure angebotene Erfahrungen bei der Verwaltung von Warnungen 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 Application Gateway-Instanz nicht in der Lage ist, die neueste 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 ein oder mehrere Ihrer Anwendungsgateways aufgrund eines falsch konfigurierten Key Vault kein Zertifikat erhalten können. 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 Aufskalierung bei hohem Datenverkehrsaufkommen zu ermöglichen, was zu Ausfallzeiten führen kann.
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 Traffic Analytics können Sie „Top Talkers“ für Azure-Bereitstellungen und andere Bereitstellungen anzeigen, geöffnete Ports, Protokolle und schädliche 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 Analyseergebnisse für Ihren Datenverkehr zu erhalten.
Einrichten von Stagingumgebungen in Azure App Service
Stellen Sie eine App zuerst in einem Slot bereit, und überführen Sie sie dann in die Produktion, um sicherzustellen, dass alle Instanzen vor der Überführung vorbereitet werden und Downtime vermieden wird. Die Umleitung des Datenverkehrs erfolgt übergangslos, und es gehen keine Anforderungen aufgrund des Tauschs verloren.
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 Korrekturaufgabe ausgelöst wird. Dadurch werden keine Tags für eine Ressourcengruppe geändert.
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 „Virtuelle Computer überwachen, die keine verwalteten Datenträger verwenden“ 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, die virtuelle Computer überwacht, die keine verwalteten Datenträger verwenden.
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. Es bietet mehrere Vorteile gegenüber dem Datenflussprotokoll der Network Security Group, wie z. B. vereinfachte Aktivierung, verbesserte Abdeckung, Genauigkeit, Leistung und Beobachtbarkeit der 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 vollständiger Sicherheit, verbesserten DevOps-Erfahrungen, vereinfachten Preisen und besseren Azure-Integrationen
Weitere Informationen zu Azure Front Door (klassisch) werden am 31. März 2027 eingestellt.
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. Als HANA-Szenarien können „OLAP“, „OLTP“, „OLAP: Scaleup“ und „OLTP: Scaleup“ verwendet werden. 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
Bearbeiten Sie im Betriebssystem der Anwendungs-VM die Datei „/etc/sysctl.conf“, und fügen Sie „net.ipv4.tcp_keepalive_time = 300“ hinzu, um eine schnellere Verbindungswiederherstellung nach einem ASCS-Failover zu ermöglichen. 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
Bearbeiten Sie im Betriebssystem der Anwendungs-VM die Datei „/etc/sysctl.conf“, und fügen Sie „net.ipv4.tcp_retries2 = 15“ hinzu, um eine schnellere Verbindungswiederherstellung nach einem ASCS-Failover zu ermöglichen. 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
Bearbeiten Sie im Betriebssystem der Anwendungs-VM die Datei „/etc/sysctl.conf“, und fügen Sie „net.ipv4.tcp_keepalive_probes = 9“ hinzu, um eine schnellere Verbindungswiederherstellung nach einem ASCS-Failover zu ermöglichen. 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
Bearbeiten Sie im Betriebssystem der Anwendungs-VM die Datei „/etc/sysctl.conf“, und fügen Sie „net.ipv4.tcp_tw_recycle = 0“ hinzu, um eine schnellere Verbindungswiederherstellung nach einem ASCS-Failover zu ermöglichen. 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
Bearbeiten Sie im Betriebssystem der Anwendungs-VM die Datei „/etc/sysctl.conf“, und fügen Sie „net.ipv4.tcp_retries1 = 3“ hinzu, um eine schnellere Verbindungswiederherstellung nach einem ASCS-Failover zu ermöglichen. 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
Bearbeiten Sie im Betriebssystem der Anwendungs-VM die Datei „/etc/sysctl.conf“, und fügen Sie „net.ipv4.tcp_tw_reuse = 0“ hinzu, um eine schnellere Verbindungswiederherstellung nach einem ASCS-Failover zu ermöglichen. 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
Bearbeiten Sie im Betriebssystem der Anwendungs-VM die Datei „/etc/sysctl.conf“, und fügen Sie „net.ipv4.tcp_keepalive_intvl = 75“ hinzu, um eine schnellere Verbindungswiederherstellung nach einem ASCS-Failover zu ermöglichen. 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 Netzwerkwartezeit zwischen App-VMs und DB-VMs für SAP-Workloads muss bei 0,7 ms oder weniger 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 Netzwerkwartezeit zwischen App-VMs und DB-VMs für SAP-Workloads muss bei 0,7 ms oder weniger 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, z. B. 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, z. B. 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, z. B. 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 zu nutzen.
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 (Empfehlung für das 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 (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 entweder bereits erreicht, oder dies wird in Kürze der Fall sein. 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 (z. B. bei HTTP 500-Fehlern) fehlerhafte Daten hochgeladen werden. Dies führt dazu, 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 die 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 bei Ihnen im aktuellen Abonnement keine Überprüfungsumgebung aktiviert ist. Beim Erstellen Ihrer Hostpools haben Sie auf der Registerkarte "Eigenschaften" unter "Überprüfungsumgebung" die Option "Nein" ausgewählt. Mit der Aktivierung von mindestens einem Hostpool mit einer Überprüfungsumgebung sorgen Sie für Geschäftskontinuität 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 bei Ihnen für zu viele Hostpools eine Überprüfungsumgebung aktiviert ist. 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 eine App zuerst in einem Slot bereit, und überführen Sie sie dann in die Produktion, um sicherzustellen, dass alle Instanzen vor der Überführung vorbereitet werden und Downtime vermieden wird. Die Umleitung des Datenverkehrs erfolgt übergangslos, und es gehen keine Anforderungen aufgrund des Tauschs verloren.
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.
Erfahren Sie mehr über App-Dienst – 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.
Erfahren Sie mehr App-Dienst – UpgradeServiceConnectorSDK (Aktualisieren des Service Connector SDK auf die neueste Version).
Nächste Schritte
Informieren Sie sich ausführlicher über Optimaler Betrieb: Microsoft Azure Well-Architected Framework.