>_Cluster CentOS 7.2 – Multipath – Pacemaker – Fence – Corosync e Lvm Cluster – 1.1

 

Criando um cluster para atender Container Docker.

Neste primeiro tutorial veremos a configuração dos seguintes pacotes: Multipath,  Pacemaker, Fence, Corosync e do Lvm Cluster.

cluster-centos7

Cluster.

Cluster (ou clustering) é, em poucas palavras, o nome dado a um sistema que relaciona dois ou mais servidores para que estes trabalhem de maneira conjunta no intuito de processar uma ou mais tarefa. Estes servidores dividem entre si as atividades de processamento e executam este trabalho de maneira simultânea.

Os nós do cluster devem ser interconectados, preferencialmente, por uma tecnologia de rede conhecida, para fins de manutenção e controle de custos, como a Ethernet. É extremamente importante que o padrão adotado permita a inclusão ou a retirada de nós com o cluster em funcionamento, do contrário, o trabalho de remoção e substituição de um computador que apresenta problemas, por exemplo, faria a aplicação como um todo parar.

Cluster de Alto Desempenho (High Performance Computing Cluster)
Clusters de alto desempenho são direcionados a aplicações bastante exigentes no que diz respeito ao processamento. Sistemas utilizados em pesquisas científicas, por exemplo, podem se beneficiar deste tipo de cluster por necessitarem analisar uma grande variedade de dados rapidamente e realizar cálculos bastante complexos.

Cluster de Alta Disponibilidade (High Availability Computing Cluster)
Nos clusters de alta disponibilidade, o foco está em sempre manter a aplicação em pleno funcionamento: não é aceitável que o sistema pare de funcionar, mas se isso acontecer, a paralização deve ser a menor possível, como é o caso de soluções de missão crítica que exigem disponibilidade de, pelo menos, 99,999% do tempo a cada ano, por exemplo.

Cluster para Balanceamento de Carga (Load Balancing)
Em clusters de balanceamento de carga, as tarefas de processamento são distribuídas o mais uniformemente possível entre os nós. O foco aqui é fazer com que cada computador receba e atenda a uma requisição e não, necessariamente, que divida uma tarefa com outras máquinas.

Fonte: http://www.infowester.com/cluster.php

Pacemaker.

Pacemaker é responsável por manter a disponibilidade para os seus serviços de cluster através da detecção e recuperação de falhas de nós e de nível de serviço. Ele consegue isso utilizando os recursos de mensagens e de filiação fornecidas por sua infraestrutura de cluster.

GFS2.

Global File System 2 ou GFS2 é um sistema de arquivos em disco compartilhado para clusters Linux.

O GFS2 difere dos demais sistemas de arquivos distribuídos (AFS, Coda, InterMezzo e GlusterFS), tudo porque permite que todos os nós possam concorrentemente acessar o mesmo bloco. Além disso, o GFS ou GFS2 também pode ser usado como um sistema de arquivos local.

O GFS não possui o modo de operação desconectado, e também não trabalha como cliente ou servidor. Todos os nós tem a mesma função de cluster como pares. Usando o GFS em um cluster, é requerido que o hardware permita que o acesso ao armazenamento compartilhado, possua um gerenciador de bloqueio para controlar o acesso ao armazenamento.

O Gerenciador de bloqueio funciona como um módulo separado. Assim o GFS e o GFS2 pode utilizar o Distributed Lock Manager (DLM) para configurações de clusters e do gerenciador de bloqueio “nolock” para sistemas de arquivos locais. Em versões mais antigas do GFS é possível encontrar o Gulam, um gerenciador de bloqueio baseado em um servidor que implementa a redundância via failover.

CLVM – Cluster LVM.

O Clustered Logical Volume Manager (CLVM) é um conjunto de extensões de cluster para o LVM. Estas extensões permitem que um cluster de computadores gerencie o armazenamento compartilhado (por exemplo, em um SAN) usando o LVM. O CLVM é parte do Resilient Storage Add-On.

O uso do CLVM depende dos requerimentos do seu sistema:
Se somente um nó de seu sistema requer acesso ao armazenamento que você estará configurando como volumes lógicos, você pode então utilizar o LVM sem as extensões do CLVM e os volumes lógicos criados com este nó serão todos locais ao nó.

Se você estiver usando um sistema em cluster para failover, onde somente um único nó acessa o armazenamento e está ativo a qualquer momento, você deve usar os agentes do Gerenciamento de Volume Lógico de Disponibilidade (HA-LVM). Para informações sobre o HA-LVM, veja Configurando e Gerenciando um Red Hat Cluster.

Se mais de um nó de seu cluster requer acesso ao seu armazenamento, o qual é compartilhado entre os nós ativos, você precisará usar o CLVM. O CLVM permite que um usuário configure os volumes lógicos em armazenamento compartilhado, bloqueando acesso ao armazenamento físico enquanto um volume lógico está sendo configurado, e usa os serviços de bloqueio em cluster para gerenciar o armazenamento compartilhado.

Para usar o CLVM, o software High Availability Add-On e Resilient Storage Add-On, incluindo o daemon do clvmd, devem estar em execução. O daemon clvmd é a extensão de cluster chave para o LVM. O daemon clvmd roda em cada computador de cluster e distribui as atualizações dos metadados do LVM em um cluster, apresentando cada computador de cluster com a mesma visão dos volumes lógicos. Para informações sobre como instalar e administrar o High Availability Add-On veja Configurando e Gerenciando um Red Hat Cluster.

Multipath.

Multipath I/O é uma técnica de tolerância a falhas e de desempenho-realce que define mais do que um caminho físico em dispositivos de armazenamento em massa através dos devices through the buses, controllers, switches e bridge devices.

Como exemplo, uma unidade de disco rígido SCSI pode conectar-se a dois controladores SCSI no mesmo computador, ou um disco pode conectar a duas portas Fiber Channel. No caso de um controlador, porto ou interruptor falhar, o sistema operacional pode encaminhar o I/O por meio do controlador, porta restante ou mudar de forma transparente e sem alterações visíveis para os aplicativos, exceto, talvez, resultando em aumento da latência.

Camadas de software Multipath pode alavancar os caminhos redundantes para fornecer recursos de melhoria de desempenho, incluindo balanceamento dinâmico de carga, traffic shaping, gestão caminho automático e reconfiguração dinâmica.

Passo 1 – Em ambos os nós (ba-vm-www1 e ba-vm-www2) foram desabilitados o firewall e o selinux.
Obs: No ambiente de produção recomente que o Firewall e o Selinux estejam ativos.

# systemctl disable firewalld
# vim /etc/selinux/config
SELINUX=disabled

Passo 2 – Atualizando os nós  (ba-vm-www1 e ba-vm-www2).

# yum update -y

Passo 3 – Instalando o ntp em ambos os nós (ba-vm-www1 e ba-vm-www2).

# yum install ntp -y
# systemctl enable ntpd

Passo 4 – Ajustando o arquivo /etc/hosts em ambos os nós (ba-vm-www1 e ba-vm-www2).

# vim /etc/hosts
192.168.0.114   ba-vm-www1
192.168.0.115   ba-vm-www2

Passo 5 – Instalando os pacotes necessários para a configuração do multipath.
Obs: A configuração da Lun no Storage não será abordada neste tutorial.

# yum install iscsi-initiator-utils iscsi-initiator-utils-devel iscsi-initiator-utils-iscsiuio device-mapper-multipath

Obs: O iqn de cada nó (ba-vm-www1 e ba-vm-www2) deve ser configurado também em cada Lun que for definida no Storage. Neste caso, ba-vm-www1 e ba-vm-www2.
Passo 6 – Definindo o iqn do nó ba-vm-www1.

# iscsi-iname  -p iqn.2016-01.ba-vm-www1.dtd.local
iqn.2016-01.ba-vm-www1.dtd.local:a2ae8b1d598

Passo 7 – Fixando o iqn criado no arquivo initiatorname.iscsi do nó ba-vm-www1.

# vim /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.2016-01.ba-vm-www1.dtd.local:a2ae8b1d598

Passo 9 – Definindo o iqn do nó ba-vm-www2.

# iscsi-iname  -p iqn.2016-01.ba-vm-www2.dtd.local
iqn.2016-01.ba-vm-www2.dtd.local:544c1fb47abf

Passo 10 – Fixando o iqn criado no arquivo initiatorname.iscsi do nó ba-vm-www2.

# vim /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.2016-01.ba-vm-www2.dtd.local:544c1fb47abf

Passo 11 – Realizando a descoberta do target em cada nó (ba-vm-www1 e ba-vm-www2).

# iscsiadm -m discovery -t sendtargets -p 172.16.0.20
# iscsiadm -m discovery -t sendtargets -p 172.16.0.21
# iscsiadm -m node -L automatic
# /sbin/mpathconf --enable

Passo 12 – Primeiro reboot  (ba-vm-www1 e ba-vm-www2).

# reboot

Passo 13 – Após o reboot, o passo seguinte é a verificação dos mapeamentos.

root@ba-vm-www1 ~]# multipath -l
mpathb (3600507630080840cd80000000000002a) dm-0 IBM     ,2145            
size=45G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=0 status=active
| `- 2:0:0:1 sdc  8:32  active undef running
`-+- policy='service-time 0' prio=0 status=enabled
  `- 3:0:0:1 sdd  8:48  active undef running
mpatha (3600507630080840cd800000000000029) dm-1 IBM     ,2145            
size=5.0G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=0 status=active
| `- 3:0:0:0 sdb  8:16  active undef running
`-+- policy='service-time 0' prio=0 status=enabled
  `- 2:0:0:0 sda  8:0   active undef running
[root@ba-vm-www2 ~]# multipath -l
mpathb (3600507630080840cd80000000000002a) dm-0 IBM     ,2145            
size=45G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=0 status=active
| `- 2:0:0:1 sdb  8:16  active undef running
`-+- policy='service-time 0' prio=0 status=enabled
  `- 3:0:0:1 sdd  8:48  active undef running
mpatha (3600507630080840cd800000000000029) dm-1 IBM     ,2145            
size=5.0G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=0 status=active
| `- 3:0:0:0 sdc  8:32  active undef running
`-+- policy='service-time 0' prio=0 status=enabled
  `- 2:0:0:0 sda  8:0   active undef running

Passo 14 – Instalação dos pacotes necessários para configuração do cluster (ba-vm-www1 e ba-vm-www2).

# yum install rgmanager lvm2-cluster gfs2-utils pcs fence-agents-all -y

Passo 15 – Habilitando e iniciando o serviço pcsd em cada nó (ba-vm-www1 e ba-vm-www2).

# systemctl start pcsd.service
# systemctl enable pcsd.service

Passo 16 – Configurando a senha do usuário hacluster em cada nó (ba-vm-www1 e ba-vm-www2).

# passwd hacluster

Passo 17 – Habilitando o lvm cluster em cada nó (ba-vm-www1 e ba-vm-www2).

# lvmconf --enable-cluster

Passo 18 – Segundo reboot  (ba-vm-www1 e ba-vm-www2).

# reboot

Passo 19 – Habilitando o cluster para os nós ba-vm-www1 e ba-vm-www2.

[root@ba-vm-www1 ~]# pcs cluster auth ba-vm-www1 ba-vm-www2
Username: hacluster
Password: 
ba-vm-www1: Authorized
ba-vm-www2: Authorized

Passo 20 – Criando o cluster com o nome de cluster_docker.

[root@ba-vm-www1 ~]# pcs cluster setup --start --name cluster_docker ba-vm-www1 ba-vm-www2
Shutting down pacemaker/corosync services...
Redirecting to /bin/systemctl stop  pacemaker.service
Redirecting to /bin/systemctl stop  corosync.service
Killing any remaining services...
Removing all cluster configuration files...
ba-vm-www1: Succeeded
ba-vm-www2: Succeeded
Starting cluster on nodes: ba-vm-www1, ba-vm-www2...
ba-vm-www2: Starting Cluster...
ba-vm-www1: Starting Cluster...
Synchronizing pcsd certificates on nodes ba-vm-www1, ba-vm-www2...
ba-vm-www1: Success
ba-vm-www2: Success

Restaring pcsd on the nodes in order to reload the certificates...
ba-vm-www1: Success
ba-vm-www2: Success

Passo 21 – Verificando o status do cluster com o comando pcs cluster status.

[root@ba-vm-www1 ~]#  pcs cluster status
Cluster Status:
 Last updated: Fri Jan 29 16:37:39 2016         Last change: Fri Jan 29 16:36:40 2016 by hacluster via crmd on ba-vm-www1
 Stack: corosync
 Current DC: ba-vm-www1 (version 1.1.13-10.el7-44eb2dd) - partition with quorum
 2 nodes and 0 resources configured
 Online: [ ba-vm-www1 ba-vm-www2 ]

PCSD Status:
  ba-vm-www1: Online
  ba-vm-www2: Online
[root@ba-vm-www2 ~]#  pcs cluster status
Cluster Status:
 Last updated: Fri Jan 29 16:36:48 2016         Last change: Fri Jan 29 16:36:40 2016 by hacluster via crmd on ba-vm-www1
 Stack: corosync
 Current DC: ba-vm-www1 (version 1.1.13-10.el7-44eb2dd) - partition with quorum
 2 nodes and 0 resources configured
 Online: [ ba-vm-www1 ba-vm-www2 ]

PCSD Status:
  ba-vm-www1: Online
  ba-vm-www2: Online

Passo 22 – Verificando os devices mapeados já com o multipath.
Obs: Os mapeamentos precisam estarem iguais em ambos os nós. Caso contrário será necessário configurar um alias no arquivo multipath.conf para cada nó. Geralmente não é necessário, mas por boas práticas recomendo que configure para o ambiente de produção.

Disk /dev/mapper/mpatha: 48.3 GB, 48318382080 bytes, 94371840 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/mpathb: 5368 MB, 5368709120 bytes, 10485760 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Passo 23 – Criando os primeiros resources.
Obs: Este primeiro resource tem como objetivo ativar o dlm deixando que o pacemaker controle o saúde do cluster.

[root@ba-vm-www1 ~]# pcs resource create dlm ocf:pacemaker:controld op monitor interval=30s on-fail=fence clone interleave=true ordered=true

Obs: Este segundo resource tem como objetivo ativar o clvmd deixando que o heartbeat cuide da saúde do serviço de lvm-cluster.

[root@ba-vm-www1 ~]# pcs resource create clvmd ocf:heartbeat:clvm op monitor interval=30s on-fail=fence clone interleave=true ordered=true

Passo 24 – Criando a ordem de inicialização dos serviços essenciais do cluster.

[root@ba-vm-www1 ~]# pcs constraint order start dlm-clone then clvmd-clone
Adding dlm-clone clvmd-clone (kind: Mandatory) (Options: first-action=start then-action=start)
[root@ba-vm-www1 ~]# pcs constraint colocation add clvmd-clone with dlm-clone

Passo 25 – Definindo qual a política de quorum que será aplicada para o cluster. Neste caso, será ignorado pelo fato de só existir dois nós. Se houvesse mais de 2 nós, poderíamos definir qual a porcentagem de perda o cluster poderia sofrer.

[root@ba-vm-www1 ~]# pcs property set no-quorum-policy=ignore

Fencing.

Como o número de nós em um cluster aumenta, o mesmo acontece com a probabilidade de que um deles possa falhar em algum ponto. O nó ou node não pode ter o controle sobre os recursos compartilhados que precisam ser recuperados, e se este nó está ou esteja agindo de forma irregular, o resto do sistema precisa ser protegido. É ai que entra o Fencing.
Com o Fencing é possível desativar o nó automaticamente, não permitindo que ele permaneça no grupo do cluster enquanto sua saúde não esteja boa. Desta forma, será possível remover o nó automaticamente, não permitindo que a integridade do cluster seja afetada.
Passo 26 – Configurando o fence_scsi, apontando para o device /dev/mapper/mpatha.
Obs: Existe vários tipos de fence, para este tutorial estou usando o fence_scsi pelo fato do multipath. Neste caso, se o multipath falhar em um dos nós, automaticamente este nó será removido do cluster.

[root@ba-vm-www1 ~]# pcs stonith create scsi fence_scsi pcmk_host_list="ba-vm-www1 ba-vm-www2" pcmk_monitor_action="metadata" pcmk_reboot_action="off"devices="/dev/mapper/mpatha" meta provides="unfencing"

Passo 26 – Verificando o status dos resources.

[root@ba-vm-www1 ~]# pcs status resources
 Clone Set: dlm-clone [dlm]
     Started: [ ba-vm-www1 ba-vm-www2 ]
 Clone Set: clvmd-clone [clvmd]
     Started: [ ba-vm-www1 ba-vm-www2 ]

Obs: Caso não esteja com a flag Started, utilize o comando abaixo para verificar o erro reportado no log.

[root@ba-vm-www1 ~]# crm_verify -L -V

Passo 27 – Terceiro reboot  (ba-vm-www1 e ba-vm-www2).

# reboot

Passo 28 – Iniciando o cluster manualmente.

[root@ba-vm-www1 ~]# pcs cluster start --all

Passo 29 – Verificando novamente o status dos resources.
Obs: Tem que iniciar automaticamente.

[root@ba-vm-www1 ~]# pcs status resources
 Clone Set: dlm-clone [dlm]
     Started: [ ba-vm-www1 ba-vm-www2 ]
 Clone Set: clvmd-clone [clvmd]
     Started: [ ba-vm-www1 ba-vm-www2 ]
[root@ba-vm-www2 ~]# pcs status resources
 Clone Set: dlm-clone [dlm]
     Started: [ ba-vm-www1 ba-vm-www2 ]
 Clone Set: clvmd-clone [clvmd]
     Started: [ ba-vm-www1 ba-vm-www2 ]

Passo 30 – Habilitando o corosync e o pacemaker em ambos os nós (ba-vm-www1 e ba-vm-www2).

[root@ba-vm-www1 ~]# systemctl enable corosync
Created symlink from /etc/systemd/system/multi-user.target.wants/corosync.service to /usr/lib/systemd/system/corosync.service.
[root@ba-vm-www2 ~]# systemctl enable corosync
Created symlink from /etc/systemd/system/multi-user.target.wants/corosync.service to /usr/lib/systemd/system/corosync.service.
[root@ba-vm-www1 ~]# systemctl enable pacemaker
Created symlink from /etc/systemd/system/multi-user.target.wants/pacemaker.service to /usr/lib/systemd/system/pacemaker.service.
[root@ba-vm-www2 ~]# systemctl enable pacemaker
Created symlink from /etc/systemd/system/multi-user.target.wants/pacemaker.service to /usr/lib/systemd/system/pacemaker.service.

Passo 31 – Quarto reboot (ba-vm-www1 e ba-vm-www2).

# reboot

Passo 32 – Verificando novamente o status dos resources.

[root@ba-vm-www1 ~]# pcs status resources
 Clone Set: dlm-clone [dlm]
     Started: [ ba-vm-www1 ba-vm-www2 ]
 Clone Set: clvmd-clone [clvmd]
     Started: [ ba-vm-www1 ba-vm-www2 ]
[root@ba-vm-www2 ~]# pcs status resources
 Clone Set: dlm-clone [dlm]
     Started: [ ba-vm-www1 ba-vm-www2 ]
 Clone Set: clvmd-clone [clvmd]
     Started: [ ba-vm-www1 ba-vm-www2 ]

Comandos importantes para verificação do cluster.

Verificando o status do fence.

[root@ba-vm-www1 ~]# pcs stonith show
 scsi	(stonith:fence_scsi):	Started ba-vm-www1

Verificando o estado do resource scsi.

# pcs stonith show scsi
 Resource: scsi (class=stonith type=fence_scsi)
  Attributes: pcmk_host_list="ba-vm-www1 ba-vm-www2" pcmk_monitor_action=metadata pcmk_reboot_action=offdevices=/dev/mapper/mpatha 
  Meta Attrs: provides=unfencing 
  Operations: monitor interval=60s (scsi-monitor-interval-60s)

Verificando a ordem de inicialização dos serviços dlm-clone e clvmd-clone.

[root@ba-vm-www1 ~]# pcs constraint show
Location Constraints:
Ordering Constraints:
  start dlm-clone then start clvmd-clone (kind:Mandatory)
Colocation Constraints:
  clvmd-clone with dlm-clone (score:INFINITY)

Verificando o status do cluster.

[root@ba-vm-www1 ~]#  pcs status
Cluster name: cluster_docker
Last updated: Sat Jan 30 20:52:59 2016		Last change: Sat Jan 30 01:42:02 2016 by root via cibadmin on ba-vm-www1
Stack: corosync
Current DC: ba-vm-www1 (version 1.1.13-10.el7-44eb2dd) - partition with quorum
2 nodes and 5 resources configured

Online: [ ba-vm-www1 ba-vm-www2 ]

Full list of resources:

 Clone Set: dlm-clone [dlm]
     Started: [ ba-vm-www1 ba-vm-www2 ]
 Clone Set: clvmd-clone [clvmd]
     Started: [ ba-vm-www1 ba-vm-www2 ]
 scsi	(stonith:fence_scsi):	Started ba-vm-www1

PCSD Status:
  ba-vm-www1: Online
  ba-vm-www2: Online

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

Habilitando o cluster.

[root@ba-vm-www1 ~]#  pcs cluster enable --all
ba-vm-www1: Cluster Enabled
ba-vm-www2: Cluster Enabled

Arquivo de log do corosync.

# /var/log/cluster/corosync.log

Continua no segundo tutorial.

Fontes:
https://access.redhat.com/documentation/pt-BR/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/LVM_Cluster_Overview.html
https://en.wikipedia.org/wiki/GFS2https://www.ibm.com/developerworks/community/blogs/mhhaque/entry/configure_two_node_highly_available_cluster_using_iscsi_fencing_on_rhel7?lang=en
http://keithtenzer.com/2015/06/22/pacemaker-the-open-source-high-availability-cluster/

>_Cluster CentOS 7.2 – Multipath – Pacemaker – Fence – Corosync e Lvm Cluster – 1.1
Tagged on:

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

%d blogueiros gostam disto: