Tutorial: Konfigurieren von Verfügbarkeitsgruppen für SQL Server auf SLES-VMs in Azure

Artikel
12/06/2023

Hinweis

In diesem Tutorial verwenden wir SQL Server 2022 (16.x) mit SUSE Linux Enterprise Server (SLES) v15. Es ist aber auch möglich, SQL Server 2019 (15.x) mit SLES v12 oder SLES v15 zum Konfigurieren von Hochverfügbarkeit zu verwenden.

In diesem Tutorial lernen Sie Folgendes:

Erstellen einer neuen Ressourcengruppe, einer Verfügbarkeitsgruppe und eines virtuellen Linux-Computers
Aktivieren von Hochverfügbarkeit (High Availability, HA)
Erstellen eines Pacemaker-Clusters
Konfigurieren eines Fencing-Agents durch Erstellen eines STONITH-Geräts
Installieren von SQL Server und „mssql-tools“ unter SLES
Konfigurieren einer SQL Server-Always On-Verfügbarkeitsgruppe
Konfigurieren von Verfügbarkeitsgruppenressourcen im Pacemaker-Cluster
Testen von Failover und Fencing-Agent

In diesem Tutorial wird die Azure CLI verwendet, um Ressourcen in Azure bereitzustellen.

Wenn Sie kein Azure-Abonnement besitzen, können Sie ein kostenloses Konto erstellen, bevor Sie beginnen.

Voraussetzungen

Verwenden Sie die Bash-Umgebung in Azure Cloud Shell. Weitere Informationen finden Sie unter Schnellstart für Bash in Azure Cloud Shell.
Wenn Sie CLI-Referenzbefehle lieber lokal ausführen, installieren Sie die Azure CLI. Wenn Sie Windows oder macOS ausführen, sollten Sie die Azure CLI in einem Docker-Container ausführen. Weitere Informationen finden Sie unter Ausführen der Azure CLI in einem Docker-Container.
- Wenn Sie eine lokale Installation verwenden, melden Sie sich mithilfe des Befehls az login bei der Azure CLI an. Führen Sie die in Ihrem Terminal angezeigten Schritte aus, um den Authentifizierungsprozess abzuschließen. Informationen zu anderen Anmeldeoptionen finden Sie unter Anmelden mit der Azure CLI.
- Installieren Sie die Azure CLI-Erweiterung beim ersten Einsatz, wenn Sie dazu aufgefordert werden. Weitere Informationen zu Erweiterungen finden Sie unter Verwenden von Erweiterungen mit der Azure CLI.
- Führen Sie az version aus, um die installierte Version und die abhängigen Bibliotheken zu ermitteln. Führen Sie az upgrade aus, um das Upgrade auf die aktuelle Version durchzuführen.

Für diesen Artikel ist mindestens Version 2.0.30 der Azure CLI erforderlich. Bei Verwendung von Azure Cloud Shell ist die aktuelle Version bereits installiert.

Erstellen einer Ressourcengruppe

Sollten Sie über mehrere Abonnements verfügen, legen Sie das Abonnement fest, für das Sie diese Ressourcen bereitstellen möchten.

Verwenden Sie den folgenden Befehl, um eine Ressourcengruppe (<resourceGroupName>) in einer Region zu erstellen. Ersetzen Sie <resourceGroupName> durch einen Namen Ihrer Wahl. In diesem Tutorial wird East US 2 verwendet. Weitere Informationen finden Sie in dieser Schnellstartanleitung.

az group create --name <resourceGroupName> --location eastus2

Verfügbarkeitsgruppe erstellen

Im nächsten Schritt wird eine Verfügbarkeitsgruppe erstellt. Führen Sie in Azure Cloud Shell den folgenden Befehl aus, und ersetzen Sie dabei <resourceGroupName> durch den Namen Ihrer Ressourcengruppe. Wählen Sie einen Namen für <availabilitySetName> aus.

az vm availability-set create \
    --resource-group <resourceGroupName> \
    --name <availabilitySetName> \
    --platform-fault-domain-count 2 \
    --platform-update-domain-count 2

Die Ergebnisse des abgeschlossenen Befehls sollten wie folgt aussehen:

{
  "id": "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Compute/availabilitySets/<availabilitySetName>",
  "location": "eastus2",
  "name": "<availabilitySetName>",
  "platformFaultDomainCount": 2,
  "platformUpdateDomainCount": 2,
  "proximityPlacementGroup": null,
  "resourceGroup": "<resourceGroupName>",
  "sku": {
    "capacity": null,
    "name": "Aligned",
    "tier": null
  },
  "statuses": null,
  "tags": {},
  "type": "Microsoft.Compute/availabilitySets",
  "virtualMachines": []
}

Erstellen eines virtuellen Netzwerks und des Subnetzes

Erstellen Sie ein benanntes Subnetz mit einem vorab zugewiesenen IP-Adressbereich. Ersetzen Sie diese Werte im folgenden Befehl:
- <resourceGroupName>
- <vNetName>
- <subnetName>
```
az network vnet create \
    --resource-group <resourceGroupName> \
    --name <vNetName> \
    --address-prefix 10.1.0.0/16 \
    --subnet-name <subnetName> \
    --subnet-prefix 10.1.1.0/24
```
Der obige Befehl erstellt ein VNet und ein Subnetz mit einem benutzerdefinierten IP-Adressbereich.

Erstellen von SLES-VMs in der Verfügbarkeitsgruppe

Rufen Sie eine Liste der VM-Images ab, die SLES v15 SP4 mit BYOS (Bring Your Own Subscription) bieten. Sie können auch die SUSE Enterprise Linux 15 SP4+-Patching-VM (sles-15-sp4-basic) verwenden.

az vm image list --all --offer "sles-15-sp3-byos"
# if you want to search the basic offers you could search using the command below
az vm image list --all --offer "sles-15-sp3-basic"

Die folgenden Ergebnisse sollten angezeigt werden, wenn Sie nach den BYOS-Images suchen:

[
   {
      "offer": "sles-15-sp3-byos",
      "publisher": "SUSE",
      "sku": "gen1",
      "urn": "SUSE:sles-15-sp3-byos:gen1:2022.05.05",
      "version": "2022.05.05"
   },
   {
      "offer": "sles-15-sp3-byos",
      "publisher": "SUSE",
      "sku": "gen1",
      "urn": "SUSE:sles-15-sp3-byos:gen1:2022.07.19",
      "version": "2022.07.19"
   },
   {
      "offer": "sles-15-sp3-byos",
      "publisher": "SUSE",
      "sku": "gen1",
      "urn": "SUSE:sles-15-sp3-byos:gen1:2022.11.10",
      "version": "2022.11.10"
   },
   {
      "offer": "sles-15-sp3-byos",
      "publisher": "SUSE",
      "sku": "gen2",
      "urn": "SUSE:sles-15-sp3-byos:gen2:2022.05.05",
      "version": "2022.05.05"
   },
   {
      "offer": "sles-15-sp3-byos",
      "publisher": "SUSE",
      "sku": "gen2",
      "urn": "SUSE:sles-15-sp3-byos:gen2:2022.07.19",
      "version": "2022.07.19"
   },
   {
      "offer": "sles-15-sp3-byos",
      "publisher": "SUSE",
      "sku": "gen2",
      "urn": "SUSE:sles-15-sp3-byos:gen2:2022.11.10",
      "version": "2022.11.10"
   }
]

In diesem Tutorial wird SUSE:sles-15-sp3-byos:gen1:2022.11.10 verwendet.

Wichtig

Computernamen müssen weniger als 15 Zeichen lang sein, damit eine Verfügbarkeitsgruppe eingerichtet werden kann. Benutzernamen dürfen keine Großbuchstaben enthalten, und Kennwörter müssen zwischen 12 und 72 Zeichen lang sein.

Erstellen Sie drei VMs in der Verfügbarkeitsgruppe. Ersetzen Sie diese Werte im folgenden Befehl:

<resourceGroupName>
<VM-basename>
<availabilitySetName>
<VM-Size>: Ein Beispiel wäre etwa „Standard_D16s_v3“.
<username>
<adminPassword>
<vNetName>
<subnetName>

for i in `seq 1 3`; do
    az vm create \
       --resource-group <resourceGroupName> \
       --name <VM-basename>$i \
       --availability-set <availabilitySetName> \
       --size "<VM-Size>" \
       --os-disk-size-gb 128 \
       --image "SUSE:sles-15-sp3-byos:gen1:2022.11.10" \
       --admin-username "<username>" \
       --admin-password "<adminPassword>" \
       --authentication-type all \
       --generate-ssh-keys \
       --vnet-name "<vNetName>" \
       --subnet "<subnetName>" \
       --public-ip-sku Standard \
       --public-ip-address ""
    done

Der obige Befehl erstellt die VMs mithilfe des zuvor definierten VNet. Weitere Informationen zu den verschiedenen Konfigurationen finden Sie im Artikel zu „az vm create“.

Der Befehl enthält auch den Parameter --os-disk-size-gb zum Erstellen einer benutzerdefinierten Laufwerkgröße für das Betriebssystem von 128 GB. Wenn Sie diesen Größenwert später erhöhen, erweitern Sie die entsprechenden Ordnervolumes für Ihre Installation, und konfigurieren Sie den Logical Volume Manager (LVM).

Nach Abschluss des Befehls für die einzelnen virtuellen Computer sollten die Ergebnisse in etwa wie folgt aussehen:

{
  "fqdns": "",
  "id": "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Compute/virtualMachines/sles1",
  "location": "westus",
  "macAddress": "<Some MAC address>",
  "powerState": "VM running",
  "privateIpAddress": "<IP1>",
  "resourceGroup": "<resourceGroupName>",
  "zones": ""
}

Testen der Verbindung mit den erstellten virtuellen Computern

Stellen Sie mithilfe des folgenden Befehls in Azure Cloud Shell eine Verbindung mit jeder VM her. Sollten Sie die IP-Adressen Ihrer VMs nicht finden, lesen Sie diese Schnellstartanleitung zu Azure Cloud Shell.

ssh <username>@<publicIPAddress>

Nach erfolgreicher Verbindungsherstellung sollte die folgende Ausgabe (Linux-Terminal) angezeigt werden:

[<username>@sles1 ~]$

Geben Sie exit ein, um die SSH-Sitzung zu verlassen.

Registrieren bei SUSEConnect und Installieren von Hochverfügbarkeitspaketen

Um dieses Tutorial abzuschließen, müssen Ihre VMs bei SUSEConnect registriert sein, damit sie Updates und Support erhalten. Anschließend können Sie das Modul mit der Hochverfügbarkeitserweiterung oder ein Musterinstallieren, bei dem es sich um eine Reihe von Paketen handelt, die Hochverfügbarkeit ermöglichen.

Es ist einfacher, auf allen VMs (Knoten) gleichzeitig eine SSH-Sitzung zu öffnen, da für den gesamten Artikel alle Befehle auf jeder VM ausgeführt werden müssen.

Wenn Sie mehrere sudo-Befehle kopieren und einfügen und zur Eingabe eines Kennworts aufgefordert werden, werden die weiteren Befehle nicht ausgeführt. Führen Sie die Befehle jeweils separat aus.

Stellen Sie eine Verbindung mit jedem VM-Knoten her, um die folgenden Schritte auszuführen.

Registrieren der VM bei SUSEConnect

Um Ihren VM-Knoten bei SUSEConnect zu registrieren, ersetzen Sie diese Werte im folgenden Befehl auf allen Knoten:

<subscriptionEmailAddress>
<registrationCode>

sudo SUSEConnect
    --url=https://scc.suse.com
    -e <subscriptionEmailAddress> \
    -r <registrationCode>

Installieren der Hochverfügbarkeitserweiterung

Führen Sie zum Installieren der Hochverfügbarkeitserweiterung den folgenden Befehl auf allen Knoten aus:

sudo SUSEConnect -p sle-ha/15.3/x86_64 -r <registration code for Partner Subscription for High Availability Extension>

Konfigurieren des kennwortlosen SSH-Zugriffs zwischen Knoten

Der kennwortlose SSH-Zugriff ermöglicht es Ihren VMs, mithilfe öffentlicher SSH-Schlüssel miteinander zu kommunizieren. Sie müssen SSH-Schlüssel auf jedem Knoten konfigurieren und diese Schlüssel auf jeden Knoten kopieren.

Generieren neuer SSH-Schlüssel

Die erforderliche SSH-Schlüsselgröße beträgt 4.096 Bit. Wechseln Sie auf jeder VM zum Ordner /root/.ssh, und führen Sie den folgenden Befehl aus:

ssh-keygen -t rsa -b 4096

In diesem Schritt werden Sie möglicherweise aufgefordert, eine vorhandene SSH-Datei zu überschreiben. Sie müssen dieser Aufforderung zustimmen. Sie müssen keine Passphrase eingeben.

Kopieren der öffentlichen SSH-Schlüssel

Sie müssen den öffentlichen Schlüssel von dem gerade erstellten Knoten mithilfe des Befehls ssh-copy-id auf jede VM kopieren. Wenn Sie das Zielverzeichnis auf der Ziel-VM angeben möchten, können Sie den Parameter -i verwenden.

Im folgenden Befehl kann das Konto <username> das gleiche Konto sein, das Sie beim Erstellen der VM für jeden Knoten konfiguriert haben. Sie können auch das Konto root verwenden, aber dies wird in einer Produktionsumgebung nicht empfohlen.

sudo ssh-copy-id <username>@sles1
sudo ssh-copy-id <username>@sles2
sudo ssh-copy-id <username>@sles3

Überprüfen des kennwortlosen Zugriffs von jedem Knoten aus

Um sich zu vergewissern, dass der öffentliche SSH-Schlüssel auf jeden Knoten kopiert wurde, verwenden Sie den Befehl ssh auf dem jedem Knoten. Wenn Sie die Schlüssel ordnungsgemäß kopiert haben, werden Sie nicht zur Eingabe eines Kennworts aufgefordert, und die Verbindung wurde erfolgreich hergestellt.

In diesem Beispiel stellen wir von der ersten VM (sles1) aus eine Verbindung mit dem zweiten und dritten Knoten her. Auch hier kann das Konto <username> das gleiche Konto sein, das Sie beim Erstellen der VM für jeden Knoten konfiguriert haben.

ssh <username>@sles2
ssh <username>@sles3

Wiederholen Sie diesen Vorgang auf allen drei Knoten, damit jeder Knoten mit den anderen kommunizieren kann, ohne Kennwörter zu benötigen.

Konfigurieren der Namensauflösung

Sie können die Namensauflösung entweder mithilfe von DNS oder durch manuelles Bearbeiten der Datei etc/hosts auf jedem Knoten konfigurieren.

Weitere Informationen zu DNS und Active Directory finden Sie unter Verknüpfen eines Hosts für SQL Server für Linux mit einer Active Directory-Domäne.

Wichtig

Es empfiehlt sich, im vorherigen Beispiel Ihre private IP-Adresse zu verwenden. Mit der öffentlichen IP-Adresse wäre die Einrichtung in dieser Konfiguration nicht erfolgreich, und Ihre VM wäre über externe Netzwerke zugänglich.

In diesem Beispiel werden die folgenden VMs und ihre zugehörigen IP-Adressen verwendet:

sles1: 10.0.0.85
sles2: 10.0.0.86
sles3: 10.0.0.87

Konfigurieren des Clusters

In diesem Tutorial ist Ihre erste VM (sles1) node 1, Ihre zweite VM (sles2) node 2und Ihre dritte VM (sles3) node 3. Weitere Informationen zur Clusterinstallation finden Sie unter Einrichten von Pacemaker unter SUSE Linux Enterprise Server in Azure.

Clusterinstallation

Führen Sie den folgenden Befehl aus, um das Paket ha-cluster-bootstrap auf „node 1“ zu installieren, und starten Sie dann den Knoten neu. In diesem Beispiel ist dies die VM sles1.

sudo zypper install ha-cluster-bootstrap

Führen Sie nach dem Neustart des Knotens den folgenden Befehl aus, um den Cluster bereitzustellen:

sudo crm cluster init --name sqlcluster

Es wird eine ähnliche Ausgabe wie das folgende Beispiel angezeigt:

Do you want to continue anyway (y/n)? y
  Generating SSH key for root
  The user 'hacluster' will have the login shell configuration changed to /bin/bash
Continue (y/n)? y
  Generating SSH key for hacluster
  Configuring csync2
  Generating csync2 shared key (this may take a while)...done
  csync2 checking files...done
  Detected cloud platform: microsoft-azure

Configure Corosync (unicast):
  This will configure the cluster messaging layer.  You will need
  to specify a network address over which to communicate (default
  is eth0's network, but you can use the network address of any
  active interface).

  Address for ring0 [10.0.0.85]
  Port for ring0 [5405]

Configure SBD:
  If you have shared storage, for example a SAN or iSCSI target,
  you can use it avoid split-brain scenarios by configuring SBD.
  This requires a 1 MB partition, accessible to all nodes in the
  cluster.  The device path must be persistent and consistent
  across all nodes in the cluster, so /dev/disk/by-id/* devices
  are a good choice.  Note that all data on the partition you
  specify here will be destroyed.

Do you wish to use SBD (y/n)? n
WARNING: Not configuring SBD - STONITH will be disabled.
  Hawk cluster interface is now running. To see cluster status, open:
    https://10.0.0.85:7630/
  Log in with username 'hacluster', password 'linux'
WARNING: You should change the hacluster password to something more secure!
  Waiting for cluster..............done
  Loading initial cluster configuration

Configure Administration IP Address:
  Optionally configure an administration virtual IP
  address. The purpose of this IP address is to
  provide a single IP that can be used to interact
  with the cluster, rather than using the IP address
  of any specific cluster node.

Do you wish to configure a virtual IP address (y/n)? y
  Virtual IP []10.0.0.89
  Configuring virtual IP (10.0.0.89)....done

Configure Qdevice/Qnetd:
  QDevice participates in quorum decisions. With the assistance of
  a third-party arbitrator Qnetd, it provides votes so that a cluster
  is able to sustain more node failures than standard quorum rules
  allow. It is recommended for clusters with an even number of nodes
  and highly recommended for 2 node clusters.

Do you want to configure QDevice (y/n)? n
Done (log saved to /var/log/crmsh/ha-cluster-bootstrap.log)

Überprüfen Sie den Status des Clusters auf node 1 mit dem folgenden Befehl:
```
sudo crm status
```
Die Ausgabe sollte den folgenden Text enthalten, wenn sie erfolgreich war:
```
1 node configured
1 resource instance configured
```
Ändern Sie mit dem folgenden Befehl das Kennwort für hacluster auf allen Knoten in eine sicherere Zeichenfolge. Sie müssen auch Ihr Benutzerkennwort root für ändern:
```
sudo passwd hacluster
```
```
sudo passwd root
```

Führen Sie den folgenden Befehl auf node 2 und node 3 aus, um zuerst das Paket crmsh zu installieren:

sudo zypper install crmsh

Führen Sie jetzt den Befehl aus, um die Knoten in den Cluster einzubinden:

sudo crm cluster join

Hier sehen einige der Interaktionen, die Sie erwarten können:

Join This Node to Cluster:
You will be asked for the IP address of an existing node, from which
configuration will be copied.  If you have not already configured
passwordless ssh between nodes, you will be prompted for the root
password of the existing node.

  IP address or hostname of existing node (e.g.: 192.168.1.1) []10.0.0.85
  Configuring SSH passwordless with root@10.0.0.85
  root@10.0.0.85's password:
  Configuring SSH passwordless with hacluster@10.0.0.85
  Configuring csync2...done
Merging known_hosts
WARNING: scp to sles2 failed (Exited with error code 1, Error output: The authenticity of host 'sles2 (10.1.1.5)' can't be established.
ECDSA key fingerprint is SHA256:UI0iyfL5N6X1ZahxntrScxyiamtzsDZ9Ftmeg8rSBFI.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
lost connection
), known_hosts update may be incomplete
Probing for new partitions...done
  Address for ring0 [10.0.0.86]

Hawk cluster interface is now running. To see cluster status, open:
    https://10.0.0.86:7630/
  Log in with username 'hacluster', password 'linux'
WARNING: You should change the hacluster password to something more secure!
Waiting for cluster.....done
Reloading cluster configuration...done
  Done (log saved to /var/log/crmsh/ha-cluster-bootstrap.log)

Wenn alle VMs in den Cluster eingebunden sind, überprüfen Sie Ihre Ressource, um festzustellen, ob alle VMs online sind:

sudo crm status

Die folgende Ausgabe wird angezeigt:

Stack: corosync
 Current DC: sles1 (version 2.0.5+20201202.ba59be712-150300.4.30.3-2.0.5+20201202.ba59be712) - partition with quorum
 Last updated: Mon Mar  6 18:01:17 2023
 Last change:  Mon Mar  6 17:10:09 2023 by root via cibadmin on sles1

3 nodes configured
1 resource instance configured

Online: [ sles1 sles2 sles3 ]

Full list of resources:

 admin-ip       (ocf::heartbeat:IPaddr2):       Started sles1

Installieren Sie die Clusterressourcenkomponente. Führen Sie den folgenden Befehl auf allen Knoten aus.
```
sudo zypper in socat
```
Installieren Sie die azure-lb-Komponente. Führen Sie den folgenden Befehl auf allen Knoten aus.
```
sudo zypper in resource-agents
```
Konfigurieren des Betriebssystems. Führen Sie die folgenden Schritte auf allen Knoten aus.
1. Bearbeiten Sie die Konfigurationsdatei:
```
sudo vi /etc/systemd/system.conf
```
2. Ändern Sie den Wert von DefaultTasksMax zu 4096:
```
#DefaultTasksMax=512
DefaultTasksMax=4096
```
3. Speichern Sie die Datei, und beenden Sie den vi-Editor.
4. Führen Sie zum Aktivieren dieser Einstellung den folgenden Befehl aus:
```
sudo systemctl daemon-reload
```
5. Testen Sie, ob die Änderung erfolgreich war:
```
sudo systemctl --no-pager show | grep DefaultTasksMax
```
Reduzieren Sie die Größe des Änderungscaches. Führen Sie die folgenden Schritte auf allen Knoten aus.
1. Bearbeiten Sie die Konfigurationsdatei der Systemsteuerung:
```
sudo vi /etc/sysctl.conf
```
2. Fügen Sie der Datei die folgenden beiden Zeilen hinzu:
```
vm.dirty_bytes = 629145600
vm.dirty_background_bytes = 314572800
```
3. Speichern Sie die Datei, und beenden Sie den vi-Editor.

Installieren Sie das Azure Python SDK mit den folgenden Befehlen auf allen Knoten:

sudo zypper install fence-agents
# Install the Azure Python SDK on SLES 15 or later:
# You might need to activate the public cloud extension first. In this example, the SUSEConnect command is for SLES 15 SP1
SUSEConnect -p sle-module-public-cloud/15.1/x86_64
sudo zypper install python3-azure-mgmt-compute
sudo zypper install python3-azure-identity

Konfigurieren des Fencing-Agents

Ein STONITH-Gerät stellt einen Fencing-Agent bereit. Für dieses Tutorial werden die folgenden Anweisungen geändert. Weitere Informationen finden Sie unter Erstellen eines STONITH-Geräts für den Azure-Fence-Agent.

Überprüfen Sie die Version des Azure-Fence-Agents, um sich zu vergewissern, dass sie aktualisiert wurde. Verwenden Sie den folgenden Befehl:

sudo zypper info resource-agents

Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

Information for package resource-agents:
----------------------------------------
Repository     : SLE-Product-HA15-SP3-Updates
Name           : resource-agents
Version        : 4.8.0+git30.d0077df0-150300.8.37.1
Arch           : x86_64
Vendor         : SUSE LLC <https://www.suse.com/>
Support Level  : Level 3
Installed Size : 2.5 MiB
Installed      : Yes (automatically)
Status         : up-to-date
Source package : resource-agents-4.8.0+git30.d0077df0-150300.8.37.1.src
Upstream URL   : http://linux-ha.org/
Summary        : HA Reusable Cluster Resource Scripts
Description    : A set of scripts to interface with several services
                 to operate in a High Availability environment for both
                 Pacemaker and rgmanager service managers.

Registrieren einer neuen Anwendung in Microsoft Entra ID

Führen Sie die folgenden Schritte aus, um eine neue Anwendung in der Microsoft Entra-ID (vormals Azure Active Directory) zu registrieren:

Wechseln Sie zu https://portal.azure.com.
Öffnen Sie den Bereich Microsoft Entra ID-Eigenschaften, und notieren Sie sich Tenant ID.
Wählen Sie App-Registrierungen aus.
Wählen Sie Neue Registrierung aus.
Geben Sie einen Namen ein (beispielsweise <resourceGroupName>-app). Klicken Sie unter Unterstützte Kontotypen auf Nur Konten in diesem Organisationsverzeichnis (nur Microsoft – einzelner Mandant).
Wählen Sie Web für Umleitungs-URI aus, und geben Sie eine URL ein (z. B. http://localhost) und wählen Sie Hinzufügen aus. Die Anmelde-URL kann eine beliebige gültige URL sein. Wählen Sie anschließend Registrieren aus.
Wählen Sie für Ihre neue App-Registrierung Zertifikate und Geheimnisse und dann Neuer geheimer Clientschlüssel aus.
Geben Sie eine Beschreibung für einen neuen Schlüssel (geheimer Clientschlüssel) ein, und wählen Sie dann Hinzufügen aus.
Notieren Sie sich den Wert des Geheimnisses. Dieser wird als Kennwort für den Dienstprinzipal verwendet.
Wählen Sie Übersicht. Notieren Sie sich die Anwendungs-ID. Sie wird als Benutzername (Anmelde-ID in den folgenden Schritten) des Dienstprinzipals verwendet.

Erstellen einer benutzerdefinierten Rolle für den Fence-Agent

Befolgen Sie die Anleitungen im Tutorial Erstellen einer benutzerdefinierten Azure-Rolle mit der Azure CLI.

Ihre JSON-Datei sollte dem folgenden Beispiel ähneln.

Ersetzen Sie <username> durch einen Namen Ihrer Wahl. Dieser Schritt dient dazu, Duplikate bei der Erstellung der Rollendefinition zu vermeiden.
Ersetzen Sie <subscriptionId> durch Ihre Azure-Abonnement-ID.

{
  "Name": "Linux Fence Agent Role-<username>",
  "Id": null,
  "IsCustom": true,
  "Description": "Allows to power-off and start virtual machines",
  "Actions": [
    "Microsoft.Compute/*/read",
    "Microsoft.Compute/virtualMachines/powerOff/action",
    "Microsoft.Compute/virtualMachines/start/action"
  ],
  "NotActions": [
  ],
  "AssignableScopes": [
    "/subscriptions/<subscriptionId>"
  ]
}

Führen Sie den folgenden Befehl aus, um die Rolle hinzuzufügen:

Ersetzen Sie <filename> durch den Namen der Datei.
Falls Sie den Befehl nicht in dem Ordner ausführen, in dem die Datei gespeichert ist, schließen Sie den Ordnerpfad der Datei in den Befehl ein.

az role definition create --role-definition "<filename>.json"

Die folgende Ausgabe wird angezeigt:

{
  "assignableScopes": [
    "/subscriptions/<subscriptionId>"
  ],
  "description": "Allows to power-off and start virtual machines",
  "id": "/subscriptions/<subscriptionId>/providers/Microsoft.Authorization/roleDefinitions/<roleNameId>",
  "name": "<roleNameId>",
  "permissions": [
    {
      "actions": [
        "Microsoft.Compute/*/read",
        "Microsoft.Compute/virtualMachines/powerOff/action",
        "Microsoft.Compute/virtualMachines/start/action"
      ],
      "dataActions": [],
      "notActions": [],
      "notDataActions": []
    }
  ],
  "roleName": "Linux Fence Agent Role-<username>",
  "roleType": "CustomRole",
  "type": "Microsoft.Authorization/roleDefinitions"
}

Zuweisen der benutzerdefinierten Rolle zum Dienstprinzipal

Weisen Sie dem Dienstprinzipal die benutzerdefinierte Rolle Linux Fence Agent Role-<username> zu, die im letzten Schritt erstellt wurde. Wiederholen Sie diese Schritte für alle Knoten.

Warnung

Verwenden Sie ab hier nicht die Rolle „Besitzer“.

Besuchen Sie https://portal.azure.com.
Öffnen Sie den Bereich Alle Ressourcen.
Wählen Sie den virtuellen Computer des ersten Clusterknotens aus.
Wählen Sie Zugriffssteuerung (IAM) aus.
Wählen Sie Rollenzuweisung hinzufügen aus.
Wählen Sie in der Liste Rolle die Rolle Linux Fence Agent Role-<username> aus.
Behalten Sie für Zugriff zuweisen zu die Standardeinstellung Users, group, or service principal bei.
Geben Sie in der Liste Auswählen den Namen der Anwendung ein, die Sie zuvor erstellt haben, z. B. <resourceGroupName>-app.
Wählen Sie Speichern aus.

Erstellen des STONITH-Geräts

Führen Sie die folgenden Befehle auf node 1 aus:
- Ersetzen Sie <ApplicationID> durch den ID-Wert aus Ihrer Anwendungsregistrierung.
- Ersetzen Sie <servicePrincipalPassword> durch den Wert aus dem geheimen Clientschlüssel.
- Ersetzen Sie <resourceGroupName> durch die Ressourcengruppe aus Ihrem für dieses Tutorial verwendeten Abonnement.
- Ersetzen Sie <tenantID> und <subscriptionId> aus Ihrem Azure-Abonnement.
Führen crm configure Sie aus, um die crm-Eingabeaufforderung zu öffnen:
```
sudo crm configure
```

Führen Sie an der crm-Eingabeaufforderung den folgenden Befehl aus, um die Ressourceneigenschaften zu konfigurieren. Dadurch wird die Ressource rsc_st_azure erstellt, wie im folgenden Beispiel gezeigt:

primitive rsc_st_azure stonith:fence_azure_arm params subscriptionId="subscriptionID" resourceGroup="ResourceGroup_Name" tenantId="TenantID" login="ApplicationID" passwd="servicePrincipalPassword" pcmk_monitor_retries=4 pcmk_action_limit=3 power_timeout=240 pcmk_reboot_timeout=900 pcmk_host_map="sles1:sles1;sles2:sles2;sles3:sles3" op monitor interval=3600 timeout=120
commit
quit

Führen Sie die folgenden Befehle aus, um den Fence-Agent zu konfigurieren:

sudo crm configure property stonith-timeout=900
sudo crm configure property stonith-enabled=true
sudo crm configure property concurrent-fencing=true

Überprüfen Sie den Status Ihres Clusters, um festzustellen, ob STONITH aktiviert wurde:

sudo crm status

Die Ausgabe sollte etwa folgendermaßen aussehen:

Stack: corosync
 Current DC: sles1 (version 2.0.5+20201202.ba59be712-150300.4.30.3-2.0.5+20201202.ba59be712) - partition with quorum
 Last updated: Mon Mar  6 18:20:17 2023
 Last change:  Mon Mar  6 18:10:09 2023 by root via cibadmin on sles1

3 nodes configured
2 resource instances configured

Online: [ sles1 sles2 sles3 ]

Full list of resources:

admin-ip       (ocf::heartbeat:IPaddr2):       Started sles1
rsc_st_azure   (stonith:fence_azure_arm):      Started sles2

Installieren von SQL Server und „mssql-tools“

Im folgenden Abschnitt werden SQL Server und mssql-tools installiert. Weitere Informationen finden Sie unter Installieren von SQL Server unter SUSE Linux Enterprise Server.

Führen Sie diese Schritte auf allen Knoten in diesem Abschnitt aus.

Installieren von SQL Server auf den VMs

Die folgenden Befehle dienen zum Installieren von SQL Server:

Laden Sie die Konfigurationsdatei für das SLES-Repository für Microsoft SQL Server 2019 herunter:
```
sudo zypper addrepo -fc https://packages.microsoft.com/config/sles/15/mssql-server-2022.repo
```
Aktualisieren Sie Ihre Repositorys.
```
sudo zypper --gpg-auto-import-keys refresh
```
Damit sichergestellt ist, dass der Microsoft-Paketsignaturschlüssel auf Ihrem System installiert ist, importieren Sie den Schlüssel mit folgendem Befehl:
```
sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
```
Führen Sie die folgenden Befehle aus, um SQL Server zu installieren:
```
sudo zypper install -y mssql-server
```
Nachdem die Paketinstallation abgeschlossen ist, führen Sie mssql-conf setup aus, und befolgen Sie die Anweisungen, um das Systemadministratorkennwort festzulegen und Ihre Edition auszuwählen.
```
sudo /opt/mssql/bin/mssql-conf setup
```
Hinweis

Stellen Sie sicher, dass Sie ein sicheres Kennwort für das Systemadministratorkonto angeben (minimale Länge von 8 Zeichen, Groß-und Kleinbuchstaben, Ziffern und/oder nicht-alphanumerische Symbole).
Nachdem die Konfiguration abgeschlossen ist, überprüfen Sie, ob der Dienst ausgeführt wird:
```
systemctl status mssql-server
```

Installieren von SQL Server-Befehlszeilentools

Mit den folgenden Schritten installieren Sie die SQL Server-Befehlszeilentools sqlcmd und bcp.

Fügen Sie das Microsoft SQL Server-Repository zu Zypper hinzu.

sudo zypper addrepo -fc https://packages.microsoft.com/config/sles/15/prod.repo

Aktualisieren Sie Ihre Repositorys.

sudo zypper --gpg-auto-import-keys refresh

Installieren Sie mssql-tools mit dem unixODBC-Entwicklerpaket. Weitere Informationen finden Sie unter Installieren des Microsoft-ODBC-Treibers für SQL Server (Linux).
```
sudo zypper install -y mssql-tools unixODBC-devel
```

Zur Vereinfachung können Sie /opt/mssql-tools/bin/ zu Ihrer PATH-Umgebungsvariable hinzufügen. Dadurch können Sie die Tools ausführen, ohne den vollständigen Pfad angeben zu müssen. Führen Sie die folgenden Befehle aus, um den Pfad (PATH) sowohl für Anmeldesitzungen als auch für interaktive Sitzungen oder Sitzungen ohne Anmeldung zu ändern:

echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> ~/.bash_profile
echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> ~/.bashrc
source ~/.bashrc

Installieren des SQL Server-Hochverfügbarkeits-Agents

Führen Sie den folgenden Befehl auf allen Knoten aus, um das Hochverfügbarkeits-Agent-Paket für SQL Server zu installieren:

sudo zypper install mssql-server-ha

Öffnen von Ports für Hochverfügbarkeitsdienste

Sie können die folgenden Firewallports auf allen Knoten für SQL Server und Hochverfügbarkeitsdienste öffnen: 1433, 2224, 3121, 5022, 5405, 21064.

sudo firewall-cmd --zone=public --add-port=1433/tcp --add-port=2224/tcp --add-port=3121/tcp --add-port=5022/tcp --add-port=5405/tcp --add-port=21064 --permanent
sudo firewall-cmd --reload

Konfigurieren einer Verfügbarkeitsgruppe

Führen Sie die folgenden Schritte aus, um eine SQL Server-Always On-Verfügbarkeitsgruppe für Ihre virtuellen Computer zu konfigurieren. Weitere Informationen finden Sie unter Konfigurieren von SQL Server-Always On-Verfügbarkeitsgruppen für Hochverfügbarkeit unter Linux.

Aktivieren von Verfügbarkeitsgruppen und Neustarten von SQL Server

Aktivieren Sie Verfügbarkeitsgruppen auf jedem Knoten, der eine SQL Server-Instanz hostet. Starten Sie den mssql-server-Dienst dann neu. Führen Sie die folgenden Befehle auf jedem Knoten aus:

sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1

sudo systemctl restart mssql-server

Erstellen eines Zertifikats

Microsoft unterstützt keine Active Directory-Authentifizierung beim Endpunkt der Verfügbarkeitsgruppe. Daher müssen wir für die Verschlüsselung des Endpunkts der Verfügbarkeitsgruppe ein Zertifikat verwenden.

Stellen Sie über SQL Server Management Studio (SSMS) oder sqlcmd eine Verbindung mit allen Knoten her. Führen Sie die folgenden Befehle aus, um eine AlwaysOn_health-Sitzung zu aktivieren und einen Hauptschlüssel zu erstellen:

Wichtig

Falls Sie eine Remoteverbindung mit Ihrer SQL Server-Instanz herstellen, muss der Port 1433 in der Firewall geöffnet sein. Außerdem müssen in Ihrer NSG für jeden virtuellen Computer eingehende Verbindungen am Port 1433 zugelassen werden. Weitere Informationen zum Erstellen einer Eingangssicherheitsregel finden Sie unter Erstellen einer Sicherheitsregel.
- Ersetzen Sie <MasterKeyPassword> durch Ihr eigenes Kennwort.
```
ALTER EVENT SESSION AlwaysOn_health ON SERVER
    WITH (STARTUP_STATE = ON);
GO

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<MasterKeyPassword>';
GO
```
Stellen Sie über SSMS oder sqlcmd eine Verbindung mit dem primären Replikat her. Die folgenden Befehle erstellen auf Ihrem primären SQL Server-Replikat ein Zertifikat unter /var/opt/mssql/data/dbm_certificate.cer und einen privaten Schlüssel unter var/opt/mssql/data/dbm_certificate.pvk:
- Ersetzen Sie <PrivateKeyPassword> durch Ihr eigenes Kennwort.
```
CREATE CERTIFICATE dbm_certificate
    WITH SUBJECT = 'dbm';
GO

BACKUP CERTIFICATE dbm_certificate TO FILE = '/var/opt/mssql/data/dbm_certificate.cer'
WITH PRIVATE KEY (
        FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
        ENCRYPTION BY PASSWORD = '<PrivateKeyPassword>'
        );
GO
```

Beenden Sie die sqlcmd-Sitzung mithilfe des Befehls exit, und kehren Sie zu Ihrer SSH-Sitzung zurück.

Kopieren des Zertifikats auf die sekundären Replikate und Erstellen der Zertifikate auf dem Server

Kopieren Sie die beiden erstellten Dateien auf allen Servern, von denen Verfügbarkeitsreplikate gehostet werden, an den gleichen Speicherort.

Führen Sie auf dem primären Server den folgenden scp-Befehl aus, um das Zertifikat auf die Zielserver zu kopieren:
- Ersetzen Sie <username> und sles2 durch den Benutzernamen bzw. den Namen der verwendeten Ziel-VM.
- Führen Sie diesen Befehl für alle sekundären Replikate aus.
Hinweis

Sie müssen nicht sudo -i ausführen, um die Stammumgebung zu erhalten. Sie können den Befehl sudo stattdessen vor jedem Befehl ausführen.
```
# The below command allows you to run commands in the root environment
sudo -i
```
```
scp /var/opt/mssql/data/dbm_certificate.* <username>@sles2:/home/<username>
```
Führen Sie auf dem Zielserver den folgenden Befehl aus:
- Ersetzen Sie <username> durch Ihren Benutzernamen.
- Der Befehl mv verschiebt die Dateien oder das Verzeichnis an einen anderen Ort.
- Der Befehl chown dient zum Ändern des Besitzers und der Gruppe von Dateien, Verzeichnissen oder Links.
- Führen Sie diese Befehle für alle sekundären Replikate aus.
```
sudo -i
mv /home/<username>/dbm_certificate.* /var/opt/mssql/data/
cd /var/opt/mssql/data
chown mssql:mssql dbm_certificate.*
```
Mit dem folgenden Transact-SQL-Skript wird ein Zertifikat auf der Grundlage der Sicherung erstellt, die Sie auf dem primären SQL Server-Replikat erstellt haben. Aktualisieren Sie das Skript durch sichere Kennwörter. Das Entschlüsselungskennwort ist das gleiche Kennwort, das Sie im vorherigen Schritt zum Erstellen der PVK-Datei verwendet haben. Um das Zertifikat zu erstellen, führen Sie das folgende Skript unter Verwendung von sqlcmd oder SSMS auf allen sekundären Servern aus:
```
CREATE CERTIFICATE dbm_certificate
    FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
    WITH PRIVATE KEY (
    FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
    DECRYPTION BY PASSWORD = '<PrivateKeyPassword>'
);
GO
```

Erstellen des Datenbankspiegelungs-Endpunkte auf allen Replikaten

Führen Sie das folgende Skript unter Verwendung von sqlcmd oder SSMS in allen SQL Server-Instanzen aus:

CREATE ENDPOINT [Hadr_endpoint]
   AS TCP (LISTENER_PORT = 5022)
   FOR DATABASE_MIRRORING (
   ROLE = ALL,
   AUTHENTICATION = CERTIFICATE dbm_certificate,
ENCRYPTION = REQUIRED ALGORITHM AES
);
GO

ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
GO

Erstellen der Verfügbarkeitsgruppe

Stellen Sie unter Verwendung von sqlcmd oder SSMS eine Verbindung mit der SQL Server-Instanz her, die das primäre Replikat hostet. Führen Sie den folgenden Befehl aus, um die Verfügbarkeitsgruppe zu erstellen:

Ersetzen Sie ag1 durch den Namen der gewünschten Verfügbarkeitsgruppe.
Ersetzen Sie die Werte sles1, sles2 und sles3 durch die Namen der SQL Server-Instanzen, von denen die Replikate gehostet werden.

CREATE AVAILABILITY
GROUP [ag1]
WITH (
        DB_FAILOVER = ON,
        CLUSTER_TYPE = EXTERNAL
        )
FOR REPLICA
    ON N'sles1'
WITH (
        ENDPOINT_URL = N'tcp://sles1:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = EXTERNAL,
        SEEDING_MODE = AUTOMATIC
        ),
    N'sles2'
WITH (
        ENDPOINT_URL = N'tcp://sles2:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = EXTERNAL,
        SEEDING_MODE = AUTOMATIC
        ),
    N'sles3'
WITH (
        ENDPOINT_URL = N'tcp://sles3:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = EXTERNAL,
        SEEDING_MODE = AUTOMATIC
        );
GO

ALTER AVAILABILITY GROUP [ag1]
GRANT CREATE ANY DATABASE;
GO

Erstellen Sie in allen SQL Server-Instanzen eine SQL Server-Anmeldung für Pacemaker. Mit dem folgenden Transact-SQL-Skript wird eine Anmeldung erstellt.

Ersetzen Sie <password> durch Ihr eigenes komplexes Kennwort.

USE [master]
GO

CREATE LOGIN [pacemakerLogin]
    WITH PASSWORD = N'<password>';
GO

ALTER SERVER ROLE [sysadmin]
    ADD MEMBER [pacemakerLogin];
GO

Speichern Sie in allen SQL Server-Instanzen die für die SQL Server-Anmeldung verwendeten Anmeldeinformationen.

Erstellen Sie die Datei:
```
sudo vi /var/opt/mssql/secrets/passwd
```
Fügen Sie der Datei die folgenden beiden Zeilen hinzu:
```
pacemakerLogin
<password>
```
Drücken Sie zum Verlassen des vi-Editors ESC, und geben Sie anschließend den Befehl :wq ein, um die Datei zu schreiben und den Editor zu beenden.

Sorgen Sie dafür, dass die Datei nur mit root-Berechtigungen lesbar ist:

sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd

Verknüpfen sekundärer Replikate mit der Verfügbarkeitsgruppe

Führen Sie auf Ihren sekundären Replikaten die folgenden Befehle aus, um die Replikate mit der Verfügbarkeitsgruppe zu verknüpfen:

ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
GO

Führen Sie auf dem primären Replikat sowie auf jedem sekundären Replikat das folgende Transact-SQL-Skript aus:

GRANT ALTER, CONTROL, VIEW DEFINITION
    ON AVAILABILITY GROUP::ag1 TO pacemakerLogin;
GO

GRANT VIEW SERVER STATE TO pacemakerLogin;
GO

Nachdem die sekundären Replikate verknüpft wurden, können Sie sie im SSMS-Objekt-Explorer anzeigen, indem Sie den Knoten Hochverfügbarkeit mit Always On erweitern:

Hinzufügen einer Datenbank zu einer Verfügbarkeitsgruppe

Dieser Abschnitt folgt dem Artikel zum Hinzufügen einer Datenbank zu einer Verfügbarkeitsgruppe.

In diesem Schritt werden die folgenden Transact-SQL-Befehle verwendet. Führen Sie diese Befehle auf dem primären Replikat aus:

CREATE DATABASE [db1]; -- creates a database named db1
GO

ALTER DATABASE [db1] SET RECOVERY FULL; -- set the database in full recovery model
GO

BACKUP DATABASE [db1] -- backs up the database to disk
    TO DISK = N'/var/opt/mssql/data/db1.bak';
GO

ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [db1]; -- adds the database db1 to the AG
GO

Sicherstellen, dass die Datenbank auf den sekundären Servern erstellt wird

Führen Sie auf jedem sekundären SQL Server-Replikat die folgende Abfrage aus, um zu ermitteln, ob die Datenbank „db1“ erstellt wurde und sich im Zustand „SYNCHRONIZED“ (Synchronisiert) befindet:

SELECT * FROM sys.databases
WHERE name = 'db1';
GO

SELECT DB_NAME(database_id) AS 'database',
    synchronization_state_desc
FROM sys.dm_hadr_database_replica_states;
GO

Wenn synchronization_state_desc für db1 den Zustand „SYNCHRONIZED“ (SYNCHRONISIERT) angibt, wurden die Replikate synchronisiert. Für die sekundären Replikate wird db1 im primären Replikat angezeigt.

Erstellen von Verfügbarkeitsgruppenressourcen im Pacemaker-Cluster

Hinweis

Vorurteilsfreie Kommunikation

In diesem Artikel wird der Begriff Slave (Sklave) verwendet, der in diesem Kontext von Microsoft als beleidigend eingestuft wird. Der Begriff wird in diesem Artikel verwendet, weil er derzeit in der Software verwendet wird. Sobald der Begriff aus der Software entfernt wird, wird er auch aus dem Artikel entfernt.

Dieser Artikel bezieht sich auf den Leitfaden zum Erstellen der Verfügbarkeitsgruppenressourcen in einem Pacemaker-Cluster.

Aktivieren von Pacemaker

Aktivieren Sie Pacemaker so, dass die Software automatisch gestartet wird.

Führen Sie den folgenden Befehl auf allen Knoten im Cluster aus.

sudo systemctl enable pacemaker

Erstellen der Verfügbarkeitsgruppen-Clusterressource

Führen crm configure Sie aus, um die crm-Eingabeaufforderung zu öffnen:
```
sudo crm configure
```

Führen Sie den folgenden Befehl an der crm-Eingabeaufforderung aus, um die Ressourceneigenschaften zu konfigurieren. Die folgenden Befehle erstellen die Ressource ag_cluster in der Verfügbarkeitsgruppe ag1.

primitive ag_cluster ocf:mssql:ag params ag_name="ag1" meta failure-timeout=60s op start timeout=60s op stop timeout=60s op promote timeout=60s op demote timeout=10s op monitor timeout=60s interval=10s op monitor timeout=60s interval=11s role="Master" op monitor timeout=60s interval=12s role="Slave" op notify timeout=60s ms ms-ag_cluster ag_cluster meta master-max="1" master-node-max="1" clone-max="3" clone-node-max="1" notify="true"
commit
quit

Tipp

Geben Sie quit ein, um die crm-Eingabeaufforderung zu beenden.

Legen Sie die Colocation-Einschränkung für die virtuelle IP-Adresse fest, damit die Ausführung ebenfalls auf dem primären Knoten erfolgen kann:
```
sudo crm configure
colocation vip_on_master inf: admin-ip ms-ag_cluster: Master
commit
quit
```
Fügen Sie eine Reihenfolgeneinschränkung hinzu, um zu vermeiden, dass die IP-Adresse vorübergehend auf den Knoten mit dem sekundären Replikat vor dem Failover verweist. Führen Sie den folgenden Befehl aus, um die Reihenfolgeneinschränkung zu erstellen:
```
sudo crm configure
order ag_first inf: ms-ag_cluster:promote admin-ip:start
commit
quit
```

Überprüfen Sie mit dem folgenden Befehl den Status des Clusters:

sudo crm status

Die Ausgabe sollte ungefähr wie das folgende Beispiel aussehen:

Cluster Summary:
  * Stack: corosync
  * Current DC: sles1 (version 2.0.5+20201202.ba59be712-150300.4.30.3-2.0.5+20201202.ba59be712) - partition with quorum
  * Last updated: Mon Mar  6 18:38:17 2023
  * Last change:  Mon Mar  6 18:38:09 2023 by root via cibadmin on sles1
  * 3 nodes configured
  * 5 resource instances configured

Node List:
  * Online: [ sles1 sles2 sles3 ]

Full List of Resources:
  * admin-ip    (ocf::heartbeat:IPaddr2):                Started sles1
  * rsc_st_azure        (stonith:fence_azure_arm):       Started sles2
  * Clone Set: ms-ag_cluster [ag_cluster] (promotable):
    * Masters: [ sles1 ]
    * Slaves: [ sles2 sles3 ]

Führen Sie den folgenden Befehl aus, um die Einschränkungen zu überprüfen:

sudo crm configure show

Die Ausgabe sollte ungefähr wie das folgende Beispiel aussehen:

node 1: sles1
node 2: sles2
node 3: sles3
primitive admin-ip IPaddr2 \
        params ip=10.0.0.93 \
        op monitor interval=10 timeout=20
primitive ag_cluster ocf:mssql:ag \
        params ag_name=ag1 \
        meta failure-timeout=60s \
        op start timeout=60s interval=0 \
        op stop timeout=60s interval=0 \
        op promote timeout=60s interval=0 \
        op demote timeout=10s interval=0 \
        op monitor timeout=60s interval=10s \
        op monitor timeout=60s interval=11s role=Master \
        op monitor timeout=60s interval=12s role=Slave \
        op notify timeout=60s interval=0
primitive rsc_st_azure stonith:fence_azure_arm \
        params subscriptionId=xxxxxxx resourceGroup=amvindomain tenantId=xxxxxxx login=xxxxxxx passwd="******" cmk_monitor_retries=4 pcmk_action_limit=3 power_timeout=240 pcmk_reboot_timeout=900 pcmk_host_map="sles1:sles1;les2:sles2;sles3:sles3" \
        op monitor interval=3600 timeout=120
ms ms-ag_cluster ag_cluster \
        meta master-max=1 master-node-max=1 clone-max=3 clone-node-max=1 notify=true
order ag_first Mandatory: ms-ag_cluster:promote admin-ip:start
colocation vip_on_master inf: admin-ip ms-ag_cluster:Master
property cib-bootstrap-options: \
        have-watchdog=false \
        dc-version="2.0.5+20201202.ba59be712-150300.4.30.3-2.0.5+20201202.ba59be712" \
        cluster-infrastructure=corosync \
        cluster-name=sqlcluster \
        stonith-enabled=true \
        concurrent-fencing=true \
        stonith-timeout=900
rsc_defaults rsc-options: \
        resource-stickiness=1 \
        migration-threshold=3
op_defaults op-options: \
        timeout=600 \
        record-pending=true

Testfailover

Führen Sie ein Testfailover durch, um sich zu vergewissern, dass die bisherige Konfiguration erfolgreich war. Weitere Informationen finden Sie unter Failover der Always On-Verfügbarkeitsgruppe unter Linux.

Führen Sie den folgenden Befehl aus, um ein manuelles Failover des primären Replikats auf sles2 durchzuführen. Ersetzen Sie sles2 durch Ihren Servernamen.
```
sudo crm resource move ag_cluster sles2
```
Die Ausgabe sollte ungefähr wie das folgende Beispiel aussehen:
```
INFO: Move constraint created for ms-ag_cluster to sles2
INFO: Use `crm resource clear ms-ag_cluster` to remove this constraint
```

Überprüfen Sie den Status des Clusters:

sudo crm status

Die Ausgabe sollte ungefähr wie das folgende Beispiel aussehen:

Cluster Summary:
  * Stack: corosync
  * Current DC: sles1 (version 2.0.5+20201202.ba59be712-150300.4.30.3-2.0.5+20201202.ba59be712) - partition with quorum
  * Last updated: Mon Mar  6 18:40:02 2023
  * Last change:  Mon Mar  6 18:39:53 2023 by root via crm_resource on sles1
  * 3 nodes configured
  * 5 resource instances configured

Node List:
  * Online: [ sles1 sles2 sles3 ]

Full List of Resources:
  * admin-ip    (ocf::heartbeat:IPaddr2):                Stopped
  * rsc_st_azure        (stonith:fence_azure_arm):       Started sles2
  * Clone Set: ms-ag_cluster [ag_cluster] (promotable):
    * Slaves: [ sles1 sles2 sles3 ]

Nach einiger Zeit ist die VM sles2 das primäre Replikat, und die anderen beiden VMs sind sekundäre Replikate. Führen Sie sudo crm status erneut aus, und überprüfen Sie die Ausgabe, die dem folgenden Beispiel ähneln sollte:

Cluster Summary:
  * Stack: corosync
  * Current DC: sles1 (version 2.0.5+20201202.ba59be712-150300.4.30.3-2.0.5+20201202.ba59be712) - partition with quorum
  * Last updated: Tue Mar  6 22:00:44 2023
  * Last change:  Mon Mar  6 18:42:59 2023 by root via cibadmin on sles1
  * 3 nodes configured
  * 5 resource instances configured

Node List:
  * Online: [ sles1 sles2 sles3 ]

Full List of Resources:
  * admin-ip    (ocf::heartbeat:IPaddr2):                Started sles2
  * rsc_st_azure        (stonith:fence_azure_arm):       Started sles2
  * Clone Set: ms-ag_cluster [ag_cluster] (promotable):
    * Masters: [ sles2 ]
    * Slaves: [ sles1 sles3 ]

Überprüfen Sie die Einschränkungen erneut mithilfe von crm config show. Beachten Sie, dass aufgrund des manuellen Failovers eine weitere Einschränkung hinzugefügt wurde.
Entfernen Sie die Einschränkung mit der ID cli-prefer-ag_cluster mithilfe des folgenden Befehls:
```
crm configure
delete cli-prefer-ms-ag_cluster
commit
```

Testen des Fencings

STONITH kann durch Ausführen des folgenden Befehls getestet werden. Führen Sie den folgenden Befehl auf sles1 für sles3aus.

sudo crm node fence sles3

Nächster Schritt

Tutorial: Konfigurieren von Verfügbarkeitsgruppenlistenern auf virtuellen Linux-Computern

Freigeben über

Tutorial: Konfigurieren von Verfügbarkeitsgruppen für SQL Server auf SLES-VMs in Azure

Voraussetzungen

Erstellen einer Ressourcengruppe

Verfügbarkeitsgruppe erstellen

Erstellen eines virtuellen Netzwerks und des Subnetzes

Erstellen von SLES-VMs in der Verfügbarkeitsgruppe

Testen der Verbindung mit den erstellten virtuellen Computern

Registrieren bei SUSEConnect und Installieren von Hochverfügbarkeitspaketen

Registrieren der VM bei SUSEConnect

Installieren der Hochverfügbarkeitserweiterung

Konfigurieren des kennwortlosen SSH-Zugriffs zwischen Knoten

Generieren neuer SSH-Schlüssel

Kopieren der öffentlichen SSH-Schlüssel

Überprüfen des kennwortlosen Zugriffs von jedem Knoten aus

Konfigurieren der Namensauflösung

Konfigurieren des Clusters

Clusterinstallation

Konfigurieren des Fencing-Agents

Registrieren einer neuen Anwendung in Microsoft Entra ID

Erstellen einer benutzerdefinierten Rolle für den Fence-Agent

Zuweisen der benutzerdefinierten Rolle zum Dienstprinzipal

Erstellen des STONITH-Geräts

Installieren von SQL Server und „mssql-tools“

Installieren von SQL Server auf den VMs

Installieren von SQL Server-Befehlszeilentools

Installieren des SQL Server-Hochverfügbarkeits-Agents

Öffnen von Ports für Hochverfügbarkeitsdienste

Konfigurieren einer Verfügbarkeitsgruppe

Aktivieren von Verfügbarkeitsgruppen und Neustarten von SQL Server

Erstellen eines Zertifikats

Kopieren des Zertifikats auf die sekundären Replikate und Erstellen der Zertifikate auf dem Server

Erstellen des Datenbankspiegelungs-Endpunkte auf allen Replikaten

Erstellen der Verfügbarkeitsgruppe

Erstellen einer SQL Server-Anmeldung für Pacemaker

Verknüpfen sekundärer Replikate mit der Verfügbarkeitsgruppe

Hinzufügen einer Datenbank zu einer Verfügbarkeitsgruppe

Sicherstellen, dass die Datenbank auf den sekundären Servern erstellt wird

Erstellen von Verfügbarkeitsgruppenressourcen im Pacemaker-Cluster

Aktivieren von Pacemaker

Erstellen der Verfügbarkeitsgruppen-Clusterressource

Testfailover

Testen des Fencings

Nächster Schritt

Feedback

Zusätzliche Ressourcen