Speicherdisziplinen für SQL Managed Instance mit Azure Arc-Unterstützung
Der Speicher ist eine kritische Komponente in einer Bereitstellung von SQL Managed Instance mit Azure Arc-Unterstützung. Das Verständnis, wie sich die in diesem Dokument beschriebenen Speicherkonzepte auf die Funktionsweise von Kubernetes-Clustern auswirken, ist ein wichtiger Aspekt der Entwurfsentscheidungen für den Speicher und seiner Verwaltung.
Anstatt direkt mit dem zugrunde liegenden Speicher zu interagieren, bietet Kubernetes mithilfe von Speicherklassen eine Abstraktionsebene für verschiedene Speichertechnologien. Cloudanbieter, Hardwarehersteller und andere von Kubernetes verwaltete Plattformen bieten verschiedene StorageClass-Optionen für bestimmte Umgebungen und Implementierungsszenarien.
SQL Managed Instance mit Azure Arc-Unterstützung beschränkt oder erzwingt keine Speicherklassen. Daher ist es wichtig, den richtigen Speicherentwurf und die richtige Konfiguration auszuwählen. Der Speicherentwurf für SQL Managed Instance mit Azure Arc-Unterstützung ist ebenso wichtig wie die Auswahl der Hintergrundspeichergeräte für eine auf Bare-Metal-Computern oder VMs ausgeführte SQL Server-Instanz. Diese Entscheidungen stellen im Grunde genommen Ihre Anforderungen bezüglich Recovery Point Objective (RPO), Recovery Time Objective (RTO), Kapazität und Leistung dar.
Für SQL Managed Instance-Bereitstellungen mit Azure Arc-Unterstützung ist die effektive Planung der Speicherfunktionen und -konfiguration entscheidend für den erfolgreichen Betrieb. Im Folgenden werden die zu berücksichtigenden Faktoren im Zusammenhang mit dem Speicher erläutert, und im Anschluss finden Sie Empfehlungen für die Konfiguration von SQL Managed Instance mit Azure Arc-Unterstützung.
Aufbau
Das folgende Architekturdiagramm zeigt den logischen Entwurf von Azure Arc-fähigen Datendienstkomponenten. Zu diesen Komponenten zählen ein erforderlicher Azure Arc-Datencontroller und mindestens eine Instanz von SQL Managed Instance mit Azure Arc-Unterstützung, die zur Referenz bereitgestellte Datenbanken enthält. Sowohl der Azure Arc-Datencontroller als auch die Instanz von SQL Managed Instance mit Azure Arc-Unterstützung bieten Optionen für Hintergrundspeichergeräte, die von Kubernetes-Distributions- und Speicherinfrastrukturanbietern abhängig sind.
Überlegungen zum Entwurf
Im Folgenden sind Überlegungen aufgeführt, die beim Entwurf und bei der Konfiguration des Speichers berücksichtigt werden sollten.
Speicherklassen
Die Auswahl der richtigen Kubernetes-Speicherklasse und -Konfiguration für Ihre Azure Arc-fähigen Datendienstkomponenten ist wichtig für die Leistung, Resilienz und Kapazität des Datenspeichers.
StorageClass (Speicherklasse), PersistentVolume (persistentes Volume, PV) und PersistentVolumeClaim (Anspruch auf ein persistentes Volume, PVC) sind Kubernetes-Ressourcenobjekte, die das System bei der Bereitstellung der Azure Arc-fähigen Datendienstkomponenten in Ihrem Kubernetes-Cluster erstellt.
StorageClass-Optionen variieren je nach den Funktionen, die Ihr Cloudanbieter und Hardwarehersteller anbieten, und der vom Kubernetes-Administrator festgelegten Konfiguration. PersistentVolumeClaim fordert die Erstellung eines PersistentVolume für die StorageClass und die angeforderte Größe an. Das folgende Diagramm veranschaulicht die Beziehung zwischen diesen Kubernetes-Ressourcen und potenziellen Optionen für die Speicherklassen.
Die PV- und PVC-Kubernetes-Ressourcen werden beim Bereitstellen des Azure Arc-Datencontrollers und der Instanz von SQL Managed Instance mit Azure Arc-Unterstützung konfiguriert.
Sie haben die Wahl zwischen zwei unterschiedlichen Speichertypen:
- Lokal: Ein auf einem lokalen Speichergerät bereitgestelltes Volume, das an den Kubernetes-Knoten angefügt ist, auf dem der Pod ausgeführt wird. Dieser Speichertyp bietet in der Regel eine geringere Wartezeit sowie höhere IOPS-Werte (Eingabe-/Ausgabevorgänge pro Sekunde) und einen höheren Durchsatz im Vergleich zu Remotespeicher/freigegebenem Speicher.
- Remotespeicher/freigegebener Speicher: NAS-Geräte (Network Attached Storage), die in der Regel integrierte Redundanz bieten. Gängige Speicheroptionen sind NAS-Geräte und SAN-Geräte (Storage Area Network).
Berücksichtigen Sie beim Auswählen einer StorageClass die folgenden Standards. Diese Kriterien würden auch für jeden von Ihnen erstellten Datenbankserver gelten:
- Leistung: Der E/A-Durchsatz (Eingabe/Ausgabe) und IOPS-Wert des Speichergeräts sollten Ihre Datenbankanforderungen erfüllen.
- Verhältnis von Lese- zu Schreibvorgängen: Das Verständnis der Workload kann Ihnen bei der Auswahl von unterstützender Hardware helfen, die Ihre Anforderungen optimal erfüllt und erschwinglich ist. Für schreibintensive Workloads können RAID 0-Konfigurationen genutzt werden, während für Daten, auf die selten zugegriffen wird, ein SAN-Gerätespeicher die beste Wahl sein kann.
- Datenbankisolation und -zusammenstellung: Alle Datenbanken in einer Instanz von SQL Managed Instance mit Azure Arc-Unterstützung teilen ein persistentes Volume (PV), sodass Sie Datenbanken in separate Instanzen von SQL Managed Instance mit Azure Arc-Unterstützung verschieben und Speicherressourcenkonflikte vermeiden können.
- Kapazität: Die definierte Speichergröße sollte der zukünftigen Kapazität Ihres Datencontrollers und Ihrer Datenbankinstanzen entsprechen, damit Sie die Größe eines PVC nicht ändern müssen. Berücksichtigen Sie alle Speicherbeschränkungen, die möglicherweise für Ihre ausgewählte StorageClass gelten.
- Zugriffsmodus: Speicherklassenanbieter verfügen über verschiedene Zugriffsmodi, die unterschiedliche Funktionen für die Bereitstellung von Speicher sowie das Lesen aus und Schreiben in Speicher durch Pods unterstützen. RWX (Read Write Many, mehrfacher Lese-/Schreibzugriff) ist für das SQL-Sicherungsvolume erforderlich.
- Redundanz: Replikation der Daten auf der physischen Speicherebene (RAID) zur Unterstützung eines nahtlosen Failovers bei Fehlern von Hardwaredatenträgern, die von der durch Verfügbarkeitsgruppen bereitgestellten Redundanz auf der Datenbankebene getrennt ist.
Sowohl der Azure Arc-Datencontroller als auch die Azure Arc-fähigen SQL Managed Instance-Datendienste bieten differenzierte Optionen zum Konfigurieren verschiedener Speicherklassen für Datenbankdaten. Diese Datendienste bieten auch Protokolle, die die flexible Auswahl von Speicherklassen entsprechend den Anforderungen ermöglichen.
Datencontroller
Für die Erstellung von Instanzen von SQL Managed Instance mit Azure Arc-Unterstützung ist ein einzelner Azure Arc-Datencontroller für einen Kubernetes-Cluster erforderlich. Die Verwendung mehrerer Datencontroller, die in einem Cluster ausgeführt werden, wird nicht unterstützt.
Der Azure Arc-Datencontroller verfügt über vier verschiedene zustandsbehaftete Pods, die im Kubernetes-Cluster ausgeführt werden: Controller-SQL, Controller-API, Protokolldatenbank und Metrikdatenbank. Jeder Pod erfordert zwei persistente Volumes für die Daten- und Protokollvolumes. Alle Datencontrollerkomponenten erfordern eine Remote-StorageClass zum Sicherstellen der Dauerhaftigkeit von Daten, da sie die Datendauerhaftigkeit selbst nicht nativ bereitstellen.
Berücksichtigen Sie die Compute- und Speicherressourcen, die der Azure Arc-Datencontroller benötigt. Das folgende Diagramm stellt die Datencontrollerspeicher-, PV- und PVC-Kubernetes-Ressourcen dar.
Die standardmäßige Volumegröße des Datencontrollers ist die empfohlene Mindestgröße. Der von Ihnen verwendete Speicher hängt von der Anzahl von Datenbanken, der Verwendung der Datenbanken und der Anzahl generierter Protokolle ab. Die Azure Arc-Datencontroller-StorageClass ist nicht wartezeitempfindlich. Für Benutzer kann die Verwendung der Grafana- und Kibana-Schnittstellen mit leistungsstarkem Speicher allerdings von Vorteil sein, wenn Sie eine große Anzahl von SQL Managed Instance-Bereitstellungen mit Azure Arc-Unterstützung in einem Cluster haben. Grafana und Kibana sind Open Source-Tools für die Überwachungsvisualisierung, die mit dem Datencontroller bereitgestellt werden und über Dashboards zum Anzeigen von Metriken und Protokollen für SQL Managed Instance mit Azure Arc-Unterstützung verfügen.
Bereitstellung des Datencontrollers
Beim Bereitstellen des Azure Arc-Datencontrollers konfigurieren Sie die StorageClass und die Speicherkapazität sowohl für Protokolle als auch für Daten. Die Konfiguration des Speichers für Protokolle und Daten gilt dann für alle acht PVs, die Sie für die Datencontrollerpods erstellen. Während der Bereitstellung können Sie eine benutzerdefinierte Bereitstellungsvorlage angeben, die Standardparameter wie Kapazität, Protokollaufbewahrung und sicherheitsbezogene Elemente wie Kubernetes-Diensttypen außer Kraft setzt. Sobald die Bereitstellung abgeschlossen ist, werden PV- und PVC-Kubernetes-Objekte erstellt.
Wichtig ist hierbei, dass die StorageClass für den Datencontroller nach der Bereitstellung nicht geändert werden kann. Wenn Sie keine StorageClass angeben, verwendet der Datencontroller die standardmäßige Kubernetes-StorageClass, die je nach Kubernetes-Instanz oder -Anbieter variieren kann.
Wenn Sie den Azure Arc-Datencontroller deinstallieren, werden alle persistenten Volumes, die ihm zugeordnet sind, gelöscht. Archivieren Sie vor der Deinstallation des Datencontrollers alle Protokolle von Azure Arc-fähigen Datendiensten auf der Steuerungsebene, die Ihre Organisation speichern muss.
SQL Managed Instance mit Azure Arc-Unterstützung
SQL Managed Instance mit Azure Arc-Unterstützung bietet je nach geschäftlichen Anforderungen zwei verschiedene Dienstebenen: „Universell“ und „Unternehmenskritisch“. Prüfen Sie für beide Ebenen unbedingt die konfigurierbaren minimalen und maximalen Grenzwerte für SQL Managed Instance mit Azure Arc-Unterstützung, und stellen Sie sicher, dass der bereitgestellte Kubernetes-Cluster über die entsprechende Compute- und Speicherkapazität verfügt.
In Szenarien mit mehreren Datenbanken auf einer Datenbankinstanz verwenden alle Datenbanken die gleiche StorageClass, den gleichen PVC und das gleiche PV, die für die Instanz von SQL Managed Instance mit Azure Arc-Unterstützung angegeben sind. Es ist möglich, mehrere Instanzen von SQL Managed Instance mit Azure Arc-Unterstützung in einem einzelnen Kubernetes-Cluster auszuführen. Diese Konfiguration ermöglicht die Verwendung unabhängiger persistenter Volumes und kann dabei helfen, E/A-Konflikte verschiedener Datenbanken zu trennen, indem Sie die Datenbanken in verschiedenen Instanzen von SQL Managed Instance mit Azure Arc-Unterstützung bereitstellen.
In der folgenden Tabelle werden die unterschiedlichen persistenten Volumes, die von den einzelnen SQL Managed Instance-Pods mit Azure Arc-Unterstützung verwendet werden, und ihr Zweck beschrieben.
| Persistentes Volume | BESCHREIBUNG | Anforderungen an die Speicherklasse |
|---|---|---|
| Daten | Datendateien von SQL-Datenbank (MDF-Dateien) | Abhängig von der Ebene |
| DataLogs | Protokolldateien von SQL-Datenbank (LDF-Dateien) | Abhängig von der Ebene |
| Protokolle | SQL-Agent, Fehlerprotokolle, Ablaufverfolgungsdateien, Integritätsprotokolle | Abhängig von der Ebene |
| Backups | SQL Server-Sicherungsdateien, einschließlich vollständiger und differenzierender Protokolle sowie Transaktionsprotokolle | Remote, ReadWriteMany-Zugriffsmodus |
Universelle Dienstebene
Bei der Dienstebene „Universell“ von SQL Managed Instance mit Azure Arc-Unterstützung muss Remotespeicher für die Datenbankinstanz verwendet werden, damit die Daten bei einem Fehler eines Pods für neu erstellte Pods verfügbar bleiben. Das Failover wird von der Kubernetes-Pod- und Knotenorchestrierung verwaltet. Diese Konfiguration ist weniger komplex als die Dienstebene „Unternehmenskritisch“, bei der SQL-Verfügbarkeitsgruppen und mehrere SQL Managed Instance-Replikate mit Azure Arc-Unterstützung verwendet werden. Bei der Konfiguration mit einem einzelnen Pod der Dienstebene „Universell“ können Sie die Speichermenge minimieren, da Sie die Speicherkapazität nicht für andere Replikate duplizieren müssen.
Dienstebene „Unternehmenskritisch“
Bei der Dienstebene „Unternehmenskritisch“ wird ein Modell mit mehreren Pods verwendet, bei dem Daten- und Protokollvolumes in lokalen oder Remotespeicherklassen gespeichert werden können. Lokale Speicherklassen bieten in der Regel eine bessere Leistung in Bezug auf die Wartezeit und den Durchsatz, da das Speichergerät direkt mit dem Knoten verbunden ist. Remotespeicher bietet meist integrierte Redundanz, im Vergleich zu lokalem Speicher sind jedoch oft die Wartezeit höher und der Durchsatz geringer. Beachten Sie, dass die Verwendung einer größeren Anzahl von Datenbankreplikaten mit der Dienstebene „Unternehmenskritisch“ zusätzliche persistente Volumes für Daten, Protokolle und Datenprotokolle (DataLogs) erfordert. Die erforderliche Gesamtspeicherkapazität ist deutlich höher.
Das folgende Diagramm zeigt die Speicherkonfiguration „Unternehmenskritisch“ für SQL Managed Instance mit Azure Arc-Unterstützung mit zwei Replikaten.
Die Dienstebene „Unternehmenskritisch“ ermöglicht es Ihnen, zwei oder drei sekundäre Replikate zu konfigurieren. Das Failover wird von der SQL Always On-Verfügbarkeitsgruppe verwaltet, wodurch die Downtime für Upgrades und Fehler kürzer ist als bei der Ebene „Universell“.
Das Konfigurieren mehrerer Replikate mit Datenreplikation im Modus mit synchronem Commit sorgt für einen besseren Schutz vor Fehlern (z. B. bei fehlerhaften Pods und Knoten oder fehlerhafter Speicherhardware). Diese Konfiguration bietet Schutz vor Fehlern, da mehrere Kopien der Daten auf den Replikaten vorhanden sind. Erwägen Sie, sekundäre Replikate als Instanzen mit horizontaler Leseskalierung zu konfigurieren, mit denen Clients bei der Verwendung des sekundären Listenerendpunkts eine Verbindung herstellen können.
Bereitstellung und Deinstallation von SQL Managed Instance mit Azure Arc-Unterstützung
Bei der Bereitstellung von SQL Managed Instance mit Azure Arc-Unterstützung haben Sie die Flexibilität, jedem der erforderlichen persistenten Volumes von SQL Managed Instance mit Azure Arc-Unterstützung verschiedene Speicherklassen zuzuweisen. Möglicherweise benötigen Sie leistungsstärkere Speicheroptionen für Daten und Datenprotokolle, können aber für die Volumes für Protokolle und Sicherungen kostengünstigere StorageClass-Optionen verwenden, um Kosten zu sparen. Stellen Sie in Szenarien, in denen Sie lokalen Speicher verwenden, sicher, dass die Volumes auf unterschiedliche Knoten und physische Speichergeräte verteilt werden können, um Konflikte bei der Datenträger-E/A zu vermeiden. Das Platzieren von Daten und Datenprotokollen auf demselben physischen Laufwerk kann zu Konflikten für dieses Speicherlaufwerk und somit zu einer Beeinträchtigung der Leistung führen. Erwägen Sie stattdessen, die Daten und Datenprotokolle auf separaten Speicherlaufwerken zu platzieren, um E/A-Vorgänge für Datenbankdaten und Protokolle zu parallelisieren.
Wenn Sie die Instanz von SQL Managed Instance mit Azure Arc-Unterstützung löschen, werden die zugehörigen PVs und PVCs nicht entfernt. Durch dieses Verhalten wird sichergestellt, dass Sie im Fall einer versehentlichen Löschung auf die Datenbankdateien zugreifen können.
Entwurfsempfehlungen
Im Folgenden sind Empfehlungen aufgeführt, die beim Entwurf und bei der Konfiguration des Speichers berücksichtigt werden sollten.
Speicherklassen für Produktionsworkloads
In der folgenden Tabelle sind die empfohlenen Speicherklassen für Produktionsworkloads für bestimmte öffentliche Clouds aufgeführt.
| Anbieter | Überprüfter und empfohlener Speicher |
|---|---|
| Azure Kubernetes Service (AKS) | Azure Managed Disks (Dienstebene „Premium“) |
| Amazon Elastic Kubernetes Service (EKS) | EBS-CSI-Speichertreiber |
| Google (GKE) | Persistente GCE-Datenträger |
Stellen Sie bei der Auswahl einer Produktions-StorageClass in lokalen Szenarien oder Multicloudszenarien sicher, dass die Speicherklasse Ihre Anforderungen bezüglich Speicherkapazität, IOPS, Redundanz und Durchsatz erfüllen kann. In den folgenden Abschnitten finden Sie weitere Empfehlungen für diese Szenarien.
Entwurf des Datencontrollers
Wählen Sie eine freigegebene Remote-StorageClass aus, um die Dauerhaftigkeit von Daten sicherzustellen. Wenn ein Pod oder Knoten entfernt wird, können Sie den Pod wieder online schalten und erneut mit dem persistenten Volume verbinden. Die unterstrichene StorageClass muss Redundanz und Hochverfügbarkeit bieten.
Wir empfehlen, beim Erstellen Ihres Datencontrollers für Azure Arc-fähige Datendienste eine benutzerdefinierte Bereitstellungsvorlage zu verwenden. Mithilfe einer benutzerdefinierten Vorlage können Sie die Speicherklassen, die Speichergröße für Daten und Protokolle, die Sicherheit und Kubernetes-Diensttypen optimieren. Sie können sie entsprechend Ihrer Umgebung und Ihrer Unternehmensanforderungen anpassen. Der Azure Arc-Datencontroller erfordert insgesamt acht persistente Volumes. Die standardmäßige Mindestkonfiguration ermöglicht 15 GiB für Daten und 10 GiB für Protokolle auf den PVs. Konfigurieren Sie eine Kapazität, die nicht nur die minimalen Empfehlungen erfüllt, sondern Wachstum unterstützt, wenn viele SQL Managed Instance-Implementierungen mit Azure Arc-Unterstützung in einem Cluster ausgeführt werden. Diese Konfiguration verhindert, dass die Größe von PVCs später geändert werden muss.
Wenn Ihr Cluster viele Datenbanken und SQL Managed Instance-Bereitstellungen mit Azure Arc-Unterstützung enthält, empfehlen wir, eine latenzarme StorageClass auszuwählen. Eine geringere Wartezeit verbessert die Benutzererfahrung bei der Verwendung von Grafana- und Kibana-Schnittstellen.
Migration von SQL Managed Instance mit Azure Arc-Unterstützung
Wir empfehlen, alle neuen und vorhandenen Datenbanken, die von der Migration und Bereitstellung Ihrer Instanz von SQL Managed Instance mit Azure Arc-Unterstützung betroffen sind, einzuplanen und zu berücksichtigen. Durch entsprechende Planung können Sie verhindern, dass Sie Datenbanken zu einem späteren Zeitpunkt zwischen Instanzen verschieben müssen.
Stellen Sie SQL Managed Instance-Bereitstellungen mit Azure Arc-Unterstützung abhängig von Ihrer Kubernetes-Clusterorganisation basierend auf der Notwendigkeit zur Trennung von Umgebungen (Nicht-Produktion, Produktion) und Regionen sowie anderen geschäftlichen Faktoren auf verschiedenen Kubernetes-Clustern bereit. Weitere Empfehlungen finden Sie im Artikel zum Entwurfsbereich Ressourcenorganisation. Achten Sie beim Konfigurieren mehrerer Datenbankinstanzen auf einem Cluster darauf, ausgelastete Datenbanken in jeweils eigenen Instanzen zu trennen, um E/A-Konflikte zu vermeiden.
Verwenden Sie Knotenbezeichnungen, um sicherzustellen, dass Datenbankinstanzen auf separaten Knoten platziert werden, damit der gesamte E/A-Datenverkehr auf mehrere Knoten verteilt wird. Informationen zum Konfigurieren der Bezeichnungen finden Sie unter Kubernetes-Knotenbezeichnungen und Kubernetes-Knotenaffinitäts- und -antiaffinitätsbezeichnungen. Wenn Sie in einer virtualisierten Umgebung arbeiten, stellen Sie sicher, dass die E/A-Vorgänge auf der physischen Hostebene angemessen verteilt werden.
Planen Sie die Kapazität für SQL Managed Instance mit Azure Arc-Unterstützung mit entsprechenden Speichergrößen für Daten, Protokolle, Datenprotokolle und Sicherungen. Wenn Sie die Kapazität unter Berücksichtigung der aktuellen Anforderungen und des voraussichtlichen Wachstums für alle zukünftigen Datenbanken in den Instanzen von SQL Managed Instance mit Azure Arc-Unterstützung planen, können Sie verhindern, dass die Größe von PVCs später geändert werden muss. Wählen Sie separate physische Laufwerke für Daten und Datenprotokolle aus, um parallele E/A-Aktivität zu ermöglichen. Parallele E/A-Aktivität verbessert die Leistung, da mögliche Konflikte bei der Verwendung eines freigegebenen Laufwerks vermieden werden.
Die Bereitstellung der Dienstebene „Unternehmenskritisch“ oder „Universell“ von SQL Managed Instance mit Azure Arc-Unterstützung kann aufgrund verschiedener Faktoren erforderlich sein. Die Ebene „Unternehmenskritisch“ mit lokalem Speicher bietet jedoch die niedrigste Wartezeit und höchste Verfügbarkeit. Überprüfen Sie den Entwurfsbereich Geschäftskontinuität für SQL Managed Instance mit Azure Arc-Unterstützung. Dort finden Sie Empfehlungen für Zeitpunktwiederherstellung, Hochverfügbarkeit und Notfallwiederherstellung. Sehen Sie sich außerdem den Entwurfsbereich Kostengovernance für SQL Managed Instance mit Azure Arc-Unterstützung an, um mehr über die Kostenauswirkungen der Dienstebenen zu erfahren.
Die folgenden Unterabschnitte enthalten spezifischere Empfehlungen für die einzelnen Dienstebenen:
Empfehlungen für die Dienstebene „Universell“
Für eine optimale Leistung wird empfohlen, eine latenzarme Remote-StorageClass für die persistenten Volumes für Daten und Datenprotokolle auszuwählen. Vermeiden Sie die Verwendung einer StorageClass, die Netzwerkpartitionen einführt, z. B. einen lokalen Cluster, der zur Verwendung einer über das Internet bereitgestellten StorageClass für die persistenten Volumes für Sicherung und Protokolle konfiguriert ist.
Empfehlungen für die Dienstebene „Unternehmenskritisch“
Es wird empfohlen, die Unterschiede der Verfügbarkeitsmodi zu überprüfen, da je nach ausgewähltem Modus eine unterschiedliche Konfiguration erforderlich ist.
Verwenden Sie für Szenarien, die eine geringstmögliche Wartezeit erfordern, lokalen Speicher, wenn dies bei Ihrer Kubernetes-Infrastruktur möglich ist. Die lokalen Speichervolumes sollten auf unterschiedliche zugrunde liegende Speichergeräte verteilt werden, um Datenträger-E/A-Konflikte zu vermeiden und die Leistung zu maximieren. Das Speichergerät sollte nicht über mehrere Funktionen verfügen, z. B. die Betriebssystempartition hosten.
Konfigurieren Sie für leseintensive Workloads und Hochverfügbarkeit mehrere Replikate, und konfigurieren Sie Ihre Anwendungen oder Clients zur Verwendung von sekundären Replikaten als Instanzen mit horizontaler Leseskalierung. Sekundäre Replikate sind standardmäßig nicht lesbar. Sie können die Einstellung konfigurieren.
Überwachung
Es wird empfohlen, alle PVCs zu überwachen, die von Azure Arc-fähigen Datendiensten erstellt werden, einschließlich des Azure Arc-Datencontrollers und aller Instanzen von SQL Managed Instance mit Azure Arc-Unterstützung in einem Cluster. Legen Sie Warnungen fest, damit Sie benachrichtigt werden, wenn die Kapazität eines PVC fast erreicht ist. Die Benachrichtigung ermöglicht es Ihnen, die Größe des PVC vor dem Erreichen der Kapazität zu ändern. Für direkt verbundene Cluster erfolgen die Überwachung von PVCs und die Benachrichtigung durch Azure Monitor und Container Insights. Verwenden Sie bei indirekt verbundenen Clustern für die Überwachung und Benachrichtigung Grafana und Kibana. Die Grafana-Installation enthält Dashboards für Metriken für SQL Managed Instance mit Azure Arc-Unterstützung und Kubernetes-Ressourcen.
Weitere Empfehlungen zur Überwachung von SQL Managed Instance mit Azure Arc-Unterstützung finden Sie unter Governancedisziplinen für SQL Managed Instance mit Azure Arc-Unterstützung.
Nächste Schritte
Weitere Informationen zu Ihrer Hybrid- und Multi-Cloud-Umgebung finden Sie in den folgenden Artikeln:
- Sehen Sie sich die Speicherkonfiguration für Azure Arc-fähige Datendienste an.
- Prüfen Sie die validierten Kubernetes-Distributionen für Azure Arc-fähige Datendienste.
- Sehen Sie sich den Dimensionierungsleitfaden für Azure Arc-fähige Datendienste an.
- Informieren Sie sich über die Überwachung mit Grafana und Kibana einer Instanz von SQL Managed Instance mit Azure Arc-Unterstützung.
- Erleben Sie automatisierte Szenarien für SQL Managed Instance mit Azure Arc-Unterstützung mit Azure Arc Jumpstart.
- Weitere Informationen zu Azure Arc finden Sie im Azure Arc-Lernpfad auf Microsoft Learn.