SQL Server 2019 Always On

Unermüdlich

In relationalen Datenbanken liegen meist kritische Unternehmensdaten. Entsprechend wichtig ist es, diese Datenspeicherung an den Grundsätzen der Informationssicherheit – Verfügbarkeit, Integrität und Vertraulichkeit – auszurichten. SQL Server setzt seit Version 2012 auf die Always-On-Technologien, um die Verfügbarkeit der Daten zu gewährleisten. Wir zeigen, wie weit Always On in der aktuellen Version 2019 gereift ist.
Mitarbeiter wie auch die Unternehmensleitung setzen die Verfügbarkeit von IT-Diensten längst als selbstverständlich voraus. Ungeplante Ausfälle sind deshalb ... (mehr)

Die Hochverfügbarkeits-Architektur von Microsoft SQL Server war ursprünglich von zwei Konzepten geprägt: Datenbankreplikation und Failover Clustering. Während die transaktionsbasierte Replikation ein hohes Maß an Verfügbarkeit und Integrität – bis hin zur Multi-Master-Replikation mit mehreren schreibbaren Replikaten – gewährleistet, ist sie nicht mit jedem Datenbankschema und nicht mit jedem Transaktionsverhalten gleichermaßen kompatibel.

Gerade wenn die Datenbank durch eine Drittanbieter-Applikation bereitgestellt wird, sind Sie darauf angewiesen, dass der Hersteller dieser Anwendung die Replikationsfähigkeit in seinem Datenbankdesign berücksichtigt. Failover Clustering ist nach wie vor das Mittel der Wahl, wenn es darum geht, dass der Zugriff auf die Datenbank selbst bei Ausfall eines Datenbankservers keinesfalls unterbrochen werden darf. Dafür existiert von jeder Datenbank, die in solch einer geclusterten Instanz (FCI) bereitgestellt wird, nur eine physische Kopie, die demnach den Single Point of Failure in diesem Konstrukt bildet.

Später kamen das Log Shipping und die darauf basierende Datenbankspiegelung dazu, die ein Aktiv-Passiv-Hochverfügbarkeitsmodell pro Datenbank bietet. Das Konzept erlaubt sogar ein automatisches Failover bei Ausfall der aktiven Kopie. Der Nachteil der herkömmlichen Datenbankspiegelung liegt in der zwingenden Notwendigkeit, der zugreifenden Clientanwendung den Spiegelpartner bereits beim Verbindungsaufbau mitzuteilen. Es ist also nicht möglich, die Spiegelung im Hintergrund auf einen anderen Server umzuleiten, ohne sämtliche zugreifenden Applikationen anpassen zu müssen.

Always On vereint den einfachen und robusten Zugriff auf die Datenbank, wie er beim Failover Clustering üblich ist, mit einer Unabhängigkeit von einem einzigen physischen Speicherort, die sowohl der transaktionellen Replikation als auch der Datenbankspiegelung eigen ist. Sogar eine gewisse Lastverteilung ist mit Always On

...

Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.

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

Ausgabe /2022