Tutorial: Configurar grupos de disponibilidade para o SQL Server em máquinas virtuais SLES no Azure

Artigo
12/06/2023

Aplica-se a:SQL Server na VM do Azure

Nota

Usamos o SQL Server 2022 (16.x) com o SUSE Linux Enterprise Server (SLES) v15 neste tutorial, mas é possível usar o SQL Server 2019 (15.x) com SLES v12 ou SLES v15, para configurar a alta disponibilidade.

Neste tutorial, irá aprender a:

Criar um novo grupo de recursos, conjunto de disponibilidade e máquinas virtuais (VMs) Linux
Habilitar alta disponibilidade (HA)
Criar um cluster de marcapasso
Configurar um agente de vedação criando um dispositivo STONITH
Instalar o SQL Server e mssql-tools no SLES
Configurar o grupo de disponibilidade Always On do SQL Server
Configurar recursos do grupo de disponibilidade (AG) no cluster do Pacemaker
Testar um failover e o agente de vedação

Este tutorial usa a CLI do Azure para implantar recursos no Azure.

Se não tiver uma subscrição do Azure, crie uma conta gratuita antes de começar.

Pré-requisitos

Use o ambiente Bash no Azure Cloud Shell. Para obter mais informações, consulte Guia de início rápido para Bash no Azure Cloud Shell.
Se preferir executar comandos de referência da CLI localmente, instale a CLI do Azure. Se estiver a utilizar o Windows ou macOS, considere executar a CLI do Azure num contentor Docker. Para obter mais informações, consulte Como executar a CLI do Azure em um contêiner do Docker.
- Se estiver a utilizar uma instalação local, inicie sessão no CLI do Azure ao utilizar o comando az login. Para concluir o processo de autenticação, siga os passos apresentados no seu terminal. Para outras opções de entrada, consulte Entrar com a CLI do Azure.
- Quando solicitado, instale a extensão da CLI do Azure na primeira utilização. Para obter mais informações sobre as extensões, veja Utilizar extensões com o CLI do Azure.
- Execute o comando az version para localizar a versão e as bibliotecas dependentes instaladas. Para atualizar para a versão mais recente, execute o comando az upgrade.

Este artigo requer a versão 2.0.30 ou posterior da CLI do Azure. Se estiver usando o Azure Cloud Shell, a versão mais recente já está instalada.

Criar um grupo de recursos

Se você tiver mais de uma assinatura, defina a assinatura para a qual deseja implantar esses recursos.

Use o comando a seguir para criar um grupo <resourceGroupName> de recursos em uma região. Substitua <resourceGroupName> por um nome de sua escolha. Este tutorial utiliza East US 2. Para obter mais informações, consulte o seguinte Guia de início rápido.

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

Criar um conjunto de disponibilidade

A próxima etapa é criar um conjunto de disponibilidade. Execute o seguinte comando no Azure Cloud Shell e substitua <resourceGroupName> pelo nome do seu grupo de recursos. Escolha um nome para <availabilitySetName>.

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

Você deve obter os seguintes resultados assim que o comando for concluído:

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

Criar uma rede virtual e uma sub-rede

Crie uma sub-rede nomeada com um intervalo de endereços IP pré-atribuído. Substitua esses valores no seguinte comando:
- <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
```
O comando anterior cria uma VNet e uma sub-rede contendo um intervalo de IP personalizado.

Criar VMs SLES dentro do conjunto de disponibilidade

Obtenha uma lista de imagens de máquinas virtuais que oferecem SLES v15 SP4 com BYOS (traga sua própria assinatura). Você também pode usar o SUSE Enterprise Linux 15 SP4 + Patching VM (sles-15-sp4-basic).

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

Você verá os seguintes resultados ao pesquisar as imagens 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"
   }
]

Este tutorial utiliza SUSE:sles-15-sp3-byos:gen1:2022.11.10.

Importante

Os nomes de máquina devem ter menos de 15 caracteres para configurar um grupo de disponibilidade. Os nomes de usuário não podem conter caracteres maiúsculos e as senhas devem ter entre 12 e 72 caracteres.

Crie três VMs no conjunto de disponibilidade. Substitua esses valores no seguinte comando:

<resourceGroupName>
<VM-basename>
<availabilitySetName>
<VM-Size> - Um exemplo seria "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

O comando anterior cria as VMs usando a VNet definida anteriormente. Para obter mais informações sobre as diferentes configurações, consulte o artigo az vm create .

O comando também inclui o --os-disk-size-gb parâmetro para criar um tamanho de unidade de sistema operacional personalizado de 128 GB. Se você aumentar esse tamanho mais tarde, expanda os volumes de pasta apropriados para acomodar sua instalação, configure o LVM (Logical Volume Manager).

Você deve obter resultados semelhantes aos seguintes quando o comando for concluído para cada VM:

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

Testar a conexão com as VMs criadas

Conecte-se a cada uma das VMs usando o seguinte comando no Azure Cloud Shell. Se você não conseguir encontrar seus IPs de VM, siga este Guia de início rápido no Azure Cloud Shell.

ssh <username>@<publicIPAddress>

Se a conexão for bem-sucedida, você verá a seguinte saída representando o terminal Linux:

[<username>@sles1 ~]$

Digite exit para sair da sessão SSH.

Registre-se no SUSEConnect e instale pacotes de alta disponibilidade

Para concluir este tutorial, suas VMs devem estar registradas no SUSEConnect para receber atualizações e suporte. Em seguida, você pode instalar o módulo de extensão de alta disponibilidade, ou padrão, que é um conjunto de pacotes que habilita o HA.

É mais fácil abrir uma sessão SSH em cada uma das VMs (nós) simultaneamente, pois os mesmos comandos devem ser executados em cada VM ao longo do artigo.

Se você estiver copiando e colando vários sudo comandos e for solicitada uma senha, os comandos adicionais não serão executados. Execute cada comando separadamente.

Conecte-se a cada nó da VM para executar as etapas a seguir.

Registrar a VM no SUSEConnect

Para registrar o nó da VM no SUSEConnect, substitua esses valores no comando a seguir, em todos os nós:

<subscriptionEmailAddress>
<registrationCode>

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

Instalar extensão de alta disponibilidade

Para instalar a Extensão de Alta Disponibilidade, execute o seguinte comando em todos os nós:

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

Configurar acesso SSH sem senha entre nós

O acesso SSH sem senha permite que suas VMs se comuniquem entre si usando chaves públicas SSH. Você deve configurar chaves SSH em cada nó e copiá-las para cada nó.

Gerar novas chaves SSH

O tamanho de chave SSH necessário é de 4.096 bits. Em cada VM, altere para a /root/.ssh pasta e execute o seguinte comando:

ssh-keygen -t rsa -b 4096

Durante esta etapa, você pode ser solicitado a substituir um arquivo SSH existente. Você deve concordar com este prompt. Não é necessário introduzir uma frase secreta.

Copie as chaves SSH públicas

Em cada VM, você deve copiar a chave pública do nó que acabou de criar, usando o ssh-copy-id comando. Se desejar especificar o diretório de destino na VM de destino, você poderá usar o -i parâmetro.

No comando a seguir, a conta pode ser a mesma conta que você configurou para cada nó ao criar a <username> VM. Você também pode usar a root conta, mas isso não é recomendado em um ambiente de produção.

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

Verificar o acesso sem senha de cada nó

Para confirmar que a chave pública SSH foi copiada para cada nó, use o ssh comando de cada nó. Se você copiou as chaves corretamente, não será solicitada uma senha e a conexão será bem-sucedida.

Neste exemplo, estamos nos conectando ao segundo e terceiro nós da primeira VM (sles1). Mais uma vez, a conta pode ser a mesma conta que você configurou para cada nó ao criar a <username> VM

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

Repita esse processo dos três nós, para que cada nó possa se comunicar com os outros sem exigir senhas.

Configurar a resolução de nomes

Você pode configurar a resolução de nomes usando o DNS ou editando manualmente o etc/hosts arquivo em cada nó.

Para obter mais informações sobre DNS e Ative Directory, consulte Associar o SQL Server em um host Linux a um domínio do Ative Directory.

Importante

Recomendamos que utilize o seu endereço IP privado no exemplo anterior. Usar o endereço IP público nessa configuração fará com que a instalação falhe e exporá sua VM a redes externas.

As VMs e seus endereços IP usados neste exemplo estão listados da seguinte maneira:

sles1: 10.0.0.85
sles2: 10.0.0.86
sles3: 10.0.0.87

Configurar o cluster

Para este tutorial, sua primeira VM () é o nó 1, sua segunda VM () é o nó 2 e sua terceira VM (sles3sles1sles2) é o nó 3. Para obter mais informações sobre a instalação do cluster, consulte Configurar o Pacemaker no SUSE Linux Enterprise Server no Azure.

Instalação de cluster

Execute o seguinte comando para instalar o pacote no nó 1 e, em seguida, reinicie o ha-cluster-bootstrap nó. Neste exemplo, é a sles1 VM.

sudo zypper install ha-cluster-bootstrap

Depois que o nó for reiniciado, execute o seguinte comando para implantar o cluster:

sudo crm cluster init --name sqlcluster

Você verá uma saída semelhante ao exemplo a seguir:

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)

Verifique o status do cluster no nó 1 usando o seguinte comando:
```
sudo crm status
```
Sua saída deve incluir o seguinte texto se tiver sido bem-sucedida:
```
1 node configured
1 resource instance configured
```
Em todos os nós, altere a senha para hacluster algo mais seguro usando o comando a seguir. Você também deve alterar sua root senha de usuário:
```
sudo passwd hacluster
```
```
sudo passwd root
```

Execute o seguinte comando no nó 2 e no nó 3 para instalar primeiro o crmsh pacote:

sudo zypper install crmsh

Agora, execute o comando para ingressar no cluster:

sudo crm cluster join

Aqui estão algumas das interações esperadas:

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)

Depois de unir todas as máquinas ao cluster, verifique seu recurso para ver se todas as VMs estão online:

sudo crm status

Deverá ver o seguinte resultado:

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

Instale o componente de recurso de cluster. Execute o seguinte comando em todos os nós.
```
sudo zypper in socat
```
Instale o azure-lb componente. Execute o seguinte comando em todos os nós.
```
sudo zypper in resource-agents
```
Configure o sistema operacional. Siga as etapas a seguir em todos os nós.
1. Edite o arquivo de configuração:
```
sudo vi /etc/systemd/system.conf
```
2. Altere o DefaultTasksMax valor para 4096:
```
#DefaultTasksMax=512
DefaultTasksMax=4096
```
3. Salve e saia do editor vi .
4. Para ativar essa configuração, execute o seguinte comando:
```
sudo systemctl daemon-reload
```
5. Teste se a alteração foi bem-sucedida:
```
sudo systemctl --no-pager show | grep DefaultTasksMax
```
Reduza o tamanho do cache sujo. Siga as etapas a seguir em todos os nós.
1. Edite o arquivo de configuração de controle do sistema:
```
sudo vi /etc/sysctl.conf
```
2. Adicione as duas linhas seguintes ao ficheiro:
```
vm.dirty_bytes = 629145600
vm.dirty_background_bytes = 314572800
```
3. Salve e saia do editor vi .

Instale o SDK do Python do Azure em todos os nós com os seguintes comandos:

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

Configurar agente de esgrima

Um dispositivo STONITH fornece um agente de esgrima. As instruções abaixo são modificadas para este tutorial. Para obter mais informações, consulte Criar um dispositivo STONITH do agente de cerca do Azure.

Verifique a versão do agente de cerca do Azure para garantir que ele seja atualizado. Utilize o seguinte comando:

sudo zypper info resource-agents

Você deve ver uma saída semelhante ao exemplo abaixo.

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.

Registar nova aplicação no Microsoft Entra ID

Para registar uma nova aplicação no Microsoft Entra ID (anteriormente Azure Ative Directory), siga estes passos:

Aceder a https://portal.azure.com.
Abra o painel Propriedades do ID do Microsoft Entra e anote o Tenant IDarquivo .
Selecione Registos de aplicações.
Selecione Novo registo.
Insira um Nome como <resourceGroupName>-app. Para tipos de conta suportados, selecione Contas somente neste diretório organizacional (somente Microsoft - Locatário único).
Selecione Web para URI de redirecionamento, insira uma URL (por exemplo, http://localhost) e selecione Adicionar. O URL de início de sessão pode ser qualquer URL válido. Uma vez feito, selecione Registrar.
Escolha Certificados e segredos para seu novo registro de aplicativo e, em seguida, selecione Novo segredo do cliente.
Insira uma descrição para uma nova chave (segredo do cliente) e selecione Adicionar.
Anote o valor do segredo. Ele é usado como a senha para a entidade de serviço.
Selecione Descrição geral. Anote o ID do aplicativo. Ele é usado como o nome de usuário (ID de login nas etapas abaixo) da entidade de serviço.

Criar função personalizada para o agente de vedação

Siga o tutorial para Criar uma função personalizada do Azure usando a CLI do Azure.

Seu arquivo JSON deve ser semelhante ao exemplo a seguir.

Substitua <username> por um nome de sua escolha. Isso é para evitar qualquer duplicação ao criar essa definição de função.
Substitua <subscriptionId> pela sua ID de Subscrição do 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>"
  ]
}

Para adicionar a função, execute o seguinte comando:

Substitua <filename> pelo nome do arquivo.
Se estiver a executar o comando a partir de um caminho diferente da pasta em que o ficheiro está guardado, inclua o caminho da pasta do ficheiro no comando.

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

Deverá ver o seguinte resultado:

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

Atribuir a função personalizada à entidade de serviço

Atribua a função Linux Fence Agent Role-<username> personalizada criada na última etapa à entidade de serviço. Repita estas etapas para todos os nós.

Aviso

Não use a função de Proprietário daqui em diante.

Aceda a https://portal.azure.com
Abrir o painel Todos os recursos
Selecione a máquina virtual do primeiro nó de cluster
Selecione Controlo de acesso (IAM)
Selecione Adicionar atribuições de função
Selecione a função Linux Fence Agent Role-<username> na lista Função
Deixe Atribuir acesso a como o padrão Users, group, or service principal.
Na lista Selecionar, digite o nome do aplicativo criado anteriormente, por exemplo<resourceGroupName>-app.
Selecione Guardar.

Criar os dispositivos STONITH

Execute os seguintes comandos no nó 1:
- Substitua o <ApplicationID> pelo valor ID do seu registro de aplicativo.
- Substitua o <servicePrincipalPassword> pelo valor do segredo do cliente.
- Substitua o <resourceGroupName> pelo grupo de recursos da sua assinatura usada para este tutorial.
- Substitua o e o <tenantID> <subscriptionId> da sua Assinatura do Azure.
Execute crm configure para abrir o prompt do crm :
```
sudo crm configure
```

No prompt crm, execute o seguinte comando para configurar as propriedades do recurso, que cria o recurso chamadorsc_st_azure, conforme mostrado no exemplo a seguir:

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

Execute os seguintes comandos para configurar o agente de esgrima:

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

Verifique o status do seu cluster para ver se o STONITH foi habilitado:

sudo crm status

Você deve ver uma saída semelhante ao seguinte texto:

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

Instalar o SQL Server e mssql-tools

Use a seção abaixo para instalar o SQL Server e o mssql-tools. Para obter mais informações, consulte Instalar o SQL Server no SUSE Linux Enterprise Server.

Execute estas etapas em todos os nós desta seção.

Instalar o SQL Server nas VMs

Os seguintes comandos são usados para instalar o SQL Server:

Baixe o arquivo de configuração do repositório SLES do Microsoft SQL Server 2019:

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

Atualize seus repositórios.
```
sudo zypper --gpg-auto-import-keys refresh
```
Para garantir que a chave de assinatura do pacote Microsoft está instalada no seu sistema, use o seguinte comando para importar a chave:
```
sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
```
Execute os seguintes comandos para instalar o SQL Server:
```
sudo zypper install -y mssql-server
```
Após a conclusão da instalação do pacote, execute mssql-conf setup e siga as instruções para definir a senha SA e escolher sua edição.
```
sudo /opt/mssql/bin/mssql-conf setup
```
Nota

Certifique-se de especificar uma senha forte para a conta SA (comprimento mínimo de 8 caracteres, incluindo letras maiúsculas e minúsculas, 10 dígitos de base e/ou símbolos não alfanuméricos).
Uma vez feita a configuração, verifique se o serviço está em execução:
```
systemctl status mssql-server
```

Instalar ferramentas de linha de comando do SQL Server

As etapas a seguir instalam as ferramentas de linha de comando do SQL Server, ou seja , sqlcmd e bcp.

Adicione o repositório do Microsoft SQL Server ao Zypper.

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

Atualize seus repositórios.

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

Instale o mssql-tools com o pacote do unixODBC desenvolvedor. Para obter mais informações, consulte Instalar o driver ODBC da Microsoft para SQL Server (Linux).
```
sudo zypper install -y mssql-tools unixODBC-devel
```

Por conveniência, você pode adicionar /opt/mssql-tools/bin/ à sua PATH variável de ambiente. Isso permite que você execute as ferramentas sem especificar o caminho completo. Execute os comandos seguintes para modificar PATH para sessões de início de sessão e sessões interativas/sem início de sessão:

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

Instalar o agente de alta disponibilidade do SQL Server

Execute o seguinte comando em todos os nós para instalar o pacote do agente de alta disponibilidade para o SQL Server:

sudo zypper install mssql-server-ha

Portas abertas para serviços de alta disponibilidade

Você pode abrir as seguintes portas de firewall em todos os nós para serviços SQL Server e 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

Configurar um grupo de disponibilidade

Use as etapas a seguir para configurar um grupo de disponibilidade Always On do SQL Server para suas VMs. Para obter mais informações, consulte Configurar grupos de disponibilidade Always On do SQL Server para alta disponibilidade no Linux

Habilitar grupos de disponibilidade e reiniciar o SQL Server

Habilite grupos de disponibilidade em cada nó que hospeda uma instância do SQL Server. Em seguida, reinicie o mssql-server serviço. Execute os seguintes comandos em cada nó:

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

sudo systemctl restart mssql-server

Criar um certificado

A Microsoft não oferece suporte à autenticação do Ative Directory para o ponto de extremidade AG. Portanto, você deve usar um certificado para criptografia de ponto de extremidade AG.

Conecte-se a todos os nós usando o SQL Server Management Studio (SSMS) ou sqlcmd. Execute os seguintes comandos para habilitar uma sessão AlwaysOn_health e criar uma chave mestra:

Importante

Se você estiver se conectando remotamente à sua instância do SQL Server, precisará ter a porta 1433 aberta no firewall. Você também precisará permitir conexões de entrada para a porta 1433 em seu NSG para cada VM. Para obter mais informações, consulte Criar uma regra de segurança para criar uma regra de segurança de entrada.
- Substitua a <MasterKeyPassword> por sua própria senha.
```
ALTER EVENT SESSION AlwaysOn_health ON SERVER
    WITH (STARTUP_STATE = ON);
GO

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<MasterKeyPassword>';
GO
```

Conecte-se à réplica primária usando SSMS ou sqlcmd. Os comandos abaixo criam um certificado em e uma chave privada em /var/opt/mssql/data/dbm_certificate.cer sua réplica principal do var/opt/mssql/data/dbm_certificate.pvk SQL Server:

Substitua a <PrivateKeyPassword> por sua própria senha.

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

Saia da sessão sqlcmd executando o exit comando e retorne à sua sessão SSH.

Copie o certificado para as réplicas secundárias e crie os certificados no servidor

Copie os dois arquivos que foram criados para o mesmo local em todos os servidores que hospedarão réplicas de disponibilidade.

No servidor primário, execute o seguinte scp comando para copiar o certificado para os servidores de destino:
- Substitua <username> e pelo nome de usuário e sles2 nome da VM de destino que você está usando.
- Execute este comando para todas as réplicas secundárias.
Nota

Você não precisa executar sudo -i, o que lhe dá o ambiente raiz. Em vez disso, você pode executar o sudo comando na frente de cada comando.
```
# The below command allows you to run commands in the root environment
sudo -i
```
```
scp /var/opt/mssql/data/dbm_certificate.* <username>@sles2:/home/<username>
```
No servidor de destino, execute o seguinte comando:
- Substitua <username> pelo seu nome de usuário.
- O mv comando move os arquivos ou diretório de um lugar para outro.
- O chown comando é usado para alterar o proprietário e o grupo de arquivos, diretórios ou links.
- Execute esses comandos para todas as réplicas secundárias.
```
sudo -i
mv /home/<username>/dbm_certificate.* /var/opt/mssql/data/
cd /var/opt/mssql/data
chown mssql:mssql dbm_certificate.*
```
O script Transact-SQL a seguir cria um certificado a partir do backup que você criou na réplica primária do SQL Server. Atualize o script com senhas fortes. A palavra-passe de desencriptação é a mesma palavra-passe que usou para criar o ficheiro .pvk no passo anterior. Para criar o certificado, execute o seguinte script usando sqlcmd ou SSMS em todos os servidores secundários:
```
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
```

Criar os pontos de extremidade de espelhamento de banco de dados em todas as réplicas

Execute o seguinte script em todas as instâncias do SQL Server usando sqlcmd ou 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

Criar o grupo de disponibilidade

Conecte-se à instância do SQL Server que hospeda a réplica primária usando sqlcmd ou SSMS. Execute o seguinte comando para criar o grupo de disponibilidade:

Substitua ag1 pelo nome AG desejado.
Substitua os sles1valores , sles2e e sles3 pelos nomes das instâncias do SQL Server que hospedam as réplicas.

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

Em todas as instâncias do SQL Server, crie um logon do SQL Server para o Pacemaker. O Transact-SQL a seguir cria um logon.

Substitua por sua própria senha complexa <password> .

USE [master]
GO

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

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

Em todas as instâncias do SQL Server, salve as credenciais usadas para o logon do SQL Server.

Crie o arquivo:
```
sudo vi /var/opt/mssql/secrets/passwd
```
Adicione as duas linhas seguintes ao ficheiro:
```
pacemakerLogin
<password>
```
Para sair do editor vi , primeiro pressione a tecla Esc e, em seguida, digite o comando :wq para gravar o arquivo e sair.

Torne o arquivo legível apenas pela raiz:

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

Associar réplicas secundárias ao grupo de disponibilidade

Em suas réplicas secundárias, execute os seguintes comandos para associá-las ao AG:

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

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

Execute o seguinte script Transact-SQL na réplica primária e em cada réplica secundária:

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

GRANT VIEW SERVER STATE TO pacemakerLogin;
GO

Depois que as réplicas secundárias forem unidas, você poderá vê-las no Pesquisador de Objetos do SSMS expandindo o nó Always On High Availability :

Adicionar um banco de dados ao grupo de disponibilidade

Esta seção segue o artigo para adicionar um banco de dados a um grupo de disponibilidade.

Os seguintes comandos Transact-SQL são usados nesta etapa. Execute estes comandos na réplica primária:

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

Verifique se o banco de dados foi criado nos servidores secundários

Em cada réplica secundária do SQL Server, execute a seguinte consulta para ver se o banco de dados db1 foi criado e está em um estado SINCRONIZADO:

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

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

Se as synchronization_state_desc listas SINCRONIZADAS para db1, isso significa que as réplicas estão sincronizadas. Os secundários são mostrados db1 na réplica primária.

Criar recursos de grupo de disponibilidade no cluster do Pacemaker

Nota

Comunicação sem preconceitos

Este artigo contém referências ao termo slave, um termo que a Microsoft considera ofensivo quando usado neste contexto. O termo aparece neste artigo porque aparece atualmente no software. Quando o termo for removido do software, iremos removê-lo do artigo.

Este artigo faz referência ao guia para criar os recursos do grupo de disponibilidade em um cluster do Pacemaker.

Ativar Pacemaker

Ative o Pacemaker para que ele seja iniciado automaticamente.

Execute o seguinte comando em todos os nós do cluster.

sudo systemctl enable pacemaker

Criar o recurso de cluster AG

Execute crm configure para abrir o prompt do crm :
```
sudo crm configure
```

No prompt crm, execute o seguinte comando para configurar as propriedades do recurso. Os comandos a seguir criam o recurso ag_cluster no grupo ag1de disponibilidade.

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

Gorjeta

Digite quit para sair do prompt do crm .

Defina a restrição de colocalização para o IP virtual, para ser executado no mesmo nó que o nó primário:
```
sudo crm configure
colocation vip_on_master inf: admin-ip ms-ag_cluster: Master
commit
quit
```
Adicione a restrição de ordenação para evitar que o endereço IP aponte temporariamente para o nó com o secundário pré-failover. Execute o seguinte comando para criar restrição de ordenação:
```
sudo crm configure
order ag_first inf: ms-ag_cluster:promote admin-ip:start
commit
quit
```

Verifique o status do cluster usando o comando:

sudo crm status

A saída deve ser semelhante ao exemplo a seguir:

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 ]

Execute o seguinte comando para revisar as restrições:

sudo crm configure show

A saída deve ser semelhante ao exemplo a seguir:

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

Ativação pós-falha de teste

Para garantir que a configuração foi bem-sucedida até agora, teste um failover. Para obter mais informações, consulte Failover de grupo de disponibilidade Always On no Linux.

Execute o seguinte comando para fazer failover manualmente da réplica primária para sles2. Substitua sles2 pelo valor do nome do servidor.
```
sudo crm resource move ag_cluster sles2
```
A saída deve ser semelhante ao exemplo a seguir:
```
INFO: Move constraint created for ms-ag_cluster to sles2
INFO: Use `crm resource clear ms-ag_cluster` to remove this constraint
```

Verifique o status do cluster:

sudo crm status

A saída deve ser semelhante ao exemplo a seguir:

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 ]

Depois de algum tempo, a VM agora é a sles2 principal e as outras duas VMs são secundárias. Execute sudo crm status mais uma vez e revise a saída, que é semelhante ao exemplo a seguir:

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 ]

Verifique suas restrições novamente, usando crm config show. Observe que outra restrição foi adicionada devido ao failover manual.
Remova a restrição com ID cli-prefer-ag_cluster, usando o seguinte comando:
```
crm configure
delete cli-prefer-ms-ag_cluster
commit
```

Teste de vedação

Você pode testar STONITH executando o seguinte comando. Tente executar o comando abaixo a partir de sles1 para sles3.

sudo crm node fence sles3

Próximo passo

Tutorial: Configurar um ouvinte de grupo de disponibilidade em máquinas virtuais Linux

Partilhar via

Tutorial: Configurar grupos de disponibilidade para o SQL Server em máquinas virtuais SLES no Azure

Pré-requisitos

Criar um grupo de recursos

Criar um conjunto de disponibilidade

Criar uma rede virtual e uma sub-rede

Criar VMs SLES dentro do conjunto de disponibilidade

Testar a conexão com as VMs criadas

Registre-se no SUSEConnect e instale pacotes de alta disponibilidade

Registrar a VM no SUSEConnect

Instalar extensão de alta disponibilidade

Configurar acesso SSH sem senha entre nós

Gerar novas chaves SSH

Copie as chaves SSH públicas

Verificar o acesso sem senha de cada nó

Configurar a resolução de nomes

Configurar o cluster

Instalação de cluster

Configurar agente de esgrima

Registar nova aplicação no Microsoft Entra ID

Criar função personalizada para o agente de vedação

Atribuir a função personalizada à entidade de serviço

Criar os dispositivos STONITH

Instalar o SQL Server e mssql-tools

Instalar o SQL Server nas VMs

Instalar ferramentas de linha de comando do SQL Server

Instalar o agente de alta disponibilidade do SQL Server

Portas abertas para serviços de alta disponibilidade

Configurar um grupo de disponibilidade

Habilitar grupos de disponibilidade e reiniciar o SQL Server

Criar um certificado

Copie o certificado para as réplicas secundárias e crie os certificados no servidor

Criar os pontos de extremidade de espelhamento de banco de dados em todas as réplicas

Criar o grupo de disponibilidade

Criar um logon do SQL Server para o Pacemaker

Associar réplicas secundárias ao grupo de disponibilidade

Adicionar um banco de dados ao grupo de disponibilidade

Verifique se o banco de dados foi criado nos servidores secundários

Criar recursos de grupo de disponibilidade no cluster do Pacemaker

Ativar Pacemaker

Criar o recurso de cluster AG

Ativação pós-falha de teste

Teste de vedação

Próximo passo

Comentários

Recursos adicionais