“Aprendi linux usando o bash, mas as facilidades que o ZSH me dâ são inegáveis”
procedimento para instalação de um cluster PCS
Este manual mostra como instalar e configurar um cluster de dois nós centos7 usando pacemaker, considere esses dados como infraestrutura para implantar
| host | IP |
|---|---|
| ucloud01.ustore.local | 192.168.0.101 |
| ucloud02.ustore.local | 192.168.0.102 |
- IP VIP: 192.168.0.100
- Serviço para controlar: uCloud
1.1 - Instalação do Software Cluster
O procedimento para instalar e configurar um cluster é o seguinte.
Em cada nó do cluster, instale os pacotes de software Red Hat High Availability Add-On juntamente com todos os agentes disponíveis.
# yum install pcs pacemaker fence-agents-all
Criar /etc/hosts entradas
Edite /etc/hosts e crie entradas para todos os nós
192.168.0.101 ucloud1.usto.local ucloud1
192.168.0.102 ucloud2.usto.local ucloud2
Configurando o firewall iptables para permitir componentes de cluster
Se você estiver executando o daemon firewalld, execute os seguintes comandos para habilitar as portas que são requeridas pelo Complemento de Alta Disponibilidade Red Hat.
Nota 1:
Você pode determinar se o daemon firewalld está instalado em seu sistema com o comando rpm -q firewalld. Se o daemon firewalld estiver instalado, você pode determinar se ele está sendo executado com o comando firewall-cmd –state.
# firewall-cmd --permanent --add-service=high-availability
# firewall-cmd --add-service=high-availability
Nota 2:
A configuração de firewall ideal para componentes de cluster depende do ambiente local, você pode precisar levar em consideração se os nós têm várias interfaces de rede ou se há firewall fora do host. O exemplo aqui, abre as portas geralmente exigidas por um cluster Pacemaker, deve ser modificado para atender às condições locais.
A Tabela 1.1, “Portas para Habilitar” mostra as portas para habilitar para o Complemento de Alta Disponibilidade e fornece uma explicação para o que a porta é usada.
Tabela 1.1. Portas a serem ativadas para complemento de alta disponibilidade
| Porta | Quando Necessário |
|---|---|
| TCP 2224 | Necessário em todos os nós (necessário pela interface do usuário da Web do pcsd e necessário para a comunicação nó a nó) É crucial abrir a porta 2224 de forma que os PCs de qualquer nó possam se comunicar com todos os nós do cluster, incluindo ele próprio. Ao usar o gerenciador de tickets de cluster Booth ou um dispositivo de quorum, você deve abrir a porta 2224 em todos os hosts relacionados, como árbitros Booth ou o host do dispositivo quorum. |
| TCP 3121 | Obrigatório em todos os nós se o cluster tiver algum nó Pacemaker Remote O daemon crmd do Pacemaker nos nós completos do cluster entrará em contato com o daemon pacemaker_remoted nos nós Pacemaker Remote na porta 3121. Se uma interface separada for usada para comunicação do cluster, a porta só precisa ser aberta nessa interface. No mínimo, a porta deve abrir nos nós remotos do Pacemaker para nós completos do cluster. Como os usuários podem converter um host entre um nó completo e um nó remoto ou executar um nó remoto dentro de um contêiner usando a rede do host, pode ser útil abrir a porta para todos os nós. Não é necessário abrir a porta para quaisquer hosts que não sejam nós. |
| TCP 5403 | Necessário no host do dispositivo de quorum ao usar um dispositivo de quorum com corosync-qnetd. O valor padrão pode ser alterado com a opção -p do comando corosync-qnetd. |
| UDP 5404 | Necessário em nós corosync se o corosync estiver configurado para multicast UDP |
| UDP 5405 | Necessário em todos os nós do corosync (necessário pelo corosync) |
| TCP 21064 | Obrigatório em todos os nós se o cluster contiver quaisquer recursos que requeiram DLM (como clvm ou GFS2) |
| TCP 9929, UDP 9929 | Necessário para ser aberto em todos os nós do cluster e nós do árbitro de cabine para conexões de qualquer um desses mesmos nós quando o gerenciador de tickets do Booth é usado para estabelecer um cluster multissite. |
Para usar pcs para configurar o cluster e se comunicar entre os nós, você deve definir uma senha em cada nó para o ID do usuário hacluster, que é a conta de administração de pcs. Recomenda-se que a senha do usuário hacluster seja a mesma em cada nó.
# passwd hacluster
Changing password for user hacluster.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
Antes que o cluster possa ser configurado, o daemon pcsd deve ser iniciado e ativado para inicializar na inicialização de cada nó. Esse daemon funciona com o comando pcs para gerenciar a configuração nos nós do cluster.
Em cada nó do cluster, execute os seguintes comandos para iniciar o serviço pcsd e habilitar o pcsd na inicialização do sistema.
# systemctl enable --now pcsd.service
Autentique o hacluster do usuário pcs para cada nó no cluster no nó a partir do qual você executará pcs.
O comando a seguir autentica o usuário hacluster em ucloud1.usto.local para ambos os nós no exemplo de cluster de dois nós, ucloud1.usto.local e ucloud2.usto.local.
[root@z1 ~]# pcs cluster auth ucloud1.usto.local ucloud2.usto.local
Username: hacluster
Password:
ucloud1.usto.local: Authorized
ucloud2.usto.local: Authorized
1.2. Criação de Cluster
Este procedimento cria um cluster de complemento de alta disponibilidade da Red Hat que consiste nos nós ucloud1.usto.local e ucloud2.usto.local.
Execute o seguinte comando de ucloud1.usto.local para criar o cluster dci de dois nós que consiste nos nós ucloud1.usto.local e ucloud2.usto.local. Isso propagará os arquivos de configuração do cluster para ambos os nós no cluster. Esse comando inclui a opção –start, que iniciará os serviços de cluster em ambos os nós do cluster.
[root@z1 ~]# pcs cluster setup --start --name dci \
ucloud1.usto.local ucloud2.usto.local
ucloud1.usto.local: Succeeded
ucloud1.usto.local: Starting Cluster...
ucloud2.usto.local: Succeeded
ucloud2.usto.local: Starting Cluster...
Ative os serviços de cluster para serem executados em cada nó do cluster quando o nó for inicializado.
Observação
Para seu ambiente específico, você pode optar por deixar os serviços de cluster desativados ignorando esta etapa. Isso permite garantir que, se um nó ficar inativo, quaisquer problemas com seu cluster ou seus recursos sejam resolvidos antes que o nó retorne ao cluster. Se você deixar os serviços de cluster desativados, precisará iniciar manualmente os serviços ao reinicializar um nó executando o comando pcs cluster start nesse nó.
[root@z1 ~]# pcs cluster enable --all
Você pode exibir o status atual do cluster com o comando pcs cluster status. Como pode haver um pequeno atraso antes que o cluster esteja funcionando quando você inicia os serviços de cluster com a opção –start do comando pcs cluster setup, você deve garantir que o cluster esteja funcionando antes de executar quaisquer ações subsequentes no cluster e sua configuração.
[root@z1 ~]# pcs cluster status
Cluster Status:
Last updated: Thu Jul 25 13:01:26 2013
Last change: Thu Jul 25 13:04:45 2013 via crmd on ucloud2.usto.local
Stack: corosync
Current DC: ucloud2.usto.local (2) - partition with quorum
Version: 1.1.10-5.el7-9abe687
2 Nodes configured
0 Resources configured
1.2. Criando os recursos e grupos de recursos com o comando pcs
Este caso de uso requer que você crie dois recursos de cluster. Para garantir que todos esses recursos sejam executados no mesmo nó, eles são configurados como parte do grupo de recursos ucloud. Os recursos a serem criados são os seguintes, listados na ordem em que serão iniciados. Considere o VIP Ip como 198.168.0.100 e a interface é uma eth1, para criar um serviço usamos um tipo de recurso systemd, esse recurso pode usar scripts systemd para controlar aplicativos.
Para configurar VIP IP:
pcs resource create VirtualIP IPaddr2 ip=198.168.0.100 nic=eth1 cidr_netmask=24 --group ucloud
Para configurar o serviço:
pcs resource create ucloud systemd:ucloud --group ucloud