CRIAÇÃO DE RECURSOS DE CLUSTER QUE ESTÃO ATIVOS EM MÚLTIPLOS NÓS (RECURSOS

CLONADOS)

Você pode clonar um recurso de cluster para que o recurso possa estar ativo em vários nós. Por

exemplo, você pode utilizar recursos clonados para configurar múltiplas instâncias de um recurso IP para distribuir em todo um cluster para balanceamento de nós. Você pode clonar qualquer recurso, desde que o agente de recursos o suporte. Um clone consiste em um recurso ou um grupo de recursos.

NOTA

Somente os recursos que podem estar ativos em vários nós ao mesmo tempo são adequados para clonagem. Por exemplo, um recurso Filesystem que monta um sistema de arquivo não exclusivo como ext4 a partir de um dispositivo de memória compartilhada não deve ser clonado. Como a partição ext4 não está ciente do cluster, este sistema de arquivo não é adequado para operações de leitura/gravação que ocorrem a partir de múltiplos nós ao mesmo tempo.

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

Você pode criar um recurso e um clone desse recurso ao mesmo tempo com o seguinte comando. pcs resource create resource_id [standard:[provider:]]type [resource options] [meta resource meta options] clone [clone options]

O nome do clone será resource_id-clone.

Não se pode criar um grupo de recursos e um clone desse grupo de recursos em um único comando. Alternativamente, você pode criar um clone de um recurso ou grupo de recursos previamente criado com o seguinte comando.

pcs resource clone resource_id | group_name [clone options]... O nome do clone será resource_id-clone ou group_name-clone.

NOTA

Você precisa configurar as mudanças de configuração de recursos em apenas um nó.

NOTA

Ao configurar as restrições, use sempre o nome do grupo ou clone.

Quando você cria um clone de um recurso, o clone assume o nome do recurso com -clone anexado ao nome. Os seguintes comandos criam um recurso do tipo apache chamado webfarm e um clone desse recurso chamado webfarm-clone.

NOTA

Quando você cria um recurso ou clone de grupo de recursos que será encomendado após outro clone, você deve quase sempre definir a opção interleave=true. Isto garante que as cópias do clone dependente possam parar ou começar quando o clone do qual depende tiver parado ou começado no mesmo nó. Se você não definir esta opção, se um recurso clonado B depender de um recurso clonado A e um nó sair do cluster, quando o nó retornar ao cluster e o recurso A começar naquele nó, então todas as cópias do recurso B em todos os nós serão reiniciadas. Isto porque quando um recurso clonado dependente não tem a opção interleave definida, todas as instâncias desse recurso dependem de qualquer instância em execução do recurso do qual ele depende.

Use o seguinte comando para remover um clone de um recurso ou de um grupo de recursos. Isto não remove o recurso ou o próprio grupo de recursos.

pcs resource unclone resource_id | group_name

Tabela 17.1, “Opções de Clonagem de Recursos” descreve as opções que você pode especificar para um recurso clonado.

Tabela 17.1. Opções de Clonagem de Recursos

Campo Descrição

priority, target-role, is-managed Opções herdadas do recurso que está sendo clonado, conforme descrito em Tabela 10.3, “Meta Opções de Recursos”.

clone-max Quantas cópias do recurso para começar. O número de nós no agrupamento é o padrão.

clone-node-max Quantas cópias do recurso podem ser iniciadas em um único nó; o valor padrão é 1.

notify Ao parar ou iniciar uma cópia do clone, informe todas as outras cópias com antecedência e quando a ação foi bem sucedida. Valores permitidos: false, true. O valor padrão é false.

globally-unique Cada cópia do clone desempenha uma função diferente? Valores permitidos: false, true Se o valor desta opção é false, estes recursos se comportam de forma idêntica em todos os lugares onde estão funcionando e, portanto, pode haver apenas uma cópia do clone ativo por máquina. Se o valor desta opção for true, uma cópia do clone rodando em uma máquina não é equivalente a outra instância, quer essa instância esteja rodando em outro nó ou no mesmo nó. O valor padrão é true se o valor de clone-node-max for maior que um; caso contrário, o valor padrão é false.

ordered Caso as cópias sejam iniciadas em série (ao invés de em paralelo). Valores permitidos: false, true. O valor padrão é false.

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

forem pedidos após este clone não poderão começar até que o número especificado de instâncias do clone original esteja em execução, mesmo que a opção interleave esteja definida para true.

Campo Descrição

Para alcançar um padrão de alocação estável, os clones são ligeiramente pegajosos por padrão, o que indica que eles têm uma ligeira preferência por permanecer no nó em que estão correndo. Se não for fornecido um valor para resource-stickiness, o clone usará um valor de 1. Sendo um valor pequeno, ele causa uma perturbação mínima nos cálculos de pontuação de outros recursos, mas é suficiente para evitar que o Pacemaker movimente desnecessariamente cópias em torno do agrupamento. Para informações sobre a configuração da meta-opção de recursos resource-stickiness, consulte

Configurando as meta-opções de recursos.

17.2. CONFIGURAÇÃO DE RESTRIÇÕES DE RECURSOS CLONAIS

Na maioria dos casos, um clone terá uma única cópia em cada nó ativo de cluster. Você pode, no entanto, definir clone-max para o recurso clone para um valor menor do que o número total de nós no cluster. Se este for o caso, você pode indicar a quais nós o cluster deve, preferencialmente, atribuir cópias com restrições de localização de recursos. Estas restrições não são escritas de maneira diferente daquelas para recursos regulares, exceto que a identificação do clone deve ser usada.

O seguinte comando cria uma restrição de localização para que o cluster atribua preferencialmente o clone de recursos webfarm-clone para node1.

# pcs constraint location webfarm-clone prefers node1

As restrições de pedidos comportam-se de forma ligeiramente diferente para os clones. No exemplo abaixo, porque a opção de clonagem interleave é deixada por padrão como false, nenhuma instância de

webfarm-stats começará até que todas as instâncias de webfarm-clone que precisam ser iniciadas o

tenham feito. Somente se nenhuma cópia de webfarm-clone puder ser iniciada, então webfarm-stats será impedida de ser ativada. Além disso, webfarm-clone aguardará que webfarm-stats seja

interrompido antes de parar por si mesmo.

# pcs constraint order start webfarm-clone then webfarm-stats

A colocação de um recurso regular (ou de grupo) com um clone significa que o recurso pode funcionar em qualquer máquina com uma cópia ativa do clone. O grupo escolherá uma cópia com base no local onde o clone está rodando e nas preferências de localização do próprio recurso.

A recolocação entre clones também é possível. Nesses casos, o conjunto de locais permitidos para o clone é limitado aos nós nos quais o clone está (ou estará) ativo. A alocação é então realizada como normalmente.

O seguinte comando cria uma restrição de colocação para garantir que o recurso webfarm-stats funcione no mesmo nó que uma cópia ativa de webfarm-clone.

# pcs constraint colocation add webfarm-stats with webfarm-clone

17.3. CRIAÇÃO DE RECURSOS DE CLONAGEM PROMOCIONAIS

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

17.3.1. Criando um recurso promocional

Você pode criar um recurso como um clone promocional com o seguinte comando único.

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

O nome do clone promocional será resource_id-clone.

Alternativamente, você pode criar um recurso promocional a partir de um recurso ou grupo de recursos previamente criado com o seguinte comando. O nome do clone promocional será resource_id-clone ou

group_name-clone.

recursos pcs promocionais resource_id [clone options]

Tabela 17.2, “Opções extras de clones disponíveis para clones promocionais” descreve as opções de clonagem extra que você pode especificar para um recurso promocional.

Tabela 17.2. Opções extras de clones disponíveis para clones promocionais

Campo Descrição

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

promoted-node-max Quantas cópias do recurso podem ser promovidas em um único nó; padrão 1.

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

Na maioria dos casos, um recurso promocional terá uma única cópia em cada nó ativo de cluster. Se este não for o caso, você pode indicar a quais nós o agrupamento deve, preferencialmente, atribuir

cópias com restrições de localização de recursos. Estas restrições não são escritas de maneira diferente daquelas para os recursos regulares.

Você pode criar uma restrição de colocação que especifica se os recursos estão operando em um papel de mestre ou de escravo. O seguinte comando cria uma restrição de colocação de recursos.

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

Para informações sobre restrições de colocação, consulte Colocando recursos de agrupamento. Ao configurar uma restrição de pedido que inclui recursos promocionais, uma das ações que você pode especificar para os recursos é promote, indicando que o recurso seja promovido do papel de escravo para o papel de mestre. Além disso, você pode especificar uma ação de demote, indicando que o recurso deve ser rebaixado do papel de mestre para o papel de escravo.

O comando para configurar uma restrição de ordem é o seguinte.

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

Para informações sobre restrições de pedidos de recursos, ver ifdef:: Determinar a ordem em que os recursos de agrupamento são executados.

17.4. DEMONSTRANDO UM RECURSO PROMOVIDO SOBRE O

FRACASSO (RHEL 8.3 E POSTERIORES)

Você pode configurar um recurso promocional para que quando uma ação promote ou monitor falhar para esse recurso, ou a partição na qual o recurso está rodando perder quorum, o recurso será rebaixado mas não será totalmente interrompido. Isto pode evitar a necessidade de intervenção manual em

situações em que a parada total do recurso o exigiria.

Para configurar um recurso promocional a ser rebaixado quando uma ação promote falhar, defina a meta-opção da operação on-fail para demote, como no exemplo a seguir.

# pcs resource op add my-rsc promote on-fail="demote"

Para configurar um recurso promocional a ser rebaixado quando uma ação monitor falhar, defina interval para um valor não zero, defina a meta-opção de operação on-fail para demote, e defina role para Master, como no exemplo a seguir.

# pcs resource op add my-rsc monitor interval="10s" on-fail="demote" role="Master"

Para configurar um cluster para que, quando uma partição de cluster perder quorum, quaisquer recursos promovidos sejam despromovidos mas deixados em funcionamento e todos os outros recursos sejam interrompidos, defina a propriedade do cluster no-quorum-policy para demote Especificar um meta-atributo demote para uma operação não afeta como a promoção de um recurso é determinada. Se o nó afetado ainda tiver a maior pontuação de promoção, ele será selecionado para ser promovido novamente.