Udostępnij za pośrednictwem


Samouczek: konfigurowanie grup dostępności dla programu SQL Server na maszynach wirtualnych SLES na platformie Azure

Dotyczy:SQL Server na maszynie wirtualnej platformy Azure

Uwaga

W tym samouczku używamy programu SQL Server 2022 (16.x) z systemem SUSE Linux Enterprise Server (SLES) w wersji 15, ale w celu skonfigurowania wysokiej dostępności można użyć programu SQL Server 2019 (15.x) z systemem SLES w wersji 12 lub SLES w wersji 15.

Z tego samouczka dowiesz się, jak wykonywać następujące czynności:

  • Tworzenie nowej grupy zasobów, zestawu dostępności i maszyn wirtualnych z systemem Linux
  • Włączanie wysokiej dostępności (HA)
  • Tworzenie klastra Pacemaker
  • Konfigurowanie agenta ogrodzenia przez utworzenie urządzenia STONITH
  • Instalowanie programu SQL Server i narzędzi mssql-tools w systemie SLES
  • Konfigurowanie zawsze włączonej grupy dostępności programu SQL Server
  • Konfigurowanie zasobów grupy dostępności w klastrze Pacemaker
  • Testowanie trybu failover i agenta ogrodzenia

W tym samouczku do wdrażania zasobów na platformie Azure jest używany interfejs wiersza polecenia platformy Azure.

Jeśli nie masz subskrypcji platformy Azure, przed rozpoczęciem utwórz bezpłatne konto.

Wymagania wstępne

  • Ten artykuł wymaga wersji 2.0.30 lub nowszej interfejsu wiersza polecenia platformy Azure. W przypadku korzystania z usługi Azure Cloud Shell najnowsza wersja jest już zainstalowana.

Tworzenie grupy zasobów

Jeśli masz więcej niż jedną subskrypcję, ustaw subskrypcję, do której chcesz wdrożyć te zasoby.

Użyj następującego polecenia, aby utworzyć grupę <resourceGroupName> zasobów w regionie. Zastąp <resourceGroupName> ciąg wybraną nazwą. W tym samouczku użyto regionu East US 2. Aby uzyskać więcej informacji, zobacz następujący przewodnik Szybki start.

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

Tworzenie zestawu dostępności

Następnym krokiem jest utworzenie zestawu dostępności. Uruchom następujące polecenie w usłudze Azure Cloud Shell i zastąp ciąg <resourceGroupName> nazwą grupy zasobów. Wybierz nazwę elementu <availabilitySetName>.

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

Po zakończeniu polecenia należy uzyskać następujące wyniki:

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

Tworzenie sieci wirtualnej i podsieci

  1. Utwórz nazwaną podsieć z wstępnie przypisanym zakresem adresów IP. Zastąp te wartości w następującym poleceniu:

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

    Poprzednie polecenie tworzy sieć wirtualną i podsieć zawierającą niestandardowy zakres adresów IP.

Tworzenie maszyn wirtualnych SLES wewnątrz zestawu dostępności

  1. Pobierz listę obrazów maszyn wirtualnych, które oferują system SLES w wersji 15 SP4 z rozwiązaniem BYOS (przynieś własną subskrypcję). Możesz również użyć maszyny wirtualnej z systemem SUSE Enterprise Linux 15 z dodatkiem SP4 i poprawkami (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"
    

    Podczas wyszukiwania obrazów BYOS powinny zostać wyświetlone następujące wyniki:

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

    W tym samouczku użyto regionu SUSE:sles-15-sp3-byos:gen1:2022.11.10.

    Ważne

    Aby skonfigurować grupę dostępności, nazwy maszyn muszą mieć długość krótszą niż 15 znaków. Nazwy użytkowników nie mogą zawierać wyższej litery, a hasła muszą zawierać od 12 do 72 znaków.

  2. Utwórz trzy maszyny wirtualne w zestawie dostępności. Zastąp te wartości w następującym poleceniu:

    • <resourceGroupName>
    • <VM-basename>
    • <availabilitySetName>
    • <VM-Size> — Przykładem może być "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
    

Poprzednie polecenie tworzy maszyny wirtualne przy użyciu wcześniej zdefiniowanej sieci wirtualnej. Aby uzyskać więcej informacji na temat różnych konfiguracji, zobacz artykuł az vm create .

Polecenie zawiera --os-disk-size-gb również parametr umożliwiający utworzenie niestandardowego rozmiaru dysku systemu operacyjnego 128 GB. Jeśli później zwiększysz ten rozmiar, rozwiń odpowiednie woluminy folderów, aby pomieścić instalację, skonfiguruj Menedżera woluminów logicznych (LVM).

Wyniki powinny być podobne do następujących po zakończeniu polecenia dla każdej maszyny wirtualnej:

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

Testowanie połączenia z utworzonymi maszynami wirtualnymi

Połączenie do każdej maszyny wirtualnej przy użyciu następującego polecenia w usłudze Azure Cloud Shell. Jeśli nie możesz znaleźć adresów IP maszyny wirtualnej, postępuj zgodnie z tym przewodnikiem Szybki start w usłudze Azure Cloud Shell.

ssh <username>@<publicIPAddress>

Jeśli połączenie zakończy się pomyślnie, powinny zostać wyświetlone następujące dane wyjściowe reprezentujące terminal systemu Linux:

[<username>@sles1 ~]$

Wpisz exit , aby opuścić sesję SSH.

Zarejestruj się w programie SUSE Połączenie i zainstaluj pakiety wysokiej dostępności

Aby ukończyć ten samouczek, maszyny wirtualne muszą być zarejestrowane w systemie SUSE Połączenie aby otrzymywać aktualizacje i pomoc techniczną. Następnie można zainstalować moduł rozszerzenia wysokiej dostępności lub wzorzec, który jest zestawem pakietów, które umożliwiają wysoką dostępność.

Łatwiej jest otworzyć sesję SSH na każdej maszynie wirtualnej (węzłach) jednocześnie, ponieważ te same polecenia muszą być uruchamiane na każdej maszynie wirtualnej w całym artykule.

Jeśli kopiujesz i wklejasz wiele sudo poleceń i zostanie wyświetlony monit o podanie hasła, dodatkowe polecenia nie zostaną uruchomione. Uruchom każde polecenie oddzielnie.

Połączenie do każdego węzła maszyny wirtualnej, aby uruchomić następujące kroki.

Rejestrowanie maszyny wirtualnej w programie SUSE Połączenie

Aby zarejestrować węzeł maszyny wirtualnej w systemie SUSE Połączenie, zastąp te wartości w następującym poleceniu na wszystkich węzłach:

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

Instalowanie rozszerzenia wysokiej dostępności

Aby zainstalować rozszerzenie wysokiej dostępności, uruchom następujące polecenie we wszystkich węzłach:

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

Konfigurowanie dostępu SSH bez hasła między węzłami

Dostęp SSH bez hasła umożliwia maszynom wirtualnym komunikowanie się ze sobą przy użyciu kluczy publicznych SSH. Należy skonfigurować klucze SSH w każdym węźle i skopiować te klucze do każdego węzła.

Generowanie nowych kluczy SSH

Wymagany rozmiar klucza SSH to 4096 bitów. Na każdej maszynie /root/.ssh wirtualnej przejdź do folderu i uruchom następujące polecenie:

ssh-keygen -t rsa -b 4096

W tym kroku może zostać wyświetlony monit o zastąpienie istniejącego pliku SSH. Musisz wyrazić zgodę na ten monit. Nie musisz wprowadzać hasła.

Kopiowanie publicznych kluczy SSH

Na każdej maszynie wirtualnej należy skopiować klucz publiczny z właśnie utworzonego węzła ssh-copy-id przy użyciu polecenia . Jeśli chcesz określić katalog docelowy na docelowej maszynie wirtualnej, możesz użyć parametru -i .

W poniższym poleceniu konto może być tym samym kontem skonfigurowanym <username> dla każdego węzła podczas tworzenia maszyny wirtualnej. Możesz również użyć root konta, ale nie jest to zalecane w środowisku produkcyjnym.

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

Weryfikowanie dostępu bez hasła z każdego węzła

Aby potwierdzić, że klucz publiczny SSH został skopiowany do każdego węzła, użyj ssh polecenia z każdego węzła. Jeśli klucze zostały skopiowane poprawnie, nie zostanie wyświetlony monit o podanie hasła, a połączenie zakończy się pomyślnie.

W tym przykładzie nawiązujemy połączenie z drugim i trzecimi węzłami z pierwszej maszyny wirtualnej (sles1). Po raz kolejny <username> konto może być tym samym kontem skonfigurowanym dla każdego węzła podczas tworzenia maszyny wirtualnej

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

Powtórz ten proces ze wszystkich trzech węzłów, aby każdy węzeł mógł komunikować się z innymi bez konieczności stosowania haseł.

Konfigurowanie rozpoznawania nazw

Rozpoznawanie nazw można skonfigurować przy użyciu systemu DNS lub ręcznie edytując etc/hosts plik w każdym węźle.

Aby uzyskać więcej informacji na temat systemu DNS i usługi Active Directory, zobacz Dołączanie programu SQL Server na hoście z systemem Linux do domeny usługi Active Directory.

Ważne

Zalecamy użycie prywatnego adresu IP w poprzednim przykładzie. Użycie publicznego adresu IP w tej konfiguracji spowoduje niepowodzenie instalacji i uwidocznie maszynę wirtualną w sieciach zewnętrznych.

Maszyny wirtualne i ich adresy IP używane w tym przykładzie są wymienione w następujący sposób:

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

Skonfiguruj klaster

W tym samouczku pierwsza maszyna wirtualna () to węzeł 1, druga maszyna wirtualna (sles2) to węzeł 2, a trzecia maszyna wirtualna (sles3) to węzeł 3.sles1 Aby uzyskać więcej informacji na temat instalacji klastra, zobacz Konfigurowanie programu Pacemaker na serwerze SUSE Linux Enterprise Server na platformie Azure.

Instalacja klastra

  1. Uruchom następujące polecenie, aby zainstalować ha-cluster-bootstrap pakiet w węźle 1, a następnie uruchom ponownie węzeł. W tym przykładzie jest to maszyna wirtualna sles1 .

    sudo zypper install ha-cluster-bootstrap
    

    Po ponownym uruchomieniu węzła uruchom następujące polecenie, aby wdrożyć klaster:

    sudo crm cluster init --name sqlcluster
    

    Zobaczysz podobne dane wyjściowe do następującego przykładu:

    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. Sprawdź stan klastra w węźle 1 przy użyciu następującego polecenia:

    sudo crm status
    

    Dane wyjściowe powinny zawierać następujący tekst, jeśli przebiegł pomyślnie:

    1 node configured
    1 resource instance configured
    
  3. Na wszystkich węzłach zmień hasło na hacluster bardziej bezpieczne przy użyciu następującego polecenia. Należy również zmienić root hasło użytkownika:

    sudo passwd hacluster
    
    sudo passwd root
    
  4. Uruchom następujące polecenie w węźle 2 i węźle 3 , aby najpierw zainstalować crmsh pakiet:

    sudo zypper install crmsh
    

    Teraz uruchom polecenie , aby dołączyć do klastra:

    sudo crm cluster join
    

    Oto niektóre interakcje, których można oczekiwać:

    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. Po dołączeniu wszystkich maszyn do klastra sprawdź zasób, aby sprawdzić, czy wszystkie maszyny wirtualne są w trybie online:

    sudo crm status
    

    Powinny zostać wyświetlone następujące dane wyjściowe:

    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. Zainstaluj składnik zasobu klastra. Uruchom następujące polecenie na wszystkich węzłach.

    sudo zypper in socat
    
  7. azure-lb Zainstaluj składnik. Uruchom następujące polecenie na wszystkich węzłach.

    sudo zypper in resource-agents
    
  8. Skonfiguruj system operacyjny. Wykonaj następujące kroki we wszystkich węzłach.

    1. Edytuj plik konfiguracji:

      sudo vi /etc/systemd/system.conf
      
    2. Zmień wartość na DefaultTasksMax4096:

      #DefaultTasksMax=512
      DefaultTasksMax=4096
      
    3. Zapisz i zamknij edytor vi .

    4. Aby aktywować to ustawienie, uruchom następujące polecenie:

      sudo systemctl daemon-reload
      
    5. Sprawdź, czy zmiana zakończyła się pomyślnie:

      sudo systemctl --no-pager show | grep DefaultTasksMax
      
  9. Zmniejsz rozmiar brudnej pamięci podręcznej. Wykonaj następujące kroki we wszystkich węzłach.

    1. Edytuj plik konfiguracji kontroli systemu:

      sudo vi /etc/sysctl.conf
      
    2. Dodaj następujące dwa wiersze do pliku:

      vm.dirty_bytes = 629145600
      vm.dirty_background_bytes = 314572800
      
    3. Zapisz i zamknij edytor vi .

  10. Zainstaluj zestaw Azure Python SDK na wszystkich węzłach przy użyciu następujących poleceń:

    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
    

Konfigurowanie agenta ogrodzenia

Urządzenie STONITH zapewnia agenta ogrodzenia. Poniższe instrukcje są modyfikowane na potrzeby tego samouczka. Aby uzyskać więcej informacji, zobacz Tworzenie agenta ogrodzenia platformy Azure STONITH urządzenia.

Sprawdź wersję agenta ogrodzenia platformy Azure, aby upewnić się, że został zaktualizowany. Użyj następującego polecenia:

sudo zypper info resource-agents

Powinny zostać wyświetlone podobne dane wyjściowe do poniższego przykładu.

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.

Rejestrowanie nowej aplikacji w usłudze Microsoft Entra ID

Aby zarejestrować nową aplikację w usłudze Microsoft Entra ID (dawniej Azure Active Directory), wykonaj następujące kroki:

  1. Przejdź do https://portal.azure.com.
  2. Otwórz okienko Właściwości identyfikatora entra firmy Microsoft i zapisz element Tenant ID.
  3. Wybierz pozycję Rejestracje aplikacji.
  4. Wybierz opcjęNowa rejestracja.
  5. Wprowadź nazwę, taką jak <resourceGroupName>-app. W przypadku obsługiwanych typów kont wybierz pozycję Konta tylko w tym katalogu organizacyjnym (tylko firma Microsoft — pojedyncza dzierżawa).
  6. Wybierz pozycję Sieć Web w polu Identyfikator URI przekierowania i wprowadź adres URL (na przykład http://localhost) i wybierz pozycję Dodaj. Adres URL logowania może być dowolnym prawidłowym adresem URL. Po zakończeniu wybierz pozycję Zarejestruj.
  7. Wybierz pozycję Certyfikaty i wpisy tajne dla nowej rejestracji aplikacji, a następnie wybierz pozycję Nowy klucz tajny klienta.
  8. Wprowadź opis nowego klucza (klucz tajny klienta), a następnie wybierz pozycję Dodaj.
  9. Zapisz wartość wpisu tajnego. Jest on używany jako hasło dla jednostki usługi.
  10. Wybierz Przegląd. Zapisz identyfikator aplikacji. Jest ona używana jako nazwa użytkownika (identyfikator logowania w poniższych krokach) jednostki usługi.

Tworzenie roli niestandardowej dla agenta ogrodzenia

Postępuj zgodnie z samouczkiem, aby utworzyć rolę niestandardową platformy Azure przy użyciu interfejsu wiersza polecenia platformy Azure.

Plik JSON powinien wyglądać podobnie do poniższego przykładu.

  • Zastąp ciąg <username> wybraną nazwą. Należy unikać duplikowania podczas tworzenia tej definicji roli.
  • Zastąp <subscriptionId> ciąg identyfikatorem subskrypcji platformy 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>"
  ]
}

Aby dodać rolę, uruchom następujące polecenie:

  • Zastąp <filename> ciąg nazwą pliku.
  • Jeśli wykonujesz polecenie ze ścieżki innej niż folder, do którego jest zapisywany plik, dołącz ścieżkę folderu pliku w poleceniu .
az role definition create --role-definition "<filename>.json"

Powinny zostać wyświetlone następujące dane wyjściowe:

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

Przypisywanie roli niestandardowej do jednostki usługi

Przypisz rolę Linux Fence Agent Role-<username> niestandardową utworzoną w ostatnim kroku do jednostki usługi. Powtórz te kroki dla wszystkich węzłów.

Ostrzeżenie

Nie używaj tutaj roli Właściciel.

  1. Przejdź do strony https://portal.azure.com
  2. Otwórz okienko Wszystkie zasoby
  3. Wybierz maszynę wirtualną pierwszego węzła klastra
  4. Wybierz pozycję Kontrola dostępu (Zarządzanie dostępem i tożsamościami)
  5. Wybierz pozycję Dodaj przypisania ról
  6. Wybierz rolę Linux Fence Agent Role-<username> z listy Rola
  7. Pozostaw opcję Przypisz dostęp jako domyślny Users, group, or service principal.
  8. Na liście Wybierz wprowadź nazwę utworzonej wcześniej aplikacji, na przykład <resourceGroupName>-app.
  9. Wybierz pozycję Zapisz.

Tworzenie urządzeń STONITH

  1. Uruchom następujące polecenia w węźle 1:

    • <ApplicationID> Zastąp wartość identyfikatorem z rejestracji aplikacji.
    • Zastąp wartość <servicePrincipalPassword> wartością z klucza tajnego klienta.
    • Zastąp element <resourceGroupName> grupą zasobów z subskrypcji używanej na potrzeby tego samouczka.
    • Zastąp <subscriptionId> wartości <tenantID> i z subskrypcji platformy Azure.
  2. Uruchom polecenie crm configure , aby otworzyć wiersz polecenia crm :

    sudo crm configure
    
  3. W wierszu polecenia crm uruchom następujące polecenie, aby skonfigurować właściwości zasobu, które tworzy zasób o nazwie rsc_st_azure , jak pokazano w poniższym przykładzie:

    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. Uruchom następujące polecenia, aby skonfigurować agenta ogrodzenia:

    sudo crm configure property stonith-timeout=900
    sudo crm configure property stonith-enabled=true
    sudo crm configure property concurrent-fencing=true
    
  5. Sprawdź stan klastra, aby sprawdzić, czy funkcja STONITH została włączona:

    sudo crm status
    

    Powinny zostać wyświetlone dane wyjściowe podobne do następującego tekstu:

    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
    

Instalowanie programu SQL Server i narzędzi mssql-tools

Użyj poniższej sekcji, aby zainstalować program SQL Server i narzędzia mssql-tools. Aby uzyskać więcej informacji, zobacz Instalowanie programu SQL Server na serwerze SUSE Linux Enterprise Server.

Wykonaj te kroki we wszystkich węzłach w tej sekcji.

Instalowanie programu SQL Server na maszynach wirtualnych

Do zainstalowania programu SQL Server służą następujące polecenia:

  1. Pobierz plik konfiguracji repozytorium SLES programu Microsoft SQL Server 2019:

    sudo zypper addrepo -fc https://packages.microsoft.com/config/sles/15/mssql-server-2022.repo
    
  2. Odśwież repozytoria.

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

    Aby upewnić się, że klucz podpisywania pakietu firmy Microsoft jest zainstalowany w systemie, użyj następującego polecenia, aby zaimportować klucz:

    sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
    
  3. Uruchom następujące polecenia, aby zainstalować program SQL Server:

    sudo zypper install -y mssql-server
    
  4. Po zakończeniu instalacji pakietu uruchom mssql-conf setup polecenie i postępuj zgodnie z monitami, aby ustawić hasło administratora systemu i wybrać wersję.

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

    Uwaga

    Upewnij się, że określono silne hasło dla konta sa (minimalna długość 8 znaków, w tym wielkie i małe litery, podstawowe 10 cyfr i/lub symbole inne niż alfanumeryczne).

  5. Po zakończeniu konfiguracji sprawdź, czy usługa jest uruchomiona:

    systemctl status mssql-server
    

Instalowanie narzędzi wiersza polecenia programu SQL Server

Poniższe kroki umożliwiają zainstalowanie narzędzi wiersza polecenia programu SQL Server, czyli sqlcmd i bcp.

  1. Dodaj repozytorium programu Microsoft SQL Server do aplikacji Zypper.

    sudo zypper addrepo -fc https://packages.microsoft.com/config/sles/15/prod.repo
    
  2. Odśwież repozytoria.

    sudo zypper --gpg-auto-import-keys refresh
    
  3. Zainstaluj narzędzia mssql-tools za pomocą pakietu dewelopera unixODBC . Aby uzyskać więcej informacji, zobacz Instalowanie sterownika Microsoft ODBC dla programu SQL Server (Linux).

    sudo zypper install -y mssql-tools unixODBC-devel
    

Dla wygody możesz dodać /opt/mssql-tools/bin/ do PATH zmiennej środowiskowej. Dzięki temu można uruchamiać narzędzia bez określania pełnej ścieżki. Uruchom następujące polecenia, aby zmodyfikować zmienną PATH zarówno dla sesji logowania, jak i sesji interaktywnych/bez logowania:

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

Instalowanie agenta wysokiej dostępności programu SQL Server

Uruchom następujące polecenie na wszystkich węzłach, aby zainstalować pakiet agenta wysokiej dostępności dla programu SQL Server:

sudo zypper install mssql-server-ha

Otwieranie portów dla usług wysokiej dostępności

  1. Następujące porty zapory można otworzyć na wszystkich węzłach dla usług SQL Server i HA: 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
    

Konfigurowanie grupy dostępności

Wykonaj poniższe kroki, aby skonfigurować zawsze włączoną grupę dostępności programu SQL Server dla maszyn wirtualnych. Aby uzyskać więcej informacji, zobacz Konfigurowanie zawsze włączonych grup dostępności programu SQL Server pod kątem wysokiej dostępności w systemie Linux

Włączanie grup dostępności i ponowne uruchamianie programu SQL Server

Włącz grupy dostępności w każdym węźle, który hostuje wystąpienie programu SQL Server. Następnie uruchom ponownie usługę mssql-server . Uruchom następujące polecenia w każdym węźle:

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

Tworzenie certyfikatu

Firma Microsoft nie obsługuje uwierzytelniania usługi Active Directory w punkcie końcowym grupy dostępności. W związku z tym należy użyć certyfikatu do szyfrowania punktu końcowego grupy dostępności.

  1. Połączenie do wszystkich węzłów przy użyciu programu SQL Server Management Studio (SSMS) lub sqlcmd. Uruchom następujące polecenia, aby włączyć sesję AlwaysOn_health i utworzyć klucz główny:

    Ważne

    Jeśli łączysz się zdalnie z wystąpieniem programu SQL Server, musisz otworzyć port 1433 w zaporze. Należy również zezwolić na połączenia przychodzące z portem 1433 w sieciowej grupie zabezpieczeń dla każdej maszyny wirtualnej. Aby uzyskać więcej informacji, zobacz Tworzenie reguły zabezpieczeń na potrzeby tworzenia reguły zabezpieczeń dla ruchu przychodzącego.

    • Zastąp element <MasterKeyPassword> własnym hasłem.
    ALTER EVENT SESSION AlwaysOn_health ON SERVER
        WITH (STARTUP_STATE = ON);
    GO
    
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<MasterKeyPassword>';
    GO
    
  2. Połączenie do repliki podstawowej przy użyciu programu SSMS lub sqlcmd. Poniższe polecenia tworzą certyfikat w lokalizacji /var/opt/mssql/data/dbm_certificate.cer i klucz prywatny w var/opt/mssql/data/dbm_certificate.pvk podstawowej repliki programu SQL Server:

    • Zastąp element <PrivateKeyPassword> własnym hasłem.
    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
    

Zamknij sesję sqlcmd , uruchamiając exit polecenie i wróć do sesji SSH.

Skopiuj certyfikat do replik pomocniczych i utwórz certyfikaty na serwerze

  1. Skopiuj dwa pliki, które zostały utworzone do tej samej lokalizacji na wszystkich serwerach, które będą hostować repliki dostępności.

    Na serwerze podstawowym uruchom następujące scp polecenie, aby skopiować certyfikat na serwery docelowe:

    • Zastąp <username> wartości i sles2 nazwą użytkownika i docelową nazwą maszyny wirtualnej, której używasz.
    • Uruchom to polecenie dla wszystkich replik pomocniczych.

    Uwaga

    Nie trzeba uruchamiać sudo -ipolecenia , co daje środowisko główne. Zamiast tego można uruchomić sudo polecenie przed każdym poleceniem.

    # 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. Na serwerze docelowym uruchom następujące polecenie:

    • Zastąp <username> ciąg nazwą użytkownika.
    • Polecenie mv przenosi pliki lub katalog z jednego miejsca do innego.
    • Polecenie chown służy do zmiany właściciela i grupy plików, katalogów lub linków.
    • Uruchom te polecenia dla wszystkich replik pomocniczych.
    sudo -i
    mv /home/<username>/dbm_certificate.* /var/opt/mssql/data/
    cd /var/opt/mssql/data
    chown mssql:mssql dbm_certificate.*
    
  3. Poniższy skrypt języka Transact-SQL tworzy certyfikat z kopii zapasowej utworzonej w podstawowej repliki programu SQL Server. Zaktualizuj skrypt przy użyciu silnych haseł. Hasło odszyfrowywania jest tym samym hasłem, które zostało użyte do utworzenia pliku pvk w poprzednim kroku. Aby utworzyć certyfikat, uruchom następujący skrypt przy użyciu narzędzia sqlcmd lub SSMS na wszystkich serwerach pomocniczych:

    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
    

Tworzenie punktów końcowych dublowania bazy danych na wszystkich replikach

Uruchom następujący skrypt we wszystkich wystąpieniach programu SQL Server przy użyciu narzędzia sqlcmd lub programu 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

Tworzenie grupy dostępności

Połączenie do wystąpienia programu SQL Server, które hostuje replikę podstawową przy użyciu programu sqlcmd lub SSMS. Uruchom następujące polecenie, aby utworzyć grupę dostępności:

  • Zastąp ag1 ciąg żądaną nazwą grupy dostępności.
  • Zastąp sles1wartości , sles2i sles3 nazwami wystąpień programu SQL Server hostujących repliki.
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

Tworzenie identyfikatora logowania programu SQL Server dla programu Pacemaker

We wszystkich wystąpieniach programu SQL Server utwórz identyfikator logowania programu SQL Server dla programu Pacemaker. Poniższy kod Transact-SQL tworzy identyfikator logowania.

  • Zastąp <password> ciąg własnym złożonym hasłem.
USE [master]
GO

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

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

We wszystkich wystąpieniach programu SQL Server zapisz poświadczenia używane do logowania programu SQL Server.

  1. Utwórz plik:

    sudo vi /var/opt/mssql/secrets/passwd
    
  2. Dodaj następujące dwa wiersze do pliku:

    pacemakerLogin
    <password>
    

    Aby zamknąć edytor vi , najpierw naciśnij klawisz Esc , a następnie wprowadź polecenie :wq , aby zapisać plik i zamknąć.

  3. Ustaw plik tylko do odczytu według katalogu głównego:

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

Dołączanie replik pomocniczych do grupy dostępności

  1. W replikach pomocniczych uruchom następujące polecenia, aby dołączyć je do grupy dostępności:

    ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
    GO
    
    ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
    GO
    
  2. Uruchom następujący skrypt Języka Transact-SQL w repliki podstawowej i każdej repliki pomocniczej:

    GRANT ALTER, CONTROL, VIEW DEFINITION
        ON AVAILABILITY GROUP::ag1 TO pacemakerLogin;
    GO
    
    GRANT VIEW SERVER STATE TO pacemakerLogin;
    GO
    
  3. Po dołączeniu replik pomocniczych można je zobaczyć w programie SSMS Eksplorator obiektów, rozwijając węzeł Zawsze włączone wysokiej dostępności:

    Screenshot shows the primary and secondary availability replicas.

Dodawanie bazy danych do grupy dostępności

Ta sekcja jest zgodna z artykułem dotyczącym dodawania bazy danych do grupy dostępności.

W tym kroku są używane następujące polecenia języka Transact-SQL. Uruchom następujące polecenia w repliki podstawowej:

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

Sprawdź, czy baza danych została utworzona na serwerach pomocniczych

Na każdej pomocniczej repliki programu SQL Server uruchom następujące zapytanie, aby sprawdzić, czy baza danych db1 została utworzona i ma stan SYNCD:

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

Jeśli lista synchronization_state_desc zsynchronizowana dla db1elementu oznacza, że repliki są synchronizowane. Sekundy są wyświetlane db1 w repliki podstawowej.

Tworzenie zasobów grupy dostępności w klastrze Pacemaker

Uwaga

Komunikacja bez uprzedzeń

Ten artykuł zawiera odwołania do terminu niewolnik, termin Microsoft uznaje za obraźliwe w przypadku użycia w tym kontekście. Termin pojawia się w tym artykule, ponieważ jest on obecnie wyświetlany w oprogramowaniu. Po usunięciu terminu z oprogramowania usuniemy go z artykułu.

W tym artykule przedstawiono przewodnik tworzenia zasobów grupy dostępności w klastrze Pacemaker.

Włącz program Pacemaker

Włącz program Pacemaker, aby automatycznie się uruchamiał.

Uruchom następujące polecenie we wszystkich węzłach w klastrze.

sudo systemctl enable pacemaker

Tworzenie zasobu klastra grupy dostępności

  1. Uruchom polecenie crm configure , aby otworzyć wiersz polecenia crm :

    sudo crm configure
    
  2. W wierszu polecenia crm uruchom następujące polecenie, aby skonfigurować właściwości zasobu. Następujące polecenia tworzą zasób ag_cluster w grupie ag1dostępności .

    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
    

    Napiwek

    Wpisz polecenie quit , aby zamknąć wiersz polecenia crm .

  3. Ustaw ograniczenie współlokacyjne dla wirtualnego adresu IP, aby było uruchamiane w tym samym węźle co węzeł podstawowy:

    sudo crm configure
    colocation vip_on_master inf: admin-ip ms-ag_cluster: Master
    commit
    quit
    
  4. Dodaj ograniczenie porządkowania, aby zapobiec tymczasowemu wskazywaniu węzła przez adres IP przy użyciu pomocniczego trybu failover przed przejściem w tryb failover. Uruchom następujące polecenie, aby utworzyć ograniczenie porządkowania:

    sudo crm configure
    order ag_first inf: ms-ag_cluster:promote admin-ip:start
    commit
    quit
    
  5. Sprawdź stan klastra przy użyciu polecenia :

    sudo crm status
    

    Dane wyjściowe powinny być podobne do następującego przykładu:

    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. Uruchom następujące polecenie, aby przejrzeć ograniczenia:

    sudo crm configure show
    

    Dane wyjściowe powinny być podobne do następującego przykładu:

    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
    

Testowanie pracy w trybie failover

Aby upewnić się, że konfiguracja zakończyła się pomyślnie, przetestuj tryb failover. Aby uzyskać więcej informacji, zobacz Tryb failover zawsze włączonej grupy dostępności w systemie Linux.

  1. Uruchom następujące polecenie, aby ręcznie przejąć replikę podstawową w tryb failover na sles2. Zastąp sles2 ciąg wartością nazwy serwera.

    sudo crm resource move ag_cluster sles2
    

    Dane wyjściowe powinny być podobne do następującego przykładu:

    INFO: Move constraint created for ms-ag_cluster to sles2
    INFO: Use `crm resource clear ms-ag_cluster` to remove this constraint
    
  2. Sprawdź stan klastra:

    sudo crm status
    

    Dane wyjściowe powinny być podobne do następującego przykładu:

    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. Po pewnym czasie maszyna wirtualna sles2 jest teraz podstawowa, a pozostałe dwie maszyny wirtualne są pomocniczymi. Ponownie uruchom polecenie sudo crm status i przejrzyj dane wyjściowe podobne do poniższego przykładu:

    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. Ponownie sprawdź ograniczenia przy użyciu polecenia crm config show. Zwróć uwagę, że dodano kolejne ograniczenie z powodu ręcznego przejścia w tryb failover.

  5. Usuń ograniczenie o identyfikatorze cli-prefer-ag_cluster, używając następującego polecenia:

    crm configure
    delete cli-prefer-ms-ag_cluster
    commit
    

Testowanie ogrodzenia

Możesz przetestować STONITH, uruchamiając następujące polecenie. Spróbuj uruchomić poniższe polecenie z sles1 polecenia dla polecenia sles3.

sudo crm node fence sles3

Następny krok