Руководство по настройке групп доступности для SQL Server на виртуальных машинах SLES в Azure

Применимо к:SQL Server на виртуальной машине Azure

Примечание.

Мы используем SQL Server 2022 (16.x) с SUSE Linux Enterprise Server версии 15 в этом руководстве, но для настройки высокой доступности можно использовать SQL Server 2019 (15.x) с SLES версии 12 или SLES версии 15.

В этом руководстве описано следующее:

  • Создание новой группы ресурсов, группы доступности и виртуальных машин Linux
  • Включение высокого уровня доступности
  • Создание кластера Pacemaker
  • Настройка агента ограждения путем создания устройства STONITH
  • Установка SQL Server и mssql-tools в SLES
  • Настройка группы доступности Always On SQL Server
  • Настройка ресурсов группы доступности в кластере Pacemaker
  • Проверка отработки отказа и агента ограждения

В этом руководстве используется Azure CLI для развертывания ресурсов в Azure.

Если у вас нет подписки Azure, создайте бесплатную учетную запись, прежде чем приступить к работе.

Необходимые компоненты

  • Используйте среду Bash в Azure Cloud Shell. Дополнительные сведения см . в кратком руководстве по Bash в Azure Cloud Shell.

  • Если вы предпочитаете выполнять справочные команды CLI локально, установите Azure CLI. Если вы работаете в Windows или macOS, Azure CLI можно запустить в контейнере Docker. Дополнительные сведения см. в статье Как запустить Azure CLI в контейнере Docker.

    • Если вы используете локальную установку, выполните вход в Azure CLI с помощью команды az login. Чтобы выполнить аутентификацию, следуйте инструкциям в окне терминала. Сведения о других возможностях, доступных при входе, см. в статье Вход с помощью Azure CLI.

    • Установите расширение Azure CLI при первом использовании, когда появится соответствующий запрос. Дополнительные сведения о расширениях см. в статье Использование расширений с Azure CLI.

    • Выполните команду az version, чтобы узнать установленную версию и зависимые библиотеки. Чтобы обновиться до последней версии, выполните команду az upgrade.

  • Для работы с этой статьей требуется Azure CLI версии 2.0.30 или более поздней. Если вы используете Azure Cloud Shell, последняя версия уже установлена.

Создание или изменение группы ресурсов

Если у вас несколько подписок, задайте подписку, в которую требуется развернуть эти ресурсы.

Выполните следующую команду, чтобы создать группу ресурсов <resourceGroupName> в регионе. Замените <resourceGroupName> именем по своему выбору. В этом учебнике используется East US 2. Дополнительные сведения см. Краткое руководство. Создание виртуальной машины Linux с помощью Azure CLI.

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

Создание группы доступности

Следующим шагом является создание группы доступности. Выполните следующую команду в Azure Cloud Shell и замените <resourceGroupName> именем группы ресурсов. Выберите имя для <availabilitySetName>.

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

После выполнения команды должны появиться следующие результаты:

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

Создание виртуальной сети и подсети

  1. Создайте именованную подсеть с предопределенным диапазоном IP-адресов. Замените эти значения в следующей команде:

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

    Предыдущая команда создает виртуальную сеть и подсеть, содержащую настраиваемый диапазон IP-адресов.

Создание виртуальных машин SLES в группе доступности

  1. Получите список образов виртуальных машин, которые предлагают SLES версии 15 с пакетом обновления 4 (SP4) с BYOS (принести собственную подписку). Вы также можете использовать виртуальную машинуsles-15-sp4-basic SUSE Enterprise Linux 15 с пакетом обновления 4 (SP4) и "Исправление".

    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"
    

    При поиске образов BYOS вы увидите следующие результаты:

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

    В этом учебнике используется SUSE:sles-15-sp3-byos:gen1:2022.11.10.

    Важно!

    Имена компьютеров должны содержать менее 15 символов, чтобы настроить группу доступности. Имена пользователей не могут содержать символы верхнего регистра, а пароли должны иметь от 12 до 72 символов.

  2. Создайте три виртуальных машины в группе доступности. Замените эти значения в следующей команде:

    • <resourceGroupName>
    • <VM-basename>
    • <availabilitySetName>
    • <VM-Size> - Примером будет "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
    

Предыдущая команда создает виртуальные машины с помощью ранее определенной виртуальной сети. Дополнительные сведения о различных конфигурациях см. в статье az vm create (Создание виртуальных машин Azure).

Команда также включает --os-disk-size-gb параметр для создания пользовательского диска ОС размером 128 ГБ. Если увеличить этот размер позже, разверните соответствующие тома папок для размещения установки, настройте диспетчер логических томов (LVM).

После завершения выполнения команды для каждой виртуальной машины вы должны получить результаты, аналогичные приведенным ниже.

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

Проверка подключения к созданным виртуальным машинам

Подключение на каждую из виртуальных машин с помощью следующей команды в Azure Cloud Shell. Если вы не можете найти IP-адреса виртуальных машин, следуйте инструкциям из этого краткого руководства в Azure Cloud Shell.

ssh <username>@<publicIPAddress>

Если установка прошла успешно, отобразятся следующие выходные данные представляющие терминал Linux:

[<username>@sles1 ~]$

Введите exit чтобы выйти из сеанса SSH.

Зарегистрируйтесь в SUSE Подключение и установите пакеты высокой доступности

Чтобы завершить работу с этим руководством, виртуальные машины должны быть зарегистрированы в SUSE Подключение для получения обновлений и поддержки. Затем можно установить модуль расширения высокой доступности или шаблон, который является набором пакетов, которые обеспечивают высокий уровень доступности.

Проще открыть сеанс SSH на каждой из виртуальных машин (узлов), так как те же команды должны выполняться на каждой виртуальной машине по всей статье.

Если вы копируете и вставляете несколько sudo команд и запрашиваете пароль, дополнительные команды не будут выполняться. Выполните каждую команду по отдельности.

Подключение на каждый узел виртуальной машины, чтобы выполнить следующие действия.

Регистрация виртуальной машины в SUSE Подключение

Чтобы зарегистрировать узел виртуальной машины в SUSE Подключение, замените эти значения в следующей команде на всех узлах:

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

Установка расширения высокой доступности

Чтобы установить расширение высокой доступности, выполните следующую команду на всех узлах:

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

Настройка доступа без пароля по протоколу SSH между узлами

Доступ без пароля SSH позволяет виртуальным машинам взаимодействовать друг с другом с помощью открытых ключей SSH. Необходимо настроить ключи SSH на каждом узле и скопировать эти ключи на каждый узел.

Создание новых ключей SSH

Требуемый размер ключа SSH составляет 4096 битов. На каждой виртуальной /root/.ssh машине перейдите в папку и выполните следующую команду:

ssh-keygen -t rsa -b 4096

На этом шаге может потребоваться перезаписать существующий SSH-файл. Вы должны согласиться с этим запросом. Не нужно вводить парольную фразу.

Копирование открытых ключей SSH

На каждой виртуальной машине необходимо скопировать открытый ключ из только что созданного узла с помощью ssh-copy-id команды. Если вы хотите указать целевой каталог на целевой виртуальной машине, можно использовать -i этот параметр.

В следующей команде учетная запись может быть той же учетной записью, <username> настроенной для каждого узла при создании виртуальной машины. Вы также можете использовать учетную запись root, но это не рекомендуется делать в рабочей среде.

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

Проверка доступа без пароля с каждого узла

Чтобы убедиться, что открытый ключ SSH был скопирован на каждый узел, используйте ssh команду с каждого узла. Если вы скопировали ключи правильно, вам не будет предложено ввести пароль, и подключение будет успешно установлено.

В этом примере мы подключаемся ко второму и третьему узлам из первой виртуальной машины (sles1). Еще раз <username> учетная запись может быть той же учетной записью, настроенной для каждого узла при создании виртуальной машины.

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

Повторите этот процесс со всех трех узлов, чтобы каждый узел могли взаимодействовать с другими, не требуя паролей.

Настройка разрешения имен

Можно настроить разрешение имен с помощью DNS или вручную изменить etc/hosts файл на каждом узле.

Дополнительные сведения о DNS и Active Directory см. в разделе "Присоединение к SQL Server" на узле Linux к домену Active Directory.

Важно!

Рекомендуется использовать частный IP-адрес в предыдущем примере. Использование общедоступного IP-адреса в этой конфигурации приведет к сбою установки и предоставит виртуальную машину внешним сетям.

Виртуальные машины и их IP-адрес, используемые в этом примере, перечислены следующим образом:

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

Настройка кластера

В этом руководстве первая виртуальная машина () — узел 1, вторая виртуальная машина (sles2) — узел 2, а третья виртуальная машина (sles3) — узел 3.sles1 Дополнительные сведения об установке кластера см. в статье Настройка Pacemaker на SUSE Linux Enterprise Server в Azure.

Установка кластера

  1. Выполните следующую команду, чтобы установить ha-cluster-bootstrap пакет на узле 1, а затем перезапустить узел. В этом примере это виртуальная sles1 машина.

    sudo zypper install ha-cluster-bootstrap
    

    После перезапуска узла выполните следующую команду, чтобы развернуть кластер:

    sudo crm cluster init --name sqlcluster
    

    Вы увидите аналогичные выходные данные в следующем примере:

    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. Проверьте состояние кластера на узле 1 с помощью следующей команды:

    sudo crm status
    

    Выходные данные должны содержать следующий текст, если он был успешным:

    1 node configured
    1 resource instance configured
    
  3. На всех узлах измените пароль hacluster на что-то более безопасное с помощью следующей команды. Кроме того, необходимо изменить root пароль пользователя:

    sudo passwd hacluster
    
    sudo passwd root
    
  4. Выполните следующую команду на узле 2 и узле 3 , чтобы сначала установить crmsh пакет:

    sudo zypper install crmsh
    

    Теперь выполните команду, чтобы присоединиться к кластеру:

    sudo crm cluster join
    

    Ниже приведены некоторые из ожидаемых действий.

    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. Присоединив все компьютеры к кластеру, проверка ресурс, чтобы узнать, подключены ли все виртуальные машины к сети:

    sudo crm status
    

    Должен появиться следующий результат:

    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. Установите компонент ресурса кластера. Выполните следующую команду на всех узлах.

    sudo zypper in socat
    
  7. azure-lb Установите компонент. Выполните следующую команду на всех узлах.

    sudo zypper in resource-agents
    
  8. Настройка операционной системы. Выполните следующие действия на всех узлах.

    1. Измените файл конфигурации:

      sudo vi /etc/systemd/system.conf
      
    2. Измените значение 4096на DefaultTasksMax :

      #DefaultTasksMax=512
      DefaultTasksMax=4096
      
    3. Сохраните и закройте редактор vi .

    4. Чтобы активировать этот параметр, выполните следующую команду:

      sudo systemctl daemon-reload
      
    5. Проверьте, успешно ли выполнено изменение:

      sudo systemctl --no-pager show | grep DefaultTasksMax
      
  9. Уменьшите размер "грязного" кэша. Выполните следующие действия на всех узлах.

    1. Измените файл конфигурации системы управления:

      sudo vi /etc/sysctl.conf
      
    2. Добавьте в файл следующие две строки:

      vm.dirty_bytes = 629145600
      vm.dirty_background_bytes = 314572800
      
    3. Сохраните и закройте редактор vi .

  10. Установите пакет SDK Для Python Azure на всех узлах со следующими командами:

    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
    

Настройка агента ограждения

Устройство STONITH предоставляет агент ограждения. Приведенные ниже инструкции изменены для данного руководства. Дополнительные сведения см. в статье "Создание устройства STONITH агента забора Azure".

Проверьте версию агента забора Azure, чтобы убедиться, что она обновлена. Используйте следующую команду:

sudo zypper info resource-agents

В приведенном ниже примере вы увидите похожие выходные данные.

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.

Регистрация нового приложения в идентификаторе Microsoft Entra

Чтобы зарегистрировать новое приложение в идентификаторе Microsoft Entra (прежнее название — Azure Active Directory), выполните следующие действия:

  1. Переход к https://portal.azure.com.
  2. Откройте область свойств идентификатора Microsoft Entra и запишите ееTenant ID.
  3. Щелкните Регистрация приложений.
  4. Выберите Создать регистрацию.
  5. Введите имя, например<resourceGroupName>-app. Для поддерживаемых типов учетных записей выберите учетные записи только в этом каталоге организации (только Майкрософт — один клиент).
  6. Выберите веб-код ресурса (URI) перенаправления и введите URL-адрес (например, http://localhost) и нажмите кнопку "Добавить". URL-адрес входа может быть любым допустимым URL-адресом. После этого нажмите кнопку "Зарегистрировать".
  7. Выберите сертификаты и секреты для новой регистрации приложения, а затем выберите новый секрет клиента.
  8. Введите описание нового ключа (секрет клиента), а затем нажмите кнопку "Добавить".
  9. Запишите значение секрета. Он используется в качестве пароля для субъекта-службы.
  10. Выберите Обзор. Запишите идентификатор приложения. Он используется в качестве имени пользователя (идентификатор входа, описанный ниже) субъекта-службы.

Создание настраиваемой роли для агента ограждения

Следуйте инструкциям из руководства по созданию настраиваемой Azure с помощью Azure CLI.

Json-файл должен выглядеть примерно так, как показано в следующем примере.

  • Замените <username> именем по своему выбору. Это позволяет избежать дублирования при создании определения роли.
  • Замените <subscriptionId> идентификатором своей подписки 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>"
  ]
}

Чтобы добавить роль, выполните следующую команду:

  • Замените <filename> на имя файла.
  • Если вы выполняете команду из пути, отличного от папки, в которую сохранен файл, добавьте путь к папке файла в команду.
az role definition create --role-definition "<filename>.json"

Должен появиться следующий результат:

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

Назначение пользовательской роли субъекту-службе

Назначьте пользовательскую роль Linux Fence Agent Role-<username> , созданную на последнем шаге, субъекту-службе. Повторите эти действия для всех узлов.

Предупреждение

Не используйте роль владельца из этой роли.

  1. Перейдите по адресу https://portal.azure.com.
  2. Открытие области "Все ресурсы"
  3. Выберите виртуальную машину первого узла кластера.
  4. Выберите Управление доступом (IAM)
  5. ВыберитеДобавить назначение ролей
  6. Выберите роль Linux Fence Agent Role-<username> из списка Роль
  7. Оставьте доступ назначить по умолчанию Users, group, or service principal.
  8. В списке "Выбор " введите имя созданного ранее приложения, например <resourceGroupName>-app.
  9. Выберите Сохранить.

Создание устройств STONITH

  1. Выполните следующие команды на узле 1:

    • Замените <ApplicationID> значением идентификатора из регистрации приложения.
    • Замените <servicePrincipalPassword> значением из секрета клиента.
    • Замените <resourceGroupName> группой ресурсов из подписки, используемой в этом учебнике.
    • Замените <tenantID> и <subscriptionId> из подписки Azure.
  2. Выполните команду crm configure , чтобы открыть запрос crm :

    sudo crm configure
    
  3. В командной строке crm выполните следующую команду, чтобы настроить свойства ресурса, создающие ресурс, как rsc_st_azure показано в следующем примере:

    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. Выполните следующие команды, чтобы настроить агент ограждения:

    sudo crm configure property stonith-timeout=900
    sudo crm configure property stonith-enabled=true
    sudo crm configure property concurrent-fencing=true
    
  5. Проверьте состояние кластера, чтобы увидеть, что STONITH включен:

    sudo crm status
    

    Выходные данные должны иметь следующий вид:

    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
    

Установка SQL Server и средств mssql

Используйте приведенный ниже раздел для установки SQL Server и mssql-tools. Дополнительные сведения см. в статье "Установка SQL Server на SUSE Linux Enterprise Server".

Выполните эти действия на всех узлах в этом разделе.

Установка SQL Server на виртуальных машинах

Для установки SQL Server используются следующие команды:

  1. Скачайте файл конфигурации репозитория Microsoft SQL Server 2019 SLES:

    sudo zypper addrepo -fc https://packages.microsoft.com/config/sles/15/mssql-server-2022.repo
    
  2. Обновите репозитории.

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

    Чтобы убедиться в том, что ключ подписывания пакета от Майкрософт установлен в системе, выполните следующую команду, чтобы импортировать ключ:

    sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
    
  3. Выполните следующие команды для установки SQL Server:

    sudo zypper install -y mssql-server
    
  4. После завершения установки пакета запустите mssql-conf setup и следуйте инструкциям, чтобы задать пароль SA и выбрать выпуск.

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

    Примечание.

    Для учетной записи системного администратора необходимо установить надежный пароль (минимальная длина — 8 символов; должен содержать строчные и прописные буквы, десятичные цифры и (или) символы, отличные от букв и цифр).

  5. По завершении настройки убедитесь в том, что служба работает.

    systemctl status mssql-server
    

Установка средств командной строки SQL Server

Ниже приведены шаги по установке средств командной строки SQL Server, а именно sqlcmd и bcp.

  1. Добавьте репозиторий Microsoft SQL Server в Zypper.

    sudo zypper addrepo -fc https://packages.microsoft.com/config/sles/15/prod.repo
    
  2. Обновите репозитории.

    sudo zypper --gpg-auto-import-keys refresh
    
  3. Установите mssql-tools с пакетом разработчика unixODBC . Дополнительные сведения см. в разделе Установка драйвера Microsoft ODBC для SQL Server (Linux).

    sudo zypper install -y mssql-tools unixODBC-devel
    

Для удобства можно добавить /opt/mssql-tools/bin/ в PATH переменную среды. Это позволит запускать программы, не указывая полный путь. Выполните следующие команды, чтобы изменить переменную среды PATH как для сеансов входа в систему, так и для интерактивных сеансов и сеансов без входа в систему:

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

Установка агента высокого уровня доступности SQL Server

Выполните следующую команду на всех узлах , чтобы установить пакет агента высокой доступности для SQL Server:

sudo zypper install mssql-server-ha

Открытие портов для служб высокой доступности

  1. Вы можете открыть следующие порты брандмауэра на всех узлах для служб SQL Server и ВЫСОКОГО уровня доступности: 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
    

Настройка группы доступности

Используйте следующие шаги для настройки группы доступности Always On SQL Server для виртуальных машин. Дополнительные сведения см. в разделе Настройка группы доступности Always On SQL Server для обеспечения высокого уровня доступности в Linux

Включение групп доступности и перезапуск SQL Server

Включите группы доступности на каждом узле, на котором размещен экземпляр SQL Server. Затем перезапустите mssql-server службу. Выполните следующие команды на каждом узле:

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

Создание сертификата

Корпорация Майкрософт не поддерживает проверку подлинности Active Directory в конечной точке группы доступности. Поэтому необходимо использовать сертификат для шифрования конечной точки группы доступности.

  1. Подключение ко всем узлам с помощью SQL Server Management Studio (SSMS) или sqlcmd. Чтобы включить сеанс AlwaysOn_health и создать главный ключ, выполните следующие команды:

    Важно!

    Если вы подключаетесь удаленно к экземпляру SQL Server, вам потребуется открыть порт 1433 на брандмауэре. Кроме того, для каждой виртуальной машины в группе безопасности сети необходимо разрешить входящие соединение к порту 1433. Дополнительные сведения о создании правила безопасности для входящего трафика см. в разделе Create a security rule (Создание правила безопасности).

    • Замените <MasterKeyPassword> собственным паролем.
    ALTER EVENT SESSION AlwaysOn_health ON SERVER
        WITH (STARTUP_STATE = ON);
    GO
    
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<MasterKeyPassword>';
    GO
    
  2. Подключение к основному реплика с помощью SSMS или sqlcmd. Приведенные ниже команды создают сертификат по /var/opt/mssql/data/dbm_certificate.cer адресу и закрытый ключ на var/opt/mssql/data/dbm_certificate.pvk основном сервере SQL Server реплика:

    • Замените <PrivateKeyPassword> собственным паролем.
    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
    

Выйдите из сеанса sqlcmd , выполнив exit команду, и вернитесь к сеансу SSH.

Копирование сертификата во вторичные реплики и создание сертификатов на сервере

  1. Скопируйте два созданные файлы в одно и то же место на всех серверах, где будут размещаться реплики доступности.

    Выполните следующую команду scp на сервере-источнике, чтобы скопировать сертификат на целевые серверы:

    • sles2 Замените <username> имя пользователя и целевое имя виртуальной машины, которые вы используете.
    • Выполните эту команду для всех вторичных реплик.

    Примечание.

    Вам не нужно запускать sudo -i, который предоставляет корневую среду. Вместо этого можно выполнить sudo команду перед каждой командой.

    # 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. Выполните следующую команду на целевом сервере:

    • Замените <username> именем пользователя.
    • Команда mv перемещает файлы или каталоги из одного места в другое.
    • Команда chown используется для изменения владельца и группы файлов, каталогов или ссылок.
    • Выполните эти команды для всех вторичных реплик.
    sudo -i
    mv /home/<username>/dbm_certificate.* /var/opt/mssql/data/
    cd /var/opt/mssql/data
    chown mssql:mssql dbm_certificate.*
    
  3. Следующий сценарий Transact-SQL создает сертификат из резервной копии, созданной в первичной реплике SQL Server. Обновите сценарий, задав надежные пароли. Для расшифровки используется тот же пароль, что и при создании PVK-файла в предыдущем шаге. Чтобы создать сертификат, выполните следующий сценарий с помощью sqlcmd или 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
    

Создайте конечные точки на всех репликах зеркального отображения базы данных

Выполните следующий скрипт во всех экземплярах SQL Server с помощью sqlcmd или 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

Создание группы доступности

Подключение экземпляр SQL Server, на котором размещается основной реплика с помощью sqlcmd или SSMS. Выполните следующую команду, чтобы создать группу доступности:

  • Замените ag1 нужным именем группы доступности.
  • Замените значения sles1, sles2, и sles3 на имена экземпляров SQL Server, где размещаются реплики.
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

Создание учетных данных SQL Server для Pacemaker

На всех экземплярах SQL Server создайте учетные данные SQL Server для Pacemaker. Следующий Transact-SQL создает имя для входа.

  • Замените <password> собственным надежным паролем.
USE [master]
GO

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

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

Сохраните учетные данные, используемые для учетных данных SQL Server, на всех экземплярах SQL Server.

  1. Создайте файл .

    sudo vi /var/opt/mssql/secrets/passwd
    
  2. Добавьте в файл следующие две строки:

    pacemakerLogin
    <password>
    

    Чтобы выйти из редактора vi, сначала нажмите клавишу Esc, а затем введите команду :wq для записи файла и выхода.

  3. Сделайте файл доступным для чтения только по корневому каталогу:

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

Присоединение вторичных реплик к группе доступности

  1. Выполните следующие команды на вторичных репликах, чтобы присоединить их к группе доступности:

    ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
    GO
    
    ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
    GO
    
  2. Выполните следующий сценарий Transact-SQL на первичной реплике и каждой вторичной реплике:

    GRANT ALTER, CONTROL, VIEW DEFINITION
        ON AVAILABILITY GROUP::ag1 TO pacemakerLogin;
    GO
    
    GRANT VIEW SERVER STATE TO pacemakerLogin;
    GO
    
  3. После объединения вторичных реплик их можно увидеть в обозревателе объектов SSMS, развернув узел высокого уровня доступности Always On:

    Screenshot shows the primary and secondary availability replicas.

Добавление базы данных в группу доступности

В этом разделе описано, как добавить базу данных в группу доступности.

В рамках этого шага используются приведенные ниже команды Transact-SQL. Выполните эти команды в первичной реплике:

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

Убедитесь, что база данных создана на вторичных серверах.

На каждой вторичной реплике SQL Server выполните следующий запрос, чтобы убедиться, что база данных "db1" создана и находится в состоянии "СИНХРОНИЗОВАНО":

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

Если в synchronization_state_desc указано "СИНХРОНИЗИРОВАНО" для db1, это означает, что реплики синхронизированы. Получатели показывают db1 в первичной реплике.

Создание ресурсов группы доступности в кластере Pacemaker

Примечание.

Обмен данными без смещения

Эта статья содержит ссылки на термин slave (подчиненный), который Майкрософт считает оскорбительным при использовании в этом контексте. Термин присутствует в этой статье, так как в настоящее время он присутствует в программном обеспечении. При удалении термина из программного обеспечения мы удалим его из статьи.

В этой статье приведено руководство по созданию ресурсов группы доступности в кластере Pacemaker.

Включение Pacemaker

Включите автоматический запуск Pacemaker.

Выполните следующую команду на всех узлах кластера.

sudo systemctl enable pacemaker

Создание кластерного ресурса группы доступности

  1. Выполните команду crm configure , чтобы открыть запрос crm :

    sudo crm configure
    
  2. В командной строке crm выполните следующую команду, чтобы настроить свойства ресурса. Следующие команды создают ресурс ag_cluster в группе 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
    

    Совет

    Введите quit , чтобы выйти из запроса crm .

  3. Задайте ограничение совместного расположения для виртуального IP-адреса, чтобы запуститься на том же узле, что и основной узел:

    sudo crm configure
    colocation vip_on_master inf: admin-ip ms-ag_cluster: Master
    commit
    quit
    
  4. Добавьте ограничение порядка, чтобы предотвратить временное указание IP-адреса на узел с предварительной отработкой отказа. Выполните следующую команду, чтобы создать ограничение упорядочивания:

    sudo crm configure
    order ag_first inf: ms-ag_cluster:promote admin-ip:start
    commit
    quit
    
  5. Проверьте состояние кластера с помощью команды:

    sudo crm status
    

    Выходные данные должны быть похожи на следующий пример:

    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. Выполните следующую команду, чтобы проверить ограничения:

    sudo crm configure show
    

    Выходные данные должны быть похожи на следующий пример:

    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
    

Тестовая отработка отказа

Чтобы убедиться, что конфигурация прошла успешно, проверьте отработку отказа. Дополнительные сведения см. в разделе Отработка отказа для группы доступности Always On на Linux.

  1. Выполните следующую команду, чтобы вручную выполнить отработку отказа первичной реплики в sles2. Замените sles2 значением имени вашего сервера.

    sudo crm resource move ag_cluster sles2
    

    Выходные данные должны быть похожи на следующий пример:

    INFO: Move constraint created for ms-ag_cluster to sles2
    INFO: Use `crm resource clear ms-ag_cluster` to remove this constraint
    
  2. Проверьте состояние кластера:

    sudo crm status
    

    Выходные данные должны быть похожи на следующий пример:

    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. Через некоторое время sles2 виртуальная машина теперь является основной, а остальные две виртуальные машины являются вторичными. Запустите sudo crm status еще раз и просмотрите выходные данные, аналогичные следующему примеру:

    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. Снова проверьте ограничения, используя crm config show. Обратите внимание, что еще одно ограничение было добавлено из-за отработки отказа вручную.

  5. Удалите ограничение с идентификатором cli-prefer-ag_cluster, выполнив следующую команду:

    crm configure
    delete cli-prefer-ms-ag_cluster
    commit
    

Тестирование ограждения

Вы можете протестировать STONITH, выполнив следующую команду. Попробуйте выполнить указанную ниже команду из sles1 для sles3.

sudo crm node fence sles3

Следующий шаг