[Quelle] Hohe Verfügbarkeit in SQL Server (1) ---- Überblick über die Hochverfügbarkeit

Seit SQL Server 2005 hat Microsoft eine Vielzahl von Hochverfügbarkeitstechnologien bereitgestellt, um Ausfallzeiten zu reduzieren und den Schutz von Geschäftsdaten zu erhöhen, und mit der kontinuierlichen Veröffentlichung von SQL Server 2008, SQL Server 2008 R2 und SQL Server 2012 gibt es viele hochverfügbare Technologien in SQL Server, um unterschiedlichen Szenarien gerecht zu werden.

    Bevor ich mit diesem Artikel beginne, gebe ich einen kurzen Überblick darüber, was bestimmt, welche hochverfügbare Technologie verwendet werden sollte.

    Viele Unternehmen müssen alle oder teilweise ihrer Daten hoch verfügbar sein, wie zum Beispiel Online-Shopping-Websites, Online-Produktdatenbanken müssen rund um die Uhr online sein; sonst bedeutet Ausfallzeiten in einem sehr wettbewerbsintensiven Marktumfeld Kundenverluste und Umsatzverluste. Zum Beispiel können in einem Callcenter, das auf SQL Server angewiesen ist, wenn die Datenbank ausfällt, alle Anrufer nur dem Kunden antworten: "Entschuldigung, Systemausfall", was ebenfalls inakzeptabel ist.

    Natürlich wären in einer idealen Welt alle kritischen Daten jederzeit online, aber in der realen Welt gibt es verschiedene Gründe, warum die Datenbank nicht verfügbar ist, da es unmöglich ist, Zeit und Art einer Katastrophe vorherzusagen; es ist notwendig, im Voraus Maßnahmen zu ergreifen, um verschiedene Notfälle zu verhindern, weshalb SQL Server eine Vielzahl von Hochverfügbarkeitstechnologien bereitstellt, die hauptsächlich Clustering, Replikation, Spiegelung, Loglieferung, AlwaysOn-Verfügbarkeitsgruppen und andere Technologien wie Sicherung und Wiederherstellung von Dateigruppen, Single-Instanz-Hochverfügbarkeitstechnologien wie Online-Rekonstruktionsindexe. Der Einsatz von Hochverfügbarkeitstechnologie besteht nicht darin, eine vertraute Technologie für den direkten Einsatz zu wählen, sondern das Geschäft und die Technologie umfassend zu betrachten. Denn es gibt keine einzige Technologie, die alle Funktionen erfüllen kann. Wie man diese Technologien basierend auf Ihrem spezifischen Unternehmen und Budget einsetzt, wird als High-Availability-Strategie bezeichnet.

Bei der Entwicklung einer High-Availability-Strategie sollten Sie zunächst folgende Faktoren berücksichtigen:

• RTO (Recovery Time Objective) – also das Wiederherstellungszeit-Ziel, bedeutet, wie viel Ausfallzeit erlaubt ist, üblicherweise ausgedrückt durch einige 9s, zum Beispiel bedeutet 99,999 % Verfügbarkeit nicht mehr als 5 Minuten Ausfallzeit pro Jahr, 99,99 % Verfügbarkeit nicht mehr als 52,5 Minuten Ausfallzeit pro Jahr und 99,9 % Verfügbarkeit nicht mehr als 8,75 Stunden Ausfallzeit pro Jahr. Es ist erwähnenswert, dass die Berechnungsmethode von RTO berücksichtigt, ob das System 24*365 oder nur von 6 Uhr morgens bis 21 Uhr usw. ist. Man muss auch darauf achten, ob das Wartungsfenster als Ausfallzeit gezählt wird, und es ist einfacher, eine höhere Verfügbarkeit zu erreichen, wenn Datenbankwartung und Patching während des Wartungsfensters erlaubt sind.
• RPO (Recovery Point Objective) – Auch bekannt als Recovery Point Objective, bedeutet, wie viel Datenverlust erlaubt ist. In der Regel kannst du, solange du ein gutes Backup machst, problemlos keinen Datenverlust erzielen. Wenn jedoch eine Katastrophe eintritt, führt je nach Ausmaß der Datenbankkorruption die Zeit, die für die Wiederherstellung von Daten aus einem Backup benötigt wird, dazu, dass die Datenbank nicht mehr verfügbar ist, was die Implementierung von RTO beeinträchtigt. Ein frühes und bekannteres Beispiel ist ein Banksystem in Europa und den Vereinigten Staaten, wobei nur RPO berücksichtigt wird, es gibt nur vollständige Backups und Log-Backups im System, vollständige Backups alle 3 Monate, Log-Backups alle 15 Minuten, und wenn eine Katastrophe eintritt, können nur vollständige Backups und Protokollbackups Daten wiederherstellen, sodass zwar kein Datenverlust vorliegt, aber weil die Wiederherstellung der Daten zwei volle Tage dauerte, das Banksystem zwei Tage lang nicht verfügbar war, sodass viele Kunden verloren gingen. Ein weiteres gegenteiliges Beispiel ist eine inländische Online-Video-Website, die SQL Server als Backend-Relationaldatenbank verwendet, das Frontend No-SQL verwendet und regelmäßig No-SQL-Daten als Backup in die relationale Datenbank importiert.
  

    Budget – RTO und RPO werden zusammen als SLAs (Service Level Agreements) bezeichnet, und bei der Entwicklung einer High-Availability-Strategie müssen Sie abmessen, wie gut Sie SLAs basierend auf Ihrem Unternehmen einhalten, abhängig von Ihrem Budget und der Messung der Kosten verschiedener SLAs im Falle eines Ausfalls. Im Allgemeinen ist es schwierig, hohe SLAs mit begrenztem Budget zu erreichen, und selbst wenn hohe SLAs durch komplexe Architekturen erreicht werden, bedeuten komplexe Architekturen auch hohe Betriebs- und Wartungskosten, weshalb es notwendig ist, die richtige Technologie innerhalb des Budgets zu wählen, um die SLAs zu erfüllen.

Daher kann im Allgemeinen das große Rahmenwerk für hohe Verfügbarkeit durch mehrere Bestellungsfragen bestimmt werden:

• Welche Ausfallzeiten sind die Aktionäre bereit zu akzeptieren?
• Welche Ausfallzeiten sind für Manager akzeptabel?
• Wie hoch ist das Budget für ein Szenario mit hoher Verfügbarkeit?
• Wie hoch ist der Verlust pro Stunde durch Ausfallzeiten?
  

• Cold Backup: Der Standby-Server ist so konfiguriert, dass er die Daten des Primärservers akzeptiert und bei einem Ausfall die Daten manuell in die Primärdatenbank zurückstellt oder die Verbindungsstring oder Berechtigungen des Programms neu konfiguriert, um die Backup-Datenbank online zu bringen.
• Warm-Backup: Die Daten des primären Servers senden kontinuierlich Logs an den Backup-Server (in unregelmäßigen Abständen, das können 15 Minuten, 30 Minuten, 1 Minute usw. dauern); auf diese Weise wird der primäre Server zum Backup-Server in der Regel asynchron aktualisiert, sodass die Daten des Primärservers und des Backup-Servers nicht garantiert werden können. Außerdem implementiert dieses Schema typischerweise keine automatische Fehlerüberwachung und Failover.
• Hot-Backup: Die Daten des Primärservers werden automatisch auf dem Backup-Server synchronisiert, in den meisten Fällen sind automatische Fehlerüberwachung und Failover enthalten; die Datenkonsistenz des Primärservers und des Backup-Servers kann garantiert werden.
  

    Von kalt zu warm bis heiß schießen die Kosten in die Höhe.

    Die in SQL Server unterstützten High-Availability-Funktionen stehen in engem Zusammenhang mit der Version, und die Enterprise-Edition unterstützt alle High-Availability-Funktionen, einschließlich:

• Failover-Cluster
• l Datenbankbild
• l Übertragung von Transaktionsprotokollen
• l Datenbank-Snapshots
• Hohe Verfügbarkeits-Upgrades
• l Hotload-Speicher
• l Online-Indexierungsoperationen
• l Datenbank teilweise online (nur Master-Dateigruppe oder Master-Dateigruppe sowie zusätzliche NDF-Dateien werden wiederhergestellt)
  

    Für spezifische Versionen dieser hochverfügbaren Funktionen siehe:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxEs ist erwähnenswert, dass die kostenlose Express-Version als Zeugenserver für Datenbankspiegelung dienen kann, was zu Kosteneinsparungen führt.

Failover-Cluster

    Failover-Cluster bieten High-Availability-Unterstützung für die gesamte SQL-Server-Instanz, was bedeutet, dass eine SQL-Server-Instanz auf einem Knoten im Cluster aufgrund von Hardwarefehlern, Betriebssystemfehlern usw. auf andere Knoten des Clusters überführt. Hohe Verfügbarkeit wird erreicht, indem mehrere Server (Knoten) eine oder mehrere Festplatten teilen, und Failover-Cluster erscheinen im Netzwerk auf ähnliche Weise wie ein einzelner Computer, jedoch mit hohen Verfügbarkeitsmerkmalen. Es ist wichtig zu beachten, dass da Failover-Cluster auf gemeinsamen Festplatten basieren, es einen Single Point of Plate Failure gibt, sodass zusätzliche Schutzmaßnahmen wie SAN-Replikation auf Festplattenebene eingesetzt werden müssen. Der häufigste Failover-Cluster ist ein Zwei-Knoten-Failover-Cluster, einschließlich Master und Slave.

Übertragung von Transaktionsprotokollen

    Das Versand von Transaktionsprotokollen bietet einen hochverfügbaren Schutz auf Datenbankebene. Logging wird verwendet, um eine oder mehrere Standby-Datenbanken (sogenannte "sekundäre Datenbanken") der entsprechenden Produktionsdatenbank (genannt "primäre Datenbank") zu pflegen. Vor einem Failover muss die sekundäre Datenbank vollständig aktualisiert werden, indem alle nicht wiederhergestellten Log-Backups manuell angewendet werden. Log-Delivery bietet die Flexibilität, mehrere Standby-Datenbanken zu unterstützen. Wenn mehrere alternative Datenbanken benötigt werden, kann die Loglieferung separat oder als Ergänzung zur Datenbankspiegelung verwendet werden. Wenn diese Lösungen zusammen verwendet werden, ist die Hauptdatenbank der aktuellen Datenbankspiegelungskonfiguration auch die primäre Datenbank der aktuellen Log-Shipping-Konfiguration.

    Die Lieferung von Transaktionsprotokollen kann verwendet werden, um kalte und warme Backups zu machen.

Datenbankspiegelung

    Datenbankspiegelung ist tatsächlich eine Softwarelösung, die auch Datenbankschutz bietet und nahezu sofortiges Failover ermöglicht, um die Datenbankverfügbarkeit zu verbessern. Ein Datenbankspiegel kann verwendet werden, um eine einzelne Standby-Datenbank (oder "Spiegeldatenbank") für die entsprechende Produktionsdatenbank (genannt "Hauptdatenbank") zu pflegen.
Da sich die Spiegeldatenbank immer im Wiederherstellungszustand befindet, die Datenbank jedoch nicht wiederhergestellt wird, kann die Spiegeldatenbank nicht direkt zugänglich sein. Für schreibgeschützte Ladevorgänge wie Berichte kann man die gespiegelte Datenbank jedoch indirekt verwenden, indem man einen Datenbanksnapshot der gespiegelten Datenbank erstellt. Datenbank-Snapshots gewähren den Clients Schreibzugriff auf die Daten in der Datenbank, wenn der Schnappschuss erstellt wird. Jede Datenbankspiegelungskonfiguration beinhaltet einen "Hauptserver", der die Hauptdatenbank enthält, sowie einen Spiegelserver, der die gespiegelte Datenbank enthält. Der Spiegelserver aktualisiert die Spiegeldatenbank kontinuierlich mit der Hauptdatenbank.
    Datenbankspiegelung läuft im synchronen Betrieb im Hochsicherheitsmodus oder asynchron im Hochleistungsmodus. Im Hochleistungsmodus müssen Transaktionen nicht warten, bis der Spiegelserver Logs auf die Festplatte schreibt, bevor sie gesendet werden können, was die Leistung maximiert. Im Hochsicherheitsmodus werden zugesagte Transaktionen von beiden Partnern durchgeführt, aber die Transaktionsverzögerung wird verlängert. Die einfachste Konfiguration des Datenbankspiegelungs umfasst nur den Hauptserver und den Spiegelserver. In dieser Konfiguration kann der Spiegelserver als Standby-Server verwendet werden, wenn der Hauptserver verloren geht, dies kann jedoch Datenverluste verursachen. Der Hochsicherheitsmodus unterstützt die Standby-Konfiguration, den Hochsicherheitsmodus mit automatischem Failover. Diese Konfiguration beinhaltet eine Drittanbieter-Serverinstanz, die als "Witness Server" bezeichnet wird und es ermöglicht, den Spiegelserver als Hot-Backup-Server zu nutzen. Der Failover von der Primärdatenbank zur Spiegeldatenbank dauert typischerweise nur wenige Sekunden.

    Datenbankspiegelung kann sowohl für warme als auch für warme Backups verwendet werden.

kopieren

    Replikation ist nicht strikt eine Funktion, die auf hohe Verfügbarkeit ausgelegt ist, aber sie kann auch auf hohe Verfügbarkeit angewendet werden. Replikation bietet Schutz auf Datenbankobjektebene. Die Replikation verwendet ein Publish-Subscribe-Modell, bei dem Daten vom primären Server, dem sogenannten Publisher, an einen oder mehrere sekundäre oder Abonnenten veröffentlicht werden. Replikation sorgt für Echtzeitverfügbarkeit und Skalierbarkeit zwischen diesen Servern. Es unterstützt Filterung, um einen Teilsatz der Daten an Abonnenten bereitzustellen, und unterstützt gleichzeitig Partitionsupdates. Der Abonnent ist online und steht für Berichte oder andere Funktionen ohne Abfragewiederherstellung zur Verfügung. SQL Server bietet vier Replikationstypen an: Snapshot-Replikation, transaktionale Replikation, Peer-to-Peer-Replikation und Merge-Replikation.

AlwaysOnUsability-Gruppe

    AlwaysOn Availability Groups ist eine neue Funktion, die in SQL Server 2012 eingeführt wurde. Ein Datenbankschutz wird ebenfalls bereitgestellt. Außerdem wird die Grenze erweitert, dass Datenbankspiegelung nur 1:1 betragen darf, sodass eine primäre Replik bis zu 4 sekundären Replikaten entspricht (in SQL Server 2014 wird diese Grenze auf 8 erhöht), von denen 2 sekundäre Replikate als Hot-Backups und primäre Replikate in Echtzeit synchronisiert werden können und die anderen beiden asynchronen sekundären Replikate als warme Backups verwendet werden können. Zusätzlich können sekundäre Replikate als schreibgeschützt konfiguriert werden und zur Übernahme von Backups genutzt werden.

    Aus diesem Grund wird Datenbankspiegelung in SQL Server 2012 als "veraltet" markiert.

    Nachdem wir die grundlegenden Konzepte der hohen Verfügbarkeit und die in SQL Server bereitgestellten High-Availability-Technologien verstanden haben, werfen wir einen Blick auf das Design einer High-Availability-Strategie. Die Planung einer Hochverfügbarkeitsstrategie lässt sich in vier Phasen unterteilen:

Sammeln von Anforderungen

    Der erste Schritt bei der Entscheidung für eine High-Availability-Strategie ist zweifellos, Geschäftsanforderungen zu sammeln, um SLAs zu etablieren. RTO und RPO sind die wichtigsten Bestandteile und setzen auf dieser Grundlage realistische Erwartungen an die Verfügbarkeitsanforderungen und entwickeln eine realistische Strategie für hohe Verfügbarkeit auf dieser Grundlage.

Bewertungsgrenzen

    Die Bewertungsgrenzen beschränken sich nicht nur auf die Einschränkungen verschiedener Hochverfügbarkeitstechnologien in SQL Server, sondern auch auf solche, die nicht technisch sind. Wenn Sie nur ein Budget von Zehntausenden Yuan haben, aber eine hochverfügbare Lösung auf Basis von externen Rechenzentren und SAN-Replikation anbieten möchten, ist das zweifellos ein Törichtraum. Eine weitere nicht-technische Einschränkung ist das Niveau des Betriebspersonals, und oft bedeuten komplexe Architekturen qualifizierteres Betriebspersonal. Weitere nicht-technische Einschränkungen sind die Verfügbarkeit von Festplattenplatz im Rechenzentrum, ob Stromversorgung und Klimaanlage die Anforderungen erfüllen können und die Zeit für die Umsetzung der Verfügbarkeitsstrategie.

    Technische Einschränkungen umfassen verschiedene Funktionen und Einschränkungen bei hoher Verfügbarkeit, Funktionen, die von verschiedenen SQL-Server-Versionen unterstützt werden, die Anzahl der CPUs und die Größe des Speichers. Es wird dringend empfohlen, zunächst die Einschränkungen verschiedener SQL-Server-Versionen und Funktionen auf der Microsoft MSDN-Website zu betrachten, bevor Sie eine High-Availability-Richtlinie implementieren.

Ausgewählte Technologie

    Nach der Sammlung von Anforderungen und der Bewertung von Einschränkungen besteht der nächste Schritt darin, die zuvor in diesem Artikel beschriebenen Technologien oder Kombinationen auszuwählen, um die SLA-Anforderungen zu erfüllen. Wenn die ausgewählte Technologie das SLA nicht erfüllt, ist es einfach, die Einschränkungen zu melden, die die SLA nicht erfüllen, sodass Sie fehlende Ressourcen anfordern oder Kompromisse beim SLA eingehen können.

Testen, validieren und dokumentieren

    High-Availability-Richtlinien müssen von Anfang an rigoros getestet und validiert werden, um sicherzustellen, dass aktuelle Verfügbarkeitsrichtlinien SLAs erfüllen. Wenn jedoch eine Hochverfügbarkeitsstrategie gestartet wird, ist es auch notwendig, diese regelmäßig zu testen und zu validieren, um sicherzustellen, dass die aktuelle Richtlinie trotz Datenwachstum, Geschäfts- oder Anforderungsänderungen weiterhin SLAs erfüllen kann. Gleichzeitig sollten die Konfiguration der Verfügbarkeitslösung, die Methode des Failovers und der Katastrophenwiederherstellungsplan dokumentiert werden, damit sie im Falle eines Ausfalls oder einer zukünftigen Anpassung der Hochverfügbarkeitsstrategie nachverfolgt werden können.

Dieser Artikel erklärt die grundlegenden Konzepte der hohen Verfügbarkeit, das Konzept der SLAs, die verschiedenen Arten von High-Availability-Funktionen, die in SQL Server unterstützt werden, sowie die notwendigen Schritte zur Entwicklung einer High-Availability-Strategie. Es ist erwähnenswert, dass, obwohl dieser Artikel nur über hohe Verfügbarkeit auf Datenbankebene spricht, hohe Verfügbarkeit nicht nur für DBA relevant ist, sondern auch die Zusammenarbeit verschiedener Rollen wie Systembetrieb und Wartung, Netzwerkadministratoren, Entwickler und Manager umfasst, um SLAs besser zu erfüllen.