Skip to content

334_High_Availability_Cluster_management

Jump to bottom
João Batista Correa Junior edited this page Jan 18, 2023 · 1 revision

Table of Contents

334.1_Hight_Availability_Concepts_and_Theory

Objetivo do Tópico

Peso: 5

Description: Candidates should understand the properties and design approaches of high availability clusters. Key Knowledge Areas: 

    Understand the most important cluster architectures
    Understand recovery and cluster reorganization mechanisms
    Design an appropriate cluster architecture for a given purpose
    Application aspects of high availability
    Operational considerations of high availability

Terms and Utilities: 

    Active/Passive Cluster, Active/Active Cluster
    Failover Cluster, Load Balanced Cluster
    Shared-Nothing Cluster, Shared-Disk Cluster
    Cluster resources
    Cluster services
    Quorum
    Fencing
    Split brain
    Redundancy
    Mean Time Before Failure (MTBF)
    Mean Time To Repair (MTTR)
    Service Level Agreement (SLA)
    Desaster Recovery
    Replication
    Session handling

Understand the most important cluster architectures

"Um Cluster é um conjunto de máquinas independentes, chamadas nós, que cooperam umas com as outras para atingir um determinado objetivo comum. Para usuários externos, o cluster é visto como sendo um único sistema."

  • 3 Tipos principais de clusters:
    • Alta disponibilidade: (High Availability (ha) and Failover): Utilizados por serviços críticos
    • Balanceamento de carga (Load Balancing): Utilizados por serviços críticos
    • Processamento distribuído ou processamento paralelo ou alto desempenho(HPC - Hight Performance Computing): Utilizado quando necessário grande poder de processamento.
  • Alta disponibilidade (HA):
"É aquele que utiliza mecanismos de detecção, recuperação e mascaramento de falhas, visando manter o funcionamento dos serviços durante o máximo de tempo possível, inclusive no decurso de manutenções programadas" Marcelo Garcia
    • Feito para prover disponibilidade de forma ininterrupta
    • Se um nó do cluster falhar, os serviços estarão disponíveis em outro nó
Modelos principais de cluster de alta disponibilidade:
      • Active/Passive Cluster: Provê uma instância totalmente redundante de cada nó, que só é colocado online quando seu nó principal associado falha. Esta configuração requer tipicamente um hardware extra adicional.
Exemplo de uso:
Este tipo compreende duas infra-estruturas idênticas próximas, logicamente configuradas lado a lado. Um nó hospeda o serviço de banco de dados ou aplicativo, 
enquanto o outro descansa "braços cruzados" à espera no caso de o sistema primário cair. Eles compartilham um componente de armazenamento e o servidor primário 
entrega 'graciosamente/gentilmente' o controle do armazenamento para o outro servidor ou nó quando ele falhar. Em caso de falha do nó primário, o nó inativo 
torna-se o principal e hospeda o banco de dados ou aplicativo

Fonte: https://technet.microsoft.com/en-us/library/cc737532%28v=ws.10%29.aspx
      • Active/Active Cluster: Tráfego destinado para o nó com falha é repassado para um nó ou feito um 'load balanced' entre os nós restantes. Isso geralmente só é possível quando os nós utilizam uma configuração de software homogênea.
Exemplos de uso:

Neste tipo, um nó (NO-01) age como primário para uma instância do banco de dados e o nó secundário (NO-02) como failover para esta instância. Ao mesmo tempo, o nó 
secundário (NO-02) age como primário para outra instância de banco de dados e o NO-01 como failover desta instância de banco.
A configuração Active/Active traz um melhor custo benefício em comparação ao Active/Passive, mas isto pode resultar em problemas de performance no momento do 
FailOver onde duas instâncias de banco de dados vão rodar no mesmo nó

Fonte: https://technet.microsoft.com/en-us/library/cc737532%28v=ws.10%29.aspx
  • Balanceamento de carga (Load Balancing):
Balanceamento de Carga (Load Balancing)é um mecanismo usado para atingir escalabilidade, dividindo a carga de processamento entre um conjunto de servidores. Chamado de server farm. Cada solicitação de um cliente é atendida completamente por um servidor.
    • As tarefas de processamento são distribuídas o mais uniformemente possível entre os nós. Cada servidor recebe e atende a uma requisição e não, necessariamente, que divida uma tarefa.
    • Exemplo: Balanceamento de servidor WEB. Encaminha e balanceia as requisições entre servidores Web. Nginx é um programa que faz isso.
    • Exemplo2: Projeto Linux Virtual Server: http://pt.wikipedia.org/wiki/LVS
  • Definição de - Disponibilidade: Capacidade de um usuário de determinado sistema acessar, incluir ou modificar os dados existentes em qualquer intervalo de tempo. Caso o usuário não tenha acesso, ele fica indisponível. Total de tempo de indisponibilidade é o downtime.
  • Shared-Nothing Cluster;
A arquitetura Shared-Nothing - 'Não compartilha Nada' - (SN) é uma arquitetura de computação distribuída em que cada nó é independente e auto-suficiente, e não há um único ponto de falha em todo o sistema. Mais especificamente, nenhum dos nós compartilha memória ou disco de armazenamento. As pessoas normalmente contrastam SN com sistemas que mantêm uma grande quantidade de informações centralmente armazenados, seja em um banco de dados, um servidor de aplicativos, ou qualquer outro ponto único. Um cluster SN por exemplo, como não compartilha disco, tem que ter um tipo de replicação para sincronização dos dados (DRBD).

Fontes:

A arquitetura de cluster com compartilhamento de disco deve utilizar um sistema de arquivos de disco compartilhado. Um sistema de arquivos em disco compartilhado usa uma rede de área de armazenamento (SAN) para fornecer acesso direto ao disco de vários computadores no nível de bloco. O Controle de acesso e tradução de operações de nível de arquivo que os aplicativos usam para operações em nível de bloco usados ​​pelo SAN deve ocorrer no nó do cliente. O tipo mais comum de sistemas de arquivos em cluster é sistema de arquivos de disco compartilhado, o que, por adição de mecanismos de controle de simultaneidade fornece uma visão consistente e serializado do sistema de arquivos, evitando a corrupção e perda de dados não intencional, mesmo quando vários clientes tentam acessar os mesmos arquivos em ao mesmo tempo. É uma prática comum para sistemas de arquivos de disco compartilhado empregar algum tipo de mecanismo de Fencing (Isolamento) para impedir a corrupção de dados em caso de falhas de nós, porque um dispositivo sem isolamento pode causar corrupção de dados se ele perder a comunicação com seus nós irmãos, e tenta acessar o mesma informação que outros nós estão acessando. Alguns protocolos utilizados na conexão com Shared-disks são: SCSI, iSCSI, HyperSCSI, ATA over Ethernet (AoE), Fibre Channel, network block device, e InfiniBand. Existem diferentes abordagens de arquitetura para um sistema de arquivos de disco compartilhado. Alguns distribuem informações de arquivo em todos os servidores em um cluster (fully distributed). Outras utilizam um servidor centralizado de metadados. Ambos alcançam o mesmo resultado de permitir que todos os servidores acessem todos os dados em um dispositivo de armazenamento compartilhado.

Understand recovery and cluster reorganization mechanisms

  • Cluster resources:
    • "Um recurso representa certa funcionalidade oferecida em um nó. Ele pode ser físico ou lógico, como um endereço IP. Recursos são a unidade básica de gerenciamento, e podem migrar de um nó para outro. O processo de migração de um recurso de um nó para outro é chamado de Failover. Um recurso tem associado a si um tipo, que descreve seus atributos genéricos e seu comportamento." Recursos também podem ser chamados de serviços (como serviço de HTTP por exemplo) que por sua vez tem dependências de outros recursos/serviços.
  • Redundancy: Redundância é basicamente hardware ou software adicional que pode ser usado como backup se o hardware ou software principal falhar. A redundância pode ser alcançada através de cluster, failover, RAID, balanceamento de carga e alta disponibilidade de forma automatizada. Uma camada superior de redundância é alcançada quando o dispositivo de suporte é completamente separado do dispositivo principal. Por exemplo, uma linha de internet de backup é fornecida por outro provedor ISP, com uma ligação física completamente separada, ou um hardware redundante que reside em outro prédio.
  • Cluster services
Os serviços de cluster para funcionar adequadamente devem garantir a integridade. Uma das situações mais comuns é quando se esta utilizando os dados em um SAN ele deve ser acessado apenas por um nó. o sistema de Cluster por sua vez deve garantir que apenas um nó acesse estes dados. Para evitar problemas como quando mais de um nó no cluster acha que pode acessar o mesmo SAN, foram criados mecanismos como Quorum e Fencing conforme será visto abaixo:
  • Split brain (cérebro dividido):
Quando mais de um nó acredita ser o cluster ativo, fornecendo concorrentemente os mesmos serviços ou acessando a mesma SAN causando corrupção de dados. Uma situação típica, por exemplo em um cluster de 3 nós (no1, no2 e no3) onde 1 (o nó no3) perde a comunicação, neste momento o cluster se divide entre no1,no2 que continuam no cluster e o no3 separado, achando que somente ele é o cluster. Métodos de resolver este problema: Quorum e fencing A ideia do fencing é cercar a parte do cluster ou o nó que não pode mais oferecer recursos ou acessar uma SAN. Ele faz isso de dois modos: Resource fencing e node fencing. Um aspecto importante de boas técnicas de fencing é que eles são realizados sem a cooperação do nó que está sendo isolado, e que o fencing da confirmação positiva de que o isolamento foi feito.
    • Resource Fencing: É a ideia de que se você sabe que recursos um nó pode estar usando, então você pode usar algum método de bloqueá-lo de acessar esses recursos. Por exemplo, se tem um disco que é acessado por um interruptor de canal de fibra, então pode-se falar com o interruptor de canal de fibra e dizer a ele para negar o acesso do nó defeituoso à SAN.
    • Node Fencing: É a ideia de que se pode manter um nó desligado de todos os recursos - sem saber que tipo de recursos que ele pode estar acessando, então como se poderia negar o acesso a eles. Uma maneira comum de fazer isso é desligar ou reiniciar o nó problemático. Este é um método um tanto deselegante mas muito eficaz de bloqueá-lo de acessar qualquer coisa. Essa técnica também é chamada STONITH - que é um acrônimo gráfico de Shoot The Other Node In The Head (atirar na cabeça do outro nó).
    • Outros recursos que podem ser utilizados, alternativos ao fencing é o Node Suicide e o self-shutdown, que são técnicas que dependem do nó problemático, onde ele ou se desligará ou reiniciará caso perca o quorum.
  • Quorum: O Fencing consegue isolar corretamente o nó ou a parte do cluster problemática. Mas como definir qual parte do cluster é a problemática (e deve ser isolada) e qual a correta e deve se manter em funcionamento? Para solucionar esta questão temos o quorum. A ideia de quorum representa o processo de seleção de um único subcluster. A solução mais clássica para a seleção de um único subgrupo é uma maioria de votos, ou seja, o subgrupo que tiver mais votos que a metade da quantidade de membros do cluster assume o controle do cluster.
    • Quorum em cluster com 2 nós: Em um cluster com dois nós, a solução clássica não funciona pois cada nós tem igual número de votos. Neste caso existem alguns métodos disponíveis para resolver o problema. Dois deles são SCSI Reserve (hardware) e Quorum Daemon (software).
      • No caso do SCSI Reserve: Quando duas maquinas tentam reservar (acessar) uma partição, o dispositivo garante que apenas uma conseguirá. Chamado também de quorum disk é utilizado normalmente por soluções de cluster da Microsoft.
      • No caso do Quorum Daemon: É uma solução de software utilizada pelo Linux-HA para arbitrar disputas de quorum entre membros de clusters. É basicamente um SCSI reserve implementado em software, escrito para isso.
  • Fontes:

Design an appropriate cluster architecture for a given purpose

  • Este tópico se baseia na capacidade de identificarmos a real necessidade do cluster e indicarmos a melhor alternativa de configuração (de arquitetura) do cluster.
  • Isto está vinculado aos tipo de clusters vistos anteriormente, ou seja:
    • Cluster de alto desempenho: Utilizado em tarefas que exigem alto desempenho, como reinderação de objetos 3d, cálculos climáticos, etc. Parte do conceito de dividir uma grande tarefa (calculo) em tarefas menores.
      • Exemplo: Cluster Beowulf, com um nó controlador que envia as tarefas para os demais nós, para execução paralela.
    • Cluster de alta disponibilidade: Utilizado em ambientes que devem garantir que um serviço esteja ativo em mais de um nó ao mesmo tempo. Utiliza replicação de dados ou serviços. Utiliza por exemplo o HeartBeat para identificar qual serviço esta ativo ou inativo através da troca de mensagens.
    • Cluster de balanceamento de carga: Distribui as solicitações através dos nós de um cluster. Usado por sistemas que possuem grande quantidade de acessos e precisam de informação em tempo real (Web Apache) . Alguns algorítmos de escalonamento (definição de qual server será enviada a próxima requisição): Least connections; Round Robin; Weighted Fair
    • Cluster de alta disponibilidade e balanceamento de carga: Une os dois mundos anteriores. Exemplo, balanceamento para server Web e Alta disponibilidade para Server de banco de dados.
  • Fonte: http://pt.slideshare.net/scfofudo/clusters-o-que
  • Fonte: http://www.clubedohardware.com.br/artigos/computacao-em-cluster/153

Application aspects of high availability

Informações necessárias para identificar o percentual de disponibilidade dos serviços:

  • Mean Time Before Failure (MTBF): É o tempo médio entre as falhas 'mean time between failures'
MTBF = (Total up time) / (número de breakdowns)
  • Mean Time To Repair (MTTR): É o tempo máximo para reparos 'maximum time to repair'
MTTR = (Total down time) / (número de breakdowns)
  • Disponibilidade: O percentual do tempo em que o serviço esta disponível
MTBF / (MTBF + MTTR) = % Disponibilidade

Operational considerations of high availability

  • Disaster Recovery (Recuperação de desastres): Envolve um conjunto de políticas e procedimentos para permitir a recuperação ou continuação da infraestrutura de tecnologia e sistemas vitais na sequência de um desastre natural ou provocado pelo homem. O plano de recuperação de desastres é composto, por cenários e procedimentos, que deverão ser aplicados sempre que ocorrer uma falha. Geralmente é composto de três fases:
    • Programa de Administração de Crise: Plano desenvolvido em conjunto, com definição de atividade, pessoas, dados lógicos e físicos
    • Plano de Continuidade Operacional: Possui diretivas do que fazer em cada operação em caso de desastres
    • Plano de Recuperação de Desastres; É a aplicação na prática do plano de continuidade operacional
  • Replication (Active Replication)
    • Replicação ativa faz a transferência de informações entre réplicas. Serve também para coordenar e sincronizar as transações. Cada réplica possui uma cópia consistente das informações. Representa um 'alto custo' a nível de hardware.
    • Replicação Passiva (Passive ou Lazy Replication): A ideia é que não se deseja que todo o estado esteja compartilhado, mas somente parte dele.
  • Session handling: O gerenciamento de sessões pode ser um problema quando trabalhamos com alta disponibilidade e balanceamento de cargas. Principalmente quando utilizamos soluções http que necessitam de informações das seções. Neste caso o tratamento das sessões deve ser previsto, armazenando as informações de sessões em locais onde todos os servidores do balanceamento tem acesso. Existe a possibilidade de 'prender' uma sessão de um usuário a um determinado servidor, chamado de “sticky sessions”, mas isso pode trazer problemas de perda de conexão do usuário caso o nó em que o usuário esteja preso venha a falhar.
  • Fontes:

334.2_Load_Balanced_Clusters-Peso6

Objetivos do tópico

Peso: 6

Description: Candidates should know how to install, configure, maintain and troubleshoot LVS. This includes the configuration and use of keepalived and ldirectord. Candidates should further be able to install, configure, maintain and troubleshoot HAProxy. Key Knowledge Areas: 

    Understanding of LVS / IPVS
    Basic knowledge of VRRP
    Configuration of keepalived
    Configuration of ldirectord
    Backend server network configuration
    Understanding of HAProxy
    Configuration of HAProxy

Terms and Utilities: 

    ipvsadm
    syncd
    LVS Forwarding (NAT, Direct Routing, Tunneling, Local Node)
    connection scheduling algorithms
    keepalived configuration file
    ldirectord configuration file
    genhash
    HAProxy configuration file
    load balancing algorithms
    ACLs

Understanding of LVS / IPVS

O Linux Virtual Server (LVS) é uma solução de balanceamento de carga avançada para sistemas Linux. É um projeto Open Source começado por Wensong Zhang em maio de 1998. A missão do projeto é construir um servidor de alto desempenho e altamente disponível para Linux usando a tecnologia de clustering, que fornece altos níveis de escalabilidade, confiabilidade e usabilidade. No momento, o trabalho principal do projeto LVS é desenvolver o software de balanceamento de carga avançado de IP (IPVS), o software de balanceamento de carga a nível aplicativo (KTCPVS) e componentes de gerenciamento de cluster. (wikipedia)

  • IPVS: é um software balanceador de carga avançado do IP executado dentro do Linux. IPVS rodando em um host atua como um balanceador de carga na frente de um cluster de servidores reais, pode dirigir pedidos de serviços baseados em TCP / UDP para os servidores reais, e faz os serviços dos servidores reais funcionarem como um serviço virtual através um endereço IP único.
O LVS pode ser implementado em uma das 3 formas:
  • Via NAT: Reescreve os pacotes TCP-IP enviados para ele, alterando o endereço e encaminhando para o destino. Pode gerar lentidão com grande fluxo de dados.
  • Via IP Tunneling: O load balancer encaminha as requisições dos clientes para os servidores reais e estes respondem diretamente para os usuários. Todos os servidores do cluster precisam ter o IP Tunneling (Encapsulamento IP) habilitado.
  • Via Direct Routing: Só processa requisições de entrada, deixando os servidores reais responderem diretamente para os usuários, utilizando roteamento direto ao invés de IP Tunneling. Para isso tanto o load balancer quanto os real servers precisam estar na mesma rede (mesmo enlace de rede).

Instalação do LVS

  • Nomenclatura utilizada pelo projeto LVS:
    • LVS: É um conjunto entre o director e os RealServers
    • Director: É o nó que roda o código IPVs. Os clientes conectam no Director que encaminha a requisição para os RealServers
    • RealServer: Servidor real que tem o serviço que o cliente precisa acessar
    • Client: Quem inicia a conexão, busca a informação, cliente final
    • Sheduling: É o algoritmo que o director utiliza para escolher qual realserver ele vai enviar uma nova conexão do cliente.
    • ipvsadm: É a interface linha de comando, para o usuário utilizar o LVS
  • O LVS já esta habilitado nos kernels dês de a versão 2.4. Para instalar o aplicativo para gerenciamento e configuração do LVS instalar o pacote abaixo no director:
No caso do Debian:
# aptitude install ipvsadm

Comando ipvsadm

Responsável pela configuração, controle e gerenciamento do IPVS.

  • ipvsadm-save: Salva as regras criadas pelo ipvsadm
  • ipvsadm-restore: Restaura as regras criadas pelo ipvsadm
  • ipvsadm --help: Mostra as diversas opções de ipvsadm
As possibilidades de algoritmos que podem ser usados para o balanceamento das conexões são os seguintes: 
Opção "-s" ou --scheduler scheduling-method
              
→ rr - Round Robin: Distribui a carga igualmente entre os RealServers disponíveis.

→ wrr - Weighted Round Robin: Distribui carga aos RealServers proporcionalmente ao peso de cada um. Servidores com maiores pesos receberão mais cargas
que servidores com pesos menores. RealServers com pesos iguais receberão carga de distribuição igual.

→ lc - Least-Connection: Atribui mais carga ao RealServer com um menor número de carga ativa.

→ wlc  - Weighted Least-Connection: Atribui mais carga ao RealServer com menor carga ativa e relativa ao peso definido ap RealServer. Este é o padrão.

→ lblc - Locality-Based Least-Connection: Atribui carga destinada do mesmo IP address (cliente) para o mesmo RealServer, se este não esta sobrecarregado e
 esta disponível. Caso contrário atribui carga ao RealServer com menor carga e mantém esta informação em caso de nova conexão do IP.

→ lblcr  -Atribui cargas destinadas ao mesmo ip  para o nó com menos conexões no servidor definido para o endereço IP. Se todos os nós estão sobre carregados,
ele sobe um novo nó no cluster e adiciona neste servidor setado para o destino.
Se o conjunto de servidores não foram modificados pelo tempo especificado, o nó mais carregado será removido do conjunto de servidores, afim de evitar o
 alto grau para replicação.

→ dh - Destination Hashing: Atribui carga ao RealServer verificando uma tabela hash estática por seu IP de destino.

→ sh - Source Hashing: Atribui carga ao RealServer verificando uma tabela hash estática por seu IP de origem. Todas as conexões requisitadas de um cliente
 vão para o mesmo RealServer

→ sed - Shortest Expected Delay: Atribui uma carga ao servidor com o menos atraso esperado. O atraso esperado que a carga vai testar é (Ci + 1) / Ui. 
Se for enviado para o servidor em que Ci é o numero de jobs/tarefas do servidor e Ui é o Peso.

→ nq - Never Queue: Atribui a carga de entrada ao servidor disponível (idle), se houver, ao invés de ficar aguardando o mais rápido. Se todos os servidores estão
ocupados ele adota o SED (Shortest Expected Delay) para encaminhar a carga.
  • LBLC, DH schedulers: Usado para cache de internet, prevê a conexão no mesmo RealServer que mantém um determinado dominio ja cacheado anteriormente
Comando básico para adição de um direcionamento:
  • Dividido em duas partes, a primeira se refere ao serviço que será adicionado, a segunda as regras referentes a este serviço. Semelhante a estrutura utilizada no 'iptabes'.
  • Abaixo a primeira parte referente a adição do serviço de encaminhamento
* No Director
# ipvsadm -A -t $VIP:$SERVICE -s $SHEDULER

Mais opções referentes a gerenciamento de serviço: 

  --add-service     -A        add virtual service with options
  --edit-service    -E        edit virtual service with options
  --delete-service  -D        delete virtual service
  --clear           -C        clear the whole table
  --restore         -R        restore rules from stdin
  --save            -S        save rules to stdout

Na manutenção de serviços, outras opções são opcionais. 

--tcp-service  -t service-address   service-address is host[:port]
--udp-service  -u service-address   service-address is host[:port]
--scheduler    -s scheduler         one of rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq, the default scheduler is wlc.
--persistent   -p [timeout]         persistent service
--pe            engine              alternate persistence engine may be sip, not set by default.
--netmask      -M netmask           persistent granularity mask

  --daemon                            output of daemon information
  --stats                             output of statistics information
  --rate                              output of rate information
  --exact                             expand numbers (display exact values)
  --thresholds                        output of thresholds information
  --persistent-conn                   output of persistent connection info
  --numeric      -n                   numeric output of addresses and ports
  • A segunda parte se refere a adição/manutenção de direcionamentos para o serviço anteriormente adicionado, chamados de rules ou regras.
* No Director
# ipvsadm -a -t $VIP:$SERVICE -r $REALSERVER_NAME:$SERVICE $FORWARDING -w 1

Opções referentes a controle de rules/regras de um serviço: 

  --add-server      -a        add real server with options
  --edit-server     -e        edit real server with options
  --delete-server   -d        delete real server
  --list            -L|-l     list the table
  --zero            -Z        zero counters in a service or all services

Tipo de encaminhamento para o serviço (FORWARDING). Dependendo do tipo de encaminhamento escolhido, a composição da rede deve estar adequada para isso, conforme explicado no início do capítulo em Understanding of LVS / IPVS. 

# Tipos de encaminhamento possíveis:
--gatewaying   -g                   gatewaying (direct routing) (default) → Opção explicada em: "Via Direct Routing"
--ipip         -i                   ipip encapsulation (tunneling) → Opção explicada em: "Via IP Tunneling" 
--masquerading -m                   masquerading (NAT) → Opção explicada em: "Via NAT"

Outras opções 'mais usadas' referentes ao detalhamento da regra 

--tcp-service  -t service-address   service-address is host[:port]
--udp-service  -u service-address   service-address is host[:port]
--real-server  -r server-address    server-address is host (and port)
--weight       -w weight            capacity of real server
--u-threshold  -x uthreshold        upper threshold of connections
--l-threshold  -y lthreshold        lower threshold of connections
--timeout                           output of timeout (tcp tcpfin udp)

Configuração do LVS no formato NAT

O LVS usa a habilidade do kernel Linux de mudar o endereço IP e porta dos pacotes que passam por ele. Neste método, o Director recebe uma requisição de um cliente e a repassa para um RealServer, que a processa, enviando o resultado de volta para o Director, que então faz as mudanças necessárias para converter o IP dos pacotes no endereço de servidor virtual, dando resposta ao cliente, dando a este a impressão que está tratando apenas com uma máquina.

Exemplo 

Director# ipvsadm -A -t 200.0.0.10:80 -p 600 -s rr
Director# ipvsadm -a -t 200.0.0.10:80 -r 192.168.3.2 -m -w 100
Director# ipvsadm -a -t 200.0.0.10:80 -r 192.168.3.3 -m -w 100
Onde: 
-A → Adiciona um serviço de balanceamento
-t → Indica que é um serviço TCP. Para UDP usar '-u'
-s → Tipo de algoritmo de encaminhamento que será utilizado (sheduler)
-p → Serviço persistente. Todas as requisições dos clientes são enviador para um servidor. O timeout 600, se o servidor real não responde em 600 segundos, 
então será feita uma requisição para um outro servidor.
-a → Adiciona uma nova ??regra?? a um serviço anteriormente adicionado.
-r → Servidor real (RealServer) que será encaminhada a requisição.
-m → Usa mascaramento. NAT (Network Address Translation).
-w → weight (peso). O IPVS assume que quanto maior o peso, mais requisições serão encaminhadas, O servidor com peso menor, terá menos encaminhamentos. 
O peso '0' indica que o servidor (RealServer) não receberá encaminhamentos.

Salvar as regras de forma permanente: 

Director# ipvsadm -S -n >> /etc/ipvsadm.rules (funciona no Debian-8)

Obs: Para correto funcionamento do NAT com 2 redes tivemos que adicionar um MASQUERADE na placa de recepção da conexão para funcionar OK.

Configuração do LVS no formato de Tunelamento-IP

Tunelamento IP (IP tunneling) é uma tecnica para encapsular datagramas IP em datagramas IP, o que permite que datagramas destinados a um endereço de IP seja redirecionado a outro endereço de IP.

  • Os servidores reais podem ter qualquer ip real e podem estar distribuídos geograficamente, porém devem suportar o encapsulamento IP.
  • No servidor Real, um ip virtual localhost deve ser criado e ao ser acessado o serviço deve escutar este IP
  • A conexão entre o Balanceador e o servidor Real funciona como uma VPN, um túnel.
  • Fluxo da conexão:
  1. Cliente requisita uma conexão ao serviço balanceado
  2. Balanceador de carga analisa o pacote e encapsula a requisição em um datagrama IP
  3. Balanceador envia a requisição para o servidor Real
  4. Servidor Real desencapsula o datagrama IP, processa a requisição
  5. Servidor Real retorna a requisição diretamente para o cliente conforme sua própria tabela de roteamento
  • Exemplo de ativação do LVS por tunelamento:
* Configuração de IPs
** O load balancer (LinuxDirector), kernel 2.2.14

#    echo 1 > /proc/sys/net/ipv4/ip_forward
#    ipvsadm -A -t 172.26.20.110:23 -s wlc
#    ipvsadm -a -t 172.26.20.110:23 -r 172.26.20.112 -i

** O real server 1, kernel 2.2.14

#    echo 1 > /proc/sys/net/ipv4/ip_forward
#    modprobe ipip
#    ifconfig tunl0 0.0.0.0 up
#    echo 1 > /proc/sys/net/ipv4/conf/all/hidden
#    echo 1 > /proc/sys/net/ipv4/conf/tunl0/hidden
#   ifconfig tunl0 172.26.20.110 netmask 255.255.255.255 broadcast 172.26.20.110 up

Configuração do LVS no formato Direct-routing

O Director repassa as conexões para os Servidores Reais e estes respondem diretamente para os clientes que fizeram as requisições. Os Servidores Reais devem estar no mesmo segmento de rede que o Director e possuir uma interface virtual de loopback(lo:0) configurada com o VIP que não responde a requisições ARP, respondendo diretamente ao cliente, o que implica que o Director não necessita estar no caminho de volta.
  • Configuração no LVS server (balanceador)
Exemplo:
# ipvsadm -A -t 192.168.90.171:80 -s rr
# ipvsadm -a -t 192.168.90.171:80 -r 192.168.90.175 -g
# ipvsadm -a -t 192.168.90.171:80 -r 192.168.90.176 -g

Basic knowledge of VRRP

  • Virtual Router Redundancy Protocol (VRRP) É um protocolo de rede de computador que prevê atribuição automática de IPs de roteadores disponíveis, para os hosts. Isso aumenta a disponibilidade e confiabilidade de caminhos de roteamento através de seleções automáticas de gateway padrão em uma sub-rede IP.
  • O protocolo consegue isso através da criação de roteadores virtuais, que são uma representação abstrata de vários roteadores, ou seja, Roteador mestre e roteadores de backup, atuando como um grupo. O gateway padrão de um host participante é atribuído ao roteador virtual (ip do grupo) em vez de um roteador físico. Se o roteador físico (que é quem esta roteando pacotes em nome do roteador virtual) falhar, outro roteador físico é selecionado para substituí-lo automaticamente. O roteador físico que está encaminhando pacotes em um determinado momento é chamado de roteador mestre.
  • O VRRP fornece informações sobre o estado de um router, não as rotas processadas ​​e trocadas por esse roteador. Cada instância VRRP é limitada, no âmbito de aplicação, a uma única sub-rede. Ela não anuncia rotas IP para além dessa sub-rede ou afeta a tabela de roteamento de qualquer forma.
  • Requisitos: right
    • Habilitar Multicast na interface que fará a comunicação entre os roteadores
  • Exemplo de configuração:
# vim /etc/sysctl.conf
net.ipv4.ip_nonlocal_bind=1

* Habilitar Multicast caso necessário.
# ip link set dev eth1 multicast on 

* No firewall Master
# vrrpd -i eth1 -v 1 -p 255 -d 60 10.1.1.254 -n & 

* No Firewall backup
# vrrpd -i eth1 -v 1 -p 1 -d 60 10.1.1.254 -n &

* Onde:
---
-i = Interface
-v = Id do grupo que o firewall/roter faz parte
-p = Peso ou prioridade do host dentro do grupo, quanto maior, maior será a prioridade
-d = Delay, ou tempo de aguardo para ser considerado falha
-n = Não alterar o IP do Mac virtual
---

Configuration of keepalived

  • Com o Keepalived unen-se dois softwares, criando uma solução completa para balanceamento de carga utilizando o LVS e a alta disponibilidade do balanceador através do VRRP.
  • Keepalived é um software de roteamento escrito em C. O principal objetivo deste projeto é fornecer instalações simples e robustas para balanceamento de carga e alta disponibilidade para o sistema Linux e infra-estruturas de base Linux. O Loadbalancing framework é confiado ao bem-conhecido e amplamente utilizado módulo do kernel Linux Virtual Server (IPVS) fornecendo balanceamento de carga em layer4. Keepalived implementa um conjunto de checagens para dinamicamente e de forma adaptativa manter e gerenciar pool de servidores loadbalance de acordo com a sua saúde (status). Por outro lado a alta disponibilidade é obtida pelo protocolo VRRP. VRRP é uma peça fundamental para o router failover. Framework keepalived pode ser usado de forma independente ou em conjunto para proporcionar as infra-estruturas resilientes.
  • O Keepalived configura um LVS, monitora a saúde dos serviços nos servidores reais e gera um daemon vrrpd para LVS que permite "director failover".
Após instalado, o arquivo de configuração do Keepalived fica situado geralmente em: /etc/keepalived/keepalived.conf
  • Como o Keepalived é um framework e facilitador para as implementações LVS e VRRP, todas as configurações são feitas neste arquivo de configuração, que é organizado conforme explicado abaixo:
* Arquivo de configuração dividido em 3 partes principais que se subdividem em outras partes:
   * Globals configurations
     * Global definitions
     * Static routes
   * VRRP configuration
     * VRRP scripts
     * VRRP Synchronization group
     * VRRP instance
   * LVS configuration
     * Virtual server group
     * Virtual server

Obs: Documentação explicativa em: /usr/share/doc/keepalived/keepalived.conf.SYNOPSIS

Exemplo de configuração do Keepalived utilizando VRRP e LVS 

* Exemplo de configuração no servidor de balanceamento-01

# Global
 # Configurações de aviso por email são colocadas aqui


# Configuração do protocolo VRRP (Virtual Router Redundancy) Redundancia do Balanceador

vrrp_instance dir01 {         # Nome da instancia
	virtual_router_id 1   # VRID - Deve ser o mesmo para todos routers participantes do grupo
	interface eth0	      # Interface. Deve ter a opção multicast habilitada
	priority 100	      # Prioridade. Quanto maior mais prioritario
	virtual_ipaddress {   # Ip virtual que será criado para acesso na interface	
	  192.168.90.171/24
	}
}

# Configurações de balanceamento - LVS

virtual_server 192.168.90.171 80 {		# Configurações do respectivo Ip virtual
  delay_loop 2 					# Tempo em segundos entre as verificações de servidores reais.
  lb_algo rr					# Algoritmo utilizaro Round Robin
  lb_kind DR					# Tipo de balanceamento (utilizando o Direct Routing)
  protocol TCP					# Protocolo
	real_server 192.168.90.175 80 {		# Configuração do servidor real 01 - Backend
	  weight 1				## Peso do servidor

	HTTP_GET {				## Tipo de checagem do server por HTTP
         url {
             path /index.html
             digest e2a7f39699ee49225bfb41535537470f  ## Utilizando hash que é obtido pelo comando genhash
         }
        }
   
	TCP_CHECK {				## Tipo de checagem Tcp/IP na porta
	   connect_port    80			## Porta e checagem
           connect_timeout 3			## Tempo de timeout
 	   } 
	}

	real_server 192.168.90.176 80 {		# Configuração do servidor real 02 - Backend
	  weight 1

	HTTP_GET {
         url {
             path /index.html
             digest 2d6e55b4e9d6acaa9536c776a846532f
         }
        }
	   TCP_CHECK {
	   connect_port    80
           connect_timeout 3
 	   } 
	}

}


* Também deve ser configurado o servidor de balanceamento-02, alterando as opções: ''vrrp_instance'' e ''priority''.

Configuration of ldirectord

  • Ldirectord é um daemon para monitorar e administrar servidores reais em um cluster de balanceamento de carga, utilizando o LVS. o ldirectord usa os recursos do projeto Linux-HA, mas também pode ser rodado a partir da interface de linha de comando.
  • O Ldirectord tem um arquivo de configuração que especifica o virtual services e associa aos servidores reais. Quando o ldirectord é inicializado ele cria os serviços virtuais para o cluster.
  • Por fim o ldirectord monitora a saúde dos servidores reais através de requisições periódicas a URL configurada, verificando se a resposta é a resposta esperada. Se o servidor real falha, então o servidor é removido do balanceamento LVS e será reativado apenas quando seu status retornar para on-line. Se todos os servidores reais estiverem apresentando falha, um servidor de espera (fall-back) pode ser inserido no pool. Tipicamente o servidor de espera é o próprio localhost, e isto é util para retornar uma página de indisponibilidade momentânea.
Exemplo de configuração de um serviço ldirectord: 
* Arquivo de configuração: /etc/ldirectord.cf 
--
checktimeout=3   # Tempo de espera para definição de servidor Down
checkinterval=5  # Intervalo de checagem
autoreload=yes   # Se houver alteração no arquivo de con. durante a execução, o ldirectord vai automaticamente carregá-la
logfile="/var/log/ldirectord.log"  # Local do arquivo e log
quiescent=no     # Em caso de algum RealServer ficar down, Ldirectord retira este Realserver do balanceamento LVS
virtual=192.168.90.171:80          # Ip Virtual de acesso
	real=192.168.90.175:80 gate   # IP_Servidor_real:Porta tipo de encaminhamento lvs. Gate=Direct Routing
	real=192.168.90.176:80 gate
	scheduler=rr               # Tipo de algoritmo de balanceamento
	protocol=tcp               # Tipo de protocolo
	checktype=connect          # Tipo de checagem do serviço
	checkport=80               # Porta do serviço a ser verificado
--

Backend server network configuration

Algumas configurações são necessárias nos servidores de backend, ou seja servidores que provem os serviços reais, para o correto funcionamento de um sistema de balanceamento e alta disponibilidade.

  • Configuração do servidor de backend para uso do LVS
    • Adicionar o ip virtual (VIP) a interface de loopback (lo:0) na mascara /32
    • Ajustar os parametros sysctl para o IP virtual criado no backend não responder ARP. Mais detalhes ver O problema ARP
    • Ajustar serviço para responder também por este IP (VIP) 
* Definindo IP virtual na interface lo:0
auto lo:0
iface lo:0 inet static
address 172.16.1.1 # Lembre-se esse é o VIP que setamos na conf do keepalived
netmask 255.255.255.255

* Resolvendo o problema Arp
sysctl net.ipv4.conf.all.arp_ignore = 1
sysctl net.ipv4.conf.eth0.arp_ignore = 1
sysctl net.ipv4.conf.eth1.arp_ignore = 1
sysctl net.ipv4.conf.all.arp_announce = 2
sysctl net.ipv4.conf.eth0.arp_announce = 2
sysctl net.ipv4.conf.eth1.arp_announce = 2

* Para ativar a feature hidden
echo 1 > /proc/sys/net/ipv4/conf/all/hidden
* Para fazer o lo:0 não responder a ARP mas lo sim
echo 1 > /proc/sys/net/ipv4/conf/<interface_name>/hidden

Understanding of HAProxy

HAProxy é uma solução livre, muito rápida e confiável. Oferece Alta Disponibilidade, load balancing e proxy para TCP/HTTP. Isto é adequado e usado para alto tráfego a Web sites. É oferecido no repositório das principais distribuições e também por default nas plataformas de cloud.

  • O modo de operação da ferramenta permite fazer integração com arquiteturas existentes de maneira muito fácil e baixo risco, enquanto oferece a possibilidade de não expor a web diretamente o servidor WEB.
  • Possui connection persistence através de cookies HTTP, balanceamento de carga, adição de cabeçalho, modificação e exclusão. Ele tem capacidades de solicitação de bloqueio e fornece uma interface WEB para exibir o status do servidor.
  • HAProxy trabalha sob camada de rede 7 (layer 7)
  • Seu uso mais comum é para melhorar o desempenho e a confiabilidade de um ambiente de servidor, distribuindo a carga de trabalho entre vários servidores. É utilizado por muitos ambientes conhecidos como o Titter e Instagram.
  • HAProxy pode trabalhar em conjunto com o Nginx agregando as funções de cache (nginx) com balanceamento e HA (haproxy)
  • Veja abaixo as características principais do HAProxy:
    • Modo de proxy-reverso
    • Disponibilidade de tunnel mode
    • Básico e avançado load-balancing
    • Checagem de saúde do server
    • Suporte IPv6
    • Management socket (CLI)
    • Multiplos métodos para conexões persistentes
    • Mitigação DOS e DDOS
    • Interface Web
    • Server / proteção do aplicativo por meio do gerenciamento de filas
    • ACLs
    • Full HTTP 1.1 support no lado do servidor
    • Pode trabalhar com TCP level com qualquer L7 protocolo
    • Poderosa ferramenta de análise de logs (halog)
  • Algumas terminologias utilizadas na configuração do HAProxy:
    • Access Control List(ACL):
Em relação ao load balancing, ACLs são usadas para testar algumas condições e executar alguma ação (como selecionar um servidor ou bloquear uma requisição) baseado no resultado de um teste. O uso de ACLs permite o encaminhamento flexível do tráfico de rede baseado em uma variedade de fatores como pattern-matching e numero de conexões para o backend.
    • Backend:
Backend é um conjunto do servidor que recebe as requisições encaminhadas. Backends são definidos na seção backend do arquivo de configuração HAProxy. Backend pode conter um ou muitos servidores. De um modo geral, acrescentar servidores no Backend aumenta a performance pois a carga será distribuida para um número maior de servidores. O aumento de confiabilidade também é conseguido através desta forma, no caso de alguns dos seus servidores backend ficarem indisponíveis.
    • Frontend:
Frontend define como as requisições devem ser encaminhadas para o backend. Frontends são definidos na seção frontend no arquivo de configuração do HAProxy. Estas definições são compostas pelos seguintes componentes:
      • Configuração de IP Address e porta
      • ACLs
      • Regras Use_backend. Definem que backends serão usados dependendo de qual condição ACL são correspondidas, e/ou uma regra default_backend que lida com todos os outros casos. Um Frontend pode ser configurado para vários tipos de tráfego de rede.
  • Sobre o Layer 7 Load Balancing
Uma via complexa para utilização do Load Balancing é a utilização do Layer 7 (camada de aplicação). Usar o Layer 7 permite que o Load Balancer (frontend) faça o encaminhamento a diferentes backends servers baseando-se no conteúdo da requisição do usuário. Este modo de Load Balancing permite rodar múltiplos servidores de aplicações Web sob um mesmo domínio e porta. Por exemplo, se um usuário requisita seudominio.com/blog, poderá ser encaminhado para o backend responsável pelo blog, ou seja para o conjunto de ervidores com a aplicação de blog. Outras requisições poderão ser encaminhadas para outro backend rodando outro tipo de aplicação.

Configuration of HAProxy

A configuração do HAProxy é feita utilizando um arquivo de configuração, geralmente situado em /etc/haproxy/haproxy.cfg.

  • O arquivo de configuração é dividido em blocos conforme o tipo de configuração:
    • global: Configurações globais referentes ao serviço
    • defaults: Configurações padrões, que serão utilizadas caso não especificadas em outros blocos
    • frontend: Configuração do encaminhador
    • backend: Configuração de encaminhamento para servidores de serviço
Abaixo um arquivo de configuração modelo comentado, usando dois servers para serviço (backend) e regra ACL simples para evitar ataque de negação de serviço. 
global
	maxconn		2000	# Numero máximo de conexoes simultaneas no Frontend
	log /dev/log	local0	# Criação de LOG
	log /dev/log	local1 notice
	chroot /var/lib/haproxy
	stats socket /run/haproxy/admin.sock mode 660 level admin
	stats timeout 30s
	user haproxy
	group haproxy
	daemon

	# Default SSL material locations
	ca-base /etc/ssl/certs
	crt-base /etc/ssl/private

	# Default ciphers to use on SSL-enabled listening sockets.
	# For more information, see ciphers(1SSL). This list is from:
	#  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
	ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
	ssl-default-bind-options no-sslv3

defaults
	# Configuracao de monitoramento de estatistica por console WEB
	stats	enable
	stats auth	usuario:senha	# Usuario e senha para acesso as estatisticas do Haproxy
	stats refresh	2s
	stats uri	/haproxystat 	# Uri para acesso das estatisticas http://servidor/haproxystat

	log	global
	mode	http
	option	httplog
	option	dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
	errorfile 400 /etc/haproxy/errors/400.http
	errorfile 403 /etc/haproxy/errors/403.http
	errorfile 408 /etc/haproxy/errors/408.http
	errorfile 500 /etc/haproxy/errors/500.http
	errorfile 502 /etc/haproxy/errors/502.http
	errorfile 503 /etc/haproxy/errors/503.http
	errorfile 504 /etc/haproxy/errors/504.http

frontend Director-HTTP			# Configuração do Frontend-Director-Encaminhador
	bind 192.168.90.171:80		# Responde pelo IP virtual
	maxconn 3000			# Máximo de conexões simultâneas

	## Configuração de captura de cabeçalho para posterior tratamento de ACL
	capture request  header Host           len 20
        capture request  header User-Agent     len 16
        capture request  header Content-Length len 10
        capture request  header Referer        len 20
        capture response header Content-Length len 10
	#
	# ACL de bloqueio de ataques comuns (awstats, manual discovery...)
        acl forbidden_uris path_dir -i chat main.php read_dump.php viewtopic.php phpbb sumthin horde _vti_bin MSOffice
        acl forbidden_uris url_reg -i (\.php\?temppath=|\.php\?setmodules=|[=:]http://)
        block if forbidden_uris
	#
	default_backend App-Servers	# Acesso por este frontend encaminha para servidores do Backend App-server

backend App-Servers			# Configuração dos servidores backend
        balance roundrobin					# Algoritmo de balanceamento
	option	forwardfor					# Encaminha ip do cliente p/ backend
	option	httpchk GET / HTTP/1.1\r\nHost:\ localhost	# Checa serviço no backend
        
	server App01 192.168.90.175:80 check			# Configuração de Servidor App1. Muitas outras opções podem
								# ser colocadas após a porta, por exemplo cookie, inter, fall
								# que ativam o cookie p/ conexao permanente, define o tempo de checagem 
								# do server e limite de falha p/ server ser considerado morto.
        server App02 192.168.90.176:80 check			# Configuração de Servidor App2

Além deste modelo de blocos, outro modelo de configuração é possível, utilizando ao invés dos blocos frontend e backend, o bloco listen que reúne as informações dos dois blocos anteriores em um só conforme o simplificado exemplo abaixo: 

# Configuração simples utilizando um único listen block. É mais curto porém menos explicativo
    global
        daemon
        maxconn 256

    defaults
        mode http
        timeout connect 5000ms
        timeout client 50000ms
        timeout server 50000ms

    listen http-in
        bind 192.168.90.171:80
        server server1 192.168.90.175:80 maxconn 32
        server server1 192.168.90.176:80 maxconn 32

334.3_Failover_Clusters-Peso6

Objetivos do tópico

Peso: 6

Description: Candidates should have experience in the installation, configuration, maintenance and troubleshooting of a Pacemaker cluster. This includes the use of Corosync. The focus is on Pacemaker 1.1 for Corosync 2.x. Key Knowledge Areas: 

    Pacemaker architecture and components (CIB, CRMd, PEngine, LRMd, DC, STONITHd)
    Pacemaker cluster configuration
    Resource classes (OCF, LSB, Systemd, Upstart, Service, STONITH, Nagios)
    Resource rules and constraints (location, order, colocation)
    Advanced resource features (templates, groups, clone resources, multi-state resources)
    Pacemaker management using pcs
    Pacemaker management using crmsh
    Configuration and Management of corosync in conjunction with Pacemaker
    Awareness of other cluster engines (OpenAIS, Heartbeat, CMAN)

Terms and Utilities: 

    pcs
    crm
    crm_mon
    crm_verify
    crm_simulate
    crm_shadow
    crm_resource
    crm_attribute
    crm_node
    crm_standby
    cibadmin
    corosync.conf
    authkey
    corosync-cfgtool
    corosync-cmapctl
    corosync-quorumtool
    stonith_admin

Pacemaker architecture and components (CIB, CRMd, PEngine, LRMd, DC, STONITHd)

Uma pequena introdução:

  • O Pacemaker precisa ser configurado de forma diferente, dependendo da distribuição. Chamamos cada combinação de Pacemaker + corosync (ou heartbeat) uma Stack "pilha".
  • No RHEL6 a stack suportada é baseada no CMAN que tem APIs Pacemaker que podem ser usadas para obter as informações de membros e quorum quando necessário. Embora o CMAN use corosync por baixo, ele é configurado via cluster.conf e o Pacemaker é iniciado como um script de inicialização separado.
  • O SLES11 não suporta CMAN, então seus usuários configuram corosync.conf diretamente e permitem um plugin personalizado que será carregado no corosync (porque corosync 1.4 não tem as APIs de quórum e de membros necessários para o Pacemaker). Este plugin também começa o Pacemaker automaticamente quando corosync é iniciado. Usuários SLES iniciam o corosync com o script de inicialização OpenAIS porque ele é utilizado por ser parte desse projeto.
  • Eventualmente todo mundo vai mudar para corosync 2 (RHEL7), que remove o suporte para Cman e plugins personalizados mas nativamente inclui a APIs Pacemaker necessárias para quorum e membership.
  • Há algumas diferenças de arquitetura entre as diferentes pilhas, e algumas são mais elegante do que outras, mas a coisa mais importante, é que todos estão pegando informações de quorum e membership a partir do mesmo lugar.
Definição de Pacemaker: Pacemaker é um gestor de recursos de cluster, ou seja, a lógica responsável pelo ciclo de vida do software implantando (indiretamente mesmo sistemas inteiros e suas interconexões) sobre seu controle dentro de um conjunto de computadores e conduzidos por regras prescritas. Ele alcança a alta disponibilidade para os seus serviços de cluster por detecção e recuperação de falhas (a nível de NÓ e Recursos) fazendo o uso de recursos de mensagens fornecidos por sua infra-estrutura de cluster preferencial, através do Corosync.
  • Arquitetura do Pacemaker
right

Em um alto nível, o custer é formado pelas seguintes partes:

    • Non-cluster-aware components: Estas partes incluem os recursos próprios; scripts para iniciar, parar e monitorar, e um daemon local que mascara as diferenças entre os diferentes padrões para implementar esses scripts. Apesar de interações desses recursos quando executados como várias instâncias pode assemelhar-se a um sistema distribuído, eles ainda não têm os mecanismos apropriados de HA e/ou governança de todo o cluster autônomo como englobado no item seguinte.
    • Resource management: O Pacemaker fornece o cérebro que processa e reage a eventos relacionados ao cluster. Estes eventos incluem nós que entram ou saem do cluster; eventos de recursos causadas por falhas, manutenção e atividades programadas; e outras ações administrativas. Pacemaker irá calcular o estado ideal do cluster e traçar um caminho para alcançá-lo depois de qualquer um desses eventos. Isso pode incluir a transferência de recursos, parando os nós e até mesmo forçá-los para ficarem offline com power switches remotos.
    • Low-level infrastructure: Projetos como Corosync, CMAN e Heartbeat provê mensagens confiáveis, filiação (membership) e informações de quorum sobre o cluster.
  • Componentes internos do Pacemaker:
O Pacemaker é composto por cinco componentes chaves:
    • Cluster Information Base (CIB)
    • Cluster Resource Management daemon (CRMd)
    • Local Resource Management daemon (LRMd)
    • Policy Engine (PEngine or PE)
    • Fencing daemon (STONITHd)
Detalhes dos componentes internos:
    • O CIB usa XML para representar tanto as configurações do cluster como o estado atual de todos os recursos (resources) no cluster. O conteúdo do CIB é automaticamente mantido em sincronia entre os clusters e é utilizado pelo PEngine para computar o 'estado ideal' do cluster e como fazer para alcançá-lo. A lista de instruções é então alimentada para o Designated Controller (DC). O Pacemaker centraliza todas as decisões, elegendo uma instância CRMd para agir como master. Se o processo CRMd eleito falha, um novo (master) é rapidamente estabelecido.
    • O DC executa as instruções do PEngine na ordem estabelecida, passando então para o daemon Local Resource Management (LRMd) ou para o CRMd se as ações devem ser executadas em outro nó. Esta conexão entre CRMd's é feita via cluster messaging infrastructure. O CRMd do outro nó por sua vez passa as instruções para o processo LRMd Local.
|NO-01 <LRMd> <--> <CRMd>| <--> |<CRMd> <--> <LRMd> NO-02|
    • Todos os nós reportam suas operações de volta para o DC e baseado na expectativa de resultado e do atual resultado, irá executar algumas ações, como precisar aguardar, ou abortar processo e pedir para PEgine para recalcular o estado ideal do cluster baseado nos resultados inesperados. E muitos casos, é necessário desligar nós para proteger dados compartilhados. Para isso o Pacemaker utiliza o STONITHd.
    • STONITH é um acronimo para "Atire na cabeça do outro nó" (Shoot-The-Other-Node-In-The-Head), uma prática recomendada quando um nó não se comporta de forma adequada, ele é prontamente isolado (desligado, corte de recursos compartilhados ou outra forma de isolamento), e é usualmente implementada com um power switch remoto. No Pacemaker, dispositivos STONITH são modelados como recursos (e configurados no CIB) para habilitar que sejam facilmente monitorados por falha, no entanto STONITHd cuida de compreender a topologia STONITH de tal forma que seus clientes simplesmente solicitam para que um nó seja cercado, e ele faz o resto.
  • Fontes:

Pacemaker cluster configuration

  • Devemos configurar antes do Pacemaker o programa de sincronização de informações chamdo corosync,
. Criar relação de confiança
# pcs cluster auth node01 node02

. Configurar o Corosync
# pcs cluster setup --name meucluster node01 node01
  • Após isto seguir com as configurações do Pacemaker.
  • Configurando Pacemaker:
. Comando de verificação de configuração atual
# crm_verify -L -V

. Comando para exibir as configurações atuais
# pcs cluster cib
  • Tipos de clusters:
A configuração do pacemaker suporta praticamente qualquer tipo de configuração de redundância, incluindo Active/Active, Active/Passive, N+1, etc.
    • Active/Passive: Utilizando o Pacemaker e o DRBD é uma ótima solução de alta disponibilidade.
    • Ao suportar muitos nós, o Pacemaker pode reduzir drasticamente os custos de hardware, permitindo vários clusters active/passive, combinados e compartilhando um nó de backup comum.
    • Quando um Storage está disponível, cada nó pode potencialmente ser usado como failover, O Pacemaker pode rodar várias copias do serviço para espalhar a carga estre os nós.
  • Fontes:

Resource classes (OCF, LSB, Systemd, Upstart, Service, STONITH, Nagios)

O papel de um agente de recursos (resource agent) é abstrair o serviço que presta e apresentar uma visão consistente ao cluster, que permite que o cluster não precise ter todo o conhecimento sobre os recursos que gere. O cluster não precisa entender como o recurso funciona porque ele depende do agente do recurso para fazer a coisa certa quando são dados os comandos stop, start ou monitor.

  • Estas são as classes de agentes suportadas pelo Pacemaker:
    • OCF
    • LSB
    • Upstart
    • Systemd
    • Service
    • Fencing
    • Nagios Plugins
  • O padrão OCF é basicamente uma extensão das convenções do Linux Standard Base para init scripts para:
    • Suporte de parâmetros
    • Torná-los auto-descritivos
    • Torná-los extensíveis
As especificações OCF têm definições estritas dos códigos de saída que as ações devem retornar. O cluster segue exatamente essas especificações. O cluster deve saber diferenciar entre um código de saída errado ou um código de saída de serviço parado.
  • O Recurso LSB pode ser encontrado em /etc/init.d Geralmente eles são fornecidos pela distribuição do S.O. a fim de ser utilizado no cluster. Para o correto funcionamento estes scripts devem estar no padrão LSB.
  • O recurso Systemd é um substituto do SysV O pacemaker pode utilizar os arquivos chamados unit files para gerenciar os serviços do cluster usando Systemd
  • O recurso Upstart é um substituto do SysV O pacemaker pode utilizar os chamados jobs para gerenciar os serviços do cluster usando Upstart
  • O pacemaker suporta a utilização do Service para gerenciamento dos serviços, através de uma utilização inteligente, tentando identificar o tipo de gerenciador de serviços utilizado pelo nó, na seguinte ordem: Primeiro scripts LSB/init.d, SystemD/UnitFile e por fim Job Upstart
  • O Plugin Nagios Nos permite monitorar serviços em um host remoto. O Pacemaker é capaz de fazer o monitoramento remoto com os plugins, se estiverem presentes. Um caso de uso comum é para configurá-los como recursos que pertencem a um contêiner de recursos (Uma maquina virtual) e o contêiner será reiniciado se houver falha.
  • Sobre o STONITH: Só porque um nó não está respondendo, isso não significa que não está acessando seus dados. A única maneira de ter 100% de certeza de que seus dados estão seguros, é usar STONITH para que possamos ter certeza de que o nó está realmente off-line, antes de permitir que os dados sejam acessados a partir de outro nó. STONITH também tem um papel a desempenhar no caso em que um serviço do cluster não pode ser interrompido. Neste caso, o cluster utiliza STONITH para forçar o desligamento do nó inteiro, tornando-o seguro para iniciar o serviço em outro lugar.
    • O STONITH pode ser iniciado pelo pacemaker ou por outras partes do cluster (tais como recursos como DRBD ou DLM). Para acomodar isto, o pacemaker não necessita que o recurso STONITH esteja no estado iniciado.
  • Opções dos recursos: http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html/Pacemaker_Explained/primitive-resource.html
  • Adicionando um recurso para ser monitorado no Pacemaker
# pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=192.168.90.180 cidr_netmask=24 op monitor interval=15s

. Onde:
.. ClusterIP: é o nome do recurso
.. ocf: é o recurso padrão de scripts. O comando "# pcs resource standards" exibe os padrões
.. heartbeat: É um recurso padrão específico para OCF. O comando "# pcs resource providers" exibe os padrões disponíveis OCF
.. ipaddr2: É o nome do script do recurso. O comando "# pcs resource agents ocf:heartbeat" exibe uma lista dos scripts disponíveis para o recurso.

* Monitorar um recurso criado:
# pcs status
  • Testar a falha do cluster e o consequente redirecionamento de recursos
# pcs cluster standby <NODE>

. Para retornar
# pcs cluster unstandby <NODE>

Resource rules and constraints (location, order, colocation)

Algumas definições importantes dentro do pacemaker vinculadas ao uso dos serviços ou recursos são as constraints e rules, elas definem através de sub-comandos o local onde o recurso será iniciado, a ordem de inicialização, se um conjunto de recursos deverão rodar juntos em um mesmo nó, assim como regras complementares que deixam a configuração do cluster ainda mais flexível, baseadas e tempo por exemplo. Cada ferramenta de administração utiliza estes conceitos de uma forma. Abaixo vamos apresentar os conceitos e a aplicação conforme o uso no crm ou pcs

  • Scores: Os Scores são calculados com base nos recursos, e qualquer nó com um resultado negativo para um recurso não pode correr esse recurso. Depois de calcular as pontuações (score) para um recurso, o cluster, em seguida, escolhe o nó com a pontuação mais alta.
    • Há duas estratégias para especificar em quais nós um dos recursos pode ser executado.
      • Opt-out: Por padrão, eles podem ser executados em qualquer lugar e, em seguida, criar restrições de localização para nós que não são permitidos.
      • Opt-in: Nenhum recurso pode rodar em qualquer lugar, em seguida ativar seletivamente os nós permitidos para execução do recurso.
. Exemplo de configuração de cluster Opt-IN
# pcs property set symmetric-cluster=false
  • Location: Utilizada para definir em qual nó o recurso ou um grupo de recursos será inicializado preferencialmente.
    • Exemplo de definição de Location usando crm 
# crm configure location HTTP_Server GrupodoServidor 100: no02
    • Exemplo de definição de Location usando pcs 
. pcs constraint location rsc avoids node[=score] ...

# pcs constraint location Webserver prefers example-1=200
  • Order: Utilizado para determinar a ordem que o recurso irá rodar. Pode ser configurado (dentro do constraint) para definir a ordem de inicialização e parada do recurso. Também é configurada a dependência entre recursos, um não inicializa antes de outro inicializar.
. pcs constraint order [action] resource_id then [action] resource_id [options]
.. Para inicializar na sequencia os serviços, utilizar:
# pcs constraint order set D1 D2 D3
  • Colocation: Determina que a localização de um recurso depende da localização de outro recurso
. Exemplo de utilização do colocation
.. pcs constraint colocation add [master|slave] source_resource with [master|slave] target_resource [score] [options]

# pcs constraint colocation add myresource1 with myresource2 score=INFINITY
  • Rules: Os rules são utilizados para tornar as configurações mais dinâmicas. Regras associadas a horários de migração de recursos é um exemplo. Cada regra pode conter um número de expressões ou até outras regras.
. pcs constraint rule add <constraint id> [id=<rule id>] [role=master|slave] [score=<score>|score-attribute=<attribute>] <expression>

.. Exemplo de configuração de rule definindo como verdadeira a expressão durante o ano de 2015
# pcs constraint location Webserver rule score=INFINITY date-spec years=2015
  • Exemplo geral:
. Priorizar WebDataClone e depois executar WebFS
# pcs -f fs_cfg constraint colocation add WebFS with WebDataClone INFINITY with-rsc-role=Master
# pcs -f fs_cfg constraint order promote WebDataClone then start WebFS

. Exibir informações de constraints
# pcs -f fs_cfg constraint show

Advanced resource features (templates, groups, clone resources, multi-state resources)

Algumas características avançadas dos resources no Pacemaker.

  • Resource Templates: Auxilia na tarefa de criação de muitos recursos com configurações semelhantes. Após a criação de um recurso do tipo template, ele pode ser referenciado utilizando o recurso primitive. Um dos exemplos é o uso para migração de maquinas virtuais, onde podemos ter várias maquinas virtuais com poucas alterações entre elas.
Exemplo de XML Template Xen: 
---
<template id="vm-template" class="ocf" provider="heartbeat" type="Xen">
​  <meta_attributes id="vm-template-meta_attributes">
​    <nvpair id="vm-template-meta_attributes-allow-migrate" name="allow-migrate" value="true"/>
​  </meta_attributes>
​  <utilization id="vm-template-utilization">
​    <nvpair id="vm-template-utilization-memory" name="memory" value="512"/>
​  </utilization>
​  <operations>
​    <op id="vm-template-monitor-15s" interval="15s" name="monitor" timeout="60s"/>
​    <op id="vm-template-start-0" interval="0" name="start" timeout="60s"/>
​  </operations>
​</template>
---

Exemplo de XML com resource primitive apontando para o template criado anteriormente. 

---
<primitive id="vm1" template="vm-template">
​  <instance_attributes id="vm1-instance_attributes">
​    <nvpair id="vm1-instance_attributes-name" name="name" value="vm1"/>
​    <nvpair id="vm1-instance_attributes-xmfile" name="xmfile" value="/etc/xen/shared-vm/vm1"/>
​  </instance_attributes>
​</primitive>
---
  • Resource Groups: Os grupos foram criados com o objetivo de facilitar a configuração de dependência entre serviços(recursos) e localização dos mesmos. Ou seja, podemos criar um grupo e nele colocar os recursos que são necessários as suas execuções em conjunto, assim como a definição da ordem de inicialização dos mesmos no grupo. O comando para adicionar os grupos é pcs resource group add 
. pcs resource group add <group name> <resource id> [resource id] ... [resource id] [--before <resource id> | --after <resource id>] [--wait[=n]]

.. Pode utilizar --before ou --after para especificar a posição dos recursos adicionais relativamente a algum recurso já existente no grupo. Se --wait for 
especificado, o pcs vai esperar até 'n' segundos para mover o recurso, em seguida, retornar 0 se os recursos forem movidos, 
ou 1 se os recursos ainda não foram movidos.
  • Clone Resource: Recurso que se ativa em vários hosts. Utilizado por uma gama de recursos como o OCFS2. Pode-se clonar qualquer recurso. Existem três tipos de cloned resources:
    • Anonymous: O mais simples. Os recursos comportam-se de forma completamente idênticas em todos os lugares que estão executando. Devido a isso, pode haver apenas uma cópia de um clone anonymous ativo por máquina.
    • Globally unique: São entidades distintas. cópia de um clone rodando em uma maquina não é equivalente a outra instância em outro nó. Nem duas cópias no mesmo nó são equivalentes.
    • Stateful: Convertida em Multi-state resource
  • Multi-state resource: Recurso que tem vários modos. Permite que as instâncias podem estar em um de dois modos (chamados roles). Os modos são chamados master e slave. Uma limitação é que quando uma instância inicia ele deve vir com o estado slave.
Exemplo de criação de um recurso com a opção de Multi-state: 
# pcs resource create resource_id standard:provider:type|type [resource options] --master [meta master_options]

Pacemaker management using pcs

  • Comandos utilizados para configuração inicial de um cluster simples, através da configuração do corosync:
. Adiciona usuario autenticado entre os nós do cluster
# pcs cluster auth pcmk-1 pcmk-2

. Configura cluster entre os nós e cria arquivo de configuração corosync configurado
# pcs cluster setup --name meucluster pcmk-1 pcmk-2

. Iniciar o Cluster
# pcs cluster start --all

. Verificar Status
# pcs cluster status

right

  • Base de uso do pcs:
O pcs é um programa de linha de comando usado para configurar todas as opções do cluster incluindo o Corosync. A base de seu uso segue a lógica abaixo: 
# pcs
Usage: pcs [-f file] [-h] [commands]...
Control and configure pacemaker and corosync.

Options:
    -h, --help  Display usage and exit
    -f file     Perform actions on file instead of active CIB
    --debug     Print all network traffic and external commands run
    --version   Print pcs version information

Commands:
    cluster     Configure cluster options and nodes
    resource    Manage cluster resources
    stonith     Configure fence devices
    constraint  Set resource constraints
    property    Set pacemaker properties
    acl         Set pacemaker access control lists
    status      View cluster status
    config      View and manage cluster configuration
  • Uma das práticas comuns é antes de aplicar novas alterações diretamente na configuração vigente do Pacemaker, aplicá-la como teste em uma configuração extraída da configuração em funcionamento, e executar os testes. Para fazer isto, deve-se extrair as configurações atuais de cluster e recurso conforme procedimento abaixo:
* Criar arquivo XML teste com a configuração de Pacemaker atual:
# pcs cluster cib teste

* Fazer as alterações no arquivo de teste:
# pcs -f teste resource create WebFS Filesystem device="/dev/drbd1" directory="/var/dados" fstype="xfs"

* Verificar o status diretamente o arquivo teste
# pcs -f teste status

* Comitar as alterações do arquivo teste na configuração padrão
# pcs cluster cib-push teste

Pacemaker management using crmsh

O crmsh começou como uma interface incluída ao gerenciador de clusters Pacemaker, mas tem crescido além de simplesmente configurar Pacemaker para lidar com muitos mais aspectos da pilha Linux HA. Ela também serve como o back-end para a interface web Hawk.

Comandos utilizados:

  • Comando crm:
. Status do Cluster
# crm status

. Saúde das maquinas do cluster
# crm cluster health

. Adicionar um recurso
# crm configure primitive p0 Dummy

.. Adicionar um recuro específico
crm configure primitive ClusterIP ocf:heartbeat:IPaddr2  \
               params ip=192.168.9.101 cidr_netmask=32 \
               op monitor interval=30s

.. Listar ocf's disponíveis
# crm ra list ocf heartbeat

. O comando crm sem argumento leva a uma sessão interativa
# crm
  • Comando crm_mon: Provê um sumário com informações sobre o estado atual do cluster.
  • Comando crm_verify: Verifica a configuração completa de sintaxe e erros conceituais comuns. 
. Verifica a consistência da configuração que esta rodando no cluster:
# crm_verify −−live−check

. Verifica a consistência de configuração de um arquivo XML:
# crm_verify −−xml−file file.xml −−verbose
  • Comando crm_simulate: Ferramenta para simulação de resposta do cluster a eventos.
  • Comando crm_shadow: Define-se um ambiente no qual as ferramentas de configuração (cibadmin, crm_resource, etc) trabalham off-line em vez de rodarem em um cluster ativo, permitindo visualizar mudanças e testar os efeitos colaterais.
. Criar uma configuração shadow de um cluster que esteja rodando:
# crm_shadow −−create myShadow
  • Comando crm_resource: Executa tarefas relacionadas aos recursos do cluster. Permite que os recursos sejam consultados, modificado e movidos no Cluster.
. Lista os recursos configurados:
# crm_resource −−list

. Move myResource para uma maquina específica:
# crm_resource −−resource myResource −−move −−node altNode

. Exibe a localização atual de ´MyResource':
# crm_resource −−resource myResource −−locate
  • Comando crm_attribute: Gerencia os atributos dos nós e opções do cluster. 
. Altera o valores de 'location' atribuído ao node 'myhost': 
# crm_attribute −−node myhost −−name location −−update backoffice

. Deleta o atributo do node 'location' do host 'myhost':
# crm_attribute −−node myhost −−name location −−delete

. Pesquisa o valor da opção cluster-delay:
# crm_attribute −−type crm_config −−name cluster−delay −−query

Configuration and Management of corosync in conjunction with Pacemaker

  • comandos de configuração do Corosync usando pcs:
. Sincronizar autenticação dos nós
# pcs cluster auth pcmk-1 pcmk-2

. Gerar e sincronizar as configurações do corosync
# pcs cluster setup --name mycluster pcmk-1 pcmk-2
  • Comandos de monitoramento Corosync:
. Exibe o status da conexão atual
# corosync-cfgtool -s

. Detalhes de configuração
# corosync-cmapctl

. Informações de votos dos membros
# pcs status corosync
  • Arquivo /etc/corosync/corosync.conf: Gerado automaticamente pelos comandos acima. 
. Exemplo de um arquivo simples 
# cat /etc/corosync/corosync.conf
--
totem {
version: 2
secauth: off
cluster_name: meucluster
transport: udpu
}

nodelist {
  node {
        ring0_addr: ov-centos-ha01
        nodeid: 1
       }
  node {
        ring0_addr: ov-centos-ha02
        nodeid: 2
       }
}

quorum {
provider: corosync_votequorum
two_node: 1
}

logging {
to_syslog: yes
}
--

Awareness of other cluster engines (OpenAIS, Heartbeat, CMAN)

  • OpenAIS: É uma implementação do Aplication Interface Specification (AIS) provido pelo Service Availability Forum. Ele é uma camada de mensagem e membership (filiação) assim como o heartbeat. O OpenAis implementa um padrão de industria para esta troca de mensagens, dizendo ao pacemaker que um nó faz parte do cluster e fornece uma maneira de enviar mensagem entre eles.
  • HeartBeat: É um daemon que também provê a infraestrutura do cluster, mensagem e membership (filiação), permitindo que os clientes saibam sobre a presença ou o desaparecimento de pares, trocando mensagem entre eles. O heartbeat necessita de uma camada superior de gerenciamento de cluster chamada de CRM para funcionar completamente.
  • CMAN: É um plugin ligado ao Corosync que monitora o nome e o número de nodes ativos no cluster, entregando informações de membership e quorum aos clientes. O CMAN é considerado um cluster manager e roda em cada nó. A escolha de utilizar o CMAN ao invés do daemon Pacemaker, muitas vezes é necessária devido a compatibilidade com algum software (como o GFS2 por exemplo). A RedHat busca uma compatibilidade com o CMAN em sua pilha de cluster.
  • Fontes:

Fontes do objetivo Pacemaker:

334.4_High_Availability_in_Enterprise_Linux_Distributions

Objetivos do Tópico

Peso: 1

Description: Candidates should be aware of how enterprise Linux distributions integrate High Availability technologies. Key Knowledge Areas: 

    Basic knowledge of Red Hat Enterprise Linux High Availability Add-On
    Basic knowledge of SUSE Linux Enterprise High Availability Extension

Terms and Utilities: 

    Distribution specific configuration tools
    Integration of cluster engines, load balancers, storage technology, cluster filesystems, etc.

Basic knowledge of Red Hat Enterprise Linux High Availability Add-On

A Redhat fornece um add-on para adicionar funcionalidades de Alta disponibilidade ao RedHat Enterprise Linux. Este Add-on que é adquirido separadamente possui as seguintes características:

  • Cluster Manager: Até a versão Enterprise 6 utilizava o CMAN para distribuição do gerenciamento de cluster através de todos os nós do cluster. A partir da versão Enterprise 7 o CMAN foi substituído pelo Pacemaker. O Cluster manager também administra a filiação (membership) e monitora a atividade do cluster para remover nós com falhas caso necessário. Para comunicação entre os nós é utilizado o Corosync, que entre outras características implementa o protocolo "Totem Single Ring Ordering"
  • Lock Management: é uma serviço de infra estrutura do cluster que provê um mecanismo para os componentes de infra estrutura de cluster para sincronizar o seu acesso a recursos compartilhados. O DLM (Distributed Lock Manager) roda em cada nó do cluster e de forma eficiente, distribui 'lock management' através de todos os nós do cluster. Utilizado geralmente em conjunto com o GFS2
  • Fencing: Se um nó é identificado com falha, o nó é automaticamente cortado para fora do storage compartilhado no cluster. este procedimento é chamado de fencing. O Add-on inclui uma variedade de métodos de fencing. Um nó pode ser configurado para um ou vários metodos de fencing.
  • Command-Line Cluster Configuration (CSS): O CSS permite usuários e não somente privilégios de root, administrar o cluster. Foi substituído pelo comando pcs na versão Enterprise 7 e pelo programa gráfico pcsd.
  • Conga - Administração de cluster por interface Web: Neste Add-on, o gerenciamento do cluster pode ser feito por interface Web, através do conga, que é uma ferramenta que trabalha na lógica cliente/servidor, onde o agente (chamado de ricci) sofre a conexão do servidor de aplicação (chamado de luci). Através da amigável interface Web, é possível adicionar clusters, sistema de storages, entre outras tarefas administrativas.
right

Basic knowledge of SUSE Linux Enterprise High Availability Extension

A Suse Linux utiliza a extensão High Availability para implementar as tecnologia de cluster e alta disponibilidade em seu produto SUSE Linux Entreprise. Esta extensão é tanto uma Interface Gráfica de usuário como interface por linha de comando. Além disso ela possui a possibilidade de configuração por Web utilizando o chamado HA Web Konsole (Hawk). As características principais da extensão são:

  • Corosync/OpenAIS: Utilizados como camada de comunicação entre os nós.
  • Pacemaker: Utilizado para gerenciamento do cluster
  • Suporta CTDB; Cluster Trivial Database
  • Por padrão utiliza o OCFS2 como sistema de arquivo distribuído.
  • Suporte a cluster em locais físicos diferentes:
      • Local Clusters: Em um mesmo datacenter
      • Metro Clusters: Múltiplos datacenters conectados por canal de fibra (latência abaixo de 5ms)
      • Geo Clusters (Multi-sites): Geograficamente disperso. O Storage é replicado de forma assincrona
  • Ferramentas de administração do cluster:
    • Pacemaker Gui: Ferramenta gráfica para facilitar o gerenciamento do cluster
    • HA Web Konsole (Hawk): Criação e configuração de recursos através de inferface WEB right
    • crm shell: Poderoso e unificado interface de linha de comando para administrar, monitorar e gerenciar todas as tarefas do cluster.
  • Fontes:

Fonte

  • https://access.redhat.com/documentation/pt-BR/Red_Hat_Enterprise_Linux/6/html/Cluster_Administration/index.html
  • https://alteeve.ca/w/AN!Cluster_Tutorial_2
Clone this wiki locally