O Add-On de Alta Disponibilidade consiste nos seguintes componentes principais:

Você pode complementar o Add-On de Alta Disponibilidade com os seguintes componentes:

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.

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.

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.

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.

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:

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.

O Red Hat High Availability Add-On oferece suporte para volumes LVM em duas configurações de cluster distintas:

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.

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.

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.

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

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

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.

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

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.

pcs status de cluster

Use o seguinte comando para exibir a configuração atual completa do cluster.

pcs config

O seguinte procedimento instala o software de cluster e configura seu sistema para a criação de clusters.

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.

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.

Este procedimento cria um cluster de Red Hat High Availability Add-On que consiste nos nós z1.example.com e z2.example.com.

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

...

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.

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.

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

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.

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

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

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]

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.

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

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.

Este caso de uso requer a criação de um volume lógico LVM no armazenamento que é compartilhado entre os nós do 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.

O seguinte procedimento configura um Servidor HTTP Apache.

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.

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.

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.

Este caso de uso requer que seu sistema inclua os seguintes componentes:

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:

Este caso de uso requer a criação de um volume lógico LVM no armazenamento que é compartilhado entre os nós do 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.

O procedimento a seguir configura o compartilhamento do NFS para o failover do serviço NFS.

Esta seção fornece o procedimento para configurar os recursos do cluster para este caso de uso.

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.

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.

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.

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.

Após realizar este procedimento, você pode criar um recurso LVM-activate para cada volume lógico.

O seguinte procedimento instala o software de cluster e configura seu sistema para a criação de clusters.

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.

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.

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.

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:

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.

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

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.

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.

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:

Tabela 9.1, “Propriedades Gerais dos Dispositivos de Esgrima” descreve as propriedades gerais que você pode definir para dispositivos de esgrima.

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.

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

Para informações sobre a definição das propriedades de agrupamento, consulte Definição e remoção das propriedades de agrupamento.

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.

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.

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

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 `apc2, e os nós `node4, node5, e `node6 para usar dispositivos de cerca apc3 e `apc4.

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 node attribute node2 rack=1
pcs node attribute node3 rack=1
pcs node attribute node4 rack=2
pcs node attribute node5 rack=2
pcs node attribute node6 rack=2
pcs stonith level add 1 attrib%rack=1 apc1,apc2
pcs stonith level add 1 attrib%rack=2 apc3,apc4

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.

# 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

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

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

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.

pcs stonith confirmam node

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

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

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.

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:

`Soft-Off by PWR-BTTN` set to
`Instant-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       |                   |
|                                             |                   |
|                                             |                   |
+---------------------------------------------|-------------------+

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.2, “Comandos para exibir as propriedades dos recursos” resume os comandos que exibem as propriedades dos recursos disponíveis.

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.

...

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.

# pcs resource defaults update resource-stickiness=100

# pcs resource defaults set create id=pgsql-stickiness meta resource-stickiness=100 rule resource ::pgsql

# pcs resource defaults
Meta Attrs: rsc_defaults-meta_attributes
  resource-stickiness=100

# pcs resource defaults
Meta Attrs: pgsql-stickiness
  resource-stickiness=100
  Rule: boolean-op=and score=INFINITY
    Expression: resource ::pgsql

pcs resource create resource_id [standard:[provider:]]type [resource options] [meta meta_options...]

# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.120 meta resource-stickiness=50

pcs resource meta resource_id | group_id | clone_id meta_options

# pcs resource meta dummy_resource failure-timeout=20s

# pcs resource config dummy_resource
 Resource: dummy_resource (class=ocf provider=heartbeat type=Dummy)
  Meta Attrs: failure-timeout=20s
  ...

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 grupos de recursos.

pcs resource group acrescentar group_name resource_id [resource_id] ... [resource_id] [- antes resource_id | - depois resource_id]

pcs resource create resource_id [standard:[provider:]]type [resource_options] [op operation_action operation_options ] --group group_name

# pcs resource group add shortcut IPaddr Email

pcs resource group remove group_name resource_id ...

lista de grupos de recursos pcs

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:

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.

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.

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

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.

Ao utilizar restrições de localização, você pode configurar uma estratégia geral para especificar em quais nós um recurso pode funcionar:

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.

# pcs property set symmetric-cluster=false

# pcs constraint location Webserver prefers example-1=200
# pcs constraint location Webserver prefers example-3=0
# pcs constraint location Database prefers example-2=200
# pcs constraint location Database prefers example-3=0

# pcs property set symmetric-cluster=true

# pcs constraint location Webserver prefers example-1=200
# pcs constraint location Webserver avoids example-2=INFINITY
# pcs constraint location Database avoids example-1=INFINITY
# pcs constraint location Database prefers example-2=200

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

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.

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

Uma situação comum é que um administrador crie uma cadeia de recursos ordenados, onde, por 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:

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.

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.

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

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

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:

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

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.

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.

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:

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.

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.

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

Use o seguinte comando para remover as restrições de colocação com source_resource.

pcs constraint colocation remover source_resource target_resource

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.

O comando a seguir lista todas as restrições de localização atuais.

pcs constraint location [mostrar [recursos [resource...]] | [nós [node...]] [--cheio]

O seguinte comando lista todas as restrições de pedidos atuais.

pcs ordem de restrição [mostrar]

O seguinte comando lista todas as restrições de colocação atuais.

pcs constraint colocation [mostrar]

O seguinte comando lista as restrições que fazem referência a recursos específicos.

pcs constraint ref resource...

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
   |  start D then start E
   `- E
# pcs resource relations E
E
`- order
   |  start D then start E
   `- 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
`- outer resource
   `- G
      `- inner resource(s)
         |  members: A B
         `- A
# pcs resource relations G
G
`- inner resource(s)
   |  members: A B
   |- A
   `- B

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.

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

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

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
 Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat)
  Attributes: ip=192.168.0.120 cidr_netmask=24
  Operations: monitor interval=30s

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.

# pcs resource config VirtualIP
 Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat)
  Attributes: ip=192.168.0.120 cidr_netmask=24
  Operations: monitor interval=30s
# pcs resource update VirtualIP ip=192.169.0.120
# pcs resource config VirtualIP
 Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat)
  Attributes: ip=192.169.0.120 cidr_netmask=24
  Operations: monitor interval=30s

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

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 falhas, e você pode configurar um cluster para mover recursos quando a conectividade externa for perdida.

# pcs resource meta dummy_resource migration-threshold=10

# pcs resource defaults migration-threshold=10

# pcs resource create ping ocf:pacemaker:ping dampen=5s multiplier=1000 host_list=gateway.example.com clone

# 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

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" à 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

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.

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.

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

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.

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.

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

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.

pcs resource create resource_id [standard:[provider:]]type [resource options] promocional [clone options]

recursos pcs promocionais resource_id [clone options]

pcs constraint colocation add [master|slave] source_resource com [master|slave] target_resource [score] [options]

pedido de restrição pcs [action] resource_id e depois [action] resource_id [options]

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.

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.

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

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.

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.

pcs cluster disable [--all | node] [...] [..

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.

Em um nó do agrupamento existente, executar as seguintes tarefas.

No novo nó a ser adicionado ao agrupamento, execute as seguintes tarefas.

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

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

Na maioria dos casos, você pode adicionar ou modificar os links em um cluster existente sem reiniciar o cluster.

[root@node1 ~] # pcs cluster link add node1=10.0.5.11 node2=10.0.5.12 node3=10.0.5.31 options linknumber=5

[root@node1 ~] # pcs cluster link delete 5

[root@node1 ~] # pcs cluster link remove 5

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.

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.

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:

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.

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

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.

# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.99 cidr_netmask=24 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
  Operations: start interval=0s timeout=20s (VirtualIP-start-timeout-20s)
              monitor interval=10s timeout=20s (VirtualIP-monitor-interval-10s)
              stop interval=0s timeout=40s (VirtualIP-name-stop-interval-0s-timeout-40s)

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.

# pcs resource update VirtualIP op monitor interval=10s

# pcs resource show VirtualIP
 Resource: VirtualIP (class=ocf provider=heartbeat type=IPaddr2)
   Attributes: ip=192.168.0.99 cidr_netmask=24 nic=eth2
   Operations: start interval=0s timeout=20s (VirtualIP-start-timeout-20s)
               monitor interval=10s (VirtualIP-monitor-interval-10s)
               stop interval=0s timeout=40s (VirtualIP-name-stop-interval-0s-timeout-40s)

# pcs resource op defaults set create id=podman-timeout meta timeout=90s rule resource ::podman

# pcs resource op defaults set create id=stop-timeout meta timeout=120s rule op stop

# pcs resource op defaults set create id=podman-stop-timeout meta timeout=120s rule resource ::podman and op stop

# pcs resource op defaults
Meta Attrs: podman-timeout
  timeout=90s
  Rule: boolean-op=and score=INFINITY
    Expression: resource ::podman

# pcs resource op defaults
Meta Attrs: podman-stop-timeout
  timeout=120s
  Rule: boolean-op=and score=INFINITY
    Expression: resource ::podman
    Expression: op stop

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.

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.

# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.99 cidr_netmask=24 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

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.

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.

# pcs property set symmetic-cluster=

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

A capacidade de evitar que os recursos falhem em um desligamento de nó limpo é implementada por meio das seguintes propriedades de agrupamento.

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.

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.

# pcs node utilization node1 cpu=2 memory=2048
# pcs node utilization node2 cpu=4 memory=2048

# 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

# pcs property set placement-strategy=balanced

As subseções a seguir resumem como a Pacemaker aloca os 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.

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.

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.

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.

Use o seguinte procedimento para criar um recurso VirtualDomain em um cluster para uma máquina virtual que você tenha criado anteriormente:

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.

Para maiores informações sobre a configuração e utilização destas opções, consulte a página de manual votequorum(5).

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

[root@node1:~]# pcs quorum config
Options:
  wait_for_all: 1

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

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.

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.

# pcs quorum unblock

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.

[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

[root@node1:~]# pcs quorum device update model algorithm=lms
Sending updated corosync.conf to nodes...
node1: Succeeded
node2: Succeeded
Corosync configuration reloaded
Reloading qdevice configuration on nodes...
node1: corosync-qdevice stopped
node2: corosync-qdevice stopped
node1: corosync-qdevice started
node2: corosync-qdevice started

[root@node1:~]# pcs quorum device remove
Sending updated corosync.conf to nodes...
node1: Succeeded
node2: Succeeded
Corosync configuration reloaded
Disabling corosync-qdevice...
node1: corosync-qdevice disabled
node2: corosync-qdevice disabled
Stopping corosync-qdevice...
node1: corosync-qdevice stopped
node2: corosync-qdevice stopped
Removing qdevice certificates from nodes...
node1: Succeeded
node2: Succeeded

[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

[root@qdevice:~]# pcs qdevice destroy net
Stopping quorum device...
quorum device stopped
quorum device disabled
Quorum device 'net' configuration files removed

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

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)

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

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.

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.

#  pcs alert recipient add my-alert value=my-alert-recipient id=my-recipient-id options value=some-address

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.

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"

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.

# 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:
 Alert: alert (path=/my/path)
  Recipients:
   Recipient: alert-recipient (value=rec_value)
   Recipient: my-recipient (value=rec_value2)
 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:
 Alert: alert (path=/my/path)
  Recipients:
   Recipient: alert-recipient (value=rec_value)
   Recipient: my-recipient (value=rec_value2)
 Alert: my-alert (path=/path/to/script)
  Description: alert_description
  Options: opt=val option1=newvalue1
  Meta options: timestamp-format=%H%M%S timeout=50s
  Recipients:
   Recipient: my-alert-recipient (value=my-other-recipient)
    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:
 Alert: alert (path=/my/path)
  Recipients:
   Recipient: alert-recipient (value=rec_value)
 Alert: my-alert (path=/path/to/script)
  Description: alert_description
  Options: opt=val option1=newvalue1
  Meta options: timestamp-format="%M%B%S" timeout=50s
  Recipients:
   Recipient: my-alert-recipient (value=my-other-recipient)
    Options: option1=new
    Meta options: timeout=60s

O seguinte comando remove myalert da configuração.

# pcs alert remove myalert
# pcs alert
Alerts:
 Alert: alert (path=/my/path)
  Recipients:
   Recipient: alert-recipient (value=rec_value)

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.

Ao escrever um agente de alerta, você deve levar em conta as seguintes preocupações.

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.

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:

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.

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

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.