Já abordamos algumas teorias sobre como configurar grupos de disponibilidade Always ON para SQL Servers baseados em Linux. O artigo atual se concentrará na prática.
Vamos apresentar o processo passo a passo de configuração dos Grupos de Disponibilidade Always ON do SQL Server entre duas réplicas síncronas. Além disso, destacaremos o uso da réplica somente de configuração para realizar o failover automático.
Antes de começarmos, recomendo que você consulte o artigo anterior e atualize seus conhecimentos.
O diagrama de design abaixo exibe a réplica síncrona de dois nós e uma réplica somente de configuração que nos ajudam a garantir failover automático e proteção de dados.
Exploramos esse design no artigo mencionado anteriormente, portanto, consulte-o para obter informações antes de prosseguir com as tarefas práticas.
Instalar o SQL Server em sistemas Ubuntu
O diagrama de design acima menciona 3 sistemas Ubuntu – aoagvm1 , aoagvm2 e aoagvm3 com as instâncias do SQL Server instaladas. Consulte as instruções sobre como instalar o SQL Server no Ubuntu – o exemplo está relacionado ao SQL Server 2019 no sistema Ubuntu 18.04. Você pode ir em frente e instalar o SQL Server 2019 em todos os 3 nós (certifique-se de instalar a mesma versão de compilação).
Para economizar custos de licença, você pode instalar a edição SQL Server Express para a réplica do terceiro nó. Este funcionará como uma réplica somente de configuração sem hospedar nenhum banco de dados de disponibilidade.
Depois que o SQL Server estiver instalado em todos os 3 nós, podemos configurar o Grupo de Disponibilidade entre eles.
Configurar grupos de disponibilidade entre três nós
Antes de prosseguir, valide seu ambiente:
- Certifique-se de que haja comunicação entre os três nós.
- Verifique e atualize o nome do computador para cada host executando o comando sudo vi /etc/hostname
- Atualize o arquivo do host com o endereço IP e os nomes dos nós para cada nó. Você pode usar o comando sudo vi /etc/hosts para fazer isso
- Verifique se você tem todas as instâncias em execução além do SQL Server 2017 CU1 se não estiver usando o SQL Server 2019
Agora, vamos começar a configurar o Grupo de Disponibilidade Always ON do SQL Server entre 3 nós. Precisamos habilitar o recurso Grupo de Disponibilidade em todos os 3 nós.
Execute o comando abaixo (observe que você precisa reiniciar o serviço SQL Server após essa ação):
--Enable Availability Group feature
sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
--Restart SQL Server service
sudo systemctl restart mssql-server
Eu executei o comando acima no nó primário. Deve ser repetido para os dois nós restantes.
A saída está abaixo – digite o nome de usuário e a senha sempre que solicitado.
[email protected]:~$ sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
SQL Server needs to be restarted to apply this setting. Please run
'systemctl restart mssql-server.service'.
[email protected]:~$ systemctl restart mssql-server
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to restart 'mssql-server.service'.
Authenticating as: Ubuntu (aoagvm1)
Password:
A próxima etapa é habilitar os eventos estendidos Sempre ATIVADOS para cada instância do SQL Server. Embora esta seja uma etapa opcional, você deve habilitá-la para solucionar quaisquer problemas que possam ocorrer posteriormente. Conecte-se à instância do SQL Server usando SQLCMD e execute o comando abaixo:
--Connect to the local SQL Server instance using sqlcmd
sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
Go
ALTER EVENT SESSION AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);
Go
A saída está abaixo:
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
1>ALTER EVENT SESSION AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);
2>GO
1>
Depois de habilitar essa opção no nó de réplica primário, faça o mesmo para os nós aoagvm2 e aoagvm3 restantes.
As instâncias do SQL Server em execução no Linux usam certificados para autenticar a comunicação entre os pontos de extremidade de espelhamento. Então, a próxima opção é criar o certificado na réplica primária aoagvm1 .
Primeiro, criamos uma chave mestra e um certificado. Em seguida, fazemos backup desse certificado em um arquivo e protegemos o arquivo com uma chave privada. Execute o script T-SQL abaixo no nó de réplica primário:
--Connect to the local SQL Server instance using sqlcmd
sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
--Configure Certificates
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '[email protected]$terKEY';
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
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 = '[email protected]');
A saída:
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
1>CREATE MASTER KEY ENCRYPTION BY PASSWORD = '[email protected]$terKEY';
2>CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
3>GO
1>BACKUP CERTIFICATE dbm_certificate TO FILE = '/var/opt/mssql/data/dbm_certificate.cer'
2>WITH PRIVATE KEY (FILE = '/var/opt/mssql/data/dbm_certificate.pvk',ENCRYPTION BY PASSWORD = '[email protected]');
3>GO
1>
O nó de réplica primário agora tem dois novos arquivos. Um é o arquivo de certificado dbm_certificate.cer e o arquivo de chave privada dbm_certificate.pvk em /var/opt/mssql/data/ localização.
Copie os dois arquivos acima para o mesmo local nos dois nós restantes (AOAGVM2 e AOAGVM3) que participarão da configuração do Grupo de Disponibilidade. Você pode usar o comando SCP ou qualquer utilitário de terceiros para copiar esses dois arquivos para o servidor de destino.
Depois que os arquivos forem copiados para os dois nós restantes, atribuiremos permissões ao mssql usuário para acessar esses arquivos em todos os 3 nós. Para isso, execute o comando abaixo e depois execute-o para o 3º nó aoagvm3 também:
--Copy files to aoagvm2 node
cd /var/opt/mssql/data
scp dbm_certificate.* [email protected]:var/opt/mssql/data/
--Grant permission to user mssql to access both newly created files
cd /var/opt/mssql/data
chown mssql:mssql dbm_certificate.*
Criaremos a chave mestra e os arquivos de certificado com a ajuda dos dois arquivos copiados acima nos dois nós restantes aoagvm2 e aoagvm3 . Execute o comando abaixo nesses dois nós para criar a chave mestra :
--Create master key and certificate on remaining two nodes
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '[email protected]$terKEY';
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 = '[email protected]');
Eu executei o comando acima no segundo nó aoagvm2 para criar a chave mestra e certificado . Dê uma olhada na saída de execução. Certifique-se de usar as mesmas senhas ao criar e fazer backup do certificado e da chave mestra.
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
1>CREATE MASTER KEY ENCRYPTION BY PASSWORD = '[email protected]$terKEY';
2>CREATE CERTIFICATE dbm_certificate
3>FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
4>WITH PRIVATE KEY (FILE = '/var/opt/mssql/data/dbm_certificate.pvk', DECRYPTION BY PASSWORD = '[email protected]');
5>GO
1>
Execute o comando acima no AOAGVM3 nó também.
Agora, configuramos os endpoints de espelhamento de banco de dados – anteriormente criamos certificados para eles. O endpoint de espelhamento chamado hadr_endpoint deve estar em todos os 3 nós de acordo com seu respectivo tipo de função.
Como os bancos de dados de disponibilidade são hospedados em apenas 2 nós aoagvm1 e aoagvm2, executaremos a instrução abaixo apenas nesses nós. O terceiro nó agirá como uma testemunha, então apenas alterará PAPEL para testemunhar no script abaixo e execute o T-SQL no terceiro nó aoagvm3 . O roteiro é:
--Configure database mirroring endpoint Hadr_endpoint on nodes aoagvm1 and aoagvm2
CREATE ENDPOINT [Hadr_endpoint]
AS TCP (LISTENER_PORT = 5022)
FOR DATABASE_MIRRORING (ROLE = ALL,
AUTHENTICATION = CERTIFICATE dbm_certificate,
ENCRYPTION = REQUIRED ALGORITHM AES);
--Start the newly created endpoint
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
Aqui está a saída do comando acima no nó de réplica primário. Eu me conectei ao sqlcmd e o executou. Certifique-se de fazer o mesmo no segundo nó de réplica aoagvm2 também.
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
1>CREATE ENDPOINT [Hadr_endpoint]
2>AS TCP (LISTENER_PORT = 5022)
3>FOR DATABASE_MIRRORING (ROLE = ALL, AUTHENTICATION = CERTIFICATE dbm_certificate, ENCRYPTION = REQUIRED ALGORITHM AES);
4>Go
1>ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
2>Go
1>
Depois de executar o script T-SQL acima nos 2 primeiros nós, precisamos modificá-lo para o terceiro nó - altere o ROLE para WITNESS.
Execute o script abaixo para criar o endpoint de espelhamento de banco de dados no nó testemunha AOAGVM3 . Se você quiser hospedar bancos de dados de disponibilidade lá, execute o comando acima no nó de 3 réplicas também. Mas certifique-se de ter instalado a edição correta do SQL Server para obter esse recurso.
Se você instalou a edição SQL Server Express no nó 3 para implementar somente configuração réplica , você só pode configurar ROLE como testemunha para este nó:
--Connect to the local SQL Server instance using sqlcmd
sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
----Configure database mirroring endpoint Hadr_endpoint on 3rd node aoagvm3
CREATE ENDPOINT [Hadr_endpoint]
AS TCP (LISTENER_PORT = 5022)
FOR DATABASE_MIRRORING (ROLE = WITNESS, AUTHENTICATION = CERTIFICATE dbm_certificate, ENCRYPTION = REQUIRED ALGORITHM AES);
--Start the newly created endpoint on aoagvm3
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
Agora temos que criar o Grupo de Disponibilidade chamado ag1 .
Conecte-se à instância do SQL Server usando o sqlcmd utilitário e execute o comando abaixo no nó de réplica primário aoagvm1 :
--Connect to the local SQL Server instance using sqlcmd hosted on primary replica node aoagvm1
sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
--Create availability group ag1
CREATE AVAILABILITY GROUP [ag1]
WITH (CLUSTER_TYPE = EXTERNAL)
FOR REPLICA ON
N'aoagvm1’ WITH (ENDPOINT_URL = N'tcp://aoagvm1:5022',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC),
N'aoagvm2' WITH (ENDPOINT_URL = N'tcp://aoagvm2:5022',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC),
N'aoagvm3' WITH (ENDPOINT_URL = N'tcp://aoagvm3:5022',
AVAILABILITY_MODE = CONFIGURATION_ONLY);
--Assign required permission
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
O script acima configura as réplicas do Grupo de Disponibilidade com os parâmetros de configuração abaixo (acabamos de usá-los no script T-SQL):
- CLUSTER_TYPE =EXTERNO porque estamos configurando o grupo de disponibilidade em instalações do SQL Server baseadas em Linux
- SEEDING_MODE =AUTOMÁTICO faz com que o SQL Server crie automaticamente um banco de dados em cada réplica secundária. Os bancos de dados de disponibilidade não serão criados em réplicas somente de configuração
- FAILOVER_MODE =EXTERNO para réplicas primárias e secundárias. significa que a réplica interage com um gerenciador de recursos de cluster externo, como Pacemaker
- AVAILABILITY_MODE =SYNCHRONOUS_COMMIT para réplicas primárias e secundárias para failover automático
- AVAILABILITY_MODE =CONFIGURATION_ONLY para a 3ª réplica que funciona como uma réplica somente de configuração
Também precisamos criar um login do Pacemaker em todas as instâncias do SQL Server. Este usuário deve receber o ALTER , CONTROLE e VER DEFINIÇÃO permissões no Grupo de Disponibilidade em todas as réplicas. Para conceder permissões, execute o script T-SQL abaixo em todos os 3 nós de réplica imediatamente. Primeiro, vamos criar um login do Pacemaker. Em seguida, atribuiremos as permissões acima a esse login.
--Create pacemaker login on each SQL Server instance. Run below commands on all 3 SQL Server instances
CREATE LOGIN pacemaker WITH PASSWORD = '[email protected]@12'
--Grant permission to pacemaker login on newly created availability group. Run it on all 3 SQL Server instances
GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::ag1 TO pacemaker
GRANT VIEW SERVER STATE TO pacemaker
Após atribuir as permissões apropriadas ao login do Pacemaker em todas as 3 réplicas, executamos os scripts T-SQL abaixo para unir as réplicas secundárias aoagvm2 e aoagvm3 para o grupo de disponibilidade recém-criado ag1 . Execute os comandos abaixo nas réplicas secundárias aoagvm2 e aoagvm3 .
--Execute below commands on aoagvm2 and aoagvm3 to join availability group ag1
ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
Abaixo está a saída das execuções acima no nó aoagvm2 . Certifique-se de executá-lo no aoagvm3 nó também.
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
1>ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
2>Go
1>ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
2>Go
1>
Assim, configuramos o Grupo de Disponibilidade. Agora, precisamos adicionar um usuário ou um banco de dados de teste a este Grupo de Disponibilidade. Se você já criou um banco de dados de usuário na réplica do nó primário, basta executar um backup completo e deixar a propagação automática restaurá-lo no nó secundário.
Assim, execute o comando abaixo:
--Run a full backup of test database or user database hosted on primary replica aoagvm1
BACKUP DATABASE [Test] TO DISK = N'/var/opt/mssql/data/Test_15June.bak';
Vamos adicionar este banco de dados Teste ao Grupo de Disponibilidade ag1 . Execute a instrução T-SQL abaixo no nó primário aoagvm1 . Você pode usar o sqlcmd utilitário para executar instruções T-SQL.
--Add user database or test database to the availability group ag1
ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [Test];
Você pode verificar o banco de dados do usuário ou um banco de dados de teste adicionado ao Grupo de Disponibilidade examinando a instância secundária do SQL Server, seja ela criada em réplicas secundárias ou não. Você pode usar o SQL Server Management Studio ou executar uma instrução T-SQL simples para buscar os detalhes sobre esse banco de dados.
--Verify test database is created on a secondary replica or not. Run it on secondary replica aoagvm2.
SELECT * FROM sys.databases WHERE name = 'Test';
GO
Você receberá o Teste banco de dados criado na réplica secundária.
Com a etapa acima, o Grupo de Disponibilidade AlwaysOn foi configurado entre todos os três nós. No entanto, esses nós ainda não estão agrupados. Nossa próxima etapa é instalar o Pacemaker aglomerar neles. Em seguida, adicionaremos o Grupo de Disponibilidade ag1 como um recurso para esse cluster.
Configuração de cluster PACEMAKER entre três nós
Portanto, usaremos um gerenciador de recursos de cluster externo PACEMAKER entre todos os 3 nós para suporte de cluster. Vamos começar habilitando as portas de firewall entre todos os 3 nós.
Abra as portas do firewall usando o comando abaixo:
--Run the below commands on all 3 nodes to open Firewall Ports
sudo ufw allow 2224/tcp
sudo ufw allow 3121/tcp
sudo ufw allow 21064/tcp
sudo ufw allow 5405/udp
sudo ufw allow 1433/tcp
sudo ufw allow 5022/tcp
sudo ufw reload
--If you don't want to open specific firewall ports then alternatively you can disable the firewall on all 3 nodes by running the below command (THIS IS ALTERNATE & OPTIONAL APPROACH)
sudo ufw disable
Veja a saída – esta é da réplica primária AOAGVM1 . Você precisa executar os comandos acima em todos os três nós, um por um. A saída deve ser semelhante.
[email protected]:~$ sudo ufw allow 2224/tcp
Rules updated
Rules updated (v6)
[email protected]:~$ sudo ufw allow 3121/tcp
Rules updated
Rules updated (v6)
[email protected]:~$ sudo ufw allow 21064/tcp
Rules updated
Rules updated (v6)
[email protected]:~$ sudo ufw allow 5405/udp
Rules updated
Rules updated (v6)
[email protected]:~$ sudo ufw allow 1433/tcp
Rules updated
Rules updated (v6)
[email protected]:~$ sudo ufw allow 5022/tcp
Rules updated
Rules updated (v6)
[email protected]:~$ sudo ufw reload
Firewall not enabled (skipping reload)
Instale o Pacemaker e corosync pacotes em todos os 3 nós. Execute o comando abaixo em cada nó – ele configurará o Pacemaker , corosync , e agente de esgrima .
--Install Pacemaker packages on all 3 nodes aoagvm1, aoagvm2 and aoagvm3 by running the below command
sudo apt-get install pacemaker pcs fence-agents resource-agents
A saída é enorme – quase 20 páginas. Copiei as primeiras e últimas linhas para ilustrar (você pode ver todos os pacotes instalados):
[email protected]:~$ sudo apt-get install pacemaker pcs fence-agents resource-agents
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
cluster-glue corosync fonts-dejavu-core fonts-lato fonts-liberation ibverbs-providers javascript-common libcfg6 libcib4 libcmap4 libcorosync-common4 libcpg4
libcrmcluster4 libcrmcommon3 libcrmservice3 libdbus-glib-1-2 libesmtp6 libibverbs1 libjs-jquery liblrm2 liblrmd1 libnet-telnet-perl libnet1 libnl-3-200
libnl-route-3-200 libnspr4 libnss3 libopenhpi3 libopenipmi0 libpe-rules2 libpe-status10 libpengine10 libpils2 libplumb2 libplumbgpl2 libqb0 libquorum5 librdmacm1
libruby2.5 libsensors4 libsgutils2-2 libsnmp-base libsnmp30 libstatgrab10 libstonith1 libstonithd2 libtimedate-perl libtotem-pg5 libtransitioner2 libvotequorum8
libxml2-utils openhpid pacemaker-cli-utils pacemaker-common pacemaker-resource-agents python-pexpect python-ptyprocess python-pycurl python3-bs4 python3-html5lib
python3-lxml python3-pycurl python3-webencodings rake ruby ruby-activesupport ruby-atomic ruby-backports ruby-did-you-mean ruby-ethon ruby-ffi ruby-highline
ruby-i18n ruby-json ruby-mime-types ruby-mime-types-data ruby-minitest ruby-multi-json ruby-net-telnet ruby-oj ruby-open4 ruby-power-assert ruby-rack
ruby-rack-protection ruby-rack-test ruby-rpam-ruby19 ruby-sinatra ruby-sinatra-contrib ruby-test-unit ruby-thread-safe ruby-tilt ruby-tzinfo ruby2.5
rubygems-integration sg3-utils snmp unzip xsltproc zip
Suggested packages:
ipmitool python-requests python-suds apache2 | lighttpd | httpd lm-sensors snmp-mibs-downloader python-pexpect-doc libcurl4-gnutls-dev python-pycurl-dbg
python-pycurl-doc python3-genshi python3-lxml-dbg python-lxml-doc python3-pycurl-dbg ri ruby-dev bundler
The following NEW packages will be installed:
cluster-glue corosync fence-agents fonts-dejavu-core fonts-lato fonts-liberation ibverbs-providers javascript-common libcfg6 libcib4 libcmap4 libcorosync-common4
libcpg4 libcrmcluster4 libcrmcommon3 libcrmservice3 libdbus-glib-1-2 libesmtp6 libibverbs1 libjs-jquery liblrm2 liblrmd1 libnet-telnet-perl libnet1 libnl-3-200
libnl-route-3-200 libnspr4 libnss3 libopenhpi3 libopenipmi0 libpe-rules2 libpe-status10 libpengine10 libpils2 libplumb2 libplumbgpl2 libqb0 libquorum5 librdmacm1
libruby2.5 libsensors4 libsgutils2-2 libsnmp-base libsnmp30 libstatgrab10 libstonith1 libstonithd2 libtimedate-perl libtotem-pg5 libtransitioner2 libvotequorum8
libxml2-utils openhpid pacemaker pacemaker-cli-utils pacemaker-common pacemaker-resource-agents pcs python-pexpect python-ptyprocess python-pycurl python3-bs4
python3-html5lib python3-lxml python3-pycurl python3-webencodings rake resource-agents ruby ruby-activesupport ruby-atomic ruby-backports ruby-did-you-mean
ruby-ethon ruby-ffi ruby-highline ruby-i18n ruby-json ruby-mime-types ruby-mime-types-data ruby-minitest ruby-multi-json ruby-net-telnet ruby-oj ruby-open4
ruby-power-assert ruby-rack ruby-rack-protection ruby-rack-test ruby-rpam-ruby19 ruby-sinatra ruby-sinatra-contrib ruby-test-unit ruby-thread-safe ruby-tilt
ruby-tzinfo ruby2.5 rubygems-integration sg3-utils snmp unzip xsltproc zip
0 upgraded, 103 newly installed, 0 to remove and 2 not upgraded.
Need to get 19.6 MB of archives.
After this operation, 86.0 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 http://azure.archive.ubuntu.com/ubuntu bionic/main amd64 fonts-lato all 2.0-2 [2698 kB]
Get:2 http://azure.archive.ubuntu.com/ubuntu bionic/main amd64 libdbus-glib-1-2 amd64 0.110-2 [58.3 kB]
…………
--------
Uma vez que o Marcapasso a instalação do cluster estiver concluída, o hacluster user será preenchido automaticamente ao executar o comando abaixo:
[email protected]:~$ cat /etc/passwd|grep hacluster
hacluster:x:111:115::/var/lib/pacemaker:/usr/sbin/nologin
Agora, podemos definir a senha para o usuário padrão criado durante a instalação do Pacemaker e o Corosync pacotes. Certifique-se de usar a mesma senha em todos os 3 nós. Use o comando abaixo:
--Set default user password on all 3 nodes
sudo passwd hacluster
Digite a senha quando solicitado:
[email protected]:~$ sudo passwd hacluster
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
A próxima etapa é ativar e iniciar o pcsd serviço e Pacemaker em todos os 3 nós. Ele permite que todos os 3 nós entrem no cluster após a reinicialização. Execute o comando abaixo em todos os 3 nós para concluir esta etapa:
--Enable and start pcsd service and pacemaker
sudo systemctl enable pcsd
sudo systemctl start pcsd
sudo systemctl enable pacemaker
Veja a execução na réplica primária aoagvm1 . Certifique-se de executá-lo nos dois nós restantes também.
--Enable pcsd service
[email protected]:~$ sudo systemctl enable pcsd
Synchronizing state of pcsd.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable pcsd
--Start pcsd service
[email protected]:~$ sudo systemctl start pcsd
--Enable Pacemaker
[email protected]:~$ sudo systemctl enable pacemaker
Synchronizing state of pacemaker.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable pacemaker
Configuramos o Pacemaker pacotes. Agora criamos um cluster.
Primeiro, certifique-se de não ter nenhum cluster configurado anteriormente nesses sistemas. Você pode destruir qualquer configuração de cluster existente de todos os nós executando os comandos abaixo. Observe que a remoção de qualquer configuração de cluster interromperá todos os serviços de cluster e desativará o Pacemaker serviço – ele precisa ser reativado.
--Destroy previously configured clusters to clean the systems
sudo pcs cluster destroy
--Reenable Pacemaker
sudo systemctl enable pacemaker
Abaixo está a saída do nó de réplica primário aoagvm1 .
--Destroy previously configured clusters to clean the systems
[email protected]:~$ sudo pcs cluster destroy
Shutting down pacemaker/corosync services...
Killing any remaining services...
Removing all cluster configuration files...
--Reenable Pacemaker
[email protected]:~$ sudo systemctl enable pacemaker
Synchronizing state of pacemaker.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable pacemaker
Em seguida, criamos o cluster de 3 nós entre todos os 3 nós da réplica primária aoagvm1 . Importante :execute os comandos abaixo somente do seu nó principal !
--Create cluster. Modify below command with your node names, hacluster password and clustername
sudo pcs cluster auth <node1> <node2> <node3> -u hacluster -p <password for hacluster>
sudo pcs cluster setup --name <clusterName> <node1> <node2...> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all
Veja a saída no nó de réplica primário:
[email protected]:~$ sudo pcs cluster auth aoagvm1 aoagvm2 aoagvm3 -u hacluster -p hacluster
aoagvm1: Authorized
aoagvm2: Authorized
aoagvm3: Authorized
[email protected]:~$ sudo pcs cluster setup --name aoagvmcluster aoagvm1 aoagvm2 aoagvm3
Destroying cluster on nodes: aoagvm1, aoagvm2, aoagvm3...
aoagvm1: Stopping Cluster (pacemaker)...
aoagvm2: Stopping Cluster (pacemaker)...
aoagvm3: Stopping Cluster (pacemaker)...
aoagvm1: Successfully destroyed cluster
aoagvm2: Successfully destroyed cluster
aoagvm3: Successfully destroyed cluster
Sending 'pacemaker_remote authkey' to 'aoagvm1', 'aoagvm2', 'aoagvm3'
aoagvm1: successful distribution of the file 'pacemaker_remote authkey'
aoagvm2: successful distribution of the file 'pacemaker_remote authkey'
aoagvm3: successful distribution of the file 'pacemaker_remote authkey'
Sending cluster config files to the nodes...
aoagvm1: Succeeded
aoagvm2: Succeeded
aoagvm3: Succeeded
Synchronizing pcsd certificates on nodes aoagvm1, aoagvm2, aoagvm3...
aoagvm1: Success
aoagvm2: Success
aoagvm3: Success
Restarting pcsd on the nodes to reload the certificates...
aoagvm1: Success
aoagvm2: Success
aoagvm3: Success
[email protected]:~$ sudo pcs cluster start --all
aoagvm1: Starting Cluster...
aoagvm2: Starting Cluster...
aoagvm3: Starting Cluster...
[email protected]:~$ sudo pcs cluster enable --all
aoagvm1: Cluster Enabled
aoagvm2: Cluster Enabled
aoagvm3: Cluster Enabled
Esgrima é uma das configurações essenciais ao usar o cluster PACEMAKER em produção. Você deve configurar o fencing para seu cluster para garantir que não haja corrupção de dados em caso de interrupções .
Existem dois tipos de implementação de esgrima:
- Nível do recurso – garante que um nó não possa usar um ou mais recursos.
- Nível do nó – garante que um nó não execute nenhum recurso.
Geralmente usamos STONITH como configuração de fencing – o fencing em nível de nó para PACEMAKER .
Quando PACEMAKER não pode determinar o estado de um nó ou um recurso em um nó, o fencing traz o cluster para um estado conhecido novamente. Para conseguir isso, o PACEMAKER exige que habilitemos STONITH , que significa Atire no outro nó na cabeça .
Não focaremos na configuração de fencing neste artigo porque a configuração de fencing no nível do nó depende muito do ambiente individual. Para nosso cenário, vamos desativá-lo executando o comando abaixo:
--Disable fencing (STONITH)
sudo pcs property set stonith-enabled=false
No entanto, se você planeja usar o Pacemaker em um ambiente de produção, você deve planejar a implementação do STONITH dependendo do seu ambiente e mantê-la habilitada.
Em seguida, definiremos algumas propriedades essenciais do cluster:cluster-recheck-interval, start-failure-is-fatal, e tempo limite de falha .
De acordo com o MSDN, se tempo limite de falha é definido como 60 segundos e cluster-recheck-interval for definido para 120 segundos, a reinicialização será tentada em um intervalo maior que 60 segundos, mas menor que 120 segundos. A Microsoft recomenda definir um valor para cluster-recheck-interval maior que o valor de failure-timeout . Outra configuração start-failure-is-fatal precisa ser definido como true . Caso contrário, o cluster não iniciará o failover da réplica primária para sua respectiva réplica secundária, caso ocorra alguma interrupção permanente.
Execute os comandos abaixo para configurar todas as 3 propriedades importantes do cluster:
--Set cluster property cluster-recheck-interval to 2 minutes
sudo pcs property set cluster-recheck-interval=2min
--Set start-failure-is-fatal to True
sudo pcs property set start-failure-is-fatal=true
--Set failure-timeout to 60 seconds. Ag1 is the name of the availability group. Change this name with your availability group name.
pcs resource update ag1 meta failure-timeout=60s
Integrar o Grupo de Disponibilidade ao Grupo de Cluster do Pacemaker
Aqui, nosso objetivo é descrever o processo de integração do recém-criado Grupo de Disponibilidade ag1 ao recém-criado Pacemaker grupo de clusters.
Primeiro, instalaremos o agente de recursos do SQL Server para integração com o Pacemaker em todos os 3 nós:
--Install SQL Server Resource Agent on all 3 nodes
sudo apt-get install mssql-server-ha
Eu executei o comando acima em todos os 3 nós. Veja a saída abaixo (retirada de aoagvm1 ):
--Install SQL Server resource agent for integration with Pacemaker
[email protected]:~$ sudo apt-get install mssql-server-ha
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
mssql-server-ha
0 upgraded, 1 newly installed, 0 to remove, and 2 not upgraded.
Need to get 1486 kB of archives.
After this operation, 9151 kB of additional disk space will be used.
Get:1 https://packages.microsoft.com/ubuntu/16.04/mssql-server-preview xenial/main amd64 mssql-server-ha amd64 15.0.1600.8-1 [1486 kB]
Fetched 1486 kB in 0s (4187 kB/s)
Selecting previously unselected package mssql-server-ha.
(Reading database ... 90430 files and directories currently installed.)
Preparing to unpack .../mssql-server-ha_15.0.1600.8-1_amd64.deb ...
Unpacking mssql-server-ha (15.0.1600.8-1) ...
Setting up mssql-server-ha (15.0.1600.8-1) ...
Repita as etapas acima nos 2 nós restantes.
Já criamos o Pacemaker faça login em todas as instâncias do SQL Server hospedadas em 3 nós quando tivermos configurado o Grupo de Disponibilidade ag1 . Agora, atribuímos a função sysadmin em todas as 3 instâncias do SQL Server. Você pode se conectar usando sqlcmd para executar este comando T-SQL. Se você não criou o Pacemaker login, você pode executar o comando abaixo para fazer isso.
--Create a pacemaker login if you missed creating it in the above section.
USE master
Go
CREATE LOGIN pacemaker WITH PASSWORD = '[email protected]@12'
Go
--Assign sysadmin role to pacemaker login on all 3 nodes. Run this T-SQL on all 3 SQL Server instances.
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemaker]
We must save the above SQL Server Pacemaker login and its credentials on all 3 nodes. Run the below command there:
--Save pacemaker login credentials on all 3 nodes by executing below commands on each node
echo 'pacemaker' >> ~/pacemaker-passwd
echo '[email protected]@12' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd
We will create the Availability Group Resource as master/subordinate .
We are using the pcs resource create command to create the Availability Group resource and set its properties. The following command will create the ocf:mssql:ag resource for the Availability Group ag1 .
The Pacemaker resource agent automatically sets the value of REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT on the Availability Group based on the Availability Group’s configuration during the creation of the Availability Group resource.
Execute the below command:
--Create availability group resource ocf:mssql:ag
sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=30s --master meta notify=true
Next, we create a virtual IP resource in Pacemaker . Ensure you have the unused private IP address from your network . Replace the IP value with your virtual IP address. This IP will point to the primary replica and you can use it to make databases connections with active nodes.
The command is below:
--Configure virtual IP resource
sudo pcs resource create virtualip ocf:heartbeat:IPaddr2 ip=10.50.0.7
We are adding the colocation constraint and ordering constraint to the Pacemaker cluster configuration . These constraints help the virtual IP resource to make decisions on resources, e.g., where they should run.
Constraints have some scores, and Pacemaker uses these scores to make decisions. Scores are calculated per resource. The cluster resource manager chooses the node with the highest score for a particular resource.
The colocation constraint has an implicit ordering constraint . We need to add an ordering constraint to prevent the IP address from temporarily pointing to the node with the pre-failover secondary . Ordering constraint ensures the cluster comes online in a particular sequential manner.
Run the below commands to add colocation constraint and ordering constraint to the cluster.
--Add colocation constraint
sudo pcs constraint colocation add virtualip ag_cluster-master INFINITY with-rsc-role=Master
--Add ordering constraint
sudo pcs constraint order promote ag_cluster-master then start virtualip
Hence, Two-Node Synchronous Replicas (aoagvm1 &aoagvm2) and a Configuration-Only Replica (aoagvm3) on PACEMAKER Cluster between 3-Node Ubuntu Systems has been completed.
We can test the configuration to validate the automatic failover. Run the below command to check the status of the Pacemaker cluster. The command also initiates the Availability Group failover.
Remember, once you couple your Availability Group with the PACEMAKER cluster, you cannot use T-SQL statements to initiate the Availability Group failovers. You can also shut down the primary replica to initiate the automatic failover.
The command is the following:
--Validate the PACEMAKER cluster configuration
sudo pcs status
--Initiate availability group failover to verify AOAG configuration
sudo pcs resource move ag_cluster-master aoagvm2 –master
Conclusão
This article was meant to help you understand the configuration of the Two-Node Synchronous Replicas and a Configuration-Only Replica on PACEMAKER Cluster. We hope that you got useful information that will help you in your workflow.
Always plan all steps carefully and do proper testing in a lower life cycle before deploying to your production environment.
We’ll be glad to hear your thoughts about this topic. Feel free to leave your feedback in a comment section.
