Erläutern von Hochverfügbarkeits- und Notfallwiederherstellungsoptionen
Über die integrierte Hochverfügbarkeit hinaus bietet die Azure-Plattform zwei Optionen zum Bereitstellen höherer Verfügbarkeit für VMs und einige PaaS-Workloads. Verfügbarkeitszonen und Verfügbarkeitsgruppen schützen Ihre Workloads vor geplanten Wartungsaktivitäten und potenziellen Hardwarefehlern.
Optionen für Hochverfügbarkeit
Die meisten SQL Server-Hochverfügbarkeitslösungen sind auf virtuellen Azure-Computern (VMs) verfügbar. In einer reinen Azure-Lösung wird das gesamte HADR-System in Azure ausgeführt. In einer Hybridkonfiguration wird ein Teil der Lösung in Azure und der andere Teil lokal in Ihrer Organisation ausgeführt. Die Flexibilität der Azure-Umgebung können Sie teilweise oder vollständig in Azure verschieben, um Budget- und HADR-Anforderungen der SQL Server-Datenbanksysteme zu erfüllen.
Verfügbarkeitszonen
Verfügbarkeitszonen sind eindeutige physische Standorte in einer Region. Jede Zone besteht aus mindestens einem Rechenzentrum, dessen Stromversorgung, Kühlung und Netzwerkbetrieb unabhängig funktionieren. In Azure-Regionen, die Verfügbarkeitszonen unterstützen, können Sie festlegen, in welcher Zone sich die VM befinden soll, wenn Sie sich bei der VM-Erstellung für die Verwendung von Verfügbarkeitszonen entscheiden. In jeder unterstützten Azure-Region gibt es drei Verfügbarkeitszonen. Verfügbarkeitszonen bieten Hochverfügbarkeit für Rechenzentrumsfehler, wenn Sie mehrere VMs in verschiedenen Zonen bereitstellen. Außerdem bieten sie Microsoft eine Möglichkeit, Wartungen (mithilfe einer Gruppierung, die als Updatedomäne bezeichnet wird) in jeder Region durchzuführen, indem immer nur eine Zone aktualisiert wird. Sie können Ihr VM-Ökosystem auf drei Zonen in der Region verteilen. Durch die Verwendung von Verfügbarkeitszonen zusammen mit Ihren Azure-VMs steigt Ihre Uptime auf vier Neunen (99,99 %), was einer maximalen Downtime von 52,60 Minuten pro Jahr entspricht. Unter docs.microsoft.com erfahren Sie, welche Azure-Regionen Verfügbarkeitszonen unterstützen. Wenn Verfügbarkeitszonen in Ihrer Region verfügbar sind und Ihre Anwendung minimale zonenübergreifende Latenz unterstützt, bieten Verfügbarkeitszonen das höchste Maß an Verfügbarkeit für Ihre Anwendung.
In der obigen Abbildung sehen Sie die Verfügbarkeitszonenkonfiguration. Wenn Sie eine VM in einer Region mit einer Verfügbarkeitszone bereitstellen, wird Ihnen die Option zur Bereitstellung in den Zonen 1, 2 und 3 angezeigt. Diese Zonen sind logische Darstellungen der physischen Rechenzentren. Eine Bereitstellung in Zone 1 in einem Abonnement bedeutet daher nicht, dass Zone 1 in einem anderen Abonnement dasselbe Rechenzentrum darstellt.
Verfügbarkeitsgruppen
Verfügbarkeitsgruppen ähneln Verfügbarkeitszonen, mit dem Unterschied, dass sie Workloads auf Server und Racks in einem Rechenzentrum verteilen, anstatt auf Rechenzentren in einer Region. Da fast alle Workloads in Azure virtuell sind, können Sie Verfügbarkeitsgruppen verwenden, um zu garantieren, dass die zwei VMs, die die Mitglieder Ihrer Always On-Verfügbarkeitsgruppe enthalten, nicht auf demselben physischen Host ausgeführt werden. Verfügbarkeitsgruppen können eine Verfügbarkeit von bis zu 99,95 % bieten und sollten verwendet werden, wenn Verfügbarkeitszonen in einer Region nicht verfügbar sind oder wenn eine Anwendung keine zoneninterne Latenz tolerieren kann.
Always On-Verfügbarkeitsgruppen
Always On-Verfügbarkeitsgruppen können mit zwei oder mehr (maximal neun) SQL Server-Instanzen implementiert werden, die auf Azure-VMs oder einem lokalen Rechenzentrum und in Azure ausgeführt werden. In einer Verfügbarkeitsgruppe werden Datenbanktransaktionen im primären Replikat committet, die dann synchron oder asynchron an alle sekundäre Replikate gesendet werden. Die physische Entfernung zwischen den Servern (d. h., ob sie sich in derselben Azure-Region befinden oder nicht) gibt vor, welchen Verfügbarkeitsmodus Sie verwenden sollten. Im Allgemeinen wird der asynchrone Verfügbarkeitsmodus empfohlen, wenn die Workload die niedrigste mögliche Latenz oder eine geografische Trennung der sekundären Replikate erfordert. Wenn die Replikate sich in derselben Azure-Region befinden und die Anwendungen einen gewissen Grad an Latenz bewältigen können, sollte der Modus für synchrone Commits in Betracht gezogen werden. Der synchrone Modus hilft dabei, sicherzustellen, dass jede Transaktion in einem oder mehreren Replikaten committet wird, bevor die Anwendung fortgesetzt werden kann. Always On-Verfügbarkeitsgruppen bieten sowohl Hochverfügbarkeit als auch Notfallwiederherstellung, da eine einzelne Verfügbarkeitsgruppe sowohl synchrone als auch asynchrone Verfügbarkeitsmodi unterstützen kann. Die Failovereinheit für eine Verfügbarkeitsgruppe ist eine Gruppe von Datenbanken, nicht die gesamte Instanz.
Always On-Verfügbarkeitsgruppen können auch für die Notfallwiederherstellung verwendet werden. Sie können bis zu neun Replikate einer Datenbank in mehreren Azure-Regionen implementieren und diese Architektur mithilfe verteilter Verfügbarkeitsgruppen noch weiter ausweiten. Verfügbarkeitsgruppen stellen sicher, dass sich eine brauchbare Kopie Ihrer Datenbank(en) an einem anderen Standort außerhalb der primären Region befindet. Auf diese Weise können Sie sicherstellen, dass Ihr Datenökosystem vor Naturkatastrophen und menschlichen Fehlern geschützt ist.
In der obigen Abbildung wird ein logisches Diagramm einer Always On-Verfügbarkeitsgruppe gezeigt, die auf einem Windows Server-Failovercluster ausgeführt wird. Es gibt ein primäres und vier sekundäre Replikate. In diesem Szenario können alle Replikate synchron sein, aber es kann auch eine Kombination aus synchronen und asynchronen Replikaten vorliegen. Beachten Sie, dass es sich bei der Failovereinheit um die Gruppe von Datenbanken handelt, nicht um die Instanz. Eine Failoverclusterinstanz bietet zwar Hochverfügbarkeit auf Instanzebene, allerdings bietet sie keine Notfallwiederherstellung.
SQL Server-Failoverclusterinstanzen
Wenn Sie die gesamte Instanz schützen müssen, können Sie eine SQL Server-Failoverclusterinstanz verwenden, die Hochverfügbarkeit für eine gesamte Instanz in einer einzelnen Region bereitstellt. Ohne Kombination mit einem anderen Feature wie Verfügbarkeitsgruppen oder Protokollversand stellt eine Failoverclusterinstanz keine Notfallwiederherstellung bereit. Für Failoverclusterinstanzen ist außerdem freigegebener Speicher erforderlich, der mithilfe von freigegebenem Dateispeicher oder mit direkten Speicherplätzen auf Windows Server in Azure bereitgestellt werden kann.
Für neuere Bereitstellungen von Azure-Workloads stellen Verfügbarkeitsgruppen die bevorzugte Lösung dar, da die erforderlichen Failoverclusterinstanzen des freigegebenen Speichers zu erhöhter Komplexität bei der Bereitstellung führen. Für Migrationen von lokalen Lösungen kann eine Failoverclusterinstanz jedoch aufgrund der Anwendungsunterstützung erforderlich sein.
Notfallwiederherstellungsoptionen
Zwar unterstützt die Azure-Plattform standardmäßig eine Uptime von 99,9 %, jedoch können dennoch Notfälle auftreten, die sich auf die Uptime der Anwendung auswirken. Es ist wichtig, dass Sie über einen angemessenen Notfallwiederherstellungsplan verfügen, wenn Sie eine Art von Migration durchführen. Azure bietet mehrere Methoden, mit denen Sie sicherstellen können, dass Ihre SQL Server-Instanz auf einer VM bei einem Notfall geschützt ist. Dieser Schutz besteht aus zwei Komponenten. Erstens gibt es Azure-Plattformoptionen wie georeplizierten Speicher für Sicherungen und Azure Site Recovery, dabei handelt es sich um eine umfassende Notfallwiederherstellungslösung für alle Ihrer Workloads. Zweitens gibt es spezifische Angebote für SQL Server wie Verfügbarkeitsgruppen und Sicherungen.
Native SQL Server-Sicherungen
Sicherungen gelten als Kernthematik eines jeden Datenbankadministrators, und das ist bei der Arbeit mit einer Cloudlösung nicht anders. Mit SQL Server auf einer Azure-VM verfügen Sie über präzise Kontrolle darüber, wann Sicherungen durchgeführt werden und wo diese gespeichert werden. Sie können SQL-Agent-Aufträge verwenden, um die Sicherung direkt über eine URL durchzuführen, die mit Azure Blob Storage verknüpft ist. Azure bietet die Möglichkeit, georedundanten Speicher (GRS) oder georedundanten Speicher mit Lesezugriff (RA-GRS) zu verwenden, um sicherzustellen, dass Ihre Sicherungsdateien in der gesamten geografischen Landschaft sicher gespeichert werden.
Darüber hinaus können Ihre Sicherungen als Teil des Azure SQL-VM-Dienstanbieters automatisch von der Plattform verwaltet werden.
Azure Backup für SQL Server
Die Azure Backup-Lösung erfordert die Installation eines Agents auf der VM. Der Agent kommuniziert dann mit einem Azure-Dienst, der die automatischen Sicherungen Ihrer SQL Server-Datenbanken verwaltet. Azure Backup bietet auch einen zentralen Speicherort, den Sie zur Verwaltung und Überwachung der Sicherungen verwenden können, um sicherzustellen, dass alle angegebenen RPO-/RTO-Metriken erfüllt werden.
Wie oben gezeigt handelt es sich bei der Azure Backup-Lösung um eine umfassende Sicherungslösung für Unternehmen, die langfristige Datenaufbewahrung, automatisierte Verwaltung und zusätzlichen Datenschutz bietet. Diese Option kostet mehr als die Verwaltung Ihrer eigenen Sicherungen oder die Verwendung des Azure-Ressourcenanbieters für SQL Server, bietet jedoch eine umfassendere Gruppe von Features.
Azure Site Recovery
Azure Site Recovery ist eine günstige Lösung, die die Replikation Ihrer Azure-VM auf der Blockebene durchführt. Dieser Dienst bietet verschiedene Optionen, einschließlich der Möglichkeit, Ihre Notfallwiederherstellungsstrategie zu testen und zu überprüfen. Diese Lösung eignet sich am besten für zustandslose Umgebungen (z. B. Webserver) anstatt für transaktionalen Datenbank-VMs.
Azure Site Recovery wird zur Verwendung mit SQL Server unterstützt. Beachten Sie jedoch, dass Sie einen höheren Wiederherstellungspunkt festlegen müssen, was einen potenziellen Verlust bedeutet. In diesem Fall entspricht Ihr RTO (Recovery Time Objective) im Grunde Ihrem RPO (Recovery Point Objective).
- Die VM ist bei Azure Site Recovery registriert.
- Daten werden kontinuierlich in den Cache repliziert
- Der Cache wird in das Zielspeicherkonto repliziert
- Während des Failovers wird der virtuellen Computer der Zielumgebung hinzugefügt.