vCore-Kaufmodell: Azure SQL Managed Instance

Gilt für:Azure SQL Managed Instance

In diesem Artikel wird das vCore-Kaufmodell für Azure SQL Managed Instance erläutert.

Überblick

Ein virtueller Kern (V-Kern) repräsentiert eine logische CPU und bietet Ihnen die Möglichkeit, die physischen Hardwaremerkmale (z. B. Anzahl der Kerne, Arbeitsspeicher und Speichergröße) auszuwählen. Beim vCore-basierten Kaufmodell erhalten Sie Flexibilität, Kontrolle und Transparenz in Bezug auf den individuellen Ressourcenverbrauch. Außerdem können Sie die lokalen Workloadanforderungen leicht auf die Cloud übertragen. Mit diesem Modell wird der Preis optimiert, und Sie können Compute-, Arbeitsspeicher- und Speicherressourcen entsprechend Ihren jeweiligen Workloadanforderungen auswählen.

Im vCore-basierten Kaufmodell hängen Ihre Kosten von der Auswahl und Verwendung der folgenden Elemente ab:

• Dienstebene
• Hardwarekonfiguration
• Computeressourcen (Anzahl von virtuellen Kernen und Arbeitsspeichermenge)
• Reservierter Datenbankspeicher
• Tatsächlicher Sicherungsspeicher

Das Kaufmodell für virtuelle Kerne (vCore) von Azure SQL Managed Instance bietet die folgenden Vorteile:

• Kontrolle über die Hardwarekonfiguration, um besser auf die Compute- und Arbeitsspeicheranforderungen der Workload reagieren zu können.
• Preisrabatte für Azure-Hybridvorteil und reservierte Instanzen (RI).
• Mehr Transparenz bei den Hardwaredetails für die Computeressourcen trägt zur besseren Planung von Migrationsvorgängen von lokalen Bereitstellungen bei.
• Höhere Granularität mit mehreren Computegrößen verfügbar.

Compute

SQL Managed Instance Compute bietet eine bestimmte Menge an Computeressourcen, die unabhängig von der Workloadaktivität ständig bereitgestellt werden. Die Abrechnung erfolgt dann zu einem Festpreis pro Stunde für die Menge an bereitgestellten Computeressourcen.

Da der Dienstebene „Unternehmenskritisch“ automatisch drei zusätzliche Replikate zugeordnet werden, ist der Preis ungefähr 2,7 Mal höher als für die Dienstebene „Universell“. Entsprechend spiegelt der höhere Speicherpreis pro GB für die Dienstebene „Unternehmenskritisch“ die höheren E/A-Grenzwerte und die geringere Latenz des lokalen SSD-Speichers wider.

Bei Instanzen der Dienstebene „Universell“ können Sie Compute- und Lizenzierungskosten sparen, indem Sie Ihre Instanz beenden, wenn diese nicht verwendet wird. Weitere Informationen finden Sie unter Beenden und Starten einer Instanz.

Daten- und Protokollspeicher

Die folgenden Faktoren wirken sich darauf aus, wie viel Speicherplatz für Daten- und Protokolldateien verwendet wird. Dies gilt für die Dienstebenen „Universell“ und „Unternehmenskritisch“.

• In der Dienstebene „Universell“ wird für tempdb lokaler SSD-Speicher verwendet, und diese Speicherkosten sind im V-Kern-Preis enthalten.
• In der Dienstebene „Unternehmenskritisch“ wird für tempdb lokaler SSD-Speicher für Daten- und Protokolldateien gemeinsam genutzt, und tempdb-Speicherkosten sind im V-Kern-Preis enthalten.
• Die maximale Speichergröße für eine Instanz von SQL Managed Instance muss als Vielfaches von 32 GB angegeben werden.

Zum Überwachen der insgesamt verbrauchten Instanzspeichergröße für SQL Managed Instance verwenden Sie die Metrikstorage_space_used_mb. Wenn Sie die aktuell zugeordnete und verwendete Speichergröße einzelner Daten- und Protokolldateien in einer Datenbank mit T-SQL überwachen möchten, verwenden Sie die Ansicht sys.database_files und die Funktion FILEPROPERTY(... , 'SpaceUsed').

Sicherungsspeicher

Der Speicher für Datenbanksicherungen wird zugeordnet, um die Funktionen von SQL Managed Instance zu unterstützen. Dieser Speicher ist vom Daten- und Protokolldateispeicher getrennt und wird separat abgerechnet.

• Zeitpunktwiederherstellung (PITR): Der Speicherverbrauch richtet sich nach der Änderungsrate der Datenbank und nach dem für Sicherungen konfigurierten Aufbewahrungszeitraum. Sie können für jede Datenbank einen separaten Aufbewahrungszeitraum zwischen 1 und 35 Tagen für SQL Managed Instance konfigurieren. Eine Sicherungsspeichermenge, die der konfigurierten maximalen Datengröße entspricht, wird ohne Zusatzkosten bereitgestellt.
• Langzeitaufbewahrung (LTR): Sie haben die Möglichkeit, die Langzeitaufbewahrung von vollständigen Sicherungen für bis zu 10 Jahre zu konfigurieren. Wie viel Speicher für LTR-Sicherungen verwendet wird, richtet sich nach der ausgewählten Konfiguration.

Dienstebenen

Die Dienstebene definiert ganz allgemein die Speicherarchitektur, die Speicherplatz- und E/A-Grenzwerte sowie Optionen für die Geschäftskontinuität im Zusammenhang mit der Verfügbarkeit und Notfallwiederherstellung.

Azure SQL Managed Instance umfasst zwei Dienstebenen:

• Universell: Sie können sich für das Upgrade auf die Dienstebene Universell der nächsten Generation (Vorschau) entscheiden.
• Unternehmenskritisch:

Einen detaillierten Vergleich zwischen den Dienstebenen finden Sie unter Ressourceneinschränkungen, aber die folgende Tabelle enthält einen kurzen Überblick:

Universell

Das Architekturmodell für die Dienstebene „Universell“ basiert auf der Trennung von Compute- und Speicherebene. Dieses Architekturmodell beruht auf der Hochverfügbarkeit und Zuverlässigkeit von Azure Blob Storage mit transparenter Replikation von Datenbankdateien und garantiert, dass bei einem Ausfall der zugrunde liegenden Infrastruktur keine Datenverluste auftreten.

In der folgenden Abbildung sind vier Knoten im Architekturmodell des Typs „Standard“ mit getrennter Compute- und Speicherebene dargestellt.

Das Architekturmodell für die Dienstebene „Universell“ umfasst zwei Ebenen:

• Eine zustandslose Computeebene, auf der der Prozess sqlservr.exe ausgeführt wird und die nur temporäre und zwischengespeicherte Daten (z. B. Plancache, Pufferpool, Spaltenspeicherpool) enthält. Dieser zustandslose Knoten wird von der Azure Service Fabric-Plattform gesteuert, die Prozesse initialisiert, die Integrität des Knotens überprüft und bei Bedarf ein Failover an einen anderen Ort durchführt.
• Eine zustandsbehaftete Datenebene mit Datenbankdateien (MDF- und LDF-Dateien), die in Azure Blob Storage gespeichert sind. Azure Blob Storage garantiert die Vermeidung von Datenverlusten jeglicher Datensätze, die in Datenbankdateien platziert werden. Azure Storage verfügt über integrierte Datenverfügbarkeit und -redundanz, die sicherstellen, dass jeder Eintrag in einer Protokolldatei und jede Seite in einer Datendatei erhalten bleibt, auch wenn der Prozess abstürzt.

Bei einem Upgrade der Datenbank-Engine oder des Betriebssystems, einem Ausfall eines Teils der zugrunde liegenden Infrastruktur oder wenn im sqlservr.exe-Prozess ein schwerwiegendes Problem erkannt wird, verschiebt Azure Service Fabric den zustandslosen Prozess auf einen anderen zustandslosen Serverknoten. Es sind mehrere Reserveknoten vorhanden, auf denen im Fall eines Failovers des primären Knotens ein neuer Computedienst ausgeführt werden kann, um die Failoverzeit zu minimieren. Daten auf der Azure Storage-Ebene sind nicht betroffen, und Daten- und Protokolldateien werden an den neu initialisierten Prozess angefügt. Dieser Prozess garantiert standardmäßig eine Verfügbarkeit von 99,99 %. Aufgrund der Übergangszeit und der Tatsache, dass der neue Knoten mit einem kalten Cache startet, kann es zu Leistungseinbußen bei großen Workloads kommen, die aktuell ausgeführt werden.

Wann sollte diese Dienstebene gewählt werden?

Die Dienstebene „Universell“ ist die Standarddienstebene in Azure SQL Managed Instance, die für die meisten generischen Workloads konzipiert ist. Wenn Sie eine vollständig verwaltete Datenbank-Engine mit einer Standard-SLA und Speicherlatenz zwischen 5 und 10 ms benötigen, ist die Ebene „Universell“ die für Sie geeignete Option.

Universell der nächsten Generation

Die Dienstebene Universell der nächsten Generation ist ein Architekturupgrade der vorhandenen Dienstebene Universell mit den folgenden zentralen Merkmalen:

• Ausgelegt auf Unternehmen mit höheren Leistungsanforderungen mit den gleichen Soll-Kosten wie die Dienstebene Universell
• Erhebliche Steigerung von Leistung, Skalierbarkeit und Ressourcenflexibilität gegenüber der Dienstebene Universell
• Verwendet verwaltete Datenträger anstelle von Seitenblobs, wodurch sich Speicherleistungsmetriken gewaltig verbessern
• 3 kostenlose IOPS für jedes GB reservierten Speicher
• Unterstützung von bis zu 500 Datenbanken pro Instanz und einer maximalen Speichergröße von 32 TB

Da es sich bei der Dienstebene Universell der nächsten Generation um ein Upgrade der vorhandenen Dienstebene Universell handelt, wird in Ihrer Abrechnung unabhängig von der tatsächlich für Ihre Instanz verwendeten Dienstebene die Dienstebene Universell ausgewiesen.

Architekturmodell

Die Dienstebene Universell der nächsten Generation ist ein Upgrade der vorhandenen Dienstebene Universell mit einer aktualisierten Remotespeicherebene zum Speichern von Instanzdaten und Protokolldateien auf verwalteten Datenträgern statt auf Seitenblobs. Dies bedeutet, dass das Upgrade auf die Dienstebene Universell der nächsten Generation eine höhere Geschwindigkeit bei Speicherlatenz, IOPS und Durchsatz bietet als die vorhandene Dienstebene Universell sowie höhere Speichergrenzwerte, Anzahl virtueller Kerne und maximale Anzahl von Datenbanken. Da die Leistungskontingente von der gesamten Instanz gemeinsam genutzt werden, müssen Sie zudem nicht mehr die Größe einzelner Dateien ändern, um die Leistung zu verbessern. Die Soll-Kosten der Dienstebene Universell der nächsten Generation sind gleich wie bei der Dienstebene Universell, Sie können jedoch über Schieberegler ihre E/A-Leistung steigern, was dann separat in Rechnung gestellt wird.

Mit drei kostenlosen IOPS für jedes GB reservierten Speicher trägt die Dienstebene Universell der nächsten Generation zur Senkung der Kosten bei. Im Preis des Speichers sind die minimalen IOPS enthalten. Wenn Sie das Minimum übersteigen, wird Ihnen Folgendes berechnet: 1 IOPS = Speicherpreis (nach Region) dividiert durch drei.

Zum Beispiel:

• Wenn 1 GB Speicher 0,115 kostet, dann 1 IOPS = 0,115/3 = 0,038 pro IOPS.
• Eine 1.024-GB-Instanz erhält 3072 IOPS kostenlos. Gegen Zusatzkosten können Sie Ihre IOPS bis zum VM-Grenzwert erhöhen.

Wann sollte diese Dienstebene gewählt werden?

Wählen Sie diese Dienstebene, wenn Ihr Unternehmen budgetorientiert ist, die Leistungsmetriken und Grenzwerte der Dienstebene Universell aber nicht ausreichend sind.

Die wichtigsten Gründe, warum Sie sich statt der Dienstebene Universell für die Dienstebene Universell der nächsten Generation entscheiden sollten, sind:

• Bessere Leistung für die gleichen Soll-Kosten
• Verbesserung bei Latenz, Durchsatz und IOPS
• Größere Speicherkapazität
• Mehr Flexibilität für Ihr Compute
• Sie brauchen mehr als 100 Datenbanken für eine einzelne Instanz.
• Sie brauchen mehr als 16 TB reservierten Speicher.

Unternehmenskritisch

Das Dienstebenenmodell des Typs „Unternehmenskritisch“ basiert auf einem Cluster von Datenbank-Engine-Prozessen. Dieses Architekturmodell beruht darauf, dass immer ein Quorum verfügbarer Datenbank-Engine-Knoten vorhanden ist, und selbst bei Wartungsarbeiten wird die Leistung Ihrer Workloads nur minimal beeinträchtigt. In Azure werden das zugrunde liegende Betriebssystem, Treiber und die SQL Server-Datenbank-Engine transparent mit minimaler Ausfallzeit für Endbenutzer*innen aktualisiert und gepatcht.

Im unternehmenskritischen Modell sind die Berechnung und der Speicher für jeden Knoten integriert. Hochverfügbarkeit wird durch Replikation von Daten zwischen Datenbankmodulprozessen auf jedem Knoten eines Vier-Knoten-Clusters erreicht, wobei jeder Knoten lokal angefügte SSD-Datenträger als Datenspeicher verwendet.

Der SQL Server-Datenbank-Engine-Prozess sowie die zugrunde liegenden MDF- und LDF-Dateien werden mit lokal angefügtem SSD-Speicher auf demselben Knoten platziert und bieten eine geringe Latenz für die Workload. Hochverfügbarkeit wird anhand einer ähnlichen Technologie wie AlwaysOn-Verfügbarkeitsgruppen in SQL Server implementiert.

Jede Instanz ist ein Cluster von Datenbank-Engine-Knoten, die Kopien aller Datenbanken auf einer Instanz enthalten, wobei eine primäre Datenbank für Kundenworkloads zugänglich ist, und drei sekundäre Datenbanken Kopien der Daten enthalten und für das Failover bereit sind. Der primäre Knoten überträgt die Änderungen kontinuierlich an die sekundären Knoten, um sicherzustellen, dass die Daten in den sekundären Replikaten verfügbar sind, wenn der primäre Knoten aus bestimmten Gründen ausfällt.

Ein Failover wird von der SQL Server-Datenbank-Engine verarbeitet: Ein sekundäres Replikat wird zum primären Knoten, und ein neues sekundäres Replikat wird erstellt, um sicherzustellen, dass ausreichend Knoten im Cluster vorhanden sind. Die Workload wird automatisch zum neuen primären Knoten umgeleitet.

Darüber hinaus umfasst der Cluster des Typs „Unternehmenskritisch“ eine integrierte Funktion Horizontale Leseskalierung, die ein gebührenfreies, integriertes und schreibgeschütztes Replikat bereitstellt, das zum Ausführen von schreibgeschützten Abfragen (z. B. Berichten) verwendet werden kann, die die Leistung des primären Replikats nicht beeinträchtigen.

Wann sollte diese Dienstebene gewählt werden?

Die Dienstebene „Unternehmenskritisch“ ist für Anwendungen gedacht, die Antworten mit geringer Latenz vom zugrunde liegenden SSD-Speicher (durchschnittlich 1 bis 2 ms), schnellere Wiederherstellung bei einem Fehler der zugrunde liegenden Infrastruktur oder das Auslagern von Berichten, Analysen und schreibgeschützten Abfragen an das kostenlose lesbare sekundäre Replikat der primären Datenbank erfordern.

Die wichtigsten Gründe dafür, dass Sie die Dienstebene „Unternehmenskritisch“ anstelle der Ebene „Universell“ wählen sollten, sind folgende:

• Niedrige E/A-Latenzanforderungen: Für Workloads, die eine schnelle Reaktion der Speicherebene (durchschnittlich 1 bis 2 Millisekunden) erfordern, sollte die Ebene „Unternehmenskritisch“ verwendet werden.
• Workload mit Berichterstellungs- und Analyseabfragen, die zum kostenlosen sekundären schreibgeschützten Replikat umgeleitet werden können.
• Höhere Resilienz und schnellere Wiederherstellung nach Fehlern. Bei einem Systemfehler werden die Datenbanken auf der primären Instanz offline geschaltet, und eines der sekundären Replikate wird sofort zur neuen primären Instanz mit Lese-/Schreibzugriff und steht für die Verarbeitung von Abfragen bereit. Es ist nicht erforderlich, dass die Datenbank-Engine Transaktionen in der Protokolldatei analysiert und wiederholt oder Daten in Arbeitsspeicherpuffer lädt.
• Erweiterter Schutz vor Datenbeschädigung. Da die Dienstebene „Unternehmenskritisch“ im Hintergrund Datenbankreplikate verwendet, nutzt der Dienst die automatische Seitenreparatur, die mit Spiegelung und Verfügbarkeitsgruppen verfügbar ist, um Datenbeschädigungen zu minimieren. Falls ein Replikat eine Seite aufgrund eines Datenintegritätsproblems nicht lesen kann, wird eine neue Kopie der Seite von einem anderen Replikat abgerufen, die die nicht lesbare Seite ohne Datenverluste oder Ausfallzeiten für die Kundschaft ersetzt. Diese Funktionalität ist in der Dienstebene „Universell“ verfügbar, wenn die verwaltete Instanz über ein georedundantes Replikat verfügt.
• Höhere Verfügbarkeit: Die Dienstebene „Unternehmenskritisch“ bietet in der Konfiguration mit mehreren Verfügbarkeitszonen Resilienz gegenüber Zonenausfällen und eine SLA mit höherer Verfügbarkeit.
• Schnelle geografische Wiederherstellung – Wenn eine Failovergruppe konfiguriert ist, hat die geschäftskritische Schicht ein garantiertes Recovery Point Objective (RPO) von 5 Sekunden und ein Recovery Time Objective (RTO) von 30 Sekunden für 100 % der bereitgestellten Stunden.

Wenn Sie die Dienstebene in Vorlagen oder Skripts angeben, wird die Ebene mithilfe ihres Namens bereitgestellt. Es gilt die folgende Tabelle:

Hardwarekonfigurationen

Die Optionen für die Hardwarekonfiguration im vCore-Modell umfassen die Standard-Serie (Gen5), die Premium-Serie und die arbeitsspeicheroptimierte Premium-Serie. Die Hardwarekonfiguration definiert in der Regel Compute- und Arbeitsspeichegrenzwerte und andere Merkmale, die sich auf die Workloadleistung auswirken.

Weitere Informationen zu den Besonderheiten und Einschränkungen der Hardwarekonfiguration finden Sie unter Merkmale der Hardwarekonfiguration.

In der dynamischen Verwaltungssicht sys.dm_user_db_resource_governance wird die Hardwaregenerierung für Instanzen mit Intel SP-8160-Prozessoren (Skylake) als „Gen6“ und die für Instanzen mit Intel 8272CL-Prozessoren (Cascade Lake) als „Gen7“ angezeigt. Die CPUs vom Typ Intel® 8370C (Ice Lake), die von den Hardwaregenerationen der Premium-Serie und der arbeitsspeicheroptimierten Premium-Serie verwendet werden, werden als „Gen8“ angezeigt. Ressourcenlimits sind für alle Instanzen der Standard-Serie (Gen5) identisch – unabhängig vom Prozessortyp (Broadwell, Skylake oder Cascade Lake).

Auswählen einer Hardwarekonfiguration

Sie können die Hardwarekonfiguration zum Zeitpunkt der Instanzerstellung auswählen oder die Hardware einer vorhandenen Instanz ändern.

So wählen Sie eine Hardwarekonfiguration beim Erstellen einer Instanz von SQL Managed Instance aus

Ausführliche Informationen finden Sie unter Erstellen einer Instanz von SQL Managed Instance.

Wählen Sie auf der Registerkarte Grundlagen im Abschnitt Compute und Speicher den Link Datenbank konfigurieren aus, und wählen Sie dann die gewünschte Hardware aus:

So ändern Sie die Hardware einer vorhandenen Instanz von SQL Managed Instance

Set-AzSqlInstance -Name "managedinstance1" -ResourceGroupName "ResourceGroup01" -ComputeGeneration Gen5

az sql mi update -g mygroup -n myinstance --family Gen5

Bei der Angabe von Hardwareparametern in Vorlagen oder Skripts wird die Hardware mithilfe ihres Namens bereitgestellt. Es gilt die folgende Tabelle:

SKU-Namen

Hardwareverfügbarkeit

Standard-Serie (Gen5) und Premium-Serie

Hardware der Standard- (Gen5) und Premium-Serie ist weltweit in allen öffentlichen Regionen verfügbar.

Hardware der arbeitsspeicheroptimierten Premium-Serie befindet sich in der Vorschauphase, und ihre regionale Verfügbarkeit ist begrenzt. Weitere Informationen finden Sie unter Ressourceneinschränkungen für Azure SQL Managed Instance.

Zugehöriger Inhalt

• Erstellen einer Instanz von SQL Managed Instance mithilfe des Azure-Portals
• Preisseite für Azure SQL Managed Instance Einzelinstanz
• Preisseite für Azure SQL Managed Instance-Pools
• Ressourcenlimits des auf virtuellen Kernen basierenden Modells für Azure SQL Managed Instance