Mainzer Datenfabrik ist Microsoft Gold Partner

Interesse geweckt?

Lassen Sie uns reden!

blog.Mainzer Datenfabrik

Windows Linux mixed SQL Server Availability Group

cover image of blog article 'Windows Linux mixed SQL Server Availability Group'

Übersicht

Linux ist schon immer ein Thema in der IT, da das Open-Source Prinzip eine kostengünstigere Alternative zu Microsoft Produkten darstellt. Zudem hat Linux den Vorteil, dass es mit den Sicherheitsfunktionen weniger Angriffsfläche bietet als Windows und dabei genauso stabil, wenn nicht stabiler läuft. Darum ist es kein Wunder, dass auch bei Datenbanksystemen häufiger zu Linux Maschinen gegriffen wird. Aber es wird dabei immer auf eine einheitliche Systemstruktur geachtet. Doch wie sieht es nun aus, wenn man Maschinen mit verschiedenen Betriebssystemen hat? Anhand eines Beispiels wollen wir in diesem Artikel zeigen, wie man eine Availability Group (AG) aus Maschinen mit unterschiedlichen Systemen erstellen kann.

Voraussetzungen

Will man nun solch eine Availability Group erstellen, benötigt man sowohl eine Linux-, als auch eine Windows-Maschine. In unserem Beispiel haben wir Ubuntu 20.04 und Windows Server 2022 genutzt. Auf beiden Maschinen ist eine Instanz von SQL Server installiert. Zudem haben wir beide Maschinen unserer Domain hinzugefügt. Im Folgenden wollen wir die AG so erstellen, dass die Windows Maschine die primäre Instanz ist. Wir verwenden virtuelle Maschinen (VMs) und nennen die Linux VM linsql und die Windows VM winsql.

1. Schritt: Vorbereiten der Maschinen

Nachdem beide VMs aufgesetzt sind, müssen noch ein paar weitere Einstellungen vorgenommen werden. Zum einen muss das Always On Feature aktiviert und zum anderen sichergestellt werden, dass beide Maschinen miteinander kommunizieren können. Da dies für beide unterschiedlich ist, teilen wir diesen Punkt auf.

Windows

Beginnen wir mit der Aktivierung der Always On Funktion. Hierzu öffnen wir den Configuration Manager. Als nächstes müssen wir den SQL Server finden. Dafür navigieren wir auf der linken Seite zu dem Eintrag “SQL Server Services”. Auf der rechten Seite sollten die Services angezeigt werden, dabei auch der Server. Mit Rechtsklick öffnen wir die Eigenschaften und navigieren zum ‘Always On Availability Groups’ Reiter. Dort den Haken zum Aktivieren der Eigenschaft setzen. Damit die Änderungen übernommen werden, muss der SQL Server anschließend neu gestartet werden.

Aktivierung der Always On Availability Groups
Aktivierung der Always On Availability Groups

In der Zwischenzeit können wir uns um die Firewall kümmern. Wir wollen zwei Ports zulassen. Zum einen den Port, über den SQL Server kommuniziert. Dieser ist standardmäßig 1433. Den zweiten Port benötigen wir zur Endpoint Kommunikation beider Maschinen. Dafür wählen wir 5022. Wählen wir hier einen anderen, müssen wir später die Skripte anpassen. Sollten beide Maschinen nicht in derselben Domain sein, müssen wir zudem noch die ‘hosts’ Datei anpassen. Diese findet man unter C:\Windows\System32\drivers\etc. Hier einfach die IP und den Hostnamen der Linux Maschine angeben.

Linux

In Linux werden die Einstellungen des SQL Servers über die mssql-conf Datei verwaltet. Um hier die Always On Funktion zu aktivieren, kann folgender Befehl ausgeführt werden.
sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
Auch hier muss der Server neu gestartet werden, damit die Einstellung übernommen wird. Dazu führen wir im Anschluss diesen Befehl aus.
sudo systemctl restart mssql-server.service
Desweiteren muss auch bei der Linux Maschine darauf geachtet werden, dass die richtigen Ports an der Firewall freigegeben sind und gegebenenfalls der Windows Hostname zusammen mit der IP angegeben wird. In Linux werden die Hostnamen in der Datei /etc/hosts gepflegt.

2. Schritt: SQL Server Verbindung herstellen

Für das Datenbank Mirroring soll die Kommunikation über Endpoints laufen. Deshalb müssen wir hierfür noch einige Dinge in SQL Server anlegen. Beginnen wollen wir mit Logins und Usern. Diese benötigen wir in beiden Instanzen. Hierfür können wir die folgenden SQL Befehle verwenden.

CREATE LOGIN dbLogin WITH PASSWORD = 'P@ssw0rd';
Go
CREATE USER dbUser FOR LOGIN dbLogin;
GO

Da wir zur Authentifizierung Zertifikate brauchen, muss zuvor ein Master Key erstellt werden. Wenn das noch nicht geschehen ist, kann folgende Funktion benutzt werden.

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'P@ssw0rd';
GO

Bis hierhin musste alles auf beiden Maschinen ausgeführt werden. Das ändert sich jetzt.

Auf der Windows Instanz erstellen wir nun ein Zertifikat, welches wir danach zur Authentifizierung auf der Linux Seite verwenden wollen. Dafür werden wir das Zertifikat nach dem Erstellen speichern.

CREATE CERTIFICATE dbCert WITH SUBJECT = 'Cross Platform AOAG';
GO

BACKUP CERTIFICATE dbCert
TO FILE = 'C:\your\path\dbCert.cer'
WITH PRIVATE KEY (
        FILE = 'C:\your\path\dbCert.pvk',
        ENCRYPTION BY PASSWORD = 'P@ssw0rd'
    );
GO

Das gespeicherte Zertifikat müssen wir nun zusammen mit dem privaten Schlüsseln auf unsere Linux Maschine kopieren. Abgelegt haben wir die Dateien unter /var/opt/mssql/data, was der Standard Pfad für die SQL Daten ist. Am Ende müssen wir dem User Agent von SQL Server Rechte an den Dateien geben. Der User ist dabei standardmäßig ‘mssql’. Damit wir später auf keine Probleme stoßen, weisen wir sowohl den User, als auch die Gruppe als Owner der Dateien zu. Das geht unter Linux mit folgenden Befehlen.
sudo chown mssql:mssql /var/opt/mssql/data/dbCert.cer

sudo chown mssql:mssql /var/opt/mssql/data/dbCert.pvk

Wurde das Zertifikat erfolgreich übertragen, können wir damit auf der Linux Instanz ebenfalls ein Zertifikat erstellen. Wichtig ist dabei, dass das Passwort dasselbe ist, welches zum Verschlüsseln auf der Windows Instanz verwendet wurde.

CREATE CERTIFICATE dbCert
AUHORIZATION dbUser
FROM FILE = '/var/opt/mssql/data/dbCert.cer'
WITH PRIVATE KEY(
  FILE = '/var/opt/mssql/data/dbCert.pvk',
  DECRYPTION BY PASSWORD = 'P@ssw0rd'
  )
GO

Da wir nun auf beiden Instanzen ein Zertifikat haben, können wir die Endpoints erstellen. Über diese Endpoints wird die Kommunikation zwischen beiden Instanzen laufen. Darum muss folgendes Skript auf beiden Maschinen ausgeführt werden.

CREATE ENPOINT AOAGEndpoint
AS TCP (LISTENER_PORT = 5022)
FOR DATA_MIRRORING(
  ROLE = ALL,
  AUTHENTICATION = CERTIFICATE dbCERT,
  ENCRYPTION = REQUIRED ALGORITHM AES
  );
GO

ALTER ENDPOINT AOAGEndpoint STATE = STARTED;
GO

GRANT CONNECT ON ENDPOINT::AOAGEndpoint TO dbLogin;
GO

3. Schritt: Erstellen der Availability Group

Kommen wir zur tatsächlichen Magie. Denn nun können wir die Availability Group erstellen. Dafür wollen wir folgendes Skript auf der Windows Instanz ausführen, da diese zu Beginn die primäre Rolle haben soll. Davor kurz ein paar Worte zu den Angaben im Code.

  • CLUSTER_TYPE: Da wir für die hier dargestellte Konfiguration keinen Cluster im Windows-Sinn erstellt haben, geben wir hier NONE an.
  • ENDPOINT_URL: Hier geben wir die Daten unserer Endpunkte an. In unserem Beispiel nutzen wir TCP und den Port 5022.
  • AVAILABILITY_MODE: Für den Anfang wollen wir diesen beim asynchronen Modus belassen.
  • SEEDING_MODE: Da unsere SQL Instanzen auf verschiedenen Betriebssystemen laufen, sind auch die Pfade der Datenbanken unterschiedlich. Darum lassen wir diese Einstellung bei MANUAL.
  • FAILOVER_MODE: Da wir kein Windwos Failover Cluster haben, wird hier nur der manuelle Failover Modus unterstützt.
  • SECONDARY_ROLE: Es werden alle Verbindungen der sekundären Replikas zugelassen.
CREATE AVAILABILITY GROUP ag1
  WITH (CLUSTER_TYPE = NONE)
  FOR REPLICA ON
      N'winsql' 
  WITH (
      ENDPOINT_URL = N'tcp://winsql:5022',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      SEEDING_MODE = MANUAL,
      FAILOVER_MODE = MANUAL,
     SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)
      ),
      N'linsql' 
  WITH (
      ENDPOINT_URL = N'tcp://linsql:5022',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      SEEDING_MODE = MANUAL,
     FAILOVER_MODE = MANUAL,
     SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)
      )
GO

Sobald die Gruppe erstellt wurde, muss die Linux Instanz dieser auch beitreten. Dafür muss folgender Befehl auf der Linux Instanz ausgeführt werden.

ALTER AVAILABILITY GROUP ag1 JOIN WITH (CLUSTER_TYPE = NONE)

Schon sind beide Instanzen in einer Availability Group. Öffnet man in SSMS das Dashboard zur Gruppe, sollten beide Maschinen angezeigt werden und eine erfolgreiche Verbindung bestehen. Jedoch wird es noch Warnungen geben. Das liegt daran, dass wir noch keine Datenbank in der Gruppe haben. Das wollen wir ändern.

Um eine Datenbank zu einer AG hinzufügen zu können, muss sich diese im Full Recovery Modus befinden und es muss ein vollständiges Backup existieren. Für unser Beispiel verwenden wir die AdventureWorks2022 Datenbank. Wir mussten den Recovery Modus ändern und haben im Anschluss ein Backup erstellt. Wenn Sie eine andere Datenbank verwenden wollen, prüfen Sie die Datenbank auf die Anforderungen. Das erstellte Backup wollen wir zur Linux Maschine kopieren, wo wir die Datenbank wiederherstellen. Wichtig ist hierbei, dass dies im NORECOVERY Modus geschieht. Zudem muss auf die richtige Pfadangabe geachtet werden. Für unser Beispiel, in dem sich die Datendateien und die TLog-Dateien im Verzeichnis /var/opt/mssql/data befinden, sieht das Skript so aus:

RESTORE DATABASE AdventureWorks2022
FROM DISK = '/<Pfad des Backup-Verzeichnis>/AdventureWorks22022.bak'
WITH MOVE 'AdventureWorks2022' TO '/var/opt/mssql/data/AdventureWorks2022.mdf',
  MOVE 'AdventureWorks2022_log' TO '/var/opt/mssql/data/AdvéntureWorks2022_log.ldf',
  NORECOVERY;
GO

Wurde die Datenbank erfolgreich wiederhergestellt, fügen wir diese zur AG hinzu. Dazu wechseln wir wieder auf die primäre Instanz und führen folgenden Befehl aus.

ALTER AVAILABILITY GROUP ag1 ADD DATABASE AdventureWorks2022
GO

Ob die DB erfolgreich hinzugefügt wurde, kann man entweder daran erkennen, dass hinter der Datenbank nun ein (Synchronized) steht. Alternativ öffnet man das Dashboard der Availability Group. In unserem Fall ist ein Fehler aufgetreten, bei dem die sekundäre Replika nicht synchronisiert war. Der Fehler bestand darin, dass wir noch keine sekundäre Replika der Datenbank hinzugefügt haben. Das lässt sich beheben, indem man ein Transaction Log Backup erstellt und dieses auf der sekundären DB wiederherstellt. Im Anschluss führt man diesen Befehl aus und die sekundäre Replika sollte den Status ‘Synchronizing’ haben.

ALTER DATABASE AdventureWorks2022 SET HADR AVAILABILITY GROUP = ag1;
GO

Wechselt man nun noch den Commit Modus zu synchron, sollten beide Datenbanken ‘Synchronized’ sein.

Melden Sie sich zu unserem monatlichen Newsletter an.

Seitennavigation

Zur Artikel Übersicht

Auf dieser Seite

SQL Server 2014 Migration SupportNEU
Im Sommer 2024 endet der Extended Support des Microsoft SQL Server 2014 SP3. Erfahren sie wie wir Sie bei Ihrer Migration unterstützen können! mehr erfahren