Esercitazioni: Configurare i gruppi di disponibilità per SQL Server nelle macchine virtuali SLES in Azure

Si applica a:SQL Server su VM Azure

Nota

In questa esercitazione si usa SQL Server 2022 (16.x) con SUSE Linux Enterprise Server (SLES) v15, ma è possibile usare SQL Server 2019 (15.x) con SLES v12 o SLES v15 per configurare la disponibilità elevata.

In questa esercitazione apprenderai a:

• Creare un nuovo gruppo di risorse, un set di disponibilità e le macchine virtuali Linux
• Abilitare la disponibilità elevata
• Creare un cluster Pacemaker
• Configurare un agente di isolamento mediante la creazione di un dispositivo STONITH
• Installare SQL Server e mssql-tools in SLES
• Configurare il gruppo di disponibilità Always On di SQL Server
• Configurare le risorse del gruppo di disponibilità nel cluster Pacemaker
• Testare un failover e l'agente di isolamento

Questa esercitazione usa l'interfaccia della riga di comando di Azure CLI per distribuire le risorse in Azure.

Se non si ha una sottoscrizione di Azure, creare un account gratuito prima di iniziare.

Prerequisiti

• Usare l'ambiente Bash in Azure Cloud Shell. Per altre informazioni, vedere Avvio rapido per Bash in Azure Cloud Shell.

  

• Se si preferisce eseguire i comandi di riferimento dell'interfaccia della riga di comando in locale, installare l'interfaccia della riga di comando di Azure. Per l'esecuzione in Windows o macOS, è consigliabile eseguire l'interfaccia della riga di comando di Azure in un contenitore Docker. Per altre informazioni, vedere Come eseguire l'interfaccia della riga di comando di Azure in un contenitore Docker.

  • Se si usa un'installazione locale, accedere all'interfaccia della riga di comando di Azure con il comando az login. Per completare il processo di autenticazione, seguire la procedura visualizzata nel terminale. Per altre opzioni di accesso, vedere Accedere tramite l'interfaccia della riga di comando di Azure.

  • Quando richiesto, installare l'estensione dell'interfaccia della riga di comando di Azure al primo utilizzo. Per altre informazioni sulle estensioni, vedere Usare le estensioni con l'interfaccia della riga di comando di Azure.

  • Eseguire az version per trovare la versione e le librerie dipendenti installate. Per eseguire l'aggiornamento alla versione più recente, eseguire az upgrade.

• Questo articolo richiede l'interfaccia della riga di comando di Azure versione 2.0.30 o successiva. Se si usa Azure Cloud Shell, la versione più recente è già installata.

Creare un gruppo di risorse

Se sono presenti più sottoscrizioni, selezionare la sottoscrizione in cui dovranno essere distribuite le risorse.

Usare il comando seguente per creare un gruppo di risorse <resourceGroupName> in un'area. Sostituire <resourceGroupName> con il nome desiderato. In questa esercitazione viene usato East US 2. Per altre informazioni, vedere la guida di Avvio rapido seguente.

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

Creare un set di disponibilità

Il passaggio successivo prevede la creazione di un set di disponibilità. Eseguire il comando seguente in Azure Cloud Shell e sostituire <resourceGroupName> con il nome del gruppo di risorse. Scegliere un nome per <availabilitySetName>.

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

Al termine del comando, verranno restituiti i risultati seguenti:

{
  "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": []
}

Creare una rete virtuale e una subnet

1. Creare una subnet denominata con un intervallo di indirizzi IP pre-assegnato. Sostituire questi valori nel comando seguente:

   • <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
   

   Il comando precedente crea una rete virtuale e una subnet contenente un intervallo IP personalizzato.

Creare macchine virtuali SLES all'interno del set di disponibilità

1. Ottenere un elenco di immagini di macchine virtuali che offrono SLES v15 SP4 con BYOS (bring your own subscription). È anche possibile usare SUSE Enterprise Linux 15 SP4 + Patching VM (sles-15-sp4-basic).

   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"
   

   Quando si cercano le immagini BYOS, verranno visualizzati i risultati seguenti:

   [
      {
         "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 questa esercitazione viene usato SUSE:sles-15-sp3-byos:gen1:2022.11.10.

   Importante

   Per configurare il gruppo di disponibilità, i nomi delle macchine virtuali devono contenere meno di 15 caratteri. Il nome utente non può contenere caratteri maiuscoli e le password devono contenere tra 12 e 72 caratteri.

2. Creare tre macchine virtuali all'interno del set di disponibilità. Sostituire questi valori nel comando seguente:

   • <resourceGroupName>
   • <VM-basename>
   • <availabilitySetName>
   • <VM-Size>, ad esempio "Standard_D16_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
   

Il comando precedente crea le macchine virtuali usando la rete virtuale definita in precedenza. Per altre informazioni sulle diverse configurazioni, vedere l'articolo con le informazioni di riferimento su az vm create.

Il comando include anche il --os-disk-size-gb parametro per creare un'unità del sistema operativo personalizzata di 128 GB. Successivamente, configurare Logical Volume Manager (LVM) se è necessario espandere i volumi delle cartelle appropriati per l'installazione.

Al termine del comando per ogni macchina virtuale, si otterrà un risultato simile al seguente:

{
  "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": ""
}

Testare la connessione alle macchine virtuali create

Connettersi a ciascuna macchina virtuale usando il comando seguente in Azure Cloud Shell. Se non si riesce a trovare gli indirizzi IP della macchina virtuale, seguire questa guida di Avvio rapido in Azure Cloud Shell.

ssh <username>@<publicIPAddress>

Se la connessione viene stabilita, verrà visualizzato l'output seguente che rappresenta il terminale Linux:

[<username>@sles1 ~]$

Digitare exit per uscire dalla sessione SSH.

Eseguire la registrazione con SUSEConnect e installare pacchetti a disponibilità elevata

Per completare questa esercitazione, le macchine virtuali devono essere registrate con SUSEConnect per ricevere aggiornamenti e supporto. È quindi possibile installare il modulo o il criterio di estensione a disponibilità elevata, ovvero un set di pacchetti che abilita la disponibilità elevata.

Sarà più semplice se si apre una sessione SSH contemporaneamente per ogni macchina virtuale (nodi), perché i comandi illustrati nell'articolo dovranno essere eseguiti in ogni macchina virtuale.

Se si copiano e incollano più sudo comandi e viene richiesta una password, i comandi aggiuntivi non verranno eseguiti. Eseguire ogni comando separatamente.

Connessione a ogni nodo della macchina virtuale per eseguire i passaggi seguenti.

Registrare la macchina virtuale con SUSEConnect

Per registrare il nodo della macchina virtuale con SUSEConnect, sostituire questi valori nel comando seguente in tutti i nodi:

• <subscriptionEmailAddress>
• <registrationCode>

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

Installare l'estensione per la disponibilità elevata

Per installare l'estensione a disponibilità elevata, eseguire il comando seguente in tutti i nodi:

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

Configurare l'accesso SSH senza password tra nodi

L'accesso SSH senza password consente alle macchine virtuali di comunicare tra loro usando chiavi pubbliche SSH. È necessario configurare le chiavi SSH in ogni nodo e copiare tali chiavi in ogni nodo.

Generare nuove chiavi SSH

Le dimensioni della chiave SSH necessarie sono 4.096 bit. In ogni macchina virtuale, passare alla cartella /root/.ssh ed eseguire il comando seguente:

ssh-keygen -t rsa -b 4096

Durante questo passaggio potrebbe essere richiesto di sovrascrivere un file SSH esistente. È necessario accettare questa richiesta. Non è necessario immettere una passphrase.

Copiare le chiavi SSH pubbliche

Su ogni macchina virtuale è necessario copiare la chiave pubblica dal nodo appena creato usando il ssh-copy-id comando. Se si vuole specificare la directory di destinazione nel nodo gestito, è possibile usare il -i parametro.

Nel comando seguente, l'account <username> può essere lo stesso account configurato per ogni nodo durante la creazione della macchina virtuale. È anche possibile usare l'account root, ma questo non è consigliato in un ambiente di produzione.

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

Verificare l'accesso senza password da ogni nodo

Per verificare che la chiave pubblica SSH sia stata copiata in ogni nodo, usare il ssh comando da ogni nodo. Se le chiavi sono state copiate correttamente, non verrà richiesta una password e la connessione avrà esito positivo.

In questo esempio ci si connette al secondo e al terzo nodo dalla prima macchina virtuale (sles1). Nel comando seguente, l'account <username> può essere lo stesso account configurato per ogni nodo durante la creazione della macchina virtuale.

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

Ripetere questo processo da tutti e tre i nodi, in modo che ogni nodo possa comunicare con gli altri senza richiedere password.

Configurare la risoluzione dei nomi

È possibile configurare la risoluzione dei nomi usando DNS o modificando manualmente il etc/hosts file in ogni nodo.

Per altre informazioni su DNS e Active Directory, vedere Aggiungere un host di SQL Server in Linux a un dominio di Active Directory.

Importante

È consigliabile usare l'indirizzo IP privato nell'esempio precedente. Se in questa configurazione si usa l'indirizzo IP pubblico, l'installazione avrà esito negativo ed esporrebbe la macchina virtuale alle reti esterne.

Le macchine virtuali e il relativo indirizzo IP usati in questo esempio sono elencati come segue:

• sles1: 10.0.0.85
• sles2: 10.0.0.86
• sles3: 10.0.0.87

Configurare il cluster

Per questa esercitazione, la prima macchina virtuale (sles1) è il nodo 1, la seconda macchina virtuale (sles2) è il nodo 2 e la terza macchina virtuale (sles3) è il nodo 3. Per altre informazioni sull'installazione del cluster, vedere Configurare Pacemaker su SUSE Linux Enterprise Server in Azure.

Installazione del cluster

1. Eseguire il comando seguente per installare il ha-cluster-bootstrap pacchetto nel nodo 1 e quindi riavviare il nodo. In questo esempio è la sles1 macchina virtuale.

   sudo zypper install ha-cluster-bootstrap
   

   Dopo il riavvio del nodo, eseguire il comando seguente per distribuire il cluster:

   sudo crm cluster init --name sqlcluster
   

   L'output sarà simile all'esempio seguente:

   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)
   

2. Per visualizzare lo stato del cluster sul nodo 1, eseguire il comando seguente:

   sudo crm status
   

   Se l'output ha esito positivo, deve includere il testo seguente:

   1 node configured
   1 resource instance configured
   

3. In tutti i nodi, modificare la password per hacluster in una più sicura usando il comando seguente. È anche necessario modificare la password dell'utente root:

   sudo passwd hacluster
   

   sudo passwd root
   

4. Eseguire il comando seguente sui nodi 2 e 3 per installare il crmsh pacchetto prima di tutto:

   sudo zypper install crmsh
   

   Eseguire ora il comando per aggiungere il cluster:

   sudo crm cluster join
   

   Ecco alcune delle possibili interazioni:

   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)
   

5. Dopo aver aggiunto tutti i computer al cluster, controllare la risorsa per verificare se tutte le macchine virtuali sono online:

   sudo crm status
   

   Verrà visualizzato l'output seguente:

   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
   

6. Installare il componente della risorsa cluster. Eseguire il comando seguente in tutti i nodi.

   sudo zypper in socat
   

7. Installare il azure-lb componente. Eseguire il comando seguente in tutti i nodi.

   sudo zypper in resource-agents
   

8. Configurazione del sistema operativo. Eseguire questa procedura in tutti i nodi.

   1. Modificare il file di configurazione:

      sudo vi /etc/systemd/system.conf
      

   2. Modificare il DefaultTasksMax valore in 4096:

      #DefaultTasksMax=512
      DefaultTasksMax=4096
      

   3. Salvare il file e chiudere l’editor vi.

   4. Per attivare questa impostazione, eseguire il comando seguente:

      sudo systemctl daemon-reload
      

   5. Verificare se la modifica ha avuto esito positivo:

      sudo systemctl --no-pager show | grep DefaultTasksMax
      

9. Ridurre le dimensioni della cache dirty. Eseguire questa procedura in tutti i nodi.

   1. Modificare il file di configurazione del controllo di sistema:

      sudo vi /etc/sysctl.conf
      

   2. Aggiungere le due righe seguenti al file:

      vm.dirty_bytes = 629145600
      vm.dirty_background_bytes = 314572800
      

   3. Salvare il file e chiudere l’editor vi.

10. Installare Azure Python SDK in tutti i nodi con i comandi seguenti:

    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
    

Configurare l'agente di isolamento

Un dispositivo STONITH fornisce un agente di isolamento. Le istruzioni seguenti sono state modificate per questa esercitazione. Per altre informazioni, vedere Creare un dispositivo STONITH dell'agente di isolamento di Azure.

Controllare la versione dell'agente di isolamento di Azure per assicurarsi che sia aggiornata. Utilizza il seguente comando:

sudo zypper info resource-agents

Verrà visualizzato un output simile all'esempio seguente.

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.

Registrare un’applicazione in Microsoft Entra ID

Per registrare una nuova applicazione in Microsoft Entra ID (in precedenza Azure Active Directory), seguire questa procedura:

1. Vai a https://portal.azure.com.
2. Aprire il riquadro Proprietà ID Microsoft Entra e annotare Tenant ID.
3. Selezionare Registrazioni app.
4. Seleziona Nuova registrazione.
5. Immettere un nome, ad esempio <resourceGroupName>-app. Per tipi di account supportati selezionare Account solo in questa directory dell'organizzazione (solo Microsoft - Tenant singolo).
6. Selezionare Web per URI di reindirizzamento e immettere un URL, ad esempio http://localhost), e selezionare Aggiungi. L'URL di accesso può essere qualsiasi URL valido. Al termine dell'operazione, selezionare Registra.
7. Selezionare Certificati e segreti per la nuova registrazione app e quindi fare clic su Nuovo segreto client.
8. Immettere una descrizione per una nuova chiave (segreto client), quindi selezionare Aggiungi.
9. Prendere nota del valore del segreto. Verrà usato come password per l'entità servizio.
10. Selezionare Panoramica. Prendere nota dell'ID applicazione. Viene usato come nome utente (ID di accesso nella procedura seguente) dell'entità servizio.

Creare un ruolo personalizzato per l'agente di isolamento

Seguire l'esercitazione Creare un ruolo personalizzato di Azure tramite l'interfaccia della riga di comando di Azure.

Il file JSON dovrebbe avere un aspetto simile all'esempio seguente.

• Sostituire <username> con il nome desiderato. In questo modo sarà possibile evitare eventuali duplicati durante la creazione di questa definizione del ruolo.
• Sostituire <subscriptionId> con l'ID della sottoscrizione di Azure.

{
  "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>"
  ]
}

Per aggiungere il ruolo, eseguire il comando seguente:

• Sostituire <filename> con il nome file.
• Se si esegue il comando da un percorso diverso dalla cartella in cui è stato salvato il file, includere il percorso della cartella del file nel comando.

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

Verrà visualizzato l'output seguente:

{
  "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"
}

Assegnare il ruolo personalizzato all'entità servizio

Assegnare all'entità servizio il ruolo personalizzato Linux Fence Agent Role-<username> creato nel passaggio precedente. Ripetere questi passaggi per tutti i nodi.

Avviso

Non usare il ruolo Proprietario da qui in poi.

1. Passare a https://portal.azure.com
2. Aprire il riquadro Tutte le risorse
3. Selezionare la macchina virtuale del primo nodo del cluster.
4. Selezionare Controllo di accesso (IAM)
5. Selezionare Aggiungi assegnazioni di ruolo
6. Selezionare il ruolo Linux Fence Agent Role-<username> dall'elenco Ruolo
7. Lasciare Assegna l'accesso a comeUsers, group, or service principal predefinito.
8. Nell'elenco Seleziona immettere il nome dell'applicazione creata sopra, per esempio <resourceGroupName>-app.
9. Seleziona Salva.

Creare i dispositivi STONITH

1. Eseguire questo comando nel nodo 1:

   • Sostituire <ApplicationID> con il valore dell'ID della registrazione dell'applicazione.
   • Sostituire <servicePrincipalPassword> con il valore del segreto client.
   • Sostituire <resourceGroupName> con il gruppo di risorse della sottoscrizione usata per questa esercitazione.
   • Sostituire <tenantID> e <subscriptionId> con i valori della sottoscrizione di Azure.

2. Eseguire crm configure per aprire il prompt di crm:

   sudo crm configure
   

3. Nel prompt crm eseguire il comando seguente per configurare le proprietà della risorsa, che crea la risorsa denominata rsc_st_azure come illustrato nell'esempio seguente:

   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
   

4. Eseguire i comandi seguenti per configurare l'agente di isolamento:

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

5. Controllare lo stato del cluster per verificare che STONITH sia stato abilitato:

   sudo crm status
   

   L'output dovrebbe essere simile al testo seguente:

   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
   

Installare SQL Server e mssql-tools

Vedere la sezione seguente per installare SQL Server e mssql-tools. Per altre informazioni, vedere Installare SQL Server in SUSE Linux Enterprise Server.

Eseguire questi passaggi in tutti i nodi di questa sezione.

Installazione di SQL Server nelle macchine virtuali

Per installare SQL Server verranno usati i comandi seguenti:

1. Scaricare il file di configurazione del repository di Microsoft SQL Server 2019 per SLES:

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

2. Aggiornare i repository.

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

   Per assicurarsi che la chiave di firma del pacchetto Microsoft sia installata nel sistema, usare il comando seguente per importare la chiave:

   sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
   

3. Eseguire i comandi seguenti per installare SQL Server:

   sudo zypper install -y mssql-server
   

4. Al termine dell'installazione del pacchetto, eseguire mssql-conf setup e seguire le istruzioni per impostare la password dell'amministratore di sistema e scegliere l'edizione.

   sudo /opt/mssql/bin/mssql-conf setup
   

   Nota

   Assicurarsi di specificare una password complessa per l'account dell'amministratore di sistema (lunghezza minima di 8 caratteri, con lettere sia maiuscole che minuscole, cifre in base 10 e/o simboli non alfanumerici).

5. Al termine della configurazione, verificare che il servizio sia in esecuzione:

   systemctl status mssql-server
   

Installare gli strumenti da riga di comando di SQL Server

La procedura seguente installa gli strumenti da riga di comando di SQL Server sqlcmd e bcp.

1. Aggiungere il repository Microsoft SQL Server a Zypper.

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

2. Aggiornare i repository.

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

3. Installare mssql-tools con il unixODBC pacchetto per sviluppatori. Per altre informazioni, vedere Installare Microsoft ODBC Driver for SQL Server (Linux).

   sudo zypper install -y mssql-tools unixODBC-devel
   

Per praticità, aggiungere /opt/mssql-tools/bin/ alla PATH variabile di ambiente. In questo modo è possibile eseguire gli strumenti senza specificare il percorso completo. Eseguire i comandi seguenti per modificare l'elemento PATH sia per le sessioni di accesso che per le sessioni interattive/non di accesso:

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

Installare l'agente a disponibilità elevata SQL Server

Eseguire il comando seguente in tutti i nodi per installare il pacchetto dell'agente a disponibilità elevata per SQL Server:

sudo zypper install mssql-server-ha

Aprire le porte per i servizi a disponibilità elevata

1. È possibile aprire le porte firewall seguenti in tutti i nodi per i servizi SQL Server e a disponibilità elevata: 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
   

Configurare un gruppo di disponibilità

Per configurare un gruppo di disponibilità Always On di SQL Server per le macchine virtuali, seguire questa procedura. Per altre informazioni, vedere Configurare gruppi di disponibilità Always On di SQL Server per la disponibilità elevata in Linux

Abilitare i gruppi di disponibilità e riavviare SQL Server

Abilitare i gruppi di disponibilità in ogni nodo che ospita un'istanza di SQL Server. Quindi riavviare ilmssql-server server. Eseguire i comandi seguenti in ogni nodo:

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

sudo systemctl restart mssql-server

Creare un certificato

Microsoft non supporta l'autenticazione di Active Directory per l'endpoint del gruppo di disponibilità. È quindi necessario usare un certificato per la crittografia dell'endpoint del gruppo di disponibilità.

1. Connettersi a tutti i nodi con SQL Server Management Studio (SSMS) o sqlcmd. Eseguire i comandi seguenti per abilitare la sessione AlwaysOn_health e creare una chiave master:

   Importante

   Se ci si connette all'istanza di SQL Server in modalità remota, sarà necessario aprire la porta 1433 sul firewall. Sarà inoltre necessario consentire le connessioni in ingresso alla porta 1433 nel gruppo di sicurezza di rete per ogni macchina virtuale. Per altre informazioni, vedere Creare una regola di sicurezza per la creazione di una regola di sicurezza in ingresso.

   • Sostituire <MasterKeyPassword> con la propria password.

   ALTER EVENT SESSION AlwaysOn_health ON SERVER
       WITH (STARTUP_STATE = ON);
   GO
   
   CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<MasterKeyPassword>';
   GO
   

2. Connettersi alla replica primaria usando SSMS o sqlcmd. I comandi seguenti creeranno un certificato in /var/opt/mssql/data/dbm_certificate.cer e una chiave privata in var/opt/mssql/data/dbm_certificate.pvk nella replica primaria di SQL Server:

   • Sostituire <PrivateKeyPassword> con la propria password.

   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
   

Per uscire dalla sessione sqlcmd eseguire il comando exit e tornare alla sessione SSH.

Copiare il certificato nelle repliche secondarie e creare i certificati nel server

1. Copiare i due file creati nello stesso percorso in tutti i server che ospiteranno le repliche di disponibilità.

   Nel server primario eseguire il comando scp per copiare il certificato nei server di destinazione:

   • Sostituire <username> e sles2 con il nome utente e il nome della macchina virtuale di destinazione in uso.
   • Eseguire questo comando per tutte le repliche secondarie.

   Nota

   Non è necessario eseguire sudo -i, che restituisce l'ambiente radice. È invece possibile eseguire il sudo comando davanti a ogni comando.

   # 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>
   

2. Nel server di destinazione eseguire questo comando:

   • Sostituire <username> con il nome utente.
   • Il comando mv sposta i file o la directory da una posizione a un'altra.
   • Il comando chown viene usato per modificare il proprietario e il gruppo di file, directory o collegamenti.
   • Eseguire questi comandi per tutte le repliche secondarie.

   sudo -i
   mv /home/<username>/dbm_certificate.* /var/opt/mssql/data/
   cd /var/opt/mssql/data
   chown mssql:mssql dbm_certificate.*
   

3. Lo script Transact-SQL seguente crea un certificato dal backup creato nella replica primaria di SQL Server. Aggiornare lo script con password complesse. La password di decrittografia è la stessa password usata per creare il file PVK nel passaggio precedente. Per creare il certificato, eseguire lo script seguente in tutti i server secondari usando sqlcmd o SSMS:

   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
   

Creare endpoint di mirroring del database in tutte le repliche

Eseguire lo script seguente in tutte le istanze di SQL Server usando sqlcmd o SSMS:

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

Creare il gruppo di disponibilità

Connettersi all'istanza di SQL Server che ospita la replica primaria usando sqlcmd o SSMS. Per creare il gruppo di disponibilità, eseguire questo comando:

• Sostituire ag1 con il nome del gruppo di disponibilità desiderato.
• Sostituire i valori di sles1, sles2 e sles3 con i nomi delle istanze di SQL Server che ospitano le repliche.

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

Creare un account di accesso di SQL Server per Pacemaker

In tutte le istanze di SQL Server creare un account di accesso di SQL Server per Pacemaker. Il codice Transact-SQL seguente crea un account di accesso.

• Sostituire <password> con una password complessa personale.

USE [master]
GO

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

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

In tutte le istanze di SQL Server salvare le credenziali usate per l'account di accesso di SQL Server.

1. Creare il file :

   sudo vi /var/opt/mssql/secrets/passwd
   

2. Aggiungere le due righe seguenti al file:

   pacemakerLogin
   <password>
   

   Per uscire dall'editor vi, premere prima il tasto ESC e quindi immettere il comando :wq per eseguire la scrittura del file e uscire.

3. Impostare il file come leggibile solo dall'utente ROOT:

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

Aggiungere le repliche secondarie al gruppo di disponibilità

1. Nelle repliche secondarie eseguire i comandi seguenti per aggiungerle al gruppo di disponibilità:

   ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
   GO
   
   ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
   GO
   

2. Nella replica primaria e in ogni replica secondaria eseguire lo script Transact-SQL seguente:

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

3. Dopo aver aggiunto le repliche secondarie, sarà possibile visualizzarle in Esplora oggetti di SSMS espandendo il nodo Disponibilità elevata Always On:

   

Aggiungere un database al gruppo di disponibilità

Questa sezione segue l'articolo relativo all'aggiunta di un database a un gruppo di disponibilità.

In questo passaggio verranno usati i comandi Transact-SQL seguenti. Eseguire questi comandi nella replica primaria:

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

Verificare che il database sia creato nei server secondari

In ogni replica secondaria di SQL Server eseguire la query seguente per verificare che il database db1 sia stato creato e che si trovi nello stato SINCRONIZZATO:

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

Se l'elenco synchronization_state_desc restituisce SINCRONIZZATO per db1, significa che le repliche sono sincronizzate. I server secondari mostrano db1 nella replica primaria.

Creare le risorse del gruppo di disponibilità nel cluster Pacemaker

Nota

Comunicazione senza distorsione

Questo articolo contiene riferimenti al termine slave, un termine che Microsoft considera offensivo se usato in questo contesto. Il termine viene visualizzato in questo articolo perché è attualmente incluso nel software. Quando il termine verrà rimosso dal software, verrà rimosso dall'articolo.

Questo articolo fa riferimento alla guida per creare le risorse del gruppo di disponibilità in un cluster Pacemaker.

Abilitare Pacemaker

Abilitare Pacemaker per consentirne l'avvio automatico.

In ogni nodo del cluster eseguire il comando seguente.

sudo systemctl enable pacemaker

Creare la risorsa cluster del gruppo di disponibilità

1. Eseguire crm configure per aprire il prompt di crm:

   sudo crm configure
   

2. Nel prompt crm eseguire il comando seguente per configurare le proprietà della risorsa. Usare il comando seguente per creare la risorsa ag_cluster nel gruppo di disponibilità 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
   

   Suggerimento

   Digitare quit per uscire dal prompt crm.

3. Impostare il vincolo di condivisione della posizione per l'indirizzo IP virtuale per l'esecuzione nello stesso nodo del nodo primario:

   sudo crm configure
   colocation vip_on_master inf: admin-ip ms-ag_cluster: Master
   commit
   quit
   

4. Per evitare che l'indirizzo IP punti temporaneamente al nodo con la replica secondaria preliminare al failover, aggiungere un vincolo di ordinamento. Eseguire il comando seguente per creare un vincolo di ordinamento:

   sudo crm configure
   order ag_first inf: ms-ag_cluster:promote admin-ip:start
   commit
   quit
   

5. Per visualizzare lo stato del cluster, eseguire il comando:

   sudo crm status
   

   L'output deve essere simile all'esempio seguente:

   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 ]
   

6. Per esaminare i vincoli, eseguire il comando seguente:

   sudo crm configure show
   

   L'output deve essere simile all'esempio seguente:

   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
   

Failover di test

Per assicurarsi che la configurazione abbia avuto esito positivo fino a questo momento, testare un failover. Per altre informazioni, vedere Failover di un gruppo di disponibilità Always On in Linux.

1. Eseguire il comando seguente per procedere al failover manuale della replica primaria in sles2. Sostituire sles2 con il valore del nome del server.

   sudo crm resource move ag_cluster sles2
   

   L'output deve essere simile all'esempio seguente:

   INFO: Move constraint created for ms-ag_cluster to sles2
   INFO: Use `crm resource clear ms-ag_cluster` to remove this constraint
   

2. Controllare lo stato del cluster:

   sudo crm status
   

   L'output deve essere simile all'esempio seguente:

   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 ]
   

3. Dopo qualche tempo, la sles2 macchina virtuale è ora la primaria e le altre due macchine virtuali sono secondarie. Eseguire sudo crm status di nuovo ed esaminare l'output, simile all'esempio seguente:

   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 ]
   

4. Controllare di nuovo i vincoli usando crm config show. Notare che è stato aggiunto un altro vincolo a causa del failover manuale.

5. Rimuovere il vincolo con l'ID cli-prefer-ag_cluster usando il comando seguente:

   crm configure
   delete cli-prefer-ms-ag_cluster
   commit
   

Testare l'isolamento

Per testare STONITH, eseguire il comando seguente. Provare a eseguire il comando seguente da sles1 per sles3.

sudo crm node fence sles3

Passaggio successivo

Esercitazione: Configurare un listener del gruppo di disponibilità su macchine virtuali Linux