Konfigurieren eines lizenzfreien Standbyreplikats für Azure SQL Managed Instance
Gilt für: 
Azure SQL Managed Instance
Dieser Artikel beschreibt, wie Sie Lizenzkosten sparen können, indem Sie Ihre sekundäre verwaltete Instanz als Standby-Instanz bestimmen, wenn Sie Azure SQL Managed Instance verwenden.
Hinweis
Der Failovervorteil gilt nur, wenn Sie eine sekundäre Instanz als Standbymodus innerhalb einer Automatisch-Failovergruppe konfigurieren. Verwenden Sie für Hybridumgebungen zwischen SQL Server und SQL Managed Instance stattdessen den Hybrid-Failovervorteil.
Übersicht
Wenn Sie eine sekundäre Bereitstellung von Azure SQL Managed Instance als Standbyinstanz für die Notfallwiederherstellung verwenden und die sekundäre Instanz keine Leseworkloads enthält und keine Anwendungen mit ihr verbunden sind, können Sie Lizenzierungskosten sparen, indem Sie das Replikat als Standbyinstanz festlegen.
Wenn eine sekundäre Instanz als Standby-Instanz festgelegt ist, stellt Microsoft Ihnen so viele virtuelle Kerne zur Verfügung wie für die primäre Instanz lizenziert sind, und zwar ohne zusätzliche Kosten. Dies erfolgt im Rahmen des von den Produktlizenzbedingungen bereitgestellten Vorteils für Failoverrechte. Ihnen werden trotzdem die Compute- und Speicherkosten in Rechnung gestellt, die von der sekundären Instanz verwendet werden.
Failovergruppen für SQL Managed Instance-Bereitstellungen unterstützen nur ein Replikat. Das Replikat muss entweder ein lesbares Replikat sein oder als Standbyreplikat festgelegt werden.
Kostenvorteil
Wenn Sie ein Replikat einer verwalteten Instanz als Standby-Instanz festlegen, berechnet Microsoft Ihnen keine SQL Server-Lizenzierungsgebühren für die virtuellen Kerne, die das Standby-Replikat verwendet. Da für die Instanz jedoch die gesamte Stunde in Rechnung gestellt wird, werden Ihnen möglicherweise weiterhin Lizenzierungskosten für die gesamte Stunde berechnet, wenn die Zustandsänderung in der Mitte der Stunde erfolgt.
Der Vorteil hat unterschiedliche Auswirkungen auf die Kundschaft, je nachdem ob sie das Modell mit nutzungsbasierter Bezahlung verwendet oder den Azure-Hybridvorteil. Für Kundschaft mit nutzungsbasierter Bezahlung wird ein Rabatt für die virtuellen Kerne auf der Rechnung ausgewiesen. Für Kundschaft, die den Azure-Hybridvorteil für das Standbyreplikat verwendet, wird die Anzahl der virtuellen Kerne, die das sekundäre Replikat verwendet, im Lizenzierungspool rückerstattet.
Wenn Sie beispielsweise als Kund*in mit nutzungsbasierter Bezahlung der sekundären Instanz 16 virtuelle Kerne zugewiesen haben, finden Sie auf Ihrer Rechnung einen Rabatt für 16 virtuelle Kerne, wenn Sie Ihre sekundäre Instanz nur für das Standby-Replikat festlegen.
Wenn Sie in einem anderen Beispiel über 16 Lizenzen mit Azure-Hybridvorteil verfügen und zwei verwaltete Instanzen mit jeweils 8 virtuellen Kernen in einer Failovergruppe bereitstellen, werden nach dem Festlegen der sekundären Instanz als Standbyinstanz 8 virtuelle Kerne an Ihren Lizenzpool rückerstattet, die Sie für andere Azure SQL-Bereitstellungen verwenden können.
Funktionen
In der folgenden Tabelle werden die Funktionen einer sekundären verwalteten Standbyinstanz beschrieben:
| Funktionalität | BESCHREIBUNG |
|---|---|
| Eingeschränkte Leseworkloads | Nachdem Sie Ihre Instanz als Standbyinstanz festgelegt haben, können Sie nur eine begrenzte Anzahl von Leseworkloads auf der sekundären Instanz ausführen, z. B. dynamische Verwaltungssichten (Dynamic Management Views, DMVs), Sicherungen und DBCC-Abfragen (Database Console Commands, Datenbankkonsolenbefehle). |
| Geplantes Failover | Vom Standbyreplikat werden alle geplanten Failoverszenarien unterstützt, einschließlich Wiederherstellungsübungen, das Verschieben von Datenbanken in andere Regionen und das Zurückgeben von Datenbanken an die primäre Instanz. Wenn das sekundäre Failover zum primären Replikat gemacht wird, kann es sowohl Lese- als auch Schreibabfragen verarbeiten. Das neue sekundäre Replikat (das ursprüngliche primäre Replikat) wird zum Standbyreplikat und sollte nicht mehr für Leseworkloads verwendet werden. |
| Ungeplantes Failover | Während eines ungeplanten Failovers kann das sekundäre Replikat, sobald es die primäre Rolle einnimmt, sowohl Lese- als auch Schreibabfragen verarbeiten. Nachdem der Ausfall behoben wurde und die ursprüngliche primäre Instanz wieder verbunden ist, wird diese zum neuen sekundären Standbyreplikat und sollte nicht mehr für Leseworkloads verwendet werden. |
| Sichern und Wiederherstellen | Das Sicherungs- und Wiederherstellungsverhalten von einem Standbyreplikat und einer lesbaren sekundären verwalteten Instanz ist identisch. |
| Überwachung | Alle Überwachungsvorgänge, die von einem lesbaren sekundären Replikat unterstützt werden, werden auch vom Standbyreplikat unterstützt. |
| RPO und RTO | Das Standbyreplikat stellt das gleiche RPO (Recovery Point Object) und RTO (Recovery Time Objective) auch als lesbares sekundäres Replikat bereit. |
| Entfernen einer Failovergruppe | Wenn die Failovergruppe über eine Methode wie das Cmdlet Remove-AzSqlDatabaseInstanceFailoverGroup entfernt wird, wird das Standbyreplikat zu einer eigenständigen Instanz mit Lese-/Schreibzugriff. Das Lizenzierungsmodell ist dann wieder so, wie es vor der Festlegung als Standbyreplikat war (entweder Azure-Hybridvorteil oder nutzungsbasierte Bezahlung). |
Die Standby-Instanz darf nur für die Notfallwiederherstellung verwendet werden. Es dürfen keine Produktionsanwendungen mit dem Replikat verbunden werden. Im Folgenden werden die einzigen Aktivitäten aufgeführt, die bei Standbyreplikaten zulässig sind:
- Ausführen von Sicherungen
- Ausführen von Wartungsvorgängen, z. B. checkDB
- Verbinden von Überwachungsanwendungen
- Ausführen von Übungen zur Notfallwiederherstellung
Konfigurieren eines Standbyreplikats
Sie haben zwei Möglichkeiten, Ihre sekundäre verwaltete Instanz als Standbyreplikat festzulegen:
- Legen Sie es als Standbyreplikat fest, wenn Sie Ihre Failovergruppe erstellen.
- Aktualisieren Sie die Konfiguration einer vorhandenen Failovergruppe.
Neue Failovergruppe
Sie können Ihre sekundäre Instanz als Standbyreplikat festlegen, wenn Sie über das Azure-Portal, Azure PowerShell und die Azure CLI. eine neue Failovergruppe erstellen.
Wenn Sie eine neue Failover-Gruppe im Azure-Portal erstellen, wählen Sie unter Failoverrechte die Option Ein aus. Aktivieren Sie das Kontrollkästchen neben Ich bestätige, dass ich die sekundäre Instanz als Standbyreplikat verwenden werde. Wählen Sie Erstellen aus, um die Failovergruppe zu erstellen.
Weitere Informationen finden Sie unter Konfigurieren einer Failover-Gruppe.
Vorhandene Failovergruppe
Sie können das Azure-Portal, Azure PowerShell und die Azure-CLI verwenden, um die Failover-Rechte für eine bestehende Failover-Gruppe zu aktualisieren.
Um die Failoverrechte für eine vorhandene Failovergruppe über das Azure-Portal zu aktualisieren, befolgen Sie diese Schritte:
Öffnen Sie im Azure-Portal Ihre sekundäre SQL Managed Instance-Ressource.
Wählen Sie im Menü auf der linken Seite unter Datenverwaltung die Option Failovergruppen aus.
Wählen Sie auf der Befehlsleiste Konfigurationen bearbeiten aus.
Wählen Sie unter Konfigurationen bearbeiten für Ihre Failovergruppe bearbeiten unter Failoverrechte die Option Ein aus. Aktivieren Sie das Kontrollkästchen Ich bestätige, dass ich die sekundäre Instanz als Standbyreplikat verwenden werde.
Wählen Sie Übernehmen aus, um die neuen Einstellungen zu speichern und den Konfigurationsbereich zu schließen.
Sie können Failoverrechte auch direkt auf der Seite Compute + Speicher für Ihre sekundäre verwaltete Instanz aktivieren. Weitere Informationen finden Sie unter Anzeigen von Lizenzierungsrechten.
Wichtig
Wenn Sie Hybrid-Failoverechte und nicht Failoverrechte sehen, befinden Sie sich wahrscheinlich auf der primären verwalteten Instanz. Wechseln Sie zu Ihrer sekundären verwalteten Instanz, um Failoverrechte ordnungsgemäß zu aktivieren. Durch die Aktivierung der Hybrid-Failoverrechte auf der primären Instanz sparen Sie keine Lizenzkosten für die sekundäre Instanz, wenn Sie mit automatischen Failovergruppen arbeiten.
Anzeigen von Lizenzierungsrechten
Sie können die Lizenzierungsrechte für eine vorhandene Failover-Gruppe über das Azure-Portal, Azure PowerShell oder die Azure CLI überprüfen.
Sie können die Lizenzierung für Ihre sekundäre verwaltete Instanz an zwei Stellen im Azure-Portal überprüfen:
- Failovergruppen für Ihre primäre verwaltete Instanz.
- Compute + Speicher für Ihre sekundäre verwaltete Instanz.
Stellen Sie in Failovergruppen sicher, dass der Status der Failoverrechte auf EIN festgelegt ist und dass das Lizenzmodell für die sekundäre Instanz Failoverrechte sind derzeit aktiviert lautet.
Das Standardlizenzmodell gibt das Lizenzierungsmodell an, auf das die Instanz zurückgesetzt wird, wenn für die Failovergruppe ein Failover ausgeführt wird und die aktuelle sekundäre Instanz zur neuen primären Instanz wird. Abhängig vom Standardlizenzmodell können bei einem Failover Gebühren anfallen.
Vergewissern Sie sich unter Compute + Speicher für Ihre sekundäre verwaltete Instanz, dass die Lizenz für Failoverrechte aktiviert ist. Zeigen Sie unter Kostenzusammenfassung den Failoverrabatt an, den Sie derzeit für diese Instanz erhalten.
Wenn die Failoverrechte nicht aktiviert sind, Sie aber für den Vorteil qualifiziert sind, wird unter Übersicht für eine der Instanzen auch die folgende Empfehlung angezeigt. Um den Vorteil zu aktivieren, wählen Sie die Empfehlung aus, um zu Konfigurationen bearbeiten zu wechseln.
Nächste Schritte
- Ein ausführliches Tutorial finden Sie unter Hinzufügen einer Instanz von SQL Managed Instance zu einer Failovergruppe.
- Ein Beispielskript finden Sie unter Erstellen einer Failovergruppe in SQL Managed Instance mithilfe von PowerShell.
- Eine Übersicht über Geschäftskontinuität und Szenarien finden Sie unter Geschäftskontinuität mit Azure SQL-Datenbank und Azure SQL Managed Instance.
- Informationen über automatisierte Sicherungen finden Sie unter Automatisierte SQL-Datenbanksicherungen.
- Informationen zum Verwenden automatisierter Sicherungen für die Wiederherstellung finden Sie unter Wiederherstellen einer Datenbank aus vom Dienst initiierten Sicherungen.