Red Hat Enterprise Linux-8-Configuring and Managing High Availability Clusters-pt-BR

Red Hat Enterprise Linux 8
Configuração e gerenciamento de clusters de

alta disponibilidade
Configuração e gerenciamento do Red Hat High Availability Add-On
Last Updated: 2021-02-27

Red Hat Enterprise Linux 8 Configuração e gerenciamento de clusters de
alta disponibilidade
Configuração e gerenciamento do Red Hat High Availability Add-On
Enter your first name here. Enter your surname here.

Enter your organisation's name here. Enter your organisational division here.
Enter your email address here.
Nota Legal
Copyright © 2021 | You need to change the HOLDER entity in the en-
US/Configuring_and_managing_high_availability_clusters.ent file | This material may only be
distributed subject to the terms and conditions set forth in the GNU Free Documentation License
(GFDL), V1.2 or later (the latest version is presently available at
http://www.gnu.org/licenses/fdl.txt).
Resumo
Este guia fornece informações sobre como instalar, configurar e gerenciar o Red Hat High
Availability Add-On para o Red Hat Enterprise Linux 8.
Índice
Índice
. . . . . . . . . . . . . .O. .CÓDIGO
TORNANDO . . . . . . . . . ABERTO
. . . . . . . . . MAIS
. . . . . . INCLUSIVO
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. . . . . . . . . . . . .
. . . . . . . . . . . . . . . . FEEDBACK
FORNECENDO . . . . . . . . . . . . SOBRE
. . . . . . . .A
. . DOCUMENTAÇÃO
. . . . . . . . . . . . . . . . . . . .DA
. . . RED
. . . . .HAT
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. . . . . . . . . . . . .
.CAPÍTULO
. . . . . . . . . . .1.. .VISÃO
. . . . . . .GERAL
. . . . . . . .DO
. . . ADD-ON
. . . . . . . . . .DE
. . . ALTA
. . . . . . .DISPONIBILIDADE
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
..............
1.1. COMPONENTES ADICIONAIS DE ALTA DISPONIBILIDADE 10
1.2. VISÃO GERAL DO MARCAPASSO 10
1.2.1. Componentes da arquitetura do marcapasso 10
1.2.2. Ferramentas de configuração e gerenciamento 11
1.2.3. Os arquivos de configuração do cluster e do marcapasso 11
1.3. VISÃO GERAL DA VEDAÇÃO 12
1.4. VISÃO GERAL DO QUORUM 12
1.5. VISÃO GERAL DOS RECURSOS 13
1.6. VOLUMES LÓGICOS LVM EM UM CLUSTER DE ALTA DISPONIBILIDADE DA RED HAT 13
1.6.1. Escolhendo HA-LVM ou volumes compartilhados 13
1.6.2. Configuração de volumes LVM em um cluster 14
.CAPÍTULO
. . . . . . . . . . .2.
. . COMEÇANDO
. . . . . . . . . . . . . . . COM
. . . . . .PACEMAKER
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
..............
2.1. APRENDENDO A USAR O PACEMAKER 15
2.2. APRENDENDO A CONFIGURAR O FAILOVER 19
.CAPÍTULO
. . . . . . . . . . .3.
. .A
. . INTERFACE
. . . . . . . . . . . . .DE
. . . LINHA
. . . . . . . DE
. . . .COMANDO
. . . . . . . . . . . .PCS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
..............
3.1. PCS AJUDAM A EXIBIR 25
3.2. VISUALIZANDO A CONFIGURAÇÃO DO CLUSTER BRUTO 25
3.3. SALVANDO UMA MUDANÇA DE CONFIGURAÇÃO PARA UM ARQUIVO DE TRABALHO 25
3.4. EXIBIÇÃO DO STATUS DO CLUSTER 26
3.5. EXIBIÇÃO DA CONFIGURAÇÃO COMPLETA DO CLUSTER 27
.CAPÍTULO
. . . . . . . . . . .4.
. . CRIANDO
. . . . . . . . . . .UM
. . . .CLUSTER
. . . . . . . . . . DE
. . . .ALTA
. . . . . .DISPONIBILIDADE
. . . . . . . . . . . . . . . . . . . RED
. . . . .HAT
. . . . .COM
. . . . . . . . . . . . . . . . . . . . . . . .28
..............
4.1. INSTALAÇÃO DE SOFTWARE DE CLUSTER 28
4.2. INSTALAÇÃO DO PACOTE PCP-ZEROCONF (RECOMENDADO) 29
4.3. CRIAÇÃO DE UM CLUSTER DE ALTA DISPONIBILIDADE 30
4.4. CRIAÇÃO DE UM CLUSTER DE ALTA DISPONIBILIDADE COM MÚLTIPLOS LINKS 31
4.5. CONFIGURAÇÃO DE CERCAS 32
4.6. APOIO E RESTAURAÇÃO DE UMA CONFIGURAÇÃO DE CLUSTER 33
4.7. HABILITAÇÃO DE PORTAS PARA O ADD-ON DE ALTA DISPONIBILIDADE 33
CAPÍTULO 5. CONFIGURAÇÃO DE UM SERVIDOR HTTP APACHE ATIVO/PASSIVO EM UM CLUSTER RED

. . . . . HIGH
HAT . . . . . . AVAILABILITY
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
..............
5.1. CONFIGURAÇÃO DE UM VOLUME LVM COM UM SISTEMA DE ARQUIVO EXT4 EM UM CLUSTER
PACEMAKER 37
5.2. CONFIGURAÇÃO DE UM SERVIDOR HTTP APACHE 38
5.3. CRIAÇÃO DOS RECURSOS E GRUPOS DE RECURSOS 39
5.4. TESTE DA CONFIGURAÇÃO DOS RECURSOS 41
CAPÍTULO 6. CONFIGURAÇÃO DE UM SERVIDOR NFS ATIVO/PASSIVO EM UM CLUSTER RED HAT HIGH

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
AVAILABILITY ..............
6.1. PRÉ-REQUISITOS 43
6.2. VISÃO GERAL DOS PROCEDIMENTOS 43
6.3. CONFIGURAÇÃO DE UM VOLUME LVM COM UM SISTEMA DE ARQUIVO EXT4 EM UM CLUSTER
PACEMAKER 43
6.4. CONFIGURAÇÃO DE UM COMPARTILHAMENTO NFS 45
6.5. CONFIGURAÇÃO DOS RECURSOS E GRUPO DE RECURSOS PARA UM SERVIDOR NFS EM UM CLUSTER
45
1
Red Hat Enterprise Linux 8 Configuração e gerenciamento de clusters de alta disponibilidade
6.6. TESTE DA CONFIGURAÇÃO DO RECURSO NFS 49

6.6.1. Teste da exportação do NFS 49
6.6.2. Teste de failover 50
.CAPÍTULO
. . . . . . . . . . .7.
. . SISTEMAS
. . . . . . . . . . . .DE
. . .ARQUIVO
. . . . . . . . . . GFS2
. . . . . . .EM
. . . UM
. . . . CLUSTER
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
..............
7.1. CONFIGURAÇÃO DE UM SISTEMA DE ARQUIVO GFS2 EM UM CLUSTER 52
7.2. MIGRAÇÃO DE UM SISTEMA DE ARQUIVOS GFS2 DE RHEL7 PARA RHEL8 57
.CAPÍTULO
. . . . . . . . . . .8.
. . COMEÇANDO
. . . . . . . . . . . . . . . COM
. . . . . .O
. . PCSD
. . . . . . .WEB
. . . . .UI
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
..............
8.1. INSTALAÇÃO DE SOFTWARE DE CLUSTER 59
8.2. CRIAÇÃO DA INTERFACE WEB DO PCSD 60
8.3. CRIANDO UM CLUSTER COM O PCSD WEB UI 61
8.3.1. Configuração de opções avançadas de configuração de clusters com a interface Web do pcsd 61
8.3.2. Definição de permissões de gerenciamento de clusters 62
8.4. CONFIGURAÇÃO DE COMPONENTES DE CLUSTER COM O PCSD WEB UI 62
8.4.1. Configuração de nós de cluster com a interface Web do pcsd 63
8.4.2. Configuração de recursos de cluster com o pcsd Web UI 63
8.4.3. Configuração de dispositivos de vedação com a interface Web do pcsd 64
8.4.4. Configuração de ACLs com a interface web pcsd 64
8.4.5. Configuração das propriedades do cluster com a interface Web do pcsd 64
8.5. CONFIGURAÇÃO DE UMA INTERFACE WEB PCSD DE ALTA DISPONIBILIDADE 65
CAPÍTULO 9. CONFIGURAÇÃO DE CERCAS EM UM CLUSTER DE ALTA DISPONIBILIDADE DE CHAPÉU

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
VERMELHO ..............
9.1. EXIBIÇÃO DOS AGENTES DE VEDAÇÃO DISPONÍVEIS E SUAS OPÇÕES 66
9.2. CRIANDO UM DISPOSITIVO DE CERCA 67
9.3. PROPRIEDADES GERAIS DOS DISPOSITIVOS DE ESGRIMA 67
9.4. OPÇÕES AVANÇADAS DE CONFIGURAÇÃO DE CERCAS 69
9.5. TESTE DE UM DISPOSITIVO DE CERCA 81
9.6. CONFIGURAÇÃO DOS NÍVEIS DE VEDAÇÃO 84
9.7. CONFIGURAÇÃO DE CERCAS PARA FONTES DE ALIMENTAÇÃO REDUNDANTES 85
9.8. EXIBIÇÃO DE DISPOSITIVOS DE CERCAS CONFIGURADOS 86
9.9. MODIFICAÇÃO E ELIMINAÇÃO DE DISPOSITIVOS DE CERCAS 86
9.10. ESGRIMA MANUAL DE UM NÓ DE CLUSTER 86
9.11. DESATIVAÇÃO DE UM DISPOSITIVO DE CERCA 87
9.12. IMPEDIR QUE UM NÓ UTILIZE UM DISPOSITIVO DE VEDAÇÃO 87
9.13. CONFIGURAÇÃO DO ACPI PARA USO COM DISPOSITIVOS DE CERCAS INTEGRADAS 87
9.13.1. Desabilitando o ACPI Soft-Off com o BIOS 88
9.13.2. Desabilitando o ACPI Soft-Off no arquivo logind.conf 89
9.13.3. Desabilitando completamente o ACPI no arquivo GRUB 2 89
. . . . . . . . . . . .10.
CAPÍTULO . . . CONFIGURAÇÃO
. . . . . . . . . . . . . . . . . . DE
. . . .RECURSOS
. . . . . . . . . . . . DE
. . . .CLUSTER
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
..............
Exemplos de criação de recursos 91
Eliminação de um recurso configurado 91
10.1. IDENTIFICADORES DO AGENTE DE RECURSOS 91
10.2. EXIBIÇÃO DE PARÂMETROS ESPECÍFICOS DE RECURSOS 93
10.3. CONFIGURANDO AS META OPÇÕES DE RECURSOS 93
10.3.1. Alterando o valor padrão de uma opção de recurso 137
10.3.2. Alteração do valor padrão de uma opção de recurso para conjuntos de recursos (RHEL 8.3 e
posteriores) 137
10.3.3. Exibição dos padrões de recursos configurados atualmente 137
10.3.4. Definição de meta opções na criação de recursos 138
10.4. CONFIGURAÇÃO DE GRUPOS DE RECURSOS 138
10.4.1. Criação de um grupo de recursos 139
2
Índice
10.4.2. Remoção de um grupo de recursos 139

10.4.3. Exibição de grupos de recursos 140
10.4.4. Opções de grupo 140
10.4.5. Adesividade do grupo 140
10.5. DETERMINANDO O COMPORTAMENTO DOS RECURSOS 140
. . . . . . . . . . . .11.
CAPÍTULO . . DETERMINAÇÃO
. . . . . . . . . . . . . . . . . . DOS
. . . . . .NÓS
. . . . .EM
. . . QUE
. . . . . .UM
. . . .RECURSO
. . . . . . . . . . PODE
. . . . . . .FUNCIONAR
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
..............
11.1. CONFIGURAÇÃO DAS RESTRIÇÕES DE LOCALIZAÇÃO 141
11.2. LIMITANDO A DESCOBERTA DE RECURSOS A UM SUBCONJUNTO DE NÓS 143
11.3. CONFIGURAÇÃO DE UMA ESTRATÉGIA DE RESTRIÇÃO DE LOCALIZAÇÃO 145
11.3.1. Configuração de um Cluster "Opt-In 145
11.3.2. Configuração de um Cluster "Opt-Out" 145
11.4. CONFIGURAÇÃO DE UM RECURSO PARA PREFERIR SEU NÓ ATUAL 146
CAPÍTULO 12. DETERMINAÇÃO DA ORDEM NA QUAL OS RECURSOS DE AGRUPAMENTO SÃO

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147
EXECUTADOS ...............
12.1. CONFIGURAÇÃO DE PEDIDOS OBRIGATÓRIOS 148
12.2. CONFIGURAÇÃO DE PEDIDOS DE CONSULTORIA 148
12.3. CONFIGURAÇÃO DE CONJUNTOS DE RECURSOS ENCOMENDADOS 148
12.4. CONFIGURAÇÃO DE ORDEM DE PARTIDA PARA DEPENDÊNCIAS DE RECURSOS NÃO GERENCIADAS
PELA PACEMAKER 150
. . . . . . . . . . . .13.
CAPÍTULO . . .COLOCANDO
. . . . . . . . . . . . . . .RECURSOS
. . . . . . . . . . . .DE
. . . CLUSTER
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
...............
13.1. ESPECIFICAR A COLOCAÇÃO OBRIGATÓRIA DE RECURSOS 152
13.2. ESPECIFICAR A COLOCAÇÃO DE RECURSOS CONSULTIVOS 153
13.3. COLOCANDO CONJUNTOS DE RECURSOS 153
13.4. REMOÇÃO DE RESTRIÇÕES DE COLOCAÇÃO 154
. . . . . . . . . . . .14.
CAPÍTULO . . . EXIBINDO
. . . . . . . . . . .RESTRIÇÕES
. . . . . . . . . . . . . . DE
. . . .RECURSOS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
...............
14.1. EXIBINDO TODAS AS RESTRIÇÕES CONFIGURADAS 155
14.2. EXIBIÇÃO DAS RESTRIÇÕES DE LOCALIZAÇÃO 155
14.3. EXIBIR RESTRIÇÕES DE PEDIDOS 155
14.4. EXIBIÇÃO DE RESTRIÇÕES DE COLOCAÇÃO 155
14.5. EXIBINDO RESTRIÇÕES ESPECÍFICAS DE RECURSOS 155
14.6. EXIBIÇÃO DAS DEPENDÊNCIAS DE RECURSOS (RED HAT ENTERPRISE LINUX 8.2 E POSTERIORES)
156
. . . . . . . . . . . .15.
CAPÍTULO . . .DETERMINAÇÃO
. . . . . . . . . . . . . . . . . .DA
. . . LOCALIZAÇÃO
. . . . . . . . . . . . . . . . .DOS
. . . . .RECURSOS
. . . . . . . . . . . .COM
. . . . . .REGRAS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158
...............
15.1. REGRAS DO MARCAPASSO 158
15.1.1. Expressões de atributos de nós 158
15.1.2. Expressões baseadas em tempo/data 160
15.1.3. Especificações de data 161
15.2. CONFIGURAÇÃO DE UMA RESTRIÇÃO DE LOCALIZAÇÃO DE MARCAPASSO USANDO REGRAS 161
. . . . . . . . . . . .16.
CAPÍTULO . . . GERENCIAMENTO
. . . . . . . . . . . . . . . . . . . .DE
. . . RECURSOS
. . . . . . . . . . . . DE
. . . .CLUSTER
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
...............
16.1. EXIBIÇÃO DE RECURSOS CONFIGURADOS 163
16.2. MODIFICAÇÃO DOS PARÂMETROS DOS RECURSOS 163
16.3. STATUS DE FALHAS DE COMPENSAÇÃO DE RECURSOS DE CLUSTER 164
16.4. MOVIMENTAÇÃO DE RECURSOS EM UM CLUSTER 164
16.4.1. Movimentação de recursos devido a falhas 165
16.4.2. Movimentação de recursos devido a mudanças na conectividade 165
16.5. DESABILITANDO UMA OPERAÇÃO DE MONITOR 166
16.6. CONFIGURAÇÃO E GERENCIAMENTO DE ETIQUETAS DE RECURSOS DE CLUSTER (RHEL 8.3 E
POSTERIORES) 167
16.6.1. Marcação de recursos de cluster para administração por categoria 167
3
16.6.2. Eliminação de um recurso de cluster etiquetado 168
CAPÍTULO 17. CRIAÇÃO DE RECURSOS DE CLUSTER QUE ESTÃO ATIVOS EM MÚLTIPLOS NÓS
. . . . . . . . . . . . . .CLONADOS)
(RECURSOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169
...............
17.1. CRIAÇÃO E REMOÇÃO DE UM RECURSO CLONADO 169
17.2. CONFIGURAÇÃO DE RESTRIÇÕES DE RECURSOS CLONAIS 171
17.3. CRIAÇÃO DE RECURSOS DE CLONAGEM PROMOCIONAIS 172
17.3.1. Criando um recurso promocional 172
17.3.2. Configuração de restrições de recursos promocionais 172
17.4. DEMONSTRANDO UM RECURSO PROMOVIDO SOBRE O FRACASSO (RHEL 8.3 E POSTERIORES) 173
. . . . . . . . . . . .18.
CAPÍTULO . . .GERENCIANDO
. . . . . . . . . . . . . . . . .NÓS
. . . . .DE
. . . CLUSTER
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .174
...............
18.1. PARAR OS SERVIÇOS DE CLUSTER 174
18.2. HABILITAÇÃO E DESATIVAÇÃO DE SERVIÇOS DE CLUSTER 174
18.3. ADIÇÃO DE NÓS DE CLUSTER 174
18.4. REMOÇÃO DE NÓS DE CLUSTER 176
18.5. ADICIONANDO UM NÓ A UM AGRUPAMENTO COM MÚLTIPLOS LINKS 176
18.6. ADIÇÃO E MODIFICAÇÃO DE LINKS EM UM CLUSTER EXISTENTE (RHEL 8.1 E POSTERIORES) 176
18.6.1. Adicionar e remover links em um cluster existente 176
18.6.2. Modificação de um link em um cluster com múltiplos links 177
18.6.3. Modificando os endereços dos links em um cluster com um único link 177
18.6.4. Modificando as opções de link para um link em um cluster com um único link 178
18.6.5. Modificar um link ao adicionar um novo link não é possível 179
18.7. CONFIGURAÇÃO DE UM GRANDE CLUSTER COM MUITOS RECURSOS 179
. . . . . . . . . . . .19.
CAPÍTULO . . . DEFINIR
. . . . . . . . . PERMISSÕES
. . . . . . . . . . . . . . DE
. . . .USUÁRIO
. . . . . . . . . . PARA
. . . . . . UM
. . . . CLUSTER
. . . . . . . . . . .DE
. . . PACEMAKER
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181
..............
19.1. DEFINIR PERMISSÕES PARA O ACESSO DOS NÓS ATRAVÉS DE UMA REDE 181
19.2. DEFINIR PERMISSÕES LOCAIS USANDO ACLS 181
.CAPÍTULO
. . . . . . . . . . .20.
. . . .OPERAÇÕES
. . . . . . . . . . . . . .DE
. . .MONITORAMENTO
. . . . . . . . . . . . . . . . . . . . DE
. . . .RECURSOS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183
...............
20.1. CONFIGURAÇÃO DE OPERAÇÕES DE MONITORAMENTO DE RECURSOS 184
20.2. CONFIGURAÇÃO DE PADRÕES DE OPERAÇÃO DE RECURSOS GLOBAIS 185
20.2.1. Valores de operação superiores aos recursos específicos 185
20.2.2. Alteração do valor padrão de uma operação de recurso para conjuntos de recursos (RHEL 8.3 e
posteriores) 186
20.2.3. Exibição dos valores padrão de operação dos recursos atualmente configurados 186
20.3. CONFIGURAÇÃO DE MÚLTIPLAS OPERAÇÕES DE MONITORAMENTO 187
. . . . . . . . . . . .21.
CAPÍTULO . . .PROPRIEDADES
. . . . . . . . . . . . . . . . . DO
. . . .CONJUNTO
. . . . . . . . . . . . .DO
. . . .MARCAPASSO
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188
...............
21.1. RESUMO DAS PROPRIEDADES E OPÇÕES DO CLUSTER 188
21.2. AJUSTE E REMOÇÃO DAS PROPRIEDADES DE AGRUPAMENTO 193
21.3. CONSULTA DE CONFIGURAÇÕES DE PROPRIEDADE DE CLUSTERS 194
CAPÍTULO 22. CONFIGURAÇÃO DE RECURSOS PARA PERMANECER PARADO NO DESLIGAMENTO DO NÓ

. . . . . . . .(RHEL
LIMPO . . . . . . .8.2
. . . .E. POSTERIORES)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195
...............
22.1. PROPRIEDADES DO CLUSTER PARA CONFIGURAR RECURSOS PARA PERMANECER PARADO NO
DESLIGAMENTO DO NÓ LIMPO 195
22.2. CONFIGURANDO A PROPRIEDADE DE BLOQUEIO DE FECHAMENTO 196
. . . . . . . . . . . .23.
CAPÍTULO . . . .CONFIGURAÇÃO
. . . . . . . . . . . . . . . . . .DE
. . . UMA
. . . . . .ESTRATÉGIA
. . . . . . . . . . . . . .DE
. . .POSICIONAMENTO
. . . . . . . . . . . . . . . . . . . . .DO
. . . NÓ
. . . . . . . . . . . . . . . . . . . . . . .198
...............
23.1. ATRIBUTOS DE UTILIZAÇÃO E ESTRATÉGIA DE COLOCAÇÃO 198
23.1.1. Configuração do nó e da capacidade de recursos 198
23.1.2. Configuração da estratégia de colocação 199
23.2. ALOCAÇÃO DE RECURSOS DO MARCAPASSO 199
23.2.1. Preferência de Nó 199
4
Índice
23.2.2. Capacidade do Nó 200

23.2.3. Preferência de Alocação de Recursos 200
23.3. DIRETRIZES DE ESTRATÉGIA DE COLOCAÇÃO DE RECURSOS 200
23.4. O AGENTE DE RECURSOS NODEUTILIZATION 201
. . . . . . . . . . . .24.
. . . . . . . . . . . . . . . . . .DE
. . . UM
. . . . DOMÍNIO
. . . . . . . . . . VIRTUAL
. . . . . . . . . . COMO
. . . . . . . .UM
. . . RECURSO
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202
...............
24.1. OPÇÕES DE RECURSOS DE DOMÍNIO VIRTUAL 202
24.2. CRIANDO O RECURSO DE DOMÍNIO VIRTUAL 238
. . . . . . . . . . . .25.
CAPÍTULO . . . QUÓRUM
. . . . . . . . . . .DE
. . . CLUSTER
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
................
25.1. CONFIGURAÇÃO DAS OPÇÕES DO QUORUM 240
25.2. MODIFICAÇÃO DAS OPÇÕES DO QUORUM 241
25.3. EXIBIÇÃO DA CONFIGURAÇÃO E STATUS DO QUORUM 242
25.4. EXECUÇÃO DE CLUSTERS DE INQUÉRITOS 242
25.5. DISPOSITIVOS DO QUORUM 243
25.5.1. Instalação de pacotes de dispositivos de quorum 243
25.5.2. Configuração de um dispositivo de quorum 243
25.5.3. Gerenciando o Serviço de Dispositivos Quorum 248
25.5.4. Gerenciamento das configurações do dispositivo de quorum em um cluster 248
25.5.4.1. Mudança das configurações do dispositivo de quorum 248
25.5.4.2. Remoção de um dispositivo de quorum 248
25.5.4.3. Destruindo um dispositivo de quorum 249
. . . . . . . . . . . .26.
CAPÍTULO . . . .ACIONAMENTO
. . . . . . . . . . . . . . . . DE
. . . .SCRIPTS
. . . . . . . . . PARA
. . . . . . .EVENTOS
. . . . . . . . . . .DE
. . .CLUSTER
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250
...............
26.1. INSTALAÇÃO E CONFIGURAÇÃO DE AMOSTRAS DE AGENTES DE ALERTA 250
26.2. CRIANDO UM ALERTA DE AGRUPAMENTO 251
26.3. EXIBIÇÃO, MODIFICAÇÃO E REMOÇÃO DE ALERTAS DE AGRUPAMENTO 252
26.4. CONFIGURAÇÃO DOS DESTINATÁRIOS DE ALERTA 252
26.5. META OPÇÕES DE ALERTA 253
26.6. EXEMPLOS DE COMANDOS DE CONFIGURAÇÃO DE ALERTAS 253
26.7. ESCREVER UM AGENTE DE ALERTA 255
. . . . . . . . . . . .27.
CAPÍTULO . . . CONFIGURAÇÃO
. . . . . . . . . . . . . . . . . . .DE
. . . CLUSTERS
. . . . . . . . . . . .DE
. . . MÚLTIPLOS
. . . . . . . . . . . . . LOCAIS
. . . . . . . . .COM
. . . . . . . . . . . . . . . . . . . . . . . . . . .258
...............
27.1. VISÃO GERAL DO GERENTE DE BILHETERIA DE ESTANDES 258
27.2. CONFIGURAÇÃO DE CLUSTERS DE MÚLTIPLOS LOCAIS COM PACEMAKER 258
CAPÍTULO 28. INTEGRAÇÃO DE NÓS NÃO-COROASYNC EM UM CLUSTER: O SERVIÇO

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .262
PACEMAKER_REMOTE ...............
28.1. AUTENTICAÇÃO DO HOSPEDEIRO E DO CONVIDADO DOS NÓS DE PACEMAKER_REMOTE 263
28.2. CONFIGURAÇÃO DOS NÓS CONVIDADOS DA KVM 263
28.2.1. Opções de recursos de nós de hóspedes 263
28.2.2. Integrando uma máquina virtual como um nó convidado 264
28.3. CONFIGURAÇÃO DOS NÓS REMOTOS DO PACEMAKER 265
28.3.1. Opções de recursos de nós remotos 265
28.3.2. Visão geral da configuração do nó remoto 273
28.4. MUDANDO A LOCALIZAÇÃO PADRÃO DA PORTA 274
28.5. ATUALIZAÇÃO DE SISTEMAS COM NÓS DE PACEMAKER_REMOTE 275
.CAPÍTULO
. . . . . . . . . . .29.
. . . .EXECUÇÃO
. . . . . . . . . . . . DE
. . . .MANUTENÇÃO
. . . . . . . . . . . . . . . .DE
. . . CLUSTERS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .276
...............
29.1. COLOCANDO UM NÓ EM MODO DE ESPERA 276
29.2. MOVIMENTAÇÃO MANUAL DOS RECURSOS DO CLUSTER 277
29.2.1. Movendo um recurso de seu nó atual 277
29.2.2. Movendo um recurso para seu nó de preferência 278
29.3. DESATIVAÇÃO, HABILITAÇÃO E PROIBIÇÃO DE RECURSOS DE CLUSTER 279
Desabilitando um recurso de cluster 279
5
Permitindo um recurso de cluster 279

Impedir que um recurso funcione em um determinado nó 279
Forçando um recurso a começar no nó atual 280
29.4. COLOCANDO UM RECURSO EM MODO NÃO GERENCIADO 280
29.5. COLOCANDO UM CLUSTER EM MODO DE MANUTENÇÃO 280
29.6. ATUALIZAÇÃO DE UM CLUSTER DE ALTA DISPONIBILIDADE RHEL 281
29.7. ATUALIZAÇÃO DE NÓS REMOTOS E NÓS DE CONVIDADOS 281
29.8. MIGRAÇÃO DE VMS EM UM CLUSTER RHEL 282
. . . . . . . . . . . .30.
. . . . . . . . . . . . . . . . . .DE
. . . CLUSTERS
. . . . . . . . . . . . DE
. . . .RECUPERAÇÃO
. . . . . . . . . . . . . . . . DE
. . . .DESASTRES
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .284
...............
30.1. CONSIDERAÇÕES SOBRE CLUSTERS DE RECUPERAÇÃO DE DESASTRES 284
30.2. EXIBIÇÃO DO STATUS DOS CLUSTERS DE RECUPERAÇÃO (RHEL 8.2 E POSTERIORES) 284
6
Índice
7
TORNANDO O CÓDIGO ABERTO MAIS INCLUSIVO

A Red Hat tem o compromisso de substituir a linguagem problemática em nosso código, documentação
e propriedades da web. Estamos começando com estes quatro termos: master, slave, blacklist e
whitelist. Por causa da enormidade deste esforço, estas mudanças serão implementadas gradualmente
ao longo de vários lançamentos futuros. Para mais detalhes, veja a mensagem de nosso CTO Chris
Wright.
8
FORNECENDO FEEDBACK SOBRE A DOCUMENTAÇÃO DA RED HAT
FORNECENDO FEEDBACK SOBRE A DOCUMENTAÇÃO DA

RED HAT
Agradecemos sua contribuição em nossa documentação. Por favor, diga-nos como podemos melhorá-
la. Para fazer isso:
Para comentários simples sobre passagens específicas:
1. Certifique-se de que você está visualizando a documentação no formato Multi-page HTML.

Além disso, certifique-se de ver o botão Feedback no canto superior direito do documento.
2. Use o cursor do mouse para destacar a parte do texto que você deseja comentar.
3. Clique no pop-up Add Feedback que aparece abaixo do texto destacado.
4. Siga as instruções apresentadas.
Para enviar comentários mais complexos, crie um bilhete Bugzilla:
1. Ir para o site da Bugzilla.
2. Como Componente, use Documentation.
3. Preencha o campo Description com sua sugestão de melhoria. Inclua um link para a(s)
parte(s) relevante(s) da documentação.
4. Clique em Submit Bug.
9
CAPÍTULO 1. VISÃO GERAL DO ADD-ON DE ALTA

DISPONIBILIDADE
O Add-On de Alta Disponibilidade é um sistema agrupado que proporciona confiabilidade,
escalabilidade e disponibilidade para serviços críticos de produção.
Um cluster são dois ou mais computadores (chamados nodes ou members) que trabalham juntos para
realizar uma tarefa. Os clusters podem ser usados para fornecer serviços ou recursos altamente
disponíveis. A redundância de múltiplas máquinas é usada para proteger contra falhas de muitos tipos.
Os clusters de alta disponibilidade oferecem serviços altamente disponíveis, eliminando pontos únicos
de falha e falhando nos serviços de um nó de cluster para outro caso um nó se torne inoperante.
Tipicamente, os serviços em um cluster de alta disponibilidade lêem e escrevem dados (por meio de
sistemas de arquivos montados de leitura-escrita). Portanto, um cluster de alta disponibilidade deve
manter a integridade dos dados quando um nó de cluster assume o controle de um serviço de outro nó
de cluster. As falhas de um nó em um cluster de alta disponibilidade não são visíveis de clientes fora do
cluster. (Os clusters de alta disponibilidade são às vezes chamados de clusters de failover.) O Add-On
de Alta Disponibilidade fornece clustering de alta disponibilidade através de seu componente de
gerenciamento de serviços de alta disponibilidade, Pacemaker.
1.1. COMPONENTES ADICIONAIS DE ALTA DISPONIBILIDADE

O Add-On de Alta Disponibilidade consiste nos seguintes componentes principais:
Infra-estrutura do cluster
Gestão de serviços de alta disponibilidade
Ferramentas de administração de clusters
Você pode complementar o Add-On de Alta Disponibilidade com os seguintes componentes:
Red Hat GFS2 (Global File System 2)
LVM Locking Daemon (lvmlockd)
Balanceador de carga
1.2. VISÃO GERAL DO MARCAPASSO

Pacemaker é um gerente de recursos de cluster. Ele alcança a máxima disponibilidade para seus serviços
e recursos de cluster fazendo uso das capacidades de mensagens e membros da infra-estrutura de
cluster para dissuadir e recuperar de falhas nos nós e nos recursos.
1.2.1. Componentes da arquitetura do marcapasso

Um cluster configurado com Pacemaker é composto de daemons componentes separados que
monitoram os membros do cluster, scripts que gerenciam os serviços, e subsistemas de gerenciamento
de recursos que monitoram os recursos díspares.
Os seguintes componentes formam a arquitetura do Pacemaker:
Base de Informações do Cluster (CIB)
O daemon de informação do Pacemaker, que usa XML internamente para distribuir e sincronizar a
10
CAPÍTULO 1. VISÃO GERAL DO ADD-ON DE ALTA DISPONIBILIDADE
O daemon de informação do Pacemaker, que usa XML internamente para distribuir e sincronizar a
configuração atual e informações de status do Coordenador Designado (DC)
Daemon de Gerenciamento de Recursos de Cluster (CRMd)
As ações de recursos de agrupamento de marcapassos são encaminhadas através deste daemon. Os
recursos gerenciados pelo CRMd podem ser consultados pelos sistemas do cliente, movidos,
instanciados e alterados quando necessário.
Cada nó de cluster também inclui um daemon (LRMd) gerente de recursos local que atua como uma
interface entre CRMd e recursos. O LRMd passa os comandos do CRMd para os agentes, tais como
iniciar e parar e retransmitir informações de status.
Atire no Outro Nó da Cabeça (STONITH)

STONITH é a implementação da esgrima do Pacemaker. Ela atua como um recurso de cluster no
Pacemaker que processa pedidos de cercas, fechando forçosamente os nós e removendo-os do
cluster para garantir a integridade dos dados. STONITH é configurado na CIB e pode ser monitorado
como um recurso normal de cluster. Para uma visão geral das cercas, veja Seção 1.3, “Visão geral da
vedação”.
corosync
corosync é o componente - e um daemon com o mesmo nome - que atende às principais
necessidades de adesão e de comunicação dos membros para os clusters de alta disponibilidade. Ele
é necessário para que o Add-On de Alta Disponibilidade funcione.
Além dessas funções de afiliação e de envio de mensagens, corosync também:
Gerencia as regras de quorum e determinação.
Fornece recursos de mensagens para aplicações que coordenam ou operam em múltiplos

membros do cluster e, portanto, devem comunicar informações estatais ou outras
informações entre as instâncias.
Utiliza a biblioteca kronosnet como seu transporte de rede para fornecer múltiplos links
redundantes e failover automático.
1.2.2. Ferramentas de configuração e gerenciamento

O Add-On de Alta Disponibilidade apresenta duas ferramentas de configuração para implantação,
monitoramento e gerenciamento de clusters.
pcs
A interface de linha de comando pcs controla e configura o Pacemaker e o daemon de batimento
cardíaco corosync. Um programa baseado em linha de comando, pcs pode realizar as seguintes
tarefas de gerenciamento de clusters:
Criar e configurar um cluster Pacemaker/Corosync
Modificar a configuração do cluster enquanto ele está funcionando
Configurar remotamente tanto Pacemaker e Corosync, quanto iniciar, parar e exibir

informações de status do cluster
pcsd Web UI
Uma interface gráfica do usuário para criar e configurar clusters Pacemaker/Corosync.
1.2.3. Os arquivos de configuração do cluster e do marcapasso
11
Os arquivos de configuração para o Red Hat High Availability Add-On são corosync.conf e cib.xml.
O arquivo corosync.conf fornece os parâmetros de cluster usados pelo corosync, o gerenciador de

cluster em que a Pacemaker é construída. Em geral, você não deve editar o corosync.conf
diretamente, mas, em vez disso, usar a interface pcs ou pcsd.
O arquivo cib.xml é um arquivo XML que representa tanto a configuração do cluster quanto o estado
atual de todos os recursos no cluster. Este arquivo é utilizado pela Pacemaker's Cluster Information
Base (CIB). O conteúdo da CIB é mantido automaticamente em sincronia em todo o cluster. Não edite
o arquivo cib.xml diretamente; use a interface pcs ou pcsd em seu lugar.
1.3. VISÃO GERAL DA VEDAÇÃO

Se a comunicação com um único nó do cluster falhar, então outros nós do cluster devem ser capazes de
restringir ou liberar o acesso a recursos aos quais o nó de cluster falhado possa ter acesso. Isto não pode
ser feito contatando o próprio nó de cluster, pois o nó de cluster pode não ser responsivo. Ao invés
disso, deve-se fornecer um método externo, que é chamado de vedação com um agente de vedação.
Um dispositivo de cerca é um dispositivo externo que pode ser usado pelo cluster para restringir o
acesso a recursos compartilhados por um nó errante, ou para emitir uma reinicialização dura no nó de
cluster.
Sem um dispositivo de cerca configurado, você não tem como saber que os recursos usados
anteriormente pelo nó de cluster desconectado foram liberados, e isso poderia impedir que os serviços
funcionassem em qualquer um dos outros nós de cluster. Por outro lado, o sistema pode assumir
erroneamente que o nó de cluster liberou seus recursos e isto pode levar à corrupção e perda de dados.
Sem um dispositivo de cerca, a integridade dos dados configurados não pode ser garantida e a
configuração do cluster não será suportada.
Quando a vedação está em andamento, nenhuma outra operação de agrupamento é permitida. A

operação normal do aglomerado não pode ser retomada até que a vedação tenha sido concluída ou o nó
de aglomerado volte a juntar-se ao aglomerado depois que o nó de aglomerado tiver sido reinicializado.
Para mais informações sobre esgrima, consulte Esgrima em um Aglomerado de Alta Disponibilidade da
Red Hat.
1.4. VISÃO GERAL DO QUORUM

A fim de manter a integridade e disponibilidade do cluster, os sistemas de cluster utilizam um conceito
conhecido como quorum para evitar a corrupção e perda de dados. Um cluster tem quorum quando
mais da metade dos nós do cluster estão on-line. Para mitigar a chance de corrupção de dados devido a
falhas, o Pacemaker por padrão pára todos os recursos se o cluster não tiver quorum.
O Quorum é estabelecido usando um sistema de votação. Quando um nó de agrupamento não funciona

como deveria ou perde a comunicação com o resto do agrupamento, os nós de trabalho da maioria
podem votar para isolar e, se necessário, cercar o nó para manutenção.
Por exemplo, em um cluster de 6 nós, o quorum é estabelecido quando pelo menos 4 nós de cluster
estão funcionando. Se a maioria dos nós ficar offline ou indisponível, o aglomerado não tem mais
quórum e o Pacemaker pára os serviços de aglomeração.
As características do quorum em Pacemaker impedem o que também é conhecido como split-brain, um

fenômeno onde o cluster é separado da comunicação, mas cada parte continua trabalhando como
clusters separados, potencialmente escrevendo para os mesmos dados e possivelmente causando
corrupção ou perda. Para mais informações sobre o que significa estar em um estado de cérebro
dividido, e sobre conceitos de quórum em geral, veja Exploring Concepts of RHEL High Availability
Clusters - Quorum.
12
CAPÍTULO 1. VISÃO GERAL DO ADD-ON DE ALTA DISPONIBILIDADE
Um cluster do Red Hat Enterprise Linux High Availability Add-On usa o serviço votequorum, em
conjunto com a esgrima, para evitar situações de cérebro dividido. Um número de votos é atribuído a
cada sistema no cluster, e as operações de cluster são permitidas somente quando uma maioria de
votos está presente.
1.5. VISÃO GERAL DOS RECURSOS

A cluster resource é uma instância de programa, dados ou aplicação a ser gerenciada pelo serviço de
cluster. Estes recursos são abstraídos por agents que fornecem uma interface padrão para gerenciar o
recurso em um ambiente de cluster.
Para garantir que os recursos permaneçam saudáveis, você pode acrescentar uma operação de
monitoramento à definição de um recurso. Se você não especificar uma operação de monitoramento
para um recurso, uma é adicionada por padrão.
Você pode determinar o comportamento de um recurso em um cluster configurando constraints. Você

pode configurar as seguintes categorias de restrições:
restrições de localização
restrições de pedidos
restrições de colocação
Um dos elementos mais comuns de um agrupamento é um conjunto de recursos que precisam ser
localizados juntos, começar sequencialmente e parar na ordem inversa. Para simplificar esta
configuração, o Pacemaker apóia o conceito de groups.
1.6. VOLUMES LÓGICOS LVM EM UM CLUSTER DE ALTA

DISPONIBILIDADE DA RED HAT
O Red Hat High Availability Add-On oferece suporte para volumes LVM em duas configurações de
cluster distintas:
Volumes LVM de alta disponibilidade (HA-LVM) em configurações de failover ativo/passivo em

que apenas um único nó do cluster acessa o armazenamento a qualquer momento.
Volumes LVM que utilizam o daemon lvmlockd para gerenciar dispositivos de armazenamento
em configurações ativas/ativas nas quais mais de um nó do cluster requer acesso ao
armazenamento ao mesmo tempo. O daemon lvmlockd faz parte do Add-On de
Armazenamento Resiliente.
1.6.1. Escolhendo HA-LVM ou volumes compartilhados

Quando usar o HA-LVM ou volumes lógicos compartilhados gerenciados pelo daemon lvmlockd devem
ser baseados nas necessidades das aplicações ou serviços que estão sendo implantados.
Se vários nós do cluster requerem acesso simultâneo de leitura/escrita a volumes LVM em um

sistema ativo/ativo, então você deve usar o daemon lvmlockd e configurar seus volumes como
volumes compartilhados. O daemon lvmlockd fornece um sistema para coordenar a ativação e
as mudanças nos volumes LVM entre os nós de um cluster simultaneamente. O serviço de
travamento do daemon lvmlockd oferece proteção aos metadados do LVM à medida que
vários nós do cluster interagem com os volumes e fazem alterações em seu layout. Esta
proteção depende da configuração de qualquer grupo de volume que será ativado
simultaneamente em vários nós de cluster como um volume compartilhado.
13
Se o cluster de alta disponibilidade for configurado para gerenciar recursos compartilhados de

forma ativa/passiva com apenas um único membro precisando de acesso a um determinado
volume de LVM de cada vez, então você pode usar o HA-LVM sem o serviço de travamento
lvmlockd.
A maioria das aplicações funcionará melhor em uma configuração ativa/passiva, já que não são
projetadas ou otimizadas para funcionar concomitantemente com outras instâncias. Optar por executar
uma aplicação que não seja sensível a cluster em volumes lógicos compartilhados pode resultar em
desempenho degradado. Isto ocorre porque há uma sobrecarga de comunicação em cluster para os
próprios volumes lógicos nestas instâncias. Uma aplicação com consciência de cluster deve ser capaz de
alcançar ganhos de desempenho acima das perdas de desempenho introduzidas pelos sistemas de
arquivos de cluster e volumes lógicos com consciência de cluster. Isto é possível para algumas
aplicações e cargas de trabalho mais facilmente do que para outras. Determinar quais são os requisitos
do cluster e se o esforço extra para otimizar um cluster ativo/ativo trará dividendos é a maneira de
escolher entre as duas variantes do LVM. A maioria dos usuários alcançará os melhores resultados HA
com o uso do HA-LVM.
HA-LVM e volumes lógicos compartilhados usando lvmlockd são semelhantes no fato de que evitam a
corrupção de metadados LVM e seus volumes lógicos, o que poderia ocorrer se várias máquinas fossem
permitidas a fazer mudanças sobrepostas. O HA-LVM impõe a restrição de que um volume lógico só
pode ser ativado exclusivamente; ou seja, ativo em apenas uma máquina de cada vez. Isto significa que
somente implementações locais (não exclusivas) dos drivers de armazenamento são utilizadas. Evitar a
sobrecarga de coordenação do cluster desta forma aumenta o desempenho. Um volume compartilhado
usando lvmlockd não impõe estas restrições e um usuário é livre para ativar um volume lógico em todas
as máquinas em um cluster; isto força o uso de drivers de armazenamento sensíveis ao cluster, que
permitem que sistemas de arquivos e aplicações sensíveis ao cluster sejam colocados em cima.
1.6.2. Configuração de volumes LVM em um cluster

No Red Hat Enterprise Linux 8, os clusters são gerenciados através do Pacemaker. Tanto o HA-LVM
quanto os volumes lógicos compartilhados são suportados somente em conjunto com os clusters
Pacemaker, e devem ser configurados como recursos de cluster.
Para exemplos de procedimentos para configurar um volume HA-LVM como parte de um

cluster Pacemaker, veja Configurando um servidor HTTP Apache ativo/passivo em um cluster
Red Hat High Availability. e Configurando um servidor NFS ativo/passivo em um cluster Red
Hat High Availability.
Observe que estes procedimentos incluem os seguintes passos:
Assegurar que somente o agrupamento seja capaz de ativar o grupo de volume
Configuração de um volume lógico LVM
Configuração do volume da LVM como um recurso de cluster
Para um procedimento de configuração de volumes LVM compartilhados que utilizam o

daemon lvmlockd para gerenciar dispositivos de armazenamento em configurações
ativas/ativas, consulte Configuração de um sistema de arquivos GFS2 em um cluster
14
CAPÍTULO 2. COMEÇANDO COM PACEMAKER

Os seguintes procedimentos fornecem uma introdução às ferramentas e processos que você utiliza
para criar um cluster Pacemaker. Eles são destinados aos usuários que estão interessados em ver como
é o software do cluster e como ele é administrado, sem a necessidade de configurar um cluster
funcional.
NOTA
Estes procedimentos não criam um cluster Red Hat suportado, que requer pelo menos
dois nós e a configuração de um dispositivo de esgrima.
2.1. APRENDENDO A USAR O PACEMAKER

Este exemplo requer um único nó rodando RHEL 8 e requer um endereço IP flutuante que reside na
mesma rede que um dos endereços IP atribuídos estaticamente a um dos nós.
O nó utilizado neste exemplo é z1.example.com.
O endereço IP flutuante usado neste exemplo é 192.168.122.120.
NOTA
Certifique-se de que o nome do nó em que você está rodando esteja em seu arquivo
/etc/hosts.
Trabalhando através deste procedimento, você aprenderá como usar o Pacemaker para configurar um
cluster, como exibir o status do cluster, e como configurar um serviço de cluster. Este exemplo cria um
servidor HTTP Apache como um recurso de cluster e mostra como o cluster responde quando o recurso
falha.
1. Instale os pacotes de software Red Hat High Availability Add-On a partir do canal High
Availability, e inicie e habilite o serviço pcsd.
# yum install pcs pacemaker fence-agents-all

...
# systemctl start pcsd.service
# systemctl enable pcsd.service
Se você estiver rodando o daemon firewalld, habilite os portos que são exigidos pelo
suplemento de alta disponibilidade da Red Hat.
# firewall-cmd --permanent --add-service=high-availability

# firewall-cmd --reload
2. Defina uma senha para o usuário hacluster em cada nó do cluster e autentique o usuário
hacluster para cada nó do cluster no nó a partir do qual você executará os comandos pcs. Este
exemplo está usando apenas um único nó, o nó a partir do qual você está executando os
comandos, mas esta etapa está incluída aqui uma vez que é uma etapa necessária na
configuração de um cluster multi-nó de alta disponibilidade compatível com a Red Hat High
Availability.
15
# passwd hacluster
...
# pcs host auth z1.example.com
3. Criar um agrupamento chamado my_cluster com um membro e verificar o status do

agrupamento. Este comando cria e inicia o agrupamento em uma única etapa.
# pcs cluster setup my_cluster --start z1.example.com

...
# pcs cluster status
Cluster Status:
Stack: corosync
Current DC: z1.example.com (version 2.0.0-10.el8-b67d8d0de9) - partition with quorum
Last updated: Thu Oct 11 16:11:18 2018
Last change: Thu Oct 11 16:11:00 2018 by hacluster via crmd on z1.example.com
1 node configured
0 resources configured
PCSD Status:
z1.example.com: Online
4. Um aglomerado Red Hat High Availability requer que você configure a vedação para o
aglomerado. As razões para esta exigência estão descritas em Esgrima em um Aglomerado de
Alta Disponibilidade da Red Hat. Para esta introdução, entretanto, que se destina a mostrar
apenas como usar os comandos básicos do Marcapasso, desabilite o cercado definindo a opção
de cercado do stonith-enabled para false.

ATENÇÃO
O uso do stonith-enabled=false é completamente inadequado para um

cluster de produção. Ele diz ao aglomerado para simplesmente fingir que os
nós falhados estão cercados com segurança.
# pcs property set stonith-enabled=false
5. Configure um navegador web em seu sistema e crie uma página web para exibir uma simples
mensagem de texto. Se você estiver executando o daemon firewalld, habilite as portas que são
exigidas por httpd.
NOTA
Não utilize systemctl enable para permitir que quaisquer serviços que serão
gerenciados pelo cluster comecem na inicialização do sistema.
# yum install -y httpd wget

...
# firewall-cmd --permanent --add-service=http
16
# cat <<-END >/var/www/html/index.html

<html>
<body>My Test Site - $(hostname)</body>
</html>
END
Para que o agente de recursos Apache obtenha o status do Apache, crie a seguinte adição à
configuração existente para habilitar a URL do servidor de status.
# cat <<-END > /etc/httpd/conf.d/status.conf

<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1
Allow from ::1
</Location>
END
6. Crie recursos para o cluster IPaddr2 e apache para gerenciá-lo. O recurso 'IPaddr2' é um
endereço IP flutuante que não deve ser um já associado a um nó físico. Se o dispositivo NIC do
recurso 'IPaddr2' não for especificado, o IP flutuante deve residir na mesma rede que o
endereço IP estaticamente atribuído usado pelo nó.
Você pode exibir uma lista de todos os tipos de recursos disponíveis com o comando pcs
resource list. Você pode usar o comando pcs resource describe resourcetype para exibir os
parâmetros que você pode definir para o tipo de recurso especificado. Por exemplo, o seguinte
comando exibe os parâmetros que você pode definir para um recurso do tipo apache:
# pcs resource describe apache

...
Neste exemplo, o recurso de endereço IP e o recurso apache são ambos configurados como
parte de um grupo chamado apachegroup, o que garante que os recursos sejam mantidos
juntos para funcionar no mesmo nó quando você estiver configurando um cluster de vários nós
em funcionamento.
# pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=192.168.122.120 --group

apachegroup
# pcs resource create WebSite ocf:heartbeat:apache

configfile=/etc/httpd/conf/httpd.conf statusurl="http://localhost/server-status" --group
apachegroup
# pcs status
Cluster name: my_cluster
Stack: corosync
Last updated: Fri Oct 12 09:54:33 2018
Last change: Fri Oct 12 09:54:30 2018 by root via cibadmin on z1.example.com
1 node configured
Online: [ z1.example.com ]
17
Full list of resources:
Resource Group: apachegroup

ClusterIP (ocf::heartbeat:IPaddr2): Started z1.example.com
WebSite (ocf::heartbeat:apache): Started z1.example.com
PCSD Status:
...
Após ter configurado um recurso de cluster, você pode usar o comando pcs resource config
para exibir as opções que estão configuradas para aquele recurso.
# pcs resource config WebSite

Resource: WebSite (class=ocf provider=heartbeat type=apache)
Attributes: configfile=/etc/httpd/conf/httpd.conf statusurl=http://localhost/server-status
Operations: start interval=0s timeout=40s (WebSite-start-interval-0s)
stop interval=0s timeout=60s (WebSite-stop-interval-0s)
monitor interval=1min (WebSite-monitor-interval-1min)
7. Aponte seu navegador para o site que você criou usando o endereço IP flutuante que você
configurou. Isto deve exibir a mensagem de texto que você definiu.
8. Pare o serviço web apache e verifique o status do cluster. O uso do killall -9 simula uma falha
em nível de aplicação.
# killall -9 httpd
Verifique o status do agrupamento. Você deve ver que parar o serviço web causou uma ação
fracassada, mas que o software de cluster reiniciou o serviço e você ainda deve ser capaz de
acessar o site.
# pcs status
...
Current DC: z1.example.com (version 1.1.13-10.el7-44eb2dd) - partition with quorum
1 node and 2 resources configured

Failed Resource Actions:

* WebSite_monitor_60000 on z1.example.com 'not running' (7): call=13, status=complete,
exitreason='none',
last-rc-change='Thu Oct 11 23:45:50 2016', queued=0ms, exec=0ms
PCSD Status:
18
Você pode limpar o status de falha no recurso que falhou uma vez que o serviço esteja
funcionando novamente e o aviso de falha de ação não aparecerá mais quando você visualizar o
status do cluster.
# pcs resource cleanup WebSite
9. Quando terminar de olhar o agrupamento e o status do agrupamento, pare os serviços de

agrupamento no nó. Embora você só tenha iniciado os serviços em um nó para esta introdução,
o parâmetro --all está incluído, pois pararia os serviços de cluster em todos os nós de um cluster
real de vários nós.
# pcs cluster stop --all
2.2. APRENDENDO A CONFIGURAR O FAILOVER

Este procedimento fornece uma introdução à criação de um agrupamento de Pacemaker executando
um serviço que irá falhar de um nó para outro quando o nó no qual o serviço está sendo executado se
tornar indisponível. Trabalhando através deste procedimento, você pode aprender como criar um
serviço em um cluster de dois nós e então você pode observar o que acontece com esse serviço quando
ele falha no nó em que está rodando.
Este procedimento de exemplo configura um cluster de dois nós Pacemaker rodando um servidor
Apache HTTP. Você pode então parar o serviço Apache em um nó para ver como o serviço permanece
disponível.
Este procedimento requer como pré-requisito que você tenha dois nós rodando o Red Hat Enterprise
Linux 8 que possam se comunicar um com o outro, e requer um endereço IP flutuante que resida na
mesma rede que um dos endereços IP atribuídos estaticamente a um dos nós.
Os nós utilizados neste exemplo são z1.example.com e z2.example.com.
O endereço IP flutuante usado neste exemplo é 192.168.122.120.
NOTA
Certifique-se de que os nomes dos nós que você está usando estão no arquivo
/etc/hosts em cada nó.
1. Em ambos os nós, instalar os pacotes de software Red Hat High Availability Add-On do canal
High Availability, e iniciar e habilitar o serviço pcsd.

...
Se você estiver rodando o daemon firewalld, em ambos os nós habilite as portas que são
exigidas pelo Add-On de Alta Disponibilidade da Red Hat.

2. Em ambos os nós do cluster, defina uma senha para o usuário hacluster.
19
# passwd hacluster
3. Autentique o usuário hacluster para cada nó do cluster no nó a partir do qual você estará
executando os comandos pcs.
# pcs host auth z1.example.com z2.example.com
4. Criar um cluster chamado my_cluster com ambos os nós como membros do cluster. Este
comando cria e inicia o agrupamento em uma única etapa. Você só precisa executar isto a partir
de um nó no cluster porque os comandos de configuração pcs entram em vigor para o cluster
inteiro.
Em um nó em cluster, execute o seguinte comando.
# pcs cluster setup my_cluster --start z1.example.com z2.example.com
5. Um aglomerado Red Hat High Availability requer que você configure a vedação para o
aglomerado. As razões para esta exigência estão descritas em Esgrima em um Aglomerado de
Alta Disponibilidade da Red Hat. Para esta introdução, porém, para mostrar apenas como
funciona o failover nesta configuração, desabilite a vedação definindo a opção de cluster
stonith-enabled para false

ATENÇÃO
O uso do stonith-enabled=false é completamente inadequado para um

cluster de produção. Ele diz ao aglomerado para simplesmente fingir que os
nós falhados estão cercados com segurança.
# pcs property set stonith-enabled=false
6. Após criar um agrupamento e desativar a vedação, verifique o status do agrupamento.
NOTA
Quando você executa o comando pcs cluster status, ele pode mostrar uma
saída que difere temporariamente dos exemplos à medida que os componentes
do sistema são iniciados.
# pcs cluster status

Cluster Status:
Stack: corosync
2 nodes configured
20
PCSD Status:
7. Em ambos os nós, configure um navegador web e crie uma página web para exibir uma
mensagem de texto simples. Se você estiver executando o daemon firewalld, habilite as portas
que são exigidas por httpd.
NOTA
Não utilize systemctl enable para permitir que quaisquer serviços que serão
gerenciados pelo cluster comecem na inicialização do sistema.

...
# firewall-cmd --permanent --add-service=http

<html>
<body>My Test Site - $(hostname)</body>
</html>
END
Para que o agente de recursos Apache obtenha o status do Apache, em cada nó do cluster crie
a seguinte adição à configuração existente para habilitar a URL do servidor de status.
# cat <<-END > /etc/httpd/conf.d/status.conf

Order deny,allow
Deny from all
Allow from 127.0.0.1
Allow from ::1
</Location>
END
8. Crie recursos para o cluster IPaddr2 e apache para gerenciá-lo. O recurso 'IPaddr2' é um
endereço IP flutuante que não deve ser um já associado a um nó físico. Se o dispositivo NIC do
recurso 'IPaddr2' não for especificado, o IP flutuante deve residir na mesma rede que o
endereço IP estaticamente atribuído usado pelo nó.
Você pode exibir uma lista de todos os tipos de recursos disponíveis com o comando pcs
resource list. Você pode usar o comando pcs resource describe resourcetype para exibir os
parâmetros que você pode definir para o tipo de recurso especificado. Por exemplo, o seguinte
comando exibe os parâmetros que você pode definir para um recurso do tipo apache:
# pcs resource describe apache

...
Neste exemplo, o recurso de endereço IP e o recurso apache são ambos configurados como
parte de um grupo chamado apachegroup, o que garante que os recursos sejam mantidos
juntos para funcionar no mesmo nó.
Execute os seguintes comandos a partir de um nó no aglomerado:
21
# pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=192.168.122.120 --group

apachegroup
# pcs resource create WebSite ocf:heartbeat:apache

configfile=/etc/httpd/conf/httpd.conf statusurl="http://localhost/server-status" --group
apachegroup
# pcs status
Stack: corosync
2 nodes configured
Online: [ z1.example.com z2.example.com ]

PCSD Status:
...
Note que, neste caso, o serviço apachegroup está rodando no nó z1.example.com.
9. Acesse o site que você criou, pare o serviço no nó em que ele está funcionando e observe como
o serviço falha até o segundo nó.
a. Aponte um navegador para o site que você criou usando o endereço IP flutuante que você
configurou. Isto deve exibir a mensagem de texto que você definiu, exibindo o nome do nó
no qual o site está rodando.
b. Pare o serviço web apache. O uso do killall -9 simula uma falha no nível de aplicação.
# killall -9 httpd
Verifique o status do agrupamento. Você deve ver que parar o serviço web causou uma
ação falhada, mas que o software de cluster reiniciou o serviço no nó no qual ele estava
rodando e você ainda deve ser capaz de acessar o navegador web.
# pcs status
Stack: corosync
2 nodes configured
22

Failed Resource Actions:

* WebSite_monitor_60000 on z1.example.com 'not running' (7): call=31,
status=complete, exitreason='none',
last-rc-change='Fri Feb 5 21:01:41 2016', queued=0ms, exec=0ms
Limpar o status de falha uma vez que o serviço esteja funcionando novamente.
# pcs resource cleanup WebSite
c. Coloque o nó sobre o qual o serviço está funcionando em modo de espera. Observe que,
como desativamos a vedação, não podemos efetivamente simular uma falha no nível do
aceno (como puxar um cabo de força) porque a vedação é necessária para que o
aglomerado se recupere de tais situações.
# pcs node standby z1.example.com
d. Verifique o status do grupo e anote onde o serviço está funcionando agora.
# pcs status
Stack: corosync
2 nodes configured
Node z1.example.com: standby


e. Acesse o site. Não deve haver perda de serviço, embora a mensagem de exibição deva
indicar o nó em que o serviço está agora em execução.
10. Para restaurar os serviços de agrupamento para o primeiro nó, tire o nó do modo de espera. Isto
não irá necessariamente mover o serviço de volta para aquele nó.
# pcs node unstandby z1.example.com
23
11. Para a limpeza final, pare os serviços de agrupamento em ambos os nós.
# pcs cluster stop --all
24
CAPÍTULO 3. A INTERFACE DE LINHA DE COMANDO PCS

A interface de linha de comando pcs controla e configura serviços de cluster como corosync,
pacemaker,booth, e sbd, fornecendo uma interface mais fácil para seus arquivos de configuração.
Note que você não deve editar o arquivo de configuração cib.xml diretamente. Na maioria dos casos, o
Pacemaker rejeitará um arquivo cib.xml diretamente modificado.
3.1. PCS AJUDAM A EXIBIR

Você pode usar a opção -h de pcs para exibir os parâmetros de um comando pcs e uma descrição
desses parâmetros. Por exemplo, o comando a seguir exibe os parâmetros do comando pcs resource.
Apenas uma parte da saída é mostrada.
# pcs resource -h
3.2. VISUALIZANDO A CONFIGURAÇÃO DO CLUSTER BRUTO

Embora você não deva editar o arquivo de configuração de cluster diretamente, você pode visualizar a
configuração de cluster em bruto com o comando pcs cluster cib.
Você pode salvar a configuração do cluster bruto em um arquivo especificado com o pcs cluster cib
filename comando. Se você tiver configurado previamente um cluster e já houver um CIB ativo, você
usa o seguinte comando para salvar o arquivo xml bruto.
pcs cluster cib filename
Por exemplo, o seguinte comando salva o xml bruto da CIB em um arquivo chamado testfile.
pcs cluster cib test file
3.3. SALVANDO UMA MUDANÇA DE CONFIGURAÇÃO PARA UM

ARQUIVO DE TRABALHO
Ao configurar um cluster, você pode salvar as alterações de configuração em um arquivo especificado
sem afetar a CIB ativa. Isto permite que você especifique atualizações de configuração sem atualizar
imediatamente a configuração de cluster em execução no momento com cada atualização individual.
Para informações sobre como salvar o CIB em um arquivo, consulte Visualização da configuração do
cluster bruto. Uma vez criado esse arquivo, você pode salvar as alterações de configuração nesse
arquivo em vez de na CIB ativa, usando a opção -f do comando pcs. Quando você tiver concluído as
mudanças e estiver pronto para atualizar o arquivo CIB ativo, você pode empurrar essas atualizações de
arquivo com o comando pcs cluster cib-push.
A seguir, o procedimento recomendado para empurrar mudanças no arquivo CIB. Este procedimento
cria uma cópia do arquivo CIB original gravado e faz alterações nessa cópia. Ao empurrar essas
alterações para o arquivo CIB ativo, este procedimento especifica a opção diff-against do comando pcs
cluster cib-push para que somente as alterações entre o arquivo original e o arquivo atualizado sejam
empurradas para o CIB. Isto permite que os usuários façam alterações em paralelo que não se
sobrepõem e reduz a carga no Pacemaker que não precisa analisar o arquivo de configuração inteiro.
1. Salvar a CIB ativa em um arquivo. Este exemplo salva a CIB em um arquivo chamado
25
1. Salvar a CIB ativa em um arquivo. Este exemplo salva a CIB em um arquivo chamado
original.xml.
# pcs cluster cib original.xml
2. Copie o arquivo salvo para o arquivo de trabalho que você estará usando para as atualizações de
configuração.
# cp original.xml updated.xml
3. Atualize sua configuração conforme necessário. O seguinte comando cria um recurso no arquivo
updated.xml, mas não adiciona esse recurso à configuração de cluster atualmente em
execução.
# pcs -f updated.xml resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.120

op monitor interval=30s
4. Empurre o arquivo atualizado para a CIB ativa, especificando que você está empurrando apenas
as mudanças que fez no arquivo original.
# pcs cluster cib-push updated.xml diff-against=original.xml
Alternativamente, você pode empurrar todo o conteúdo atual de um arquivo CIB com o seguinte
comando.
pcs cluster cib-push filename
Ao empurrar o arquivo CIB inteiro, o Pacemaker verifica a versão e não permite que você empurre um
arquivo CIB que seja mais antigo do que aquele já em um cluster. Se você precisar atualizar o arquivo
CIB inteiro com uma versão mais antiga que a que está atualmente no cluster, você pode usar a opção --
config do comando pcs cluster cib-push.
pcs cluster cib-push --config filename
3.4. EXIBIÇÃO DO STATUS DO CLUSTER

Você pode exibir o status do agrupamento e os recursos do agrupamento com o seguinte comando.
status pcs
Você pode exibir o status de um determinado componente de cluster com o parâmetro commands do
comando pcs status, especificando resources, cluster, nodes, ou pcsd.
status pcs commands
Por exemplo, o seguinte comando exibe o status dos recursos do cluster.
recursos de status pcs
O seguinte comando exibe o status do agrupamento, mas não os recursos do agrupamento.
26
pcs status de cluster
3.5. EXIBIÇÃO DA CONFIGURAÇÃO COMPLETA DO CLUSTER

Use o seguinte comando para exibir a configuração atual completa do cluster.
pcs config
27
CAPÍTULO 4. CRIANDO UM CLUSTER DE ALTA

DISPONIBILIDADE RED HAT COM PACEMAKER
O seguinte procedimento cria um cluster de dois nós Red Hat High Availability usando pcs.
A configuração do cluster neste exemplo requer que seu sistema inclua os seguintes componentes:
2 nós, que serão usados para criar o agrupamento. Neste exemplo, os nós utilizados são
z1.example.com e z2.example.com.
Comutadores de rede para a rede privada. Recomendamos, mas não exigimos uma rede privada
para a comunicação entre os nós de cluster e outros equipamentos de cluster, tais como
comutadores de energia de rede e comutadores de canal de fibra óptica.
Um dispositivo de vedação para cada nó do aglomerado. Este exemplo usa duas portas do
interruptor de energia APC com um nome de host zapc.example.com.
4.1. INSTALAÇÃO DE SOFTWARE DE CLUSTER

O seguinte procedimento instala o software de cluster e configura seu sistema para a criação de
clusters.
1. Em cada nó do cluster, instale os pacotes de software Red Hat High Availability Add-On junto
com todos os agentes de vedação disponíveis no canal High Availability.
Alternativamente, você pode instalar os pacotes de software Red Hat High Availability Add-On
junto com apenas o agente de vedação que você necessita com o seguinte comando.
# yum install pcs pacemaker fence-agents-model
O comando a seguir exibe uma lista dos agentes de vedação disponíveis.
# rpm -q -a | grep fence

fence-agents-rhevm-4.0.2-3.el7.x86_64
fence-agents-ilo-mp-4.0.2-3.el7.x86_64
fence-agents-ipmilan-4.0.2-3.el7.x86_64
...

ATENÇÃO
Após instalar os pacotes Red Hat High Availability Add-On, você deve
assegurar-se de que suas preferências de atualização de software estejam
definidas para que nada seja instalado automaticamente. A instalação em
um cluster em execução pode causar comportamentos inesperados. Para
mais informações, consulte Práticas recomendadas para a aplicação de
atualizações de software em um cluster de armazenamento RHEL de alta
disponibilidade ou resiliente.
28
CAPÍTULO 4. CRIANDO UM CLUSTER DE ALTA DISPONIBILIDADE RED HAT COM PACEMAKER
2. Se você estiver executando o daemon firewalld, execute os seguintes comandos para habilitar
as portas que são exigidas pelo Add-On de Alta Disponibilidade da Red Hat.
NOTA
Você pode determinar se o daemon firewalld está instalado em seu sistema com
o comando rpm -q firewalld. Se ele estiver instalado, você pode determinar se
ele está rodando com o comando firewall-cmd --state.

# firewall-cmd --add-service=high-availability
NOTA
A configuração ideal de firewall para componentes de cluster depende do

ambiente local, onde talvez seja necessário levar em conta considerações como,
por exemplo, se os nós têm múltiplas interfaces de rede ou se há firewalls fora do
host. O exemplo aqui, que abre as portas que são geralmente exigidas por um
cluster Pacemaker, deve ser modificado para se adequar às condições locais. A
habilitação de portas para o Add-On de Alta Disponibilidade mostra as portas
para habilitar para o Add-On de Alta Disponibilidade da Red Hat e fornece uma
explicação para o que cada porta é usada.
3. Para usar pcs para configurar o cluster e se comunicar entre os nós, você deve definir uma
senha em cada nó para o ID do usuário hacluster, que é a conta de administração pcs. É
recomendado que a senha para o usuário hacluster seja a mesma em cada nó.
# passwd hacluster
Changing password for user hacluster.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
4. Antes que o cluster possa ser configurado, o daemon pcsd deve ser iniciado e habilitado para
iniciar na inicialização em cada nó. Este daemon trabalha com o comando pcs para gerenciar a
configuração através dos nós do cluster.
Em cada nó do cluster, execute os seguintes comandos para iniciar o serviço pcsd e para
habilitar pcsd no início do sistema.

4.2. INSTALAÇÃO DO PACOTE PCP-ZEROCONF (RECOMENDADO)

Ao configurar seu cluster, é recomendável instalar o pacote pcp-zeroconf para a ferramenta
Performance Co-Pilot (PCP). O PCP é a ferramenta de monitoramento de recursos recomendada pela
Red Hat para os sistemas RHEL. A instalação do pacote pcp-zeroconf permite que você tenha o PCP
rodando e coletando dados de monitoramento de desempenho para o benefício de investigações sobre
esgrima, falhas de recursos e outros eventos que perturbam o cluster.
NOTA
29
NOTA
As implantações de clusters onde o PCP é ativado precisarão de espaço suficiente

disponível para os dados capturados do PCP no sistema de arquivos que contém
/var/log/pcp/. O uso típico de espaço pelo PCP varia entre as implantações, mas 10Gb é
normalmente suficiente quando se utiliza as configurações padrão pcp-zeroconf, e
alguns ambientes podem requerer menos. O monitoramento do uso neste diretório
durante um período de 14 dias de atividade típica pode fornecer uma expectativa de uso
mais precisa.
Para instalar o pacote pcp-zeroconf, execute o seguinte comando.
# yum install pcp-zeroconf
Este pacote permite pmcd e estabelece a captura de dados em um intervalo de 10 segundos.
Para informações sobre a revisão de dados PCP, veja Por que um nó de cluster RHEL de alta
disponibilidade foi reinicializado - e como posso evitar que isso aconteça novamente? no Portal do
Cliente da Red Hat.
4.3. CRIAÇÃO DE UM CLUSTER DE ALTA DISPONIBILIDADE

Este procedimento cria um cluster de Red Hat High Availability Add-On que consiste nos nós
z1.example.com e z2.example.com.
1. Autentique o usuário pcs hacluster para cada nó do cluster no nó a partir do qual você estará
rodando pcs.
O seguinte comando autentica o usuário hacluster em z1.example.com para os dois nós em
um cluster de dois nós que consistirá de z1.example.com e z2.example.com.
[root@z1 ~]# pcs host auth z1.example.com z2.example.com

Username: hacluster
Password:
z1.example.com: Authorized
2. Execute o seguinte comando de z1.example.com para criar o cluster de dois nós my_cluster
que consiste de nós z1.example.com e z2.example.com. Isto propagará os arquivos de
configuração do cluster para ambos os nós do cluster. Este comando inclui a opção --start, que
iniciará os serviços de cluster em ambos os nós do cluster.
[root@z1 ~]# pcs cluster setup my_cluster --start z1.example.com z2.example.com
3. Permitir que os serviços de cluster funcionem em cada nó do cluster quando o nó for

inicializado.
NOTA
Para seu ambiente particular, você pode optar por deixar os serviços de cluster
desativados, pulando esta etapa. Isto lhe permite assegurar que se um nó cair,
quaisquer problemas com seu agrupamento ou seus recursos serão resolvidos
antes que o nó se reintegre ao agrupamento. Se você deixar os serviços do
cluster desativados, você precisará iniciar manualmente os serviços quando
reiniciar um nó executando o comando pcs cluster start naquele nó.
30
[root@z1 ~]# pcs cluster enable --all
Você pode exibir o status atual do cluster com o comando pcs cluster status. Como pode haver um
pequeno atraso antes que o cluster esteja pronto e funcionando quando você iniciar os serviços de
cluster com a opção --start do comando pcs cluster setup, você deve assegurar que o cluster esteja
pronto e funcionando antes de executar qualquer ação subseqüente sobre o cluster e sua configuração.
[root@z1 ~]# pcs cluster status

Cluster Status:
Stack: corosync
2 Nodes configured
0 Resources configured
...
4.4. CRIAÇÃO DE UM CLUSTER DE ALTA DISPONIBILIDADE COM

MÚLTIPLOS LINKS
Você pode usar o comando pcs cluster setup para criar um cluster Red Hat High Availability com
múltiplos links, especificando todos os links para cada nó.
O formato do comando para criar um cluster de dois nós com dois links é o seguinte.
pcs cluster setup cluster_name node1_name addr=node1_link0_address addr=node1_link1_address

node2_name addr=node2_link0_address addr=node2_link1_address
Ao criar um cluster com múltiplos links, você deve levar em conta o seguinte.
A ordem do addr=address parâmetros é importante. O primeiro endereço especificado após o

nome de um nó é para link0, o segundo para link1, e assim por diante.
É possível especificar até oito ligações usando o protocolo de transporte de nós, que é o
protocolo de transporte padrão.
Todos os nós devem ter o mesmo número de parâmetros addr=.
A partir do RHEL 8.1, é possível adicionar, remover e alterar links em um cluster existente
usando os comandos pcs cluster link add, o pcs cluster link remove, o pcs cluster link
delete e o pcs cluster link update.
Assim como nos clusters de link único, não misture endereços IPv4 e IPv6 em um link, embora
você possa ter um link rodando IPv4 e o outro rodando IPv6.
Como nos clusters de link único, você pode especificar endereços como endereços IP ou como
nomes desde que os nomes resolvam para endereços IPv4 ou IPv6 para os quais endereços
IPv4 e IPv6 não estejam misturados em um link.
O exemplo seguinte cria um cluster de dois nós chamado my_twolink_cluster com dois nós, rh80-
node1 e rh80-node2. rh80-node1 tem duas interfaces, endereço IP 192.168.122.201 como link0 e
192.168.123.201 como link1. rh80-node2 tem duas interfaces, endereço IP 192.168.122.202 como link0 e
192.168.123.202 como link1.
31
# pcs cluster setup my_twolink_cluster rh80-node1 addr=192.168.122.201

addr=192.168.123.201 rh80-node2 addr=192.168.122.202 addr=192.168.123.202
Para informações sobre como adicionar nós a um cluster existente com múltiplos links, consulte
Adicionando um nó a um cluster com múltiplos links .
Para informações sobre como alterar os links em um cluster existente com múltiplos links, veja Adicionar
e modificar links em um cluster existente.
4.5. CONFIGURAÇÃO DE CERCAS

Você deve configurar um dispositivo de vedação para cada nó do aglomerado. Para informações sobre
os comandos e opções de configuração da cerca, veja Configurando a cerca em um cluster de Alta
Disponibilidade da Red Hat.
Para informações gerais sobre cercas e sua importância em um aglomerado de Red Hat High
Availability, veja Fencing in a Red Hat High Availability Cluster .
NOTA
Ao configurar um dispositivo de vedação, deve ser dada atenção se esse dispositivo

compartilha energia com quaisquer nós ou dispositivos do cluster. Se um nó e seu
dispositivo de cerca compartilham energia, então o aglomerado pode estar em risco de
não poder cercar esse nó se a energia para ele e seu dispositivo de cerca forem perdidos.
Tal aglomerado deve ter fontes de alimentação redundantes para os dispositivos e nós
do cercado, ou dispositivos de cercado redundantes que não compartilham a energia.
Métodos alternativos de vedação como SBD ou vedação de armazenamento também
podem trazer redundância no caso de perdas isoladas de energia.
Este exemplo usa o interruptor de energia APC com um nome de host zapc.example.com para cercar
os nós, e usa o agente de cercas fence_apc_snmp. Como ambos os nós serão vedados pelo mesmo
agente de vedação, você pode configurar ambos os dispositivos de vedação como um único recurso,
usando a opção pcmk_host_map.
Você cria um dispositivo de esgrima configurando o dispositivo como um recurso stonith com o
comando pcs stonith create. O seguinte comando configura um recurso stonith chamado myapc que
usa o agente de esgrima fence_apc_snmp para os nós z1.example.com e z2.example.com. A opção
pcmk_host_map mapeia z1.example.com para a porta 1, e z2.example.com para a porta 2. O valor de
login e a senha para o dispositivo APC são ambos apc. Por padrão, este dispositivo usará um intervalo
de monitor de sessenta segundos para cada nó.
Observe que você pode usar um endereço IP ao especificar o nome do host para os nós.
[root@z1 ~]# pcs stonith create myapc fence_apc_snmp \

ipaddr="zapc.example.com" \
pcmk_host_map="z1.example.com:1;z2.example.com:2" \
login="apc" passwd="apc"
O seguinte comando exibe os parâmetros de um dispositivo STONITH existente.
[root@rh7-1 ~]# pcs stonith config myapc

Resource: myapc (class=stonith type=fence_apc_snmp)
Attributes: ipaddr=zapc.example.com pcmk_host_map=z1.example.com:1;z2.example.com:2
32
login=apc passwd=apc
Operations: monitor interval=60s (myapc-monitor-interval-60s)
Após configurar seu dispositivo de cerca, você deve testar o dispositivo. Para informações sobre como
testar um dispositivo de cerca, veja Testar um dispositivo de cerca .
NOTA
Não teste seu dispositivo de cercas desativando a interface de rede, pois isso não testará
corretamente as cercas.
NOTA
Uma vez configurada a vedação e iniciado um cluster, um reinício da rede acionará a

vedação para o nó que reinicia a rede, mesmo quando o tempo limite não for
ultrapassado. Por este motivo, não reinicie o serviço de rede enquanto o serviço de
cluster estiver em funcionamento, pois ele acionará uma vedação não intencional no nó.
4.6. APOIO E RESTAURAÇÃO DE UMA CONFIGURAÇÃO DE CLUSTER

Você pode fazer o backup da configuração do cluster em uma tarball com o seguinte comando. Se você
não especificar um nome de arquivo, será usada a saída padrão.
pcs config backup filename
NOTA
O comando pcs config backup faz backup apenas da própria configuração do cluster
conforme configurado no CIB; a configuração dos daemons de recursos está fora do
escopo deste comando. Por exemplo, se você tiver configurado um recurso Apache no
cluster, as configurações do recurso (que estão na CIB) serão copiadas, enquanto as
configurações do daemon Apache (como definido em`/etc/httpd`) e os arquivos que
ele serve não serão copiados. Da mesma forma, se houver um recurso de banco de dados
configurado no cluster, o banco de dados em si não será feito o backup, enquanto a
configuração do recurso de banco de dados (CIB) será feita.
Use o seguinte comando para restaurar os arquivos de configuração de cluster em todos os nós a partir
do backup. Se você não especificar um nome de arquivo, será usada a entrada padrão. Especificar a
opção --local restaura somente os arquivos no nó atual.
pcs config restore [--local] [filename]
4.7. HABILITAÇÃO DE PORTAS PARA O ADD-ON DE ALTA

DISPONIBILIDADE
A configuração ideal de firewall para componentes de cluster depende do ambiente local, onde talvez
seja necessário levar em conta considerações como, por exemplo, se os nós têm múltiplas interfaces de
rede ou se há firewalls fora do host.
Se você estiver executando o daemon firewalld, execute os seguintes comandos para habilitar as
portas que são exigidas pelo Add-On de Alta Disponibilidade da Red Hat.
33

Talvez seja necessário modificar quais portos estão abertos para atender às condições locais.
NOTA
Você pode determinar se o daemon firewalld está instalado em seu sistema com o
comando rpm -q firewalld. Se o daemon firewalld estiver instalado, você pode
determinar se ele está rodando com o comando firewall-cmd --state.
Tabela 4.1, “Portos que possibilitam um suplemento de alta disponibilidade” mostra os portos a serem
habilitados para o Red Hat High Availability Add-On e fornece uma explicação para o que o porto é
usado.
Tabela 4.1. Portos que possibilitam um suplemento de alta disponibilidade
Porto Quando necessário
TCP 2224 Padrão pcsd porta necessária em todos os nós

(necessária pela interface Web do pcsd e necessária
para comunicação node-to-node). Você pode
configurar a porta pcsd por meio do parâmetro
PCSD_PORT no arquivo /etc/sysconfig/pcsd.
É crucial abrir a porta 2224 de tal forma que pcs de

qualquer nó possa falar com todos os nós do
agrupamento, inclusive consigo mesmo. Ao usar o
gerente de bilhetes de estande de cluster ou um
dispositivo de quorum, você deve abrir a porta 2224
em todos os hosts relacionados, tais como árbitros
de estande ou o host do dispositivo de quorum.
TCP 3121 Necessário em todos os nós se o agrupamento tiver

algum nó de Pacemaker Remote
O daemon do Pacemaker pacemaker-based nos

nós de agrupamento completo entrará em contato
com o daemon pacemaker_remoted nos nós
remotos do Pacemaker na porta 3121. Se uma
interface separada for usada para comunicação em
cluster, a porta só precisa estar aberta nessa
interface. No mínimo, a porta deve ser aberta nos nós
Remotos do Pacemaker para nós de cluster
completo. Como os usuários podem converter um
host entre um nó completo e um nó remoto, ou
executar um nó remoto dentro de um container
usando a rede do host, pode ser útil abrir a porta para
todos os nós. Não é necessário abrir a porta para
nenhum outro host além dos nós.
34
Porto Quando necessário
TCP 5403 Necessário no quorum quando se utiliza um

dispositivo de quorum com corosync-qnetd. O
valor padrão pode ser alterado com a opção -p do
comando corosync-qnetd.
UDP 5404-5412 Necessário nos nós corosync para facilitar a

comunicação entre os nós. É crucial abrir as portas
5404-5412 de tal forma que corosync de qualquer
nó possa falar com todos os nós do cluster, inclusive
consigo mesmo.
TCP 21064 Necessário em todos os nós se o cluster contiver

algum recurso que requeira DLM (como GFS2 ).
TCP 9929, UDP 9929 É necessário estar aberto em todos os nós de cluster
e nós árbitros de estande para conexões de qualquer
um desses mesmos nós quando o gerente de
bilhetes do estande é usado para estabelecer um
cluster com vários locais.
35
CAPÍTULO 5. CONFIGURAÇÃO DE UM SERVIDOR HTTP

APACHE ATIVO/PASSIVO EM UM CLUSTER RED HAT HIGH
AVAILABILITY
O seguinte procedimento configura um servidor Apache HTTP ativo/passivo em um cluster de dois nós
Red Hat Enterprise Linux High Availability Add-On usando pcs para configurar recursos de cluster.
Neste caso de uso, os clientes acessam o servidor Apache HTTP através de um endereço IP flutuante. O
servidor web roda em um dos dois nós do cluster. Se o nó no qual o servidor web está rodando ficar
inoperante, o servidor web inicia novamente no segundo nó do cluster com interrupção mínima do
serviço.
Figura 5.1, “Apache em um grupo de dois nós de alta disponibilidade de chapéu vermelho” mostra uma
visão geral de alto nível do cluster no qual O cluster é um cluster de dois nós Red Hat High Availability
configurado com um switch de energia de rede e com armazenamento compartilhado. Os nós do cluster
são conectados a uma rede pública, para acesso do cliente ao servidor HTTP Apache através de um IP
virtual. O servidor Apache roda no Nó 1 ou no Nó 2, cada um dos quais tem acesso ao armazenamento no
qual os dados do Apache são mantidos. Nesta ilustração, o servidor web está rodando no Nó 1, enquanto
o Nó 2 está disponível para rodar o servidor caso o Nó 1 se torne inoperante.
Figura 5.1. Apache em um grupo de dois nós de alta disponibilidade de chapéu vermelho
Este caso de uso requer que seu sistema inclua os seguintes componentes:
Um cluster de dois nós Red Hat High Availability com vedação de energia configurada para cada
nó. Recomendamos, mas não exigimos uma rede privada. Este procedimento utiliza o exemplo
de cluster fornecido em Criar um cluster Red Hat High-Availability com Pacemaker .
Um endereço IP virtual público, necessário para o Apache.
Armazenamento compartilhado para os nós do cluster, utilizando iSCSI, Fibre Channel ou outro
dispositivo de bloco de rede compartilhado.
O cluster é configurado com um grupo de recursos Apache, que contém os componentes do cluster que
o servidor web requer: um recurso LVM, um recurso de sistema de arquivos, um recurso de endereço IP e
um recurso de servidor web. Este grupo de recursos pode falhar de um nó do cluster para o outro,
36
LO 5. CONFIGURAÇÃO DE UM SERVIDOR HTTP APACHE ATIVO/PASSIVO EM UM CLUSTER RED HAT HIGH AVAILABILITY
permitindo que qualquer um dos nós execute o servidor web. Antes de criar o grupo de recursos para
este cluster, você estará executando os seguintes procedimentos:
1. Configurar um sistema de arquivo ext4 no volume lógico my_lv.
2. Configurar um servidor web.
Depois de executar estas etapas, você cria o grupo de recursos e os recursos que ele contém.
5.1. CONFIGURAÇÃO DE UM VOLUME LVM COM UM SISTEMA DE

ARQUIVO EXT4 EM UM CLUSTER PACEMAKER
Este caso de uso requer a criação de um volume lógico LVM no armazenamento que é compartilhado
entre os nós do cluster.
NOTA
Os volumes LVM e as partições e dispositivos correspondentes usados pelos nós de

cluster devem ser conectados somente aos nós de cluster.
O procedimento seguinte cria um volume lógico LVM e depois cria um sistema de arquivo ext4 nesse
volume para uso em um cluster de Pacemaker. Neste exemplo, a partição compartilhada /dev/sdb1 é
usada para armazenar o volume físico LVM a partir do qual o volume lógico LVM será criado.
1. Em ambos os nós do cluster, executar os seguintes passos para definir o valor para o ID do
sistema LVM para o valor do identificador uname para o sistema. O ID do sistema LVM será
usado para garantir que somente o cluster seja capaz de ativar o grupo de volume.
a. Defina a opção de configuração system_id_source no arquivo de configuração

/etc/lvm/lvm.conf para uname.
# Configuration option global/system_id_source.

system_id_source = "uname"
b. Verificar se o ID do sistema LVM no nó corresponde ao uname para o nó.
# lvm systemid
system ID: z1.example.com
# uname -n
z1.example.com
2. Criar o volume LVM e criar um sistema de arquivo ext4 sobre esse volume. Uma vez que a
partição /dev/sdb1 é o armazenamento compartilhado, esta parte do procedimento é realizada
em apenas um nó.
a. Criar um volume físico LVM na partição /dev/sdb1.
# pvcreate /dev/sdb1
Physical volume "/dev/sdb1" successfully created
b. Criar o grupo de volume my_vg que consiste no volume físico /dev/sdb1.
# vgcreate my_vg /dev/sdb1

Volume group "my_vg" successfully created
37
c. Verifique se o novo grupo de volume tem a identificação do sistema do nó no qual você está
rodando e a partir do qual você criou o grupo de volume.
# vgs -o+systemid
VG #PV #LV #SN Attr VSize VFree System ID
my_vg 1 0 0 wz--n- <1.82t <1.82t z1.example.com
d. Criar um volume lógico utilizando o grupo de volume my_vg.
# lvcreate -L450 -n my_lv my_vg

Rounding up size to full physical extent 452.00 MiB
Logical volume "my_lv" created
Você pode usar o comando lvs para exibir o volume lógico.
# lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
my_lv my_vg -wi-a---- 452.00m
...
e. Criar um sistema de arquivo ext4 no volume lógico my_lv.
# mkfs.ext4 /dev/my_vg/my_lv
mke2fs 1.44.3 (10-July-2018)
Creating filesystem with 462848 1k blocks and 115824 inodes
...
5.2. CONFIGURAÇÃO DE UM SERVIDOR HTTP APACHE

O seguinte procedimento configura um Servidor HTTP Apache.
1. Garantir que o Servidor HTTP Apache esteja instalado em cada nó do cluster. Você também
precisa da ferramenta wget instalada no cluster para poder verificar o status do Servidor HTTP
Apache.
Em cada nó, executar o seguinte comando.
Se você estiver rodando o daemon firewalld, em cada nó do cluster habilite as portas que são
exigidas pelo Add-On de Alta Disponibilidade da Red Hat.

2. Para que o agente de recursos Apache obtenha o status do Servidor HTTP Apache, certifique-
se de que o seguinte texto esteja presente no arquivo /etc/httpd/conf/httpd.conf em cada nó
do cluster, e certifique-se de que ele não tenha sido comentado. Se este texto ainda não
estiver presente, adicione o texto ao final do arquivo.
Require local
38
</Location>
3. Quando você usa o agente de recursos apache para gerenciar o Apache, ele não usa systemd.
Por causa disso, você deve editar o script logrotate fornecido com o Apache para que ele não
utilize systemctl para recarregar o Apache.
Remova a seguinte linha no arquivo /etc/logrotate.d/httpd em cada nó do cluster.
/bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true
Substitua a linha que você removeu pelas três linhas a seguir.
/usr/bin/test -f /run/httpd.pid >/dev/null 2>/dev/null &&

/usr/bin/ps -q $(/usr/bin/cat /run/httpd.pid) >/dev/null 2>/dev/null &&
/usr/sbin/httpd -f /etc/httpd/conf/httpd.conf \
-c "PidFile /run/httpd.pid" -k graceful > /dev/null 2>/dev/null || true
4. Criar uma página web para que o Apache possa servir. Em um nó do cluster, monte o sistema de
arquivo que você criou em Configurando um volume LVM com um sistema de arquivo ext4 , crie
o arquivo index.html nesse sistema de arquivo, e depois desmonte o sistema de arquivo.
# mount /dev/my_vg/my_lv /var/www/

# mkdir /var/www/html
# mkdir /var/www/cgi-bin
# mkdir /var/www/error
# restorecon -R /var/www
<html>
<body>Hello</body>
</html>
END
# umount /var/www
5.3. CRIAÇÃO DOS RECURSOS E GRUPOS DE RECURSOS

Este caso de uso requer que você crie quatro recursos de cluster. Para garantir que todos esses recursos
funcionem no mesmo nó, eles são configurados como parte do grupo de recursos apachegroup. Os
recursos a serem criados são os seguintes, listados na ordem em que serão iniciados.
1. Um recurso LVM chamado my_lvm que usa o grupo de volume LVM que você criou em
Configurar um volume LVM com um sistema de arquivo ext4 .
2. Um recurso Filesystem chamado my_fs, que usa o dispositivo de sistema de arquivo

/dev/my_vg/my_lv que você criou em Configurando um volume LVM com um sistema de
arquivo ext4.
3. Um recurso IPaddr2, que é um endereço IP flutuante para o grupo de recursos apachegroup. O

endereço IP não deve ser um endereço já associado a um nó físico. Se o dispositivo NIC do
recurso IPaddr2 não for especificado, o IP flutuante deve residir na mesma rede que um dos
endereços IP do nó estaticamente atribuído, caso contrário o dispositivo NIC para atribuir o
endereço IP flutuante não poderá ser detectado corretamente.
4. Um recurso apache chamado Website que usa o arquivo index.html e a configuração do

Apache que você definiu em Configurando um servidor Apache HTTP .
O seguinte procedimento cria o grupo de recursos apachegroup e os recursos que o grupo contém. Os
39
O seguinte procedimento cria o grupo de recursos apachegroup e os recursos que o grupo contém. Os
recursos começarão na ordem em que são adicionados ao grupo, e pararão na ordem inversa em que
são adicionados ao grupo. Execute este procedimento a partir de um único nó do grupo.
1. O seguinte comando cria o recurso LVM-activate my_lvm . Como o grupo de recursos

apachegroup ainda não existe, este comando cria o grupo de recursos.
NOTA
Não configure mais de um recurso LVM-activate que utiliza o mesmo grupo de

volume LVM em uma configuração HA ativa/passiva, pois isso poderia causar
corrupção de dados. Além disso, não configure um recurso LVM-activate como
um recurso clone em uma configuração de HA ativa/passiva.
[root@z1 ~]# pcs resource create my_lvm ocf:heartbeat:LVM-activate vgname=my_vg

vg_access_mode=system_id --group apachegroup
Quando você cria um recurso, o recurso é iniciado automaticamente. Você pode usar o seguinte
comando para confirmar que o recurso foi criado e foi iniciado.
# pcs resource status

my_lvm (ocf::heartbeat:LVM-activate): Started
Você pode parar e iniciar manualmente um recurso individual com os comandos pcs resource
disable e pcs resource enable.
2. Os seguintes comandos criam os recursos restantes para a configuração, adicionando-os ao

grupo de recursos existentes apachegroup.
[root@z1 ~]# pcs resource create my_fs Filesystem \

device="/dev/my_vg/my_lv" directory="/var/www" fstype="ext4" \
--group apachegroup
[root@z1 ~]# pcs resource create VirtualIP IPaddr2 ip=198.51.100.3 \

cidr_netmask=24 --group apachegroup
[root@z1 ~]# pcs resource create Website apache \

configfile="/etc/httpd/conf/httpd.conf" \
statusurl="http://127.0.0.1/server-status" --group apachegroup
3. Depois de criar os recursos e o grupo de recursos que os contém, você pode verificar o status
do agrupamento. Observe que todos os quatro recursos estão funcionando no mesmo nó.
[root@z1 ~]# pcs status

Last updated: Wed Jul 31 16:38:51 2013
Last change: Wed Jul 31 16:42:14 2013 via crm_attribute on z1.example.com
Stack: corosync
Current DC: z2.example.com (2) - partition with quorum
Version: 1.1.10-5.el7-9abe687
2 Nodes configured
40

myapc (stonith:fence_apc_snmp): Started z1.example.com
my_lvm (ocf::heartbeat:LVM): Started z1.example.com
my_fs (ocf::heartbeat:Filesystem): Started z1.example.com
VirtualIP (ocf::heartbeat:IPaddr2): Started z1.example.com
Website (ocf::heartbeat:apache): Started z1.example.com
Observe que se você não tiver configurado um dispositivo de esgrima para seu cluster, por
padrão os recursos não começam.
4. Uma vez que o cluster esteja instalado e funcionando, você pode apontar um navegador para o
endereço IP que você definiu como o recurso IPaddr2 para visualizar a exibição da amostra, que
consiste na simples palavra "Olá".
Olá
Se você descobrir que os recursos que você configurou não estão funcionando, você pode
executar o pcs resource debug-start resource comando para testar a configuração do
recurso.
5.4. TESTE DA CONFIGURAÇÃO DOS RECURSOS

Na exibição do status do cluster mostrada em Criando os recursos e grupos de recursos , todos os
recursos estão rodando no nó z1.example.com. Você pode testar se o grupo de recursos falha no nó
z2.example.com usando o seguinte procedimento para colocar o primeiro nó no modo standby, após o
qual o nó não será mais capaz de hospedar recursos.
1. O seguinte comando coloca o nó z1.example.com no modo standby.
[root@z1 ~]# pcs node standby z1.example.com
2. Após colocar o nó z1 no modo standby, verifique o status do agrupamento. Observe que agora
todos os recursos devem estar funcionando em z2.

Last updated: Wed Jul 31 17:16:17 2013
Last change: Wed Jul 31 17:18:34 2013 via crm_attribute on z1.example.com
Stack: corosync
Version: 1.1.10-5.el7-9abe687
2 Nodes configured
Node z1.example.com (1): standby


41
my_fs (ocf::heartbeat:Filesystem): Started z2.example.com

VirtualIP (ocf::heartbeat:IPaddr2): Started z2.example.com
Website (ocf::heartbeat:apache): Started z2.example.com
O site no endereço IP definido ainda deve ser exibido, sem interrupção.
3. Para remover z1 do modo standby, digite o seguinte comando.
[root@z1 ~]# pcs node unstandby z1.example.com
NOTA
A remoção de um nó do modo standby não faz com que os recursos, por si só,
falhem de volta a esse nó. Isto dependerá do valor resource-stickiness para os
recursos. Para informações sobre o meta atributo resource-stickiness, consulte
Configurando um recurso para preferir seu nó atual .
42
CAPÍTULO 6. CONFIGURAÇÃO DE UM SERVIDOR NFS ATIVO/PASSIVO EM UM CLUSTER RED HAT HIGH AVAILABILITY
CAPÍTULO 6. CONFIGURAÇÃO DE UM SERVIDOR NFS

ATIVO/PASSIVO EM UM CLUSTER RED HAT HIGH
AVAILABILITY
O procedimento a seguir configura um servidor NFS ativo/passivo altamente disponível em um cluster
de dois nós Red Hat Enterprise Linux High Availability Add-On usando armazenamento compartilhado.
O procedimento usa pcs para configurar os recursos de cluster do Pacemaker. Neste caso de uso, os
clientes acessam o sistema de arquivo NFS através de um endereço IP flutuante. O servidor NFS roda
em um dos dois nós do cluster. Se o nó no qual o servidor NFS está rodando se torna inoperante, o
servidor NFS inicia novamente no segundo nó do cluster com interrupção mínima do serviço.
6.1. PRÉ-REQUISITOS
Este caso de uso requer que seu sistema inclua os seguintes componentes:
Um cluster de dois nós Red Hat High Availability com vedação de energia configurada para cada
nó. Recomendamos, mas não exigimos uma rede privada. Este procedimento utiliza o exemplo
de cluster fornecido em Criar um cluster Red Hat High-Availability com Pacemaker .
Um endereço IP virtual público, necessário para o servidor NFS.
Armazenamento compartilhado para os nós do cluster, utilizando iSCSI, Fibre Channel ou outro
dispositivo de bloco de rede compartilhado.
6.2. VISÃO GERAL DOS PROCEDIMENTOS

A configuração de um servidor NFS ativo/passivo altamente disponível em um cluster Red Hat
Enterprise Linux High Availability de dois nós já existente requer que você execute os seguintes passos:
1. Configurar um sistema de arquivo ext4 no volume lógico do LVM my_lv sobre o

armazenamento compartilhado para os nós no cluster.
2. Configurar um compartilhamento NFS sobre o armazenamento compartilhado no volume lógico

LVM.
3. Criar os recursos do cluster.
4. Teste o servidor NFS que você configurou.
6.3. CONFIGURAÇÃO DE UM VOLUME LVM COM UM SISTEMA DE

ARQUIVO EXT4 EM UM CLUSTER PACEMAKER
Este caso de uso requer a criação de um volume lógico LVM no armazenamento que é compartilhado
entre os nós do cluster.
NOTA
Os volumes LVM e as partições e dispositivos correspondentes usados pelos nós de

cluster devem ser conectados somente aos nós de cluster.
43
volume para uso em um cluster de Pacemaker. Neste exemplo, a partição compartilhada /dev/sdb1 é
usada para armazenar o volume físico LVM a partir do qual o volume lógico LVM será criado.
1. Em ambos os nós do cluster, executar os seguintes passos para definir o valor para o ID do
sistema LVM para o valor do identificador uname para o sistema. O ID do sistema LVM será
usado para garantir que somente o cluster seja capaz de ativar o grupo de volume.
a. Defina a opção de configuração system_id_source no arquivo de configuração

/etc/lvm/lvm.conf para uname.
# Configuration option global/system_id_source.

system_id_source = "uname"
b. Verificar se o ID do sistema LVM no nó corresponde ao uname para o nó.
# lvm systemid
system ID: z1.example.com
# uname -n
z1.example.com
2. Criar o volume LVM e criar um sistema de arquivo ext4 sobre esse volume. Uma vez que a
partição /dev/sdb1 é o armazenamento compartilhado, esta parte do procedimento é realizada
em apenas um nó.
a. Criar um volume físico LVM na partição /dev/sdb1.
# pvcreate /dev/sdb1
Physical volume "/dev/sdb1" successfully created
b. Criar o grupo de volume my_vg que consiste no volume físico /dev/sdb1.
# vgcreate my_vg /dev/sdb1

Volume group "my_vg" successfully created
c. Verifique se o novo grupo de volume tem a identificação do sistema do nó no qual você está
rodando e a partir do qual você criou o grupo de volume.
# vgs -o+systemid
VG #PV #LV #SN Attr VSize VFree System ID
my_vg 1 0 0 wz--n- <1.82t <1.82t z1.example.com
d. Criar um volume lógico utilizando o grupo de volume my_vg.
# lvcreate -L450 -n my_lv my_vg

Rounding up size to full physical extent 452.00 MiB
Logical volume "my_lv" created
Você pode usar o comando lvs para exibir o volume lógico.
# lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
my_lv my_vg -wi-a---- 452.00m
...
44
e. Criar um sistema de arquivo ext4 no volume lógico my_lv.
# mkfs.ext4 /dev/my_vg/my_lv
mke2fs 1.44.3 (10-July-2018)
Creating filesystem with 462848 1k blocks and 115824 inodes
...
6.4. CONFIGURAÇÃO DE UM COMPARTILHAMENTO NFS

O procedimento a seguir configura o compartilhamento do NFS para o failover do serviço NFS.
1. Em ambos os nós do cluster, criar o diretório /nfsshare.
# mkdir /nfsshare
2. Em um nó do agrupamento, realizar o seguinte procedimento.
a. Monte o sistema de arquivo ext4 que você criou em Configurando um volume LVM com um
sistema de arquivo ext4 no diretório /nfsshare.
[root@z1 ~]# mount /dev/my_vg/my_lv /nfsshare
b. Criar uma árvore de diretório exports no diretório /nfsshare.
[root@z1 ~]# mkdir -p /nfsshare/exports

[root@z1 ~]# mkdir -p /nfsshare/exports/export1
[root@z1 ~]# mkdir -p /nfsshare/exports/export2
c. Coloque os arquivos no diretório exports para que os clientes do NFS tenham acesso. Para
este exemplo, estamos criando arquivos de teste chamados clientdatafile1 e
clientdatafile2.
[root@z1 ~]# touch /nfsshare/exports/export1/clientdatafile1

[root@z1 ~]# touch /nfsshare/exports/export2/clientdatafile2
d. Desmontar o sistema de arquivo ext4 e desativar o grupo de volume LVM.
[root@z1 ~]# umount /dev/my_vg/my_lv

[root@z1 ~]# vgchange -an my_vg
6.5. CONFIGURAÇÃO DOS RECURSOS E GRUPO DE RECURSOS PARA

UM SERVIDOR NFS EM UM CLUSTER
Esta seção fornece o procedimento para configurar os recursos do cluster para este caso de uso.
NOTA
45
NOTA
Se você não tiver configurado um dispositivo de esgrima para seu cluster, por padrão os
recursos não começam.
Se você descobrir que os recursos que você configurou não estão funcionando, você
pode executar o pcs resource debug-start resource comando para testar a
configuração do recurso. Isto inicia o serviço fora do controle e do conhecimento do
cluster. No ponto em que os recursos configurados estão rodando novamente, executar
pcs resource cleanup resource para que o grupo tome conhecimento das atualizações.
O procedimento a seguir configura os recursos do sistema. Para garantir que todos estes recursos
funcionem no mesmo nó, eles são configurados como parte do grupo de recursos nfsgroup. Os
recursos começarão na ordem em que são adicionados ao grupo, e pararão na ordem inversa em que
são adicionados ao grupo. Execute este procedimento a partir de um único nó do grupo.
1. Criar o recurso LVM-activate chamado my_lvm. Como o grupo de recursos nfsgroup ainda
não existe, este comando cria o grupo de recursos.

ATENÇÃO
Não configure mais de um recurso LVM-activate que utiliza o mesmo grupo

de volume LVM em uma configuração HA ativa/passiva, pois isso corre o
risco de corrupção de dados. Além disso, não configure um recurso LVM-
activate como um recurso clone em uma configuração de HA ativa/passiva.
[root@z1 ~]# pcs resource create my_lvm ocf:heartbeat:LVM-activate vgname=my_vg

vg_access_mode=system_id --group nfsgroup
2. Verifique o status do agrupamento para verificar se o recurso está funcionando.
root@z1 ~]# pcs status

Last updated: Thu Jan 8 11:13:17 2015
Last change: Thu Jan 8 11:13:08 2015
Stack: corosync
Version: 1.1.12-a14efad
2 Nodes configured

Resource Group: nfsgroup
PCSD Status:
46
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
3. Configurar um recurso Filesystem para o cluster.

O seguinte comando configura um recurso ext4 Filesystem chamado nfsshare como parte do
grupo de recursos nfsgroup. Este sistema de arquivo usa o grupo de volume LVM e o sistema
de arquivo ext4 que você criou em Configuring an LVM volume with an ext4 file system e será
montado no diretório /nfsshare que você criou em Configuring an NFS share .
[root@z1 ~]# pcs resource create nfsshare Filesystem \

device=/dev/my_vg/my_lv directory=/nfsshare \
fstype=ext4 --group nfsgroup
Você pode especificar opções de montagem como parte da configuração do recurso para um
recurso Filesystem com o options=options parâmetro. Execute o comando pcs resource
describe Filesystem para opções de configuração completa.
4. Verifique se os recursos my_lvm e nfsshare estão funcionando.

...
nfsshare (ocf::heartbeat:Filesystem): Started z1.example.com
...
5. Criar o recurso nfsserver chamado nfs-daemon como parte do grupo de recursos nfsgroup.
NOTA
O recurso nfsserver permite especificar um parâmetro nfs_shared_infodir, que

é um diretório que os servidores NFS usam para armazenar informações de
estado relacionadas ao NFS.
Recomenda-se que este atributo seja definido em um subdiretório de um dos

recursos Filesystem que você criou nesta coleção de exportações. Isto garante
que os servidores NFS estejam armazenando suas informações de estado em um
dispositivo que ficará disponível para outro nó se este grupo de recursos precisar
se relocalizar. Neste exemplo;
/nfsshare é o diretório de armazéns compartilhados gerenciado pelo recurso

Filesystem
/nfsshare/exports/export1 e /nfsshare/exports/export2 são os diretórios

de exportação
/nfsshare/nfsinfo é o diretório de informações compartilhadas para o

recurso nfsserver
47
[root@z1 ~]# pcs resource create nfs-daemon nfsserver \

nfs_shared_infodir=/nfsshare/nfsinfo nfs_no_notify=true \
--group nfsgroup

...
6. Adicione os recursos de exportfs para exportar o diretório /nfsshare/exports. Estes recursos

fazem parte do grupo de recursos nfsgroup. Isto constrói um diretório virtual para clientes do
NFSv4. Os clientes do NFSv3 também podem acessar estas exportações.
NOTA
A opção fsid=0 é necessária somente se você quiser criar um diretório virtual

para clientes do NFSv4. Para mais informações, veja Como configurar a opção
fsid no arquivo /etc/exports de um servidor NFS?
[root@z1 ~]# pcs resource create nfs-root exportfs \

clientspec=192.168.122.0/255.255.255.0 \
options=rw,sync,no_root_squash \
directory=/nfsshare/exports \
fsid=0 --group nfsgroup
[root@z1 ~]# # pcs resource create nfs-export1 exportfs \

clientspec=192.168.122.0/255.255.255.0 \
options=rw,sync,no_root_squash directory=/nfsshare/exports/export1 \
[root@z1 ~]# # pcs resource create nfs-export2 exportfs \

clientspec=192.168.122.0/255.255.255.0 \
options=rw,sync,no_root_squash directory=/nfsshare/exports/export2 \
7. Adicione o recurso de endereço IP flutuante que os clientes NFS usarão para acessar o
compartilhamento NFS. Este recurso faz parte do grupo de recursos nfsgroup. Para este
exemplo de implantação, estamos usando 192.168.122.200 como o endereço IP flutuante.
[root@z1 ~]# pcs resource create nfs_ip IPaddr2 \

ip=192.168.122.200 cidr_netmask=24 --group nfsgroup
8. Adicione um recurso nfsnotify para enviar notificações de reinicialização do NFSv3 quando

toda a implantação do NFS tiver sido iniciada. Este recurso faz parte do grupo de recursos
nfsgroup.
NOTA
Para que a notificação NFS seja processada corretamente, o endereço IP

flutuante deve ter associado um nome de host que seja consistente tanto nos
servidores NFS quanto no cliente NFS.
[root@z1 ~]# pcs resource create nfs-notify nfsnotify \

source_host=192.168.122.200 --group nfsgroup
48
9. Depois de criar os recursos e as restrições de recursos, você pode verificar o status do

agrupamento. Observe que todos os recursos estão funcionando no mesmo nó.

...
nfs-daemon (ocf::heartbeat:nfsserver): Started z1.example.com
nfs-root (ocf::heartbeat:exportfs): Started z1.example.com
nfs-export1 (ocf::heartbeat:exportfs): Started z1.example.com
nfs_ip (ocf::heartbeat:IPaddr2): Started z1.example.com
nfs-notify (ocf::heartbeat:nfsnotify): Started z1.example.com
...
6.6. TESTE DA CONFIGURAÇÃO DO RECURSO NFS

Você pode validar a configuração de seu sistema com os seguintes procedimentos. Você deve ser capaz
de montar o sistema de arquivo exportado com NFSv3 ou NFSv4.
6.6.1. Teste da exportação do NFS

1. Em um nó fora do agrupamento, residindo na mesma rede que a instalação, verifique se o
compartilhamento NFS pode ser visto através da montagem do compartilhamento NFS. Para
este exemplo, estamos utilizando a rede 192.168.122.0/24.
# showmount -e 192.168.122.200
Export list for 192.168.122.200:
/nfsshare/exports/export1 192.168.122.0/255.255.255.0
/nfsshare/exports 192.168.122.0/255.255.255.0
/nfsshare/exports/export2 192.168.122.0/255.255.255.0
2. Para verificar se você pode montar o compartilhamento NFS com o NFSv4, monte o
compartilhamento NFS em um diretório no nó do cliente. Após a montagem, verifique se o
conteúdo dos diretórios de exportação está visível. Desmonte o compartilhamento após o
teste.
# mkdir nfsshare
# mount -o "vers=4" 192.168.122.200:export1 nfsshare
# ls nfsshare
clientdatafile1
# umount nfsshare
3. Verifique se você pode montar o compartilhamento do NFS com o NFSv3. Após a montagem,
verifique se o arquivo de teste clientdatafile1 está visível. Ao contrário do NFSv4, como o
NFSv3 não utiliza o sistema de arquivo virtual, você deve montar uma exportação específica.
Desmonte o compartilhamento após o teste.
# mkdir nfsshare
# mount -o "vers=3" 192.168.122.200:/nfsshare/exports/export2 nfsshare
# ls nfsshare
49
clientdatafile2
# umount nfsshare
6.6.2. Teste de failover

1. Em um nó fora do cluster, montar o compartilhamento NFS e verificar o acesso ao
clientdatafile1 que criamos em Configuring an NFS share
# mkdir nfsshare
# mount -o "vers=4" 192.168.122.200:export1 nfsshare
# ls nfsshare
clientdatafile1
2. A partir de um nó dentro do agrupamento, determinar qual nó do agrupamento está

funcionando nfsgroup. Neste exemplo, nfsgroup está rodando em z1.example.com.

...
...
3. A partir de um nó dentro do agrupamento, coloque o nó que está rodando nfsgroup em modo

de espera.
[root@z1 ~]# pcs node standby z1.example.com
4. Verifique se nfsgroup começa com sucesso no outro nó de agrupamento.

...
...
5. A partir do nó fora do agrupamento no qual você montou a parte NFS, verifique se este nó
externo ainda continua a ter acesso ao arquivo de teste dentro da montagem NFS.
50
# ls nfsshare
clientdatafile1
O serviço será perdido brevemente para o cliente durante o failover, mas o cliente deverá
recuperá-lo sem intervenção do usuário. Por padrão, os clientes que utilizam o NFSv4 podem
levar até 90 segundos para recuperar a montagem; estes 90 segundos representam o período
de graça do NFSv4 observado pelo servidor na inicialização. Os clientes do NFSv3 devem
recuperar o acesso à montagem em questão de poucos segundos.
6. De um nó dentro do agrupamento, remova o nó que estava inicialmente rodando nfsgroup do

modo de espera.
NOTA
A remoção de um nó do modo standby não faz com que os recursos, por si só,
falhem de volta a esse nó. Isto dependerá do valor resource-stickiness para os
recursos. Para informações sobre o meta atributo resource-stickiness, consulte
Configurando um recurso para preferir seu nó atual .
[root@z1 ~]# pcs node unstandby z1.example.com
51
CAPÍTULO 7. SISTEMAS DE ARQUIVO GFS2 EM UM CLUSTER

Esta seção fornece:
Um procedimento para criar um cluster de Pacemaker que inclui sistemas de arquivo GFS2
Um procedimento para migrar os volumes lógicos RHEL 7 que contêm sistemas de arquivo
GFS2 para um cluster RHEL 8
7.1. CONFIGURAÇÃO DE UM SISTEMA DE ARQUIVO GFS2 EM UM

CLUSTER
Este procedimento é um esboço dos passos necessários para a criação de um cluster Pacemaker que
inclui sistemas de arquivos GFS2. Este exemplo cria três sistemas de arquivos GFS2 em três volumes
lógicos.
Como pré-requisito para este procedimento, você deve instalar e iniciar o software de cluster em todos
os nós e criar um cluster básico de dois nós. Você também deve configurar a vedação para o cluster.
Para informações sobre como criar um cluster Pacemaker e configurar a vedação para o cluster, veja
Criar um cluster Red Hat High-Availability com Pacemaker .
Procedimento
1. Em ambos os nós do cluster, instalar os pacotes lvm2-lockd, gfs2-utils, e dlm. O pacote lvm2-
lockd faz parte do canal AppStream e os pacotes gfs2-utils e dlm fazem parte do canal de
Armazenamento Resiliente.
# yum install lvm2-lockd gfs2-utils dlm
2. Definir o parâmetro global Pacemaker no_quorum_policy para freeze.
NOTA
Por padrão, o valor de no-quorum-policy está definido para stop, indicando que
uma vez perdido o quorum, todos os recursos na partição restante serão
imediatamente parados. Normalmente este padrão é a opção mais segura e
ótima, mas ao contrário da maioria dos recursos, o GFS2 requer quorum para
funcionar. Quando o quorum é perdido, tanto as aplicações que utilizam os
suportes GFS2 como o próprio suporte GFS2 não podem ser parados
corretamente. Qualquer tentativa de parar estes recursos sem quorum falhará, o
que resultará no final em todo o aglomerado ser cercado toda vez que o quorum
for perdido.
Para resolver esta situação, defina no-quorum-policy para freeze quando o

GFS2 estiver em uso. Isto significa que quando o quorum for perdido, a partição
restante não fará nada até que o quorum seja recuperado.
# pcs property set no-quorum-policy=freeze
3. Configurar um recurso em dlm. Esta é uma dependência necessária para configurar um sistema
de arquivos GFS2 em um cluster. Este exemplo cria o recurso dlm como parte de um grupo de
recursos chamado locking.
52
[root@z1 ~]# pcs resource create dlm --group locking ocf:pacemaker:controld op

monitor interval=30s on-fail=fence
4. Clonar o grupo de recursos locking para que o grupo de recursos possa estar ativo nos dois nós
do cluster.
[root@z1 ~]# pcs resource clone locking interleave=true
5. Estabelecer um recurso lvmlockd como parte do grupo locking.
[root@z1 ~]# pcs resource create lvmlockd --group locking ocf:heartbeat:lvmlockd op

monitor interval=30s on-fail=fence
6. Verifique o status do agrupamento para garantir que o grupo de recursos locking tenha
começado em ambos os nós do agrupamento.
[root@z1 ~]# pcs status --full

[...]
Online: [ z1.example.com (1) z2.example.com (2) ]
smoke-apc (stonith:fence_apc): Started z1.example.com

Clone Set: locking-clone [locking]
Resource Group: locking:0
dlm (ocf::pacemaker:controld): Started z1.example.com
lvmlockd (ocf::heartbeat:lvmlockd): Started z1.example.com
Started: [ z1.example.com z2.example.com ]
7. Verifique se o daemon lvmlockd está rodando nos dois nós do cluster.
[root@z1 ~]# ps -ef | grep lvmlockd

root 12257 1 0 17:45 ? 00:00:00 lvmlockd -p /run/lvmlockd.pid -A 1 -g dlm
[root@z2 ~]# ps -ef | grep lvmlockd
root 12270 1 0 17:45 ? 00:00:00 lvmlockd -p /run/lvmlockd.pid -A 1 -g dlm
8. Em um nó do agrupamento, criar dois grupos de volume compartilhado. Um grupo de volume

conterá dois sistemas de arquivos GFS2 e o outro grupo de volume conterá um sistema de
arquivos GFS2.
O seguinte comando cria o grupo de volume compartilhado shared_vg1 em /dev/vdb.
[root@z1 ~]# vgcreate --shared shared_vg1 /dev/vdb

Physical volume "/dev/vdb" successfully created.
Volume group "shared_vg1" successfully created
VG shared_vg1 starting dlm lockspace
Starting locking. Waiting until locks are ready...
O seguinte comando cria o grupo de volume compartilhado shared_vg2 em /dev/vdc.
53
[root@z1 ~]# vgcreate --shared shared_vg2 /dev/vdc

Physical volume "/dev/vdc" successfully created.
Volume group "shared_vg2" successfully created
9. No segundo nó do agrupamento, inicie o gerenciador de fechaduras para cada um dos grupos

de volume compartilhado.
[root@z2 ~]# vgchange --lock-start shared_vg1

[root@z2 ~]# vgchange --lock-start shared_vg2
10. Em um nó do cluster, criar os volumes lógicos compartilhados e formatar os volumes com um

sistema de arquivos GFS2. É necessário um diário para cada nó que monta o sistema de arquivo.
Certifique-se de criar periódicos suficientes para cada um dos nós de seu cluster.
[root@z1 ~]# lvcreate --activate sy -L5G -n shared_lv1 shared_vg1

Logical volume "shared_lv1" created.
[root@z1 ~]# mkfs.gfs2 -j2 -p lock_dlm -t my_cluster:gfs2-demo1

/dev/shared_vg1/shared_lv1
11. Crie um recurso LVM-activate para cada volume lógico para ativar automaticamente esse
volume lógico em todos os nós.
a. Criar um recurso LVM-activate chamado sharedlv1 para o volume lógico shared_lv1 no

grupo de volume shared_vg1. Este comando também cria o grupo de recursos shared_vg1
que inclui o recurso. Neste exemplo, o grupo de recursos tem o mesmo nome do grupo de
volume compartilhado que inclui o volume lógico.
[root@z1 ~]# pcs resource create sharedlv1 --group shared_vg1 ocf:heartbeat:LVM-

activate lvname=shared_lv1 vgname=shared_vg1 activation_mode=shared
vg_access_mode=lvmlockd
b. Criar um recurso LVM-activate chamado sharedlv2 para o volume lógico shared_lv2 no

grupo de volume shared_vg1. Este recurso também fará parte do grupo de recursos
shared_vg1.

c. Criar um recurso LVM-activate chamado sharedlv3 para o volume lógico shared_lv1 no

54
c. Criar um recurso LVM-activate chamado sharedlv3 para o volume lógico shared_lv1 no

grupo de volume shared_vg2. Este comando também cria o grupo de recursos shared_vg2
que inclui o recurso.

12. Clonar os dois novos grupos de recursos.
[root@z1 ~]# pcs resource clone shared_vg1 interleave=true

[root@z1 ~]# pcs resource clone shared_vg2 interleave=true
13. Configurar as restrições de pedidos para garantir que o grupo de recursos locking que inclui os
recursos dlm e lvmlockd comece primeiro.
[root@z1 ~]# pcs constraint order start locking-clone then shared_vg1-clone

Adding locking-clone shared_vg1-clone (kind: Mandatory) (Options: first-action=start then-
action=start)
[root@z1 ~]# pcs constraint order start locking-clone then shared_vg2-clone
Adding locking-clone shared_vg2-clone (kind: Mandatory) (Options: first-action=start then-
action=start)
14. Configurar as restrições de colocação para garantir que os grupos de recursos vg1 e vg2
comecem no mesmo nó que o grupo de recursos locking.
[root@z1 ~]# pcs constraint colocation add shared_vg1-clone with locking-clone

[root@z1 ~]# pcs constraint colocation add shared_vg2-clone with locking-clone
15. Em ambos os nós do agrupamento, verificar se os volumes lógicos estão ativos. Pode haver um
atraso de alguns segundos.
[root@z1 ~]# lvs

LV VG Attr LSize
shared_lv1 shared_vg1 -wi-a----- 5.00g
[root@z2 ~]# lvs

LV VG Attr LSize
16. Criar um recurso de sistema de arquivo para montar automaticamente cada sistema de arquivo
GFS2 em todos os nós.
Você não deve adicionar o sistema de arquivo ao arquivo /etc/fstab porque ele será gerenciado
como um recurso de cluster Pacemaker. As opções de montagem podem ser especificadas
como parte da configuração do recurso com options=options. Execute o comando pcs
resource describe Filesystem para opções de configuração completa.
Os seguintes comandos criam os recursos do sistema de arquivos. Estes comandos adicionam

cada recurso ao grupo de recursos que inclui o recurso de volume lógico para aquele sistema de
arquivo.
55
[root@z1 ~]# pcs resource create sharedfs1 --group shared_vg1

ocf:heartbeat:Filesystem device="/dev/shared_vg1/shared_lv1" directory="/mnt/gfs1"
fstype="gfs2" options=noatime op monitor interval=10s on-fail=fence
17. Verificar se os sistemas de arquivo GFS2 estão montados em ambos os nós do cluster.
[root@z1 ~]# mount | grep gfs2

/dev/mapper/shared_vg1-shared_lv1 on /mnt/gfs1 type gfs2 (rw,noatime,seclabel)
[root@z2 ~]# mount | grep gfs2

18. Verifique o status do agrupamento.
[root@z1 ~]# pcs status --full

[...1
smoke-apc (stonith:fence_apc): Started z1.example.com

Clone Set: locking-clone [locking]
Clone Set: shared_vg1-clone [shared_vg1]
Resource Group: shared_vg1:0
sharedlv1 (ocf::heartbeat:LVM-activate): Started z2.example.com
sharedfs1 (ocf::heartbeat:Filesystem): Started z2.example.com
sharedfs2 (ocf::heartbeat:Filesystem): Started example.co
Clone Set: shared_vg2-clone [shared_vg2]
56

...
Recursos adicionais
Para informações sobre a configuração do armazenamento em bloco compartilhado para um

cluster Red Hat High Availability com discos compartilhados Microsoft Azure, consulte
Configuração do armazenamento em bloco compartilhado .
Para informações sobre a configuração do armazenamento em bloco compartilhado para um

cluster Red Hat High Availability com volumes Amazon EBS Multi-Attach, consulte
Configuração do armazenamento em bloco compartilhado .
Para informações sobre como configurar o armazenamento em blocos compartilhados para um

cluster de alta disponibilidade da Red Hat em Alibaba Cloud, veja Configurando o
armazenamento em blocos compartilhados para um cluster de alta disponibilidade da Red Hat
em Alibaba Cloud.
7.2. MIGRAÇÃO DE UM SISTEMA DE ARQUIVOS GFS2 DE RHEL7 PARA

RHEL8
No Red Hat Enterprise Linux 8, o LVM usa o daemon LVM lock lvmlockd ao invés de clvmd para
gerenciar dispositivos de armazenamento compartilhado em um cluster ativo/ativo. Isto requer que
você configure os volumes lógicos que seu cluster ativo/ativo irá requerer como volumes lógicos
compartilhados. Além disso, isto requer que você use o recurso LVM-activate para gerenciar um volume
LVM e que você use o agente de recursos lvmlockd para gerenciar o daemon lvmlockd. Veja
Configurando um sistema de arquivos GFS2 em um cluster para um procedimento completo de
configuração de um cluster Pacemaker que inclui sistemas de arquivos GFS2 usando volumes lógicos
compartilhados.
Para usar seus volumes lógicos existentes do Red Hat Enterprise Linux 7 ao configurar um cluster
RHEL8 que inclui sistemas de arquivo GFS2, execute o seguinte procedimento a partir do cluster
RHEL8. Neste exemplo, o volume lógico do cluster RHEL 7 faz parte do grupo de volume
upgrade_gfs_vg.
NOTA
O cluster RHEL8 deve ter o mesmo nome que o cluster RHEL7 que inclui o sistema de
arquivos GFS2 para que o sistema de arquivos existente seja válido.
1. Certifique-se de que os volumes lógicos contendo os sistemas de arquivo GFS2 estejam

atualmente inativos. Este procedimento é seguro somente se todos os nós tiverem parado de
usar o grupo de volume.
2. A partir de um nó no aglomerado, mudar forçadamente o grupo de volume para ser local.
[root@rhel8-01 ~]# vgchange --lock-type none --lock-opt force upgrade_gfs_vg

Forcibly change VG lock type to none? [y/n]: y
Volume group "upgrade_gfs_vg" successfully changed
57
3. De um nó no agrupamento, mude o grupo de volume local para um grupo de volume

compartilhado
[root@rhel8-01 ~]# vgchange --lock-type dlm upgrade_gfs_vg

Volume group "upgrade_gfs_vg" successfully changed
4. Em cada nó do aglomerado, comece a travar para o grupo de volume.
[root@rhel8-01 ~]# vgchange --lock-start upgrade_gfs_vg

VG upgrade_gfs_vg starting dlm lockspace
[root@rhel8-02 ~]# vgchange --lock-start upgrade_gfs_vg
VG upgrade_gfs_vg starting dlm lockspace
Após realizar este procedimento, você pode criar um recurso LVM-activate para cada volume lógico.
58
CAPÍTULO 8. COMEÇANDO COM O PCSD WEB UI

A pcsd Web UI é uma interface gráfica do usuário para criar e configurar clusters Pacemaker/Corosync.
8.1. INSTALAÇÃO DE SOFTWARE DE CLUSTER

O seguinte procedimento instala o software de cluster e configura seu sistema para a criação de
clusters.
1. Em cada nó do cluster, instale os pacotes de software Red Hat High Availability Add-On junto
com todos os agentes de vedação disponíveis no canal High Availability.
Alternativamente, você pode instalar os pacotes de software Red Hat High Availability Add-On
junto com apenas o agente de vedação que você necessita com o seguinte comando.
# yum install pcs pacemaker fence-agents-model
O comando a seguir exibe uma lista dos agentes de vedação disponíveis.
# rpm -q -a | grep fence

fence-agents-rhevm-4.0.2-3.el7.x86_64
fence-agents-ilo-mp-4.0.2-3.el7.x86_64
fence-agents-ipmilan-4.0.2-3.el7.x86_64
...

ATENÇÃO
Após instalar os pacotes Red Hat High Availability Add-On, você deve
assegurar-se de que suas preferências de atualização de software estejam
definidas para que nada seja instalado automaticamente. A instalação em
um cluster em execução pode causar comportamentos inesperados. Para
mais informações, consulte Práticas recomendadas para a aplicação de
atualizações de software em um cluster de armazenamento RHEL de alta
disponibilidade ou resiliente.
NOTA
Você pode determinar se o daemon firewalld está instalado em seu sistema com
o comando rpm -q firewalld. Se ele estiver instalado, você pode determinar se
ele está rodando com o comando firewall-cmd --state.
59

NOTA
A configuração ideal de firewall para componentes de cluster depende do

ambiente local, onde talvez seja necessário levar em conta considerações como,
por exemplo, se os nós têm múltiplas interfaces de rede ou se há firewalls fora do
host. O exemplo aqui, que abre as portas que são geralmente exigidas por um
cluster Pacemaker, deve ser modificado para se adequar às condições locais. A
habilitação de portas para o Add-On de Alta Disponibilidade mostra as portas
para habilitar para o Add-On de Alta Disponibilidade da Red Hat e fornece uma
explicação para o que cada porta é usada.
3. Para usar pcs para configurar o cluster e se comunicar entre os nós, você deve definir uma
senha em cada nó para o ID do usuário hacluster, que é a conta de administração pcs. É
recomendado que a senha para o usuário hacluster seja a mesma em cada nó.
# passwd hacluster
New password:
4. Antes que o cluster possa ser configurado, o daemon pcsd deve ser iniciado e habilitado para
iniciar na inicialização em cada nó. Este daemon trabalha com o comando pcs para gerenciar a
configuração através dos nós do cluster.
Em cada nó do cluster, execute os seguintes comandos para iniciar o serviço pcsd e para
habilitar pcsd no início do sistema.

8.2. CRIAÇÃO DA INTERFACE WEB DO PCSD

Após ter instalado as ferramentas de configuração do Pacemaker e configurado seu sistema para
configuração de cluster, use o seguinte procedimento para configurar seu sistema para usar a interface
web pcsd para configurar um cluster.
1. Em qualquer sistema, abra um navegador para o seguinte URL, especificando um dos nós do
cluster (note que este usa o protocolo https ). Isto faz surgir a tela de login pcsd Web UI.
https://nodename:2224
2. Faça o login como usuário hacluster. Isto traz à tona a página Manage Clusters como
mostrado em Figura 8.1, “Página Gerenciar Clusters” .
Figura 8.1. Página Gerenciar Clusters

60
Figura 8.1. Página Gerenciar Clusters
8.3. CRIANDO UM CLUSTER COM O PCSD WEB UI

A partir da página Gerenciar clusters, você pode criar um novo cluster, adicionar um cluster existente à
interface web, ou remover um cluster da interface web.
Para criar um cluster, clique em Create New. Digite o nome do agrupamento a ser criado e os
nós que constituem o agrupamento. Se você não tiver autenticado previamente o usuário
hacluster para cada nó do cluster, será solicitado que você autentique os nós do cluster.
Ao criar o cluster, você pode configurar opções avançadas de cluster, clicando em Go to

advanced settings nesta tela. As configurações avançadas de cluster que você pode configurar
são descritas em Configuração de opções avançadas de configuração de cluster com a
interface Web do pcsd.
Para adicionar um cluster existente à interface web, clique em Add Existing e digite o nome do
host ou endereço IP de um nó no cluster que você gostaria de gerenciar com a interface web.
Uma vez criado ou adicionado um agrupamento, o nome do agrupamento é exibido na página Gerenciar
Agrupamento. Selecionando o agrupamento, são exibidas informações sobre o agrupamento.
NOTA
Ao usar a interface pcsd para configurar um cluster, você pode mover o mouse sobre o
texto descrevendo muitas das opções para ver descrições mais longas dessas opções
como um display tooltip.
8.3.1. Configuração de opções avançadas de configuração de clusters com a

interface Web do pcsd
Ao criar um cluster, você pode configurar opções adicionais de cluster clicando em Ir para
configurações avançadas na tela Criar cluster. Isto permite modificar as configurações configuráveis
dos seguintes componentes do cluster:
61
Configurações de transporte: Valores para o mecanismo de transporte utilizado para a

comunicação em cluster
Ajustes do quorum: Valores para as opções de quorum do serviço votequorum
Ajustes do Totem: Valores para o protocolo Totem usado pela Corosync
Selecionando essas opções, são exibidas as configurações que você pode configurar. Para obter
informações sobre cada uma das configurações, coloque o ponteiro do mouse sobre a opção em
particular.
8.3.2. Definição de permissões de gerenciamento de clusters

Há dois conjuntos de permissões de agrupamento que você pode conceder aos usuários:
Permissões para gerenciar o cluster com a interface Web, que também concede permissões
para executar comandos pcs que se conectam aos nós através de uma rede. Esta seção
descreve como configurar essas permissões com a interface Web.
Permissões para usuários locais para permitir o acesso somente leitura ou leitura-escrita à
configuração do cluster, usando ACLs. A configuração de ACLs com a interface Web é descrita
em Configuração de componentes de cluster com a interface Web pcsd .
Você pode conceder permissão para usuários específicos que não o usuário hacluster para gerenciar o
cluster através da interface Web e executar comandos pcs que se conectam aos nós através de uma
rede, adicionando-os ao grupo haclient. Você pode então configurar as permissões definidas para um
membro individual do grupo haclient, clicando na guia Permissões na página Gerenciar clusters e
definindo as permissões na tela resultante. A partir desta tela, você também pode configurar as
permissões para os grupos.
Você pode conceder as seguintes permissões:
Leia as permissões, para ver as configurações do cluster
Escrever permissões, para modificar as configurações do cluster (exceto permissões e ACLs)
Conceder permissões, para modificar as permissões de agrupamento e ACLs
Permissões completas, para acesso irrestrito a um cluster, incluindo adição e remoção de nós,
com acesso a chaves e certificados
8.4. CONFIGURAÇÃO DE COMPONENTES DE CLUSTER COM O PCSD

WEB UI
Para configurar os componentes e atributos de um cluster, clique no nome do cluster exibido na tela
Manage Clusters. Isto faz surgir a página Nodes, conforme descrito em Seção 8.4.1, “Configuração de
nós de cluster com a interface Web do pcsd”. Esta página exibe um menu na parte superior da página
com as seguintes entradas:
Nós, como descrito em Seção 8.4.1, “Configuração de nós de cluster com a interface Web do
pcsd”
Recursos, conforme descritos em Seção 8.4.2, “Configuração de recursos de cluster com o pcsd
Web UI”
Dispositivos de vedação, como descrito em Seção 8.4.3, “Configuração de dispositivos de
62
Dispositivos de vedação, como descrito em Seção 8.4.3, “Configuração de dispositivos de

vedação com a interface Web do pcsd”
ACLs, como descrito em Seção 8.4.4, “Configuração de ACLs com a interface web pcsd”
Propriedades do Cluster, como descrito em Seção 8.4.5, “Configuração das propriedades do

cluster com a interface Web do pcsd”
8.4.1. Configuração de nós de cluster com a interface Web do pcsd

Selecionando a opção Nodes no menu ao longo da parte superior da página de gerenciamento de
cluster exibe os nós atualmente configurados e o status do nó atualmente selecionado, incluindo quais
recursos estão rodando no nó e as preferências de localização de recursos. Esta é a página padrão que é
exibida quando você seleciona um cluster na tela Manage Clusters.
Forme esta página, Você pode adicionar ou remover nós. Você também pode iniciar, parar, reiniciar ou
colocar um nó em modo de espera ou de manutenção. Para informações sobre o modo standby,
consulte Colocando um nó em modo standby. Para informações sobre o modo de manutenção, consulte
Colocando um nó em modo de manutenção.
Você também pode configurar os dispositivos de vedação diretamente desta página, como descrito na
seleção Configure Fencing. A configuração dos dispositivos de cercas é descrita em Seção 8.4.3,
“Configuração de dispositivos de vedação com a interface Web do pcsd”.
8.4.2. Configuração de recursos de cluster com o pcsd Web UI

Selecionando a opção Resources no menu ao longo da parte superior da página de gerenciamento de
cluster exibe os recursos atualmente configurados para o cluster, organizados de acordo com grupos de
recursos. A seleção de um grupo ou recurso exibe os atributos desse grupo ou recurso.
A partir desta tela, você pode adicionar ou remover recursos, pode editar a configuração dos recursos
existentes e pode criar um grupo de recursos.
Acrescentar um novo recurso ao agrupamento:
Clique em Add. Isto faz surgir a tela Add Resource.
Quando você seleciona um tipo de recurso no menu suspenso Type, os argumentos que você
deve especificar para esse recurso aparecem no menu.
Você pode clicar em Optional Arguments para exibir argumentos adicionais que você pode
especificar para o recurso que você está definindo.
Após inserir os parâmetros para o recurso que você está criando, clique em Create Resource.
Ao configurar os argumentos para um recurso, uma breve descrição do argumento aparece no menu.
Se você mover o cursor para o campo, é exibida uma descrição mais longa da ajuda desse argumento.
Você pode definir um recurso como um recurso clonado, ou como um recurso clonado promocional.
Para informações sobre estes tipos de recursos, consulte Criando recursos de cluster que estão ativos
em vários nós (recursos clonados).
Uma vez criado pelo menos um recurso, você pode criar um grupo de recursos. Para obter informações
gerais sobre grupos de recursos, consulte Configuração de grupos de recursos .
Para criar um grupo de recursos:
63
Selecione os recursos que farão parte do grupo na tela Resources e, em seguida, clique em
Create Group. Isto exibe a tela Create Group.
A partir da tela Create Group, você pode reorganizar a ordem dos recursos em um grupo de
recursos usando o recurso de arrastar e soltar para mover a lista dos recursos de um lugar para
outro.
Digite um nome de grupo e clique em Create Group. Isto o retorna à tela Resources, que
agora exibe o nome do grupo e os recursos dentro desse grupo.
Após ter criado um grupo de recursos, você pode indicar o nome desse grupo como parâmetro de
recurso ao criar ou modificar recursos adicionais.
8.4.3. Configuração de dispositivos de vedação com a interface Web do pcsd

Selecionando a opção Fence Devices no menu ao longo da parte superior da página de gerenciamento
de agrupamento exibe a tela Fence Devices, mostrando os dispositivos de vedação atualmente
configurados.
Para adicionar um novo dispositivo de cerca ao conjunto:
Clique em Add. Isto faz surgir a tela Add Fence Device.
Quando você seleciona um tipo de dispositivo de cerca no menu suspenso Type, os

argumentos que você deve especificar para aquele dispositivo de cerca aparecem no menu.
Você pode clicar em Optional Arguments para exibir argumentos adicionais que você pode
especificar para o dispositivo de cerca que você está definindo.
Após inserir os parâmetros para o novo dispositivo de vedação, clique em Create Fence
Instance.
Para configurar um dispositivo de esgrima SBD, clique em SBD na tela Fence Devices. Isto chama uma
tela que lhe permite ativar ou desativar a SBD no cluster.
Para mais informações sobre dispositivos de cercas, consulte Configuração de cercas em um cluster de
Alta Disponibilidade da Red Hat.
8.4.4. Configuração de ACLs com a interface web pcsd

Selecionando a opção ACLS no menu ao longo do topo da página de gerenciamento de cluster exibe
uma tela a partir da qual você pode definir permissões para usuários locais, permitindo acesso somente
leitura ou leitura-escrita à configuração do cluster usando listas de controle de acesso (ACLs).
Para atribuir permissões ACL, você cria uma função e define as permissões de acesso para essa função.
Cada função pode ter um número ilimitado de permissões (leitura/escrita/denúncia) aplicadas a uma
consulta XPath ou à identificação de um elemento específico. Após definir a função, você pode atribuí-
la a um usuário ou grupo existente.
Para mais informações sobre a atribuição de permissões usando ACLs, consulte Definindo permissões
locais usando ACLs.
8.4.5. Configuração das propriedades do cluster com a interface Web do pcsd

Selecionando a opção Cluster Properties no menu ao longo do topo da página de gerenciamento de
cluster exibe as propriedades do cluster e permite modificar estas propriedades a partir de seus valores
64
padrão. Para obter informações sobre as propriedades de agrupamento do Pacemaker, consulte

Propriedades de agrupamento do Pacemaker .
8.5. CONFIGURAÇÃO DE UMA INTERFACE WEB PCSD DE ALTA

DISPONIBILIDADE
Quando você usa a interface pcsd, você se conecta a um dos nós do cluster para exibir as páginas de
gerenciamento do cluster. Se o nó ao qual você está se conectando cair ou ficar indisponível, você pode
reconectar-se ao cluster abrindo seu navegador para uma URL que especifique um nó diferente do
cluster.
É possível, no entanto, configurar a própria interface pcsd para alta disponibilidade, caso em que você
pode continuar a gerenciar o cluster sem entrar em uma nova URL.
Para configurar a interface web pcsd para alta disponibilidade, execute os seguintes passos.
1. Certifique-se de que os certificados pcsd estejam sincronizados entre os nós do cluster,

definindo PCSD_SSL_CERT_SYNC_ENABLED para true no arquivo de configuração
/etc/sysconfig/pcsd. A habilitação da sincronização de certificados faz com que pcsd
sincronize os certificados para a configuração do cluster e os comandos de adição de nós. No
RHEL 8, PCSD_SSL_CERT_SYNC_ENABLED é definido como false por padrão.
2. Crie um recurso de cluster IPaddr2, que é um endereço IP flutuante que você usará para se
conectar à pcsd Web UI. O endereço IP não deve ser um endereço já associado a um nó físico.
Se o dispositivo NIC do recurso IPaddr2 não for especificado, o IP flutuante deve residir na
mesma rede que um dos endereços IP do nó estaticamente atribuído, caso contrário o
dispositivo NIC para atribuir o endereço IP flutuante não poderá ser detectado adequadamente.
3. Criar certificados SSL personalizados para uso com pcsd e garantir que eles sejam válidos para
os endereços dos nós usados para conexão com a IU da Web pcsd.
a. Para criar certificados SSL personalizados, você pode usar certificados wildcard ou pode
usar a extensão do certificado Subject Alternative Name. Para informações sobre o Sistema
de Certificados Red Hat, consulte o Guia de Administração do Sistema de Certificados Red
Hat.
b. Instale os certificados personalizados para pcsd com o comando pcs pcsd certkey.
c. Sincronize os certificados pcsd para todos os nós do cluster com o comando pcs pcsd
sync-certificates.
4. Conecte-se à pcsd Web UI usando o endereço IP flutuante que você configurou como um
recurso de cluster.
NOTA
Mesmo quando você configurar a interface pcsd para alta disponibilidade, você será
solicitado a entrar novamente quando o nó ao qual você está se conectando for
desligado.
65
CAPÍTULO 9. CONFIGURAÇÃO DE CERCAS EM UM CLUSTER

DE ALTA DISPONIBILIDADE DE CHAPÉU VERMELHO
Um nó que não responde ainda pode estar acessando dados. A única maneira de ter certeza de que
seus dados estão seguros é cercando o nó usando STONITH. STONITH é um acrônimo para "Shoot The
Other Node In The Head" e protege seus dados de serem corrompidos por nós desonestos ou acessos
simultâneos. Usando STONITH, você pode ter certeza de que um nó está verdadeiramente offline antes
de permitir que os dados sejam acessados de outro nó.
A STONITH também tem um papel a desempenhar no caso de um serviço agrupado não poder ser
interrompido. Neste caso, o cluster utiliza STONITH para forçar o nó inteiro a ficar offline, tornando
assim seguro iniciar o serviço em outro lugar.
Para informações gerais mais completas sobre cercas e sua importância em um cluster da Red Hat High
Availability, veja Fencing in a Red Hat High Availability Cluster .
Você implementa STONITH em um aglomerado de Pacemaker, configurando dispositivos de vedação

para os nós do aglomerado.
9.1. EXIBIÇÃO DOS AGENTES DE VEDAÇÃO DISPONÍVEIS E SUAS

OPÇÕES
Use o seguinte comando para visualizar a lista de todos os agentes STONITH disponíveis. Quando você
especifica um filtro, este comando exibe apenas os agentes STONITH que correspondem ao filtro.
pcs stonith list [filter]
Use o seguinte comando para visualizar as opções para o agente STONITH especificado.
pcs stonith descrevem stonith_agent
Por exemplo, o seguinte comando exibe as opções para o agente de vedação para APC sobre
telnet/SSH.
# pcs stonith describe fence_apc

Stonith options for: fence_apc
ipaddr (required): IP Address or Hostname
login (required): Login Name
passwd: Login password or passphrase
passwd_script: Script to retrieve password
cmd_prompt: Force command prompt
secure: SSH connection
port (required): Physical plug number or name of virtual machine
identity_file: Identity file for ssh
switch: Physical switch number on device
inet4_only: Forces agent to use IPv4 addresses only
inet6_only: Forces agent to use IPv6 addresses only
ipport: TCP port to use for connection with device
action (required): Fencing Action
verbose: Verbose mode
debug: Write debug information to given file
version: Display version information and exit
help: Display help and exit
66
CAPÍTULO 9. CONFIGURAÇÃO DE CERCAS EM UM CLUSTER DE ALTA DISPONIBILIDADE DE CHAPÉU VERMELHO
separator: Separator for CSV created by operation list

power_timeout: Test X seconds for status change after ON/OFF
shell_timeout: Wait X seconds for cmd prompt after issuing command
login_timeout: Wait X seconds for cmd prompt after login
power_wait: Wait X seconds after issuing ON/OFF
delay: Wait X seconds before fencing is started
retry_on: Count of attempts to retry power on

ATENÇÃO
Para agentes de cercas que fornecem uma opção method, um valor de cycle não é
apoiado e não deve ser especificado, pois pode causar corrupção de dados.
9.2. CRIANDO UM DISPOSITIVO DE CERCA

O formato para o comando para criar um dispositivo de pedra é o seguinte. Para uma listagem das
opções de criação de pedra disponíveis, consulte a tela pcs stonith -h.
pcs stonith create stonith_id stonith_device_type [stonith_device_options] [op operation_action

operation_options]
O seguinte comando cria um único dispositivo de esgrima para um único nó.
# pcs stonith create MyStonith fence_virt pcmk_host_list=f1 op monitor interval=30s
Alguns dispositivos de cerca podem cercar apenas um único nó, enquanto outros dispositivos podem
cercar vários nós. Os parâmetros que você especifica ao criar um dispositivo de cerca dependem do que
seu dispositivo de cerca suporta e requer.
Alguns dispositivos de cercas podem determinar automaticamente quais nós podem cercar.
Você pode usar o parâmetro pcmk_host_list ao criar um dispositivo de esgrima para

especificar todas as máquinas que são controladas por esse dispositivo de esgrima.
Alguns dispositivos de cercas exigem um mapeamento dos nomes dos hospedeiros de acordo
com as especificações que o dispositivo de cerca compreende. Você pode mapear os nomes
dos anfitriões com o parâmetro pcmk_host_map ao criar um dispositivo de cercas.
Para informações sobre os parâmetros pcmk_host_list e pcmk_host_map, consulte Propriedades

Gerais dos Dispositivos de Esgrima.
Após configurar um dispositivo de cerca, é imperativo que você teste o dispositivo para garantir que ele
esteja funcionando corretamente. Para informações sobre como testar um dispositivo de cerca,
consulte Testando um dispositivo de cerca .
9.3. PROPRIEDADES GERAIS DOS DISPOSITIVOS DE ESGRIMA
Qualquer nó de cluster pode cercar qualquer outro nó de cluster com qualquer dispositivo de cerca,
67
Qualquer nó de cluster pode cercar qualquer outro nó de cluster com qualquer dispositivo de cerca,
independentemente de o recurso de cerca ser iniciado ou parado. Se o recurso é iniciado controla
apenas o monitor periódico do dispositivo, não se ele pode ser usado, com as seguintes exceções:
Você pode desativar um dispositivo de esgrima ao executar o pcs stonith disable stonith_id
comando. Isto impedirá qualquer nó de usar aquele dispositivo.
Para evitar que um nó específico utilize um dispositivo de esgrima, você pode configurar
restrições de localização para o recurso de esgrima com o comando pcs constraint location …
avoids.
A configuração do stonith-enabled=false irá desativar totalmente a vedação. Note, entretanto,

que a Red Hat não suporta aglomerados quando a vedação é desativada, pois não é adequada
para um ambiente de produção.
Tabela 9.1, “Propriedades Gerais dos Dispositivos de Esgrima” descreve as propriedades gerais que você
pode definir para dispositivos de esgrima.
Tabela 9.1. Propriedades Gerais dos Dispositivos de Esgrima
Campo Tipo Padrão Descrição
pcmk_host_map corda Um mapeamento de

nomes de host para
números de porta para
dispositivos que não
suportam nomes de
host. Por exemplo:
node1:1;node2:2,3
diz ao cluster para usar a
porta 1 para o nó 1 e as
portas 2 e 3 para o nó 2
pcmk_host_list corda Uma lista das máquinas

controladas por este
dispositivo (Opcional, a
menos que
pcmk_host_check=s
tatic-list).
68
pcmk_host_check corda * static-list se Como determinar quais

pcmk_host_list ou máquinas são
pcmk_host_map controladas pelo
estiver definido dispositivo. Valores
permitidos: dynamic-
* Caso contrário, list (consulte o
dynamic-list se o dispositivo), static-list
dispositivo de vedação (consulte o atributo
suportar a ação list pcmk_host_list ),
nenhum (assuma que
* Caso contrário, status cada dispositivo pode
se o dispositivo de cercar todas as
vedação suportar a ação máquinas)
status
*Caso contrário, none.
9.4. OPÇÕES AVANÇADAS DE CONFIGURAÇÃO DE CERCAS

Tabela 9.2, “Propriedades Avançadas dos Dispositivos de Esgrima” resume as propriedades adicionais
que você pode definir para dispositivos de esgrima. Note que estas propriedades são apenas para uso
avançado.
Tabela 9.2. Propriedades Avançadas dos Dispositivos de Esgrima
pcmk_host_argume corda porto Um parâmetro

nt alternativo para
fornecer em vez de
porto. Alguns
dispositivos não
suportam o parâmetro
padrão de porta ou
podem fornecer
parâmetros adicionais.
Use isto para especificar
um parâmetro
alternativo, específico
do dispositivo, que deve
indicar a máquina a ser
vedada. Um valor de
none pode ser usado
para dizer ao grupo que
não forneça nenhum
parâmetro adicional.
69
pcmk_reboot_action corda reinicialização Um comando alternativo

para executar ao invés
de reboot. Alguns
dispositivos não
suportam os comandos
padrão ou podem
fornecer comandos
adicionais. Use isto para
especificar um comando
do dispositivo, que
implemente a ação de
reinicialização.
pcmk_reboot_timeo tempo 60s Especifique um tempo

ut limite alternativo a ser
usado para ações de
reinicialização em vez de
stonith-timeout.
Alguns dispositivos
precisam de muito
mais/menos tempo para
serem completados do
que o normal. Use isto
para especificar um
tempo limite alternativo,
específico para o
dispositivo, para ações
de reinicialização.
pcmk_reboot_retries inteiro 2 O número máximo de

vezes para tentar
novamente o comando
reboot dentro do
período de tempo limite.
Alguns dispositivos não
suportam conexões
múltiplas. As operações
podem falhar se o
dispositivo estiver
ocupado com outra
tarefa, então o
Pacemaker irá
automaticamente tentar
de novo a operação, se
houver tempo restante.
Use esta opção para
alterar o número de
vezes que o Pacemaker
reinicia as ações antes
de desistir.
70
pcmk_off_action corda off Um comando alternativo

de off. Alguns
dispositivos não
padrão ou podem
fornecer comandos
para o dispositivo, que
implemente a ação off.
pcmk_off_timeout tempo 60s Especifique um tempo

limite alternativo a ser
usado para ações fora
do ar em vez de
stonith-timeout.
Alguns dispositivos
precisam de muito mais
ou muito menos tempo
para serem completados
do que o normal. Use
isto para especificar um
específico para o
dispositivo, para as
ações de desligamento.
pcmk_off_retries inteiro 2 O número máximo de

vezes para tentar
novamente o comando
off dentro do tempo
limite. Alguns
dispositivos não
suportam conexões
podem falhar se o
dispositivo estiver
ocupado com outra
tarefa, então o
Pacemaker irá
vezes em que o
Pacemaker tenta
novamente desligar as
ações antes de desistir.
71
pcmk_list_action corda lista Um comando alternativo

de list. Alguns
dispositivos não
padrão ou podem
fornecer comandos
do dispositivo, que
implemente a ação da
lista.
pcmk_list_timeout tempo 60s Especifique um tempo

limite alternativo a ser
lista. Alguns dispositivos
específico do
ações da lista.
pcmk_list_retries inteiro 2 O número máximo de

vezes para tentar
novamente o comando
list dentro do período
de tempo limite. Alguns
dispositivos não
suportam conexões
podem falhar se o
dispositivo estiver
ocupado com outra
tarefa, então o
Pacemaker irá
tenta novamente listar
ações antes de desistir.
72
pcmk_monitor_actio corda monitor Um comando alternativo

n para executar ao invés
de monitor. Alguns
dispositivos não
padrão ou podem
fornecer comandos
do dispositivo, que
monitoramento.
pcmk_monitor_time tempo 60s Especifique um tempo

out limite alternativo a ser
monitoramento em vez
de stonith-timeout.
Alguns dispositivos
específico para o
ações de
monitoramento.
73
pcmk_monitor_retrie inteiro 2 O número máximo de

s vezes para tentar
novamente o comando
monitor dentro do
suportam conexões
podem falhar se o
dispositivo estiver
ocupado com outra
tarefa, então o
Pacemaker irá
volta a testar as ações
de monitoramento antes
de desistir.
pcmk_status_action corda status Um comando alternativo

de status. Alguns
dispositivos não
padrão ou podem
fornecer comandos
status.
74
pcmk_status_timeou tempo 60s Especifique um tempo

t limite alternativo a ser
status em vez de
stonith-timeout.
Alguns dispositivos
específico do
ações de status.
pcmk_status_retries inteiro 2 O número máximo de

vezes para tentar
novamente o comando
de status dentro do
suportam conexões
podem falhar se o
dispositivo estiver
ocupado com outra
tarefa, então o
Pacemaker irá
vezes em que o
Pacemaker tenta
novamente as ações de
status antes de desistir.
75
pcmk_delay_base tempo 0s Habilitar um atraso de

base para ações de
pedra e especificar um
valor de atraso de base.
Em um cluster com um
número par de nós,
configurar um atraso
pode ajudar a evitar que
os nós se cerquem uns
aos outros ao mesmo
tempo em uma divisão
uniforme. Um atraso
aleatório pode ser útil
quando o mesmo
dispositivo de cerca é
usado para todos os nós,
e diferentes atrasos
estáticos podem ser
úteis em cada
dispositivo de cerca
quando um dispositivo
separado é usado para
cada nó. O atraso geral é
derivado de um valor de
atraso aleatório
adicionando este atraso
estático para que a
soma seja mantida
abaixo do atraso
máximo. Se você definir
pcmk_delay_base
mas não definir
pcmk_delay_max,
não há nenhum
componente aleatório
para o atraso e este será
o valor de
pcmk_delay_base.
Alguns agentes
individuais de cercas
implementam um
parâmetro de "atraso",
que é independente de
atrasos configurados
com uma propriedade
pcmk_delay_*. Se
ambos os atrasos forem
configurados, eles são
adicionados juntos e,
portanto, geralmente
não seriam usados em
conjunto.
76
Campo
pcmk_delay_max Tipo
tempo Padrão
0s Descrição
Permitir um atraso
aleatório para ações
pedregosas e
especificar o máximo de
atraso aleatório. Em um
cluster com um número
par de nós, configurar
um atraso pode ajudar a
evitar que os nós se
cerquem uns aos outros
ao mesmo tempo em
uma divisão uniforme.
Um atraso aleatório
pode ser útil quando o
mesmo dispositivo de
cerca é usado para
todos os nós, e
diferentes atrasos
estáticos podem ser
úteis em cada
dispositivo de cerca
quando um dispositivo
separado é usado para
cada nó. O atraso geral é
derivado deste valor de
atraso aleatório
adicionando um atraso
estático para que a
soma seja mantida
abaixo do atraso
máximo. Se você definir
pcmk_delay_max,
mas não definir
pcmk_delay_base,
não há nenhum
componente estático
para o atraso.
Alguns agentes
individuais de cercas
implementam um
parâmetro de "atraso",
que é independente de
atrasos configurados
com uma propriedade
pcmk_delay_*. Se
ambos os atrasos forem
configurados, eles são
adicionados juntos e,
portanto, geralmente
não seriam usados em
conjunto.
77
pcmk_action_limit inteiro 1 O número máximo de

ações que podem ser
realizadas em paralelo
neste dispositivo. A
propriedade do cluster
concurrent-
fencing=true precisa
ser configurada primeiro
(este é o valor padrão
para RHEL 8.1 e
posterior). Um valor de -
1 é ilimitado.
pcmk_on_action corda em Apenas para uso

avançado: Um comando
alternativo para
executar em vez de on.
padrão ou podem
fornecer comandos
implemente a ação on.
pcmk_on_timeout tempo 60s Apenas para uso

avançado: Especifique
um tempo limite
alternativo para usar
para ações em on ao
invés de stonith-
timeout . Alguns
dispositivos precisam de
muito mais ou muito
menos tempo para
serem completados do
que o normal. Use isto
para especificar um
timeout alternativo,
específico para o
dispositivo, para ações
em on.
78
pcmk_on_retries inteiro 2 Apenas para uso

avançado: O número
máximo de vezes para
tentar novamente o
comando on dentro do
suportam múltiplas
conexões. As operações
podem fail se o
dispositivo estiver
ocupado com outra
tarefa, então o
Pacemaker irá
novamente a operação,
se houver tempo
restante. Use esta
opção para alterar o
número de vezes que o
Pacemaker tenta
novamente on ações
antes de desistir.
Além das propriedades que você pode definir para cada dispositivo de cerca, há também propriedades
de agrupamento que você pode definir que determinam o comportamento da cerca, como descrito em
Tabela 9.3, “Propriedades de aglomeração que determinam o comportamento das vedações” .
Tabela 9.3. Propriedades de aglomeração que determinam o comportamento das vedações
Opção Padrão Descrição
stonith-enabled verdadeiro Indica que os nós que falharam e

os nós com recursos que não
podem ser parados devem ser
cercados. A proteção de seus
dados requer que você defina isto
true.
Se true, ou não configurado, o

grupo se recusará a iniciar
recursos a menos que um ou mais
recursos STONITH também
tenham sido configurados.
A Red Hat só suporta clusters

com este valor definido para true.
79
stonith-action reinicialização Ação para enviar ao dispositivo

STONITH. Valores permitidos:
reboot, off. O valor poweroff
também é permitido, mas é usado
somente para dispositivos
legados.
stonith-timeout 60s Quanto tempo esperar para que

uma ação de STONITH seja
concluída.
stonith-max-attempts 10 Quantas vezes a esgrima pode

falhar para um alvo antes que o
agrupamento não o volte a tentar
imediatamente.
stonith-watchdog-timeout O tempo máximo de espera até

que um nó possa ser assumido
como tendo sido morto pelo cão
de guarda de hardware.
Recomenda-se que este valor
seja ajustado para o dobro do
valor do timeout do cão de guarda
de hardware. Esta opção só é
necessária se a SBD baseada em
Watchdog for usada para esgrima.
concurrent-fencing verdadeiro (RHEL 8.1 e Permitir que as operações de

posteriores) esgrima sejam realizadas em
paralelo.
80
fence-reaction parar (Red Hat Enterprise Linux 8.2 e

posteriores) Determina como um
nó de cluster deve reagir se
notificado de sua própria
vedação. Um nó de cluster pode
receber notificação de seu
próprio cercado se o cercado
estiver mal configurado, ou se
estiver em uso um cercado de
tecido que não corte a
comunicação de cluster. Os
valores permitidos são stop para
tentar parar imediatamente o
Pacemaker e ficar parado, ou
panic para tentar reiniciar
imediatamente o nó local, caindo
de volta para parar em caso de
falha.
Embora o valor padrão para esta

propriedade seja stop, a escolha
mais segura para este valor é
panic , que tenta reinicializar
imediatamente o nó local. Se você
preferir o comportamento de
parada, como é mais provável que
seja o caso em conjunto com a
vedação de tecido, é
recomendável que você defina
isto explicitamente.
Para informações sobre a definição das propriedades de agrupamento, consulte Definição e remoção
das propriedades de agrupamento.
9.5. TESTE DE UM DISPOSITIVO DE CERCA

A vedação é uma parte fundamental da infra-estrutura do Red Hat Cluster e, portanto, é importante
validar ou testar se a vedação está funcionando corretamente.
Use o seguinte procedimento para testar um dispositivo de cerca.
1. Use ssh, telnet, HTTP, ou qualquer protocolo remoto que for usado para conectar ao dispositivo
para fazer o login e testar manualmente o dispositivo de cerca ou ver qual saída é dada. Por
exemplo, se você estiver configurando uma cerca para um dispositivo habilitado para IPMI,
então tente fazer o log in remotamente com ipmitool. Tome nota das opções usadas ao fazer o
login manualmente, pois essas opções podem ser necessárias ao usar o agente de vedação.
Se você não conseguir entrar no dispositivo de cerca, verifique se o dispositivo é "pingável", não
há nada como uma configuração de firewall que esteja impedindo o acesso ao dispositivo de
cerca, o acesso remoto está habilitado no dispositivo de cerca e as credenciais estão corretas.
2. Executar o agente de vedação manualmente, usando o roteiro do agente de vedação. Isto não
81
requer que os serviços de cercado estejam sendo executados, portanto, você pode executar
esta etapa antes que o dispositivo seja configurado no cercado. Isto pode garantir que o
dispositivo de cerca esteja respondendo corretamente antes de prosseguir.
NOTA
Os exemplos nesta seção utilizam o script fence_ipmilan fence agent para um

dispositivo iLO. O verdadeiro agente de cerca que você usará e o comando que
chama esse agente dependerá do hardware de seu servidor. Você deve consultar
a página de manual do agente de cerca que você está usando para determinar
quais opções especificar. Você normalmente precisará saber o login e a senha do
dispositivo de cerca e outras informações relacionadas ao dispositivo de cerca.
O exemplo a seguir mostra o formato que você usaria para executar o script fence_ipmilan
fence agent com o parâmetro -o status para verificar o status da interface do dispositivo de
cerca em outro nó sem realmente cercar o mesmo. Isto permite que você teste o dispositivo e o
faça funcionar antes de tentar reiniciar o nó. Ao executar este comando, você especifica o nome
e a senha de um usuário iLO que tem permissão para ligar e desligar o dispositivo iLO.
# fence_ipmilan -a ipaddress -l username -p password -o status
O exemplo a seguir mostra o formato que você usaria para executar o script fence_ipmilan
fence agent com o parâmetro -o reboot. A execução deste comando em um nó reinicia o nó
gerenciado por este dispositivo iLO.
# fence_ipmilan -a ipaddress -l username -p password -o reboot
Se o agente da cerca falhou em fazer uma ação de status, desligado, ligado ou reinicialização,
você deve verificar o hardware, a configuração do dispositivo da cerca e a sintaxe de seus
comandos. Além disso, você pode executar o script do agente de cerca com a saída de debug
habilitada. A saída de depuração é útil para alguns agentes de cercas para ver onde na
seqüência de eventos o script do agente de cercas está falhando ao efetuar login no dispositivo
de cercas.
# fence_ipmilan -a ipaddress -l username -p password -o status -D /tmp/$(hostname)-

fence_agent.debug
Ao diagnosticar uma falha que tenha ocorrido, você deve se certificar de que as opções
especificadas ao fazer o login manualmente no dispositivo de cerca são idênticas ao que você
passou para o agente de cerca com o roteiro do agente de cerca.
Para agentes de cerca que suportam uma conexão criptografada, você pode ver um erro devido
à falha na validação do certificado, exigindo que você confie no host ou que você use o
parâmetro ssl-insecure do agente de cerca. Da mesma forma, se o SSL/TLS estiver
desabilitado no dispositivo alvo, você pode precisar prestar contas disso ao definir os
parâmetros SSL para o agente de cerca.
NOTA
Se o agente de vedação que está sendo testado é um fence_drac, fence_ilo, ou

algum outro agente de vedação para um dispositivo de gerenciamento de
sistemas que continua a falhar, então volte a tentar fence_ipmilan. A maioria dos
cartões de gerenciamento de sistemas suporta o login remoto IPMI e o único
agente de vedação suportado é fence_ipmilan.
82
3. Uma vez que o dispositivo de cerca tenha sido configurado no aglomerado com as mesmas
opções que funcionaram manualmente e o aglomerado tenha sido iniciado, teste a cerca com o
comando pcs stonith fence de qualquer nó (ou mesmo várias vezes de diferentes nós), como
no exemplo a seguir. O comando pcs stonith fence lê a configuração do cluster a partir do CIB
e chama o agente de cerca como configurado para executar a ação de cerca. Isto verifica se a
configuração do aglomerado está correta.
# pcs stonith fence node_name
Se o comando pcs stonith fence funcionar corretamente, isso significa que a configuração da
cerca para o conjunto deve funcionar quando ocorrer um evento de cerca. Se o comando falhar,
isso significa que o gerenciamento do cercado não pode invocar o dispositivo de cercado
através da configuração que ele recuperou. Verifique as seguintes questões e atualize sua
configuração de cercas conforme necessário.
Verifique a configuração de sua cerca. Por exemplo, se você tiver usado um mapa do host,
você deve assegurar-se de que o sistema possa encontrar o nó usando o nome do host que
você forneceu.
Verifique se a senha e o nome de usuário do dispositivo incluem algum caractere especial

que possa ser mal interpretado pela concha do bash. Certifique-se de digitar senhas e
nomes de usuário rodeados de aspas que possam resolver este problema.
Verifique se você pode se conectar ao dispositivo usando o endereço IP exato ou o nome

do host que você especificou no comando pcs stonith. Por exemplo, se você der o nome
do host no comando stonith mas testar usando o endereço IP, este não é um teste válido.
Se o protocolo que seu dispositivo de cerca usa for acessível a você, use esse protocolo
para tentar se conectar ao dispositivo. Por exemplo, muitos agentes usam ssh ou telnet.
Você deve tentar conectar-se ao dispositivo com as credenciais que você forneceu ao
configurar o dispositivo, para ver se você recebe um prompt válido e pode fazer o login no
dispositivo.
Se você determinar que todos os seus parâmetros são apropriados, mas ainda tiver
problemas de conexão com seu dispositivo de cerca, você pode verificar o registro no
próprio dispositivo de cerca, se o dispositivo fornece isso, o que mostrará se o usuário se
conectou e qual comando o usuário emitiu. Você também pode procurar no arquivo
/var/log/messages por casos de pedraria e erro, o que poderia dar alguma idéia do que está
acontecendo, mas alguns agentes podem fornecer informações adicionais.
4. Uma vez que os testes do dispositivo de vedação estejam funcionando e o conjunto esteja em
funcionamento, teste uma falha real. Para isso, tomar uma ação no aglomerado que deve iniciar
uma perda simbólica.
Desmontar uma rede. A maneira como você toma uma rede depende de sua configuração
específica. Em muitos casos, você pode fisicamente puxar a rede ou os cabos de energia
para fora do host. Para informações sobre como simular uma falha de rede, veja Qual é a
maneira adequada de simular uma falha de rede em um Cluster RHEL?
NOTA
Desabilitar a interface de rede no host local em vez de desconectar

fisicamente a rede ou os cabos de energia não é recomendado como um
teste de vedação, pois não simula com precisão uma falha típica do mundo
real.
Bloquear o tráfego corosync tanto na entrada quanto na saída usando o firewall local.
83
O seguinte exemplo bloqueia a corosync, assumindo que a porta padrão corosync é usada,
firewalld é usado como firewall local, e a interface de rede usada pela corosync está na
zona padrão do firewall:
# firewall-cmd --direct --add-rule ipv4 filter OUTPUT 2 -p udp --dport=5405 -j DROP

# firewall-cmd --add-rich-rule='rule family="ipv4" port port="5405" protocol="udp"
drop'
Simule um acidente e entre em pânico com sua máquina com sysrq-trigger. Note,
entretanto, que desencadear um pânico no núcleo pode causar perda de dados; é
recomendável que você desative seus recursos de cluster primeiro.
# echo c > /proc/sysrq-trigger
9.6. CONFIGURAÇÃO DOS NÍVEIS DE VEDAÇÃO

O pacemaker suporta nós de vedação com múltiplos dispositivos através de uma característica
chamada topologias de vedação. Para implementar topologias, crie os dispositivos individuais como
você normalmente faria e então defina um ou mais níveis de vedação na seção de topologia de vedação
na configuração.
Cada nível é tentado em ordem numérica ascendente, começando em 1.
Se um dispositivo falhar, o processamento termina para o nível atual. Nenhum outro dispositivo
nesse nível é exercido e o próximo nível é tentado em seu lugar.
Se todos os dispositivos forem vedados com sucesso, então esse nível foi bem sucedido e
nenhum outro nível é tentado.
A operação é concluída quando um nível tiver passado (sucesso), ou quando todos os níveis
tiverem sido tentados (fracassados).
Use o seguinte comando para adicionar um nível de esgrima a um nó. Os dispositivos são dados como
uma lista separada por vírgula de ids de pedra, que são tentadas para o nó nesse nível.
pcs nível de pedra adicionar level node devices
O seguinte comando lista todos os níveis de vedação que estão configurados atualmente.
pcs nível de pedra
No exemplo a seguir, há dois dispositivos de cerca configurados para o nó rh7-2: um dispositivo de

cerca ilo chamado my_ilo e um dispositivo de cerca apc chamado my_apc. Estes comandos configuram
os níveis de cerca de modo que, se o dispositivo my_ilo falhar e não conseguir cercar o nó, então o
Pacemaker tentará usar o dispositivo my_apc. Este exemplo também mostra a saída do comando pcs
stonith level depois que os níveis são configurados.
# pcs stonith level add 1 rh7-2 my_ilo

# pcs stonith level add 2 rh7-2 my_apc
# pcs stonith level
Node: rh7-2
Level 1 - my_ilo
Level 2 - my_apc
84
O seguinte comando remove o nível da cerca para o nó e dispositivos especificados. Se nenhum nó ou

dispositivo for especificado, então o nível de cerca especificado será removido de todos os nós.
pcs stonith nível remover level [node_id] [stonith_id] ... [stonith_id]
O comando a seguir limpa os níveis da cerca no nó especificado ou na identificação da pedra. Se você

não especificar um nó ou id de pedra, todos os níveis da cerca são limpos.
pcs stonith level clear [node|stonith_id(s)]
Se você especificar mais de uma identificação de pedra, elas devem ser separadas por uma vírgula e
sem espaços, como no exemplo a seguir.
# pcs stonith level clear dev_a,dev_b
O seguinte comando verifica que todos os dispositivos e nós especificados nos níveis das cercas
existem.
pcs verificação de nível de pedra
Você pode especificar os nós na topologia da cerca por uma expressão regular aplicada sobre o nome
de um nó e por um atributo de nó e seu valor. Por exemplo, os seguintes comandos configuram os nós
node1, node2, e `node3 para usar dispositivos de cerca apc1 e àpc2, e os nós `node4, node5, e
`node6 para usar dispositivos de cerca apc3 e àpc4.
pcs stonith level add 1 "regexp%node[1-3]" apc1,apc2

pcs stonith level add 1 "regexp%node[4-6]" apc3,apc4
Os seguintes comandos produzem os mesmos resultados usando a correspondência de atributos de

nós.
pcs node attribute node1 rack=1

pcs stonith level add 1 attrib%rack=1 apc1,apc2
pcs stonith level add 1 attrib%rack=2 apc3,apc4
9.7. CONFIGURAÇÃO DE CERCAS PARA FONTES DE ALIMENTAÇÃO

REDUNDANTES
Ao configurar a vedação para fontes de alimentação redundantes, o cluster deve assegurar que ao
tentar reiniciar um host, ambas as fontes de alimentação sejam desligadas antes que qualquer uma delas
seja ligada novamente.
Se o nó nunca perder completamente a energia, o nó pode não liberar seus recursos. Isto abre a
possibilidade de os nós acessarem esses recursos simultaneamente e corrompê-los.
Você precisa definir cada dispositivo apenas uma vez e especificar que ambos são necessários para
cercar o nó, como no exemplo a seguir.
85
# pcs stonith create apc1 fence_apc_snmp ipaddr=apc1.example.com login=user

passwd='7a4D#1j!pz864' pcmk_host_map="node1.example.com:1;node2.example.com:2"
# pcs stonith create apc2 fence_apc_snmp ipaddr=apc2.example.com login=user

passwd='7a4D#1j!pz864' pcmk_host_map="node1.example.com:1;node2.example.com:2"
# pcs stonith level add 1 node1.example.com apc1,apc2

# pcs stonith level add 1 node2.example.com apc1,apc2
9.8. EXIBIÇÃO DE DISPOSITIVOS DE CERCAS CONFIGURADOS

O comando a seguir mostra todos os dispositivos de vedação atualmente configurados. Se for
especificado um stonith_id, o comando mostra as opções apenas para aquele dispositivo de pedra
configurado. Se a opção --full for especificada, todas as opções de pedra configuradas são exibidas.
pcs stonith config [stonith_id] [--full] [--full] [--full] [--full] [--full
9.9. MODIFICAÇÃO E ELIMINAÇÃO DE DISPOSITIVOS DE CERCAS

Use o seguinte comando para modificar ou adicionar opções a um dispositivo de esgrima configurado
atualmente.
pcs stonith update stonith_id [stonith_device_options]
Use o seguinte comando para remover um dispositivo de esgrima da configuração atual.
pcs stonith apagar stonith_id
9.10. ESGRIMA MANUAL DE UM NÓ DE CLUSTER

Você pode cercar um nó manualmente com o seguinte comando. Se você especificar --off, isto usará a
chamada API off para o Stonith, que desligará o nó em vez de reiniciá-lo.
pcs stonith fence node [--off]
Em uma situação em que nenhum dispositivo de pedra é capaz de cercar um nó mesmo que ele não
esteja mais ativo, o aglomerado pode não ser capaz de recuperar os recursos do nó. Se isto ocorrer,
após assegurar manualmente que o nó está desligado, você pode entrar com o seguinte comando para
confirmar ao aglomerado que o nó está desligado e liberar seus recursos para recuperação.

ATENÇÃO
Se o nó especificado não estiver realmente desligado, mas executando o software

ou serviços normalmente controlados pelo cluster, ocorrerá corrupção/falha de
cluster de dados.
86
pcs stonith confirmam node
9.11. DESATIVAÇÃO DE UM DISPOSITIVO DE CERCA

Para desativar um dispositivo/recurso de esgrima, você executa o comando pcs stonith disable.
O seguinte comando desabilita o dispositivo de vedação myapc.
# pcs stonith disable myapc
9.12. IMPEDIR QUE UM NÓ UTILIZE UM DISPOSITIVO DE VEDAÇÃO

Para evitar que um nó específico utilize um dispositivo de vedação, você pode configurar restrições de
localização para o recurso de vedação.
O seguinte exemplo impede que o dispositivo de vedação node1-ipmi funcione em node1.
# pcs constraint location node1-ipmi avoids node1
9.13. CONFIGURAÇÃO DO ACPI PARA USO COM DISPOSITIVOS DE

CERCAS INTEGRADAS
Se seu agrupamento utiliza dispositivos de vedação integrados, você deve configurar o ACPI (Advanced
Configuration and Power Interface) para garantir a vedação imediata e completa.
Se um nó de cluster for configurado para ser cercado por um dispositivo de cerca integrado, desabilite o
ACPI Soft-Off para esse nó. A desativação do ACPI Soft-Off permite que um dispositivo de cerca
integrado desligue um nó imediata e completamente ao invés de tentar um desligamento limpo (por
exemplo, shutdown -h now). Caso contrário, se o ACPI Soft-Off for ativado, um dispositivo de cerca
integrado pode levar quatro ou mais segundos para desligar um nó (veja a nota que se segue). Além
disso, se o ACPI Soft-Off estiver ativado e um nó entrar em pânico ou congelar durante o desligamento,
um dispositivo de cerca integrado pode não ser capaz de desligar o nó. Nessas circunstâncias, a vedação
é atrasada ou não tem êxito. Consequentemente, quando um nó é cercado com um dispositivo de cerca
integrado e o ACPI Soft-Off é habilitado, um aglomerado se recupera lentamente ou requer
intervenção administrativa para se recuperar.
NOTA
A quantidade de tempo necessária para cercar um nó depende do dispositivo de cerca

integrado utilizado. Alguns dispositivos de cerca integrados realizam o equivalente a
pressionar e segurar o botão de energia; portanto, o dispositivo de cerca desliga o nó em
quatro a cinco segundos. Outros dispositivos de cercas integradas executam o
equivalente a pressionar o botão de energia momentaneamente, contando com o sistema
operacional para desligar o nó; portanto, o dispositivo de cercas desliga o nó em um
período de tempo muito maior do que quatro a cinco segundos.
A maneira preferida de desativar o ACPI Soft-Off é alterar a configuração da BIOS para

"instant-off" ou uma configuração equivalente que desligue o nó sem demora, como descrito
em Seção 9.13.1, “Desabilitando o ACPI Soft-Off com o BIOS” .
A desativação do ACPI Soft-Off com o BIOS pode não ser possível com alguns sistemas. Se a
87
A desativação do ACPI Soft-Off com o BIOS pode não ser possível com alguns sistemas. Se a
desativação do ACPI Soft-Off com o BIOS não for satisfatória para seu cluster, você pode desativar o
ACPI Soft-Off com um dos seguintes métodos alternativos:
Configurando HandlePowerKey=ignore no arquivo /etc/systemd/logind.conf e verificando

que o nó do nó se desliga imediatamente quando cercado, como descrito em Seção 9.13.2,
“Desabilitando o ACPI Soft-Off no arquivo logind.conf”. Este é o primeiro método alternativo de
desativação do ACPI Soft-Off.
Anexando acpi=off à linha de comando de inicialização do kernel, conforme descrito em

Seção 9.13.3, “Desabilitando completamente o ACPI no arquivo GRUB 2” . Este é o segundo
método alternativo de desativação do ACPI Soft-Off, se o método preferido ou o primeiro
método alternativo não estiver disponível.
IMPORTANTE
Este método desabilita completamente o ACPI; alguns computadores não

inicializam corretamente se o ACPI estiver completamente desabilitado. Use este
método only se os outros métodos não forem eficazes para seu cluster.
9.13.1. Desabilitando o ACPI Soft-Off com o BIOS

Você pode desativar o ACPI Soft-Off configurando a BIOS de cada nó de cluster com o seguinte
procedimento.
NOTA
O procedimento para desativar o ACPI Soft-Off com o BIOS pode ser diferente entre os
sistemas de servidores. Você deve verificar este procedimento com sua documentação
de hardware.
1. Reiniciar o nó e iniciar o programa BIOS CMOS Setup Utility.
2. Navegue até o menu Poder (ou menu de gerenciamento de energia equivalente).
3. No menu Power, defina a função Soft-Off by PWR-BTTN (ou equivalente) para Instant-Off (ou
a configuração equivalente que desliga o nó por meio do botão Power sem demora). BIOS
CMOS Setup Utility: mostra um menu Power com ACPI Function defina para Enabled e Soft-
Off by PWR-BTTN defina para Instant-Off.
NOTA
Os equivalentes a ACPI Function, Soft-Off by PWR-BTTN, e Instant-Off podem

variar entre computadores. Entretanto, o objetivo deste procedimento é
configurar a BIOS para que o computador seja desligado sem demora por meio
do botão de ligar/desligar.
4. Sair do programa BIOS CMOS Setup Utility, salvando a configuração da BIOS.
5. Verificar se o nó se desliga imediatamente quando cercado. Para informações sobre como

BIOS CMOS Setup Utility:
88
`Soft-Off by PWR-BTTN` set to

Ìnstant-Off`
+---------------------------------------------|-------------------+
| ACPI Function [Enabled] | Item Help |
| ACPI Suspend Type [S1(POS)] |-------------------|
| x Run VGABIOS if S3 Resume Auto | Menu Level * |
| Suspend Mode [Disabled] | |
| HDD Power Down [Disabled] | |
| Soft-Off by PWR-BTTN [Instant-Off | |
| CPU THRM-Throttling [50.0%] | |
| Wake-Up by PCI card [Enabled] | |
| Power On by Ring [Enabled] | |
| Wake Up On LAN [Enabled] | |
| x USB KB Wake-Up From S3 Disabled | |
| Resume by Alarm [Disabled] | |
| x Date(of Month) Alarm 0 | |
| x Time(hh:mm:ss) Alarm 0: 0: | |
| POWER ON Function [BUTTON ONLY | |
| x KB Power ON Password Enter | |
| x Hot Key Power ON Ctrl-F1 | |
| | |
| | |
+---------------------------------------------|-------------------+
Este exemplo mostra ACPI Function set to Enabled, e Soft-Off by PWR-BTTN set to Instant-Off.
9.13.2. Desabilitando o ACPI Soft-Off no arquivo logind.conf

Para desativar a entrega da chave de alimentação no arquivo /etc/systemd/logind.conf, use o seguinte
procedimento.
1. Defina a seguinte configuração no arquivo /etc/systemd/logind.conf:
HandlePowerKey=ignore
2. Reinicie o serviço systemd-logind:
# systemctl restart systemd-logind.service

9.13.3. Desabilitando completamente o ACPI no arquivo GRUB 2

Você pode desativar o ACPI Soft-Off anexando acpi=off à entrada do menu GRUB para um kernel.
IMPORTANTE
Este método desabilita completamente o ACPI; alguns computadores não inicializam

corretamente se o ACPI estiver completamente desabilitado. Use este método only se os
outros métodos não forem eficazes para seu cluster.
89
Use o seguinte procedimento para desativar o ACPI no arquivo GRUB 2:
1. Use a opção --args em combinação com a opção --update-kernel da ferramenta grubby para
alterar o arquivo grub.cfg de cada nó de cluster da seguinte forma:
# grubby --args=acpi=off --update-kernel=ALL
2. Reiniciar o nó.

90
CAPÍTULO 10. CONFIGURAÇÃO DE RECURSOS DE CLUSTER

O formato do comando para criar um recurso de cluster é o seguinte:
pcs resource create resource_id [standard:[provider:]]type [resource_options] [op operation_action

operation_options [operation_action operation options ]...] [meta meta_options...] [clone
[clone_options] | master [master_options] | --group group_name [--before resource_id | --after
resource_id] | [bundle bundle_id] [--disabled] [--wait[=n]] [--wait[= ]]
As principais opções de criação de recursos de cluster incluem o seguinte:
Quando você especifica a opção --group, o recurso é adicionado ao grupo de recursos

nomeado. Se o grupo não existir, isto cria o grupo e adiciona este recurso ao grupo.
As opções --before e --after especificam a posição do recurso adicionado em relação a um

recurso que já existe em um grupo de recursos.
A especificação da opção --disabled indica que o recurso não é iniciado automaticamente.
Você pode determinar o comportamento de um recurso em um cluster, configurando restrições para

esse recurso.
Exemplos de criação de recursos

O seguinte comando cria um recurso com o nome VirtualIP da norma ocf, provedor heartbeat, e tipo
IPaddr2. O endereço flutuante deste recurso é 192.168.0.120, e o sistema verificará se o recurso está
funcionando a cada 30 segundos.
# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.120 cidr_netmask=24 op

monitor interval=30s
Alternativamente, você pode omitir os campos standard e provider e usar o seguinte comando. Isto será
padrão para um padrão de ocf e um provedor de heartbeat.
# pcs resource create VirtualIP IPaddr2 ip=192.168.0.120 cidr_netmask=24 op monitor

interval=30s
Eliminação de um recurso configurado

Use o seguinte comando para excluir um recurso configurado.
pcs resource delete resource_id
Por exemplo, o seguinte comando apaga um recurso existente com um ID de recurso de VirtualIP.
# pcs resource delete VirtualIP
10.1. IDENTIFICADORES DO AGENTE DE RECURSOS

Os identificadores que você define para um recurso dizem ao agrupamento qual agente usar para o
recurso, onde encontrar esse agente e quais padrões ele está em conformidade. Tabela 10.1, “Agente de
Identificação de Recursos”, descreve estas propriedades.
Tabela 10.1. Agente de Identificação de Recursos
91
Campo Descrição
padrão O padrão ao qual o agente está em conformidade. Os

valores permitidos e seu significado:
* ocf - O especificado type é o nome de um arquivo

executável em conformidade com o Open Cluster
Framework Resource Agent API e localizado abaixo
do /usr/lib/ocf/resource.d/provider
* lsb - O especificado type é o nome de um arquivo

executável em conformidade com as ações do Linux
Base Init Script. Se o tipo não especificar um caminho
completo, o sistema o procurará no diretório
/etc/init.d.
* systemd - O especificado type é o nome de uma

unidade systemd instalada
* service - Pacemaker procurará o especificado

type, primeiro como um agentelsb, depois como um
agente systemd
* nagios - O type especificado é o nome de um

arquivo executável conforme a API do Nagios Plugin
API e localizado no diretório
/usr/libexec/nagios/plugins, com metadados no
estilo OCF armazenados separadamente no diretório
/usr/share/nagios/plugins-metadata (disponível
no pacote nagios-agents-metadata para certos
plugins comuns).
tipo O nome do agente de recursos que você deseja

utilizar, por exemplo IPaddr ou Filesystem
fornecedor A especificação OCF permite que vários

fornecedores forneçam o mesmo agente de
recursos. A maioria dos agentes enviados pela Red
Hat usa heartbeat como fornecedor.
Tabela 10.2, “Comandos para exibir as propriedades dos recursos” resume os comandos que exibem as
propriedades dos recursos disponíveis.
Tabela 10.2. Comandos para exibir as propriedades dos recursos
pcs Display Command Saída
pcs resource list Exibe uma lista de todos os recursos disponíveis.
pcs resource standards Exibe uma lista de padrões de agentes de recursos

disponíveis.
92
pcs Display Command Saída
pcs resource providers Exibe uma lista de fornecedores de agentes de

recursos disponíveis.
pcs resource list string Exibe uma lista dos recursos disponíveis filtrados pela
seqüência especificada. Você pode usar este
comando para exibir recursos filtrados pelo nome de
um padrão, de um provedor ou de um tipo.
10.2. EXIBIÇÃO DE PARÂMETROS ESPECÍFICOS DE RECURSOS

Para qualquer recurso individual, você pode usar o seguinte comando para exibir uma descrição do
recurso, os parâmetros que você pode definir para aquele recurso e os valores padrão que são definidos
para o recurso.
pcs resource describe [standard:[provider:]]type
Por exemplo, o seguinte comando exibe informações para um recurso do tipo apache.
# pcs resource describe ocf:heartbeat:apache

This is the resource agent for the Apache Web server.
This resource agent operates both version 1.x and version 2.x Apache
servers.
...
10.3. CONFIGURANDO AS META OPÇÕES DE RECURSOS

Além dos parâmetros específicos do recurso, você pode configurar opções adicionais de recursos para
qualquer recurso. Estas opções são usadas pelo cluster para decidir como seu recurso deve se
comportar.
Tabela 10.3, “Meta Opções de Recursos” descreve as meta opções de recursos.
Tabela 10.3. Meta Opções de Recursos
93
C Padrão D
a e
m s
p c
o r
i
ç
ã
o
p 0 S
r e
i n
o e
r m
i t
t o
y d
o
s
o
s
r
e
c
u
r
s
o
s
p
u
d
e
r
e
m
e
s
t
a
r
a
t
i
v
o
s
,
o
a
g
r
u
p
94
a
C Padrão Dm
a ee
m sn
p ct
o ro
ip
ça
ãr
oa
r
á
o
s
r
e
c
u
r
s
o
s
d
e
p
r
i
o
r
i
d
a
d
e
m
a
i
s
b
a
i
x
a
p
a
r
a
m
a
n
t
e
r
o
s
d
95
e
C Padrão Dp
a er
m si
p co
o rr
ii
çd
ãa
od
e
m
a
i
s
a
l
t
a
a
t
i
v
o
s
.
t Started E
a m
r q
g u
e e
t e
- s
r t
o a
l d
e o
o
a
g
r
u
p
a
m
e
n
t
o
d
e
v
e
t
e
96
n
C Padrão Dt
a ea
m sr
p cm
o ra
in
çt
ãe
or
e
s
t
e
r
e
c
u
r
s
o
?
V
a
l
o
r
e
s
p
e
r
m
i
t
i
d
o
s
:
*
S
t
o
p
p
e
d
-
F
o
r
ç
a
r
97
o
C Padrão Dr
a ee
m sc
p cu
o rr
is
ço
ãa
os
e
r
p
a
r
a
d
o
*
S
t
a
r
t
e
d
-
P
e
r
m
i
t
i
r
q
u
e
o
r
e
c
u
r
s
o
s
e
j
a
i
n
i
c
i
98
a
C Padrão Dd
a eo
m s(
p ce
o rn
io
çc
ãa
os
o
d
e
c
l
o
n
e
s
p
r
o
m
o
v
í
v
e
i
s
,
p
r
o
m
o
v
i
d
o
s
p
a
r
a
d
o
m
i
n
a
r
o
p
a
p
99
e
C Padrão Dl
a e,
m ss
p ce
o ra
ip
çr
ão
op
r
i
a
d
o
)
*
M
a
s
t
e
r
-
P
e
r
m
i
t
i
r
q
u
e
o
r
e
c
u
r
s
o
s
e
j
a
i
n
i
c
i
a
d
o
100
e
C Padrão D,
a es
m se
p ca
o rp
ir
ço
ãp
or
i
a
d
o
,
p
r
o
m
o
v
i
d
o
*
S
l
a
v
e
-
P
e
r
m
i
t
i
r
q
u
e
o
r
e
c
u
r
s
o
s
e
j
a
i
101
n
C Padrão Di
a ec
m si
p ca
o rd
io
ç,
ãm
oa
s
s
o
m
e
n
t
e
n
o
m
o
d
o
E
s
c
r
a
v
o
,
s
e
o
r
e
c
u
r
s
o
f
o
r
p
r
o
m
o
c
i
o
n
a
l
102
C Padrão D
a e
m s
p c
i true É
o r
s p
i
- e
ç
m r
ã
a m
o
n i
a t
g i
e d
d o
q
u
e
o
a
g
r
u
p
a
m
e
n
t
o
c
o
m
e
c
e
e
p
a
r
e
o
r
e
c
u
r
s
o
?
V
a
l
o
r
e
s
103
p
C Padrão De
a er
m sm
p ci
o rt
ii
çd
ão
os
:
t
r
u
e
,
f
a
l
s
e
104
C Padrão D
a e
m s
p c
o r
i
ç
ã
o
r 0 V
e a
s l
o o
u r
r p
c a
e r
- a
s i
t n
i d
c i
k c
i a
n r
e o
s q
s u
a
n
t
o
o
r
e
c
u
r
s
o
p
r
e
f
e
r
e
f
i
c
a
r
o
n
105
d
C Padrão De
a ee
m ss
p ct
o rá
i.
ç
ã
o
r Calculado I
e n
q d
u i
i c
r a
e s
s o
b
q
u
a
i
s
c
o
n
d
i
ç
õ
e
s
o
r
e
c
u
r
s
o
p
o
d
e
s
e
r
i
n
i
c
i
a
106
d
C Padrão Do
a e.
m s
p cO
o rp
ia
çd
ãr
oã
o
é
f
e
n
c
i
n
g
,
e
x
c
e
t
o
s
o
b
a
s
c
o
n
d
i
ç
õ
e
s
a
b
a
i
x
o
m
e
n
c
i
o
n
a
d
a
107
s
C Padrão D.
a eV
m sa
p cl
o ro
ir
çe
ãs
op
o
s
s
í
v
e
i
s
:
*
n
o
t
h
i
n
g
-
O
a
g
r
u
p
a
m
e
n
t
o
p
o
d
e
s
e
m
p
r
e
i
n
i
c
i
108
a
C Padrão Dr
a eo
m sr
p ce
o rc
iu
çr
ãs
oo
.
*
q
u
o
r
u
m
-
O
c
l
u
s
t
e
r
s
ó
p
o
d
e
i
n
i
c
i
a
r
e
s
t
e
r
e
c
u
r
s
o
s
e
a
m
109
a
C Padrão Di
a eo
m sr
p ci
o ra
id
ço
ãs
on
ó
s
c
o
n
f
i
g
u
r
a
d
o
s
e
s
t
i
v
e
r
a
t
i
v
a
.
E
s
t
e
é
o
v
a
l
o
r
p
a
d
r
ã
o
s
e
110
s
C Padrão Dt
a eo
m sn
p ci
o rt
ih
ç-
ãe
on
a
b
l
e
d
f
o
r
f
a
l
s
e
o
u
s
e
o
r
e
c
u
r
s
o
s
t
a
n
d
a
r
d
f
o
r
s
t
o
n
i
t
h
.
111
f
C Padrão De
a en
m sc
p ci
o rn
ig
ç-
ãO
oc
l
u
s
t
e
r
s
ó
p
o
d
e
i
n
i
c
i
a
r
e
s
t
e
r
e
c
u
r
s
o
s
e
a
m
a
i
o
r
i
a
d
o
s
n
ó
s
112
c
C Padrão Do
a en
m sf
p ci
o rg
iu
çr
ãa
od
o
s
e
s
t
i
v
e
r
a
t
i
v
a
a
n
d
q
u
a
l
q
u
e
r
n
ó
f
a
l
h
a
d
o
o
u
d
e
s
c
o
n
h
e
c
i
113
d
C Padrão Do
a ef
m so
p ci
o rc
ie
çr
ãc
oa
d
o
.
*
u
n
f
e
n
c
i
n
g
-
O
c
l
u
s
t
e
r
s
ó
p
o
d
e
i
n
i
c
i
a
r
e
s
t
e
r
e
c
u
r
s
114
o
C Padrão Ds
a ee
m sa
p cm
o ra
ii
ço
ãr
oi
a
d
o
s
n
ó
s
c
o
n
f
i
g
u
r
a
d
o
s
e
s
t
i
v
e
r
a
t
i
v
a
a
n
d
q
u
a
l
q
u
e
r
n
ó
f
a
115
l
C Padrão Dh
a ea
m sd
p co
o ro
iu
çd
ãe
os
c
o
n
h
e
c
i
d
o
f
o
i
c
e
r
c
a
d
o
a
n
d
s
o
m
e
n
t
e
e
m
n
ó
s
q
u
e
t
e
n
h
a
m
s
i
d
116
o
C Padrão Du
a en
m sf
p ce
o rn
ic
çe
ãd
o.
E
s
t
e
é
o
v
a
l
o
r
p
a
d
r
ã
o
s
e
a
m
e
t
a
o
p
ç
ã
o
p
r
o
v
i
d
e
s
=
u
n
f
e
n
c
i
n
117
g
C Padrão Ds
a et
m so
p cn
o ri
it
çh
ãt
oi
v
e
r
s
i
d
o
c
o
n
f
i
g
u
r
a
d
a
p
a
r
a
u
m
d
i
s
p
o
s
i
t
i
v
o
d
e
e
s
g
r
i
m
a
.
118
C Padrão D
a e
m INFINITY Q
m s
i u
p c
g a
o r
r n
i
a t
ç
t a
ã
i s
o
o f
n a
- l
t h
h a
r s
e p
s o
h d
o e
l m
d o
c
o
r
r
e
r
p
a
r
a
e
s
t
e
r
e
c
u
r
s
o
e
m
u
m
n
ó
,
a
n
t
e
s
q
u
119
e
C Padrão De
a es
m st
p ce
o rn
ió
çs
ãe
oj
a
m
a
r
c
a
d
o
c
o
m
o
i
n
e
l
e
g
í
v
e
l
p
a
r
a
h
o
s
p
e
d
a
r
e
s
t
e
r
e
c
u
r
s
o
.
120
U
C Padrão Dm
a ev
m sa
p cl
o ro
ir
çd
ãe
o0
i
n
d
i
c
a
q
u
e
e
s
t
e
r
e
c
u
r
s
o
e
s
t
á
d
e
s
a
b
i
l
i
t
a
d
o
(
o
n
ó
n
u
n
c
a
s
121
e
C Padrão Dr
a eá
m sm
p ca
o rr
ic
ça
ãd
oo
c
o
m
o
i
n
e
l
e
g
í
v
e
l
)
;
e
m
c
o
n
t
r
a
s
t
e
,
o
c
l
u
s
t
e
r
t
r
a
t
a
I
N
F
I
N
122
I
C Padrão DT
a eY
m s(
p co
o rp
ia
çd
ãr
oã
o
)
c
o
m
o
u
m
n
ú
m
e
r
o
m
u
i
t
o
g
r
a
n
d
e
,
m
a
s
f
i
n
i
t
o
.
E
s
t
a
o
p
ç
ã
o
s
123
ó
C Padrão Dt
a ee
m sm
p ce
o rf
ie
çi
ãt
oo
s
e
a
o
p
e
r
a
ç
ã
o
f
a
l
h
a
d
a
t
i
v
e
r
o
n
-
f
a
i
l
=
r
e
s
t
a
r
t
(
o
p
a
d
r
ã
o
124
)
C Padrão D,
a ee
m sa
p cd
o ri
ic
çi
ão
on
a
l
m
e
n
t
e
p
a
r
a
o
p
e
r
a
ç
õ
e
s
d
e
i
n
í
c
i
o
f
a
l
h
a
d
a
s
s
e
a
p
r
o
p
r
i
e
125
d
C Padrão Da
a ed
m se
p cd
o ro
ic
çl
ãu
os
t
e
r
s
t
a
r
t
-
f
a
i
l
u
r
e
-
i
s
-
f
a
t
a
l
f
o
r
f
a
l
s
e
.
f 0 (desativado) U
a s
i a
l d
u o
r e
e m
- c
t o
i n
126
m j
C
e Padrão Du
a
o en
m
u st
tp co
o rc
io
çm
ãa
oo
p
ç
ã
o
m
i
g
r
a
t
i
o
n
-
t
h
r
e
s
h
o
l
d
,
i
n
d
i
c
a
q
u
a
n
t
o
s
s
e
g
u
n
d
o
s
e
127
s
C Padrão Dp
a ee
m sr
p ca
o rr
ia
çn
ãt
oe
s
d
e
a
g
i
r
c
o
m
o
s
e
a
f
a
l
h
a
n
ã
o
t
i
v
e
s
s
e
o
c
o
r
r
i
d
o
,
e
p
o
t
e
n
c
i
128
a
C Padrão Dl
a em
m se
p cn
o rt
ie
çp
ãe
or
m
i
t
i
r
q
u
e
o
r
e
c
u
r
s
o
v
o
l
t
e
a
o
n
ó
e
m
q
u
e
f
a
l
h
o
u
.
C
o
m
o
e
m
q
u
a
129
l
C Padrão Dq
a eu
m se
p cr
o ra
iç
çã
ão
ob
a
s
e
a
d
a
n
o
t
e
m
p
o
,
n
ã
o
é
g
a
r
a
n
t
i
d
o
q
u
e
i
s
t
o
s
e
j
a
v
e
r
i
f
i
c
a
130
d
C Padrão Do
a ec
m so
p cm
o rm
ia
çi
ãs
of
r
e
q
ü
ê
n
c
i
a
d
o
q
u
e
o
v
a
l
o
r
d
o
p
a
r
â
m
e
t
r
o
d
e
c
l
u
s
t
e
r
c
l
u
s
t
e
131
r
C Padrão D-
a er
m se
p cc
o rh
ie
çc
ãk
o-
i
n
t
e
r
v
a
l
.
m stop_start O
u q
l u
t e
i o
p a
l g
e r
- u
a p
c a
t m
i e
v n
e t
o
d
e
v
e
f
a
z
e
r
s
e
a
l
g
u
m
a
v
e
z
e
132
n
C Padrão Dc
a eo
m sn
p ct
o rr
ia
çr
ão
or
e
c
u
r
s
o
a
t
i
v
o
e
m
m
a
i
s
d
e
u
m
n
ó
.
V
a
l
o
r
e
s
p
e
r
m
i
t
i
d
o
s
:
*
b
l
133
o
C Padrão Dc
a ek
m s-
p cm
o ra
ir
çc
ãa
or
o
r
e
c
u
r
s
o
c
o
m
o
n
ã
o
a
d
m
i
n
i
s
t
r
a
d
o
*
s
t
o
p
_
o
n
l
y
-
p
a
r
a
r
t
o
134
d
C Padrão Da
a es
m sa
p cs
o ri
in
çs
ãt
oâ
n
c
i
a
s
a
t
i
v
a
s
e
d
e
i
x
á
-
l
a
s
d
e
s
s
a
f
o
r
m
a
*
s
t
o
p
_
s
t
a
r
t
-
p
a
135
r
C Padrão Da
a er
m st
p co
o rd
ia
çs
ãa
os
i
n
s
t
â
n
c
i
a
s
a
t
i
v
a
s
e
i
n
i
c
i
a
r
o
r
e
c
u
r
s
o
e
m
u
m
ú
n
i
c
o
l
o
c
a
l
136
C Padrão D
a e
10.3.1. Alterando o valor padrão de uma opção de recurso
m s
A ppartir do Red Hat Enterprise Linux 8.3, você pode alterar o valor default de uma opção de recurso c
o todos os recursos com o comando pcs resource defaults update. O seguinte comando redefiner o
para
valor default de resource-stickiness para 100. i
ç
ã
# pcs resource defaults update resource-stickiness=100
o
O original pcs resource defaults name=value que define os padrões para todos os recursos em
versões anteriores do RHEL 8, continua sendo suportado, a menos que haja mais de um conjunto de
padrões configurado. Entretanto, pcs resource defaults update é agora a versão preferida do
comando.
10.3.2. Alteração do valor padrão de uma opção de recurso para conjuntos de

recursos (RHEL 8.3 e posteriores)
A partir do Red Hat Enterprise Linux 8.3, você pode criar múltiplos conjuntos de padrões de recursos
com o comando pcs resource defaults set create, o que lhe permite especificar uma regra que contém
expressões resource. Apenas as expressões resource, incluindo and, or e parênteses, são permitidas
nas regras que você especificar com este comando.
Com o comando pcs resource defaults set create, você pode configurar um valor de recurso padrão
para todos os recursos de um determinado tipo. Se, por exemplo, você estiver rodando bancos de dados
que levam muito tempo para parar, você pode aumentar o valor padrão resource-stickiness para
todos os recursos do tipo banco de dados para evitar que esses recursos se movam para outros nós com
mais freqüência do que você deseja.
O seguinte comando define o valor padrão de resource-stickiness para 100 para todos os recursos do
tipo pqsql.
A opção id, que nomeia o conjunto de padrões de recursos, não é obrigatória. Se você não
definir esta opção pcs irá gerar uma identificação automaticamente. A definição deste valor
permite que você forneça um nome mais descritivo.
Neste exemplo, ::pgsql significa um recurso de qualquer classe, de qualquer fornecedor, do

tipo pgsql.
Especificar ocf:heartbeat:pgsql indicaria a classe ocf, fornecedor heartbeat, tipo pgsql,
Especificar ocf:pacemaker: indicaria todos os recursos da classe ocf, fornecedor

pacemaker, de qualquer tipo.
# pcs resource defaults set create id=pgsql-stickiness meta resource-stickiness=100 rule

resource ::pgsql
Para alterar os valores padrão em um conjunto existente, use o comando pcs resource defaults set
update.
10.3.3. Exibição dos padrões de recursos configurados atualmente

O comando pcs resource defaults exibe uma lista de valores padrão configurados atualmente para
opções de recursos, incluindo quaisquer regras que você especificou.
O exemplo a seguir mostra a saída deste comando após você ter redefinido o valor padrão de resource-
137
O exemplo a seguir mostra a saída deste comando após você ter redefinido o valor padrão de resource-
stickiness para 100.
# pcs resource defaults

Meta Attrs: rsc_defaults-meta_attributes
resource-stickiness=100
O exemplo a seguir mostra a saída deste comando após ter redefinido o valor padrão de resource-
stickiness para 100 para todos os recursos do tipo pqsql e ajustado a opção id para id=pgsql-
stickiness.
# pcs resource defaults

Meta Attrs: pgsql-stickiness
resource-stickiness=100
Rule: boolean-op=and score=INFINITY
Expression: resource ::pgsql
10.3.4. Definição de meta opções na criação de recursos

Quer você tenha redefinido ou não o valor padrão de uma meta opção de recurso, você pode definir
uma opção de recurso para um determinado recurso para um valor diferente do padrão quando você
criar o recurso. O seguinte mostra o formato do comando pcs resource create que você usa ao
especificar um valor para uma meta opção de recurso.
pcs resource create resource_id [standard:[provider:]]type [resource options] [meta meta_options...]
Por exemplo, o seguinte comando cria um recurso com um valor resource-stickiness de 50.
# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.120 meta resource-

stickiness=50
Você também pode definir o valor de uma meta opção de recurso para um recurso existente, grupo, ou
recurso clonado com o seguinte comando.
pcs resource meta resource_id | group_id | clone_id meta_options
No exemplo a seguir, há um recurso existente chamado dummy_resource. Este comando coloca a

meta opção failure-timeout em 20 segundos, para que o recurso possa tentar reiniciar no mesmo nó em
20 segundos.
# pcs resource meta dummy_resource failure-timeout=20s
Após executar este comando, você pode exibir os valores do recurso para verificar se failure-
timeout=20s está configurado.
# pcs resource config dummy_resource

Resource: dummy_resource (class=ocf provider=heartbeat type=Dummy)
Meta Attrs: failure-timeout=20s
...
10.4. CONFIGURAÇÃO DE GRUPOS DE RECURSOS
138
localizados juntos, começar sequencialmente e parar na ordem inversa. Para simplificar esta
configuração, o Pacemaker apóia o conceito de grupos de recursos.
10.4.1. Criação de um grupo de recursos

Você cria um grupo de recursos com o seguinte comando, especificando os recursos a serem incluídos
no grupo. Se o grupo não existir, este comando cria o grupo. Se o grupo existir, este comando adiciona
recursos adicionais ao grupo. Os recursos começarão na ordem que você os especificar com este
comando, e pararão na ordem inversa de sua ordem inicial.
pcs resource group acrescentar group_name resource_id [resource_id] ... [resource_id] [- antes
resource_id | - depois resource_id]
Você pode usar as opções --before e --after deste comando para especificar a posição dos recursos
adicionados em relação a um recurso que já existe no grupo.
Você também pode adicionar um novo recurso a um grupo existente quando você criar o recurso,
usando o seguinte comando. O recurso que você cria é adicionado ao grupo chamado group_name. Se o
grupo group_name não existir, ele será criado.
pcs resource create resource_id [standard:[provider:]]type [resource_options] [op operation_action

operation_options ] --group group_name
Não há limite para o número de recursos que um grupo pode conter. As propriedades fundamentais de
um grupo são as seguintes.
Os recursos são agrupados dentro de um grupo.
Os recursos são iniciados na ordem em que você os especifica. Se um recurso do grupo não
puder funcionar em nenhum lugar, então nenhum recurso especificado após esse recurso é
permitido para funcionar.
Os recursos são interrompidos na ordem inversa na qual você os especifica.
O exemplo seguinte cria um grupo de recursos chamado shortcut que contém os recursos existentes
IPaddr e Email.
# pcs resource group add shortcut IPaddr Email
Neste exemplo:
O IPaddr é iniciado primeiro, depois Email.
O recurso Email é interrompido primeiro, depois IPAddr.
Se IPaddr não pode funcionar em qualquer lugar, também não pode Email.
Se Email não puder funcionar em nenhum lugar, no entanto, isso não afeta de forma alguma
IPaddr.
10.4.2. Remoção de um grupo de recursos

Você remove um recurso de um grupo com o seguinte comando. Se não houver recursos restantes no
grupo, este comando remove o próprio grupo.
139
pcs resource group remove group_name resource_id ...
10.4.3. Exibição de grupos de recursos

O seguinte comando lista todos os grupos de recursos atualmente configurados.
lista de grupos de recursos pcs
10.4.4. Opções de grupo

Você pode definir as seguintes opções para um grupo de recursos e elas mantêm o mesmo significado
que quando são definidas para um único recurso: priority, target-role, is-managed. Para obter
informações sobre as meta opções de recursos, consulte Configurando as meta opções de recursos .
10.4.5. Adesividade do grupo

A viscosidade, a medida de quanto um recurso quer ficar onde está, é aditiva em grupos. Cada recurso
ativo do grupo contribuirá com seu valor de pegajosidade para o total do grupo. Portanto, se o padrão
resource-stickiness é 100, e um grupo tem sete membros, dos quais cinco são ativos, então o grupo
como um todo preferirá sua localização atual com uma pontuação de 500.
10.5. DETERMINANDO O COMPORTAMENTO DOS RECURSOS

Você pode determinar o comportamento de um recurso em um cluster, configurando restrições para
esse recurso. Você pode configurar as seguintes categorias de restrições:
location restrições
order restrições
colocation restrições
Como abreviação para configurar um conjunto de restrições que irá localizar um conjunto de recursos
em conjunto e garantir que os recursos comecem sequencialmente e parem em ordem inversa, a
Pacemaker apóia o conceito de grupos de recursos. Após ter criado um grupo de recursos, você pode
configurar restrições no próprio grupo, assim como configurar restrições para recursos individuais. Para
obter informações sobre grupos de recursos, consulte Configuração de grupos de recursos .
140
CAPÍTULO 11. DETERMINAÇÃO DOS NÓS EM QUE UM RECURSO PODE FUNCIONAR
CAPÍTULO 11. DETERMINAÇÃO DOS NÓS EM QUE UM

RECURSO PODE FUNCIONAR
As restrições de localização determinam em quais nós um recurso pode funcionar. Você pode configurar
as restrições de localização para determinar se um recurso preferirá ou evitará um nó especificado.
Além das restrições de localização, o nó em que um recurso funciona é influenciado pelo valor
resource-stickiness para esse recurso, que determina até que ponto um recurso prefere permanecer
no nó em que está funcionando atualmente. Para informações sobre como definir o valor resource-
stickiness, consulte Configurando um recurso para preferir seu nó atual .
11.1. CONFIGURAÇÃO DAS RESTRIÇÕES DE LOCALIZAÇÃO

Você pode configurar uma restrição básica de localização para especificar se um recurso prefere ou
evita um nó, com um valor opcional score para indicar o grau relativo de preferência pela restrição.
O seguinte comando cria uma restrição de localização para que um recurso prefira o nó ou nós
especificados. Note que é possível criar restrições em um determinado recurso para mais de um nó com
um único comando.
pcs constraint location rsc prefere node[=score] [node[=score]] ...
O seguinte comando cria uma restrição de localização para um recurso para evitar o nó ou nós
especificados.
pcs constraint location rsc evita node[=score] [node[=score]] ...
Tabela 11.1, “Opções de restrição de localização” resume os significados das opções básicas para a
configuração das restrições de localização.
Tabela 11.1. Opções de restrição de localização
Campo Descrição
rsc Um nome de recurso
node O nome de um nó
141
Campo Descrição
score Valor inteiro positivo para indicar o grau de

preferência para se o recurso dado deve preferir ou
evitar o nó dado. INFINITY é o valor padrão score
para uma restrição de localização de recurso.
Um valor de INFINITY para score em um pcs

contraint location rsc prefers indica que o
recurso preferirá aquele nó se o nó estiver disponível,
mas não impede que o recurso funcione em outro nó
se o nó especificado estiver indisponível.
Um valor de INFINITY para score em um pcs

contraint location rsc avoids indica que o
recurso nunca irá funcionar naquele nó, mesmo que
nenhum outro nó esteja disponível. Isto é o
equivalente a definir um comando pcs constraint
location add com uma pontuação de-INFINITY.
Uma pontuação numérica (ou seja, não INFINITY)

significa que a restrição é opcional, e será honrada a
menos que algum outro fator a ultrapasse. Por
exemplo, se o recurso já estiver colocado em um nó
diferente, e sua pontuação resource-stickiness
for superior à pontuação de uma restrição de
localização prefers, então o recurso será deixado
onde está.
O seguinte comando cria uma restrição de localização para especificar que o recurso Webserver
prefere o nó node1.
pcs constraint location Webserver prefere o nó1
pcs suporta expressões regulares em restrições de localização na linha de comando. Estas restrições se
aplicam a múltiplos recursos com base na expressão regular que corresponde ao nome do recurso. Isto
permite que você configure contrações de múltiplas localizações com uma única linha de comando.
O seguinte comando cria uma restrição de localização para especificar que os recursos dummy0 a
dummy9 preferem node1.
pcs constraint location 'regexpmmy[0-9]' prefere o nó1
Como a Pacemaker usa expressões regulares estendidas POSIX, conforme documentado em

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04você pode
especificar a mesma restrição com o seguinte comando.
pcs constraint location 'regexpmmy[[:digit:]]' prefere o nó1
11.2. LIMITANDO A DESCOBERTA DE RECURSOS A UM

142
11.2. LIMITANDO A DESCOBERTA DE RECURSOS A UM

SUBCONJUNTO DE NÓS
Antes que o Pacemaker inicie um recurso em qualquer lugar, ele primeiro executa uma única operação
de monitoramento (freqüentemente chamada de "sonda") em cada nó, para saber se o recurso já está
funcionando. Este processo de descoberta de recursos pode resultar em erros nos nós que são
incapazes de executar o monitor.
Ao configurar uma restrição de localização em um nó, você pode usar a opção resource-discovery do
comando pcs constraint location para indicar se a Pacemaker deve realizar a descoberta de recursos
neste nó para o recurso especificado. Limitar a descoberta de recursos a um subconjunto de nós em que
o recurso é fisicamente capaz de funcionar pode aumentar significativamente o desempenho quando
um grande conjunto de nós está presente. Quando pacemaker_remote estiver em uso para expandir a
contagem do nó para a faixa de centenas de nós, esta opção deve ser considerada.
O seguinte comando mostra o formato para especificar a opção resource-discovery do comando pcs
constraint location. Neste comando, um valor positivo para score corresponde a uma restrição de
localização básica que configura um recurso para preferir um nó, enquanto um valor negativo para score
corresponde a uma restrição de localização básica`constraint que configura um recurso para evitar um
nó. Assim como as restrições básicas de localização, você pode usar expressões regulares para recursos
com estas restrições também.
pcs constraint location add id rsc node score [resource-discovery=option]
Tabela 11.2, “Parâmetros de Restrição de Descoberta de Recursos” resume os significados dos

parâmetros básicos para a configuração de restrições para a descoberta de recursos.
Tabela 11.2. Parâmetros de Restrição de Descoberta de Recursos
Campo Descrição
id Um nome escolhido pelo usuário para a restrição em si.
rsc Um nome de recurso
node O nome de um nó
143
score Valor inteiro para indicar o grau de preferência para se o recurso

dado deve preferir ou evitar o nó dado. Um valor positivo para
pontuação corresponde a uma restrição básica de localização
que configura um recurso para preferir um nó, enquanto um
valor negativo para pontuação corresponde a uma restrição
básica de localização que configura um recurso para evitar um
nó.
Um valor de INFINITY para score indica que o recurso preferirá

esse nó se o nó estiver disponível, mas não impede que o
recurso funcione em outro nó se o nó especificado não estiver
disponível. Um valor de -INFINITY para score indica que o
recurso nunca funcionará naquele nó, mesmo se nenhum outro
nó estiver disponível.
Uma pontuação numérica (ou seja, não INFINITY ou -

INFINITY) significa que a restrição é opcional, e será honrada a
menos que algum outro fator a supere. Por exemplo, se o
recurso já estiver colocado em um nó diferente, e sua pontuação
resource-stickiness for superior à pontuação de uma
restrição de localização prefers, então o recurso será deixado
onde está.
resource-discovery opções * always - Sempre realize a descoberta de recursos para o

recurso especificado neste nó. Este é o valor padrão resource-
discovery para uma restrição de localização de recurso.
* never - Nunca realize a descoberta de recursos para o recurso

especificado neste nó.
* exclusive - Realizar a descoberta de recursos para o recurso

especificado somente neste nó (e outros nós marcados de
forma semelhante como exclusive). Restrições de localização
múltipla usando exclusive descoberta para o mesmo recurso
em diferentes nós cria um subconjunto de nós resource-
discovery é exclusivo para. Se um recurso estiver marcado para
exclusive descoberta em um ou mais nós, esse recurso só
poderá ser colocado dentro desse subconjunto de nós.

ATENÇÃO
O ajuste resource-discovery para never ou exclusive remove a capacidade da

Pacemaker de detectar e parar instâncias indesejadas de um serviço em execução
onde ele não deveria estar. Cabe ao administrador do sistema certificar-se de que o
serviço nunca poderá estar ativo em nós sem a descoberta de recursos (por
exemplo, deixando o software relevante desinstalado).
144
11.3. CONFIGURAÇÃO DE UMA ESTRATÉGIA DE RESTRIÇÃO DE

LOCALIZAÇÃO
Ao utilizar restrições de localização, você pode configurar uma estratégia geral para especificar em
quais nós um recurso pode funcionar:
Aglomerados de Opt-In
Aglomerados de Opt-Out
A escolha de configurar seu cluster como um cluster opt-in ou opt-out depende tanto de sua
preferência pessoal quanto da composição de seu cluster. Se a maioria de seus recursos puder
funcionar na maioria dos nós, então uma configuração opt-out provavelmente resultará em uma
configuração mais simples. Por outro lado, se a maioria dos recursos só pode funcionar em um pequeno
subconjunto de nós, uma configuração opt-in pode ser mais simples.
11.3.1. Configuração de um Cluster "Opt-In

Para criar um cluster opt-in, defina a propriedade do cluster symmetric-cluster para false para evitar
que os recursos funcionem em qualquer lugar por padrão.
# pcs property set symmetric-cluster=false
Habilitar os nós para os recursos individuais. Os seguintes comandos configuram restrições de

localização para que o recurso Webserver prefira o nó example-1, o recurso Database prefira o nó
example-2, e ambos os recursos podem falhar em relação ao nó example-3 se seu nó preferido falhar.
Ao configurar as restrições de localização para um cluster opt-in, definir uma pontuação zero permite
que um recurso seja executado em um nó sem indicar qualquer preferência para preferir ou evitar o nó.
# pcs constraint location Webserver prefers example-1=200

# pcs constraint location Database prefers example-2=200
11.3.2. Configuração de um Cluster "Opt-Out"

Para criar um cluster opt-out, defina a propriedade do cluster symmetric-cluster para true para
permitir que os recursos funcionem em todos os lugares por padrão. Esta é a configuração padrão se
symmetric-cluster não for definido explicitamente.
# pcs property set symmetric-cluster=true
Os seguintes comandos produzirão então uma configuração que é equivalente ao exemplo em

Seção 11.3.1, “Configuração de um Cluster "Opt-In” . Ambos os recursos podem falhar no nó example-3
se seu nó preferido falhar, uma vez que cada nó tem uma pontuação implícita de 0.

# pcs constraint location Webserver avoids example-2=INFINITY
# pcs constraint location Database avoids example-1=INFINITY
Note que não é necessário especificar uma pontuação de INFINIDADE nestes comandos, já que esse é
o valor padrão para a pontuação.
145
11.4. CONFIGURAÇÃO DE UM RECURSO PARA PREFERIR SEU NÓ

ATUAL
Os recursos têm um valor resource-stickiness que você pode definir como meta atributo ao criar o
recurso, conforme descrito em Configurando as meta opções de recursos . O valor resource-stickiness
determina o quanto um recurso quer permanecer no nó onde está rodando atualmente. O Pacemaker
considera o valor resource-stickiness em conjunto com outras configurações (por exemplo, os valores
de pontuação das restrições de localização) para determinar se um recurso deve ser movido para outro
nó ou se deve ser deixado no lugar.
Por padrão, um recurso é criado com um valor resource-stickiness de 0. O comportamento padrão do

Pacemaker quando resource-stickiness é definido como 0 e não há restrições de localização é mover
os recursos de forma que eles sejam distribuídos uniformemente entre os nós de cluster. Isto pode
resultar na movimentação de recursos saudáveis com mais freqüência do que se deseja. Para evitar este
comportamento, você pode definir o valor padrão resource-stickiness como 1. Este padrão se aplicará
a todos os recursos no cluster. Este pequeno valor pode ser facilmente superado por outras restrições
que você cria, mas é suficiente para evitar que o Pacemaker movimente desnecessariamente recursos
saudáveis em torno do cluster.
O seguinte comando define o valor padrão resource-stickiness como 1.
# pcs resource defaults resource-stickiness=1
Se o valor resource-stickiness for definido, então nenhum recurso será movido para um nó recém-
adicionado. Se o equilíbrio de recursos for desejado nesse ponto, você pode definir temporariamente o
valor resource-stickiness de volta para 0.
Observe que se uma pontuação de restrição de localização for maior que o valor resource-stickiness, o
agrupamento ainda pode mover um recurso saudável para o nó onde a restrição de localização aponta.
Para maiores informações sobre como o Pacemaker determina onde colocar um recurso, veja
Configurando uma estratégia de colocação de nó .
146
CAPÍTULO 12. DETERMINAÇÃO DA ORDEM NA QUAL OS RECURSOS DE AGRUPAMENTO SÃO EXECUTADOS
CAPÍTULO 12. DETERMINAÇÃO DA ORDEM NA QUAL OS

RECURSOS DE AGRUPAMENTO SÃO EXECUTADOS
Para determinar a ordem na qual os recursos funcionam, você configura uma restrição de pedidos.
O seguinte mostra o formato do comando para configurar uma restrição de ordenação.
pedido de restrição pcs [action] resource_id e depois [action] resource_id [options]
Tabela 12.1, “Propriedades de uma restrição de ordem” , resume as propriedades e opções para
configurar as restrições de pedidos.
Tabela 12.1. Propriedades de uma restrição de ordem
Campo Descrição
resource_id O nome de um recurso sobre o qual uma ação é executada.
ação A ação a ser realizada sobre um recurso. Os valores possíveis da

propriedade action são os seguintes:
* start - Iniciar o recurso.
* stop - Pare o recurso.
* promote - Promover o recurso de um recurso escravo para

um recurso mestre.
* demote - Demote o recurso de um recurso mestre para um

recurso escravo.
Se nenhuma ação for especificada, a ação padrão é start.
kind opção Como fazer cumprir a restrição. Os valores possíveis da opção

kind são os seguintes:
* Optional - Somente se aplica se ambos os recursos estiverem

executando a ação especificada. Para informações sobre
pedidos opcionais, consulte Configuração de pedidos
consultivos.
* Mandatory - Sempre (valor padrão). Se o primeiro recurso

que você especificou estiver parando ou não puder ser iniciado,
o segundo recurso que você especificou deve ser parado. Para
informações sobre pedidos obrigatórios, consulte Configuração
de pedidos obrigatórios.
* Serialize - Assegure-se de que não ocorram duas ações de

parada/arranque concomitantes para os recursos especificados.
O primeiro e o segundo recurso que você especificar podem ser
iniciados em qualquer ordem, mas um deve ser concluído antes
que o outro possa ser iniciado. Um caso típico de uso é quando a
partida dos recursos coloca uma carga alta no host.
147
Campo Descrição
symmetrical opção Se for verdade, o contrário da restrição se aplica à ação oposta

(por exemplo, se B começa após A começa, então B pára antes
de Ordenar restrições para as quais kind é Serialize não pode
ser simétrico. O valor padrão é true para os tipos Mandatory e
Ordering, false para Serialize .
Use o seguinte comando para remover recursos de qualquer restrição de pedidos.
ordem de restrição de pcs remover resource1 [resourceN]...
12.1. CONFIGURAÇÃO DE PEDIDOS OBRIGATÓRIOS

Uma restrição de pedido obrigatória indica que a segunda ação não deve ser iniciada para o segundo
recurso a menos que e até que a primeira ação seja concluída com sucesso para o primeiro recurso. As
ações que podem ser encomendadas são stop, start, e, adicionalmente, para clones promocionais,
demote e promote. Por exemplo, "A e depois B" (que é equivalente a "iniciar A e depois iniciar B")
significa que B não será iniciado a menos que e até que A comece com sucesso. Uma restrição de
pedido é obrigatória se a opção kind para a restrição for definida para Mandatory ou deixada como
padrão.
Se a opção symmetrical for definida para true ou deixada para o padrão, as ações opostas serão
ordenadas em reverso. As ações start e stop são opostas, e demote e promote são opostas. Por
exemplo, uma ordem simétrica de "promover A e depois iniciar B" implica em "parar B e depois rebaixar
A", o que significa que A não pode ser rebaixado até e a menos que B pare com sucesso. Uma
ordenação simétrica significa que mudanças no estado de A podem fazer com que ações sejam
programadas para B. Por exemplo, dado "A então B", se A reinicia devido a falha, B será parado primeiro,
depois A será parado, depois A será iniciado, depois B será iniciado.
Observe que o agrupamento reage a cada mudança de estado. Se o primeiro recurso for reiniciado e
estiver num estado inicial novamente antes do segundo recurso iniciar uma operação de parada, o
segundo recurso não precisará ser reiniciado.
12.2. CONFIGURAÇÃO DE PEDIDOS DE CONSULTORIA

Quando a opção kind=Optional é especificada para uma restrição de pedido, a restrição é considerada
opcional e só se aplica se ambos os recursos estiverem executando as ações especificadas. Qualquer
mudança no estado pelo primeiro recurso especificado não terá efeito sobre o segundo recurso
especificado.
O seguinte comando configura uma restrição de ordenação consultiva para os recursos denominados
VirtualIP e dummy_resource.
# pcs constraint order VirtualIP then dummy_resource kind=Optional
12.3. CONFIGURAÇÃO DE CONJUNTOS DE RECURSOS

ENCOMENDADOS
Uma situação comum é que um administrador crie uma cadeia de recursos ordenados, onde, por
148
exemplo, o recurso A começa antes do recurso B que começa antes do recurso C. Se sua configuração
exigir que você crie um conjunto de recursos que seja colocado e iniciado em ordem, você pode
configurar um grupo de recursos que contenha esses recursos, conforme descrito em Configuração de
grupos de recursos.
Há algumas situações, entretanto, onde a configuração dos recursos que precisam começar em uma
ordem específica como um grupo de recursos não é apropriada:
Talvez seja necessário configurar os recursos para começar em ordem e os recursos não são
necessariamente colocados.
Você pode ter um recurso C que deve começar depois que o recurso A ou B tiver começado,
mas não há nenhuma relação entre A e B.
Você pode ter recursos C e D que devem começar depois que ambos os recursos A e B tiverem
começado, mas não há relação entre A e B ou entre C e D.
Nestas situações, você pode criar uma restrição de pedidos em um conjunto ou conjuntos de recursos
com o comando pcs constraint order set.
Você pode definir as seguintes opções para um conjunto de recursos com o comando pcs constraint
order set.
sequential, que pode ser ajustado para true ou false para indicar se o conjunto de recursos
deve ser ordenado em relação um ao outro. O valor padrão é true.
A configuração sequential para false permite que um conjunto seja ordenado em relação a
outros conjuntos na restrição de ordenação, sem que seus membros sejam ordenados em
relação uns aos outros. Portanto, esta opção só faz sentido se vários conjuntos estiverem
listados na restrição; caso contrário, a restrição não tem efeito.
require-all, que pode ser ajustado para true ou false para indicar se todos os recursos do
conjunto devem estar ativos antes de continuar. Definir require-all para false significa que
apenas um recurso do conjunto precisa ser iniciado antes de continuar para o próximo conjunto.
A configuração require-all a false não tem efeito, a menos que seja usada em conjunto com
conjuntos não ordenados, que são conjuntos para os quais sequential está configurado para
false. O valor padrão é true.
action, que pode ser ajustado para start, promote, demote ou stop, conforme descrito em
Propriedades de uma Restrição de Ordem .
role, que pode ser ajustado para Stopped, Started, Master, ou Slave.
Você pode definir as seguintes opções de restrição para um conjunto de recursos seguindo o parâmetro
setoptions do comando pcs constraint order set.
id, para fornecer um nome para a restrição que você está definindo.
kind, que indica como aplicar a restrição, conforme descrito em Propriedades de uma Restrição
de Ordem.
symmetrical, para definir se o inverso da restrição se aplica à ação oposta, conforme descrito
em Propriedades de uma Restrição de Ordem .
pcs constraint order set resource1 resource2 [resourceN]... [options] [set resourceX resourceY ...
[options]]] [set [setoptions [constraint_options]]]
Se você tiver três recursos chamados D1, D2, e D3, o seguinte comando os configura como um conjunto
149
Se você tiver três recursos chamados D1, D2, e D3, o seguinte comando os configura como um conjunto
de recursos ordenados.
# pcs constraint order set D1 D2 D3
Se você tiver seis recursos denominados A, B, C, D, E, e F, este exemplo configura uma restrição de
pedido para o conjunto de recursos que começará como a seguir:
A e B começam independentemente um do outro
C começa uma vez que A ou B já começou
D começa quando C já começou
E e F começam independentemente um do outro uma vez que D já começou
A interrupção dos recursos não é influenciada por esta restrição, uma vez que o site symmetrical=false
está definido.
# pcs constraint order set A B sequential=false require-all=false set C D set E F

sequential=false setoptions symmetrical=false
12.4. CONFIGURAÇÃO DE ORDEM DE PARTIDA PARA DEPENDÊNCIAS

DE RECURSOS NÃO GERENCIADAS PELA PACEMAKER
É possível que um agrupamento inclua recursos com dependências que não são gerenciadas pelo
próprio agrupamento. Neste caso, é preciso garantir que essas dependências sejam iniciadas antes de o
Pacemaker ser iniciado e parado depois que o Pacemaker for parado.
Você pode configurar sua ordem de partida para responder por esta situação por meio da meta
systemd resource-agents-deps . Você pode criar uma unidade drop-in systemd para este alvo e o
Pacemaker se encarregará de fazer o pedido de forma apropriada em relação a este alvo.
Por exemplo, se um cluster inclui um recurso que depende do serviço externo foo que não é gerenciado
pelo cluster, execute o seguinte procedimento.
1. Crie a unidade drop-in /etc/systemd/system/resource-agents-deps.target.d/foo.conf que

contém o seguinte:
[Unit]
Requires=foo.service
After=foo.service
2. Execute o comando systemctl daemon-reload.
Uma dependência de cluster especificada desta forma pode ser algo diferente de um serviço. Por
exemplo, você pode ter uma dependência na montagem de um sistema de arquivo em /srv, caso em
que você executaria o seguinte procedimento:
1. Assegure-se de que /srv esteja listado no arquivo /etc/fstab. Isto será convertido
automaticamente para o arquivo systemd srv.mount na inicialização, quando a configuração
do gerenciador do sistema for recarregada. Para mais informações, consulte as páginas de
manual systemd.mount(5) e systemd-fstab-generator(8).
2. Para ter certeza de que o Pacemaker inicia após a montagem do disco, crie a unidade drop-in
150
2. Para ter certeza de que o Pacemaker inicia após a montagem do disco, crie a unidade drop-in
/etc/systemd/system/resource-agents-deps.target.d/srv.conf que contém o seguinte.
[Unit]
Requires=srv.mount
After=srv.mount
3. Execute o comando systemctl daemon-reload.
151
CAPÍTULO 13. COLOCANDO RECURSOS DE CLUSTER

Para especificar que a localização de um recurso depende da localização de outro recurso, você
configura uma restrição de colocação.
Há um importante efeito colateral de criar uma restrição de colocação entre dois recursos: ela afeta a
ordem na qual os recursos são atribuídos a um nó. Isto porque não se pode colocar o recurso A em
relação ao recurso B, a menos que se saiba onde está o recurso B. Portanto, quando você estiver
criando restrições de colocação, é importante considerar se você deve colocar o recurso A com o
recurso B ou o recurso B com o recurso A.
Outra coisa a ter em mente ao criar restrições de colocação é que, supondo que o recurso A esteja
colocado com o recurso B, o agrupamento também levará em conta as preferências do recurso A ao
decidir qual nó escolher para o recurso B.
O seguinte comando cria uma restrição de colocação.
pcs constraint colocation add [master|slave] source_resource com [master|slave] target_resource

[score] [options]
Tabela 13.1, “Propriedades de uma Restrição de Colocação” , resume as propriedades e opções para a
configuração de restrições de colocação.
Tabela 13.1. Propriedades de uma Restrição de Colocação
Campo Descrição
fonte_resource A fonte de colocação. Se a restrição não puder ser satisfeita, o

agrupamento pode decidir não permitir que o recurso funcione
de forma alguma.
target_resource O alvo da colocação. O agrupamento decidirá onde colocar este

recurso em primeiro lugar e depois decidirá onde colocar o
recurso fonte.
pontuação Os valores positivos indicam que o recurso deve funcionar no

mesmo nó. Os valores negativos indicam que os recursos não
devem ser executados no mesmo nó. Um valor de INFINITY, o
valor padrão, indica que o source_resource deve rodar no mesmo
nó que o target_resource. Um valor de -INFINITY indica que o
source_resource não deve rodar no mesmo nó que o
target_resource.
13.1. ESPECIFICAR A COLOCAÇÃO OBRIGATÓRIA DE RECURSOS

A colocação obrigatória ocorre sempre que a pontuação da restrição é INFINITY ou -INFINITY. Nesses
casos, se a restrição não puder ser satisfeita, então o source_resource não tem permissão para
funcionar. Para score=INFINITY, isto inclui casos em que o target_resource não está ativo.
Se você precisar que myresource1 funcione sempre na mesma máquina que myresource2, você
acrescentaria a seguinte restrição:
# pcs constraint colocation add myresource1 with myresource2 score=INFINITY
152
CAPÍTULO 13. COLOCANDO RECURSOS DE CLUSTER
Como INFINITY foi utilizado, se myresource2 não puder funcionar em nenhum dos nós de cluster (por
qualquer razão), então myresource1 não será permitido funcionar.
Alternativamente, você pode querer configurar o oposto, um cluster no qual myresource1 não pode
funcionar na mesma máquina que myresource2. Neste caso, use score=-INFINITY
# pcs constraint colocation add myresource1 with myresource2 score=-INFINITY
Mais uma vez, especificando -INFINITY, a restrição é vinculativa. Portanto, se o único lugar que resta
para correr é onde já está myresource2, então myresource1 não pode correr em nenhum lugar.
13.2. ESPECIFICAR A COLOCAÇÃO DE RECURSOS CONSULTIVOS

Se a colocação obrigatória é sobre "deve" e "não deve", então a colocação consultiva é a alternativa "eu
preferiria se". Para restrições com pontuação maior que -INFINITY e menor que INFINITY, o
agrupamento tentará acomodar seus desejos, mas poderá ignorá-los se a alternativa for parar alguns
dos recursos do agrupamento.
13.3. COLOCANDO CONJUNTOS DE RECURSOS

Se sua configuração exigir que você crie um conjunto de recursos que são colocados e iniciados em
ordem, você pode configurar um grupo de recursos que contenha esses recursos, conforme descrito em
Configuração de grupos de recursos . Há algumas situações, no entanto, onde configurar os recursos que
precisam ser colocados como um grupo de recursos não é apropriado:
Você pode precisar colocar um conjunto de recursos, mas os recursos não precisam
necessariamente começar em ordem.
Você pode ter um recurso C que deve ser colocado com o recurso A ou B, mas não há nenhuma
relação entre A e B.
Você pode ter recursos C e D que devem ser colocados com ambos os recursos A e B, mas não
há relação entre A e B ou entre C e D.
Nestas situações, você pode criar uma restrição de colocação sobre um conjunto ou conjuntos de
recursos com o comando pcs constraint colocation set.
Você pode definir as seguintes opções para um conjunto de recursos com o comando pcs constraint
colocation set.
sequential, que pode ser ajustado para true ou false para indicar se os membros do conjunto
devem ser colocados uns com os outros.
A configuração sequential para false permite que os membros deste conjunto sejam colocados
com outro conjunto listado posteriormente na restrição, independentemente de quais membros
deste conjunto estejam ativos. Portanto, esta opção só faz sentido se outro conjunto for listado
depois deste na restrição; caso contrário, a restrição não tem efeito.
role, que pode ser ajustado para Stopped, Started, Master, ou Slave.
Você pode definir a seguinte opção de restrição para um conjunto de recursos seguindo o parâmetro
setoptions do comando pcs constraint colocation set.
id, para fornecer um nome para a restrição que você está definindo.
score, para indicar o grau de preferência por esta restrição. Para informações sobre esta opção,
153
score, para indicar o grau de preferência por esta restrição. Para informações sobre esta opção,
consulte Opções de Restrição de Localização .
Ao listar os membros de um conjunto, cada membro é colocado com aquele que o precedeu. Por
exemplo, "conjunto A B" significa "B é colocado com A". No entanto, ao listar vários conjuntos, cada
conjunto é colocado com o que está depois dele. Por exemplo, "conjunto C D seqüencial=conjunto falso
A B" significa "conjunto C D (onde C e D não têm relação entre si) é colocado com o conjunto A B
(onde B é colocado com A)".
O seguinte comando cria uma restrição de colocação sobre um conjunto ou conjuntos de recursos.
pcs constraint colocation set resource1 resource2 [resourceN]... [options] [set resourceX resourceY
... [options]]] [set [setoptions [constraint_options]]]
13.4. REMOÇÃO DE RESTRIÇÕES DE COLOCAÇÃO

Use o seguinte comando para remover as restrições de colocação com source_resource.
pcs constraint colocation remover source_resource target_resource
154
CAPÍTULO 14. EXIBINDO RESTRIÇÕES DE RECURSOS

Há vários comandos que você pode usar para exibir as restrições que foram configuradas.
14.1. EXIBINDO TODAS AS RESTRIÇÕES CONFIGURADAS

O seguinte comando lista todas as restrições atuais de localização, ordem e colocação. Se a opção --full
for especificada, mostrar as identificações de restrições internas.
pcs constraint [list|show] [--full] [--full] [--full] [--full
A partir do RHEL 8.2, a listagem das restrições de recursos não mais, por padrão, exibe as restrições
expiradas. Para incluir os consignamentos expirados, use a opção --all do comando pcs constraint. Isto
listará as restrições expiradas, anotando as restrições e suas regras associadas como (expired) no
display.
14.2. EXIBIÇÃO DAS RESTRIÇÕES DE LOCALIZAÇÃO

O comando a seguir lista todas as restrições de localização atuais.
Se resources for especificado, as restrições de localização são exibidas por recurso. Este é o
comportamento padrão.
Se nodes for especificado, as restrições de localização são exibidas por nó.
Se forem especificados recursos ou nós específicos, então somente informações sobre esses
recursos ou nós serão exibidas.
pcs constraint location [mostrar [recursos [resource...]] | [nós [node...]] [--cheio]
14.3. EXIBIR RESTRIÇÕES DE PEDIDOS

O seguinte comando lista todas as restrições de pedidos atuais.
pcs ordem de restrição [mostrar]
14.4. EXIBIÇÃO DE RESTRIÇÕES DE COLOCAÇÃO

O seguinte comando lista todas as restrições de colocação atuais.
pcs constraint colocation [mostrar]
14.5. EXIBINDO RESTRIÇÕES ESPECÍFICAS DE RECURSOS

O seguinte comando lista as restrições que fazem referência a recursos específicos.
pcs constraint ref resource...
14.6. EXIBIÇÃO DAS DEPENDÊNCIAS DE RECURSOS (RED HAT

155
14.6. EXIBIÇÃO DAS DEPENDÊNCIAS DE RECURSOS (RED HAT

ENTERPRISE LINUX 8.2 E POSTERIORES)
O comando seguinte mostra as relações entre os recursos de agrupamento em uma estrutura em
árvore.
pcs resource relations resource [--full]
Se a opção --full for utilizada, o comando exibe informações adicionais, incluindo as identificações de
restrição e os tipos de recursos.
No exemplo a seguir, há 3 recursos configurados: C, D, e E.
# pcs constraint order start C then start D

Adding C D (kind: Mandatory) (Options: first-action=start then-action=start)
# pcs constraint order start D then start E
Adding D E (kind: Mandatory) (Options: first-action=start then-action=start)
# pcs resource relations C

C
`- order
| start C then start D
`- D
`- order
| start D then start E
`- E
# pcs resource relations D
D
|- order
| | start C then start D
| `- C
`- order
`- E
# pcs resource relations E
E
`- order
`- D
`- order
| start C then start D
`- C
No exemplo a seguir, há 2 recursos configurados: A e B. Os recursos A e B são parte do grupo de

recursos G.
# pcs resource relations A

A
`- outer resource
`- G
`- inner resource(s)
| members: A B
`- B
# pcs resource relations B
B
156
`- outer resource
`- G
| members: A B
`- A
# pcs resource relations G
G
| members: A B
|- A
`- B
157
CAPÍTULO 15. DETERMINAÇÃO DA LOCALIZAÇÃO DOS

RECURSOS COM REGRAS
Para restrições de localização mais complicadas, você pode usar as regras do Pacemaker para
determinar a localização de um recurso.
15.1. REGRAS DO MARCAPASSO

As regras podem ser usadas para tornar sua configuração mais dinâmica. Um uso de regras pode ser o
de atribuir máquinas a diferentes grupos de processamento (usando um atributo de nó) com base no
tempo e depois usar esse atributo ao criar restrições de localização.
Cada regra pode conter uma série de expressões, expressões de datas e até mesmo outras regras. Os
resultados das expressões são combinados com base no campo da regra boolean-op para determinar
se a regra finalmente avalia para true ou false. O que acontece em seguida depende do contexto em
que a regra está sendo usada.
Tabela 15.1. Propriedades de uma regra
Campo Descrição
role Limita a regra a ser aplicada somente quando o

recurso está nessa função. Valores permitidos:
Started, Slave, e Master. NOTA: Uma regra com
role="Master" não pode determinar a localização
inicial de uma instância clonal. Ela somente afetará
quais das instâncias ativas serão promovidas.
score A pontuação a aplicar se a regra for avaliada para

true. Limitada a ser usada em regras que fazem
parte das restrições de localização.
score-attribute O atributo do nó a ser procurado e usado como

pontuação se a regra for avaliada para true. Limitado
ao uso em regras que são parte das restrições de
localização.
boolean-op Como combinar o resultado de objetos de expressão

múltipla. Valores permitidos: and e or. O valor
padrão é and .
15.1.1. Expressões de atributos de nós

As expressões de atributos de nós são utilizadas para controlar um recurso com base nos atributos
definidos por um ou mais nós.
Tabela 15.2. Propriedades de uma Expressão
Campo Descrição
attribute O atributo do nó a ser testado
158
CAPÍTULO 15. DETERMINAÇÃO DA LOCALIZAÇÃO DOS RECURSOS COM REGRAS
Campo Descrição
type Determina como o(s) valor(es) deve(m) ser

testado(s). Valores permitidos: string , integer ,
version. O valor padrão é string .
operation A comparação a ser feita. Os valores permitidos:
* lt - Verdadeiro se o valor do atributo do nó for

inferior a value
* gt - Verdadeiro se o valor do atributo do nó for

maior que value
* lte - Verdadeiro se o valor do atributo do nó for

menor ou igual a value
* gte - Verdadeiro se o valor do atributo do nó for

maior ou igual a value
* eq - Verdadeiro se o valor do atributo do nó for

igual a value
* ne - Verdadeiro se o valor do atributo do nó não for

igual a value
* defined - Verdadeiro se o nó tiver o atributo

nomeado
* not_defined - Verdadeiro se o nó não tiver o

atributo nomeado
value Valor fornecido pelo usuário para comparação

(necessário, a menos que operation seja defined
ou not_defined)
Além de quaisquer atributos adicionados pelo administrador, o cluster define atributos de nó especiais e
integrados para cada nó que também podem ser usados, como descrito em Tabela 15.3, “Atributos dos
nós embutidos”.
Tabela 15.3. Atributos dos nós embutidos
Nome Descrição
#uname Nome do nó
#id Identificação do nó
159
Nome Descrição
#kind Tipo de nó. Os valores possíveis são cluster,

remote , e container. O valor de kind é remote
para nós Pacemaker Remote criados com o recurso
ocf:pacemaker:remote, e container para nós
Pacemaker Remote guest e nós de pacote.
#is_dc true se este nó for um Controlador Designado (DC),

false caso contrário
#cluster_name O valor da propriedade do cluster cluster-name, se

definido
#site_name O valor do atributo do nó site-name, se definido,

caso contrário idêntico ao #cluster-name
#role O papel que o clone promocional relevante tem

sobre este nó. Válido somente dentro de uma regra
para uma restrição de localização para um clone
promocional.
15.1.2. Expressões baseadas em tempo/data

As expressões de data são usadas para controlar um recurso ou opção de cluster com base na
data/hora atual. Elas podem conter uma especificação de data opcional.
Tabela 15.4. Propriedades de uma expressão de data
Campo Descrição
start Uma data/hora em conformidade com a

especificação ISO8601.
end Uma data/hora em conformidade com a

especificação ISO8601.
operation Compara a data/hora atual com a data inicial ou final

ou ambas as datas, dependendo do contexto.
Valores permitidos:
* gt - Verdadeiro se a data/hora atual for depois

start
* lt - Verdadeiro se a data/hora atual for antes end
* in_range - Verdadeiro se a data/hora atual for

depois de start e antes end
* date-spec - realiza uma comparação cronológica

com a data/hora atual
160
CAPÍTULO 15. DETERMINAÇÃO DA LOCALIZAÇÃO DOS RECURSOS COM REGRAS
15.1.3. Especificações de data

As especificações de data são usadas para criar expressões semelhantes a cron cron cronômetro
relacionadas ao tempo. Cada campo pode conter um único número ou um único intervalo. Em vez de
ser padrão a zero, qualquer campo não fornecido é ignorado.
Por exemplo, monthdays="1" corresponde ao primeiro dia de cada mês e hours="09-17" corresponde
ao horário entre 9h e 17h (inclusive). Entretanto, não é possível especificar weekdays="1,2" ou
weekdays="1-2,5-6", uma vez que eles contêm múltiplos intervalos.
Tabela 15.5. Propriedades de uma especificação de data
Campo Descrição
id Um nome único para a data
hours Valores permitidos: 0-23
monthdays Valores permitidos: 0-31 (dependendo do mês e do

ano)
weekdays Valores permitidos: 1-7 (1=Domingo, 7=Domingo)
yeardays Valores permitidos: 1-366 (dependendo do ano)
months Valores permitidos: 1-12
weeks Valores permitidos: 1-53 (dependendo de

weekyear)
years Ano de acordo com o calendário gregoriano
weekyears Pode diferir dos anos gregorianos; por exemplo,

2005-001 Ordinal é também 2005-01-01
Gregorian é também 2004-W53-6 Weekly
moon Valores permitidos: 0-7 (0 é novo, 4 é lua cheia).
15.2. CONFIGURAÇÃO DE UMA RESTRIÇÃO DE LOCALIZAÇÃO DE

MARCAPASSO USANDO REGRAS
Use o seguinte comando para configurar uma restrição do Pacemaker que usa regras. Se score for
omitido, o padrão é INFINIDADE. Se resource-discovery for omitido, o valor padrão é always.
Para informações sobre a opção resource-discovery, consulte Limitando a descoberta de recursos a

um subconjunto de nós.
Assim como com as restrições básicas de localização, você pode usar expressões regulares para
recursos com estas restrições também.
Ao utilizar regras para configurar restrições de localização, o valor de score pode ser positivo ou
161
Ao utilizar regras para configurar restrições de localização, o valor de score pode ser positivo ou
negativo, com um valor positivo indicando "prefere" e um valor negativo indicando "evita".
pcs constraint location rsc rule [resource-discovery=option] [role=master|slave] [score=score | score-

attribute=attribute] expression
A opção expression pode ser uma das seguintes onde duration_options e date_spec_options são: horas,
dias do mês, dias da semana, dias da semana, dias do ano, meses, semanas, anos, anos da semana, lua,
conforme descrito em Propriedades de uma Especificação de Data .
defined|not_defined attribute
attribute lt|gt|lte|gte|eq|ne [string|integer|version] value
date gt|lt date
date in_range date to date
date in_range date to duration duration_options …
date-spec date_spec_options
expression and|or expression
(expression)
Observe que as durações são uma forma alternativa de especificar um fim para as operações do
in_range por meio de cálculos. Por exemplo, você pode especificar uma duração de 19 meses.
A seguinte restrição de localização configura uma expressão que é verdadeira se agora for em qualquer
época do ano de 2018.
# pcs constraint location Webserver rule score=INFINITY date-spec years=2018
O seguinte comando configura uma expressão que é verdadeira das 9h às 17h, de segunda a sexta-feira.
Observe que o valor de 16 horas corresponde até 16:59:59, pois o valor numérico (hora) ainda
corresponde.
# pcs constraint location Webserver rule score=INFINITY date-spec hours="9-16"

weekdays="1-5"
O comando seguinte configura uma expressão que é verdadeira quando há lua cheia na sexta-feira, dia
treze.
# pcs constraint location Webserver rule date-spec weekdays=5 monthdays=13 moon=4
Para remover uma regra, use o seguinte comando. Se a regra que você está removendo é a última regra
em sua restrição, a restrição será removida.
regra de restrição de pcs remover rule_id
162
CAPÍTULO 16. GERENCIAMENTO DE RECURSOS DE CLUSTER

Esta seção descreve vários comandos que você pode usar para gerenciar recursos de cluster.
16.1. EXIBIÇÃO DE RECURSOS CONFIGURADOS

Para exibir uma lista de todos os recursos configurados, use o seguinte comando.
pcs status dos recursos
Por exemplo, se seu sistema for configurado com um recurso chamado VirtualIP e um recurso chamado
WebSite, o comando pcs resource show produz o seguinte resultado.
# pcs resource status

VirtualIP (ocf::heartbeat:IPaddr2): Started
WebSite (ocf::heartbeat:apache): Started
Para exibir uma lista de todos os recursos configurados e os parâmetros configurados para esses
recursos, use a opção --full do comando pcs resource config, como no exemplo a seguir.
# pcs resource config

Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat)
Attributes: ip=192.168.0.120 cidr_netmask=24
Operations: monitor interval=30s
Resource: WebSite (type=apache class=ocf provider=heartbeat)
Attributes: statusurl=http://localhost/server-status configfile=/etc/httpd/conf/httpd.conf
Operations: monitor interval=1min
Para exibir os parâmetros configurados para um recurso, use o seguinte comando.
pcs resource config resource_id
Por exemplo, o seguinte comando exibe os parâmetros atualmente configurados para o recurso
VirtualIP.
# pcs resource config VirtualIP

16.2. MODIFICAÇÃO DOS PARÂMETROS DOS RECURSOS

Para modificar os parâmetros de um recurso configurado, use o seguinte comando.
atualização de recursos pcs resource_id [resource_options]
A seguinte seqüência de comandos mostra os valores iniciais dos parâmetros configurados para o
recurso VirtualIP, o comando para alterar o valor do parâmetro ip, e os valores após o comando de
atualização.

163

# pcs resource update VirtualIP ip=192.169.0.120
NOTA
Quando você atualiza a operação de um recurso com o comando pcs resource update,
quaisquer opções que você não chamar especificamente são redefinidas para seus
valores padrão.
16.3. STATUS DE FALHAS DE COMPENSAÇÃO DE RECURSOS DE

CLUSTER
Se um recurso falhou, uma mensagem de falha aparece quando você exibe o status do cluster. Se você
resolver esse recurso, você pode limpar esse status de falha com o comando pcs resource cleanup.
Este comando restabelece o status do recurso e failcount, dizendo ao cluster para esquecer o histórico
de operação de um recurso e re-detectar seu estado atual.
O seguinte comando limpa o recurso especificado por resource_id.
pcs limpeza de recursos resource_id
Se você não especificar um resource_id, este comando restabelece o status do recurso e failcountpara
todos os recursos.
O comando pcs resource cleanup sonda apenas os recursos que se apresentam como uma ação
fracassada. Para sondar todos os recursos em todos os nós, você pode digitar o seguinte comando:
atualização de recursos pcs
Por padrão, o comando pcs resource refresh sonda apenas os nós onde o estado de um recurso é
conhecido. Para sondar todos os recursos, mesmo que o estado não seja conhecido, digite o seguinte
comando:
atualização de recursos pcs --cheio
16.4. MOVIMENTAÇÃO DE RECURSOS EM UM CLUSTER

Pacemaker fornece uma variedade de mecanismos para configurar um recurso para mover de um nó
para outro e para mover manualmente um recurso quando necessário.
Você pode mover recursos manualmente em um cluster com os comandos pcs resource move e pcs
resource relocate, conforme descrito em Movimentação manual de recursos de cluster .
Além destes comandos, você também pode controlar o comportamento dos recursos de cluster,
ativando, desativando e proibindo recursos, conforme descrito em Habilitação, desativação e proibição
de recursos de cluster.
Você pode configurar um recurso para que ele se mova para um novo nó após um número definido de
164
Você pode configurar um recurso para que ele se mova para um novo nó após um número definido de
falhas, e você pode configurar um cluster para mover recursos quando a conectividade externa for
perdida.
16.4.1. Movimentação de recursos devido a falhas

Quando você cria um recurso, você pode configurar o recurso para que ele se mova para um novo nó
após um número definido de falhas, definindo a opção migration-threshold para esse recurso. Uma vez
atingido o limite, este nó não terá mais permissão para executar o recurso falhado até que seja atingido:
O administrador redefine manualmente o recurso failcount usando o comando pcs resource

cleanup.
O valor do recurso failure-timeout é alcançado.
O valor de migration-threshold é definido como INFINITY por padrão. INFINITY é definido

internamente como um número muito grande, mas finito. Um valor de 0 desativa o recurso migration-
threshold.
NOTA
Configurar um migration-threshold para um recurso não é o mesmo que configurar um

recurso para migração, no qual o recurso se move para outro local sem perda de estado.
O exemplo seguinte acrescenta um limiar de migração de 10 ao recurso denominado dummy_resource,

o que indica que o recurso se moverá para um novo nó após 10 falhas.
# pcs resource meta dummy_resource migration-threshold=10
Você pode adicionar um limiar de migração aos padrões para todo o cluster com o seguinte comando.
# pcs resource defaults migration-threshold=10
Para determinar o estado atual de falhas e limites do recurso, use o comando pcs resource failcount
show.
Há duas exceções ao conceito de limite de migração; elas ocorrem quando um recurso não inicia ou não
pára. Se a propriedade do cluster start-failure-is-fatal estiver definida para true (que é o padrão), as
falhas de partida fazem com que o failcount seja definido para INFINITY e, assim, sempre faz com que o
recurso se mova imediatamente.
As falhas de parada são ligeiramente diferentes e cruciais. Se um recurso não parar e o STONITH for
ativado, então o agrupamento cercará o nó a fim de poder iniciar o recurso em outro lugar. Se o
STONITH não estiver ativado, então o aglomerado não tem como continuar e não tentará iniciar o
recurso em outro lugar, mas tentará pará-lo novamente após o timeout de falhas.
16.4.2. Movimentação de recursos devido a mudanças na conectividade

A configuração do cluster para mover recursos quando a conectividade externa é perdida é um
processo de duas etapas.
1. Adicione um recurso ping ao agrupamento. O recurso ping usa a utilidade do sistema com o
mesmo nome para testar se uma lista de máquinas (especificada pelo nome do host DNS ou
endereço IPv4/IPv6) é alcançável e usa os resultados para manter um atributo de nó chamado
165
pingd.
2. Configurar uma restrição de localização para o recurso que irá mover o recurso para um nó
diferente quando a conectividade for perdida.
Tabela 10.1, “Agente de Identificação de Recursos” descreve as propriedades que você pode definir para
um recurso ping.
Tabela 16.1. Propriedades de um recurso de ping
Campo Descrição
dampen O tempo de espera (amortecimento) para que

ocorram mais mudanças. Isto evita que um recurso
salte ao redor do cluster quando os nós do cluster
percebem a perda de conectividade em momentos
ligeiramente diferentes.
multiplier O número de nós de ping conectados é multiplicado

por este valor para obter uma pontuação. Útil
quando há múltiplos nós ping configurados.
host_list As máquinas a serem contatadas a fim de determinar

o estado atual da conectividade. Os valores
permitidos incluem nomes de hosts DNS resolvíveis,
endereços IPv4 e IPv6. As entradas na lista de hosts
são separadas por espaço.
O seguinte exemplo de comando cria um recurso ping que verifica a conectividade para
gateway.example.com. Na prática, você verificaria a conectividade com seu gateway/router de rede.
Você configura o recurso ping como um clone para que o recurso seja executado em todos os nós de
cluster.
# pcs resource create ping ocf:pacemaker:ping dampen=5s multiplier=1000

host_list=gateway.example.com clone
O exemplo a seguir configura uma regra de restrição de localização para o recurso existente
denominado Webserver. Isso fará com que o recurso Webserver se mude para um host capaz de ping
gateway.example.com se o host em que ele está atualmente funcionando não puder pingar
gateway.example.com.
# pcs constraint location Webserver rule score=-INFINITY pingd lt 1 or not_defined pingd
Module included in the following assemblies:

//
// <List assemblies here, each on a new line>
// rhel-8-docs/enterprise/assemblies/assembly_managing-cluster-resources.adoc
16.5. DESABILITANDO UMA OPERAÇÃO DE MONITOR

A maneira mais fácil de parar um monitor recorrente é apagá-lo. No entanto, pode haver momentos em
que você deseja desativá-lo apenas temporariamente. Nesses casos, adicione enabled="false" à
166
definição da operação. Quando você quiser restabelecer a operação de monitoramento, defina

enabled="true" para a definição da operação.
Quando você atualiza a operação de um recurso com o comando pcs resource update, quaisquer
opções que você não chamar especificamente são redefinidas para seus valores padrão. Por exemplo,
se você tiver configurado uma operação de monitoramento com um valor de timeout personalizado de
600, a execução dos seguintes comandos redefinirá o valor de timeout para o valor padrão de 20 (ou o
que quer que você tenha configurado o valor padrão com o comando pcs resource ops default ).
# pcs resource update resourceXZY op monitor enabled=false

# pcs resource update resourceXZY op monitor enabled=true
A fim de manter o valor original de 600 para esta opção, quando você restabelece a operação de
monitoramento você deve especificar este valor, como no exemplo a seguir.
# pcs resource update resourceXZY op monitor timeout=600 enabled=true
16.6. CONFIGURAÇÃO E GERENCIAMENTO DE ETIQUETAS DE

RECURSOS DE CLUSTER (RHEL 8.3 E POSTERIORES)
A partir do Red Hat Enterprise Linux 8.3, você pode usar o comando pcs para marcar os recursos do
cluster. Isto permite que você habilite, desabilite, gerencie ou não gerencie um conjunto específico de
recursos com um único comando.
16.6.1. Marcação de recursos de cluster para administração por categoria

O seguinte procedimento marca dois recursos com uma etiqueta de recurso e desativa os recursos
marcados. Neste exemplo, os recursos existentes a serem etiquetados são denominados d-01 e d-02.
1. Criar uma tag chamada special-resources para os recursos d-01 e d-02.
[root@node-01]# pcs tag create special-resources d-01 d-02
2. Exibir a configuração da etiqueta de recurso.
[root@node-01]# pcs tag config

special-resources
d-01
d-02
3. Desabilite todos os recursos que estão marcados com a tag special-resources.
[root@node-01]# pcs resource disable special-resources
4. Mostrar o status dos recursos para confirmar que os recursos d-01 e d-02 estão desativados.
[root@node-01]# pcs resource

* d-01 (ocf::pacemaker:Dummy): Stopped (disabled)
* d-02 (ocf::pacemaker:Dummy): Stopped (disabled)
Além do comando pcs resource disable, os comandos pcs resource enable, pcs resource manage, e
pcs resource unmanage apóiam a administração de recursos marcados.
167
Depois de ter criado uma etiqueta de recurso:
Você pode excluir uma etiqueta de recurso com o comando pcs tag delete.
Você pode modificar a configuração da tag de recurso para uma tag de recurso existente com o
comando pcs tag update.
16.6.2. Eliminação de um recurso de cluster etiquetado

Você não pode excluir um recurso de cluster marcado com o comando pcs. Para excluir um recurso
etiquetado, use o seguinte procedimento.
1. Remover a etiqueta do recurso.
a. O seguinte comando remove a tag de recurso special-resources de todos os recursos com

essa tag,
[root@node-01]# pcs tag remove special-resources

[root@node-01]# pcs tag
No tags defined
b. O seguinte comando remove a etiqueta do recurso special-resources do recurso d-01

apenas.
[root@node-01]# pcs tag update special-resources remove d-01
2. Eliminar o recurso.
[root@node-01]# pcs resource delete d-01

Attempting to stop: d-01... Stopped
168
CAPÍTULO 17. CRIAÇÃO DE RECURSOS DE CLUSTER QUE ESTÃO ATIVOS EM MÚLTIPLOS NÓS (RECURSOS CLONADOS)
CAPÍTULO 17. CRIAÇÃO DE RECURSOS DE CLUSTER QUE

ESTÃO ATIVOS EM MÚLTIPLOS NÓS (RECURSOS
CLONADOS)
Você pode clonar um recurso de cluster para que o recurso possa estar ativo em vários nós. Por
exemplo, você pode utilizar recursos clonados para configurar múltiplas instâncias de um recurso IP para
distribuir em todo um cluster para balanceamento de nós. Você pode clonar qualquer recurso, desde
que o agente de recursos o suporte. Um clone consiste em um recurso ou um grupo de recursos.
NOTA
Somente os recursos que podem estar ativos em vários nós ao mesmo tempo são
adequados para clonagem. Por exemplo, um recurso Filesystem que monta um sistema
de arquivo não exclusivo como ext4 a partir de um dispositivo de memória compartilhada
não deve ser clonado. Como a partição ext4 não está ciente do cluster, este sistema de
arquivo não é adequado para operações de leitura/gravação que ocorrem a partir de
múltiplos nós ao mesmo tempo.
17.1. CRIAÇÃO E REMOÇÃO DE UM RECURSO CLONADO

Você pode criar um recurso e um clone desse recurso ao mesmo tempo com o seguinte comando.
pcs resource create resource_id [standard:[provider:]]type [resource options] [meta resource meta
options] clone [clone options]
O nome do clone será resource_id-clone.
Não se pode criar um grupo de recursos e um clone desse grupo de recursos em um único comando.
Alternativamente, você pode criar um clone de um recurso ou grupo de recursos previamente criado
com o seguinte comando.
pcs resource clone resource_id | group_name [clone options]...
O nome do clone será resource_id-clone ou group_name-clone.
NOTA
Você precisa configurar as mudanças de configuração de recursos em apenas um nó.
NOTA
Ao configurar as restrições, use sempre o nome do grupo ou clone.
Quando você cria um clone de um recurso, o clone assume o nome do recurso com -clone anexado ao
nome. Os seguintes comandos criam um recurso do tipo apache chamado webfarm e um clone desse
recurso chamado webfarm-clone.
# pcs resource create webfarm apache clone
NOTA
169
NOTA
Quando você cria um recurso ou clone de grupo de recursos que será encomendado após
outro clone, você deve quase sempre definir a opção interleave=true. Isto garante que as
cópias do clone dependente possam parar ou começar quando o clone do qual depende
tiver parado ou começado no mesmo nó. Se você não definir esta opção, se um recurso
clonado B depender de um recurso clonado A e um nó sair do cluster, quando o nó
retornar ao cluster e o recurso A começar naquele nó, então todas as cópias do recurso B
em todos os nós serão reiniciadas. Isto porque quando um recurso clonado dependente
não tem a opção interleave definida, todas as instâncias desse recurso dependem de
qualquer instância em execução do recurso do qual ele depende.
Use o seguinte comando para remover um clone de um recurso ou de um grupo de recursos. Isto não
remove o recurso ou o próprio grupo de recursos.
pcs resource unclone resource_id | group_name
Tabela 17.1, “Opções de Clonagem de Recursos” descreve as opções que você pode especificar para um
recurso clonado.
Tabela 17.1. Opções de Clonagem de Recursos
Campo Descrição
priority, target-role, is-managed Opções herdadas do recurso que está sendo

clonado, conforme descrito em Tabela 10.3, “Meta
Opções de Recursos”.
clone-max Quantas cópias do recurso para começar. O número

de nós no agrupamento é o padrão.
clone-node-max Quantas cópias do recurso podem ser iniciadas em

um único nó; o valor padrão é 1.
notify Ao parar ou iniciar uma cópia do clone, informe todas

as outras cópias com antecedência e quando a ação
foi bem sucedida. Valores permitidos: false, true. O
valor padrão é false.
globally-unique Cada cópia do clone desempenha uma função

diferente? Valores permitidos: false, true
Se o valor desta opção é false, estes recursos se

comportam de forma idêntica em todos os lugares
onde estão funcionando e, portanto, pode haver
apenas uma cópia do clone ativo por máquina.
Se o valor desta opção for true, uma cópia do clone

rodando em uma máquina não é equivalente a outra
instância, quer essa instância esteja rodando em
outro nó ou no mesmo nó. O valor padrão é true se o
valor de clone-node-max for maior que um; caso
contrário, o valor padrão é false.
170
Campo Descrição
ordered Caso as cópias sejam iniciadas em série (ao invés de

em paralelo). Valores permitidos: false, true. O valor
padrão é false.
interleave Muda o comportamento das restrições de pedidos

(entre clones) para que as cópias do primeiro clone
possam começar ou parar assim que a cópia no
mesmo nó do segundo clone tenha começado ou
parado (em vez de esperar até que cada instância do
segundo clone tenha começado ou parado). Valores
permitidos: false, true. O valor padrão é false.
clone-min Se um valor for especificado, quaisquer clones que

forem pedidos após este clone não poderão
começar até que o número especificado de
instâncias do clone original esteja em execução,
mesmo que a opção interleave esteja definida para
true.
Para alcançar um padrão de alocação estável, os clones são ligeiramente pegajosos por padrão, o que
indica que eles têm uma ligeira preferência por permanecer no nó em que estão correndo. Se não for
fornecido um valor para resource-stickiness, o clone usará um valor de 1. Sendo um valor pequeno, ele
causa uma perturbação mínima nos cálculos de pontuação de outros recursos, mas é suficiente para
evitar que o Pacemaker movimente desnecessariamente cópias em torno do agrupamento. Para
informações sobre a configuração da meta-opção de recursos resource-stickiness, consulte
Configurando as meta-opções de recursos .
17.2. CONFIGURAÇÃO DE RESTRIÇÕES DE RECURSOS CLONAIS

Na maioria dos casos, um clone terá uma única cópia em cada nó ativo de cluster. Você pode, no
entanto, definir clone-max para o recurso clone para um valor menor do que o número total de nós no
cluster. Se este for o caso, você pode indicar a quais nós o cluster deve, preferencialmente, atribuir
cópias com restrições de localização de recursos. Estas restrições não são escritas de maneira diferente
daquelas para recursos regulares, exceto que a identificação do clone deve ser usada.
O seguinte comando cria uma restrição de localização para que o cluster atribua preferencialmente o
clone de recursos webfarm-clone para node1.
# pcs constraint location webfarm-clone prefers node1
As restrições de pedidos comportam-se de forma ligeiramente diferente para os clones. No exemplo

abaixo, porque a opção de clonagem interleave é deixada por padrão como false, nenhuma instância de
webfarm-stats começará até que todas as instâncias de webfarm-clone que precisam ser iniciadas o
tenham feito. Somente se nenhuma cópia de webfarm-clone puder ser iniciada, então webfarm-stats
será impedida de ser ativada. Além disso, webfarm-clone aguardará que webfarm-stats seja
interrompido antes de parar por si mesmo.
# pcs constraint order start webfarm-clone then webfarm-stats
A colocação de um recurso regular (ou de grupo) com um clone significa que o recurso pode funcionar
171
A colocação de um recurso regular (ou de grupo) com um clone significa que o recurso pode funcionar
em qualquer máquina com uma cópia ativa do clone. O grupo escolherá uma cópia com base no local
onde o clone está rodando e nas preferências de localização do próprio recurso.
A recolocação entre clones também é possível. Nesses casos, o conjunto de locais permitidos para o
clone é limitado aos nós nos quais o clone está (ou estará) ativo. A alocação é então realizada como
normalmente.
O seguinte comando cria uma restrição de colocação para garantir que o recurso webfarm-stats
funcione no mesmo nó que uma cópia ativa de webfarm-clone.
# pcs constraint colocation add webfarm-stats with webfarm-clone
17.3. CRIAÇÃO DE RECURSOS DE CLONAGEM PROMOCIONAIS

Os recursos de clonagem promocionais são recursos de clonagem com o meta atributo promotable
definido para true. Eles permitem que as instâncias estejam em um dos dois modos operacionais; estes
são chamados Master e Slave. Os nomes dos modos não têm significados específicos, exceto pela
limitação de que quando uma instância é iniciada, ela deve aparecer no estado Slave.
17.3.1. Criando um recurso promocional

Você pode criar um recurso como um clone promocional com o seguinte comando único.
pcs resource create resource_id [standard:[provider:]]type [resource options] promocional [clone

options]
O nome do clone promocional será resource_id-clone.
Alternativamente, você pode criar um recurso promocional a partir de um recurso ou grupo de recursos
previamente criado com o seguinte comando. O nome do clone promocional será resource_id-clone ou
group_name-clone.
recursos pcs promocionais resource_id [clone options]
Tabela 17.2, “Opções extras de clones disponíveis para clones promocionais” descreve as opções de
clonagem extra que você pode especificar para um recurso promocional.
Tabela 17.2. Opções extras de clones disponíveis para clones promocionais
Campo Descrição
promoted-max Quantas cópias do recurso podem ser promovidas;

padrão 1.
promoted-node-max Quantas cópias do recurso podem ser promovidas

em um único nó; padrão 1.
17.3.2. Configuração de restrições de recursos promocionais

Na maioria dos casos, um recurso promocional terá uma única cópia em cada nó ativo de cluster. Se
este não for o caso, você pode indicar a quais nós o agrupamento deve, preferencialmente, atribuir
172
cópias com restrições de localização de recursos. Estas restrições não são escritas de maneira diferente
daquelas para os recursos regulares.
Você pode criar uma restrição de colocação que especifica se os recursos estão operando em um papel
de mestre ou de escravo. O seguinte comando cria uma restrição de colocação de recursos.
pcs constraint colocation add [master|slave] source_resource com [master|slave] target_resource

[score] [options]
Para informações sobre restrições de colocação, consulte Colocando recursos de agrupamento .
Ao configurar uma restrição de pedido que inclui recursos promocionais, uma das ações que você pode
especificar para os recursos é promote, indicando que o recurso seja promovido do papel de escravo
para o papel de mestre. Além disso, você pode especificar uma ação de demote, indicando que o
recurso deve ser rebaixado do papel de mestre para o papel de escravo.
O comando para configurar uma restrição de ordem é o seguinte.
pedido de restrição pcs [action] resource_id e depois [action] resource_id [options]
Para informações sobre restrições de pedidos de recursos, ver ifdef:: Determinar a ordem em que os
recursos de agrupamento são executados.
17.4. DEMONSTRANDO UM RECURSO PROMOVIDO SOBRE O

FRACASSO (RHEL 8.3 E POSTERIORES)
Você pode configurar um recurso promocional para que quando uma ação promote ou monitor falhar
para esse recurso, ou a partição na qual o recurso está rodando perder quorum, o recurso será rebaixado
mas não será totalmente interrompido. Isto pode evitar a necessidade de intervenção manual em
situações em que a parada total do recurso o exigiria.
Para configurar um recurso promocional a ser rebaixado quando uma ação promote falhar,
defina a meta-opção da operação on-fail para demote, como no exemplo a seguir.
# pcs resource op add my-rsc promote on-fail="demote"
Para configurar um recurso promocional a ser rebaixado quando uma ação monitor falhar,
defina interval para um valor não zero, defina a meta-opção de operação on-fail para demote,
e defina role para Master, como no exemplo a seguir.
# pcs resource op add my-rsc monitor interval="10s" on-fail="demote" role="Master"
Para configurar um cluster para que, quando uma partição de cluster perder quorum, quaisquer
recursos promovidos sejam despromovidos mas deixados em funcionamento e todos os outros
recursos sejam interrompidos, defina a propriedade do cluster no-quorum-policy para demote
Especificar um meta-atributo demote para uma operação não afeta como a promoção de um recurso é
determinada. Se o nó afetado ainda tiver a maior pontuação de promoção, ele será selecionado para ser
promovido novamente.
173
CAPÍTULO 18. GERENCIANDO NÓS DE CLUSTER

As seções seguintes descrevem os comandos usados para gerenciar os nós de cluster, incluindo
comandos para iniciar e parar serviços de cluster e para adicionar e remover nós de cluster.
18.1. PARAR OS SERVIÇOS DE CLUSTER

O seguinte comando pára os serviços de agrupamento no nó ou nós especificados. Como com o pcs
cluster start, a opção --all interrompe os serviços de cluster em todos os nós e se você não especificar
nenhum nó, os serviços de cluster são interrompidos somente no nó local.
pcs cluster stop [--tudo | node] [...] [..
Você pode forçar uma parada dos serviços de cluster no nó local com o seguinte comando, que executa
um comando kill -9.
pcs cluster kill
18.2. HABILITAÇÃO E DESATIVAÇÃO DE SERVIÇOS DE CLUSTER

Use o seguinte comando para habilitar os serviços de cluster, que configura os serviços de cluster para
serem executados na inicialização no nó ou nós especificados. A ativação permite que os nós se juntem
novamente ao cluster automaticamente após terem sido cercados, minimizando o tempo em que o
cluster está com menos de força total. Se os serviços de cluster não forem habilitados, um administrador
pode investigar manualmente o que deu errado antes de iniciar os serviços de cluster manualmente, de
modo que, por exemplo, um nó com problemas de hardware não possa voltar ao cluster quando for
provável que falhe novamente.
Se você especificar a opção --all, o comando permite serviços de cluster em todos os nós.
Se você não especificar nenhum nó, os serviços de cluster são habilitados somente no nó local.
pcs cluster enable [--all | node] [...] [..
Use o seguinte comando para configurar os serviços de cluster para não serem executados na
inicialização no nó ou nós especificados.
Se você especificar a opção --all, o comando desabilita os serviços de cluster em todos os nós.
Se você não especificar nenhum nó, os serviços de cluster são desativados somente no nó local.
pcs cluster disable [--all | node] [...] [..
18.3. ADIÇÃO DE NÓS DE CLUSTER
NOTA
É altamente recomendável que você adicione nós aos agrupamentos existentes somente
durante uma janela de manutenção da produção. Isto permite que você realize os testes
apropriados de recursos e implantação para o novo nó e sua configuração de cercas.
Use o seguinte procedimento para adicionar um novo nó a um agrupamento existente. Este

174
Use o seguinte procedimento para adicionar um novo nó a um agrupamento existente. Este

procedimento adiciona nós de clusters padrão rodando corosync. Para informações sobre a integração
de nós não-corossincronos em um cluster, consulte Integração de nós não-corossincronos em um
cluster: o serviço pacemaker_remote.
Neste exemplo, os nós de agrupamento existentes são clusternode-01.example.com, clusternode-

02.example.com, e clusternode-03.example.com. O novo nó é newnode.example.com.
No novo nó a ser adicionado ao agrupamento, execute as seguintes tarefas.
1. Instalar os pacotes de cluster. Se o cluster utiliza a SBD, o gerente de tickets do estande ou um

dispositivo de quorum, você deve instalar manualmente os respectivos pacotes (sbd, booth-
site, corosync-qdevice) no novo nó também.
[root@newnode ~]# yum install -y pcs fence-agents-all
Além dos pacotes de cluster, você também precisará instalar e configurar todos os serviços que
você está executando no cluster, os quais você instalou nos nós de cluster existentes. Por
exemplo, se você estiver rodando um servidor Apache HTTP em um cluster de alta
disponibilidade da Red Hat, você precisará instalar o servidor no nó que está adicionando, assim
como a ferramenta wget que verifica o status do servidor.

3. Defina uma senha para o ID do usuário hacluster. Recomenda-se utilizar a mesma senha para
cada nó do cluster.
[root@newnode ~]# passwd hacluster

New password:
4. Execute os seguintes comandos para iniciar o serviço pcsd e para habilitar pcsd no início do
sistema.

Em um nó do agrupamento existente, executar as seguintes tarefas.
1. Autenticar o usuário hacluster no novo nó de cluster.
[root@clusternode-01 ~]# pcs host auth newnode.example.com

Username: hacluster
Password:
newnode.example.com: Authorized
2. Adicionar o novo nó ao agrupamento existente. Este comando também sincroniza o arquivo de

configuração do cluster corosync.conf com todos os nós do cluster, incluindo o novo nó que
você está adicionando.
175
[root@clusternode-01 ~]# pcs cluster node add newnode.example.com
No novo nó a ser adicionado ao agrupamento, execute as seguintes tarefas.
1. Iniciar e habilitar serviços de cluster no novo nó.
[root@newnode ~]# pcs cluster start

Starting Cluster...
[root@newnode ~]# pcs cluster enable
2. Certifique-se de configurar e testar um dispositivo de esgrima para o novo nó de cluster.
18.4. REMOÇÃO DE NÓS DE CLUSTER

O seguinte comando desliga o nó especificado e o remove do arquivo de configuração do cluster,
corosync.conf, em todos os outros nós do cluster.
pcs remover nó de cluster node
18.5. ADICIONANDO UM NÓ A UM AGRUPAMENTO COM MÚLTIPLOS

LINKS
Ao adicionar um nó a um agrupamento com múltiplos links, você deve especificar endereços para todos
os links. O exemplo seguinte adiciona o nó rh80-node3 a um cluster, especificando o endereço IP
192.168.122.203 para o primeiro link e 192.168.123.203 como o segundo link.
# pcs cluster node add rh80-node3 addr=192.168.122.203 addr=192.168.123.203
18.6. ADIÇÃO E MODIFICAÇÃO DE LINKS EM UM CLUSTER EXISTENTE

(RHEL 8.1 E POSTERIORES)
Na maioria dos casos, você pode adicionar ou modificar os links em um cluster existente sem reiniciar o
cluster.
18.6.1. Adicionar e remover links em um cluster existente

Para adicionar um novo link para um cluster em execução, use o comando pcs cluster link add.
Ao adicionar um link, você deve especificar um endereço para cada nó.
Adicionar e remover um link só é possível quando se está usando o protocolo de transporte de

nós.
Pelo menos um link no agrupamento deve ser definido a qualquer momento.
O número máximo de links em um agrupamento é 8, numerados de 0 a 7. Não importa quais

links são definidos, assim, por exemplo, você pode definir apenas os links 3, 6 e 7.
Quando você adiciona um link sem especificar seu número de link, pcs usa o link mais baixo
disponível.
Os números dos links atualmente configurados estão contidos no arquivo corosync.conf. Para
176
Os números dos links atualmente configurados estão contidos no arquivo corosync.conf. Para
exibir o arquivo corosync.conf, execute o comando pcs cluster corosync.
O seguinte comando adiciona o link número 5 a um agrupamento de três nós.
[root@node1 ~] # pcs cluster link add node1=10.0.5.11 node2=10.0.5.12 node3=10.0.5.31

options linknumber=5
Para remover um link existente, use o comando pcs cluster link delete ou pcs cluster link remove.
Qualquer um dos comandos a seguir removerá o link número 5 do agrupamento.
[root@node1 ~] # pcs cluster link delete 5
[root@node1 ~] # pcs cluster link remove 5
18.6.2. Modificação de um link em um cluster com múltiplos links

Se houver vários links no agrupamento e você quiser mudar um deles, execute o procedimento a seguir.
1. Remova o link que você deseja mudar.
2. Adicione o link de volta ao cluster com os endereços e opções atualizados.
[root@node1 ~] # pcs cluster link add node1=10.0.5.11 node2=10.0.5.12

node3=10.0.5.31 options linknumber=2
18.6.3. Modificando os endereços dos links em um cluster com um único link

Se seu agrupamento utiliza apenas um link e você deseja modificar esse link para utilizar endereços
diferentes, execute o procedimento a seguir. Neste exemplo, o link original é o link 1.
1. Adicione um novo link com os novos endereços e opções.
[root@node1 ~] # pcs cluster link add node1=10.0.5.11 node2=10.0.5.12

node3=10.0.5.31 options linknumber=2
2. Remover o link original.
Observe que você não pode especificar endereços que estão em uso no momento ao adicionar links a
um cluster. Isto significa, por exemplo, que se você tiver um cluster de dois nós com um link e quiser
alterar o endereço de apenas um nó, você não pode usar o procedimento acima para adicionar um novo
link que especifique um novo endereço e um endereço existente. Ao invés disso, você pode adicionar um
link temporário antes de remover o link existente e adicioná-lo de volta com o endereço atualizado,
como no exemplo a seguir.
Neste exemplo:
O link para o agrupamento existente é o link 1, que usa o endereço 10.0.5.11 para o nó 1 e o
endereço 10.0.5.12 para o nó 2.
177
Você gostaria de mudar o endereço do nó 2 para 10.0.5.31.
Para atualizar apenas um dos endereços de um cluster de dois nós com um único link, use o seguinte
procedimento.
1. Adicionar um novo link temporário ao cluster existente, utilizando endereços que não estão em
uso atualmente.
[root@node1 ~] # pcs cluster link add node1=10.0.5.13 node2=10.0.5.14 options

linknumber=2
3. Adicione o novo e modificado link.

linknumber=1
4. Remova o vínculo temporário que você criou
18.6.4. Modificando as opções de link para um link em um cluster com um único link
Se seu agrupamento utiliza apenas um link e você deseja modificar as opções para esse link mas não
deseja modificar o endereço a ser utilizado, você pode adicionar um link temporário antes de remover e
atualizar o link para modificar.
Neste exemplo:
O link para o agrupamento existente é o link 1, que usa o endereço 10.0.5.11 para o nó 1 e o
endereço 10.0.5.12 para o nó 2.
Você gostaria de mudar a opção de link link_priority para 11.
Use o seguinte procedimento para modificar a opção de link em um cluster com um único link.
1. Adicionar um novo link temporário ao cluster existente, utilizando endereços que não estão em
uso atualmente.

linknumber=2
3. Adicione de volta o link original com as opções atualizadas.

linknumber=1 link_priority=11
178
4. Remover o vínculo temporário.
18.6.5. Modificar um link ao adicionar um novo link não é possível

Se por algum motivo não for possível adicionar um novo link em sua configuração e sua única opção for
modificar um único link existente, você pode usar o seguinte procedimento, o que requer que você
feche seu cluster.
O seguinte procedimento de exemplo atualiza o link número 1 no agrupamento e estabelece a opção

link_priority para o link 11.
1. Pare os serviços de agrupamento para o agrupamento.
[root@node1 ~] # pcs cluster stop --all
2. Atualizar os endereços e opções do link.

O comando pcs cluster link update não exige que você especifique todos os endereços e
opções dos nós. Ao invés disso, você pode especificar apenas os endereços a serem alterados.
Este exemplo modifica os endereços para node1 e node3 e a opção link_priority apenas.
[root@node1 ~] # pcs cluster link update 1 node1=10.0.5.11 node3=10.0.5.31 options

link_priority=11
Para remover uma opção, você pode definir a opção para um valor nulo com o option=
formato.
3. Reiniciar o conjunto
[root@node1 ~] # pcs cluster start --all
18.7. CONFIGURAÇÃO DE UM GRANDE CLUSTER COM MUITOS

RECURSOS
Se o cluster que você está implantando consiste de um grande número de nós e muitos recursos, você
pode precisar modificar os valores padrão dos seguintes parâmetros para seu cluster.
A propriedade do clustercluster-ipc-limit
A propriedade de cluster cluster-ipc-limit é o backlog máximo de mensagens IPC antes que um
daemon de cluster desconecte outro. Quando um grande número de recursos é limpo ou modificado
simultaneamente em um grande aglomerado, um grande número de atualizações CIB chega de uma
só vez. Isto pode fazer com que clientes mais lentos sejam despejados se o serviço Pacemaker não
tiver tempo para processar todas as atualizações de configuração antes que o limite da fila de
eventos CIB seja atingido.
O valor recomendado de cluster-ipc-limit para uso em grandes clusters é o número de recursos no
cluster multiplicado pelo número de nós. Este valor pode ser aumentado se você vir mensagens de
"Evicting client" para PIDs de clusters nos logs.
Você pode aumentar o valor de cluster-ipc-limit a partir de seu valor padrão de 500 com o
comando pcs property set. Por exemplo, para um cluster de dez nós com 200 recursos, você pode
definir o valor de cluster-ipc-limit para 2000 com o seguinte comando.
179
# pcs property set cluster-ipc-limit=2000
O parâmetro PCMK_ipc_buffer Pacemaker

Em implantações muito grandes, as mensagens internas do marca-passo podem exceder o tamanho
do buffer de mensagens. Quando isto ocorrer, você verá uma mensagem nos logs do sistema no
seguinte formato:
Compressed message exceeds X% of configured IPC limit (X bytes); consider setting

PCMK_ipc_buffer to X or higher
Ao ver esta mensagem, você pode aumentar o valor de PCMK_ipc_buffer no arquivo de

configuração /etc/sysconfig/pacemaker em cada nó. Por exemplo, para aumentar o valor de
PCMK_ipc_buffer de seu valor padrão para 13396332 bytes, altere o campo não comentado
PCMK_ipc_buffer no arquivo /etc/sysconfig/pacemaker em cada nó do cluster da seguinte forma.
PCMK_ipc_buffer=13396332
Para aplicar esta mudança, execute o seguinte comando.
# systemctl restart pacemaker
180
CAPÍTULO 19. DEFINIR PERMISSÕES DE USUÁRIO PARA UM CLUSTER DE PACEMAKER
CAPÍTULO 19. DEFINIR PERMISSÕES DE USUÁRIO PARA UM

CLUSTER DE PACEMAKER
Você pode conceder permissão para outros usuários específicos além do usuário hacluster para
gerenciar um cluster Pacemaker. Há dois conjuntos de permissões que você pode conceder a usuários
individuais:
Permissões que permitem aos usuários individuais gerenciar o cluster através da interface Web
e executar comandos pcs que se conectam aos nós através de uma rede. Os comandos que se
conectam aos nós através de uma rede incluem comandos para configurar um cluster, ou para
adicionar ou remover nós de um cluster.
Permissões para usuários locais para permitir o acesso somente leitura ou leitura-escrita à
configuração do cluster. Os comandos que não requerem conexão através de uma rede incluem
comandos que editam a configuração do cluster, tais como os que criam recursos e configuram
restrições.
Em situações onde ambos os conjuntos de permissões foram atribuídos, as permissões para comandos
que se conectam através de uma rede são aplicadas primeiro, e depois as permissões para editar a
configuração do cluster no nó local são aplicadas. A maioria dos comandos pcs não exige acesso à rede
e, nesses casos, as permissões de rede não serão aplicadas.
19.1. DEFINIR PERMISSÕES PARA O ACESSO DOS NÓS ATRAVÉS DE

UMA REDE
Para conceder permissão a usuários específicos para gerenciar o cluster através da interface Web e
executar comandos pcs que se conectam aos nós através de uma rede, adicione esses usuários ao
grupo haclient. Isto deve ser feito em todos os nós do cluster.
19.2. DEFINIR PERMISSÕES LOCAIS USANDO ACLS

Você pode usar o comando pcs acl para definir permissões para usuários locais para permitir acesso
somente leitura ou leitura-escrita à configuração do cluster, usando listas de controle de acesso (ACLs).
Por padrão, as ACLs não são habilitadas. Quando as ACLs não são ativadas, o usuário root e qualquer
usuário que seja membro do grupo haclient em todos os nós tem acesso local completo à configuração
do cluster enquanto os usuários que não são membros do haclient não têm acesso. Quando as ACLs
são ativadas, entretanto, mesmo os usuários que são membros do grupo haclient têm acesso apenas
ao que foi concedido a esse usuário pelas ACLs.
A definição de permissões para usuários locais é um processo em duas etapas:
1. Executar o comando pcs acl role create… para criar um role que define as permissões para
essa função.
2. Atribua a função que você criou a um usuário com o comando pcs acl user create. Se você
atribuir várias funções ao mesmo usuário, qualquer permissão deny tem precedência, então
write, então read.
O seguinte procedimento de exemplo fornece acesso somente leitura para uma configuração de cluster
a um usuário local chamado rouser. Note que também é possível restringir o acesso apenas a certas
partes da configuração.
181

ATENÇÃO
É importante realizar este procedimento como raiz ou salvar todas as atualizações

de configuração em um arquivo de trabalho que você pode então empurrar para a
CIB ativa quando estiver terminado. Caso contrário, você pode se bloquear de fazer
qualquer outra alteração. Para informações sobre como salvar atualizações de
configuração em um arquivo de trabalho, consulte Salvando uma mudança de
configuração em um arquivo de trabalho.
1. Este procedimento exige que o usuário rouser exista no sistema local e que o usuário rouser
seja um membro do grupo haclient.
# adduser rouser
# usermod -a -G haclient rouser
2. Habilite as ACLs do Pacemaker com o comando pcs acl enable.
# pcs acl enable
3. Criar uma função chamada read-only com permissões somente de leitura para a cib.
# pcs acl role create read-only description="Read access to cluster" read xpath /cib
4. Criar o usuário rouser no sistema ACL da pcs e atribuir a esse usuário a função read-only.
# pcs acl user create rouser read-only
5. Veja as ACLs atuais.
# pcs acl
User: rouser
Roles: read-only
Role: read-only
Description: Read access to cluster
Permission: read xpath /cib (read-only-read)
182
CAPÍTULO 20. OPERAÇÕES DE MONITORAMENTO DE RECURSOS
CAPÍTULO 20. OPERAÇÕES DE MONITORAMENTO DE

RECURSOS
Para garantir que os recursos permaneçam saudáveis, você pode acrescentar uma operação de
monitoramento à definição de um recurso. Se você não especificar uma operação de monitoramento
para um recurso, por padrão o comando pcs criará uma operação de monitoramento, com um intervalo
que é determinado pelo agente do recurso. Se o agente de recursos não fornecer um intervalo de
monitoramento padrão, o comando pcs criará uma operação de monitoramento com um intervalo de 60
segundos.
Tabela 20.1, “Propriedades de uma operação” resume as propriedades de uma operação de

monitoramento de recursos.
Tabela 20.1. Propriedades de uma operação
Campo Descrição
id Nome único para a ação. O sistema atribui isto quando você configura uma
operação.
name A ação a realizar. Valores comuns: monitor, start, stop
interval Se definido para um valor diferente de zero, é criada uma operação recorrente
que se repete nesta freqüência, em segundos. Um valor diferente de zero só faz
sentido quando a ação name é definida para monitor. Uma ação de
monitoramento recorrente será executada imediatamente após o início de um
recurso, e as ações de monitoramento subseqüentes são programadas a partir do
momento em que a ação de monitoramento anterior for concluída. Por exemplo,
se uma ação de monitoramento com interval=20s for executada à 01:00:00, a
próxima ação de monitoramento não ocorrerá à 01:00:20, mas aos 20 segundos
após a conclusão da primeira ação de monitoramento.
Se definido como zero, que é o valor padrão, este parâmetro permite fornecer
valores a serem usados para operações criadas pelo cluster. Por exemplo, se o
interval for definido como zero, o name da operação é definido como start, e o
valor timeout é definido como 40, então o Pacemaker usará um timeout de 40
segundos ao iniciar este recurso. Uma operação monitor com intervalo zero
permite definir os valores de timeout / on-fail/ enabled para as sondas que o
Pacemaker faz na inicialização para obter o status atual de todos os recursos
quando os padrões não são desejáveis.
timeout Se a operação não for concluída no tempo definido por este parâmetro, abortar a
operação e considerá-la fracassada. O valor padrão é o valor de timeout se
configurado com o comando pcs resource op defaults, ou 20 segundos se
não estiver configurado. Se você descobrir que seu sistema inclui um recurso que
requer mais tempo do que o sistema permite para realizar uma operação (como
start, stop, ou monitor), investigue a causa e se o longo tempo de execução é
esperado, você pode aumentar este valor.
O valor timeout não é um atraso de nenhum tipo, nem o cluster espera todo o
período de timeout se a operação retornar antes que o período de timeout tenha
terminado.
183
Campo Descrição
on-fail A ação a ser tomada se esta ação falhar. Os valores permitidos:
* ignore - Finja que o recurso não falhou
* block - Não realizar nenhuma outra operação sobre o recurso
* stop - Pare o recurso e não o inicie em outro lugar
* restart - Pare o recurso e inicie-o novamente (possivelmente em um nó

diferente)
* fence - STONITH o nó sobre o qual o recurso falhou
* standby - Afastar all recursos do nó em que o recurso falhou
* demote - Quando uma ação promote falha para o recurso, o recurso será
rebaixado, mas não será totalmente interrompido. Quando uma ação monitor
falhar para um recurso, se interval estiver definido para um valor diferente de
zero e role estiver definido para Master, o recurso será rebaixado, mas não será
totalmente interrompido.
O padrão para a operação stop é fence quando a STONITH está habilitada e

block caso contrário. Todas as outras operações são padrão para restart.
enabled Se false, a operação é tratada como se ela não existisse. Valores permitidos:true,
false
20.1. CONFIGURAÇÃO DE OPERAÇÕES DE MONITORAMENTO DE

RECURSOS
Você pode configurar as operações de monitoramento ao criar um recurso, usando o seguinte comando.
pcs resource create resource_id standard:provider:type|type [resource_options] [op operation_action

operation_options [operation_type operation_options ]...]
Por exemplo, o seguinte comando cria um recurso IPaddr2 com uma operação de monitoramento. O
novo recurso é chamado VirtualIP com um endereço IP de 192.168.0.99 e uma máscara de rede de 24
em eth2. Uma operação de monitoramento será realizada a cada 30 segundos.
# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.99 cidr_netmask=24

nic=eth2 op monitor interval=30s
Alternativamente, você pode adicionar uma operação de monitoramento a um recurso existente com o
seguinte comando.
pcs resource op adicionar resource_id operation_action [operation_properties]
Use o seguinte comando para excluir uma operação de recurso configurado.
pcs resource op remove resource_id operation_name operation_properties
NOTA
184
NOTA
Você deve especificar as propriedades exatas da operação para remover corretamente

uma operação existente.
Para alterar os valores de uma opção de monitoramento, você pode atualizar o recurso. Por exemplo,
você pode criar um VirtualIP com o seguinte comando.

nic=eth2
Por padrão, este comando cria estas operações.
Operations: start interval=0s timeout=20s (VirtualIP-start-timeout-20s)

stop interval=0s timeout=20s (VirtualIP-stop-timeout-20s)
monitor interval=10s timeout=20s (VirtualIP-monitor-interval-10s)
Para alterar a operação de parada, execute o seguinte comando.
# pcs resource update VirtualIP op stop interval=0s timeout=40s
# pcs resource show VirtualIP

Resource: VirtualIP (class=ocf provider=heartbeat type=IPaddr2)
Attributes: ip=192.168.0.99 cidr_netmask=24 nic=eth2
monitor interval=10s timeout=20s (VirtualIP-monitor-interval-10s)
stop interval=0s timeout=40s (VirtualIP-name-stop-interval-0s-timeout-40s)
20.2. CONFIGURAÇÃO DE PADRÕES DE OPERAÇÃO DE RECURSOS

GLOBAIS
A partir do Red Hat Enterprise Linux 8.3, você pode alterar o valor default de uma operação de recurso
para todos os recursos com o comando pcs resource op defaults update. O seguinte comando define
o valor default global de um timeout de 240 segundos para todas as operações de monitoramento.
# pcs resource op defaults update timeout=240s
O original pcs resource op defaults name=value que define os padrões de operação de recursos para
todos os recursos em versões anteriores do RHEL 8, continua sendo suportado, a menos que haja mais
de um conjunto de padrões configurado. Entretanto, pcs resource op defaults update é agora a
versão preferida do comando.
20.2.1. Valores de operação superiores aos recursos específicos

Observe que um recurso de cluster usará o padrão global somente quando a opção não estiver
especificada na definição do recurso de cluster. Por padrão, os agentes de recursos definem a opção
timeout para todas as operações. Para que o valor de timeout global da operação seja honrado, você
deve criar o recurso de cluster sem a opção timeout explicitamente ou deve remover a opção timeout
atualizando o recurso de cluster, como no seguinte comando.
# pcs resource update VirtualIP op monitor interval=10s
185
Por exemplo, após definir um valor padrão global de 240 segundos para timeout para todas as
operações de monitoramento e atualizar o recurso de cluster VirtualIP para remover o valor de timeout
para a operação monitor, o recurso VirtualIP terá então valores de timeout para start, stop e monitor
operações de 20s, 40s e 240s, respectivamente. O valor padrão global para operações de timeout é
aplicado aqui apenas na operação monitor, onde a opção padrão timeout foi removida pelo comando
anterior.
# pcs resource show VirtualIP

Resource: VirtualIP (class=ocf provider=heartbeat type=IPaddr2)
Attributes: ip=192.168.0.99 cidr_netmask=24 nic=eth2
monitor interval=10s (VirtualIP-monitor-interval-10s)
stop interval=0s timeout=40s (VirtualIP-name-stop-interval-0s-timeout-40s)
20.2.2. Alteração do valor padrão de uma operação de recurso para conjuntos de

recursos (RHEL 8.3 e posteriores)
A partir do Red Hat Enterprise Linux 8.3, você pode criar múltiplos conjuntos de padrões de operação de
recursos com o comando pcs resource op defaults set create, que lhe permite especificar uma regra
que contém resource e expressões de operação. Somente resource e expressões de operação,
incluindo and, or e parênteses, são permitidas nas regras que você especificar com este comando.
Com este comando, você pode configurar um valor padrão de operação de recursos para todos os
recursos de um determinado tipo. Por exemplo, agora é possível configurar os recursos implícitos
podman criados pela Pacemaker quando os pacotes estão em uso.
O seguinte comando estabelece um valor de tempo limite padrão de 90s para todas as operações para
todos os recursos podman. Neste exemplo, ::podman significa um recurso de qualquer classe, de
qualquer fornecedor, do tipo podman.
A opção id, que nomeia o conjunto de recursos padrão de operação, não é obrigatória. Se você não
definir esta opção, pcs irá gerar uma identificação automaticamente. A definição deste valor permite
que você forneça um nome mais descritivo.
# pcs resource op defaults set create id=podman-timeout meta timeout=90s rule resource
::podman
O seguinte comando estabelece um valor padrão de tempo limite de 120s para a operação stop para
todos os recursos.
# pcs resource op defaults set create id=stop-timeout meta timeout=120s rule op stop
É possível definir o valor padrão de timeout para uma operação específica para todos os recursos de um
determinado tipo. O exemplo a seguir define um valor de timeout padrão de 120s para a operação stop
para todos os recursos podman.
# pcs resource op defaults set create id=podman-stop-timeout meta timeout=120s rule

resource ::podman and op stop
20.2.3. Exibição dos valores padrão de operação dos recursos atualmente

configurados
O comando pcs resource op defaults exibe uma lista de valores padrão configurados atualmente para
186
O comando pcs resource op defaults exibe uma lista de valores padrão configurados atualmente para
operações de recursos, incluindo quaisquer regras que você especificou.
O seguinte comando exibe os valores padrão de operação para um cluster que foi configurado com um
valor de timeout padrão de 90s para todas as operações de todos os recursos podman, e para o qual foi
definido um ID para o conjunto de padrões de operação de recursos como podman-timeout.
# pcs resource op defaults

Meta Attrs: podman-timeout
timeout=90s
Expression: resource ::podman
O seguinte comando exibe os valores padrão de operação para um cluster que foi configurado com um
valor de timeout padrão de 120s para a operação stop para todos os recursos podman, e para o qual foi
definido um ID para o conjunto de recursos padrão de operação como podman-stop-timeout.
# pcs resource op defaults

Meta Attrs: podman-stop-timeout
timeout=120s
Expression: resource ::podman
Expression: op stop
20.3. CONFIGURAÇÃO DE MÚLTIPLAS OPERAÇÕES DE

MONITORAMENTO
Você pode configurar um único recurso com tantas operações de monitoramento quanto um agente de
recursos suporta. Desta forma, você pode fazer um exame de saúde superficial a cada minuto e
progressivamente mais intenso em intervalos maiores.
NOTA
Ao configurar várias operações de monitoramento, você deve garantir que não sejam
realizadas duas operações no mesmo intervalo.
Para configurar operações de monitoramento adicionais para um recurso que suporte verificações mais
profundas em diferentes níveis, você adiciona um OCF_CHECK_LEVEL=n opção.
Por exemplo, se você configurar o seguinte recurso IPaddr2, por padrão isto cria uma operação de
monitoramento com um intervalo de 10 segundos e um valor de timeout de 20 segundos.

nic=eth2
Se o IP Virtual suporta uma verificação diferente com uma profundidade de 10, o seguinte comando faz
com que o Pacemaker realize a verificação de monitoramento mais avançada a cada 60 segundos, além
da verificação IP Virtual normal a cada 10 segundos. (Como observado, não se deve configurar a
operação de monitoramento adicional com um intervalo de 10 segundos também)
# pcs resource op add VirtualIP monitor interval=60s OCF_CHECK_LEVEL=10
187
CAPÍTULO 21. PROPRIEDADES DO CONJUNTO DO

MARCAPASSO
As propriedades do agrupamento controlam como o agrupamento se comporta quando confrontado
com situações que podem ocorrer durante a operação de agrupamento.
21.1. RESUMO DAS PROPRIEDADES E OPÇÕES DO CLUSTER

Tabela 21.1, “Propriedades do Cluster” resume as propriedades do Pacemaker cluster, mostrando os
valores padrão das propriedades e os possíveis valores que você pode definir para essas propriedades.
Há propriedades de agrupamento adicionais que determinam o comportamento das vedações. Para

informações sobre essas propriedades, consulte Opções avançadas de configuração de cercas .
NOTA
Além das propriedades descritas nesta tabela, há propriedades adicionais de cluster que
são expostas pelo software de cluster. Para estas propriedades, é recomendável não
alterar seus valores em relação a seus padrões.
Tabela 21.1. Propriedades do Cluster
batch-limit 0 O número de ações de recursos

que o agrupamento é permitido
executar em paralelo. O valor
"correto" dependerá da
velocidade e da carga de sua rede
e dos nós de cluster. O valor
padrão de 0 significa que o
cluster irá impor dinamicamente
um limite quando qualquer nó
tiver uma carga alta de CPU.
migration-limit -1 (ilimitado) O número de trabalhos de

migração que o agrupamento é
permitido executar em paralelo
em um nó.
188
CAPÍTULO 21. PROPRIEDADES DO CONJUNTO DO MARCAPASSO
no-quorum-policy parar O que fazer quando o conjunto

não tem quorum. Valores
permitidos:
* ignorar - continuar toda a

gestão de recursos
* congelar - continuar o
gerenciamento de recursos, mas
não recuperar recursos de nós
que não estejam na partição
afetada
* parar - parar todos os recursos

na partição do cluster afetado
* suicídio - cercar todos os nós na

divisória de cluster afetada
* demote - se uma partição de

cluster perder quorum, demote
quaisquer recursos promovidos e
pare todos os outros recursos
symmetric-cluster verdadeiro Indica se os recursos podem ser

executados em qualquer nó por
padrão.
cluster-delay 60s Atraso de ida e volta sobre a rede

(excluindo a execução da ação).
O valor "correto" dependerá da
velocidade e da carga de sua rede
e dos nós de cluster.
stop-orphan-resources verdadeiro Indica se os recursos eliminados

devem ser suspensos.
stop-orphan-actions verdadeiro Indica se as ações eliminadas

devem ser canceladas.
189
start-failure-is-fatal verdadeiro Indica se a falha em iniciar um

recurso em um determinado nó
impede novas tentativas de iniciar
esse nó. Quando ajustado para
false, o agrupamento decidirá se
deve tentar iniciar no mesmo nó
novamente com base na
contagem atual de falhas e no
limiar de migração do recurso.
Para informações sobre como
configurar a opção migration-
threshold para um recurso, veja
Configurando as meta opções de
recursos.
Ajustando start-failure-is-fatal
para false corre-se o risco de que
isso permita que um nó
defeituoso, incapaz de iniciar um
recurso, possa atrasar todas as
ações dependentes. É por isso
que start-failure-is-fatal é o
padrão da verdade. O risco de
definir start-failure-is-
fatal=false pode ser mitigado ao
estabelecer um baixo limiar de
migração para que outras ações
possam prosseguir após muitas
falhas.
pe-error-series-max -1 (todos) O número de entradas do

programador resultando em
ERRORs para economizar. Usado
ao relatar problemas.
pe-warn-series-max -1 (todos) O número de entradas do

programador resultando em
ADVERTÊNCIAS a serem salvas.
Usado ao relatar problemas.
pe-input-series-max -1 (todos) O número de entradas "normais"

do agendador para economizar.
Usado ao relatar problemas.
cluster-infrastructure A pilha de mensagens sobre a

qual a Pacemaker está
atualmente funcionando. Utilizada
para fins de informação e
diagnóstico; não é configurável
pelo usuário.
190
dc-version Versão do Pacemaker no

Controlador Designado (DC) do
cluster. Utilizado para fins de
diagnóstico; não configurável
pelo usuário.
cluster-recheck-interval 15 minutos Intervalo de votação para

mudanças baseadas no tempo
para opções, parâmetros de
recursos e restrições. Valores
permitidos: Zero desativa a
votação, os valores positivos são
um intervalo em segundos (a
menos que outras unidades SI
sejam especificadas, tais como
5min). Observe que este valor é o
tempo máximo entre verificações;
se um evento de cluster ocorrer
mais cedo do que o tempo
especificado por este valor, a
verificação será feita mais cedo.
maintenance-mode falso O modo de manutenção diz ao

grupo para ir para um modo "mãos
desligadas", e não iniciar ou parar
qualquer serviço até que seja dito
o contrário. Quando o modo de
manutenção é concluído, o
cluster faz uma verificação de
sanidade do estado atual de
qualquer serviço, e então pára ou
inicia qualquer serviço que
precise dele.
shutdown-escalation 20min O tempo depois do qual desistir

de tentar fechar graciosamente e
simplesmente sair. Somente para
uso avançado.
stop-all-resources falso Caso o agrupamento interrompa

todos os recursos.
enable-acl falso Indica se o cluster pode utilizar

listas de controle de acesso,
conforme definido com o
comando pcs acl.
191
placement-strategy default Indica se e como o agrupamento

levará em conta os atributos de
utilização ao determinar a
colocação de recursos nos nós do
agrupamento.
priority-fencing-delay 0 (inválido) (RHEL 8.3 e posteriores) Permite

configurar um agrupamento de
dois nós de modo que, em uma
situação de cérebro dividido, o nó
com menos recursos em
funcionamento seja o nó que é
cercado.
A propriedade priority-fencing-
delay pode ser definida para uma
duração de tempo. O valor padrão
para esta propriedade é 0
(desabilitado). Se esta
propriedade for definida para um
valor diferente de zero, e o meta-
atributo priority for configurado
para pelo menos um recurso,
então em uma situação de
cérebro dividido, o nó com a
maior prioridade combinada de
todos os recursos que correm
sobre ele terá mais probabilidade
de sobreviver.
Por exemplo, se você definir pcs

resource defaults priority=1 e
pcs property set priority-
fencing-delay=15s e nenhuma
outra prioridade for definida,
então o nó com mais recursos
terá mais probabilidade de
sobreviver porque o outro nó
esperará 15 segundos antes de
iniciar a esgrima. Se um
determinado recurso é mais
importante que o resto, você
pode dar-lhe uma prioridade
maior.
O nó que executa o papel

principal de um clone
promocional recebe um ponto
extra se uma prioridade tiver sido
configurada para aquele clone.
Qualquer atraso definido com a

propriedade priority-fencing-
192
delay será adicionado a qualquer

atraso das propriedades dos
dispositivos de cerca
pcmk_delay_base e
pcmk_delay_max. Este
comportamento permite algum
atraso quando ambos os nós têm
prioridade igual, ou ambos os nós
precisam ser cercados por algum
outro motivo que não seja a perda
do nó (por exemplo, se on-
fail=fencing estiver definido
para uma operação de
monitoramento de recursos). Se
usado em combinação,
recomenda-se definir a
propriedade priority-fencing-
delay para um valor
significativamente maior que o
atraso máximo de
pcmk_delay_base e
pcmk_delay_max, para ter
certeza de que o nó priorizado é
preferível (o dobro do valor seria
completamente seguro).
Somente esgrima programada

pela própria Pacemaker irá
observar priority-fencing-
delay. A vedação programada
por código externo como
dlm_controld não fornecerá as
informações necessárias para o
dispositivo de vedação.
21.2. AJUSTE E REMOÇÃO DAS PROPRIEDADES DE AGRUPAMENTO

Para definir o valor de uma propriedade de cluster, use o seguinte pcs comando.
pcs conjunto de propriedade property=value
Por exemplo, para definir o valor de symmetric-cluster para false, use o seguinte comando.
# pcs property set symmetric-cluster=false
Você pode remover uma propriedade de cluster da configuração com o seguinte comando.
pcs propriedade não definida property
Alternativamente, você pode remover uma propriedade de cluster de uma configuração, deixando o
campo de valor do comando pcs property set em branco. Isto restaura essa propriedade a seu valor
padrão. Por exemplo, se você definiu previamente a propriedade symmetric-cluster para false, o
seguinte comando remove o valor definido da configuração e restaura o valor de symmetric-cluster
para true, que é seu valor padrão.
193
# pcs property set symmetic-cluster=
21.3. CONSULTA DE CONFIGURAÇÕES DE PROPRIEDADE DE

CLUSTERS
Na maioria dos casos, quando você usa o comando pcs para exibir valores dos vários componentes do
cluster, você pode usar pcs list ou pcs show intercambiavelmente. Nos exemplos seguintes, pcs list é
o formato usado para exibir uma lista completa de todas as configurações para mais de uma
propriedade, enquanto pcs show é o formato usado para exibir os valores de uma propriedade
específica.
Para exibir os valores dos ajustes de propriedade que foram definidos para o conjunto, use o seguinte
pcs comando.
pcs lista de propriedades
Para exibir todos os valores das configurações de propriedade para o conjunto, incluindo os valores
padrão das configurações de propriedade que não foram explicitamente definidas, use o seguinte
comando.
pcs lista de propriedades -- todas
Para exibir o valor atual de uma propriedade de cluster específica, use o seguinte comando.
pcs property show property
Por exemplo, para exibir o valor atual do imóvel cluster-infrastructure, execute o seguinte comando:
# pcs property show cluster-infrastructure

Cluster Properties:
cluster-infrastructure: cman
Para fins informativos, você pode exibir uma lista de todos os valores padrão para as propriedades, quer
tenham sido definidos para um valor diferente do padrão ou não, usando o seguinte comando.
pcs propriedade [lista|show] -defaults
194
GURAÇÃO DE RECURSOS PARA PERMANECER PARADO NO DESLIGAMENTO DO NÓ LIMPO (RHEL 8.2 E POSTERIORES)
CAPÍTULO 22. CONFIGURAÇÃO DE RECURSOS PARA

PERMANECER PARADO NO DESLIGAMENTO DO NÓ LIMPO
Quando um nó de cluster se desliga, a resposta padrão do Pacemaker é parar todos os recursos que
estão correndo naquele nó e recuperá-los em outro lugar, mesmo que o desligamento seja um
desligamento limpo. A partir do RHEL 8.2, você pode configurar o Pacemaker para que quando um nó
for desligado de forma limpa, os recursos anexados ao nó serão bloqueados ao nó e não poderão ser
iniciados em outro lugar até que comecem novamente quando o nó que foi desligado se juntar
novamente ao cluster. Isto permite que você desligue os nós durante as janelas de manutenção quando
as interrupções de serviço forem aceitáveis, sem fazer com que os recursos desse nó falhem para outros
nós do aglomerado.
22.1. PROPRIEDADES DO CLUSTER PARA CONFIGURAR RECURSOS

PARA PERMANECER PARADO NO DESLIGAMENTO DO NÓ LIMPO
A capacidade de evitar que os recursos falhem em um desligamento de nó limpo é implementada por
meio das seguintes propriedades de agrupamento.
shutdown-lock
Quando esta propriedade de agrupamento é definida para o valor padrão de false, o agrupamento
recuperará recursos que estão ativos nos nós que estão sendo limpos. Quando esta propriedade é
definida para true, os recursos que estão ativos nos nós que estão sendo limpos não podem começar
em outro lugar até que eles comecem no nó novamente depois que ele se juntar ao cluster.
A propriedade shutdown-lock funcionará tanto para nós de cluster quanto para nós remotos, mas
não para nós convidados.
Se shutdown-lock estiver configurado para true, você pode remover a trava em um recurso de
cluster quando um nó estiver em baixo para que o recurso possa começar em outro lugar,
executando uma atualização manual no nó com o seguinte comando.
pcs resource refresh resource node=nodename
Note que uma vez que os recursos sejam desbloqueados, o agrupamento é livre para mover os
recursos para outro lugar. Você pode controlar a probabilidade de isto ocorrer usando valores de
aderência ou preferências de localização para o recurso.
NOTA
Uma atualização manual só funcionará com nós remotos se você executar primeiro os
seguintes comandos:
1. Execute o comando systemctl stop pacemaker_remote no nó remoto para

parar o nó.
2. Execute o pcs resource disable remote-connection-resource comando.
Você pode então realizar uma atualização manual no nó remoto.
shutdown-lock-limit
Quando esta propriedade de agrupamento for definida para um tempo diferente do valor padrão de
195
Quando esta propriedade de agrupamento for definida para um tempo diferente do valor padrão de
0, os recursos estarão disponíveis para recuperação em outros nós se o nó não voltar dentro do
tempo especificado desde que o desligamento foi iniciado.
NOTA
A propriedade shutdown-lock-limit só funcionará com nós remotos se você executar

primeiro os seguintes comandos:
1. Execute o comando systemctl stop pacemaker_remote no nó remoto para

parar o nó.
2. Execute o pcs resource disable remote-connection-resource comando.
Após executar estes comandos, os recursos que estavam sendo executados no nó

remoto estarão disponíveis para recuperação em outros nós quando o tempo
especificado como o shutdown-lock-limit tiver passado.
22.2. CONFIGURANDO A PROPRIEDADE DE BLOQUEIO DE

FECHAMENTO
O exemplo a seguir define a propriedade do cluster shutdown-lock como true em um cluster de
exemplo e mostra o efeito que isso tem quando o nó é desligado e iniciado novamente. Este exemplo
de cluster consiste em três nós: z1.example.com, z2.example.com, e z3.example.com.
1. Defina o imóvel shutdown-lock para true e verifique seu valor. Neste exemplo, o imóvel
shutdown-lock-limit mantém seu valor padrão de 0.
[root@z3.example.com ~]# pcs property set shutdown-lock=true

[root@z3.example.com ~]# pcs property list --all | grep shutdown-lock
shutdown-lock: true
shutdown-lock-limit: 0
2. Verifique o status do agrupamento. Neste exemplo, os recursos third e fifth estão funcionando
em z1.example.com.
[root@z3.example.com ~]# pcs status

...
Full List of Resources:
...
* first (ocf::pacemaker:Dummy): Started z3.example.com
* second (ocf::pacemaker:Dummy): Started z2.example.com
* third (ocf::pacemaker:Dummy): Started z1.example.com
* fourth (ocf::pacemaker:Dummy): Started z2.example.com
* fifth (ocf::pacemaker:Dummy): Started z1.example.com
...
3. Encerrar z1.example.com, o que irá parar os recursos que estão funcionando naquele nó.
[root@z3.example.com ~] # pcs cluster stop z1.example.com

Stopping Cluster (pacemaker)...
Stopping Cluster (corosync)...
196
GURAÇÃO DE RECURSOS PARA PERMANECER PARADO NO DESLIGAMENTO DO NÓ LIMPO (RHEL 8.2 E POSTERIORES)
4. A execução do comando pcs status mostra que o nó z1.example.com está offline e que os
recursos que estavam rodando no z1.example.com são LOCKED enquanto o nó está em baixo.

...
Node List:
* Online: [ z2.example.com z3.example.com ]
* OFFLINE: [ z1.example.com ]

...
* third (ocf::pacemaker:Dummy): Stopped z1.example.com (LOCKED)
* fifth (ocf::pacemaker:Dummy): Stopped z1.example.com (LOCKED)
...
5. Comece novamente os serviços de cluster em z1.example.com para que ele se reintegre ao

cluster. Os recursos bloqueados devem começar naquele nó, embora uma vez iniciados não
necessariamente permaneçam no mesmo nó.
[root@z3.example.com ~]# pcs cluster start z1.example.com

Starting Cluster...
6. Neste exemplo, os recursos third e fifth são recuperados no nó z1.example.com.

...
Node List:
* Online: [ z1.example.com z2.example.com z3.example.com ]

..
* third (ocf::pacemaker:Dummy): Started z1.example.com
* fifth (ocf::pacemaker:Dummy): Started z1.example.com
...
197
CAPÍTULO 23. CONFIGURAÇÃO DE UMA ESTRATÉGIA DE

POSICIONAMENTO DO NÓ
O pacemaker decide onde colocar um recurso de acordo com as pontuações de alocação de recursos
em cada nó. O recurso será alocado ao nó onde o recurso tiver a pontuação mais alta. Esta pontuação de
alocação é derivada de uma combinação de fatores, incluindo restrições de recursos, configurações
resource-stickiness, histórico anterior de falhas de um recurso em cada nó, e utilização de cada nó.
Se as pontuações de alocação de recursos em todos os nós forem iguais, pela estratégia de colocação
padrão o Pacemaker escolherá um nó com o menor número de recursos alocados para equilibrar a carga.
Se o número de recursos em cada nó for igual, o primeiro nó elegível listado na CIB será escolhido para
executar o recurso.
Muitas vezes, porém, recursos diferentes utilizam proporções significativamente diferentes das
capacidades de um nó (como memória ou E/S). Nem sempre é possível equilibrar a carga de forma ideal
levando em conta apenas o número de recursos alocados a um nó. Além disso, se os recursos forem
colocados de forma que suas necessidades combinadas excedam a capacidade fornecida, eles podem
não conseguir iniciar completamente ou podem funcionar com desempenho degradado. Para levar estes
fatores em consideração, o Pacemaker permite configurar os seguintes componentes:
a capacidade que um determinado nó proporciona
a capacidade que um determinado recurso requer
uma estratégia global para a colocação de recursos
23.1. ATRIBUTOS DE UTILIZAÇÃO E ESTRATÉGIA DE COLOCAÇÃO

Para configurar a capacidade que um nó fornece ou um recurso requer, você pode usar utilization
attributes para nós e recursos. Você faz isso definindo uma variável de utilização para um recurso e
atribuindo um valor a essa variável para indicar o que o recurso requer, e então definindo essa mesma
variável de utilização para um nó e atribuindo um valor a essa variável para indicar o que o nó fornece.
Você pode nomear atributos de utilização de acordo com suas preferências e definir tantos pares de
nomes e valores quanto suas necessidades de configuração. Os valores dos atributos de utilização
devem ser números inteiros.
23.1.1. Configuração do nó e da capacidade de recursos

O exemplo a seguir configura um atributo de utilização da capacidade da CPU para dois nós, definindo
este atributo como a variável cpu. Ele também configura um atributo de utilização da capacidade de
RAM, definindo este atributo como a variável memory. Neste exemplo:
O Nó 1 é definido como fornecendo uma capacidade de CPU de dois e uma capacidade de RAM
de 2048
O Nó 2 é definido como fornecendo uma capacidade de CPU de quatro e uma capacidade de

RAM de 2048
# pcs node utilization node1 cpu=2 memory=2048

# pcs node utilization node2 cpu=4 memory=2048
O exemplo a seguir especifica os mesmos atributos de utilização que três recursos diferentes exigem.
Neste exemplo:
198
CAPÍTULO 23. CONFIGURAÇÃO DE UMA ESTRATÉGIA DE POSICIONAMENTO DO NÓ
recurso dummy-small requer uma capacidade de CPU de 1 e uma capacidade de RAM de 1024
recurso dummy-medium requer uma capacidade de CPU de 2 e uma capacidade de RAM de

2048
recurso dummy-large requer uma capacidade de CPU de 1 e uma capacidade de RAM de 3072
# pcs resource utilization dummy-small cpu=1 memory=1024

# pcs resource utilization dummy-medium cpu=2 memory=2048
# pcs resource utilization dummy-large cpu=3 memory=3072
Um nó é considerado elegível para um recurso se tiver capacidade livre suficiente para satisfazer as
necessidades do recurso, conforme definido pelos atributos de utilização.
23.1.2. Configuração da estratégia de colocação

Após ter configurado as capacidades que seus nós fornecem e as capacidades que seus recursos
requerem, você precisa definir a propriedade do cluster placement-strategy, caso contrário, as
configurações de capacidade não terão efeito.
Quatro valores estão disponíveis para a propriedade do cluster placement-strategy:
default
utilization
balanced
minimal
O seguinte exemplo de comando estabelece o valor de placement-strategy para balanced. Após

executar este comando, Pacemaker assegurará que a carga de seus recursos será distribuída
uniformemente por todo o cluster, sem a necessidade de complicados conjuntos de restrições de
colocação.
# pcs property set placement-strategy=balanced
23.2. ALOCAÇÃO DE RECURSOS DO MARCAPASSO

As subseções a seguir resumem como a Pacemaker aloca os recursos.
23.2.1. Preferência de Nó
O marcapasso determina qual nó é preferido ao alocar recursos de acordo com a seguinte estratégia.
O nó com o maior peso do nó é consumido primeiro. O peso do nó é uma pontuação mantida

pelo agrupamento para representar a saúde do nó.
Se vários nós tiverem o mesmo peso de nó:
Se a propriedade do cluster placement-strategy é default ou utilization:
O nó que tem o menor número de recursos alocados é consumido primeiro.
Se os números de recursos alocados forem iguais, o primeiro nó elegível listado na CIB é

199
Se os números de recursos alocados forem iguais, o primeiro nó elegível listado na CIB é

consumido primeiro.
Se a propriedade do cluster placement-strategy é balanced:
O nó que tem a capacidade mais livre é consumido primeiro.
Se as capacidades livres dos nós forem iguais, o nó que tiver o menor número de
recursos alocados é consumido primeiro.
Se as capacidades livres dos nós forem iguais e o número de recursos alocados for igual,
o primeiro nó elegível listado na CIB é consumido primeiro.
Se a propriedade do cluster placement-strategy é minimal, o primeiro nó elegível listado

na CIB é consumido primeiro.
23.2.2. Capacidade do Nó
O marcapasso determina qual nó tem a capacidade mais livre, de acordo com a seguinte estratégia.
Se apenas um tipo de atributo de utilização tiver sido definido, a capacidade livre é uma simples
comparação numérica.
Se vários tipos de atributos de utilização tiverem sido definidos, então o nó que é

numericamente mais alto na maioria dos tipos de atributos tem a capacidade mais livre. Por
exemplo, o nó que tem a capacidade mais livre:
Se NodeA tem mais CPUs livres, e NodeB tem mais memória livre, então suas capacidades
livres são iguais.
Se NodeA tem mais CPUs livres, enquanto NodeB tem mais memória e armazenamento
livres, então NodeB tem mais capacidade livre.
23.2.3. Preferência de Alocação de Recursos

Pacemaker determina qual recurso é alocado primeiro de acordo com a seguinte estratégia.
O recurso que tem a maior prioridade é alocado primeiro. Você pode definir a prioridade de um
recurso ao criar o recurso.
Se as prioridades dos recursos forem iguais, o recurso que tiver a pontuação mais alta no nó
onde ele está funcionando é alocado primeiro, para evitar o embaralhamento de recursos.
Se as pontuações dos recursos nos nós onde os recursos estão funcionando forem iguais ou se
os recursos não estiverem funcionando, o recurso que tiver a pontuação mais alta no nó
preferido é alocado primeiro. Se as pontuações dos recursos no nó preferido forem iguais neste
caso, o primeiro recurso executável listado na CIB é alocado em primeiro lugar.
23.3. DIRETRIZES DE ESTRATÉGIA DE COLOCAÇÃO DE RECURSOS

Para garantir que a estratégia de colocação de recursos da Pacemaker funcione de forma mais eficaz,
você deve levar em conta as seguintes considerações ao configurar seu sistema.
Certifique-se de que você tenha capacidade física suficiente.
Se a capacidade física de seus nós estiver sendo utilizada ao máximo em condições normais,
200
CAPÍTULO 23. CONFIGURAÇÃO DE UMA ESTRATÉGIA DE POSICIONAMENTO DO NÓ
Se a capacidade física de seus nós estiver sendo utilizada ao máximo em condições normais,
então poderão ocorrer problemas durante o failover. Mesmo sem o recurso de utilização, você
pode começar a experimentar timeouts e falhas secundárias.
Construa algum buffer nas capacidades que você configura para os nós.
Anuncie um pouco mais de recursos de nós do que você fisicamente tem, no pressuposto de
que um recurso Pacemaker não utilizará 100% da quantidade configurada de CPU, memória, e
assim por diante o tempo todo. Esta prática às vezes é chamada de overcommit.
Especifique as prioridades de recursos.

Se o grupo vai sacrificar serviços, devem ser aqueles com os quais você menos se importa.
Assegure-se de que as prioridades de recursos estejam devidamente definidas para que seus
recursos mais importantes sejam agendados em primeiro lugar.
23.4. O AGENTE DE RECURSOS NODEUTILIZATION

O agente NodeUtilization pode detectar os parâmetros do sistema de CPU disponível, disponibilidade
de memória host e disponibilidade de memória hypervisor e adicionar estes parâmetros ao CIB. Você
pode executar o agente como um recurso clone para que ele preencha automaticamente estes
parâmetros em cada nó.
Para obter informações sobre o agente de recursos NodeUtilization e as opções de recursos para este
agente, execute o comando pcs resource describe NodeUtilization.
201
CAPÍTULO 24. CONFIGURAÇÃO DE UM DOMÍNIO VIRTUAL

COMO UM RECURSO
Você pode configurar um domínio virtual que é gerenciado pela estrutura de virtualização libvirt como
um recurso de cluster com o comando pcs resource create, especificando VirtualDomain como o tipo
de recurso.
Ao configurar um domínio virtual como um recurso, leve em conta as seguintes considerações:
Um domínio virtual deve ser interrompido antes de ser configurado como um recurso de cluster.
Uma vez que um domínio virtual é um recurso de cluster, ele não deve ser iniciado, parado ou
migrado, exceto através das ferramentas de cluster.
Não configure um domínio virtual que você tenha configurado como um recurso de cluster para
começar quando seu host boots.
Todos os nós autorizados a executar um domínio virtual devem ter acesso aos arquivos de
configuração e dispositivos de armazenamento necessários para esse domínio virtual.
Se você quiser que o cluster gerencie serviços dentro do próprio domínio virtual, você pode configurar o
domínio virtual como um nó convidado.
24.1. OPÇÕES DE RECURSOS DE DOMÍNIO VIRTUAL

Tabela 24.1, “Opções de Recursos para Recursos de Domínio Virtual” descreve as opções de recursos
que você pode configurar para um recurso VirtualDomain.
Tabela 24.1. Opções de Recursos para Recursos de Domínio Virtual
C Padrão D
a e
m s
p c
o r
i
ç
ã
o
c (
o r
n e
f q
i u
g e
r
i
d
o
)
C
a
m
i
202
CAPÍTULO 24. CONFIGURAÇÃO DE UM DOMÍNIO VIRTUAL COMO UM RECURSO
n
C Padrão Dh
a eo
m sa
p cb
o rs
io
çl
ãu
ot
o
p
a
r
a
o
a
r
q
u
i
v
o
d
e
c
o
n
f
i
g
u
r
a
ç
ã
o
l
i
b
v
i
r
t
p
a
r
a
e
s
t
e
d
o
m
í
203
n
C Padrão Di
a eo
m sv
p ci
o rr
it
çu
ãa
ol
.
h Dependente do sistema H
y y
p p
e e
r r
v v
i i
s s
o o
r r
U
R
I
p
a
r
a
c
o
n
e
c
t
a
r
.
V
o
c
ê
p
o
d
e
d
e
t
e
r
m
i
n
a
204
r
C Padrão Do
a eU
m sR
p cI
o rp
ia
çd
ãr
oã
o
d
o
s
i
s
t
e
m
a
e
x
e
c
u
t
a
n
d
o
o
c
o
m
a
n
d
o
v
i
r
s
h
-
-
q
u
i
e
t
u
r
i
.
f 0 S
205
o e
C
r Padrão Dm
a
c ep
m
e sr
p
_ ce
o
s rd
t ie
o çs
p ãl
oi
g
u
e
à
f
o
r
ç
a
(
"
d
e
s
t
r
u
i
r
"
)
o
d
o
m
í
n
i
o
e
m
p
a
r
a
d
a
.
O
c
o
m
p
o
r
t
206
a
C Padrão Dm
a ee
m sn
p ct
o ro
ip
ça
ãd
or
ã
o
é
r
e
c
o
r
r
e
r
a
u
m
d
e
s
l
i
g
a
m
e
n
t
o
f
o
r
ç
a
d
o
s
o
m
e
n
t
e
a
p
ó
s
u
m
207
a
C Padrão Dt
a ee
m sn
p ct
o ra
it
çi
ãv
oa
d
e
d
e
s
l
i
g
a
m
e
n
t
o
g
r
a
c
i
o
s
o
t
e
r
f
a
l
h
a
d
o
.
V
o
c
ê
d
e
v
e
d
e
f
i
n
208
i
C Padrão Dr
a ei
m ss
p ct
o ro
ip
ça
ãr
oa
t
r
u
e
s
o
m
e
n
t
e
s
e
s
e
u
d
o
m
í
n
i
o
v
i
r
t
u
a
l
(
o
u
s
e
u
b
a
c
k
e
n
d
d
e
v
209
i
C Padrão Dr
a et
m su
p ca
o rl
ii
çz
ãa
oç
ã
o
)
n
ã
o
s
u
p
o
r
t
a
r
u
m
d
e
s
l
i
g
a
m
e
n
t
o
g
r
a
c
i
o
s
o
.
m Dependente do sistema T
i r
g a
r n
a s
t p
i o
o r
210
n t
C
_ Padrão De
a
t eu
m
r ss
p
a ca
o
n rd
s io
p çp
o ãa
r or
t a
c
o
n
e
c
t
a
r
a
o
h
i
p
e
r
v
i
s
o
r
r
e
m
o
t
o
e
n
q
u
a
n
t
o
m
i
g
r
a
v
a
.
S
e
e
211
s
C Padrão Dt
a ee
m sp
p ca
o rr
iâ
çm
ãe
ot
r
o
f
o
r
o
m
i
t
i
d
o
,
o
r
e
c
u
r
s
o
u
s
a
r
á
o
t
r
a
n
s
p
o
r
t
e
p
a
d
r
ã
o
d
o
l
212
i
C Padrão Db
a ev
m si
p cr
o rt
ip
ça
ãr
oa
s
e
c
o
n
e
c
t
a
r
a
o
h
i
p
e
r
v
i
s
o
r
r
e
m
o
t
o
.
m U
i t
g i
r l
a i
t z
i a
o r
n u
_ m
n a
e r
t e
w d
o e
r d
k e
213
_ m
C
s Padrão Di
a
u eg
m
f sr
fp ca
o
i rç
x iã
ço
ãd
oe
d
i
c
a
d
a
.
A
U
R
I
d
e
m
i
g
r
a
ç
ã
o
é
c
o
m
p
o
s
t
a
p
e
l
a
a
d
i
ç
ã
o
d
o
v
a
l
o
214
r
C Padrão Dd
a ee
m ss
p ct
o re
ip
ça
ãr
oâ
m
e
t
r
o
a
o
f
i
n
a
l
d
o
n
o
m
e
d
o
n
ó
.
S
e
o
n
o
m
e
d
o
n
ó
f
o
r
u
m
n
o
m
e
d
e
d
215
o
C Padrão Dm
a eí
m sn
p ci
o ro
it
ço
ãt
oa
l
m
e
n
t
e
q
u
a
l
i
f
i
c
a
d
o
(
F
Q
D
N
)
,
i
n
s
e
r
i
r
o
s
u
f
i
x
o
i
m
e
d
i
a
t
a
216
m
C Padrão De
a en
m st
p ce
o ra
in
çt
ãe
os
d
o
p
r
i
m
e
i
r
o
p
e
r
í
o
d
o
(
.
)
n
o
F
Q
D
N
.
C
e
r
t
i
f
i
q
u
e
-
s
e
d
e
q
u
e
e
217
s
C Padrão Dt
a ee
m sn
p co
o rm
ie
çd
ãe
oh
o
s
t
c
o
m
p
o
s
t
o
s
e
j
a
r
e
s
o
l
ú
v
e
l
l
o
c
a
l
m
e
n
t
e
e
o
e
n
d
e
r
e
ç
o
I
P
218
a
C Padrão Ds
a es
m so
p cc
o ri
ia
çd
ão
os
e
j
a
a
c
e
s
s
í
v
e
l
a
t
r
a
v
é
s
d
a
r
e
d
e
f
a
v
o
r
e
c
i
d
a
.
m P
o a
n r
i a
t m
o o
r n
_ i
s t
219
c o
C
r Padrão Dr
a
i ea
m
p sr
tp cs
o
s re
ir
çv
ãi
oç
o
s
d
e
n
t
r
o
d
o
d
o
m
í
n
i
o
v
i
r
t
u
a
l
,
a
d
i
c
i
o
n
e
e
s
t
e
p
a
r
â
m
e
t
r
o
220
c
C Padrão Do
a em
m su
p cm
o ra
il
çi
ãs
ot
a
d
e
s
c
r
i
p
t
s
p
a
r
a
m
o
n
i
t
o
r
a
r
.
N
o
t
e
:
Q
u
a
n
d
o
o
s
s
c
r
i
p
t
s
d
e
221
m
C Padrão Do
a en
m si
p ct
o ro
ir
ça
ãm
oe
n
t
o
f
o
r
e
m
u
s
a
d
o
s
,
a
s
o
p
e
r
a
ç
õ
e
s
d
e
s
t
a
r
t
e
m
i
g
r
a
t
e
_
f
r
o
m
222
s
C Padrão De
a er
m sã
p co
o rc
io
çn
ãc
ol
u
í
d
a
s
s
o
m
e
n
t
e
q
u
a
n
d
o
t
o
d
o
s
o
s
s
c
r
i
p
t
s
d
e
m
o
n
i
t
o
r
a
m
e
n
t
223
o
C Padrão Dt
a ei
m sv
p ce
o rr
ie
çm
ãs
oi
d
o
c
o
n
c
l
u
í
d
o
s
c
o
m
s
u
c
e
s
s
o
.
C
e
r
t
i
f
i
q
u
e
-
s
e
d
e
d
e
f
i
n
i
r
o
224
t
C Padrão De
a em
m sp
p co
o rl
ii
çm
ãi
ot
e
d
e
s
t
a
s
o
p
e
r
a
ç
õ
e
s
p
a
r
a
a
c
o
m
o
d
a
r
e
s
t
e
a
t
r
a
s
o
a true S
u e
t a
o j
s u
e s
225
t t
C
_ Padrão Da
a
u ed
m
t so
ip cp
o
l ra
i ir
z ça
a ãt
t or
i u
o e
n ,
_ o
c a
p g
u e
n
t
e
d
e
t
e
c
t
a
r
á
o
n
ú
m
e
r
o
d
e
d
o
m
a
i
n
U
'
s
v
C
P
U
s
d
e
v
i
226
r
C Padrão Ds
a eh
m s,
p ce
o ro
ic
ço
ãl
oo
c
a
r
á
n
a
u
t
i
l
i
z
a
ç
ã
o
d
a
C
P
U
d
o
r
e
c
u
r
s
o
q
u
a
n
d
o
o
m
o
n
i
t
o
r
f
o
227
r
C Padrão De
a ex
m se
p cc
o ru
it
ça
ãd
oo
.
a true S
u e
t f
o o
s r
e d
t e
_ f
u i
t n
i i
l d
i o
z c
a o
t m
i o
o v
n e
_ r
h d
v a
_ d
m e
e i
m r
o o
r ,
y o
a
g
e
n
t
e
d
e
t
e
c
t
a
r
á
o
228
n
C Padrão Dú
a em
m se
p cr
o ro
id
çe
ãM
oa
x
m
e
m
o
r
y
d
e
v
i
r
s
h
,
e
o
c
o
l
o
c
a
r
á
n
o
h
v
_
m
e
m
o
r
y
u
t
i
l
i
z
a
ç
ã
o
229
d
C Padrão Da
a ef
m so
p cn
o rt
ie
çq
ãu
oa
n
d
o
o
m
o
n
i
t
o
r
f
o
r
e
x
e
c
u
t
a
d
o
.
m porto alto aleatório E

i s
g t
r e
a p
t o
e r
p t
o o
r s
t e
r
á
u
t
i
l
i
z
230
a
C Padrão Dd
a eo
m sn
p co
o rq
ie
çm
ãu
om
i
g
r
a
r
U
R
I
.
S
e
n
ã
o
e
s
t
i
v
e
r
d
e
f
i
n
i
d
o
,
o
p
o
r
t
o
s
e
r
á
u
m
p
o
r
t
231
o
C Padrão Da
a el
m st
p co
o ra
il
çe
ãa
ot
ó
r
i
o
.
s C
n a
a m
p i
s n
h h
o o
t p
a
r
a
o
d
i
r
e
t
ó
r
i
o
d
e
i
n
s
t
a
n
t
â
n
e
o
s
o
n
d
e
a
i
232
m
C Padrão Da
a eg
m se
p cm
o rd
ia
çm
ãá
oq
u
i
n
a
v
i
r
t
u
a
l
s
e
r
á
a
r
m
a
z
e
n
a
d
a
.
Q
u
a
n
d
o
e
s
t
e
p
a
r
â
m
e
t
r
o
f
233
o
C Padrão Dr
a ed
m se
p cf
o ri
in
çi
ãd
oo
,
o
e
s
t
a
d
o
d
e
R
A
M
d
a
m
á
q
u
i
n
a
v
i
r
t
u
a
l
s
e
r
á
s
a
l
v
o
e
m
u
m
a
r
q
u
234
i
C Padrão Dv
a eo
m sn
p co
o rd
ii
çr
ãe
ot
ó
r
i
o
d
e
i
n
s
t
a
n
t
â
n
e
o
s
q
u
a
n
d
o
p
a
r
a
d
o
.
S
e
a
o
i
n
i
c
i
a
r
u
m
a
r
235
q
C Padrão Du
a ei
m sv
p co
o rd
ie
çe
ãs
ot
a
d
o
e
s
t
i
v
e
r
p
r
e
s
e
n
t
e
p
a
r
a
o
d
o
m
í
n
i
o
,
o
d
o
m
í
n
i
o
s
e
r
á
r
e
s
236
t
C Padrão Da
a eu
m sr
p ca
o rd
io
çp
ãa
or
a
o
m
e
s
m
o
e
s
t
a
d
o
e
m
q
u
e
e
s
t
a
v
a
a
n
t
e
s
d
e
t
e
r
p
a
r
a
d
o
p
o
r
ú
l
t
237
i
C Padrão Dm
a eo
m s.
p cE
o rs
it
ça
ão
op
ç
ã
o
é
i
n
c
o
m
p
a
t
í
v
e
l
c
o
m
a
o
p
ç
ã
o
f
o
r
c
e
_
s
t
o
p
.
Além das opções de recursos VirtualDomain, você pode configurar a opção allow-migrate metadados
para permitir a migração ao vivo do recurso para outro nó. Quando esta opção é configurada para true, o
recurso pode ser migrado sem perda de estado. Quando esta opção for definida para false, que é o
estado padrão, o domínio virtual será desligado no primeiro nó e então reiniciado no segundo nó quando
ele for movido de um nó para o outro.
24.2. CRIANDO O RECURSO DE DOMÍNIO VIRTUAL
238
Use o seguinte procedimento para criar um recurso VirtualDomain em um cluster para uma máquina
virtual que você tenha criado anteriormente:
1. Para criar o agente de recursos VirtualDomain para o gerenciamento da máquina virtual, a

Pacemaker requer que o arquivo de configuração xml da máquina virtual seja despejado em um
arquivo em disco. Por exemplo, se você criou uma máquina virtual chamada guest1, descarte o
arquivo xml para um arquivo em algum lugar em um dos nós do cluster que será permitido
executar o convidado. Você pode usar um nome de arquivo de sua escolha; este exemplo usa
/etc/pacemaker/guest1.xml.
# virsh dumpxml guest1 > /etc/pacemaker/guest1.xml
2. Copie o arquivo de configuração da máquina virtual xml para todos os outros nós de cluster que
poderão executar o convidado, no mesmo local em cada nó.
3. Assegurar que todos os nós autorizados a executar o domínio virtual tenham acesso aos
dispositivos de armazenamento necessários para esse domínio virtual.
4. Testar separadamente que o domínio virtual pode iniciar e parar em cada nó que irá executar o
domínio virtual.
5. Se estiver funcionando, desligue o nó convidado. O marcapasso iniciará o nó quando ele estiver

configurado no cluster. A máquina virtual não deve ser configurada para iniciar
automaticamente quando o host iniciar.
6. Configure o recurso VirtualDomain com o comando pcs resource create. Por exemplo, o
seguinte comando configura um recurso VirtualDomain chamado VM. Como a opção allow-
migrate está configurada para true a pcs move VM nodeX seria feito como uma migração ao
vivo.
Neste exemplo migration_transport está configurado para ssh. Observe que para que a
migração SSH funcione corretamente, o registro sem chave deve funcionar entre nós.
# pcs resource create VM VirtualDomain config=/etc/pacemaker/guest1.xml

migration_transport=ssh meta allow-migrate=true
239
CAPÍTULO 25. QUÓRUM DE CLUSTER

Um cluster do Red Hat Enterprise Linux High Availability Add-On usa o serviço votequorum, em
conjunto com a esgrima, para evitar situações de cérebro dividido. Um número de votos é atribuído a
cada sistema no cluster, e as operações de cluster são permitidas somente quando uma maioria de
votos está presente. O serviço deve ser carregado em todos os nós ou em nenhum; se for carregado em
um subconjunto de nós de cluster, os resultados serão imprevisíveis. Para informações sobre a
configuração e operação do serviço votequorum, consulte a página de manual votequorum(5).
25.1. CONFIGURAÇÃO DAS OPÇÕES DO QUORUM

Há algumas características especiais de configuração de quorum que você pode definir ao criar um
cluster com o comando pcs cluster setup. Tabela 25.1, “Opções do Quorum” resume estas opções.
Tabela 25.1. Opções do Quorum
Opção Descrição
auto_tie_breaker Quando ativado, o aglomerado pode sofrer até 50%

de falhas nos nós ao mesmo tempo, de forma
determinista. A partição do cluster, ou o conjunto de
nós que ainda estão em contato com o nodeid
configurado em auto_tie_breaker_node (ou o
mais baixo nodeid se não estiver configurado),
permanecerá quorato. Os outros nós serão
questionados.
A opção auto_tie_breaker é utilizada

principalmente para clusters com um número par de
nós, pois permite que o cluster continue operando
com uma divisão uniforme. Para falhas mais
complexas, tais como divisões múltiplas e desiguais, é
recomendado o uso de um dispositivo de quorum,
como descrito nos dispositivos Quorum.
A opção auto_tie_breaker é incompatível com os

dispositivos de quorum.
wait_for_all Quando ativado, o agrupamento será quorato pela

primeira vez somente após todos os nós terem sido
visíveis pelo menos uma vez ao mesmo tempo.
A opção wait_for_all é usada principalmente para

clusters de dois nós e para clusters de nós pares
usando o algoritmo de quorum lms (último homem
de pé).
A opção wait_for_all é ativada automaticamente

quando um cluster tem dois nós, não utiliza um
dispositivo de quorum e auto_tie_breaker é
desativado. Você pode anular isto, definindo
explicitamente wait_for_all como 0.
240
Opção Descrição
last_man_standing Quando ativado, o agrupamento pode recalcular

dinamicamente expected_votes e o quorum sob
circunstâncias específicas. Você deve habilitar
wait_for_all quando ativar esta opção. A opção
last_man_standing é incompatível com os
dispositivos de quorum.
last_man_standing_window O tempo, em milissegundos, para esperar antes de

recalcular expected_votes e o quorum após um
agrupamento perder nós.
Para maiores informações sobre a configuração e utilização destas opções, consulte a página de manual
votequorum(5).
25.2. MODIFICAÇÃO DAS OPÇÕES DO QUORUM

Você pode modificar as opções gerais de quorum para seu agrupamento com o comando pcs quorum
update. A execução deste comando exige que o agrupamento seja interrompido. Para informações
sobre as opções de quorum, consulte a página de manual votequorum(5).
O formato do comando pcs quorum update é o seguinte.
pcs quorum update [auto_tie_breaker=[0|1]] [last_man_standing=[0|1]] [last_man_standing_window=

[time-in-ms] [wait_for_all=[0|1]]
A série de comandos a seguir modifica a opção do quorum wait_for_all e exibe o status atualizado da
opção. Note que o sistema não permite executar este comando enquanto o cluster estiver em
execução.
[root@node1:~]# pcs quorum update wait_for_all=1

Checking corosync is not running on nodes...
Error: node1: corosync is running
Error: node2: corosync is running
[root@node1:~]# pcs cluster stop --all

node2: Stopping Cluster (pacemaker)...
node1: Stopping Cluster (pacemaker)...
node1: Stopping Cluster (corosync)...
node2: Stopping Cluster (corosync)...
[root@node1:~]# pcs quorum update wait_for_all=1

Checking corosync is not running on nodes...
node2: corosync is not running
node1: corosync is not running
Sending updated corosync.conf to nodes...
node1: Succeeded
node2: Succeeded
241
[root@node1:~]# pcs quorum config

Options:
wait_for_all: 1
25.3. EXIBIÇÃO DA CONFIGURAÇÃO E STATUS DO QUORUM

Uma vez que um agrupamento esteja em execução, você pode entrar nos seguintes comandos de
quorum de agrupamento.
O seguinte comando mostra a configuração do quorum.
pcs quorum [config]
O seguinte comando mostra o status do quorum runtime.
status de quorum pcs
25.4. EXECUÇÃO DE CLUSTERS DE INQUÉRITOS

Se você retirar nós de um agrupamento por um longo período de tempo e a perda desses nós causar
perda de quórum, você pode alterar o valor do parâmetro expected_votes para o agrupamento ao vivo
com o comando pcs quorum expected-votes. Isto permite que o aglomerado continue operando
quando não tiver quorum.

ATENÇÃO
A mudança dos votos esperados em um grupo vivo deve ser feita com extrema
cautela. Se menos de 50% do agrupamento estiver funcionando porque você
mudou manualmente os votos esperados, então os outros nós do agrupamento
podem ser iniciados separadamente e executar serviços de agrupamento, causando
corrupção de dados e outros resultados inesperados. Se você alterar este valor,
você deve garantir que o parâmetro wait_for_all esteja ativado.
O seguinte comando define os votos esperados no conjunto vivo para o valor especificado. Isto afeta
apenas o live cluster e não altera o arquivo de configuração; o valor de expected_votes é redefinido
para o valor no arquivo de configuração no caso de uma recarga.
quorum esperado de votos pcs votes
Em uma situação em que você sabe que o agrupamento é inquirido, mas quer que o agrupamento
prossiga com o gerenciamento de recursos, você pode usar o comando pcs quorum unblock para
evitar que o agrupamento espere por todos os nós ao estabelecer o quorum.
NOTA
Este comando deve ser usado com extrema cautela. Antes de emitir este comando, é
imperativo garantir que os nós que não estão atualmente no cluster sejam desligados e
não tenham acesso a recursos compartilhados.
242
# pcs quorum unblock
25.5. DISPOSITIVOS DO QUORUM

Você pode permitir que um agrupamento mantenha mais falhas nos nós do que as regras de quórum
padrão permitem, configurando um dispositivo de quórum separado que atua como um dispositivo de
arbitragem de terceiros para o agrupamento. Um dispositivo de quorum é recomendado para clusters
com um número par de nós. Com clusters de dois nós, o uso de um dispositivo de quórum pode
determinar melhor qual o nó que sobrevive em uma situação de cérebro dividido.
Deve-se levar em conta o seguinte ao configurar um dispositivo de quorum.
Recomenda-se que um dispositivo de quorum seja executado em uma rede física diferente no
mesmo local que o aglomerado que utiliza o dispositivo de quorum. O ideal é que o host do
dispositivo de quorum esteja em um rack separado do cluster principal, ou pelo menos em uma
PSU separada e não no mesmo segmento de rede que o anel ou anéis corosync.
Não é possível usar mais de um dispositivo de quorum em um conjunto ao mesmo tempo.
Embora não se possa usar mais de um dispositivo de quorum em um agrupamento ao mesmo

tempo, um único dispositivo de quorum pode ser usado por vários agrupamentos ao mesmo
tempo. Cada agrupamento usando esse dispositivo de quorum pode usar diferentes algoritmos
e opções de quorum, já que estes são armazenados nos próprios nós do agrupamento. Por
exemplo, um único dispositivo de quorum pode ser usado por um cluster com um algoritmo
ffsplit (fifty/fifty split) e por um segundo cluster com um algoritmo lms (last man standing).
Um dispositivo de quorum não deve ser executado em um nó de cluster existente.
25.5.1. Instalação de pacotes de dispositivos de quorum

A configuração de um dispositivo de quorum para um cluster requer que você instale os seguintes
pacotes
Instale corosync-qdevice nos nós de um cluster existente.
[root@node1:~]# yum install corosync-qdevice

[root@node2:~]# yum install corosync-qdevice
Instale pcs e corosync-qnetd no host do dispositivo quorum.
[root@qdevice:~]# yum install pcs corosync-qnetd
Iniciar o serviço pcsd e habilitar pcsd no início do sistema no host do dispositivo quorum.
[root@qdevice:~]# systemctl start pcsd.service

[root@qdevice:~]# systemctl enable pcsd.service
25.5.2. Configuração de um dispositivo de quorum

O procedimento seguinte configura um dispositivo de quorum e o adiciona ao conjunto. Neste exemplo:
O nó utilizado para um dispositivo de quorum é qdevice.
O modelo do dispositivo de quorum é net, que é atualmente o único modelo suportado. O

243
O modelo do dispositivo de quorum é net, que é atualmente o único modelo suportado. O

modelo net suporta os seguintes algoritmos:
ffsplit: fifty-fifty split. Isto proporciona exatamente um voto para a partição com o maior
número de nós ativos.
lms: último homem de pé. Se o nó é o único que resta no cluster que pode ver o servidor
qnetd, então ele retorna uma votação.

ATENÇÃO
O algoritmo LMS permite que o cluster permaneça quorado mesmo

com apenas um nó restante, mas também significa que o poder de voto
do dispositivo de quorum é grande, pois é o mesmo que o
número_de_nós - 1. Perder a conexão com o dispositivo de quorum
significa perder número_de_nós - 1 voto, o que significa que apenas um
cluster com todos os nós ativos pode permanecer quorado (através da
votação excessiva do dispositivo de quorum); qualquer outro cluster se
torna inquieto.
Para informações mais detalhadas sobre a implementação destes algoritmos, consulte a

página de manual corosync-qdevice(8).
Os nós de agrupamento são node1 e node2.
O procedimento seguinte configura um dispositivo de quorum e adiciona esse dispositivo de quorum a

um conjunto.
1. No nó que você usará para hospedar seu dispositivo de quórum, configure o dispositivo de
quórum com o seguinte comando. Este comando configura e inicia o dispositivo de quorum
modelo net e configura o dispositivo para iniciar na inicialização.
[root@qdevice:~]# pcs qdevice setup model net --enable --start

Quorum device 'net' initialized
quorum device enabled
Starting quorum device...
quorum device started
Após configurar o dispositivo do quorum, você pode verificar seu status. Isto deve mostrar que
o daemon corosync-qnetd está funcionando e, neste ponto, não há clientes conectados a ele.
A opção de comando --full fornece uma saída detalhada.
[root@qdevice:~]# pcs qdevice status net --full

QNetd address: *:5403
TLS: Supported (client certificate required)
Connected clients: 0
Connected clusters: 0
Maximum send/receive size: 32768/32768 bytes
2. Habilite as portas no firewall necessárias ao daemon pcsd e ao dispositivo de quorum net

habilitando o serviço high-availability em firewalld com os seguintes comandos.
244
[root@qdevice:~]# firewall-cmd --permanent --add-service=high-availability

[root@qdevice:~]# firewall-cmd --add-service=high-availability
3. De um dos nós do cluster existente, autentique o usuário hacluster no nó que está hospedando
o dispositivo de quorum. Isto permite que pcs no cluster se conecte a pcs no host qdevice,
mas não permite que pcs no host qdevice se conecte a pcs no cluster.
[root@node1:~] # pcs host auth qdevice

Username: hacluster
Password:
qdevice: Authorized
4. Adicione o dispositivo de quorum ao conjunto.

Antes de adicionar o dispositivo de quorum, você pode verificar a configuração atual e o status
do dispositivo de quorum para comparação posterior. A saída para estes comandos indica que o
agrupamento ainda não está usando um dispositivo de quorum, e o status de membro Qdevice
para cada nó é NR (Não registrado).

Options:
[root@node1:~]# pcs quorum status

Quorum information
------------------
Date: Wed Jun 29 13:15:36 2016
Quorum provider: corosync_votequorum
Nodes: 2
Node ID: 1
Ring ID: 1/8272
Quorate: Yes
Votequorum information
----------------------
Expected votes: 2
Highest expected: 2
Total votes: 2
Quorum: 1
Flags: 2Node Quorate
Membership information
----------------------
Nodeid Votes Qdevice Name
1 1 NR node1 (local)
2 1 NR node2
O seguinte comando acrescenta o dispositivo de quorum que você criou anteriormente ao

agrupamento. Você não pode usar mais de um dispositivo de quorum em um agrupamento ao
mesmo tempo. Entretanto, um dispositivo de quorum pode ser usado por vários aglomerados
ao mesmo tempo. Este comando de exemplo configura o dispositivo de quorum para usar o
algoritmo ffsplit. Para informações sobre as opções de configuração do dispositivo de quorum,
consulte a página de manual corosync-qdevice(8).
[root@node1:~]# pcs quorum device add model net host=qdevice \

algorithm=ffsplit
245
Setting up qdevice certificates on nodes...

node2: Succeeded
node1: Succeeded
Enabling corosync-qdevice...
node1: corosync-qdevice enabled
node2: corosync-qdevice enabled
node1: Succeeded
node2: Succeeded
Corosync configuration reloaded
Starting corosync-qdevice...
node1: corosync-qdevice started
5. Verificar o status de configuração do dispositivo de quorum.

Do lado do cluster, você pode executar os seguintes comandos para ver como a configuração
mudou.
O pcs quorum config mostra o dispositivo do quorum que foi configurado.

Options:
Device:
Model: net
algorithm: ffsplit
host: qdevice
O comando pcs quorum status mostra o status de tempo de execução do quorum, indicando
que o dispositivo do quorum está em uso. Os significados dos valores de status das informações
de associação do Qdevice para cada nó de agrupamento são os seguintes:
A/NA
V/NV
MW/NMW
[root@node1:~]# pcs quorum status

Quorum information
------------------
Date: Wed Jun 29 13:17:02 2016
Quorum provider: corosync_votequorum
Nodes: 2
Node ID: 1
Ring ID: 1/8272
Quorate: Yes
Votequorum information
----------------------
Expected votes: 3
Highest expected: 3
Total votes: 3
Quorum: 2
Flags: Quorate Qdevice
Membership information
246
----------------------
Nodeid Votes Qdevice Name
1 1 A,V,NMW node1 (local)
2 1 A,V,NMW node2
0 1 Qdevice
O pcs quorum device status mostra o status de tempo de execução do dispositivo de

quorum.
[root@node1:~]# pcs quorum device status

Qdevice information
-------------------
Model: Net
Node ID: 1
Configured node list:
0 Node ID = 1
1 Node ID = 2
Membership node list: 1, 2
Qdevice-net information
----------------------
Cluster name: mycluster
QNetd host: qdevice:5403
Algorithm: ffsplit
Tie-breaker: Node with lowest node ID
State: Connected
Do lado do dispositivo do quorum, você pode executar o seguinte comando de status, que
mostra o status do daemon corosync-qnetd.
[root@qdevice:~]# pcs qdevice status net --full

QNetd address: *:5403
TLS: Supported (client certificate required)
Connected clients: 2
Connected clusters: 1
Maximum send/receive size: 32768/32768 bytes
Cluster "mycluster":
Algorithm: ffsplit
Tie-breaker: Node with lowest node ID
Node ID 2:
Client address: ::ffff:192.168.122.122:50028
HB interval: 8000ms
Configured node list: 1, 2
Ring ID: 1.2050
TLS active: Yes (client certificate verified)
Vote: ACK (ACK)
Node ID 1:
Client address: ::ffff:192.168.122.121:48786
HB interval: 8000ms
Configured node list: 1, 2
Ring ID: 1.2050
TLS active: Yes (client certificate verified)
Vote: ACK (ACK)
247
25.5.3. Gerenciando o Serviço de Dispositivos Quorum

O PCS fornece a capacidade de gerenciar o serviço de dispositivo de quorum no host local (corosync-
qnetd), como mostrado nos comandos do exemplo a seguir. Observe que estes comandos afetam
apenas o serviço corosync-qnetd.
[root@qdevice:~]# pcs qdevice start net

[root@qdevice:~]# pcs qdevice stop net
[root@qdevice:~]# pcs qdevice enable net
[root@qdevice:~]# pcs qdevice disable net
[root@qdevice:~]# pcs qdevice kill net
25.5.4. Gerenciamento das configurações do dispositivo de quorum em um cluster

As seções seguintes descrevem os comandos PCS que você pode usar para gerenciar as configurações
do dispositivo de quorum em um cluster.
25.5.4.1. Mudança das configurações do dispositivo de quorum
Você pode alterar a configuração de um dispositivo de quorum com o comando pcs quorum device
update.

ATENÇÃO
Para mudar a opção host do modelo net do dispositivo quorum, use os comandos
pcs quorum device remove e pcs quorum device add para configurar
corretamente a configuração, a menos que o antigo e o novo host sejam a mesma
máquina.
O seguinte comando muda o algoritmo do dispositivo de quorum para lms.
[root@node1:~]# pcs quorum device update model algorithm=lms

node1: Succeeded
node2: Succeeded
Reloading qdevice configuration on nodes...
node1: corosync-qdevice stopped
25.5.4.2. Remoção de um dispositivo de quorum
Use o seguinte comando para remover um dispositivo de quorum configurado em um nó de cluster.
[root@node1:~]# pcs quorum device remove

248
node1: Succeeded
node2: Succeeded
Disabling corosync-qdevice...
node1: corosync-qdevice disabled
node2: corosync-qdevice disabled
Stopping corosync-qdevice...
Removing qdevice certificates from nodes...
node1: Succeeded
node2: Succeeded
Depois de remover um dispositivo de quórum, você deve ver a seguinte mensagem de erro ao exibir o
status do dispositivo de quórum.
[root@node1:~]# pcs quorum device status

Error: Unable to get quorum status: corosync-qdevice-tool: Can't connect to QDevice socket (is
QDevice running?): No such file or directory
25.5.4.3. Destruindo um dispositivo de quorum
Para desativar e parar um dispositivo de quorum no host do dispositivo de quorum e excluir todos os
seus arquivos de configuração, use o seguinte comando.
[root@qdevice:~]# pcs qdevice destroy net

Stopping quorum device...
quorum device stopped
quorum device disabled
Quorum device 'net' configuration files removed
249
CAPÍTULO 26. ACIONAMENTO DE SCRIPTS PARA EVENTOS

DE CLUSTER
Um cluster Pacemaker é um sistema acionado por eventos, onde um evento pode ser uma falha de
recurso ou nó, uma mudança de configuração, ou um recurso iniciando ou parando. Você pode
configurar os alertas de cluster do Pacemaker para tomar alguma ação externa quando um evento de
cluster ocorre por meio de agentes de alerta, que são programas externos que o cluster chama da
mesma forma que o cluster chama os agentes de recursos para lidar com a configuração e operação dos
recursos.
O cluster passa informações sobre o evento para o agente por meio de variáveis ambientais. Os agentes
podem fazer qualquer coisa com estas informações, como enviar uma mensagem de e-mail ou log para
um arquivo ou atualizar um sistema de monitoramento.
Pacemaker fornece vários agentes de alerta de amostra, que são instalados em

/usr/share/pacemaker/alerts por padrão. Estes exemplos de scripts podem ser copiados e
usados como estão, ou podem ser usados como modelos a serem editados de acordo com seus
propósitos. Consulte o código fonte dos agentes de amostra para o conjunto completo de
atributos que eles suportam.
Se as amostras de agentes de alerta não atenderem às suas necessidades, você pode escrever
seus próprios agentes de alerta para que um alerta de Pacemaker seja chamado.
26.1. INSTALAÇÃO E CONFIGURAÇÃO DE AMOSTRAS DE AGENTES

DE ALERTA
Ao utilizar um dos agentes de alerta de amostra, você deve revisar o roteiro para garantir que ele se
adapte às suas necessidades. Estes agentes de amostra são fornecidos como ponto de partida para
scripts personalizados para ambientes de cluster específicos. Note que enquanto a Red Hat suporta as
interfaces que os scripts de agentes de alerta usam para se comunicar com o Pacemaker, a Red Hat não
fornece suporte para os agentes personalizados em si.
Para utilizar um dos agentes de alerta de amostra, você deve instalar o agente em cada nó do
aglomerado. Por exemplo, o seguinte comando instala o script alert_file.sh.sample como alert_file.sh.
# install --mode=0755 /usr/share/pacemaker/alerts/alert_file.sh.sample

/var/lib/pacemaker/alert_file.sh
Após ter instalado o roteiro, você pode criar um alerta que utiliza o roteiro.
O exemplo a seguir configura um alerta que utiliza o agente de alerta alert_file.sh instalado para
registrar eventos em um arquivo. Os agentes de alerta funcionam como o usuário hacluster, que tem
um conjunto mínimo de permissões.
Este exemplo cria o arquivo de registro pcmk_alert_file.log que será usado para registrar os eventos.
Ele então cria o agente de alerta e adiciona o caminho para o arquivo de registro como seu destinatário.
# touch /var/log/pcmk_alert_file.log
# chown hacluster:haclient /var/log/pcmk_alert_file.log
# chmod 600 /var/log/pcmk_alert_file.log
# pcs alert create id=alert_file description="Log events to a file."
path=/var/lib/pacemaker/alert_file.sh
# pcs alert recipient add alert_file id=my-alert_logfile value=/var/log/pcmk_alert_file.log
250
CAPÍTULO 26. ACIONAMENTO DE SCRIPTS PARA EVENTOS DE CLUSTER
O seguinte exemplo instala o script alert_snmp.sh.sample como alert_snmp.sh e configura um alerta

que usa o agente de alerta alert_snmp.sh instalado para enviar eventos de cluster como armadilhas
SNMP. Por padrão, o script enviará todos os eventos, exceto as chamadas de monitoramento bem
sucedidas para o servidor SNMP. Este exemplo configura o formato de timestamp como uma meta
opção. Após configurar o alerta, este exemplo configura um destinatário para o alerta e exibe a
configuração do alerta.
# install --mode=0755 /usr/share/pacemaker/alerts/alert_snmp.sh.sample

/var/lib/pacemaker/alert_snmp.sh
# pcs alert create id=snmp_alert path=/var/lib/pacemaker/alert_snmp.sh meta timestamp-
format="%Y-%m-%d,%H:%M:%S.%01N"
# pcs alert recipient add snmp_alert value=192.168.1.2
# pcs alert
Alerts:
Alert: snmp_alert (path=/var/lib/pacemaker/alert_snmp.sh)
Meta options: timestamp-format=%Y-%m-%d,%H:%M:%S.%01N.
Recipients:
Recipient: snmp_alert-recipient (value=192.168.1.2)
O exemplo seguinte instala o agente alert_smtp.sh e depois configura um alerta que usa o agente de
alerta instalado para enviar eventos de cluster como mensagens de e-mail. Após configurar o alerta,
este exemplo configura um destinatário e exibe a configuração do alerta.
# install --mode=0755 /usr/share/pacemaker/alerts/alert_smtp.sh.sample

/var/lib/pacemaker/alert_smtp.sh
# pcs alert create id=smtp_alert path=/var/lib/pacemaker/alert_smtp.sh options
email_sender=donotreply@example.com
# pcs alert recipient add smtp_alert value=admin@example.com
# pcs alert
Alerts:
Alert: smtp_alert (path=/var/lib/pacemaker/alert_smtp.sh)
Options: email_sender=donotreply@example.com
Recipients:
Recipient: smtp_alert-recipient (value=admin@example.com)
26.2. CRIANDO UM ALERTA DE AGRUPAMENTO

O seguinte comando cria um alerta de agrupamento. As opções que você configura são valores de
configuração específicos do agente que são passados para o script do agente de alerta no caminho
especificado como variáveis adicionais de ambiente. Se você não especificar um valor para id, será
gerado um.
pcs alert create path=path [id=alert-id] [description=description] [options [option=value]...] [meta

[meta-option=value]...]
Múltiplos agentes de alerta podem ser configurados; o grupo chamará todos eles para cada evento. Os
agentes de alerta serão chamados apenas nos nós de agrupamento. Eles serão chamados para eventos
envolvendo nós Remotos de Pacemaker, mas nunca serão chamados sobre esses nós.
O exemplo a seguir cria um alerta simples que ligará para myscript.sh para cada evento.
# pcs alert create id=my_alert path=/path/to/myscript.sh
251
26.3. EXIBIÇÃO, MODIFICAÇÃO E REMOÇÃO DE ALERTAS DE

AGRUPAMENTO
O seguinte comando mostra todos os alertas configurados juntamente com os valores das opções
configuradas.
pcs alert [config|show]
O seguinte comando atualiza um alerta existente com o valor alert-id especificado.
pcs alert update alert-id [path=path] [description=description] [options [option=value]...] [meta [meta-
option=value]...]
O seguinte comando remove um alerta com o valor alert-id especificado.
pcs alert remover alert-id
Alternativamente, você pode executar o comando pcs alert delete, que é idêntico ao comando pcs
alert remove. Tanto o comando pcs alert delete quanto o pcs alert remove permitem especificar mais
de um alerta a ser excluído.
26.4. CONFIGURAÇÃO DOS DESTINATÁRIOS DE ALERTA

Normalmente os alertas são direcionados para um destinatário. Assim, cada alerta pode ser configurado
adicionalmente com um ou mais destinatários. O grupo chamará o agente separadamente para cada
destinatário.
O destinatário pode ser qualquer coisa que o agente de alerta possa reconhecer: an Endereço IP, um
endereço de e-mail, um nome de arquivo, ou qualquer coisa que o agente em particular suporte.
O seguinte comando adiciona um novo destinatário ao alerta especificado.
pcs alert receptor adicionar alert-id value=recipient-value [id=recipient-id] [description=description]

[options [option=value]...] [meta [meta-option=value]...]
O seguinte comando atualiza um receptor de alerta existente.
pcs alertam o destinatário recipient-id [valor=recipient-value] [descrição=description] [opções

[option=value]...] [meta [meta-option=value]...]
O seguinte comando remove o receptor de alerta especificado.
pcs alertar o destinatário remover recipient-id
Alternativamente, você pode executar o comando pcs alert recipient delete, que é idêntico ao
comando pcs alert recipient remove. Tanto o comando pcs alert recipient remove como o pcs alert
recipient delete permitem remover mais de um receptor de alerta.
O seguinte exemplo de comando adiciona o destinatário do alerta my-alert-recipient com uma

identificação do destinatário de my-recipient-id ao alerta my-alert. Isto irá configurar o cluster para
chamar o script de alerta que foi configurado para my-alert para cada evento, passando o destinatário
some-address como uma variável de ambiente.
252
# pcs alert recipient add my-alert value=my-alert-recipient id=my-recipient-id options

value=some-address
26.5. META OPÇÕES DE ALERTA

Assim como os agentes de recursos, as meta opções podem ser configuradas para que os agentes de
alerta possam afetar a forma como a Pacemaker os chama. Tabela 26.1, “Alertar Meta Opções” descreve
as meta opções de alerta. As meta opções podem ser configuradas por agente de alerta, assim como
por destinatário.
Tabela 26.1. Alertar Meta Opções
Meta-Atributo Padrão Descrição
timestamp-format %H:%M:%S.N O formato que o grupo usará ao

enviar o carimbo de horário do
evento para o agente. Esta é uma
string como usada com o
comando date (1).
timeout 30s Se o agente de alerta não concluir

dentro deste período de tempo,
ele será encerrado.
O exemplo seguinte configura um alerta que chama o script myscript.sh e depois adiciona dois
destinatários ao alerta. O primeiro destinatário tem uma identificação de my-alert-recipient1 e o
segundo destinatário tem uma identificação de my-alert-recipient2. O script será chamado duas vezes
para cada evento, com cada chamada usando um timeout de 15 segundos. Uma chamada será passada
ao destinatário someuser@example.com com um timestamp no formato %H:%M, enquanto a outra
chamada será passada ao destinatário otheruser@example.com com um timestamp no formato
# pcs alert create id=my-alert path=/path/to/myscript.sh meta timeout=15s

# pcs alert recipient add my-alert value=someuser@example.com id=my-alert-recipient1 meta
timestamp-format="%D %H:%M"
# pcs alert recipient add my-alert value=otheruser@example.com id=my-alert-recipient2 meta
timestamp-format="%c"
26.6. EXEMPLOS DE COMANDOS DE CONFIGURAÇÃO DE ALERTAS

Os exemplos seqüenciais a seguir mostram alguns comandos básicos de configuração de alerta para
mostrar o formato a ser usado para criar alertas, adicionar destinatários e exibir os alertas configurados.
Observe que enquanto você deve instalar os próprios agentes de alerta em cada nó de um cluster, você
precisa executar os comandos pcs apenas uma vez.
Os seguintes comandos criam um alerta simples, adicionam dois destinatários ao alerta e exibem os
valores configurados.
Como nenhum valor de identificação de alerta é especificado, o sistema cria um valor de

identificação de alerta de alert.
O primeiro comando de criação de destinatários especifica um destinatário de rec_value. Como
253
O primeiro comando de criação de destinatários especifica um destinatário de rec_value. Como

este comando não especifica um ID de destinatário, o valor de alert-recipient é usado como o
ID de destinatário.
O segundo comando de criação de destinatários especifica um destinatário de rec_value2. Este

comando especifica um ID de destinatário de my-recipient para o destinatário.
# pcs alert create path=/my/path

# pcs alert recipient add alert value=rec_value
# pcs alert recipient add alert value=rec_value2 id=my-recipient
# pcs alert config
Alerts:
Alert: alert (path=/my/path)
Recipients:
Recipient: alert-recipient (value=rec_value)
Recipient: my-recipient (value=rec_value2)
Estes comandos seguintes acrescentam um segundo alerta e um destinatário para esse alerta. O ID do
alerta para o segundo alerta é my-alert e o valor do destinatário é my-other-recipient. Como nenhuma
identificação do destinatário é especificada, o sistema fornece uma identificação do destinatário de my-
alert-recipient.
# pcs alert create id=my-alert path=/path/to/script description=alert_description options

option1=value1 opt=val meta timeout=50s timestamp-format="%H%B%S"
# pcs alert recipient add my-alert value=my-other-recipient
# pcs alert
Alerts:
Recipients:
Alert: my-alert (path=/path/to/script)
Description: alert_description
Options: opt=val option1=value1
Meta options: timestamp-format=%H%B%S timeout=50s
Recipients:
Recipient: my-alert-recipient (value=my-other-recipient)
Os seguintes comandos modificam os valores de alerta para o alerta my-alert e para o destinatário my-
alert-recipient.
# pcs alert update my-alert options option1=newvalue1 meta timestamp-format="%H%M%S"

# pcs alert recipient update my-alert-recipient options option1=new meta timeout=60s
# pcs alert
Alerts:
Recipients:
Options: opt=val option1=newvalue1
Meta options: timestamp-format=%H%M%S timeout=50s
Recipients:
254

Options: option1=new
Meta options: timeout=60s
O seguinte comando remove o destinatário my-alert-recipient de alert.
# pcs alert recipient remove my-recipient

# pcs alert
Alerts:
Recipients:
Options: opt=val option1=newvalue1
Meta options: timestamp-format="%M%B%S" timeout=50s
Recipients:
Options: option1=new
Meta options: timeout=60s
O seguinte comando remove myalert da configuração.
# pcs alert remove myalert

# pcs alert
Alerts:
Recipients:
26.7. ESCREVER UM AGENTE DE ALERTA

Há três tipos de alertas de Pacemaker: alertas de nós, alertas de cercas e alertas de recursos. As
variáveis de ambiente que são passadas aos agentes de alerta podem ser diferentes, dependendo do
tipo de alerta. Tabela 26.2, “Variáveis Ambientais Passadas aos Agentes de Alerta” descreve as variáveis
de ambiente que são passadas aos agentes de alerta e especifica quando a variável de ambiente é
associada a um tipo de alerta específico.
Tabela 26.2. Variáveis Ambientais Passadas aos Agentes de Alerta
Variável Ambiental Descrição
CRM_alert_kind O tipo de alerta (nó, vedação, ou recurso)
CRM_alert_version A versão do Pacemaker enviando o alerta
CRM_alert_recipient O destinatário configurado
255
CRM_alert_node_sequence Um número seqüencial aumentado sempre que um

alerta é emitido no nó local, que pode ser usado para
referenciar a ordem na qual os alertas foram emitidos
pela Pacemaker. Um alerta para um evento que
aconteceu mais tarde de forma confiável tem um
número seqüencial maior do que os alertas para
eventos anteriores. Esteja ciente de que este
número não tem um significado de agrupamento.
CRM_alert_timestamp Um carimbo de tempo criado antes da execução do

agente, no formato especificado pela meta opção
timestamp-format. Isto permite que o agente
tenha um tempo confiável e de alta precisão de
quando o evento ocorreu, independentemente de
quando o próprio agente foi invocado (o que poderia
ser potencialmente atrasado devido à carga do
sistema ou outras circunstâncias).
CRM_alert_node Nome do nó afetado
CRM_alert_desc Detalhe do evento. Para alertas de nó, este é o

estado atual do nó (membro ou perdido). Para
alertas de esgrima, este é um resumo da operação de
esgrima solicitada, incluindo origem, alvo e código de
erro da operação de esgrima, se houver. Para alertas
de recursos, este é um equivalente de string legível
de CRM_alert_status.
CRM_alert_nodeid Identificação do nó cujo status mudou (fornecido

apenas com alertas de nó)
CRM_alert_task A operação de esgrima ou recurso solicitada (apenas

com alertas de esgrima e recursos)
CRM_alert_rc O código numérico de retorno da operação de

cercado ou recurso (fornecido apenas com alertas de
cercado e recurso)
CRM_alert_rsc O nome do recurso afetado (somente alertas de

recursos)
CRM_alert_interval O intervalo da operação do recurso (somente alertas

de recurso)
CRM_alert_target_rc O código numérico de retorno esperado da operação

(somente alertas de recursos)
256
CRM_alert_status Um código numérico utilizado pela Pacemaker para

representar o resultado da operação (apenas alertas
de recursos)
Ao escrever um agente de alerta, você deve levar em conta as seguintes preocupações.
Agentes de alerta podem ser chamados sem destinatário (se nenhum estiver configurado),
portanto, o agente deve ser capaz de lidar com esta situação, mesmo que só saia nesse caso.
Os usuários podem modificar a configuração em etapas, e adicionar um destinatário mais tarde.
Se mais de um destinatário estiver configurado para um alerta, o agente de alerta será chamado
uma vez por destinatário. Se um agente não for capaz de operar simultaneamente, ele deverá
ser configurado com apenas um único destinatário. O agente é livre, entretanto, para interpretar
o destinatário como uma lista.
Quando ocorre um evento de cluster, todos os alertas são disparados ao mesmo tempo em que
os processos são separados. Dependendo de quantos alertas e destinatários são configurados
e do que é feito dentro dos agentes de alerta, pode ocorrer uma explosão de carga significativa.
O agente pode ser escrito para levar isto em consideração, por exemplo, enfileirando ações de
recursos intensivos em alguma outra instância, em vez de executá-las diretamente.
Os agentes de alerta são executados como o usuário hacluster, que tem um conjunto mínimo
de permissões. Se um agente requer privilégios adicionais, recomenda-se configurar sudo para
permitir que o agente execute os comandos necessários como outro usuário com os privilégios
apropriados.
Tenha o cuidado de validar e higienizar parâmetros configurados pelo usuário, tais como
CRM_alert_timestamp (cujo conteúdo é especificado pelo usuário-configurado timestamp-
format), CRM_alert_recipient, e todas as opções de alerta. Isto é necessário para proteger
contra erros de configuração. Além disso, se algum usuário pode modificar a CIB sem ter acesso
aos nós de cluster em hacluster, esta é uma preocupação potencial de segurança também, e o
usuário deve evitar a possibilidade de injeção de código.
Se um cluster contém recursos com operações para as quais o parâmetro on-fail está definido
para fence, haverá múltiplas notificações de falha da cerca, uma para cada recurso para o qual
este parâmetro está definido mais uma notificação adicional. Tanto o pacemaker-fenced como
o pacemaker-controld enviarão notificações. O marcapasso realiza apenas uma operação de
cerca real neste caso, entretanto, não importa quantas notificações sejam enviadas.
NOTA
A interface de alertas é projetada para ser retrocompatível com a interface de scripts

externos utilizada pelo recurso ocf:pacemaker:ClusterMon. Para preservar esta
compatibilidade, as variáveis de ambiente passadas aos agentes de alerta estão
disponíveis com CRM_notify_ bem como CRM_alert_. Uma quebra na compatibilidade é
que o recurso ClusterMon executou scripts externos como usuário root, enquanto os
agentes de alerta são executados como usuário hacluster.
257
CAPÍTULO 27. CONFIGURAÇÃO DE CLUSTERS DE

MÚLTIPLOS LOCAIS COM PACEMAKER
Quando um cluster abrange mais de um site, os problemas de conectividade de rede entre os sites
podem levar a situações de cérebro dividido. Quando a conectividade cai, não há maneira de um nó em
um site determinar se um nó em outro site falhou ou ainda está funcionando com uma interligação de
site falhada. Além disso, pode ser problemático fornecer serviços de alta disponibilidade em dois sites
que estão muito distantes para manter a sincronia.
Para resolver estes problemas, a Pacemaker oferece suporte total para a capacidade de configurar
clusters de alta disponibilidade que abrangem vários locais através do uso de um gerente de ingressos
para clusters de estande.
27.1. VISÃO GERAL DO GERENTE DE BILHETERIA DE ESTANDES

O estande ticket manager é um serviço distribuído que deve ser executado em uma rede física diferente
das redes que conectam os nós de cluster em determinados locais. Ele produz outro cluster solto, um
Booth formation, que fica em cima dos clusters regulares nos sites. Esta camada de comunicação
agregada facilita os processos de decisão baseados em consenso para os bilhetes individuais dos
estandes.
Um estande ticket é um singleton na formação do estande e representa uma unidade de autorização

móvel e sensível ao tempo. Os recursos podem ser configurados para exigir um determinado bilhete
para rodar. Isto pode garantir que os recursos sejam executados em apenas um local de cada vez, para o
qual um bilhete ou bilhetes foram concedidos.
Você pode pensar na formação de um estande como um aglomerado sobreposto que consiste em
clusters funcionando em locais diferentes, onde todos os clusters originais são independentes uns dos
outros. É o serviço de estande que comunica aos aglomerados se foi concedido um bilhete, e é o
Pacemaker que determina se os recursos devem ser administrados em um aglomerado com base em
uma restrição de bilhetes do Pacemaker. Isto significa que ao utilizar o gerenciador de bilhetes, cada um
dos clusters pode administrar seus próprios recursos, bem como os recursos compartilhados. Por
exemplo, pode haver recursos A, B e C rodando apenas em um cluster, recursos D, E e F rodando
apenas no outro cluster, e recursos G e H rodando em qualquer um dos dois clusters conforme
determinado por um ticket. Também é possível ter um recurso adicional J que poderia funcionar em
qualquer um dos dois aglomerados, conforme determinado por um bilhete separado.
27.2. CONFIGURAÇÃO DE CLUSTERS DE MÚLTIPLOS LOCAIS COM

PACEMAKER
O procedimento a seguir fornece um esboço dos passos a seguir para configurar uma configuração em
vários locais que utiliza o gerente de bilhetes do estande.
Estes comandos de exemplo utilizam a seguinte disposição:
O Cluster 1 é composto pelos nós cluster1-node1 e cluster1-node2
O Cluster 1 tem um endereço IP flutuante atribuído a ele de 192.168.11.100
O Cluster 2 consiste em cluster2-node1 e cluster2-node2
O Cluster 2 tem um endereço IP flutuante atribuído a ele de 192.168.22.100
O nó árbitro é arbitrator-node com um endereço ip de 192.168.99.100
258
CAPÍTULO 27. CONFIGURAÇÃO DE CLUSTERS DE MÚLTIPLOS LOCAIS COM PACEMAKER
O nome do bilhete do estande que esta configuração utiliza é apacheticket
Estes comandos de exemplo assumem que os recursos de cluster para um serviço Apache foram
configurados como parte do grupo de recursos apachegroup para cada cluster. Não é necessário que
os recursos e grupos de recursos sejam os mesmos em cada cluster para configurar uma restrição de
ingressos para esses recursos, já que a instância Pacemaker para cada cluster é independente, mas isso
é um cenário de failover comum.
Observe que a qualquer momento no procedimento de configuração você pode entrar no comando pcs
booth config para exibir a configuração do estande para o nó ou cluster atual ou o comando pcs booth
status para exibir o status atual do estande no nó local.
1. Instale o pacote booth-site Booth ticket manager em cada nó de ambos os clusters.
[root@cluster1-node1 ~]# yum install -y booth-site

2. Instale os pacotes pcs, booth-core, e booth-arbitrator no nó árbitro.
[root@arbitrator-node ~]# yum install -y pcs booth-core booth-arbitrator
3. Se você estiver executando o daemon firewalld, execute os seguintes comandos em todos os

nós em ambos os clusters, bem como no nó árbitro para habilitar as portas que são exigidas pelo
Add-On de Alta Disponibilidade da Red Hat.
# firewall-cmd --permanent --add-service=high-availability`

# firewall-cmd --add-service=high-availability`
Talvez seja necessário modificar quais portos estão abertos para atender às condições locais.
Para mais informações sobre as portas que são exigidas pelo suplemento de alta disponibilidade
da Red Hat, veja Habilitação de portas para o suplemento de alta disponibilidade .
4. Criar uma configuração de estande em um nó de um cluster. Os endereços especificados para

cada cluster e para o árbitro devem ser endereços IP. Para cada cluster, você especifica um
endereço IP flutuante.
[cluster1-node1 ~] # pcs booth setup sites 192.168.11.100 192.168.22.100 arbitrators

192.168.99.100
Este comando cria os arquivos de configuração /etc/booth/booth.conf e /etc/booth/booth.key

no nó a partir do qual é executado.
5. Criar um bilhete para a configuração do estande. Este é o bilhete que será usado para definir a
restrição de recursos que permitirá que os recursos funcionem somente quando este bilhete
tiver sido concedido ao conjunto.
Este procedimento básico de configuração de failover utiliza apenas um ticket, mas você pode
criar tickets adicionais para cenários mais complicados onde cada ticket está associado a um
recurso ou recursos diferentes.
[cluster1-node1 ~] # pcs booth ticket add apacheticket
6. Sincronizar a configuração do estande com todos os nós do cluster atual.
259
[cluster1-node1 ~] # pcs booth sync
7. Do nó do árbitro, puxe a configuração do estande para o árbitro. Se você não o tiver feito
anteriormente, deve primeiro autenticar pcs para o nó do qual você está puxando a
configuração.
[arbitrator-node ~] # pcs host auth cluster1-node1

[arbitrator-node ~] # pcs booth pull cluster1-node1
8. Puxe a configuração da cabine para o outro conjunto e sincronize com todos os nós desse
conjunto. Como no caso do nó árbitro, se você não o fez anteriormente, deve primeiro
autenticar pcs para o nó do qual você está puxando a configuração.
[cluster2-node1 ~] # pcs host auth cluster1-node1

[cluster2-node1 ~] # pcs booth pull cluster1-node1
[cluster2-node1 ~] # pcs booth sync
9. Comece e habilite Booth no árbitro.
NOTA
Você não deve iniciar ou ativar manualmente Booth em nenhum dos nós dos
agrupamentos, uma vez que Booth funciona como um recurso de Pacemaker
nesses agrupamentos.
[arbitrator-node ~] # pcs booth start

[arbitrator-node ~] # pcs booth enable
10. Configure Booth para funcionar como um recurso de cluster em ambos os locais de cluster. Isto
cria um grupo de recursos com booth-ip e booth-service como membros desse grupo.
[cluster1-node1 ~] # pcs booth create ip 192.168.11.100

[cluster2-node1 ~] # pcs booth create ip 192.168.22.100
11. Adicione uma restrição de bilhetes ao grupo de recursos que você definiu para cada grupo.
[cluster1-node1 ~] # pcs constraint ticket add apacheticket apachegroup

[cluster2-node1 ~] # pcs constraint ticket add apacheticket apachegroup
Você pode digitar o seguinte comando para exibir as restrições de bilhetes atualmente
configuradas.
pcs constraint ticket [show]
12. Conceda o bilhete que você criou para esta configuração ao primeiro grupo.
Note que não é necessário ter restrições de ingressos definidas antes de conceder um bilhete.
Uma vez que você tenha inicialmente concedido um bilhete para um agrupamento, então Booth
assume o gerenciamento de bilhetes, a menos que você anule isto manualmente com o
comando pcs booth ticket revoke. Para obter informações sobre os comandos de
administração pcs booth, consulte a tela de ajuda do PCS para o comando pcs booth.
[cluster1-node1 ~] # pcs booth ticket grant apacheticket
260
CAPÍTULO 27. CONFIGURAÇÃO DE CLUSTERS DE MÚLTIPLOS LOCAIS COM PACEMAKER
É possível adicionar ou remover bilhetes a qualquer momento, mesmo após a conclusão deste
procedimento. Após adicionar ou remover um bilhete, entretanto, deve-se sincronizar os arquivos de
configuração com os outros nós e clusters, bem como com o árbitro e conceder o bilhete, como é
mostrado neste procedimento.
Para informações sobre comandos adicionais de administração de estandes que você pode usar para
limpar e remover arquivos de configuração de estandes, ingressos e recursos, consulte a tela de ajuda
do PCS para o comando pcs booth.
261
CAPÍTULO 28. INTEGRAÇÃO DE NÓS NÃO-COROASYNC EM

UM CLUSTER: O SERVIÇO PACEMAKER_REMOTE
O serviço pacemaker_remote permite que os nós que não funcionam corosync se integrem ao cluster
e façam com que o cluster gerencie seus recursos como se fossem verdadeiros nós de cluster.
Entre as capacidades que o serviço pacemaker_remote oferece estão as seguintes:
O serviço pacemaker_remote permite escalar além do limite de 32 nós de suporte da Red Hat
para o RHEL 8.1.
O serviço pacemaker_remote permite gerenciar um ambiente virtual como um recurso de

cluster e também gerenciar serviços individuais dentro do ambiente virtual como recursos de
cluster.
Os seguintes termos são usados para descrever o serviço pacemaker_remote.
cluster node
remote node
guest node
pacemaker_remote
Um cluster Pacemaker executando o serviço pacemaker_remote tem as seguintes características.
Os nós remotos e os nós convidados executam o serviço pacemaker_remote (com muito

pouca configuração necessária no lado da máquina virtual).
A pilha de cluster (pacemaker e corosync), rodando nos nós do cluster, conecta-se ao serviço
pacemaker_remote nos nós remotos, permitindo que eles se integrem ao cluster.
A pilha de cluster (pacemaker e corosync), rodando nos nós de cluster, lança os nós
convidados e se conecta imediatamente ao serviço pacemaker_remote nos nós convidados,
permitindo que eles se integrem ao cluster.
A principal diferença entre os nós de cluster e os nós remoto e de convidado que os nós de cluster
gerenciam é que os nós remoto e de convidado não estão rodando a pilha de cluster. Isto significa que
os nós remoto e de convidado têm as seguintes limitações:
não se realizam em quorum
eles não executam ações de dispositivos de esgrima
não são elegíveis para ser o Controlador Designado (DC) do cluster
eles mesmos não executam a gama completa de comandos pcs
Por outro lado, os nós remotos e os nós convidados não estão vinculados aos limites de escalabilidade
associados com a pilha de agregados.
Além dessas limitações observadas, os nós remotos e convidados comportam-se como nós de cluster
no que diz respeito ao gerenciamento de recursos, e os nós remotos e convidados podem eles mesmos
ser cercados. O cluster é totalmente capaz de gerenciar e monitorar recursos em cada nó remoto e
262
CAPÍTULO 28. INTEGRAÇÃO DE NÓS NÃO-COROASYNC EM UM CLUSTER: O SERVIÇO PACEMAKER_REMOTE
convidado: Você pode criar restrições contra eles, colocá-los em espera ou executar qualquer outra
ação nos nós de cluster com os comandos pcs. Os nós remoto e de convidado aparecem na saída de
status do cluster exatamente como os nós de cluster aparecem.
28.1. AUTENTICAÇÃO DO HOSPEDEIRO E DO CONVIDADO DOS NÓS

DE PACEMAKER_REMOTE
A conexão entre os nós de cluster e o pacemaker_remote é protegida usando a Camada de Segurança
de Transporte (TLS) com criptografia de chave pré-compartilhada (PSK) e autenticação sobre TCP
(usando a porta 3121 por padrão). Isto significa que tanto o nó de cluster quanto o nó rodando
pacemaker_remote devem compartilhar a mesma chave privada. Por padrão, esta chave deve ser
colocada em /etc/pacemaker/authkey nos dois nós de cluster e nos nós remotos.
O comando pcs cluster node add-guest estabelece o authkey para nós convidados e o pcs cluster
node add-remote estabelece o authkey para nós remotos.
28.2. CONFIGURAÇÃO DOS NÓS CONVIDADOS DA KVM

Um nó convidado da Pacemaker é um nó convidado virtual que executa o serviço pacemaker_remote.
O nó hóspede virtual é gerenciado pelo cluster.
28.2.1. Opções de recursos de nós de hóspedes

Ao configurar uma máquina virtual para atuar como um nó convidado, você cria um recurso
VirtualDomain, que gerencia a máquina virtual. Para descrições das opções que você pode definir para
um recurso VirtualDomain, veja Tabela 24.1, “Opções de Recursos para Recursos de Domínio Virtual” .
Além das opções de recursos VirtualDomain, as opções de metadados definem o recurso como um nó
convidado e definem os parâmetros de conexão. Você define estas opções de recurso com o comando
pcs cluster node add-guest. Tabela 28.1, “Opções de Metadados para Configuração de Recursos KVM
como Nós Remotos” descreve estas opções de metadados.
Tabela 28.1. Opções de Metadados para Configuração de Recursos KVM como Nós Remotos
Campo Padrão Descrição
remote-node <none> O nome do nó convidado que

este recurso define. Isto tanto
permite o recurso como um nó
convidado e define o nome único
usado para identificar o nó
convidado. WARNING: Este valor
não pode se sobrepor a nenhum
recurso ou ID de nó.
remote-port 3121 Configura uma porta

personalizada a ser utilizada para
a conexão do hóspede para
pacemaker_remote
remote-addr O endereço fornecido no O endereço IP ou nome do host

comando pcs host auth para se conectar a
263
Campo Padrão Descrição
remote-connect-timeout 60s O tempo antes de uma conexão

de convidado pendente será
expirado
28.2.2. Integrando uma máquina virtual como um nó convidado

O procedimento a seguir é um resumo de alto nível dos passos a serem executados para que a
Pacemaker lance uma máquina virtual e para integrar essa máquina como um nó convidado, usando
libvirt e convidados virtuais da KVM.
1. Configure os recursos do VirtualDomain.
2. Insira os seguintes comandos em cada máquina virtual para instalar pacotes

pacemaker_remote, inicie o serviço pcsd e habilite-o a funcionar na inicialização, e permita a
porta TCP 3121 através do firewall.
# yum install pacemaker-remote resource-agents pcs

# firewall-cmd --add-port 3121/tcp --permanent
# firewall-cmd --add-port 2224/tcp --permanent
3. Dê a cada máquina virtual um endereço de rede estático e um nome de host único, que deve ser
conhecido por todos os nós. Para informações sobre como definir um endereço IP estático para
a máquina virtual convidada, consulte o Virtualization Deployment and Administration Guide.
4. Se você ainda não o fez, autentique pcs ao nó que você estará integrando como um nó de
busca.
# pcs host auth nodename
5. Use o seguinte comando para converter um recurso VirtualDomain existente em um nó

convidado. Este comando deve ser executado em um nó de cluster e não no nó convidado que
está sendo adicionado. Além de converter o recurso, este comando copia o
/etc/pacemaker/authkey para o nó convidado e inicia e habilita o daemon pacemaker_remote
no nó convidado. O nome do nó para o nó convidado, que você pode definir arbitrariamente,
pode diferir do nome do host para o nó.
# pcs cluster node add-guest nodename resource_id [options]
6. Depois de criar o recurso VirtualDomain, você pode tratar o nó convidado da mesma forma que
trataria qualquer outro nó do agrupamento. Por exemplo, você pode criar um recurso e colocar
uma restrição de recursos no recurso a ser executado no nó convidado como nos comandos a
seguir, que são executados a partir de um nó de cluster. Você pode incluir nós convidados em
grupos, o que permite agrupar um dispositivo de armazenamento, sistema de arquivos e VM.
264
# pcs resource create webserver apache configfile=/etc/httpd/conf/httpd.conf op

# pcs constraint location webserver prefers nodename
28.3. CONFIGURAÇÃO DOS NÓS REMOTOS DO PACEMAKER

Um nó remoto é definido como um recurso de cluster com ocf:pacemaker:remote como o agente de
recurso. Você cria este recurso com o comando pcs cluster node add-remote.
28.3.1. Opções de recursos de nós remotos

Tabela 28.2, “Opções de recursos para nós remotos” descreve as opções de recursos que você pode
configurar para um recurso remote.
Tabela 28.2. Opções de recursos para nós remotos
C Padrão D
a e
m s
p c
o r
i
ç
ã
o
r 0 T
e e
c m
o p
n o
n e
e m
c s
t e
_ g
i u
n n
t d
e o
r s
v p
a a
l r
a
e
s
p
e
r
a
r
a
n
265
t
C Padrão De
a es
m sd
p ce
o rt
ie
çn
ãt
oa
r
r
e
l
i
g
a
r
a
u
m
n
ó
r
e
m
o
t
o
a
p
ó
s
u
m
a
c
o
n
e
x
ã
o
a
t
i
v
a
c
o
m
o
n
ó
r
e
266
m
C Padrão Do
a et
m so
p ct
o re
ir
çs
ãi
od
o
c
o
r
t
a
d
a
.
E
s
t
a
e
s
p
e
r
a
é
r
e
c
o
r
r
e
n
t
e
.
S
e
a
r
e
c
o
n
e
x
ã
o
f
a
l
267
h
C Padrão Da
a er
m sa
p cp
o ró
is
ço
ãp
oe
r
í
o
d
o
d
e
e
s
p
e
r
a
,
u
m
a
n
o
v
a
t
e
n
t
a
t
i
v
a
d
e
r
e
c
o
n
e
x
ã
o
s
e
r
á
f
268
e
C Padrão Di
a et
m sa
p ca
o rp
ió
çs
ãa
oo
b
s
e
r
v
a
ç
ã
o
d
o
t
e
m
p
o
d
e
e
s
p
e
r
a
.
Q
u
a
n
d
o
e
s
t
a
o
p
ç
ã
o
e
s
t
i
v
e
269
r
C Padrão De
a em
m su
p cs
o ro
i,
ço
ãP
oa
c
e
m
a
k
e
r
c
o
n
t
i
n
u
a
r
á
t
e
n
t
a
n
d
o
a
l
c
a
n
ç
a
r
e
c
o
n
e
c
t
a
r
-
s
e
a
270
o
C Padrão Dn
a eó
m sr
p ce
o rm
io
çt
ão
oi
n
d
e
f
i
n
i
d
a
m
e
n
t
e
a
p
ó
s
c
a
d
a
i
n
t
e
r
v
a
l
o
d
e
e
s
p
e
r
a
.
s Endereço especificado com o comando pcs host auth S

e e
r r
v
i
271
v d
C
e Padrão Do
a
r er
m sa
p cq
o ru
ie
çs
ãe
oc
o
n
e
c
t
a
r
.
E
s
t
e
p
o
d
e
s
e
r
u
m
e
n
d
e
r
e
ç
o
I
P
o
u
u
m
n
o
m
e
d
e
h
o
s
t
.
272
C
p Padrão DP
a
o eo
m
r sr
p
t ct
o ra
iT
çC
ãP
op
a
r
a
c
o
n
e
x
ã
o
.
28.3.2. Visão geral da configuração do nó remoto

Esta seção fornece um resumo de alto nível dos passos a serem executados para configurar um nó
Pacemaker Remote e para integrar esse nó em um ambiente de cluster Pacemaker existente.
1. No nó que você estará configurando como um nó remoto, permita serviços relacionados ao

cluster através do firewall local.

success
success
NOTA
Se você estiver usando diretamente iptables, ou alguma outra solução de firewall

além de firewalld, basta abrir as seguintes portas: Portas TCP 2224 e 3121.
2. Instale o daemon pacemaker_remote no nó remoto.
# yum install -y pacemaker-remote resource-agents pcs
3. Iniciar e ativar pcsd no nó remoto.

4. Se você ainda não o fez, autentique pcs no nó que você estará adicionando como um nó
remoto.
273
# pcs host auth remote1
5. Adicione o recurso do nó remoto ao agrupamento com o seguinte comando. Este comando

também sincroniza todos os arquivos de configuração relevantes para o novo nó, inicia o nó e o
configura para iniciar pacemaker_remote na inicialização. Este comando deve ser executado
em um nó de cluster e não no nó remoto que está sendo adicionado.
# pcs cluster node add-remote remote1
6. Depois de adicionar o recurso remote ao agrupamento, você pode tratar o nó remoto da

mesma forma que trataria qualquer outro nó no agrupamento. Por exemplo, você pode criar um
recurso e colocar uma restrição de recursos sobre o recurso a ser executado no nó remoto
como nos comandos a seguir, que são executados a partir de um nó de cluster.
# pcs resource create webserver apache configfile=/etc/httpd/conf/httpd.conf op

# pcs constraint location webserver prefers remote1

ATENÇÃO
Nunca envolva um recurso de conexão de nó remoto em um grupo de

recursos, restrição de colocação, ou restrição de ordem.
7. Configurar recursos de esgrima para o nó remoto. Os nós remotos são cercados da mesma
forma que os nós de cluster. Configurar os recursos de cercas para uso com nós remotos da
mesma forma que você faria com os nós de cluster. Observe, entretanto, que os nós remotos
nunca podem iniciar uma ação de vedação. Somente os nós de cluster são capazes de
realmente executar uma operação de cerca contra outro nó.
28.4. MUDANDO A LOCALIZAÇÃO PADRÃO DA PORTA

Se você precisar alterar a localização padrão da porta para Pacemaker ou pacemaker_remote, você
pode definir a variável de ambiente PCMK_remote_port que afeta estes dois daemons. Esta variável de
ambiente pode ser ativada colocando-a no arquivo /etc/sysconfig/pacemaker da seguinte forma.
====# Pacemaker Remote

...
#
# Specify a custom port for Pacemaker Remote connections
PCMK_remote_port=3121
Ao alterar a porta padrão usada por um determinado nó convidado ou remoto, a variável

PCMK_remote_port deve ser definida no arquivo /etc/sysconfig/pacemaker desse nó, e o recurso de
cluster que cria a conexão do nó convidado ou do nó remoto também deve ser configurado com o
mesmo número de porta (usando a opção remote-port metadados para nós convidados, ou a opção
port para nós remotos).
28.5. ATUALIZAÇÃO DE SISTEMAS COM NÓS DE

274
28.5. ATUALIZAÇÃO DE SISTEMAS COM NÓS DE

PACEMAKER_REMOTE
Se o serviço pacemaker_remote for interrompido em um nó Pacemaker Remote ativo, o cluster
migrará graciosamente os recursos para fora do nó antes de interromper o nó. Isto permite que você
realize atualizações de software e outros procedimentos de manutenção de rotina sem remover o nó do
cluster. Uma vez que o pacemaker_remote for desligado, no entanto, o cluster tentará imediatamente
reconectar-se. Se pacemaker_remote não for reiniciado dentro do tempo limite do monitor do recurso,
o cluster considerará a operação do monitor como falhada.
Se você deseja evitar falhas de monitoramento quando o serviço pacemaker_remote é interrompido

em um nó remoto do Pacemaker ativo, você pode usar o seguinte procedimento para retirar o nó do
cluster antes de realizar qualquer administração de sistema que possa parar pacemaker_remote
1. Parar o recurso de conexão do nó com o pcs resource disable resourcenameque tirará todos
os serviços do nó. Para nós convidados, isto também irá parar o VM, portanto o VM deve ser
iniciado fora do cluster (por exemplo, usando virsh) para realizar qualquer manutenção.
2. Realizar a manutenção necessária.
3. Quando estiver pronto para retornar o nó ao agrupamento, reative o recurso com o pcs
resource enable.
275
CAPÍTULO 29. EXECUÇÃO DE MANUTENÇÃO DE CLUSTERS

A fim de realizar a manutenção nos nós de seu cluster, você pode precisar parar ou mover os recursos e
serviços em execução naquele cluster. Ou você pode precisar parar o software do cluster enquanto
deixa os serviços intocados. Pacemaker oferece uma variedade de métodos para realizar a manutenção
do sistema.
Se você precisar parar um nó em um aglomerado enquanto continua a fornecer os serviços

funcionando nesse aglomerado em outro nó, você pode colocar o nó do aglomerado em modo
de espera. Um nó que está em modo de espera não é mais capaz de hospedar recursos.
Qualquer recurso atualmente ativo no nó será movido para outro nó, ou parado se nenhum
outro nó for elegível para executar o recurso. Para informações sobre o modo de espera,
consulte Colocando um nó em modo de espera.
Se você precisar mover um recurso individual para fora do nó no qual ele está atualmente
rodando sem parar esse recurso, você pode usar o comando pcs resource move para mover o
recurso para um nó diferente. Para obter informações sobre o comando pcs resource move,
consulte Movimentação manual de recursos em cluster .
Quando você executa o comando pcs resource move, isto acrescenta uma restrição ao
recurso para impedi-lo de rodar no nó no qual ele está rodando atualmente. Quando você
estiver pronto para mover o recurso de volta, poderá executar o comando pcs resource clear
ou pcs constraint delete para remover a restrição. Isto não necessariamente move os recursos
de volta para o nó original, no entanto, já que onde os recursos podem ser executados naquele
ponto depende de como você configurou seus recursos inicialmente. Você pode realocar um
recurso para seu nó preferido com o comando pcs resource relocate run, como descrito em
Movendo um recurso para seu nó preferido .
Se você precisar parar completamente um recurso em execução e impedir que o cluster o inicie
novamente, você pode usar o comando pcs resource disable. Para informações sobre o
comando pcs resource disable, consulte Habilitação, desativação e proibição de recursos de
cluster.
Se você quiser impedir que o Pacemaker tome qualquer ação para um recurso (por exemplo, se
você quiser desativar ações de recuperação enquanto realiza a manutenção no recurso, ou se
você precisar recarregar as configurações /etc/sysconfig/pacemaker ), use o comando pcs
resource unmanage, conforme descrito em Configurando um recurso para o modo não
gerenciado. Os recursos de conexão remota do pacemaker nunca devem ser não gerenciados.
Se você precisar colocar o cluster em um estado onde nenhum serviço será iniciado ou
interrompido, você pode definir a propriedade do cluster maintenance-mode. Colocando o
cluster em modo de manutenção, todos os recursos são automaticamente desmanchados. Para
informações sobre como colocar o cluster em modo de manutenção, consulte Colocando um
cluster em modo de manutenção.
Se você precisar atualizar os pacotes que compõem os Add-Ons RHEL de Alta Disponibilidade
e Armazenamento Resiliente, você pode atualizar os pacotes em um nó de cada vez ou em todo
o cluster como um todo, conforme resumido em Atualizando um cluster de alta disponibilidade
do Red Hat Enterprise Linux.
Se você precisar fazer manutenção em um nó remoto do Pacemaker, você pode remover esse
nó do cluster desativando o recurso do nó remoto, como descrito em Atualização de nós
remotos e nós convidados.
29.1. COLOCANDO UM NÓ EM MODO DE ESPERA
Quando um nó de cluster está em modo de espera, o nó não é mais capaz de hospedar recursos.
276
Quando um nó de cluster está em modo de espera, o nó não é mais capaz de hospedar recursos.
Quaisquer recursos atualmente ativos no nó serão movidos para outro nó.
O comando a seguir coloca o nó especificado em modo de espera. Se você especificar o --all, este
comando coloca todos os nós em modo de espera.
Você pode usar este comando ao atualizar os pacotes de um recurso. Você também pode usar este
comando ao testar uma configuração, para simular a recuperação sem realmente desligar um nó.
pcs node standby node | -- todos
O seguinte comando remove o nó especificado do modo de espera. Após executar este comando, o nó
especificado é então capaz de hospedar recursos. Se você especificar o --all, este comando remove
todos os nós do modo standby.
pcs node unstandby node | -- tudo
Note que ao executar o comando pcs node standby, isto impede que os recursos sejam executados no
nó indicado. Quando você executa o comando pcs node unstandby, isto permite que os recursos sejam
executados no nó indicado. Isto não necessariamente move os recursos de volta para o nó indicado;
onde os recursos podem ser executados naquele ponto depende de como você configurou seus
recursos inicialmente.
29.2. MOVIMENTAÇÃO MANUAL DOS RECURSOS DO CLUSTER

Você pode anular o agrupamento e forçar os recursos a se moverem a partir de sua localização atual. Há
duas ocasiões em que você gostaria de fazer isso:
Quando um nó está em manutenção, e você precisa mover todos os recursos funcionando

nesse nó para um nó diferente
Quando recursos individualmente especificados precisam ser movimentados
Para mover todos os recursos funcionando em um nó para um nó diferente, você coloca o nó em modo
de espera.
Você pode mover recursos individualmente especificados de uma das seguintes maneiras.
Você pode usar o comando pcs resource move para mover um recurso de um nó no qual ele
está rodando atualmente.
Você pode usar o comando pcs resource relocate run para mover um recurso para seu nó
preferido, conforme determinado pelo status atual do cluster, restrições, localização dos
recursos e outras configurações.
29.2.1. Movendo um recurso de seu nó atual

Para mover um recurso para fora do nó no qual ele está rodando atualmente, use o seguinte comando,
especificando o resource_id do recurso, conforme definido. Especifique o destination_node se você
quiser indicar em qual nó rodar o recurso que você está movendo.
pcs resource move resource_id [destination_node] [--master] [--master] [lifetime=lifetime]
NOTA
277
NOTA
Quando você executa o comando pcs resource move, isto acrescenta uma restrição ao
recurso para impedi-lo de rodar no nó no qual ele está rodando atualmente. Você pode
executar o comando pcs resource clear ou o comando pcs constraint delete para
remover a restrição. Isto não necessariamente move os recursos de volta para o nó
original; onde os recursos podem ser executados naquele ponto depende de como você
configurou seus recursos inicialmente.
Se você especificar o parâmetro --master do comando pcs resource move, o escopo da restrição é
limitado ao papel principal e você deve especificar master_id em vez de resource_id.
Opcionalmente, você pode configurar um parâmetro lifetime para o comando pcs resource move para
indicar um período de tempo em que a restrição deve permanecer. Você especifica as unidades de um
parâmetro lifetime de acordo com o formato definido na ISO 8601, o que requer que você especifique a
unidade como uma letra maiúscula como Y (para anos), M (para meses), W (para semanas), D (para
dias), H (para horas), M (para minutos), e S (para segundos).
Para distinguir uma unidade de minutos(M) de uma unidade de meses(M), é necessário especificar o PT
antes de indicar o valor em minutos. Por exemplo, um parâmetro lifetime de 5M indica um intervalo de
cinco meses, enquanto um parâmetro lifetime de PT5M indica um intervalo de cinco minutos.
O parâmetro lifetime é verificado em intervalos definidos pela propriedade do cluster cluster-recheck-

interval. Por padrão, este valor é de 15 minutos. Se sua configuração exigir que você verifique este
parâmetro com mais freqüência, você pode redefinir este valor com o seguinte comando.
pcs conjunto de propriedade cluster-recheck-interval=value
Opcionalmente, você pode configurar um --wait[=n] para o comando pcs resource move para indicar o
número de segundos de espera para que o recurso comece no nó de destino antes de retornar 0 se o
recurso for iniciado ou 1 se o recurso ainda não tiver começado. Se você não especificar n, será usado o
tempo limite padrão do recurso.
O seguinte comando move o recurso resource1 para o nó example-node2 e evita que ele volte ao nó
no qual estava originalmente rodando por uma hora e trinta minutos.
pcs resource move resource1 exemplo-node2 vida útil=PT1H30M
O seguinte comando move o recurso resource1 para o nó example-node2 e impede que ele volte ao
nó no qual estava originalmente rodando por trinta minutos.
pcs resource move resource1 exemplo-node2 lifetime=PT30M
29.2.2. Movendo um recurso para seu nó de preferência

Após um recurso ter se movido, seja devido a um failover ou a um administrador movendo manualmente
o nó, ele não necessariamente voltará a seu nó original, mesmo depois que as circunstâncias que
causaram o failover tenham sido corrigidas. Para deslocar os recursos para seu nó de preferência, use o
seguinte comando. Um nó preferencial é determinado pelo status atual do cluster, restrições,
localização dos recursos e outras configurações e pode mudar com o tempo.
pcs resource relocate run [resource1] [resource2] ...
Se você não especificar nenhum recurso, todos os recursos são realocados para seus nós preferidos.
278
Este comando calcula o nó preferido para cada recurso, ignorando a aderência do recurso. Após calcular
o nó preferido, ele cria restrições de localização que farão com que os recursos se movam para seus nós
preferidos. Uma vez que os recursos tenham sido movidos, as restrições são apagadas
automaticamente. Para remover todas as restrições criadas pelo comando pcs resource relocate run,
você pode digitar o comando pcs resource relocate clear. Para exibir o status atual dos recursos e seu
nó ótimo ignorando a aderência dos recursos, digite o comando pcs resource relocate show.
29.3. DESATIVAÇÃO, HABILITAÇÃO E PROIBIÇÃO DE RECURSOS DE

CLUSTER
Além dos comandos pcs resource move e pcs resource relocate, há uma variedade de outros
comandos que você pode usar para controlar o comportamento dos recursos do cluster.
Desabilitando um recurso de cluster

Você pode parar manualmente um recurso em execução e impedir que o cluster o inicie novamente
com o seguinte comando. Dependendo do resto da configuração (restrições, opções, falhas, etc.), o
recurso pode permanecer iniciado. Se você especificar a opção --wait, pcs esperará até 'n' segundos
para o recurso parar e então retornará 0 se o recurso estiver parado ou 1 se o recurso não tiver parado.
Se 'n' não for especificado, o tempo padrão é de 60 minutos.
pcs resource disable resource_id [--wait[=n]]]
A partir do Red Hat Enterprise Linux 8.2, você pode especificar que um recurso seja desativado somente
se a desativação do recurso não tiver um efeito sobre outros recursos. Assegurar que este seria o caso
pode ser impossível de fazer à mão quando relações complexas de recursos são estabelecidas.
O comando pcs resource disable --simulate mostra os efeitos da desativação de um recurso

sem alterar a configuração do cluster.
O comando pcs resource disable --safe desabilita um recurso somente se nenhum outro
recurso for afetado de alguma forma, como por exemplo, ser migrado de um nó para outro. O
comando pcs resource safe-disable é um pseudônimo para o comando pcs resource disable
--safe.
O comando pcs resource disable --safe --no-strict desabilita um recurso somente se nenhum
outro recurso for interrompido ou rebaixado
Permitindo um recurso de cluster

Use o seguinte comando para permitir que o agrupamento inicie um recurso. Dependendo do resto da
configuração, o recurso pode permanecer parado. Se você especificar a opção --wait, pcs esperará até
'n' segundos para que o recurso comece e então retornará 0 se o recurso for iniciado ou 1 se o recurso
não tiver começado. Se 'n' não for especificado, o tempo padrão é de 60 minutos.
pcs resource enable resource_id [--wait[=n]]]
Impedir que um recurso funcione em um determinado nó

Use o seguinte comando para evitar que um recurso seja executado em um nó especificado, ou no nó
atual, se nenhum nó for especificado.
pcs resource ban resource_id [node] [--master] [--master] [lifetime=lifetime] [--wait[=n]]
Note que quando você executa o comando pcs resource ban, isto adiciona uma restrição de
localização -INFINITY ao recurso para impedir que ele funcione no nó indicado. Você pode executar o
comando pcs resource clear ou o comando pcs constraint delete para remover a restrição. Isto não
279
necessariamente move os recursos de volta para o nó indicado; onde os recursos podem rodar naquele
ponto depende de como você configurou seus recursos inicialmente.
Se você especificar o parâmetro --master do comando pcs resource ban, o escopo da restrição é
limitado ao papel principal e você deve especificar master_id em vez de resource_id.
Opcionalmente, você pode configurar um parâmetro lifetime para o comando pcs resource ban para
indicar um período de tempo em que a restrição deve permanecer.
Opcionalmente, você pode configurar um --wait[=n] para o comando pcs resource ban para indicar o
número de segundos de espera para que o recurso comece no nó de destino antes de retornar 0 se o
recurso for iniciado ou 1 se o recurso ainda não tiver começado. Se você não especificar n, será usado o
tempo limite padrão do recurso.
Forçando um recurso a começar no nó atual

Use o parâmetro debug-start do comando pcs resource para forçar um recurso especificado a iniciar
no nó atual, ignorando as recomendações do cluster e imprimindo a saída a partir do início do recurso.
Isto é usado principalmente para depuração de recursos; a partida de recursos em um cluster é (quase)
sempre feita pelo Pacemaker e não diretamente com um comando pcs. Se seu recurso não está
iniciando, geralmente é devido ou a uma má configuração do recurso (que você depura no log do
sistema), a restrições que impedem o início do recurso ou a desativação do recurso. Você pode usar este
comando para testar a configuração do recurso, mas ele normalmente não deve ser usado para iniciar
recursos em um cluster.
O formato do comando debug-start é o seguinte.
pcs resource debug-start resource_id
29.4. COLOCANDO UM RECURSO EM MODO NÃO GERENCIADO

Quando um recurso está no modo unmanaged, o recurso ainda está na configuração, mas o Pacemaker
não gerencia o recurso.
O comando a seguir define os recursos indicados para o modo unmanaged.
pcs resource unmanage resource1 [resource2] ...
O seguinte comando define os recursos para o modo managed, que é o estado padrão.
pcs resource manage resource1 [resource2] ...
Você pode especificar o nome de um grupo de recursos com o comando pcs resource manage ou pcs
resource unmanage. O comando atuará sobre todos os recursos do grupo, de modo que você possa
definir todos os recursos de um grupo para o modo managed ou unmanaged com um único comando
e, em seguida, gerenciar os recursos contidos individualmente.
29.5. COLOCANDO UM CLUSTER EM MODO DE MANUTENÇÃO

Quando um cluster está em modo de manutenção, o cluster não inicia ou pára qualquer serviço até que
se diga o contrário. Quando o modo de manutenção é concluído, o cluster faz uma verificação de
sanidade do estado atual de qualquer serviço, e então pára ou inicia qualquer serviço que precise dele.
Para colocar um cluster em modo de manutenção, use o seguinte comando para definir a propriedade
do cluster maintenance-mode para true.
280
# pcs property set maintenance-mode=true
Para remover um cluster do modo de manutenção, use o seguinte comando para definir a propriedade
do cluster maintenance-mode para false.
# pcs property set maintenance-mode=false
Você pode remover uma propriedade de cluster da configuração com o seguinte comando.
pcs propriedade não definida property
Alternativamente, você pode remover uma propriedade de cluster de uma configuração, deixando o
campo de valor do comando pcs property set em branco. Isto restaura essa propriedade a seu valor
padrão. Por exemplo, se você definiu previamente a propriedade symmetric-cluster para false, o
seguinte comando remove o valor definido da configuração e restaura o valor de symmetric-cluster
para true, que é seu valor padrão.
# pcs property set symmetric-cluster=
29.6. ATUALIZAÇÃO DE UM CLUSTER DE ALTA DISPONIBILIDADE

RHEL
A atualização dos pacotes que compõem os Add-Ons RHEL High Availability e Resilient Storage Add-
Ons, seja individualmente ou como um todo, pode ser feita de uma de duas maneiras gerais:
Rolling Updates: Remover um nó de cada vez do serviço, atualizar seu software e depois integrá-
lo de volta ao cluster. Isto permite que o cluster continue fornecendo serviços e gerenciando
recursos enquanto cada nó é atualizado.
Entire Cluster Update : Pare todo o agrupamento, aplique atualizações em todos os nós e, em
seguida, inicie o backup do agrupamento.

ATENÇÃO
É fundamental que ao realizar procedimentos de atualização de software para os

clusters Red Hat Enterprise LInux de Alta Disponibilidade e Armazenamento
Resiliente, você garanta que qualquer nó que será submetido a atualizações não
seja um membro ativo do cluster antes que essas atualizações sejam iniciadas.
Para uma descrição completa de cada um desses métodos e os procedimentos a seguir para as
atualizações, consulte Práticas recomendadas para a aplicação de atualizações de software em um
Cluster RHEL de alta disponibilidade ou de armazenamento resiliente.
29.7. ATUALIZAÇÃO DE NÓS REMOTOS E NÓS DE CONVIDADOS

Se o serviço pacemaker_remote for interrompido em um nó remoto ativo ou em um nó convidado, o
cluster migrará graciosamente os recursos para fora do nó antes de parar o nó. Isto permite que você
realize atualizações de software e outros procedimentos de manutenção de rotina sem remover o nó do
281
cluster. Uma vez que pacemaker_remote seja desligado, no entanto, o cluster tentará imediatamente
reconectar-se. Se pacemaker_remote não for reiniciado dentro do tempo limite do monitor do recurso,
o cluster considerará a operação do monitor como falhada.
Se você deseja evitar falhas de monitoramento quando o serviço pacemaker_remote é interrompido

em um nó remoto do Pacemaker ativo, você pode usar o seguinte procedimento para retirar o nó do
cluster antes de realizar qualquer administração de sistema que possa parar pacemaker_remote
1. Parar o recurso de conexão do nó com o pcs resource disable resourcenameque tirará todos
os serviços do nó. Para nós convidados, isto também irá parar o VM, portanto o VM deve ser
iniciado fora do cluster (por exemplo, usando virsh) para realizar qualquer manutenção.
2. Realizar a manutenção necessária.
3. Quando estiver pronto para retornar o nó ao agrupamento, reative o recurso com o pcs
resource enable.
29.8. MIGRAÇÃO DE VMS EM UM CLUSTER RHEL

Informações sobre políticas de suporte para clusters de alta disponibilidade da RHEL com membros de
clusters virtualizados podem ser encontradas em Políticas de suporte para clusters de alta
disponibilidade da RHEL - Condições Gerais com Membros de Clusters Virtualizados. Como observado,
a Red Hat não suporta a migração ao vivo de nós de cluster ativos através de hipervisores ou hosts. Se
você precisar realizar uma migração ao vivo, primeiro você precisará parar os serviços de cluster na VM
para remover o nó do cluster, e então iniciar o backup do cluster após realizar a migração. Os passos
seguintes descrevem o procedimento para remover uma VM de um cluster, migrando a VM, e
restaurando a VM para o cluster.
Este procedimento se aplica às VMs que são usadas como nós de cluster completos, não às VMs
gerenciadas como recursos de cluster (incluindo as VMs usadas como nós convidados) que podem ser
migradas ao vivo sem precauções especiais. Para informações gerais sobre o procedimento mais
completo necessário para atualizar os pacotes que compõem os Add-Ons de Alta Disponibilidade e
Armazenamento Resiliente da RHEL, seja individualmente ou como um todo, consulte Práticas
Recomendadas para Aplicação de Atualizações de Software a um Cluster de Alta Disponibilidade ou
Armazenamento Resiliente da RHEL.
NOTA
Antes de realizar este procedimento, considere o efeito sobre o quorum de aglomeração

da remoção de um nó de aglomeração. Por exemplo, se você tiver um agrupamento de
três nós e remover um nó, seu agrupamento pode suportar apenas mais uma falha de nó.
Se um nó de um aglomerado de três nós já estiver em baixo, a remoção de um segundo
nó perderá o quorum.
1. Se alguma preparação precisar ser feita antes de parar ou mover os recursos ou software em
execução na VM para migrar, execute essas etapas.
2. Execute o seguinte comando na VM para parar o software de cluster na VM.
# pcs cluster stop
3. Realizar a migração ao vivo do VM.
4. Iniciar serviços de cluster na VM.
282
# pcs cluster start
283
CAPÍTULO 30. CONFIGURAÇÃO DE CLUSTERS DE

RECUPERAÇÃO DE DESASTRES
Um método de recuperação de desastres para um cluster de alta disponibilidade é a configuração de
dois clusters. Você pode então configurar um cluster como seu cluster principal de site, e o segundo
cluster como seu cluster de recuperação de desastres.
Em circunstâncias normais, o aglomerado primário está operando recursos no modo de produção. O

cluster de recuperação de desastres também tem todos os recursos configurados e está executando-os
em modo despromoção ou não está funcionando em modo de produção. Por exemplo, pode haver um
banco de dados rodando no cluster primário em modo promovido e rodando no cluster de recuperação
de desastres em modo despromovido. O banco de dados nesta configuração seria configurado para que
os dados sejam sincronizados do local primário para o local de recuperação de desastres. Isto é feito
através da própria configuração do banco de dados e não através da interface de comando pcs.
Quando o cluster primário cair, os usuários podem usar a interface de comando pcs para falhar
manualmente os recursos para o site de recuperação de desastres. Eles podem então entrar no site do
desastre e promover e iniciar os recursos lá. Uma vez recuperado o cluster primário, os usuários podem
usar a interface de comando pcs para mover manualmente os recursos de volta para o site primário.
A partir do Red Hat Enterprise Linux 8.2, você pode usar o comando pcs para exibir o status do cluster
do site principal e do site de recuperação de desastres a partir de um único nó em ambos os sites.
30.1. CONSIDERAÇÕES SOBRE CLUSTERS DE RECUPERAÇÃO DE

DESASTRES
Ao planejar e configurar um site de recuperação de desastres que você irá gerenciar e monitorar com a
interface de comando pcs, observe as seguintes considerações.
O local de recuperação de desastres deve ser um aglomerado. Isto torna possível configurá-lo
com as mesmas ferramentas e procedimentos similares ao local principal.
Os clusters primários e de recuperação de desastres são criados por comandos independentes

do pcs cluster setup.
Os clusters e seus recursos devem ser configurados para que os dados sejam sincronizados e o
failover seja possível.
Os nós de agrupamento no local de recuperação não podem ter os mesmos nomes que os nós
no local primário.
O usuário do pcs hacluster deve ser autenticado para cada nó em ambos os clusters no nó a
partir do qual você estará executando os comandos pcs.
30.2. EXIBIÇÃO DO STATUS DOS CLUSTERS DE RECUPERAÇÃO

Para configurar um cluster primário e um cluster de recuperação de desastres para que você possa
exibir o status de ambos os clusters, execute o seguinte procedimento.
NOTA
284
CAPÍTULO 30. CONFIGURAÇÃO DE CLUSTERS DE RECUPERAÇÃO DE DESASTRES
NOTA
A criação de um cluster de recuperação de desastres não configura automaticamente os

recursos nem reproduz os dados. Esses itens devem ser configurados manualmente pelo
usuário.
Neste exemplo:
O cluster primário será denominado PrimarySite e consistirá dos nós z1.example.com. e

z2.example.com.
O cluster do site de recuperação de desastres será denominado DRsite e será composto pelos
nós z3.example.com e z4.example.com.
Este exemplo estabelece um cluster básico sem recursos ou cercas configuradas.
1. Autenticar todos os nós que serão utilizados para ambos os agrupamentos.
[root@z1 ~]# pcs host auth z1.example.com z2.example.com z3.example.com

z4.example.com -u hacluster -p password
2. Criar o cluster que será usado como cluster primário e iniciar os serviços de cluster para o
cluster.
[root@z1 ~]# pcs cluster setup PrimarySite z1.example.com z2.example.com --start

{...}
Cluster has been successfully set up.
Starting cluster on hosts: 'z1.example.com', 'z2.example.com'...
3. Criar o cluster que será usado como o cluster de recuperação de desastres e iniciar os serviços
de cluster para o cluster.
[root@z1 ~]# pcs cluster setup DRSite z3.example.com z4.example.com --start

{...}
Cluster has been successfully set up.
Starting cluster on hosts: 'z3.example.com', 'z4.example.com'...
4. A partir de um nó no aglomerado primário, montar o segundo aglomerado como o local de

recuperação. O local de recuperação é definido por um nome de um de seus nós.
[root@z1 ~]# pcs dr set-recovery-site z3.example.com

Sending 'disaster-recovery config' to 'z3.example.com', 'z4.example.com'
z3.example.com: successful distribution of the file 'disaster-recovery config'
Sending 'disaster-recovery config' to 'z1.example.com', 'z2.example.com'
5. Verifique a configuração de recuperação de desastres.
285
[root@z1 ~]# pcs dr config

Local site:
Role: Primary
Remote site:
Role: Recovery
Nodes:
z1.example.com
z2.example.com
6. Verificar o status do aglomerado primário e do aglomerado de recuperação de desastres de um

nó no aglomerado primário.
[root@z1 ~]# pcs dr status

--- Local cluster - Primary site ---
Cluster name: PrimarySite
WARNINGS:
No stonith devices and stonith-enabled is not false
Cluster Summary:
* Stack: corosync
* Current DC: z2.example.com (version 2.0.3-2.el8-2c9cea563e) - partition with quorum
* Last updated: Mon Dec 9 04:10:31 2019
* Last change: Mon Dec 9 04:06:10 2019 by hacluster via crmd on z2.example.com
* 2 nodes configured
* 0 resource instances configured
Node List:

* No resources
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
--- Remote cluster - Recovery site ---

Cluster name: DRSite
WARNINGS:
No stonith devices and stonith-enabled is not false
Cluster Summary:
* Stack: corosync
* Current DC: z4.example.com (version 2.0.3-2.el8-2c9cea563e) - partition with quorum
* Last updated: Mon Dec 9 04:10:34 2019
* Last change: Mon Dec 9 04:09:55 2019 by hacluster via crmd on z4.example.com
* 2 nodes configured
* 0 resource instances configured
Node List:
286
CAPÍTULO 30. CONFIGURAÇÃO DE CLUSTERS DE RECUPERAÇÃO DE DESASTRES

* No resources
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
Para opções de exibição adicionais para uma configuração de recuperação de desastres, consulte a tela
de ajuda para o comando pcs dr.
287

Red Hat Enterprise Linux-8-Configuring and Managing High Availability Clusters-pt-BR

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Red Hat Enterprise Linux-8-Configuring and Managing High Availability Clusters-pt-BR

Enviado por

Direitos autorais:

Formatos disponíveis

Red Hat Enterprise Linux 8

Configuração e gerenciamento de clusters de

Configuração e gerenciamento do Red Hat High Availability Add-On

Last Updated: 2021-02-27

Enter your first name here. Enter your surname here.

CAPÍTULO 5. CONFIGURAÇÃO DE UM SERVIDOR HTTP APACHE ATIVO/PASSIVO EM UM CLUSTER RED

CAPÍTULO 6. CONFIGURAÇÃO DE UM SERVIDOR NFS ATIVO/PASSIVO EM UM CLUSTER RED HAT HIGH

6.6. TESTE DA CONFIGURAÇÃO DO RECURSO NFS 49

CAPÍTULO 9. CONFIGURAÇÃO DE CERCAS EM UM CLUSTER DE ALTA DISPONIBILIDADE DE CHAPÉU

10.4.2. Remoção de um grupo de recursos 139

CAPÍTULO 12. DETERMINAÇÃO DA ORDEM NA QUAL OS RECURSOS DE AGRUPAMENTO SÃO

16.6.2. Eliminação de um recurso de cluster etiquetado 168

CAPÍTULO 22. CONFIGURAÇÃO DE RECURSOS PARA PERMANECER PARADO NO DESLIGAMENTO DO NÓ

23.2.2. Capacidade do Nó 200

CAPÍTULO 28. INTEGRAÇÃO DE NÓS NÃO-COROASYNC EM UM CLUSTER: O SERVIÇO

Permitindo um recurso de cluster 279

TORNANDO O CÓDIGO ABERTO MAIS INCLUSIVO

FORNECENDO FEEDBACK SOBRE A DOCUMENTAÇÃO DA

Para comentários simples sobre passagens específicas:

1. Certifique-se de que você está visualizando a documentação no formato Multi-page HTML.

3. Clique no pop-up Add Feedback que aparece abaixo do texto destacado.

4. Siga as instruções apresentadas.

Para enviar comentários mais complexos, crie um bilhete Bugzilla:

1. Ir para o site da Bugzilla.

2. Como Componente, use Documentation.

4. Clique em Submit Bug.

CAPÍTULO 1. VISÃO GERAL DO ADD-ON DE ALTA

1.1. COMPONENTES ADICIONAIS DE ALTA DISPONIBILIDADE

Gestão de serviços de alta disponibilidade

Ferramentas de administração de clusters

Você pode complementar o Add-On de Alta Disponibilidade com os seguintes componentes:

Red Hat GFS2 (Global File System 2)

LVM Locking Daemon (lvmlockd)

1.2. VISÃO GERAL DO MARCAPASSO

1.2.1. Componentes da arquitetura do marcapasso

Os seguintes componentes formam a arquitetura do Pacemaker:

Base de Informações do Cluster (CIB)

Atire no Outro Nó da Cabeça (STONITH)

Gerencia as regras de quorum e determinação.

Fornece recursos de mensagens para aplicações que coordenam ou operam em múltiplos

1.2.2. Ferramentas de configuração e gerenciamento

Criar e configurar um cluster Pacemaker/Corosync

Modificar a configuração do cluster enquanto ele está funcionando

Configurar remotamente tanto Pacemaker e Corosync, quanto iniciar, parar e exibir

1.2.3. Os arquivos de configuração do cluster e do marcapasso

O arquivo corosync.conf fornece os parâmetros de cluster usados pelo corosync, o gerenciador de

1.3. VISÃO GERAL DA VEDAÇÃO

Quando a vedação está em andamento, nenhuma outra operação de agrupamento é permitida. A

1.4. VISÃO GERAL DO QUORUM

O Quorum é estabelecido usando um sistema de votação. Quando um nó de agrupamento não funciona

As características do quorum em Pacemaker impedem o que também é conhecido como split-brain, um

1.5. VISÃO GERAL DOS RECURSOS

Você pode determinar o comportamento de um recurso em um cluster configurando constraints. Você

1.6. VOLUMES LÓGICOS LVM EM UM CLUSTER DE ALTA

Volumes LVM de alta disponibilidade (HA-LVM) em configurações de failover ativo/passivo em

1.6.1. Escolhendo HA-LVM ou volumes compartilhados

Se vários nós do cluster requerem acesso simultâneo de leitura/escrita a volumes LVM em um

Se o cluster de alta disponibilidade for configurado para gerenciar recursos compartilhados de

1.6.2. Configuração de volumes LVM em um cluster

Para exemplos de procedimentos para configurar um volume HA-LVM como parte de um

Assegurar que somente o agrupamento seja capaz de ativar o grupo de volume

Configuração de um volume lógico LVM

Configuração do volume da LVM como um recurso de cluster

Para um procedimento de configuração de volumes LVM compartilhados que utilizam o