DETERMINAÇÃO DA ORDEM NA QUAL OS RECURSOS DE AGRUPAMENTO SÃO EXECUTADOS

Para determinar a ordem na qual os recursos funcionam, você configura uma restrição de pedidos. O seguinte mostra o formato do comando para configurar uma restrição de ordenação.

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

Tabela 12.1, “Propriedades de uma restrição de ordem”, resume as propriedades e opções para configurar as restrições de pedidos.

Tabela 12.1. Propriedades de uma restrição de ordem

Campo Descrição

resource_id O nome de um recurso sobre o qual uma ação é executada. ação A ação a ser realizada sobre um recurso. Os valores possíveis da

propriedade action são os seguintes: * start - Iniciar o recurso.

* stop - Pare o recurso.

* promote - Promover o recurso de um recurso escravo para um recurso mestre.

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

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

kind são os seguintes:

* Optional - Somente se aplica se ambos os recursos estiverem executando a ação especificada. Para informações sobre pedidos opcionais, consulte Configuração de pedidos consultivos.

* Mandatory - Sempre (valor padrão). Se o primeiro recurso que você especificou estiver parando ou não puder ser iniciado, o segundo recurso que você especificou deve ser parado. Para informações sobre pedidos obrigatórios, consulte Configuração de pedidos obrigatórios.

* Serialize - Assegure-se de que não ocorram duas ações de parada/arranque concomitantes para os recursos especificados. O primeiro e o segundo recurso que você especificar podem ser iniciados em qualquer ordem, mas um deve ser concluído antes que o outro possa ser iniciado. Um caso típico de uso é quando a partida dos recursos coloca uma carga alta no host.

symmetrical opção Se for verdade, o contrário da restrição se aplica à ação oposta (por exemplo, se B começa após A começa, então B pára antes de Ordenar restrições para as quais kind é Serialize não pode ser simétrico. O valor padrão é true para os tipos Mandatory e Ordering, false para Serialize.

Campo Descrição

Use o seguinte comando para remover recursos de qualquer restrição de pedidos. ordem de restrição de pcs remover resource1 [resourceN]...

12.1. CONFIGURAÇÃO DE PEDIDOS OBRIGATÓRIOS

Uma restrição de pedido obrigatória indica que a segunda ação não deve ser iniciada para o segundo recurso a menos que e até que a primeira ação seja concluída com sucesso para o primeiro recurso. As ações que podem ser encomendadas são stop, start, e, adicionalmente, para clones promocionais,

demote e promote. Por exemplo, "A e depois B" (que é equivalente a "iniciar A e depois iniciar B")

significa que B não será iniciado a menos que e até que A comece com sucesso. Uma restrição de pedido é obrigatória se a opção kind para a restrição for definida para Mandatory ou deixada como padrão.

Se a opção symmetrical for definida para true ou deixada para o padrão, as ações opostas serão ordenadas em reverso. As ações start e stop são opostas, e demote e promote são opostas. Por exemplo, uma ordem simétrica de "promover A e depois iniciar B" implica em "parar B e depois rebaixar A", o que significa que A não pode ser rebaixado até e a menos que B pare com sucesso. Uma

ordenação simétrica significa que mudanças no estado de A podem fazer com que ações sejam

programadas para B. Por exemplo, dado "A então B", se A reinicia devido a falha, B será parado primeiro, depois A será parado, depois A será iniciado, depois B será iniciado.

Observe que o agrupamento reage a cada mudança de estado. Se o primeiro recurso for reiniciado e estiver num estado inicial novamente antes do segundo recurso iniciar uma operação de parada, o segundo recurso não precisará ser reiniciado.

12.2. CONFIGURAÇÃO DE PEDIDOS DE CONSULTORIA

Quando a opção kind=Optional é especificada para uma restrição de pedido, a restrição é considerada opcional e só se aplica se ambos os recursos estiverem executando as ações especificadas. Qualquer mudança no estado pelo primeiro recurso especificado não terá efeito sobre o segundo recurso especificado.

O seguinte comando configura uma restrição de ordenação consultiva para os recursos denominados

VirtualIP e dummy_resource.

# pcs constraint order VirtualIP then dummy_resource kind=Optional

12.3. CONFIGURAÇÃO DE CONJUNTOS DE RECURSOS

ENCOMENDADOS

exemplo, o recurso A começa antes do recurso B que começa antes do recurso C. Se sua configuração exigir que você crie um conjunto de recursos que seja colocado e iniciado em ordem, você pode configurar um grupo de recursos que contenha esses recursos, conforme descrito em Configuração de grupos de recursos.

Há algumas situações, entretanto, onde a configuração dos recursos que precisam começar em uma ordem específica como um grupo de recursos não é apropriada:

Talvez seja necessário configurar os recursos para começar em ordem e os recursos não são necessariamente colocados.

Você pode ter um recurso C que deve começar depois que o recurso A ou B tiver começado, mas não há nenhuma relação entre A e B.

Você pode ter recursos C e D que devem começar depois que ambos os recursos A e B tiverem começado, mas não há relação entre A e B ou entre C e D.

Nestas situações, você pode criar uma restrição de pedidos em um conjunto ou conjuntos de recursos com o comando pcs constraint order set.

Você pode definir as seguintes opções para um conjunto de recursos com o comando pcs constraint

order set.

sequential, que pode ser ajustado para true ou false para indicar se o conjunto de recursos

deve ser ordenado em relação um ao outro. O valor padrão é true.

A configuração sequential para false permite que um conjunto seja ordenado em relação a outros conjuntos na restrição de ordenação, sem que seus membros sejam ordenados em relação uns aos outros. Portanto, esta opção só faz sentido se vários conjuntos estiverem listados na restrição; caso contrário, a restrição não tem efeito.

require-all, que pode ser ajustado para true ou false para indicar se todos os recursos do

conjunto devem estar ativos antes de continuar. Definir require-all para false significa que apenas um recurso do conjunto precisa ser iniciado antes de continuar para o próximo conjunto. A configuração require-all a false não tem efeito, a menos que seja usada em conjunto com conjuntos não ordenados, que são conjuntos para os quais sequential está configurado para

false. O valor padrão é true.

action, que pode ser ajustado para start, promote, demote ou stop, conforme descrito em Propriedades de uma Restrição de Ordem.

role, que pode ser ajustado para Stopped, Started, Master, ou Slave.

Você pode definir as seguintes opções de restrição para um conjunto de recursos seguindo o parâmetro

setoptions do comando pcs constraint order set.

id, para fornecer um nome para a restrição que você está definindo.

kind, que indica como aplicar a restrição, conforme descrito em Propriedades de uma Restrição de Ordem.

symmetrical, para definir se o inverso da restrição se aplica à ação oposta, conforme descrito

em Propriedades de uma Restrição de Ordem.

pcs constraint order set resource1 resource2 [resourceN]... [options] [set resourceX resourceY ... [options]]] [set [setoptions [constraint_options]]]

Se você tiver três recursos chamados D1, D2, e D3, o seguinte comando os configura como um conjunto de recursos ordenados.

# pcs constraint order set D1 D2 D3

Se você tiver seis recursos denominados A, B, C, D, E, e F, este exemplo configura uma restrição de pedido para o conjunto de recursos que começará como a seguir:

A e B começam independentemente um do outro C começa uma vez que A ou B já começou D começa quando C já começou

E e F começam independentemente um do outro uma vez que D já começou

A interrupção dos recursos não é influenciada por esta restrição, uma vez que o site symmetrical=false está definido.

# pcs constraint order set A B sequential=false require-all=false set C D set E F sequential=false setoptions symmetrical=false

12.4. CONFIGURAÇÃO DE ORDEM DE PARTIDA PARA DEPENDÊNCIAS

DE RECURSOS NÃO GERENCIADAS PELA PACEMAKER

É possível que um agrupamento inclua recursos com dependências que não são gerenciadas pelo próprio agrupamento. Neste caso, é preciso garantir que essas dependências sejam iniciadas antes de o Pacemaker ser iniciado e parado depois que o Pacemaker for parado.

Você pode configurar sua ordem de partida para responder por esta situação por meio da meta

systemd resource-agents-deps . Você pode criar uma unidade drop-in systemd para este alvo e o

Pacemaker se encarregará de fazer o pedido de forma apropriada em relação a este alvo.

Por exemplo, se um cluster inclui um recurso que depende do serviço externo foo que não é gerenciado pelo cluster, execute o seguinte procedimento.

1. Crie a unidade drop-in /etc/systemd/system/resource-agents-deps.target.d/foo.conf que contém o seguinte:

[Unit]

Requires=foo.service After=foo.service

2. Execute o comando systemctl daemon-reload.

Uma dependência de cluster especificada desta forma pode ser algo diferente de um serviço. Por exemplo, você pode ter uma dependência na montagem de um sistema de arquivo em /srv, caso em que você executaria o seguinte procedimento:

1. Assegure-se de que /srv esteja listado no arquivo /etc/fstab. Isto será convertido

automaticamente para o arquivo systemd srv.mount na inicialização, quando a configuração do gerenciador do sistema for recarregada. Para mais informações, consulte as páginas de manual systemd.mount(5) e systemd-fstab-generator(8).

2. Para ter certeza de que o Pacemaker inicia após a montagem do disco, crie a unidade drop-in

/etc/systemd/system/resource-agents-deps.target.d/srv.conf que contém o seguinte.

[Unit]

Requires=srv.mount After=srv.mount