ADMIN 11/13 stellt die besten Lösungen vor und klärt, ob Browser-Plugins, Anonymisierer sowie Verschlüsselung wirklich helfen. Weitere Themen: Small ... (mehr)

AlwaysOn Failover Cluster

AlwaysOn-Failover-Cluster-Instanzen bieten ein Failover von einem momentan nicht mehr verfügbaren Knoten auf einen anderen Knoten unter Verwendung von Windows Server Failover Clustering (WSFC). Lokale Hochverfügbarkeit kommt in diesem Fall durch redundante Server-Instanzen zustande, die sogenannten FCIs (Failover-Cluster-Instanzen), die SAN-Speicher gemeinsam nutzen.

Bei einer FCI handelt es sich um eine einzelne Instanz von SQL Server, die über mehrere WSFC-Knoten (möglicherweise auch über mehrere Subnetze) verteilt installiert ist. Im Netz erscheint eine solche Installation wie ein einzelner Computer. Microsofts SQL Server Management Studio verbindet sich mit dem Cluster wie mit einem gewöhnlichen Host.

Die Editionen Standard und BI von SQL Server 2012 und 2014 unterstützen jeweils genau zwei Knoten. Die Enterprise-Version geht diesbezüglich bis an die Grenzen des Betriebssystems. Fällt der aktive Knoten aus, erfolgt ein vollautomatisches Failover: Der zweite Knoten übernimmt die Aufgaben des ersten Knotens. Für die Endanwender hat sich nichts geändert, sie können ihre Arbeit ungestört fortsetzen. Lediglich nicht abgeschlossene Transaktionen gehen dabei zwangsweise verloren. Bereits abgeschlossene Transaktionen bleiben erhalten.

Standard und Enterprise

In der Version 2014 erhält SQL Server leistungsstarke neue Funktionen, darunter:

  • In-Memory-OLTP (Codename Hakaton) für deutliche Performance-Verbesserungen bei häufigen Zugriffen auf eine Tabelle;
  • Verbesserungen in der Handhabung von Big Data mithilfe des »Resource Governors« .

Zahlreiche relevante Funktionen von SQL Server 2014 kommen leider nur Benutzern der Enterprise-Edition zu Gute. Dazu zählen:

  • Datenbanksnapshots,
  • Online-Re-Indizierung und parallele Indizierungsvorgänge,
  • Datenbankverschlüsselung (z.B. für E-Commerce),
  • Auditing,
  • Regelkonformität (der Deutsche Corporate Governance Kodex, DCGK, spricht hierbei Neudeutsch von »Compliance« ),
  • die überwiegende Mehrheit der Business-Intelligence-Funktionen,
  • Unterstützung für AlwaysOn-Hochverfügbarkeitsgruppen mit nun bis zu acht (statt vier) lesbaren Sekundärservern.

Die Standard-Edition von SQL Server 2014 bietet somit gar keine nicht veraltete Hochverfügbarkeitsfunktionen (stattdessen gibt es die eher nutzlose, weil veraltete Datenbankspiegelung). Noch bedauerlicher ist die Tatsache, dass die Standard-Edition von SQL Server 2014 bei gerade einmal 64 GByte Arbeitsspeicher das Ende der Fahnenstange erreicht, was die praktische Nutzbarkeit von nativem In-Memoy-OLTP in dieser Edition des Servers in Frage stellt.

AlwaysOn-Failover-Cluster-Instanzen schützen die Umgebung vor dem Ausfall eines Servers in dem Cluster, nicht jedoch vor dem Ausfall des SAN-Speichers. Die Daten sind damit nämlich nicht automatisch ebenfalls redundant gesichert, im Gegenteil: Alle Knoten greifen einfach auf denselben gemeinsam genutzten SAN-Speicher zu. Ein Defekt dieser Hardware kann daher leicht zum Verlust aller Daten führen. Um das Risiko von Datenverlusten zu minimieren, lässt sich SAN-Replikation einsetzen. Beim Ausfall des primären SAN-Speichers besteht in diesem Fall die Möglichkeit, die SAN-Replika dem Cluster manuell zur Verfügung zu stellen. Leider ist diese Lösung mit erheblichen Zusatzkosten verbunden und erfordert die Beteiligung eines SAN-Administrators.

AlwaysOn-HA in SQL Server

AlwaysOn-Hochverfügbarkeitsgruppen ersetzen die Funktionalität der Datenbankspiegelung und des Log-Versands durch Verbesserungen wie die Log-Synchronisierung. AlwaysOn-Hochverfügbarkeitsgruppen setzen auf WSFC auf, gewährleisten Redundanz auf Datenbankebene und erlauben die Nutzung der Sekundärserver für Lesezugriffe. Anders als im Falle der Datenbankreplikation müssen Indizes und Schemata auf allen Instanzen identisch sein.

Bei einer Verfügbarkeitsgruppe handelt es sich um eine Failover-Umgebung für Benutzerdatenbanken (die sogenannten Verfügbarkeitsdatenbanken). Das Failover zwischen synchronen Replika in einer AlwaysOn-Hochverfügbarkeitsgruppe erfolgt vollautomatisch. Asynchrone Replika eignen sich nur für manuelles Failover. Dafür können sie sich in verschiedenen Datencentern befinden und auf völlig verschiedener Hardware laufen.

Microsoft führte die AlwaysOn-Hochverfügbarkeitsgruppen in SQL Server 2012 ein und hat diese Technologie in der Version 2014 ausgebaut. SQL Server 2014 bietet nun Unterstützung für insgesamt acht statt der zuvor unterstützten vier Sekundärreplikas. In Multi-Site-Umgebungen bleiben diese erstmals auch dann lesbar, wenn sich die Verbindung zum primären Server nicht herstellen lässt. Den größten Nutzen ziehen daraus diejenigen Unternehmen, die ihre Hochverfügbarkeitsgruppen in verschiedenen geografisch verteilten Datencentern aufstellen.

Asynchrone Replika können die primären Instanzen entlasten, indem sie einen Teil der Lesezugriffe übernehmen. Erstmals in SQL Server 2014 besteht die Möglichkeit, die Belastung der Hochverfügbarkeitsgruppe mit einem Lastverteiler zu verwalten.

SQL Server 2014 integriert sich nahtlos mit Windows Azure. Benutzer von SQL Server in der Microsoft-Wolke können SQL Server 2014 als eine synchrone sekundäre Replika für die Azure-Dienste nutzen. Auch das umgekehrte Szenario ist vorgesehen: Wer SQL Server im Haus einsetzt, kann seine Datenbanken auf Windows Azure asynchron replizieren, um im Notfall ein manuelles Failover zu veranlassen.

AlwaysOn-Hochverfügbarkeitsgruppen erfordern leider die Edition Enterprise sowohl in SQL Server 2012 als auch in 2014. Die Datenbankspiegelung, die voraussichtlich in der nächsten Version nach SQL Server 2014 entfällt, war auch in der Edition Standard verfügbar. Es ist daher bedauerlich, dass Microsoft der Standard-Edition von SQL Server 2012 und 2014 nicht einmal die geringste Ausbaustufe von AlwaysOn-Hochverfügbarkeitsgruppen spendiert hat. Der Wegfall von Hochverfügbarkeitstechnologien in der Edition Standard bedeutet also praktisch eine schleichende Preiserhöhung. Daher sehen sich viele Anwender von SQL Server gezwungen, alternative Lösungen in Betracht zu ziehen.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2020