Share via

Failoverclusterinstanzen – SQL Server für Linux

  • Artikel

Gilt für:SQL Server – Linux

In diesem Artikel werden die Konzepte im Zusammenhang mit SQL Server-Failoverclusterinstanzen (FCI) unter Linux erläutert.

Informationen zum Erstellen einer SQL Server-FCI unter Linux finden Sie unter Configure SQL Server FCI on Linux (Konfigurieren von SQL Server-FCI unter Linux).

Die Clusteringebene

Sowohl das RHEL-Hochverfügbarkeits-Add-On als auch SUSE HAE basieren auf Pacemaker.

Wie in der folgenden Abbildung zu sehen, wird der Speicher zwei Servern präsentiert. Clusteringkomponenten – Corosync und Pacemaker – koordinieren die Kommunikation und die Ressourcenverwaltung. Ein Server verfügt über die aktive Verbindung mit den Speicherressourcen und SQL Server. Wenn Pacemaker einen Fehler erkennt, sind die Clusteringkomponenten das Verschieben der Ressourcen auf den anderen Knoten verantwortlich.

Diagram of Red Hat Enterprise Linux 7 shared disk SQL Server cluster.

Die Integration von SQL Server mit Pacemaker unter Linux ist nicht so stark gekoppelt wie mit WSFC unter Windows. SQL Server hat keine Kenntnis über das Vorhandensein des Clusters. Alle Orchestrierungen befinden sich außerhalb und der Dienst wird von Pacemaker als eigenständige Instanz gesteuert. Außerdem ist der Name des virtuellen Netzwerks spezifisch für WSFC, das keine Entsprechung in Pacemaker hat. Es wird erwartet, dass @@SERVERNAME und sys.servers den Knotennamen zurückgeben, während die Cluster-DMVs sys.dm_os_cluster_nodes und sys.dm_os_cluster_properties keine Datensätze zurückgeben. Wenn Sie eine Verbindungszeichenfolge verwenden möchten, die auf einen Zeichenfolgenservernamen zeigt und nicht die IP-Adresse verwendet, müssen Sie die IP-Adresse, die (wie in den folgenden Abschnitten beschrieben) zum Erstellen der virtuellen IP-Ressource verwendet wird, mit dem ausgewählten Servernamen beim DNS-Server registrieren.

Anzahl der Instanzen und Knoten

Ein wichtiger Unterschied bei SQL Server für Linux besteht darin, dass es pro Linux-Server nur eine Installation von SQL Server geben kann. Diese Installation wird als Instanz bezeichnet. Im Gegensatz zu Windows Server, das bis zu 25 FCIs pro Windows Server Failover-Cluster (WSFC) unterstützt, verfügt ein Linux-basierter FCI nur über eine einzige Instanz. Diese eine Instanz ist zudem eine Standardinstanz. Es gibt kein Konzept für eine benannten Instanz unter Linux.

Wenn Corosync verwendet wird, kann ein Pacemaker-Cluster nur bis zu 16 Knoten enthalten, sodass eine einzelne FCI bis zu 16 Server umfassen kann. Eine mit der Standard Edition von SQL Server implementierte FCI unterstützt bis zu zwei Knoten eines Clusters, auch wenn der Pacemaker-Cluster über die maximal möglichen 16 Knoten verfügt.

Die SQL Server-Instanz in einer SQL Server-FCI ist nur auf einem der beiden Knoten aktiv.

IP-Adresse und Name

In einem Linux Pacemaker-Cluster benötigt jede SQL Server-FCI eine eigene eindeutige IP-Adresse und einen eigenen Namen. Wenn die FCI-Konfiguration mehrere Subnetze umfasst, ist eine IP-Adresse pro Subnetz erforderlich. Der eindeutige Name und die IP-Adressen werden für den Zugriff auf die FCI verwendet, damit Anwendungen und Endbenutzer nicht wissen müssen, welcher Server dem Pacemaker-Cluster zugrunde liegt.

Der Name der FCI in DNS muss mit dem Namen der FCI-Ressource übereinstimmen, die im Pacemaker-Cluster erstellt wird. Sowohl der Name als auch die IP-Adresse müssen in DNS registriert werden.

Freigegebener Speicher

Alle FCIs benötigen unabhängig davon, ob sie unter Linux oder Windows Server ausgeführt werden, einen freigegebenen Speicher. Dieser Speicher wird allen Servern präsentiert, die die FCI hosten können, aber nur ein einziger Server kann den Speicher jederzeit für die FCI verwenden. Für den freigegebenen Speicher unter Linux sind folgende Optionen verfügbar:

  • iSCSI
  • Network File System (NFS)
  • SMB (Server Message Block): Unter Windows Server gibt es etwas andere Optionen. Eine Option, die derzeit für Linux-basierte FCIS nicht unterstützt wird, ist die Möglichkeit, für tempdb einen für den Knoten lokalen Datenträger zu verwenden, bei dem es sich um den temporären Arbeitsbereich von SQL Server handelt.

In einer Konfiguration, die mehrere Standorte umfasst, muss das, was in einem Rechenzentrum gespeichert wird, mit dem anderen synchronisiert werden. Bei einem Failovers kann die FCI online geschaltet werden, und der Speicher wird als identisch betrachtet. Hierfür ist eine externe Methode für die Speicherreplikation erforderlich, und zwar unabhängig davon, ob dies über die zugrunde liegende Speicherhardware oder ein softwarebasiertes Dienstprogramm erfolgt.

Hinweis

Bei SQL Server müssen Linux-basierte Bereitstellungen, in denen Datenträger verwendet werden, die einem Server direkt präsentiert werden, mit XFS oder EXT4 formatiert werden. Andere Dateisysteme werden derzeit nicht unterstützt. Sämtliche Änderungen werden hier berücksichtigt.

Der Prozess für die Präsentation von freigegebenem Speicher ist für die verschiedenen unterstützten Methoden identisch:

  • Konfigurieren des freigegebenen Speichers
  • Einbinden des Speichers als Ordner auf den Servern, die als Knoten des Pacemaker-Clusters für die FCI dienen sollen
  • Ggf. Verschieben der SQL Server-Systemdatenbanken in den freigegebenen Speicher
  • Testen, ob SQL Server über alle mit dem freigegebenen Speicher verbundenen Server funktioniert

Ein wesentlicher Unterschied bei SQL Server für Linux besteht darin, dass die Systemdatenbanken während der Konfiguration der standardmäßigen Benutzerdaten und des Speicherorts für die Protokolldatei immer unter /var/opt/mssql/data vorhanden sein müssen. Unter Windows Server haben Sie die Möglichkeit, die Systemdatenbanken sowie tempdb zu verschieben. Dieser Umstand spielt bei der Konfiguration des freigegebenen Speichers für eine FCI eine Rolle.

Die Standardpfade für systemfremde Datenbanken können mithilfe des Hilfsprogramms mssql-conf geändert werden. Informationen zum Ändern der Standardeinstellungen finden Sie unter Ändern des Speicherorts für das Datenbankdateien- oder Protokollverzeichnis. Sofern Sie über die richtigen Sicherheitseinstellungen verfügen, können Sie SQL Server-Daten und -Transaktionen auch an anderen Speicherorten speichern, selbst dann, wenn es sich nicht um einen Standardspeicherort handelt. Der Speicherort muss dann angegeben werden.

Zugehöriger Inhalt