• Nenhum resultado encontrado

Red Hat Enterprise Linux 8

N/A
N/A
Protected

Academic year: 2021

Share "Red Hat Enterprise Linux 8"

Copied!
291
0
0

Texto

(1)

Configuração e gerenciamento de clusters de

alta disponibilidade

Configuração e gerenciamento do Red Hat High Availability Add-On

(2)
(3)

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.

(4)

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.

(5)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Índice

TORNANDO O CÓDIGO ABERTO MAIS INCLUSIVO

FORNECENDO FEEDBACK SOBRE A DOCUMENTAÇÃO DA RED HAT CAPÍTULO 1. VISÃO GERAL DO ADD-ON DE ALTA DISPONIBILIDADE

1.1. COMPONENTES ADICIONAIS DE ALTA DISPONIBILIDADE 1.2. VISÃO GERAL DO MARCAPASSO

1.2.1. Componentes da arquitetura do marcapasso 1.2.2. Ferramentas de configuração e gerenciamento

1.2.3. Os arquivos de configuração do cluster e do marcapasso 1.3. VISÃO GERAL DA VEDAÇÃO

1.4. VISÃO GERAL DO QUORUM 1.5. VISÃO GERAL DOS RECURSOS

1.6. VOLUMES LÓGICOS LVM EM UM CLUSTER DE ALTA DISPONIBILIDADE DA RED HAT 1.6.1. Escolhendo HA-LVM ou volumes compartilhados

1.6.2. Configuração de volumes LVM em um cluster CAPÍTULO 2. COMEÇANDO COM PACEMAKER

2.1. APRENDENDO A USAR O PACEMAKER 2.2. APRENDENDO A CONFIGURAR O FAILOVER

CAPÍTULO 3. A INTERFACE DE LINHA DE COMANDO PCS 3.1. PCS AJUDAM A EXIBIR

3.2. VISUALIZANDO A CONFIGURAÇÃO DO CLUSTER BRUTO

3.3. SALVANDO UMA MUDANÇA DE CONFIGURAÇÃO PARA UM ARQUIVO DE TRABALHO 3.4. EXIBIÇÃO DO STATUS DO CLUSTER

3.5. EXIBIÇÃO DA CONFIGURAÇÃO COMPLETA DO CLUSTER

CAPÍTULO 4. CRIANDO UM CLUSTER DE ALTA DISPONIBILIDADE RED HAT COM PACEMAKER 4.1. INSTALAÇÃO DE SOFTWARE DE CLUSTER

4.2. INSTALAÇÃO DO PACOTE PCP-ZEROCONF (RECOMENDADO) 4.3. CRIAÇÃO DE UM CLUSTER DE ALTA DISPONIBILIDADE

4.4. CRIAÇÃO DE UM CLUSTER DE ALTA DISPONIBILIDADE COM MÚLTIPLOS LINKS 4.5. CONFIGURAÇÃO DE CERCAS

4.6. APOIO E RESTAURAÇÃO DE UMA CONFIGURAÇÃO DE CLUSTER 4.7. HABILITAÇÃO DE PORTAS PARA O ADD-ON DE ALTA DISPONIBILIDADE

CAPÍTULO 5. CONFIGURAÇÃO DE UM SERVIDOR HTTP APACHE ATIVO/PASSIVO EM UM CLUSTER RED HAT HIGH AVAILABILITY

5.1. CONFIGURAÇÃO DE UM VOLUME LVM COM UM SISTEMA DE ARQUIVO EXT4 EM UM CLUSTER PACEMAKER

5.2. CONFIGURAÇÃO DE UM SERVIDOR HTTP APACHE 5.3. CRIAÇÃO DOS RECURSOS E GRUPOS DE RECURSOS 5.4. TESTE DA CONFIGURAÇÃO DOS RECURSOS

CAPÍTULO 6. CONFIGURAÇÃO DE UM SERVIDOR NFS ATIVO/PASSIVO EM UM CLUSTER RED HAT HIGH AVAILABILITY

6.1. PRÉ-REQUISITOS

6.2. VISÃO GERAL DOS PROCEDIMENTOS

6.3. CONFIGURAÇÃO DE UM VOLUME LVM COM UM SISTEMA DE ARQUIVO EXT4 EM UM CLUSTER PACEMAKER

6.4. CONFIGURAÇÃO DE UM COMPARTILHAMENTO NFS

6.5. CONFIGURAÇÃO DOS RECURSOS E GRUPO DE RECURSOS PARA UM SERVIDOR NFS EM UM CLUSTER 8 9 10 10 10 10 11 11 12 12 13 13 13 14 15 15 19 25 25 25 25 26 27 28 28 29 30 31 32 33 33 36 37 38 39 41 43 43 43 43 45 45

(6)

. . . .

. . . .

. . . .

. . . . 6.6. TESTE DA CONFIGURAÇÃO DO RECURSO NFS

6.6.1. Teste da exportação do NFS 6.6.2. Teste de failover

CAPÍTULO 7. SISTEMAS DE ARQUIVO GFS2 EM UM CLUSTER

7.1. CONFIGURAÇÃO DE UM SISTEMA DE ARQUIVO GFS2 EM UM CLUSTER 7.2. MIGRAÇÃO DE UM SISTEMA DE ARQUIVOS GFS2 DE RHEL7 PARA RHEL8 CAPÍTULO 8. COMEÇANDO COM O PCSD WEB UI

8.1. INSTALAÇÃO DE SOFTWARE DE CLUSTER 8.2. CRIAÇÃO DA INTERFACE WEB DO PCSD 8.3. CRIANDO UM CLUSTER COM O PCSD WEB UI

8.3.1. Configuração de opções avançadas de configuração de clusters com a interface Web do pcsd 8.3.2. Definição de permissões de gerenciamento de clusters

8.4. CONFIGURAÇÃO DE COMPONENTES DE CLUSTER COM O PCSD WEB UI 8.4.1. Configuração de nós de cluster com a interface Web do pcsd

8.4.2. Configuração de recursos de cluster com o pcsd Web UI

8.4.3. Configuração de dispositivos de vedação com a interface Web do pcsd 8.4.4. Configuração de ACLs com a interface web pcsd

8.4.5. Configuração das propriedades do cluster com a interface Web do pcsd 8.5. CONFIGURAÇÃO DE UMA INTERFACE WEB PCSD DE ALTA DISPONIBILIDADE

CAPÍTULO 9. CONFIGURAÇÃO DE CERCAS EM UM CLUSTER DE ALTA DISPONIBILIDADE DE CHAPÉU VERMELHO

9.1. EXIBIÇÃO DOS AGENTES DE VEDAÇÃO DISPONÍVEIS E SUAS OPÇÕES 9.2. CRIANDO UM DISPOSITIVO DE CERCA

9.3. PROPRIEDADES GERAIS DOS DISPOSITIVOS DE ESGRIMA 9.4. OPÇÕES AVANÇADAS DE CONFIGURAÇÃO DE CERCAS 9.5. TESTE DE UM DISPOSITIVO DE CERCA

9.6. CONFIGURAÇÃO DOS NÍVEIS DE VEDAÇÃO

9.7. CONFIGURAÇÃO DE CERCAS PARA FONTES DE ALIMENTAÇÃO REDUNDANTES 9.8. EXIBIÇÃO DE DISPOSITIVOS DE CERCAS CONFIGURADOS

9.9. MODIFICAÇÃO E ELIMINAÇÃO DE DISPOSITIVOS DE CERCAS 9.10. ESGRIMA MANUAL DE UM NÓ DE CLUSTER

9.11. DESATIVAÇÃO DE UM DISPOSITIVO DE CERCA

9.12. IMPEDIR QUE UM NÓ UTILIZE UM DISPOSITIVO DE VEDAÇÃO

9.13. CONFIGURAÇÃO DO ACPI PARA USO COM DISPOSITIVOS DE CERCAS INTEGRADAS 9.13.1. Desabilitando o ACPI Soft-Off com o BIOS

9.13.2. Desabilitando o ACPI Soft-Off no arquivo logind.conf 9.13.3. Desabilitando completamente o ACPI no arquivo GRUB 2 CAPÍTULO 10. CONFIGURAÇÃO DE RECURSOS DE CLUSTER

Exemplos de criação de recursos Eliminação de um recurso configurado

10.1. IDENTIFICADORES DO AGENTE DE RECURSOS

10.2. EXIBIÇÃO DE PARÂMETROS ESPECÍFICOS DE RECURSOS 10.3. CONFIGURANDO AS META OPÇÕES DE RECURSOS

10.3.1. Alterando o valor padrão de uma opção de recurso

10.3.2. Alteração do valor padrão de uma opção de recurso para conjuntos de recursos (RHEL 8.3 e posteriores)

10.3.3. Exibição dos padrões de recursos configurados atualmente 10.3.4. Definição de meta opções na criação de recursos

10.4. CONFIGURAÇÃO DE GRUPOS DE RECURSOS 10.4.1. Criação de um grupo de recursos

49 49 50 52 52 57 59 59 60 61 61 62 62 63 63 64 64 64 65 66 66 67 67 69 81 84 85 86 86 86 87 87 87 88 89 89 91 91 91 91 93 93 137 137 137 138 138 139

(7)

. . . . . . . . . . . . . . . . . . . . . . . . 10.4.2. Remoção de um grupo de recursos

10.4.3. Exibição de grupos de recursos 10.4.4. Opções de grupo

10.4.5. Adesividade do grupo

10.5. DETERMINANDO O COMPORTAMENTO DOS RECURSOS

CAPÍTULO 11. DETERMINAÇÃO DOS NÓS EM QUE UM RECURSO PODE FUNCIONAR 11.1. CONFIGURAÇÃO DAS RESTRIÇÕES DE LOCALIZAÇÃO

11.2. LIMITANDO A DESCOBERTA DE RECURSOS A UM SUBCONJUNTO DE NÓS 11.3. CONFIGURAÇÃO DE UMA ESTRATÉGIA DE RESTRIÇÃO DE LOCALIZAÇÃO

11.3.1. Configuração de um Cluster "Opt-In 11.3.2. Configuração de um Cluster "Opt-Out"

11.4. CONFIGURAÇÃO DE UM RECURSO PARA PREFERIR SEU NÓ ATUAL

CAPÍTULO 12. DETERMINAÇÃO DA ORDEM NA QUAL OS RECURSOS DE AGRUPAMENTO SÃO EXECUTADOS

12.1. CONFIGURAÇÃO DE PEDIDOS OBRIGATÓRIOS 12.2. CONFIGURAÇÃO DE PEDIDOS DE CONSULTORIA

12.3. CONFIGURAÇÃO DE CONJUNTOS DE RECURSOS ENCOMENDADOS

12.4. CONFIGURAÇÃO DE ORDEM DE PARTIDA PARA DEPENDÊNCIAS DE RECURSOS NÃO GERENCIADAS PELA PACEMAKER

CAPÍTULO 13. COLOCANDO RECURSOS DE CLUSTER

13.1. ESPECIFICAR A COLOCAÇÃO OBRIGATÓRIA DE RECURSOS 13.2. ESPECIFICAR A COLOCAÇÃO DE RECURSOS CONSULTIVOS 13.3. COLOCANDO CONJUNTOS DE RECURSOS

13.4. REMOÇÃO DE RESTRIÇÕES DE COLOCAÇÃO CAPÍTULO 14. EXIBINDO RESTRIÇÕES DE RECURSOS

14.1. EXIBINDO TODAS AS RESTRIÇÕES CONFIGURADAS 14.2. EXIBIÇÃO DAS RESTRIÇÕES DE LOCALIZAÇÃO 14.3. EXIBIR RESTRIÇÕES DE PEDIDOS

14.4. EXIBIÇÃO DE RESTRIÇÕES DE COLOCAÇÃO

14.5. EXIBINDO RESTRIÇÕES ESPECÍFICAS DE RECURSOS

14.6. EXIBIÇÃO DAS DEPENDÊNCIAS DE RECURSOS (RED HAT ENTERPRISE LINUX 8.2 E POSTERIORES) CAPÍTULO 15. DETERMINAÇÃO DA LOCALIZAÇÃO DOS RECURSOS COM REGRAS

15.1. REGRAS DO MARCAPASSO 15.1.1. Expressões de atributos de nós 15.1.2. Expressões baseadas em tempo/data 15.1.3. Especificações de data

15.2. CONFIGURAÇÃO DE UMA RESTRIÇÃO DE LOCALIZAÇÃO DE MARCAPASSO USANDO REGRAS CAPÍTULO 16. GERENCIAMENTO DE RECURSOS DE CLUSTER

16.1. EXIBIÇÃO DE RECURSOS CONFIGURADOS

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

16.3. STATUS DE FALHAS DE COMPENSAÇÃO DE RECURSOS DE CLUSTER 16.4. MOVIMENTAÇÃO DE RECURSOS EM UM CLUSTER

16.4.1. Movimentação de recursos devido a falhas

16.4.2. Movimentação de recursos devido a mudanças na conectividade 16.5. DESABILITANDO UMA OPERAÇÃO DE MONITOR

16.6. CONFIGURAÇÃO E GERENCIAMENTO DE ETIQUETAS DE RECURSOS DE CLUSTER (RHEL 8.3 E POSTERIORES)

16.6.1. Marcação de recursos de cluster para administração por categoria

139 140 140 140 140 141 141 143 145 145 145 146 147 148 148 148 150 152 152 153 153 154 155 155 155 155 155 155 156 158 158 158 160 161 161 163 163 163 164 164 165 165 166 167 167

(8)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.6.2. Eliminação de um recurso de cluster etiquetado

CAPÍTULO 17. CRIAÇÃO DE RECURSOS DE CLUSTER QUE ESTÃO ATIVOS EM MÚLTIPLOS NÓS (RECURSOS CLONADOS)

17.1. CRIAÇÃO E REMOÇÃO DE UM RECURSO CLONADO

17.2. CONFIGURAÇÃO DE RESTRIÇÕES DE RECURSOS CLONAIS 17.3. CRIAÇÃO DE RECURSOS DE CLONAGEM PROMOCIONAIS

17.3.1. Criando um recurso promocional

17.3.2. Configuração de restrições de recursos promocionais

17.4. DEMONSTRANDO UM RECURSO PROMOVIDO SOBRE O FRACASSO (RHEL 8.3 E POSTERIORES) CAPÍTULO 18. GERENCIANDO NÓS DE CLUSTER

18.1. PARAR OS SERVIÇOS DE CLUSTER

18.2. HABILITAÇÃO E DESATIVAÇÃO DE SERVIÇOS DE CLUSTER 18.3. ADIÇÃO DE NÓS DE CLUSTER

18.4. REMOÇÃO DE NÓS DE CLUSTER

18.5. ADICIONANDO UM NÓ A UM AGRUPAMENTO COM MÚLTIPLOS LINKS

18.6. ADIÇÃO E MODIFICAÇÃO DE LINKS EM UM CLUSTER EXISTENTE (RHEL 8.1 E POSTERIORES) 18.6.1. Adicionar e remover links em um cluster existente

18.6.2. Modificação de um link em um cluster com múltiplos links

18.6.3. Modificando os endereços dos links em um cluster com um único link 18.6.4. Modificando as opções de link para um link em um cluster com um único link 18.6.5. Modificar um link ao adicionar um novo link não é possível

18.7. CONFIGURAÇÃO DE UM GRANDE CLUSTER COM MUITOS RECURSOS

CAPÍTULO 19. DEFINIR PERMISSÕES DE USUÁRIO PARA UM CLUSTER DE PACEMAKER 19.1. DEFINIR PERMISSÕES PARA O ACESSO DOS NÓS ATRAVÉS DE UMA REDE

19.2. DEFINIR PERMISSÕES LOCAIS USANDO ACLS

CAPÍTULO 20. OPERAÇÕES DE MONITORAMENTO DE RECURSOS

20.1. CONFIGURAÇÃO DE OPERAÇÕES DE MONITORAMENTO DE RECURSOS 20.2. CONFIGURAÇÃO DE PADRÕES DE OPERAÇÃO DE RECURSOS GLOBAIS

20.2.1. Valores de operação superiores aos recursos específicos

20.2.2. Alteração do valor padrão de uma operação de recurso para conjuntos de recursos (RHEL 8.3 e posteriores)

20.2.3. Exibição dos valores padrão de operação dos recursos atualmente configurados 20.3. CONFIGURAÇÃO DE MÚLTIPLAS OPERAÇÕES DE MONITORAMENTO

CAPÍTULO 21. PROPRIEDADES DO CONJUNTO DO MARCAPASSO 21.1. RESUMO DAS PROPRIEDADES E OPÇÕES DO CLUSTER

21.2. AJUSTE E REMOÇÃO DAS PROPRIEDADES DE AGRUPAMENTO 21.3. CONSULTA DE CONFIGURAÇÕES DE PROPRIEDADE DE CLUSTERS

CAPÍTULO 22. CONFIGURAÇÃO DE RECURSOS PARA PERMANECER PARADO NO DESLIGAMENTO DO NÓ LIMPO (RHEL 8.2 E POSTERIORES)

22.1. PROPRIEDADES DO CLUSTER PARA CONFIGURAR RECURSOS PARA PERMANECER PARADO NO DESLIGAMENTO DO NÓ LIMPO

22.2. CONFIGURANDO A PROPRIEDADE DE BLOQUEIO DE FECHAMENTO

CAPÍTULO 23. CONFIGURAÇÃO DE UMA ESTRATÉGIA DE POSICIONAMENTO DO NÓ 23.1. ATRIBUTOS DE UTILIZAÇÃO E ESTRATÉGIA DE COLOCAÇÃO

23.1.1. Configuração do nó e da capacidade de recursos 23.1.2. Configuração da estratégia de colocação 23.2. ALOCAÇÃO DE RECURSOS DO MARCAPASSO

23.2.1. Preferência de Nó 168 169 169 171 172 172 172 173 174 174 174 174 176 176 176 176 177 177 178 179 179 181 181 181 183 184 185 185 186 186 187 188 188 193 194 195 195 196 198 198 198 199 199 199

(9)

. . . . . . . . . . . . . . . . . . . . . . . . 23.2.2. Capacidade do Nó

23.2.3. Preferência de Alocação de Recursos

23.3. DIRETRIZES DE ESTRATÉGIA DE COLOCAÇÃO DE RECURSOS 23.4. O AGENTE DE RECURSOS NODEUTILIZATION

CAPÍTULO 24. CONFIGURAÇÃO DE UM DOMÍNIO VIRTUAL COMO UM RECURSO 24.1. OPÇÕES DE RECURSOS DE DOMÍNIO VIRTUAL

24.2. CRIANDO O RECURSO DE DOMÍNIO VIRTUAL CAPÍTULO 25. QUÓRUM DE CLUSTER

25.1. CONFIGURAÇÃO DAS OPÇÕES DO QUORUM 25.2. MODIFICAÇÃO DAS OPÇÕES DO QUORUM

25.3. EXIBIÇÃO DA CONFIGURAÇÃO E STATUS DO QUORUM 25.4. EXECUÇÃO DE CLUSTERS DE INQUÉRITOS

25.5. DISPOSITIVOS DO QUORUM

25.5.1. Instalação de pacotes de dispositivos de quorum 25.5.2. Configuração de um dispositivo de quorum 25.5.3. Gerenciando o Serviço de Dispositivos Quorum

25.5.4. Gerenciamento das configurações do dispositivo de quorum em um cluster 25.5.4.1. Mudança das configurações do dispositivo de quorum

25.5.4.2. Remoção de um dispositivo de quorum 25.5.4.3. Destruindo um dispositivo de quorum

CAPÍTULO 26. ACIONAMENTO DE SCRIPTS PARA EVENTOS DE CLUSTER 26.1. INSTALAÇÃO E CONFIGURAÇÃO DE AMOSTRAS DE AGENTES DE ALERTA 26.2. CRIANDO UM ALERTA DE AGRUPAMENTO

26.3. EXIBIÇÃO, MODIFICAÇÃO E REMOÇÃO DE ALERTAS DE AGRUPAMENTO 26.4. CONFIGURAÇÃO DOS DESTINATÁRIOS DE ALERTA

26.5. META OPÇÕES DE ALERTA

26.6. EXEMPLOS DE COMANDOS DE CONFIGURAÇÃO DE ALERTAS 26.7. ESCREVER UM AGENTE DE ALERTA

CAPÍTULO 27. CONFIGURAÇÃO DE CLUSTERS DE MÚLTIPLOS LOCAIS COM PACEMAKER 27.1. VISÃO GERAL DO GERENTE DE BILHETERIA DE ESTANDES

27.2. CONFIGURAÇÃO DE CLUSTERS DE MÚLTIPLOS LOCAIS COM PACEMAKER CAPÍTULO 28. INTEGRAÇÃO DE NÓS NÃO-COROASYNC EM UM CLUSTER: O SERVIÇO PACEMAKER_REMOTE

28.1. AUTENTICAÇÃO DO HOSPEDEIRO E DO CONVIDADO DOS NÓS DE PACEMAKER_REMOTE 28.2. CONFIGURAÇÃO DOS NÓS CONVIDADOS DA KVM

28.2.1. Opções de recursos de nós de hóspedes

28.2.2. Integrando uma máquina virtual como um nó convidado 28.3. CONFIGURAÇÃO DOS NÓS REMOTOS DO PACEMAKER

28.3.1. Opções de recursos de nós remotos 28.3.2. Visão geral da configuração do nó remoto 28.4. MUDANDO A LOCALIZAÇÃO PADRÃO DA PORTA

28.5. ATUALIZAÇÃO DE SISTEMAS COM NÓS DE PACEMAKER_REMOTE CAPÍTULO 29. EXECUÇÃO DE MANUTENÇÃO DE CLUSTERS

29.1. COLOCANDO UM NÓ EM MODO DE ESPERA

29.2. MOVIMENTAÇÃO MANUAL DOS RECURSOS DO CLUSTER 29.2.1. Movendo um recurso de seu nó atual

29.2.2. Movendo um recurso para seu nó de preferência

29.3. DESATIVAÇÃO, HABILITAÇÃO E PROIBIÇÃO DE RECURSOS DE CLUSTER Desabilitando um recurso de cluster

200 200 200 201 202 202 238 240 240 241 242 242 243 243 243 248 248 248 248 249 250 250 251 252 252 253 253 255 258 258 258 262 263 263 263 264 265 265 273 274 275 276 276 277 277 278 279 279

(10)

. . . . Permitindo um recurso de cluster

Impedir que um recurso funcione em um determinado nó Forçando um recurso a começar no nó atual

29.4. COLOCANDO UM RECURSO EM MODO NÃO GERENCIADO 29.5. COLOCANDO UM CLUSTER EM MODO DE MANUTENÇÃO

29.6. ATUALIZAÇÃO DE UM CLUSTER DE ALTA DISPONIBILIDADE RHEL 29.7. ATUALIZAÇÃO DE NÓS REMOTOS E NÓS DE CONVIDADOS 29.8. MIGRAÇÃO DE VMS EM UM CLUSTER RHEL

CAPÍTULO 30. CONFIGURAÇÃO DE CLUSTERS DE RECUPERAÇÃO DE DESASTRES 30.1. CONSIDERAÇÕES SOBRE CLUSTERS DE RECUPERAÇÃO DE DESASTRES

30.2. EXIBIÇÃO DO STATUS DOS CLUSTERS DE RECUPERAÇÃO (RHEL 8.2 E POSTERIORES)

279 279 280 280 280 281 281 282 284 284 284

(11)
(12)

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.

(13)

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.

(14)

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)

(15)

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.

(16)

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.

(17)

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.

(18)

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

(19)

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.

(20)

# 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

# firewall-cmd --reload

(21)

# 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

Current DC: z1.example.com (version 2.0.0-10.el8-b67d8d0de9) - partition with quorum 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

2 resources configured Online: [ z1.example.com ]

(22)

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:

z1.example.com: Online ...

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

Cluster name: my_cluster ...

Current DC: z1.example.com (version 1.1.13-10.el7-44eb2dd) - partition with quorum 1 node and 2 resources configured

Online: [ z1.example.com ] Full list of resources:

Resource Group: apachegroup

ClusterIP (ocf::heartbeat:IPaddr2): Started z1.example.com WebSite (ocf::heartbeat:apache): Started z1.example.com 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:

(23)

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.

# yum install pcs pacemaker fence-agents-all

...

# systemctl start pcsd.service

# systemctl enable pcsd.service

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.

# firewall-cmd --permanent --add-service=high-availability

# firewall-cmd --reload

(24)

# 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

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 2 nodes configured

0 resources configured

(25)

PCSD Status:

z1.example.com: Online z2.example.com: Online

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.

# yum install -y httpd wget

...

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

# firewall-cmd --reload

# 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, 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 <Location /server-status>

SetHandler server-status 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ó.

(26)

# 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

Current DC: z1.example.com (version 2.0.0-10.el8-b67d8d0de9) - partition with quorum 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 2 nodes configured

2 resources configured

Online: [ z1.example.com z2.example.com ] 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:

z1.example.com: Online z2.example.com: Online ...

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

Cluster name: my_cluster Stack: corosync

Current DC: z1.example.com (version 2.0.0-10.el8-b67d8d0de9) - partition with quorum 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 2 nodes configured

(27)

2 resources configured

Online: [ z1.example.com z2.example.com ] Full list of resources:

Resource Group: apachegroup

ClusterIP (ocf::heartbeat:IPaddr2): Started z1.example.com WebSite (ocf::heartbeat:apache): Started z1.example.com 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

Cluster name: my_cluster Stack: corosync

Current DC: z1.example.com (version 2.0.0-10.el8-b67d8d0de9) - partition with quorum 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 2 nodes configured

2 resources configured

Node z1.example.com: standby Online: [ z2.example.com ] Full list of resources:

Resource Group: apachegroup

ClusterIP (ocf::heartbeat:IPaddr2): Started z2.example.com WebSite (ocf::heartbeat:apache): Started z2.example.com

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ó.

(28)

11. Para a limpeza final, pare os serviços de agrupamento em ambos os nós. # pcs cluster stop --all

(29)

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.

(30)

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

(31)

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

(32)

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.

# yum install pcs pacemaker fence-agents-all

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.

(33)

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 --permanent --add-service=high-availability

# 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.

# systemctl start pcsd.service

# systemctl enable pcsd.service

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.

(34)

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 z2.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ó.

(35)

[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

Current DC: z2.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 z2.example.com 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-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.

(36)

# 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)

Referências

Documentos relacionados

Buscando responder esta questão, alargando os horizontes da educação em controle e integrando o processo de projeto de controladores, em um equilíbrio entre os

Resumindo, este artigo propõe a implementação de um algoritmo híbrido combinando uma técnica de otimização por nuvem de partículas (fase de evolução ou fase de

No Piauí de cada 100 crianças que nascem 78 morrem antes de completar 8 anos de idade No Piauí. de cada 100 crianças

A ênfase atual ao estudo da Síndrome da respiração oral deve-se ao fato deste problema causar alterações em vários órgãos e sistemas estando ligada não só à capacidade vital

Neste aspecto nomes como Martins de Aguiar (Fonética do Português do Ceará In: Repasse Crítico da Gramática Portuguesa); Antônio Sales ( O falar Cearense) e Florival

Corporate Control and Policies Page 12 UNIVERSIDAD DE PIURA UNIVERSIDAD DEL PACÍFICO UNIVERSIDAD ESAN UNIVERSIDAD NACIONAL AGRARIA LA MOLINA UNIVERSIDAD NACIONAL

Conclui-se dos resultados empíricos do estudo que a adoção da Interpretação Técnica ICPC 01 gera efeitos relevantes nas demonstrações contábeis das empresas concessionárias

Assim, este trabalho tem como objetivo desenvolver um modelo de dispersão de poluentes na atmosfera para regiões de relevo complexo, com base em um campo de ventos obtido através de