Antes de tudo, configure o stickiness para 100. Assim iremos ter certeza que os resources, no caso o ClusterIP e o WebSite que iremos criar, irão mudar para o nó que ficará ativo. Execute:
pcs resource defaults resource-stickiness=100
Confirme:
[root@oracle86 ~]# pcs resource defaults resource-stickiness: 100
Mas, voltando ao tema, agora que temos um cluster de dois nós ativo/passivo básico, mas funcional, estamos prontos para adicionar alguns serviços reais. Vamos começar com servidor web Apache porque é um resource usado por muitos clusters e relativamente simples de configurar.
Agora que começamos a trabalhar com resources é bom saber: “não habilite nenhum serviço, como o httpd manualmente quando estes foram adicionados ao Cluster. Os serviços destinados a serem gerenciados por meio do software de cluster nunca devem ser gerenciados pelo sistema operacional. Muitas vezes é útil, no entanto, iniciar manualmente o serviço para verificar se ele funciona e pará-lo novamente antes de adicioná-lo ao cluster. Isso permite que você resolva quaisquer problemas não relacionados ao cluster antes de continuar.“
Vamos começar então pelo apache.
Instale o Apache
Antes de tudo, instale a ferramenta wget juntamente com o apache:
RED HAT, CENTOS E DERIVADOS
dnf install wget httpd
DEBIAN, UBUNTU E DERIVADOS
apt install wget apache2
Habilitando a URL de Status do Apache
Para monitorar a integridade de sua instância do Apache e recuperá-la em caso de falha, o agente de recursos usado pelo Pacemaker assume que a URL de status do servidor está disponível. Em ambos os nós, habilite o URL criando o arquivo status.conf com o seguinte conteúdo:
Conteúdo do arquivo /etc/httpd/conf.d/status.conf
<Location /server-status> SetHandler server-status Require local </Location>
Se quiser, poderá usar o comando cat para criar esse arquivo
# cat <<-END >/etc/httpd/conf.d/status.conf <Location /server-status> SetHandler server-status Require local </Location> END
Se você estiver usando um sistema operacional diferente CentOS ou Red Hat, o status do servidor pode já estar ativado ou pode ser configurado em um local diferente. Se você estiver usando uma versão do Apache HTTP Server inferior a 2.4, a sintaxe será diferente.
Configurando o Cluster para Adicionar o Apache
Vamos chamar o resource de WebSite. Precisamos usar um script de resource OCF chamado apache no namespace heartbeat. Veja: Padrões de Resources Disponíveis. O único parâmetro obrigatório do script é o caminho para o arquivo de configuração principal do Apache; diremos ao cluster para verificar uma vez por minuto se o Apache ainda está em execução.
Execute:
[root@orcle86 ~]# pcs resource create WebSite ocf:heartbeat:apache \ configfile=/etc/httpd/conf/httpd.conf \ statusurl="http://localhost/server-status" \ op monitor interval=1min
Por padrão, o tempo limite de operação para iniciar, parar e monitorar as operações de todos os recursos é de 20 segundos. Em muitos casos, esse período de tempo limite é menor do que o período de tempo limite recomendado de um recurso específico. Para os fins deste tutorial, ajustaremos o padrão de tempo limite de operação global para 240 segundos.
[root@pcmk-1 ~]# pcs resource op defaults timeout=240s Warning: Defaults do not apply to resources which override them with their own defined values
[root@pcmk-1 ~]# pcs resource op defaults timeout: 240s
Nota: Em um cluster em produção em sua organização, geralmente é melhor ajustar os tempos limite de início, parada e monitoramento de cada resource para valores apropriados ao comportamento observado em seu ambiente, em vez de ajustar o padrão global.
Após um pequeno atraso, devemos ver o cluster iniciar o Apache.
[root@oracle86B ~]# pcs status Cluster name: meuCluster Status of pacemakerd: 'Pacemaker is running' (last updated 2023-03-06 15:55:57 -05:00) Cluster Summary: * Stack: corosync * Current DC: oracle86B (version 2.1.4-5.0.1.el8_7.2-dc6eb4362e) - partition with quorum * Last updated: Mon Mar 6 15:55:57 2023 * Last change: Mon Mar 6 15:44:26 2023 by root via cibadmin on oracle86B * 2 nodes configured * 2 resource instances configured Node List: * Online: [ oracle86 oracle86B ] Full List of Resources: * ClusterIP (ocf::heartbeat:IPaddr2): Started oracle86B * WebSite (ocf::heartbeat:apache): Started oracle86B Daemon Status: corosync: active/disabled pacemaker: active/enabled pcsd: active/enabled
Outra coisa, se receber erro na mudança do serviço WebSite para o outro nó reveja se configurou certo o arquivo status.conf.
Você poderá usar o comando abaixo no terminal:
wget -O - http://localhost/server-status
Se você receber um Not Found ou Forbidden como resultado, provavelmente esse é o problema. Certifique-se de que o conteúdo dentro de status.conf esteja correto.
Certifique-se de que os Recursos Sejam Executados no Mesmo Host
Se os resources no seu cluster então ativos em diferentes nós e você deseja que todos fiquem ativos em apenas um então falaremos sobre isso.
Para reduzir a carga em qualquer máquina, o Pacemaker geralmente tentará distribuir/espalhar os resources(recursos) em vários nós do cluster, ou seja, um serviço em um nó e outro em outro nó. No entanto, podemos dizer ao cluster que dois resources estão relacionados e precisam ser executados no mesmo host.
Aqui, instruímos o cluster que o WebSite só pode ser executado no host em que o ClusterIP está ativo.
Para conseguir isso, usamos uma colocation constraint que indicará que é obrigatório que o WebSite seja executado no mesmo nó que o ClusterIP. A parte “obrigatória” da restrição de colocation é indicada usando uma pontuação de INFINITY. A pontuação INFINITY também significa que, se o ClusterIP não estiver ativo em nenhum lugar, o WebSite não terá permissão para ser executado.
colocation constraint são “direcionais”, pois implicam certas coisas sobre a ordem em que os dois resources/recursos terão um local escolhido. Neste caso, estamos dizendo que o WebSite precisa ser colocado na mesma máquina que o ClusterIP, o que implica que o cluster deve saber a localização do ClusterIP antes de escolher um local para o WebSite.
Execute:
[root@oracle86B ~]# pcs constraint colocation add WebSite with ClusterIP INFINITY
Agora veja o resultado
[root@oracle86B ~]# pcs constraint Location Constraints: Ordering Constraints: Colocation Constraints: WebSite with ClusterIP (score:INFINITY) Ticket Constraints:
Se estava com resources ativos em diferentes nós então, ao executar pcs status, verá que os resouces WebSite e ClusterIP estarão em somente um dos nós.
Certifique-se de que os Recursos Iniciem e Parem na Ordem Correta
Como muitos serviços, o Apache pode ser configurado para se ligar a endereços IP específicos em um host ou ao endereço IP curinga. Se o Apache se vincular ao curinga, não importa se um endereço IP é adicionado antes ou depois do início do Apache; O Apache responderá nesse IP da mesma forma. No entanto, se o Apache se vincular apenas a determinados endereços IP, a ordem é importante: se o endereço for adicionado após o início do Apache, o Apache não responderá nesse endereço.
Para garantir que nosso WebSite responda independentemente da configuração de endereço do Apache, precisamos garantir que o ClusterIP não apenas seja executado no mesmo nó, mas comece antes do WebSite. Uma constraint colocation(restrição de colocação) garante apenas que os recursos sejam executados juntos, não a ordem em que são iniciados e interrompidos. Para a ordem usamos constraint order.
Por padrão, todas as constraint order(restrições de ordem) são obrigatórias, o que significa que a recuperação do ClusterIP também acionará a recuperação do WebSite.
Execute: pcs constraint order ClusterIP then WebSite
[root@oracle86B ~]# pcs constraint order ClusterIP then WebSite Adding ClusterIP WebSite (kind: Mandatory) (Options: first-action=start then-action=start)
Veja executando pcs constraint
[root@oracle86B ~]# pcs constraint Location Constraints: Ordering Constraints: start ClusterIP then start WebSite (kind:Mandatory) Colocation Constraints: WebSite with ClusterIP (score:INFINITY) Ticket Constraints:
Prefira um nó ao invés de outro
O Pacemaker não depende de nenhum tipo de simetria de hardware entre os nós, então pode ser que uma máquina seja mais poderosa que a outra.
Nesses casos, você pode querer hospedar os resources/recursos no nó(servidor) mais poderoso quando estiver disponível, para ter o melhor desempenho.
Para fazer isso, criamos uma constraint location(restrição de localização).
No constraint location abaixo estamos dizendo que o resource WebSite prefere o nó oracle86 com uma pontuação de 50. Aqui, a pontuação indica o quanto gostaríamos que o recurso fosse executado neste local.
Execute: pcs constraint location WebSite prefers oracle86=50
[root@oracle86B ~]# pcs constraint location WebSite prefers oracle86=50
mas se você olhar agora o status do cluster verá que os resources estarão ainda ativos em oracle86B.
[root@oracle86B ~]# pcs status Cluster name: meuCluster ........ Node List: * Online: [ oracle86 oracle86B ] Full List of Resources: * ClusterIP (ocf::heartbeat:IPaddr2): Started oracle86B * WebSite (ocf::heartbeat:apache): Started oracle86B .......
Mesmo que o WebSite agora prefira rodar no oracle86 ao invés de oracle86B, essa preferência é, intencionalmente, menor que a stickiness(o quanto preferimos não ter tempo de inatividade desnecessário).
Para ver as pontuações de colocation atuais, você pode usar uma ferramenta chamada crm_simulate.
Execute crm_simulate -sL
[root@oracle86B ~]# crm_simulate -sL [ oracle86 oracle86B ] ClusterIP (ocf::heartbeat:IPaddr2): Started oracle86B WebSite (ocf::heartbeat:apache): Started oracle86B pcmk__native_allocate: ClusterIP allocation score on oracle86: 50 pcmk__native_allocate: ClusterIP allocation score on oracle86B: 200 pcmk__native_allocate: WebSite allocation score on oracle86: -INFINITY pcmk__native_allocate: WebSite allocation score on oracle86B: 100