Microsoft SQL Failover-Cluster: iSCSI Server

Mit dieser Tutorialreihe möchte ich Schritt für Schritt einen Microsoft SQL Failover-Cluster aus dem Boden stampfen. Du befindest dich dabei beim zweiten Artikel zu dieser Reihe, falls du Part 1 noch nicht gelesen hast, würde ich dir folgenden Post ans Herz legen: Microsoft SQL Failover-Cluster: Einführung. Im zweiten Teil möchte ich die Grundlagen für den Cluster schaffen und das steht ganz im Zeichen des Shared Storages. Die Datenbank, sowie die Logs müssen auf einem zentralen Speicherort liegen, welcher im Failover-Fall in wenigen Sekunden auf einen anderen Node geswitcht werden kann. Dabei gibt es verschiedenste Ansätze, welche man dafür verfolgen kann:

• FibreChannel: Ein abgekoppeltes Storage-Network, welches aus eigener Hardware (FibreCables, Switches, NICs,..) besteht und dementsprechend kostenintensiv ist. Die Daten werden nicht über das gewöhnliche LAN per TCP/IP übertragen, sondern über ein FC-SAN.
• iSCSI: Die Daten des „Internet Small Computer System Interface“ werden hingegen über das herkömmliche TCP/IP Netzwerk geschickt. Durch 10GBit NICs kann zu günstigeren Anschaffungskosten ein sehr gutes Ergebnis erzielt werden.

In unserem Fall möchten wir uns auf die Variante 2, dem iSCSI Target/Initiator System stützen. Das Target entspricht dabei dem Server und der Client wird Initiator genannt – ein typisches Client/Server Verfahren.

iSCSI Target Server

Netzwerk konfigurieren

Wir bereits in der Einführung aufgeführt, brauchen wir für diese Zwecke einen Windows Server, welcher optional bereits einer AD-Domäne gejoint ist. Außerdem möchten wir das LAN vom iSCSI Netzwerk trennen. Das hat zum einen Sicherheitsvorteile, zum anderen können wir die beiden Netzwerke physisch auf verschiedene Netzwerkkarten legen und damit die Last optimal verteilen. Auch würde somit ein stärker ausgelastetes LAN die Funktion des Clusters nicht beeinträchtigen.

Im folgenden Bild wurden beide NICs bereits korrekt konfiguriert.

iSCSI Rolle installieren

Damit der Fileserver auch iSCSI LUNs an Clients ausliefern kann, muss zuvor die entsprechende Windows Rolle installiert werden. Dies kann einerseits über den Server-Manager passieren, oder man benutzt den nachfolgenden Powershelll-Befehl.

Install-WindowsFeature -Name FS-iSCSITarget-Server

Der Server muss nach der erfolgreichen Installation nicht neugestartet werden und wir können direkt zum nächsten Schritt übergehen.

iSCSI Target & LUNs erstellen

Für unseren SQL-Cluster benötigen wir ein Target und drei verschiedene LUNs (Logical Unit Number = Disks). Das Target scheint dem Client (Initiator) dabei als Endpunkt auf, welcher die damit verbundenen LUNs ausliefert. Folgende Disks werden für den Failover-Cluster benötigt:

• Quorum: Um zu verstehen, warum man eine sogenannte Quorum-Disk benötigt, muss man zuerst die Funktionsweise eines Clusters verstehen. Ein Cluster und der damit verbundene aktive Node, wird aufgrund einer Mehrheitsentscheidung betrieben. Man stelle sich vor, der Cluster besteht aus zwei Nodes. Solange beide Server aktiv miteinander sprechen können, ist alles in Ordnung. Doch was passiert, wenn die Cluster untereinander die Verbindung verlieren und nicht mehr miteinander kommunizieren können? Jeder Node würde für sich denken, dass der jeweils Andere nicht mehr funktionstüchtig ist und würde einen Failover einleiten und die Shared Disks, sowie die Applikation hosten wollen. Das würde in einem Chaos enden und die Applikation zwangsläufig nicht mehr erreichbar sein. Aus diesem Grund gibt es die Quorum-Disk – diese entscheidet in so einem Fall, welcher Server der aktive Node ist. Jener Server, der das Quorum gemountet hat, darf die Applikation hosten. Falls Ihr etwas tiefer in die Materie eintauchen wollt, kann ich den Microsoft Docs Artikel zu diesem Thema empfehlen.
• Database: Auf dieser Disk wird die SQL-Datenbank gehostet.
• Logs: Auf dieser Disk werden die SQL-Logs gelagert.

Zum Konfigurieren können wir wieder den Weg über den Server-Manager oder die Powershell wählen.

Die Virtual Disks sollten, wenn möglich, auf einer eigenen, leistungsstarken Disk oder zumindest auf einer weiteren Partition abgelegt werden. Im nächsten Fenster vergeben wir den Namen des LUNs, in unserem Fall also „Quorum“.

Beim Anlegen der VHDX haben wir drei Auswahlmöglichkeiten, wobei „Fixed Size“ und „Dynamically expanding“ für uns relevant sind:

• Fixed Size: Beansprucht sofort den gesamten Speicherplatz der Disk. Legt man ein LUN mit einer Größe von beispielsweise 500GB an, werden diese 500GB auf der darunterliegenden Partition sofort reserviert. Der Vorteil dieser Variante liegt in der besseren Performance.
• Dynamically expanding: Das LUN besetzt auf der Partition nur den tatsächlich benutzten Speicher. Legt man eine Disk mit 500GB an, speichert allerdings nur 45GB an Daten darauf, werden nur 45GB belegt.

Da eine SQL Applikation sehr performant arbeitet, legen wir alle LUNs als „Fixed Size“ mit folgenden Größen an:

• Quorum: 500MB
• SQL-DB: 10GB (je nach Bedarf)
• SQL-Log: 10GB (je nach Bedarf)

Anschließend muss ein neues iSCSI Target erstellt werden. Dazu vergeben wir den Namen „mssql-target01“, eine Description kann optional hinzugefügt werden.

Im nächsten und vorerst letzten Schritt, müssen wir noch die Clients, welche später auf das Target Zugriff haben sollen, freischalten. Dazu können wir die Initiatoren einfach über das angebundene Active-Directory suchen und hinzufügen. Wird kein AD verwendet, können die Clients auch mithilfe des iSCSI Qualified Names (IQN) hinzugefügt werden. Wir man diese ID herausfindet, erkläre ich im Bereich „iSCSI Initiator-IDs hinzufügen„.

Eine Authentifizierung in Richtung CHAP wird nicht benötigt, daher können wir die letzten zwei Seiten bestätigen und das LUN, sowie das Target anlegen. Diese Schritte müssen zwei weitere Male für die SQL-Datenbank und SQL-Log LUNs ausgeführt werden. Nur legt man dafür nicht jedes mal ein eigenes iSCSI-Target an, sondern benutzt das zuvor angelegte „mssql-target01“.

Der gleiche Prozess kann, wie bereits erwähnt, auch über die Shell mit verschiedenen CMDLETS ausgeführt werden. Folgende Befehle würden das gleiche Ergebnis hervorrufen:

#Create a new iSCSI Target
New-IscsiServerTarget -TargetName mssql-target01

#Check the current configuration of the iSCSI Target
Get-IscsiTargetServerSetting

#Remove the LAN NIC - only the iSCSI network should be available for iSCSI traffic
Set-IscsiTargetServerSetting -IP 192.168.50.10 -Enable $false

#Create three fixed-size iSCSI LUNs (Quorum, Database and Logs)
New-IscsiVirtualDisk -Path D:\iSCSI\mssql_quorum.vhdx -Size 500MB -Fixed
New-IscsiVirtualDisk -Path D:\iSCSI\mssql_db.vhdx -Size 10GB -Fixed
New-IscsiVirtualDisk -Path D:\iSCSI\mssql_logs.vhdx -Size 10GB -Fixed

#Add all LUNs to the iSCSI target
Add-IscsiVirtualDiskTargetMapping -TargetName mssql-target01 -Path D:\iSCSI\mssql_quorum.vhdx
Add-IscsiVirtualDiskTargetMapping -TargetName mssql-target01 -Path D:\iSCSI\mssql_db.vhdx
Add-IscsiVirtualDiskTargetMapping -TargetName mssql-target01 -Path D:\iSCSI\mssql_logs.vhdx

iSCSI Initiator-IDs hinzufügen

Folgende Schritte müssen nur ausgeführt werden, wenn die Clients zuvor nicht mithilfe des ADs eingebunden werden konnten:
Somit hätten wir bereits einen Windows iSCSI Server aufgebaut. Ein letzter Schritt fehlt uns noch und zwar die Initiatoren – also die Clients. Denn nicht jeder Client darf mit dem iSCSI Target eine Verbindung aufbauen. Die jeweilige Initiator-ID muss zuvor am Client bestimmt und in die Config des Servers aufgenommen werden. Dazu ruft man den „iSCSI Initiator“ am Client über den Server-Manager auf und kopiert den Namen im Reiter „Configuration“.

Mithilfe folgender Powershell Befehle können die IQNs am iSCSI Target Server eingebunden werden:

Set-IscsiServerTarget -TargetName mssql_target01 -InitiatorIds IQN:iqn.1991-05.com.microsoft:mssql01.test.local
Set-IscsiServerTarget -TargetName mssql_target01 -InitiatorIds IQN:iqn.1991-05.com.microsoft:mssql01.test.local

Möchte man nicht den Weg der Shell nutzen, lässt sich das natürlich auch noch per Server-Manager und GUI lösen. Dazu müssen vom iSCSI Target die Eigenschaften geöffnet werden und im Reiter „Initiators“ lassen sich die zuvor kopieren IQNs einfügen.

Somit haben wir die Vorbereitung seitens des Shared Storages getroffen und können im nächsten Teil auf die Konfiguration des Failover-Clusters eingehen.