Visão Geral dos Complementos de Alta Disponibilidade

Transcrição

Red Hat Enterprise Linux 6
Visão Geral dos Complementos de
Alta Disponibilidade
Visão Geral dos Complementos de Alta Disponibilidade para o Red Hat
Enterprise Linux
Edição 6
Red Hat Enterprise Linux 6 Visão Geral dos Complementos de Alta
Disponibilidade
Visão Geral dos Complementos de Alta Disponibilidade para o Red Hat
Enterprise Linux
Edição 6
Nota Legal
Co pyright © 20 14 Red Hat, Inc. and o thers.
This do cument is licensed by Red Hat under the Creative Co mmo ns Attributio n-ShareAlike 3.0
Unpo rted License. If yo u distribute this do cument, o r a mo dified versio n o f it, yo u must pro vide
attributio n to Red Hat, Inc. and pro vide a link to the o riginal. If the do cument is mo dified, all Red
Hat trademarks must be remo ved.
Red Hat, as the licenso r o f this do cument, waives the right to enfo rce, and agrees no t to assert,
Sectio n 4 d o f CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shado wman lo go , JBo ss, MetaMatrix, Fedo ra, the Infinity
Lo go , and RHCE are trademarks o f Red Hat, Inc., registered in the United States and o ther
co untries.
Linux ® is the registered trademark o f Linus To rvalds in the United States and o ther co untries.
Java ® is a registered trademark o f Oracle and/o r its affiliates.
XFS ® is a trademark o f Silico n Graphics Internatio nal Co rp. o r its subsidiaries in the United
States and/o r o ther co untries.
MySQL ® is a registered trademark o f MySQL AB in the United States, the Euro pean Unio n and
o ther co untries.
No de.js ® is an o fficial trademark o f Jo yent. Red Hat So ftware Co llectio ns is no t fo rmally
related to o r endo rsed by the o fficial Jo yent No de.js o pen so urce o r co mmercial pro ject.
The OpenStack ® Wo rd Mark and OpenStack Lo go are either registered trademarks/service
marks o r trademarks/service marks o f the OpenStack Fo undatio n, in the United States and o ther
co untries and are used with the OpenStack Fo undatio n's permissio n. We are no t affiliated with,
endo rsed o r spo nso red by the OpenStack Fo undatio n, o r the OpenStack co mmunity.
All o ther trademarks are the pro perty o f their respective o wners.
Resumo
Visão Geral do Co mplemento de Alta Dispo nibilidade — Fo rnece uma visão geral do
Co mplemento de Alta Dispo nibilidade para o Red Hat Enterprise Linux 6 ..
Índice
Índice
⁠I.nt
. .rodução
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . .
⁠1. Co nvenç õ es d e Do c umento s
3
⁠1.1. Co nvenç õ es Tip o g ráfic as
4
⁠1.2. Co nvenç õ es d e Pull-Q uo te
5
⁠1.3. No tas e Avis o s
6
⁠2 . Prec is amo s d o s eu Feed b ac k!
6
. .apít
⁠C
. . . ulo
...1
. .. .Visão
. . . . .G. eral
. . . . dos
. . . .Complement
. . . . . . . . . . .os
. . .de
. . Alt
. . .a. Disponibilidade
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. . . . . . . . . .
⁠1.1. Bás ic o s d e Clus ter
8
⁠1.2. Intro d uç ão ao Co mp o nente d e Alta Dis p o nib ilid ad e
9
⁠1.3. Infraes trutura d o c lus ter
10
. .apít
⁠C
. . . ulo
...2
. .. .G. erenciament
. . . . . . . . . . .o. .de
. . Clust
. . . . .er
. . com
. . . .o
. .CMAN
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1. 1. . . . . . . . . .
⁠2 .1. Q uo rum d e Clus ter
11
⁠2 .1.1. Dis c o s d e q uo rum
⁠2 .1.2. Tie-b reakers
12
12
. .apít
⁠C
. . . ulo
. . . 3.
. . RG
. . . Manager
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1. 4. . . . . . . . . .
⁠3 .1. Do mínio s d e failo ver
14
⁠3 .1.1. Exemp lo s d e Co mp o rtamento
15
⁠3 .2. Po lític as d e Serviç o
16
⁠3 .2.1. Po lític a d e Inic iaç ão
16
⁠3 .2.2. Po lític a d e rec up eraç ão
16
⁠3 .2.3. Extens õ es d e Po lític a d e Reinic iaç ão
16
⁠3 .3. Árvo res d e Rec urs o s - Bás ic o s / Definiç õ es
17
⁠3 .3.1. Relac io namento s d e Pai / Filho , Dep end ênc ias e O rd em d e Iníc io
17
⁠3 .4. O p eraç õ es d e Serviç o e Es tad o s
18
⁠3 .4.1. O p eraç õ es d o s Serviç o s
18
⁠3 .4.1.1. A O p eraç ão freez e
18
⁠3 .4.1.1.1. Co mp o rtamento d o Serviç o q uand o Co ng elad o
18
⁠3 .4.2. Es tad o s d o Serviç o
19
⁠3 .5. Co mp o rtamento s d e Máq uina Virtual
19
⁠3 .5.1. O p eraç õ es No rmais
19
⁠3 .5.2. Mig raç ão
20
⁠3 .5.3. Rec urs o s d a Máq uina Virtual RG Manag er
20
⁠3 .5.3.1. Ras treamento d e Máq uina Virtual
⁠3 .5.3.2. Sup o rte d e Do mínio Trans iente
⁠3 .5.3.2.1. Rec urs o s d e G erenc iamento
⁠3 .5.4. Co mp o rtamento não manip ulad o
⁠3 .6 . Aç õ es d e Rec urs o
⁠3 .6 .1. Valo res d e Reto rno
20
21
21
21
21
21
. .apít
⁠C
. . . ulo
...4
. .. .Fencing
. . . . . . . (Isolament
. . . . . . . . . o)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. 3. . . . . . . . . .
. .apít
⁠C
. . . ulo
. . . 5.
..G
. .erenciament
. . . . . . . . . . .o. de
. . . Bloqueio
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2. 8. . . . . . . . . .
⁠5 .1. Mo d elo d e Blo q ueio d e DLM
28
⁠5 .2. Es tad o s d e Blo q ueio
29
. .apít
⁠C
. . . ulo
...6
. .. .Ferrament
. . . . . . . . as
. . .de
. . .Configuração
. . . . . . . . . . . .e. Administ
. . . . . . . . ração
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
...........
⁠6 .1. Ferramentas d e Ad minis traç ão d o Clus ter
30
. .apít
⁠C
. . . ulo
...7
. .. .Virt
. . .ualiz
. . . .ação
. . . . .e. Alt
. . .a. Disponibilidade
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
...........
⁠7 .1. VMs c o mo Rec urs o s d e Alta Dis p o nib ilid ad e/Serviç o s
32
⁠7 .1.1. Rec o mend aç õ es G erais
33
1
Visão G eral dos Complement os de Alt a Disponibilidade
⁠7 .2. Clus ters d e Co nvid ad o s
33
34
⁠7 .2.1. O us o d o fenc e_s c s i e iSCSI Shared Sto rag e
36
36
. .pêndice
⁠A
. . . . . . . A.
. . Hist
. . . .órico
. . . . .de
. . .Revisões
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
...........
2
⁠Int rodução
Introdução
Este documento fornece uma visão geral de alto nível do High Availability Add-On para o Red Hat
Enterprise Linux 6.
Embora as informações deste documento sejam uma visão geral, você deve possuir conhecimento
avançado do Red Hat Enterprise Linux e entender os conceitos de computação de servidor para
compreender bem as informações.
Para mais informações sobre como usar o Red Hat Enterprise Linux, consulte os seguintes recursos:
Guia de Instalação do Red Hat Enterprise Linux — Fornece informações sobre a instalação do Red
Hat Enterprise Linux 6.
Guia de Implantação do Red Hat Enterprise Linux — Fornece informações sobre a implantação,
configuração e administração do Red Hat Enterprise Linux 6.
Para maiores informações sobre este e os produtos relacionados ao Red Hat Enterprise Linux 6,
consulte os seguintes recursos:
Configurando e Gerenciando o Complemento de Alta Disponibilidade Provê informações sobre a
configuração e gerenciamento do Complemento de Alta D isponibilidade (High Availability AddOn também conhecido como Red Hat Cluster) para o Red Hat Enterprise Linux 6.
Administrador do Gerenciador de Volume Lógico — Fornece uma descrição do Gerenciador de
Volume Lógico (LVM), incluindo informações sobre como executar o LVM em um ambiente de
cluster.
Sistema de Arquivo Global 2: Configuração e Administração— Fornece informações sobre instalação,
configuração e manutenção do Red Hat GFS2 (Red Hat Global File System 2), o qual está
incluso no Resilient Storage Add-On (Adição de Armazenamento Resiliente).
DM Multipath — Fornece informações sobre o uso do recurso D evice-Mapper Multipath do Red Hat
Enterprise Linux 6.
Administração do Balanceador de Carga — Fornece informações sobre a configuração dos sistemas
de alto desempenho e serviços com o Red Hat Load Balancer Add-On (Formalmente conhecido
como Linux Virtual Server [LVS]),
Notas de Lançamento — Fornece informações sobre os lançamentos atuais dos produtos da Red
Hat.
Nota
Para obter informações sobre as melhores práticas de implementação e atualização dos
clusters do Red Hat Enterprise Linux, utilizando o Complemento de Alta D isponiblidade e
Sistema de Arquivo Global da Red Hat 2 (GFS2), consulte o artigo Red Hat Enterprise Linux
Cluster, High Availability, e GFS D eployment Best Practices" no Red Hat Customer Portal em .
https://access.redhat.com/kb/docs/D OC-40821.
Este documento e outros documentos do Red Hat, estão disponíveis nas versões HTML, PD F e RPM
no CD de documentação do Red Hat Enterprise Linux no site
http://access.redhat.com/documentation/docs.
1. Convenções de Document os
3
Este manual usa diversas convenções para destacar certas palavras e frases e chamar atenção às
informações específicas.
1.1. Convenções T ipográficas
São usadas quatro convenções tipográficas para realçar palavras e frases específicas. Estas
convenções, e circunstâncias a que se aplicam, são as seguintes:
Neg ri to Espaço Úni co (Mono-spaced Bold)
Usada para realçar entradas do sistema, incluindo comandos de shell, nomes de arquivos e
caminhos. São também usadas para realçar teclas Maiúsculas/Minúsculas e as combinações de
teclas. Por exemplo:
Para ver o conteúdo do arquivo my_next_bestsel l i ng _no vel em sua pasta de
trabalho atual, insira o comando cat my_next_bestsel l i ng _no vel na janela
de solicitação e pressione Enter para executar o comando.
O comando acima inclui um nome de arquivo, um comando de shell e uma tecla, todos
apresentados em Negrito Espaço Único (Mono-spaced Bold) e todos distintos, graças ao conteúdo.
As combinações de tecla podem ser diferenciadas de uma tecla individual pelo sinal positivo que
conecta cada parte da combinação da tecla. Por exemplo:
Pressione Enter para executar o comando.
Pressione C trl +Al t+F2 para trocar ao terminal virtual.
A primeira sentença, destaca uma tecla específica a ser pressionada. A segunda destaca duas
combinações de teclas: um conjunto de três teclas pressionadas simultaneamente.
Caso o código fonte seja discutido, os nomes de classe, métodos, funções, nomes de variantes e
valores retornados mencionados em um parágrafo serão apresentados como acima em Neg ri to
d e Espaço Úni co (Mo no -spaced Bo l d ). Por exemplo:
As classes baseadas em arquivo incluem fi l esystem para sistemas de arquivo,
fi l e para arquivos e d i r para diretórios. Cada classe possui seu conjunto próprio
de permissões associadas.
N eg rit o Pro p o rcio n al
Esta convenção representa as palavras e frases encontradas no sistema, incluindo os nomes de
aplicativos, texto de caixa de diálogo, botões rotulados, caixa de seleção e rótulos de botão de
opção, títulos de menus e submenus. Por exemplo:
Selecione Sist ema → Pref erên cias → Mo u se a partir da barra do menu principal
para lançar as Pref erên cias d o Mo u se. Na aba Bo tõ es, selecione a opção
Bo tão d a esq uerd a d o mo use e clique em Fechar com o objetivo de mudar o
botão inicial do mouse da esquerda para a direita (tornando o mouse adequado
para o uso na mão esquerda).
Selecione Ap licat ivo s → Acessó rio s → Map a d e C aract ere a partir da barra de
menu principal, com o objetivo de inserir um caractere especial ao arquivo g ed it . Em
seguida, selecione B u scar → En co n t rar… a partir da barra do menu Map a d e
C aract ere, digite o nome do caractere no campo Buscar e clique em P ró xi ma. O
caractere pesquisado aparecerá destacado na T abel a d e C aractere. Clique
duas vezes no caractere destacado para posicioná-lo no campo T exto para
có pi a e clique no botão C o pi ar. Retorne ao seu documento e selecione Ed it ar →
C o lar a partir da barra do menu g ed it .
4
⁠Int rodução
O texto acima inclui nomes de aplicativos, nomes de menu e itens de todo o sistema, nomes de menu
específicos do aplicativo, além de botões e textos encontrados na interface GUI (Graphical User
Interface), todos apresentados em Negrito Proporcional (Proportional Bold) e todos diferenciados
de acordo com o contexto.
Itálico em Negrito de Espaço Único (Mono-spaced Bold Italic) ou Itálico em
Negrito Proporcional (Proportional Bold Italic)
Independente de ser o Negrito Espaço Único (Mono-spaced Bold) ou o Negrito Proporcional
(Proportional Bold), os itálicos extras indicam textos substituíveis ou variáveis. O Itálico denota o
texto que você não inseriu literalmente ou textos exibidos que mudam dependendo das
circunstâncias. Por exemplo:
D igite ssh nome do usuário@ domain.name na janela de comandos, com o
objetivo de conectar-se à uma máquina remota usando o ssh. Por exemplo,
considere que a máquina remota seja exampl e. co m e seu nome de usuário nesta
máquina seja john, digite ssh jo hn@ exampl e. co m.
O comando mo unt -o remo unt file-system remonta o sistema de arquivo
nomeado. Por exemplo, para remontar o sistema de arquivo /ho me, o comando é
mo unt -o remo unt /ho me.
Use o comando rpm -q package com o objetivo de visualizar a versão de um
pacote instalado. Isto irá retornar um resultado como parecido com: packageversion-release.
Verifique as palavras em negrito e itálico acima - username, domain.name, file-system, package,
version e release. Cada palavra é um espaço reservado, tanto para o texto que você insere quando
emitindo um comando ou para textos exibidos pelo sistema.
Além de uso padrão para apresentar o título de um trabalho, os itálicos denotam a primeira vez que
um termo novo e importante é usado. Por exemplo:
O Publican é um sistema de publicação do DocBook.
1.2. Convenções de Pull-Quot e
As listagens de código fonte e resultado de terminal são definidas visualmente com base no
contexto.
O resultado enviado ao terminal é configurado em R o mano d e Espaço Úni co (Mo no -spaced
R o man) e apresentado como o seguinte:
books
books_tests
Desktop
Desktop1
documentation drafts mss
downloads
images notes
photos
scripts
stuff
svgs
svn
As listas de código fonte também são configuradas em R o mano d e Espaço Úni co (Mo no spaced R o man), porém são apresentadas e realçadas conforme abaixo:
static int kvm_vm_ioctl_deassign_device(struct kvm *kvm,
struct kvm_assigned_pci_dev *assigned_dev)
{
int r = 0;
struct kvm_assigned_dev_kernel *match;
mutex_lock(& kvm->lock);
5
match = kvm_find_assigned_dev(& kvm->arch.assigned_dev_head,
assigned_dev->assigned_dev_id);
if (!match) {
printk(KERN_INFO "%s: device hasn't been assigned
before, "
"so cannot be deassigned\n", __func__);
r = -EINVAL;
goto out;
}
kvm_deassign_device(kvm, match);
kvm_free_assigned_device(kvm, match);
out:
mutex_unlock(& kvm->lock);
return r;
}
1.3. Not as e Avisos
Finalmente, usamos três estilos visuais para chamar a atenção às informações que possam passar
despercebidas.
Nota
Uma nota é uma dica ou símbolo, ou ainda uma opção alternativa para a tarefa em questão.
Caso ignore uma nota, provavelmente não resultará em más consequências, porém uma dica
importante (que poderá facilitar a sua vida) poderá passar despercebida.
Importante
Caixas " importante" descrevem detalhes que facilmente passam despercebidos como
alterações de configuração que somente se aplicam à sessão atual, ou serviços que
precisam ser reiniciados antes que uma atualização seja efetuada. Caso ignore estas caixas
importantes, não haverá perda de dados, porém isto poderá causar irritação e frustração.
Atenção
Um aviso não deve ser ignorado. Caso ignore avisos, provavelmente ocorrerá perda de
dados.
2. Precisamos do seu Feedback!
6
⁠Int rodução
Se você encontar um erro de digitação neste manual ou se você pensou numa maneira de fazer este
manual melhor, nós gostaríamos de saber! Por favor envie um relatório no Bugzilla:
http://bugzilla.redhat.com/ para o produto R ed H at En t erp rise Lin u x6 , o componente docHigh_Availability_Add-On_Overview e número de versão: 6 . 6 .
Se você tem uma sugestão para melhorar esta documentação, tente ser o mais específico possível
ao descrevê-la. Se você encontrou um erro, inclua o número da seção e um pouco do texto dele,
para que possamos encontrar com mais facilidade.
7
Capítulo 1. Visão Geral dos Complementos de Alta
Disponibilidade
O Complemento de Alta D isponibilidade é um sistema em cluster que fornece a confiabilidade,
escalabilidade e disponibilidade para serviços de produção crítica. As seções a seguir fornecem
uma descrição de alto nível dos componentes e funções do Componente de Alta D isponibilidade:
Seção 1.1, “ Básicos de Cluster”
Seção 1.2, “ Introdução ao Componente de Alta D isponibilidade”
Seção 1.3, “ Infraestrutura do cluster”
1.1. Básicos de Clust er
Um cluster são dois ou mais computadores (chamados de nodes or members) que funcionam juntos
para realizarem uma tarefa. Existem quatro tipos principais de clusters:
Armazenamento
Alta D isponibilidade
Balanceamento de Carga
Alto D esempenho
Clusters de armazenamento fornecem uma imagem de sistema de arquivos consistente em todos os
servidores em um cluster, permitindo que os servidores leiam e gravem ao mesmo tempo em um
único sistema de arquivos compartilhado. Um cluster de armazenamento simplifica a administração
de armazenamento, limitando a instalação e correção de aplicações para um sistema de arquivos.
Além disso, com um sistema de arquivos em todo o cluster, um cluster de armazenamento elimina a
necessidade de cópias redundantes de dados de aplicativos e simplifica o backup e recuperação
de desastres. O High Availability Add-On fornece agrupamento de armazenamento em conjunto com
Red Hat GFS2 (parte do Componente de Armazenamento Resiliente).
Clusters de alta disponibilidade fornecem serviços altamente disponíveis, eliminando pontos únicos
de falha e serviços de failover a partir de um nó de cluster para outro no caso de um nó tornar-se
inoperante. Normalmente, os serviços em um cluster de alta disponibilidade de leitura e gravação de
dados (através de leitura e gravação de sistemas de arquivos montados). Portanto, um cluster de
alta disponibilidade deve manter a integridade dos dados quando um nó de cluster assumir o
controle de um serviço de um outro nó do cluster. As falhas de nós em um cluster de alta
disponibilidade não são visíveis por clientes de fora do cluster. (clusters de alta disponibilidade são
muitas vezes referidos como clusters de failover.) O High Availability Add-On oferece alta
disponibilidade de agrupamento por meio de seu componente de Gerenciamento de Serviços de Alta
D isponibilidade, rg manag er.
Clusters de balanceamento de carga despacham pedidos de serviços de rede para vários nós do
cluster para balancear a carga de pedido entre os nós do cluster. O balanceamento de carga
fornece escalabilidade custo-benefício, porque você pode combinar o número de nós de acordo
com os requisitos de carga. Se um nó em um cluster de balanceamento de carga tornar-se
inoperante, o software de balanceamento de carga detecta a falha e redireciona as solicitações para
outros nós do cluster. As falhas de nós em um cluster de balanceamento de carga não são não ser
vistas por clientes de fora do cluster. O balanceamento de carga está disponível com o Load
Balancer Add-On (Componente de Balanceador de Carga).
8
⁠Capít ulo 1 . Visão G eral dos Complement os de Alt a Disponibilidade
Clusters de alto desempenho usam os nós do cluster para realizar cálculos simultâneos. Um cluster
de alto desempenho permite que os aplicativos funcionem em paralelo, melhorando assim o
desempenho das aplicações. (Clusters de alto desempenho também são referidos como clusters
computacionais ou computação em grade.)
Nota
Os tipos de cluster resumidos no texto anterior reflete configurações básicas; você pode
precisar de uma combinação de clusters descritas para atender às suas necessidades.
Além disso, o Red Hat Enterprise Linux High Availability Add-On contém somente suporte para
confiugração e gerenciamento de servidores de alta disponibilidade . Ele não suporta clusters
de alto desempenho.
1.2. Int rodução ao Component e de Alt a Disponibilidade
O Componente de Alta D isponibilidade é um conjunto integrado de componentes e software que
pode ser implementado em diversas configurações para atender às suas necessidades de
desempenho, alta disponibilidade, balanceamento de carga, escalabilidade, compartilhamento de
arquivo e economia.
O Componente de Alta D isponibilidade consiste nos seguintes componentes principais:
Infra-estrutura de Cluster — Fornece funções fundamentais para nós funcionarem juntos como
um cluster: gerenciamento de configuração de arquivo, gerenciamento de associação,
gerenciamento de bloqueio e fencing.
Gerenciamento de Serviço de Alta D isponibilidade — Fornece failover de serviços de um nó de
cluster para outro no caso do nó se tornar inoperante.
Ferramentas de administração de cluster — Ferramentas de Configuração e Gerenciamento para
instalar, configurar e gerenciar um Componente de Alta D isponibilidade. As ferramentas são
utilizadas com os componentes de infra-estrutura do Cluster, a alta disponibilidade e os
componentes de Gerenciamento de Serviços, e armazenamento.
Nota
Somente clusters de locais únicos são suportados neste momento. Clusters espalhados por
múltiplas localidades físicas não são formalmente suportados. Para mais detalhes e para
discutir sobre cluster em múltiplas locações, por favor converse com seu representante de
vendas ou suporte Red Hat.
Você pode suplementar o Componente de Alta D isponibilidade com os seguintes componentes:
Red Hat GFS2 (Global File System 2) — Parte do Componente de Armazenamento Resiliente, ele
fornece um sistema de arquivos de cluster para uso com o High Availability Add-On. O GFS2
permite que múltiplos nós compartilhem armazenamento em nível de bloco como se o
armazenamento fosse conectado localmente para cada nó do cluster. O GFS2 sistema de
arquivos de cluster requer uma infra-estrutura de cluster.
Cluster Logical Volume Manager (CLVM) — Parte do Componente de Armazenamento Resiliente,
ele fornece gerenciamento de volume de armazenamento de cluster. O suporte do CLVM também
9
requer infra-estrutura de cluster.
Componente de Balanceador de Carga — O software de roteamento que fornece o
balanceamento de Carga IP. O Componente de Balanceador de Carga é executado em um par de
servidores virtuais redundantes que distribuem requisições de cliente de formaigual para
servidores reais que estão atrás dos servidores virtuais.
1.3. Infraest rut ura do clust er
A infra-estrutura do cluster do Componente de Alta D isponibilidade fornece as funções básicas de
um grupo de computadores (chamado nós ou membros ) para trabalhar juntos como um cluster.
Uma vez que um cluster é formado usando a infra-estrutura de cluster, você pode usar outros
componentes para atender às suas necessidades de agrupamento (por exemplo, a criação de um
cluster para o compartilhamento de arquivos em um sistema de arquivos GFS2 ou a criação de
failover do serviço). A infra-estrutura de cluster executa as seguintes funções:
Gerenciamento de Cluster
Gerenciamento de Bloqueio
Fencing
Gerenciamento de Configuração de Cluster
10
⁠Capít ulo 2 . G erenciament o de Clust er com o CMAN
Capítulo 2. Gerenciamento de Cluster com o CMAN
Gerenciamento de cluster gerencia o quorum do cluster e adesão do cluster. CMAN (uma abreviação
para o gerenciador de cluster) realiza gerenciamento de cluster no High Availability Add-On para
Red Hat Enterprise Linux. CMAN é um gerenciador de clusters distribuído e é executado em cada nó
do cluster; o gerenciamento de cluster é distribuído entre todos os nós do cluster.
CMAN mantém o controle da adesão, monitorando mensagens de outros nós do cluster. Quando a
associação do cluster muda, o gerenciador de cluster notifica os outros componentes de infraestrutura, que, em seguida, tomam as medidas necessárias. Se um nó de cluster não transmite uma
mensagem dentro de um período de tempo prescrito, o gerenciador de cluster remove o nó do cluster
e se comunica com outros componentes da infra-estrutura de cluster que o nó não é membro. Outros
componentes de infra-estrutura de cluster determinam quais as ações a tomar sobre a notificação de
que o nó não é mais um membro do cluster. Por exemplo, o Fencing cercaria o nó que não é mais
um membro.
CMAN mantém o controle de quorum do cluster, monitorando a contagem dos nós do cluster. Se
mais da metade dos nós estiverem ativos, o cluster tem quorum. Se metade dos nós (ou menos)
estiverem ativos, o cluster não tem quorum, e todas as atividades do cluster serão interrompidas. O
quorum do Cluster impede a ocorrência de uma condição de " split-brain" (dupla personalidade) uma condição em que duas instâncias do mesmo cluster estão em execução. A condição de dupla
personalidade permite que cada instância de cluster acesse recursos do cluster sem o
conhecimento da outra instância de cluster, resultando em integridade do cluster corrompida.
2.1. Quorum de Clust er
Quorum é um algorítimo de voto utilizado pelo CMAN.
Um cluster só pode funcionar corretamente se não houver um acordo geral entre os membros sobre
o seu status. D izemos que um cluster tem quorum se a maioria de nós estiver em atividade,
comunicando-se e concordar com os membros do cluster ativos. Por exemplo, num conjunto de
treze nós de cluster, o quorum é apenas alcançado se sete ou mais nós estiverem se comunicando.
Se o sétimo nó morrer, o cluster perde quorum e já não poderá mais funcionar.
Um cluster deve manter quorum para evitar problemas de dupla personalidade . Se o quorum não foi
forçado, um erro de comunicação no mesmo grupo de treze nós poderá causar uma situação onde
seis nós estão operando no armazenamento compartilhado, enquanto outros seis nós também
estão operando nele, de forma independente. Por causa do erro de comunicação, os dois clusters
parciais substituiriam áreas do disco e corromperiam o sistema de arquivos. Com as regras de
quorum aplicadas, apenas um dos conjuntos parciais poderá usar o armazenamento
compartilhado, protegendo, assim, a integridade dos dados.
O quorum não previne situações de dupla personalidades, mas ele decide quem é dominante e
pode funcionar no cluster. Caso a dupla personalidade aconteça, o quorum previne mais de um
grupo de cluster de fazer qualquer coisa.
O quorum é determinado pela comunicação de mensagens entre os nós do cluster através de
Ethernet. Opcionalmente, o quorum pode ser determinada por uma combinação de comunicação de
mensagens através de Ethernet e através de um disco de quorum. Para quorum via Ethernet, o
quorum consiste de uma simples maioria (50% dos nós adicionais + 1). Ao configurar um disco de
quorum, o quorum é constituído por condições especificadas pelo usuário.
11
Nota
Por padrão, cada nó possui um voto de quorum. Opcionalmente, você pode configurar cada
nó para ter mais de um voto.
2.1.1. Discos de quorum
O disco de quorum ou partição é uma seção de um disco que está configurada para uso com
componentes do projeto de cluster. Ele possui alguns propósitos. Novamente, irei explicar utilizando
um exemplo.
Suponha que você tem os nós A e B, e um nó não consegue obter vários pacotes " Heartbeat" do
gerenciador de clusters de nó B. O nó A não sabe porque não recebeu os pacotes, mas existem
várias possibilidades: ou o nó B falhou, o switch de rede ou hub falhou, adaptador de rede de um
nó falhou, ou talvez apenas porque nó B estava ocupado demais para enviar o pacote. Isso pode
acontecer se o cluster é extremamente grande, seus sistemas são extremamente ocupados ou se a
sua rede é flakey.
Um nó não sabe qual é o caso, e não sabe se o problema está dentro de si mesmo ou com nó B. Isto
é especialmente problemático em um cluster de dois nós, porque ambos os nós, fora de contato com
o outro, podem tentar cercar o outro.
Portanto, antes de cercar um nó, seria bom ter uma outra maneira de verificar se o outro nó está
realmente em atividade, mesmo que não consiga entrar em contato com ele. Um disco de quorum lhe
dá a capacidade de fazer exatamente isso. Antes de isolar um nó que esteja fora de controle, o
software de cluster pode verificar se o nó ainda está em atividade para saber se ele tem gravado os
dados para a partição de quorum.
No caso do sistema de dois nós, o disco do quorum também age como um tie-breaker. Se um nó
possui acesso ao disco de quorum e a rede, isto conta como dois votos.
Um nó que tenha perdido contato com a rede ou o disco de quorum perdeu um voto, e portanto
pode ser cercado com segurança.
Para informações detalhadas sobre como configurar parâmetros de disco de quorum consulte o
capítulo correspondente no Conga e na administração ccs no manual do Cluster Administration.
2.1.2. T ie-breakers
Tie-breakers são heurísticas adicionais que permitem uma partição de cluster decidir se é ou não é
quórum no caso de um even-split - antes do fencing. A construção de tie-breaker típico é um IP tiebreaker, às vezes chamado de um nó de ping.
Com tal critério de tie-breaker, nós não só monitoraram uns aos outros, como também um roteador
de upstream que está no mesmo caminho que as comunicações de cluster. Se os dois nós perderem
o contacto com o outro, o que ganha é aquele que ainda puder pingar o roteador montante. É claro,
há casos, como por exemplo um interruptor de circuito, onde é possível que dois nós vejam o
roteador de upstream - mas não um ao outro - causando o que é chamado de dupla personalidade
(split brain). É por isso que, mesmo quando se utiliza tie-breakers, é importante assegurar que o
fencing está configurado corretamente.
Outros tipos de tie-breakers incluem onde uma partição compartilhada, muitas vezes chamada de
disco de quorum, fornece detalhes adicionais. O clumanager 1.2.x (Red Hat Cluster Suite 3) tinha
um disco de tie-breaker que permitia que a operação se a rede caisse, enquanto os dois nós ainda
estávam se comunicando sobre a partição compartilhada.
12
⁠Capít ulo 2 . G erenciament o de Clust er com o CMAN
Existem esquemas de tie-breaker mais complexos, comoQD isk (parte do linux-cluster). Qdisk permite
que uma heurística arbitrária seja especificada. Estes permitem que cada nó determine a sua própria
aptidão para a participação no cluster. Porém, ele é frequentemente usado como um simples IP tiebreaker. Veja a página de manual do qdisk(5) para mais informações.
O CMAN não possui tie-breakers internos por diversas razões. No entanto, os tie-breakers podem
ser implementados utilizando o API. Este API permite o registro de dispositivo do quorum e
atualização. Por exemplo, veja o código de fonte do QD isk.
Você pode precisar de um tie-breaker se você:
Tiver uma configuração de dois nós com os dispositivos de fence em um caminho de rede
diferente do caminho utilizado para a comunicação de cluster.
Tiver uma configuração de dois nós onde o fencing está no nível de fábrica - especialmente para
reservas de SCSI.
No entanto, se você tiver uma configuração de fencing e rede correta em seu cluster, um tie-breaker
adiciona somente complexidade, exceto em casos patológicos.
13
Capítulo 3. RGManager
Rgmanager administra e fornece recursos de failover para coleções de recursos de cluster
chamados de serviços, grupos de apoio ou árvores de recursos. Estes grupos de recursos são
estruturadas em árvores, e possui dependência entre pais e filhos e as relações de herança dentro
de cada sub-árvore.
A maneira como o rgmanager funciona, é que ele permite aos administradores definir, configurar e
monitorar os serviços de cluster. No caso de uma falha de nó, o rgmanager muda o serviço de
cluster para outro nó com a interrupção do serviço mínimo. Você também pode restringir os serviços
para determinados nós, tal como restringir httpd para um grupo de nós enquanto mysq l pode
ser restringido a um conjunto separado de nós.
Existem diversos processos e agentes que juntos fazem o RGManager funcionar. A lista a seguir
resume estas áreas.
D omínios de failover - Como funciona o sistema de domínio do failover de RGManager
Políticas de Serviços - A inicialização do serviço do Rgmanager e políticas de recuperação
Árvores de Recursos - Como as árvores de recurso do rgmanager funcionam, incluindo as
ordens e heranças de iniciar e interromper.
Comportamentos Operacionais de Serviço - Como as operações do rgmanager funcionam e o
que significa estado.
Comportamentos de Máquina Virtual - Coisas especiais a se lembrar ao executar os VMs em um
cluster de rgmanager.
ResourceActions - As ações de agente que o RGManager utiliza e como padronizar seus
comportamentos a partir do arquivo cl uster. co nf.
Event Scripting - Se o failover do rgmanager e políticas de recuperação não se encaixarem em
seu ambiente, você pode padronizar seu próprio utilizando o subsistema de scripting.
3.1. Domínios de failover
Um domínio de failover é um sub-conjunto ordenado de membros com o qual um serviço deve ser
vínculado. Os domínios de failover, apesar de úteis para a padronização de cluster, não são
requeridos para a operação.
Segue uma lista de semânticas que governam as opções de como as opções de configuração
diferentes afetam o comportamento de um domínio de failover.
nó preferido ou membro preferido: O nó preferido era o membro designado para executar um
determinado serviço se o membro estiver online. Podemos imitar esse comportamento
especificando um desordenadas, domínio failover irrestrito de exatamente um membro.
domínio restrito: Serviços ligados ao domínio só pode ser executado em membros do cluster, que
também são membros do domínio failover. Se nenhum membro do domínio de failover está
disponível, o serviço é colocado no estado interrompido. Em um cluster com diversos membros,
usar um domínio de failover restringido pode facilitar a configuração de um serviço de cluster (tal
como httpd), que requer uma configuração idêntica em todos os membros que executam o
serviço. Ao invés de configurar o cluster inteiro para executar o serviço de cluster, você deve
configurar somente os membros do domínio de failover restringidos que você associa com o
serviço de cluster.
14
⁠Capít ulo 3. RG Manager
domínio irrestrito: o comportamento padrão, serviços ligados a este domínio pode ser executado
em todos os membros do cluster, mas será executado em um membro do domínio, sempre que
estiver disponível. Isto significa que se um serviço está sendo executado fora do domínio e um
membro do domínio vem on-line, o serviço vai migrar para esse membro, a menos que o
nofailback seja definido.
domínio ordenou: A ordem especificada na configuração dita a ordem de preferência dos
membros dentro do domínio. O membro mais graduado do domínio irá executar o serviço sempre
que estiver online. Isto significa que, se um membro tem uma posição mais elevada do que
membro B, o serviço irá migrar para um se ele estava correndo em B se transições A partir de
offline para online.
ordenada de domínio: O comportamento padrão, os membros do domínio não tem ordem de
preferência, qualquer membro pode executar o serviço. Serviços sempre migrar para os membros
do seu domínio de falha, sempre que possível, no entanto, um domínio não ordenada.
failback: Serviços de membros de um domínio de failover ordenado falhar volta para o nó que
estava originalmente rodando antes do nó falhou, o que é útil para muitas vezes não nós para
evitar mudanças freqüentes de serviços entre o nó falhar eo nó de failover.
Ordenação, restrição, e nofailback são bandeiras e podem ser combinadas em qualquer forma (por
exemplo, ordenados + restrita, desordenada + livre, etc.) Estas combinações afetar tanto onde os
serviços de começar após a formação do quorum inicial e que os membros do cluster vai assumir os
serviços no caso em que o serviço falhou.
3.1.1. Exemplos de Comport ament o
D ado um cluster deste conjunto de membros: {A, B, C, D , E, F, G}.
O rd en ad o , d o mín io d e f ailo ver rest rit o {A, B , C }.
Com nofailback unset: Um serviço de 'S' será sempre executado em member 'A' sempre
member 'A' está on-line e não há quórum. Se todos os membros de {A, B, C} estão offline, o
serviço não será executado. Se o serviço está sendo executado em 'C' e transições 'A' online, o serviço vai migrar para 'A'.
Com o nofailback configurado: Um serviço de 'S' será executado no membro de cluster de
maior prioridade quando um quorum se formar. Se todos os membros de {A, B, C} estiver
offline, o serviço não será executado. Se o serviço estiver sendo executado em 'C' e 'A'
transitar on-line, o serviço permanecerá em 'C' a menos que 'C' falhe, o qual fará um fail
over em 'A'.
D eso rd en ad o , d o mín io d e f ailo ver rest rit o {A, B , C }.
Um serviço 'S' será executado somente se existir um quorum e ao menos um membro de {A,
B, C} estiver online. Se outro membro do domínio transitar online, o serviço não será
realocado.
O rd en ad o , d o mín io d e f ailo ver irrest rit o {A, B , C }.
Com nofailback não configurado: Um Serviço de 'S' será, executado sempre que existir um
quorum. Se um membro do domínio failover estiver online, o serviço será executado no
membro de mais alta prioridade, caso contrário um membro de cluster será escolhido
aleatóriamente para executar o serviço. Ou seja, o serviço irá executar em 'A' sempre que
'A' estiver online, seguido de 'B'.
Com set nofailback: Um serviço de 'S' será executado sempre que há um quorum. Se um
membro do domínio de failover está disponível online em formação de quorum, o serviço
15
será executado no membro mais prioridade do domínio de failover. Ou seja, se 'B' está online (mas 'A' não é), o serviço será executado em 'B'. Se, em algum momento mais tarde, 'A'
se junta ao cluster, o serviço não vai mudar para 'A'.
D eso rd en ad o , d o mín io d e f ailo ver irrest rit o {A, B , C }.
Isso também é chamado de um " Conjunto de Membros Preferidos" . Quando um ou mais
membros do domínio failover estiverem on-line, o serviço será executado em um membro
on-line não específico do domínio de failover. Se outro membrode domínio de failover
transitar on-line, o serviço não muda.
3.2. Polít icas de Serviço
RGManager possui três serviços de políticas de recuperação que podem ser padronizados pelo
administrador por serviço.
Nota
Estas políticas também se aplicam à recursos de máquina virtual.
3.2.1. Polít ica de Iniciação
O RGManager por padrão, inicia todos os serviços quando inicializa o rgmanager e um quorum é
apresentado. Este comportamento pode ser alterado pelos administradores.
autostart - (padrão) - inicia o serviço quando o rgmanager inicializa e se forma um quorum. Se
definido para '0', o cluster não iniciará o serviço e ao invés disso o alocará para estado
desativado.
3.2.2. Polít ica de recuperação
A política de recuperação é a ação padrão que o rgmanager toma quando um serviço falha em um
nó específico. Existem três opções disponíveis, definidas na seguinte lista.
restart (padrão) - reinicie o serviço no mesmo nó. Caso não haja nenhuma outra política de
recuperação especificada, esta política de recuperação será usada. Se o restart falhar, o
rgmanager toma seu lugar para realocar o serviço.
relocate - Tente iniciar o serviço em outro nó(s) no cluster. Caso nenhum outro nó inicie com
sucesso o serviço, o serviço será então colocado em estado de interrompido.
disable - Não faça nada. Coloque o serviço no estado de desabilitado.
restart-disable - Tente reiniciar o serviço, no local. Coloque o serivço no estado de desabilitado
caso o restart falhe.
3.2.3. Ext ensões de Polít ica de Reiniciação
Quando a política de recuperação de reinicialização é usada, você pode ainda especificar um limite
máximo para o número de reinicializações que podem ocorrer no mesmo nó em um determinado
momento. Há dois parâmetros disponíveis para os serviços chamados max_restarts e
restart_expire_time que controlam este.
16
O parâmetro max_restarts é um inteiro que especifica o número máximo de reiniciações antes de
desistir e realocar o serviço para um outro host no cluster.
O parâmetro restart_expire_time instrui o rgmanager quanto tempo lembrar um evento do restart.
O uso de dois parâmetros juntos cria uma janela móvel para um número de reiniciações toleradas
em um período de tempo específico. Por exemplo:
<service name="myservice" max_restarts="3" restart_expire_time="300" ...>
...
</service>
A tolerância do serviço acima é de 3 reinicia em 5 minutos. Na quarta falha de serviço em 300
segundos, o rgmanager não reiniciará o serviço a não ser que realoque o serviço para outro host
disponível em um cluster.
Nota
Você deve especificar ambos parâmetros juntos; o uso de um dos parâmetros por si só é
indefinido.
3.3. Árvores de Recursos - Básicos/ Definições
Estes a seguir ilustram a estrutura de uma árvore de recurso, com uma lista correspondente que
define cada área.
<service name="foo" ...>
<fs name="myfs" ...>
<script name="script_child"/>
</fs>
<ip address="10.1.1.2" .../>
</service>
Árvores de recursos são representações de XML de recursos, seus atributos, relacionamentos de
pais/ filho e irmãos. A raiz da árvore de recurso é quase sempre um tipo especial de recurso
chamado de serviço. A Árvore de recurso, grupo de recurso, e o serviço são geralmente usados
intercambiavelmente nesta wiki. D a perspectiva do rgmanager, uma árvore de recurso é uma
unidade atômica. Todos os componentes de uma árvore de recurso são iniciadas em um mesmo
nó de cluster.
fs:myfs e ip:10.1.1.2 são irmãos
fs:myfs é o pai do script:script_child
script:script_child é o filho do fs:myfs
3.3.1. Relacionament os de Pai / Filho, Dependências e Ordem de Início
As regras para relacionamentos de pai/ filho na árvore de recurso são bastante simples:
Pais são iniciados antes do filho
Filhos devem todos parar antes de um pai
17
A partir destes dois, você poderia dizer que um recurso filho é dependente de seu recurso pai
Para que um recurso seja considerado em boa saúde, todos os seus filhos dependentes devem
também estar com uma boa saúde.
3.4 . Operações de Serviço e Est ados
As seguintes operações se aplicam a ambos os serviços e máquinas virtuais, exceto para a
operação de migração, que somente funciona com máquinas virtuais.
3.4 .1. Operações dos Serviços
As operações de serviço são comandos disponíveis que um usuário pode chamar para aplicar uma
das cinco ações disponíveis, definidas na lista a seguir.
enable — inicia o serviço, opcionalmente, em um alvo preferencial e, opcionalmente, de acordo
com regras de domínio de failover. Na ausência de qualquer um, o host local onde clusvcadm é
executado irá iniciar o serviço. Se o início original falhar, o serviço se comporta como se fosse
solicitada uma operação de mudança (ver abaixo). Se a operação for bem sucedida, o serviço é
colocado no estado iniciado.
disable — pare o serviço e coloque-o em estado de desabilitado. Esta é a única operação
permissível quando um serviço estiver em estado de falha.
relocate — muda o serviço para outro nó. Opcionalmente, o administrador pode especificar um
nó preferencial para receber o serviço, mas a incapacidade do serviço ser executado naquele
host (por exemplo, se o serviço não for iniciado ou o anfitrião estiver offline) não impede a
mudança, e outro nó será escolhido. O Rgmanager tenta iniciar o serviço em cada nó permissível
no cluster. Se nenhum nó alvo permissível no cluster iniciar o serviço com sucesso, a realocação
irá falhar e o serviço tentará ser reiniciado no proprietário original. Se o proprietário original não
puder reiniciar o serviço, o serviço será colocado no estado interrompido.
stop — pare o serviço e coloque-o em estado de interrompido.
migrate — migra a máquina virtual para outro nó. O administrador deve especificar um nó alvo.
D ependendo da falha, uma falha de migração pode resultar com a máquina virtual no estado de
falha ou no estado iniciado no proprietário original.
3.4 .1 .1 . A Ope ração freeze
RGManager pode congelar serviços. Ao fazer isto, ele permite que usuários atualizem o rgmanager,
CMAN e qualquer outro software no sistema enquanto minimiza o down-time dos serviços
gerenciados pelo rgmanager.
Também permite a manutenção das peças de serviços rgmanager. Por exemplo, se você tem um
banco de dados e um servidor web em um único serviço rgmanager, você pode congelar o serviço
rgmanager, parar o banco de dados, realizar a manutenção, reiniciar o banco de dados, e
descongelar o serviço.
3.4 .1.1.1. C o mp o rt amen t o d o Serviço q u an d o C o n g elad o
verificação de status está desabilitada
operações de início estão desabilitadas
operações de interrupção estão desabilitadas
18
Failover não ocorrerá (até mesmo se você desligar o proprietário do serviço)
Importante
Falha ao seguir estas diretrizes podem resultar no recurso ser alocado em hosts múltiplos.
Você não deve parar todas as instãncias do rgmanager quando um serviço estiver
congelado a não ser que você planeje reiniciar os hosts antes de reiniciar o rgmanager.
Você não deve descongelar um serviço até que o proprietário reportado do serviço se
reúna ao cluster e reinicie o rgmanager.
3.4 .2. Est ados do Serviço
A lista a seguir define os estados dos serviços gerenciados pelo RGManager.
disabled — O serviço ficará em estado desabilitado até que um adiministrador rehabilite o
serviço ou que o cluster perca o quorum (neste ponto o parâmetro do autostart é avaliado). Um
administrador pode habilitar o serviço a partir deste estado.
failed — Presume-se que o serviço está morto. Este estado ocorre sempre que uma falha
operação de interrupção de recurso falha. O administrador deve verificar se não existe recursos
alocados (sistemas de arquivo montados, etc) antes de emitir uma requisição de desabilitado. A
única ação que pode tomar o lugar deste estado é desabilitar.
stopped — Quando está em estado parado, o serviço será avaliado para iniciar após o próximo
serviço ou transição de nó. Isto é uma medida temporária. Um administrador pode desabilitar ou
habilitar o serviço a partir deste estado.
recovering — O cluster está tentanto recuperar o serviço. Um administrador pode desabilitar o
serviço para prevenir a recuperação se desejado.
started — Se uma verificação de status de serviço falhar, recupere-a de acordo com a política de
recuperação do serviço. Se o host executando o serviço falhar, recupere-o seguindo o domínio
do failover e regras de serviço exclusivas. Um administrador pode realocar, parar, desabilitar e
(com máquinas virtuais) migrar o serviço a partir deste estado.
Nota
Outros estados como starti ng e sto ppi ng são estados transacionais especiais do estado
started .
3.5. Comport ament os de Máquina Virt ual
O RGManager lida com máquinas virtuais de uma maneira diferente de outros serviços não MV.
3.5.1. Operações Normais
MVs gerenciadas por um rgmanager deveriam ser administradas usando somente o clusvcadm ou
outra ferramenta com suporte a cluster. A maioria dos comportamentos são comuns com serviços
normais. Isto inclui:
19
Iniciando (ativando)
Interrompendo (desativando)
Monitoração de Status
Realocação
Recuperação
Para aprender mais sobre os serviços virtuais de alta disponibilidade, reveja o Capítulo 7,
Virtualização e Alta Disponibilidade .
3.5.2. Migração
Além das operações de serviço normais, as máquinas virtuais suportam um comportamento não
suportado por outros serviços: a migração. A migração minimiza o downtime de máquinas virtuais,
removendo o requerimento para um início/interrupção para que a mudança do local de uma
máquina virtual dentro de um cluster.
Existem dois tipos de migração suportados pelo rgmanager que são selecionados por MV (Máquina
Virtual) por atributo de migração:
live (default) — a máquina virtual continua a funcionar enquanto a maior parte do seu conteúdo
de memória são copiados para o host de destino. Isto minimiza a inacessibilidade do VM
(tipicamente bem menos de 1 segundo), em detrimento do desempenho do VM durante a
migração e a quantidade total de tempo que leva para a migração para completar.
pausa - a máquina virtual está congelada na memória enquanto o conteúdo da memória é
copiado para o host de destino. Isto minimiza a quantidade de tempo que leva para uma
migração de máquina virtual concluir.
O estilo de migração que você irá usar dependerá da disponibilidade e desempenho. Por exemplo,
a migração ao vivo pode significar 29 segundo de degradação de desempenho e um segundo de
indisponibilidade completa, enquanto uma migração pausada pode significar 8 segundos de
indisponibilidade completa e nenhuma degradação de desempenho.
Importante
Uma máquina virtual pode ser um componente de serviço, mas isto também irá desativar
todas as formas de migração e a maioria dos recursos de conveniência abaixo.
Além disso, o uso da migração com o KVM requer configuração detalhada do ssh.
3.5.3. Recursos da Máquina Virt ual RGManager
A lista a seguir da seção de diversas formas que o RGManager facilita o uso do gerenciamento de
máquinas virtuais.
3.5 .3.1 . Rast re am e nt o de Máquina Virt ual
A partir de uma máquina virtual com o cl usvcad m , se o VM já estiver em execução irá fazer com
que o rgmanager procure o cluster no VM e marque um VM como co meço u , onde quer que se
encontrem.
20
Os administradores que acidentalmente migrarem uma VM entre os nós do cluster com ferramentas
não-cluster, como vi rsh farão com que o rgmanager busque o cluster para o VM e marque a VM
como i ni ci ad o onde quer que seja encontrado.
Nota
Se a VM estiver sendo executada em múltiplos locais, o RGManager não o avisará.
3.5 .3.2 . Supo rt e de Do m ínio T ransie nt e
Rgmanager suporta máquinas virtuais transientes que são suportadas pelo libvirt. Isto possibilita
que o rmanager crie e remova máquinas virtuais rapidamente, ajudando a reduzir a possibilidade
de duplo início de máquinas virtuais para o uso de ferramentas de não cluster.
Suporte de máquinas virtuais transientes também possibilitam que você armazene os arquivos de
descrição do libvirt XML em um sistema de arquivo em cluster, para que você não tenha que manter
manualmente o /etc/l i bvi rt/q emu em sincronia por todo o cluster.
3.5.3.2.1. R ecu rso s d e G eren ciamen t o
Adicionar ou remover uma MV de um cluster.conf não iniciará ou interromperá a MV, irá
simplesmente fazer com que o rgmanager inicie ou pare de prestar atenção à MV.
Failback (movendo para um nó mais preferencial) é realizado utilizando a migração para minimizar
o tempo de inatividade.
3.5.4 . Comport ament o não manipulado
Condições a seguir e ações de usuário não são suportadas no RGManager.
Utilizando uma ferramenta não cluster (tal como uma virsh ou xm) para manipular um estado de
máquina virtual ou configuração enquanto o cluster está gerenciando uma máquina virtual.
Verificando se o estado de uma máquina virtual está bom (ex.: virsh list, virsh dumpxml).
Migrando uma MV gerenciada por cluster para um nó sem cluster ou um nó no cluster que não
está executando o rgmanager. O Rgmanager irá reiniciar a MV no local anterior, fazendo com
que duas instâncias da MV estejam em execução, resultando em travamento do sistema de
arquivo.
3.6. Ações de Recurso
O RGManager espera os seguintes valores de retorno a partir dos agentes de recurso:
start - iniciar o recurso
stop - interromper o recurso
status - verificar o estado do recurso
metadata - reportar o metadado OCF RA XML
3.6.1. Valores de Ret orno
21
OCF possui uma ampla classe de códigos de retorno para a operação de monitoramento, mas como
o rgmanager chama o estado, ele confia exclusivamente nos códigos de retorno SysV-style.
0 - su cesso
interromper após interrupção ou interromper quando não estiver em execução, deve
retornar successo
iniciar após iniciar ou iniciar quando estiver em execução deve retornar com sucesso
n o n z ero - f alh a
caso a operação interrompida retornar com valor não zero, o serviço inserirá o estado
falho e o serviço deverá ser recuperado manualmente.
22
⁠Capít ulo 4 . Fencing (Isolament o)
Capítulo 4. Fencing (Isolamento)
Fencing ou Isolamento é a desconexão de um nó do armazenamento compartilhado de cluster. O
fencing corta o I/O do armazenamento compartilhado, garantindo desta forma a integridade de
dados. A infra-estrutura de cluster desempenha isolamento através do fence daemon, fenced .
Quando um CMAN determina que um nó falhou, ele se comunica com outros componentes de cluster
de infraestrutura cujo nó falhou. O fenced , quando notificado da falha, cerca os nós falhos. Outros
componentes de infra-estrutura de cluster determinam quais ações tomar — ou seja, eles realizam
qualquer recuperação que precisa ser feita. Por exemplo, D LM e GFS2, quando notificado de uma
falha de nó, suspende a atividade até que detectem que o fenced tenha concluído o nó falho. Ao
obter a confirmação que o nó falho foi cercado, o D LM e GFS2 realizam a recuperação. O D LM
lança bloqueios de nós falhos; o GFS2 recupera a agenda de nós falhos.
O programa de isolamento (fencing) determina,a partir do arquivo de configuração de cluster, qual
método de isolamento a ser usado. Existem dois elementos chaves num arquivo de configuração de
cluster dos quais definem o método de isolamento: o agente de isolamento e o dispositivo de
isolamento. O programa de isolamento efetua uma chamada para um agente de isolamento
especificado num arquivo de configuração de cluster. O agente de isolamento, por outro lado, limita
o nó por meio de um dispositivo de isolamento. Quando o fencing for concluído, o programa de
isolamento (fencing) notificará o gerenciador de cluster.
O Complemento de Alta D isponibilidade provê uma variedade de métodos de isolamento:
Força fencing — Um método fencing que usa uma força controladora para desligar um nó
inoperante.
isolamento (fencing) de armazenamento — Um método de isolamento que desabilita a porta do
Canal de Fibra que conecta o armazenamento com um nó inoperante.
Outros isolamentos (fencing) — D iversos métodos de isolamento que desativam o I/O ou força de
um nó inoperante, incluindo bladecentres IBM, PAP, D RAC/MC, HP ILO, IPMI, IBM RSA II, e
outros.
Figura 4.1, “ Exemplo de Força Fencing ( Power Fencing)” mostra um exemplo de força fencing. No
exemplo, o programa de isolamento no nó A faz com que o controlador de potência desligue o nó D .
Figura 4.2, “ Exemplo de Isolamento de Armazenamento” mostra um exemplo de isolamento de
armazenamento. No exemplo, o programa de isolamento no nó A faz com que o Canal de Fibra
mude para desabilitar a porta para o nó D , desconectando o nó D do armazenamento.
23
Fig u ra 4 .1. Exemp lo d e Fo rça Fen cin g ( Po wer Fen cin g )
24
Fig u ra 4 .2. Exemp lo d e Iso lamen t o d e Armaz en amen t o
Especifica que um método fencing consiste na edição de um arquivo de configuração de cluster
para determinar o nome do método fencing, o agente fencing, e dispositivo fencing para cada nó
num cluster.
A forma na qual um método fencing é especificada depende se um nó possui duas fontes de
alimetanção ou diversos caminhos para o armazenamento. Se um nó possuir duas fontes de
alimentação, então o método fencing para o nó deve especificar ao menos dois dispositivos de
fencing — um dispositivo de isolamento para cada fonte de alimentação (consulte o Figura 4.3,
“ Isolando um Nó com Fonte de Alimentação D upla” ). D a mesma forma, se um nó possuir diversos
caminhos para o armazenamento de Canal de Fibra, então o método fencing para o nó deve
especificar um dispositivo de fencing para cada caminho para o armazenamento de Canal de Fibra.
Por exemplo, se um nó possui dois caminhos para o armazenamento de Canal de Fibra, o método
fencing deve especificar dois dispositivos de fencing — um para cada caminho para o
armazenamento de Canal de Fibra (consulte o Figura 4.4, “ Isolando um Nó com Conexões de Canal
de Fibra D uplas” )
25
Fig u ra 4 .3. Iso lan d o u m N ó co m Fo n t e d e Alimen t ação D u p la
26
Fig u ra 4 .4 . Iso lan d o u m N ó co m C o n exõ es d e C an al d e Fib ra D u p las
Você pode configurar um nó com um método fencing ou múltiplos métodos fencing. Quando você
configurar um nó num método fencing, este será o único método disponível para fencing aquele nó.
Quando você configurar um nó para múltiplos métodos fencing, os métodos fencing se apresentam
como um efeito cascata de um método fencing a outro, de acordo com os métodos fencing
especificados num arquivo de configuração de cluster. Se o nó falhar, este será fenced usando-se o
primeiro método especificado num arquivo de configuração de cluster para aquele nó. Caso o
primeiro método fencing não seja bem sucedido, o próximo método fencing especificado para o nó
será usado. Se nenhum dos métodos fencing forem bem sucedidos, então o fencing iniciará
novamente o primeiro método fencing especificado, e continuará laçado através de métodos
fencing, de maneira especificada no arquivo de configuração de cluster até o nó ser fenced.
Para informações detalhadas sobre como configurar dispositivo de fence (isolamento), consulte o
capítulo correspondente no manual Cluster Administration.
27
Capítulo 5. Gerenciamento de Bloqueio
Gerenciamento de Bloqueio é um serviço de infra estrutura comum que fornece um mecanismo para
outros componentes de infraestrutura de cluster para sincronizarem seus acessos para compartilhar
recursos. Em um cluster de Red Hat o D LM (D istributed Lock Manager) é o gerenciador de bloqueio.
Um gerenciador de bloqueio é um policial de trânsito que controla o acesso aos recursos do cluster,
tais como acesso ao sistema de arquivo GFS. Você precisa dele porque sem um gerenciador de
bloqueio não haveria controle sob o acesso ao seu armazenamento compartilhado, e os nós no
cluster danificariam seus próprios dados.
Como diz o nome, o D LM é um gerenciador de bloqueio distribuídos e é executado em cada nó de
cluster; o gerenciamento de bloqueio é distribuído em todos os nós no cluster. O GFS2 e CLVM usa
o bloqueio a partir do gerenciador de bloqueio. O GFS2 utiliza os bloqueios a partir do gerenciador
de bloqueio para sincronizar acesso aos metadados de sistema de arquivo (em armazenamento
compartilhado). O CLVM utiliza bloqueios a partir do gerenciador de bloqueio para sincronizar
atualizações para os volumes LVM e grupos de volume (também em armazenamento
compartilhado). Além disso, o rg manag er utiliza o D LM para sincronizar estados de serviço.
5.1. Modelo de Bloqueio de DLM
O Modelo de bloqueio de D LM fornece um conjunto rico de modos de bloqueios e ambas execuções
sincronizadas e assíncronas. Um aplicativo obtém um bloqueio em um recurso de bloqueio. Um
relacionamento 1 para N existe entre os recursos de bloqueio e os bloqueios: um único recurso de
bloqueio pode ter múltiplos bloqueios associados à ele.
Um recurso de bloqueio pode corresponder a um objeto atual, tal como um arquivo, uma estrutura
de dado, um banco de dados, ou uma rotina executável, mas não precisa corresponder a um destes
itens. O objeto que você associa com um recurso de bloqueio deermina a granularidade do
bloqueio. Por exemplo, bloquear um banco de dados todo é considerado bloqueio de alta
granularidade. Bloquear cada item em um banco de dados é considerado bloquear em
granularidade fina.
O modelo de bloqueio de D LM suporta:
Seis modos de bloqueios que aumentam o acesso restrito à um recurso
A promoção de demoção dos bloqueios através de conversão
Conclusão sincronizada de requisições de bloqueios
Conclusão assíncrona
D ados globais através de blocos de valor de bloqueio
O D LM fornece seu próprio mecanismo para suportar seus recursos de bloqueio, tais como a
comunicação inter-nó para gerenciar o tráfego de bloqueio e os protocolos de recuperação para reprioritizar bloqueios após a falha de um nó ou para migrar bloqueios quando um nó une à um
cluster. No entanto, o D LM não fornece mecanismo para realmente gerenciar o próprio cluster.
Portanto, o D LM espera operar em um cluster junto a um outro ambiente de infraestrutura de cluster
que forneça os seguintes requerimentos mínimos:
O nó é uma parte de um cluster.
Todos os nós concordam com um grupo de cluster e possuem um quorum.
Um endereço IP deve se comunicar com o D LM em um nó. Geralmente o D LM utiliza o TCP/IP
28
⁠Capít ulo 5. G erenciament o de Bloqueio
para comunicações inter-nó, as quais restringem-no a um único endereço IP por nó (através
disto pode-se tornar mais redundante utilizando o driver de vinculação). O D LM pode ser
configurado para utilizar o SCTP como seu transporte inter-nó que permite endereços múltiplos
IP por nó.
O D LM funciona com qualquer ambiente de infra-estrutura de cluster que fornece o mínimo de
requerimentos listados acima. A escolha de uma fonte aberta ou ambiente de fonte fechada é
decidido pelo usuário. No entanto, a limitação principal do D LM é a quantidade de testes realizados
com ambientes diferentes.
5.2. Est ados de Bloqueio
Um estado de bloqueio indica o estado atual de uma requisição de bloqueio. Um bloqueio está
sempre em um destes três estados:
Granted — A requisição de bloqueio foi bem sucedida e adquiriu o modo requisitado.
Converting — Um cliente tentou mudar o modo de bloqueio e o novo modo está incompatível com
um bloqueio existente.
Blocked — A requisição para um novo bloqueio não poderia ser fornecida pois existem
bloqueios conflitantes.
Um estado de bloqueio é determinado pelo seu modo requisitado e os modos de outros bloqueios
no mesmo recurso.
29
Capítulo 6. Ferramentas de Configuração e Administração
O arquivo de configuração do cluster, /etc/cl uster/cl uster. co nf especifica a configuração
do Complemento de Alta D isponibilidade. O arquivo de configuração é um arquivo XML que
descreve as seguintes características de cluster:
Nome do Cluster — Especifica o nome do cluster, nível de revisão do arquivo de configuração do
cluster, e limite de tempo das propriedades do fence utilizadas quando um nó une ao cluster ou é
cercado a partir de um cluster.
O Cluster — Especifica cada nó de cluster, especificando nome do nó, ID do nó, número de votos
de quorum, e método de isolamento para aquele nó.
D ispositivo Fence — Especifica os dispositivos de fence no cluster. Os Parâmetros variam de
acordo com o tipo de dispositivo de fence. Por exemplo, para um controlador de energia
utilizado como um dispositivo de fence, a configuração de cluster define o nome do controlador
de energia, seu endereço IP, login e senha.
Recursos Gerenciados — Especifica os recursos requeridos para criar serviços de cluster.
Recursos gerenciados incluem a definição de domínios de failover, recursos (por exemplo um
endereço IP) e serviços. Juntos os recursos gerenciados definem os serviços de cluster e
comportamento de failover dos serviços de cluster.
A configuração do cluster é automaticamente validada de acordo com o esquema de cluster no
/usr/share/cl uster/cl uster. rng durante o tempo de inicialização e quando uma
configuração é recarregada. Também, você pode validar uma configuração de cluster em qualquer
momento usando o comando ccs_co nfi g _val i d ate.
Um esquema anotado é disponível para vizualização em /usr/share/d o c/cmanX. Y . ZZ/cl uster_co nf. html (por exemplo /usr/share/d o c/cman3. 0 . 12/cl uster_co nf. html ).
A validação de configuração checa pelos seguintes erros básicos:
Validade XML — Checa que o arquivo de configuração é um arquivo XML válido.
Opções de configuração — Verifica para ter certeza que opções (elementos e atributos XML) são
vaĺidos.
Valores de Opção — Verifica que as opções contém dados válidos (limitados).
6.1. Ferrament as de Administ ração do Clust er
Gerenciar o software de Complemento de Alta D isponibilidade do Red Hat consiste em utilizar as
ferramentas de configuração para especificar o relacionamento entre os componentes de cluster. As
seguintes ferramentas de configuração do cluster estão disponíveis no Complemento de Alta
D isponibilidade do Red Hat
C o n g a — Esta é uma interface compreensiva para instalar, configurar e gerenciar o Componente
de Alta D isponibilidade da Red Hat. Consulte o Configurando e Gerenciando o Componente de Alta
Disponibilidade para obter informações sobre como configurar e gerenciar o Complemento de Alta
D isponibilidade com o C o n g a.
Luci — Este é o servidor do aplicativo que fornece a interface de usuário para o Conga. Ele
permite que os usuários gerenciem os serviços de cluster e fornece acesso para ajuda e
documentação online quando necessário.
30
⁠Capít ulo 6 . Ferrament as de Configuração e Administ ração
Ricci — Este é um serviço de daemon que gerencia a distribuição da configuração do cluster.
A configuração de passe de usuários detalha utilizando a interface Luci, e a configuração é
carregada no corosync para distribuição para nós de cluster.
A partir do lançamento do Red Hat Enterprise Linux 6.1 e posteriores, o Complemento de Alta
D isponibilidade da Red Hat fornece suporte para o comando de configuração de cluster ccs o
qual permite um administrador criar, modificar e vizualizar o arquivo de configuração
cluster.conf. Consulte o manual Cluster Administration para obter mais informações sobre a
configuração e gerenciamento do Complemento de Alta D isponibilidade com o comando ccs.
Nota
O system-co nfi g -cl uster não está disponível no RHEL 6.
31
Capítulo 7. Virtualização e Alta Disponibilidade
Várias plataformas de virtualização são suportados em conjunto com o Red Hat Enterprise Linux 6,
utilizando o Componente de Alta D isponibilidade e Componentes de Armazenamento Resiliente. Há
dois casos de uso com suporte para virtualização em conjunto com Red Hat Enterprise Linux High
Availability Add-on.
Isso se refere ao RHEL Cluster/HA executando em hosts bare metal que são utilizáveis como
plataformas de virtualização. Neste modo, você pode configurar o gerenciador de recursos de
cluster (rgmanager) para gerenciar máquinas virtuais (guests) como recursos de alta
disponibilidade.
VMs como Recursos de Alta D isponibilidade/Serviços
Clusters de Convidados
7.1. VMs como Recursos de Alt a Disponibilidade/Serviços
Ambos RHEL HA e RHEV fornecem mecanismos para fornecer máquinas virtuais HA. D ada a
sobreposição em termos de funcionalidade, o cuidado deve ser tomado para escolher o produto
certo para encaixar o seu caso de uso específico. Aqui estão algumas diretrizes a considerar ao
escolher entre RHEL HA e RHEV para fornecer HA de VMs.
Para a máquina Virtual e host físico, conta:
Se um grande número de VMs estiver se tornando HA em diversos hosts físicos, usar o RHEV
pode ser a melhor solução, pois tem algoritmos mais sofisticados para gerenciar a alocação de
VM que leva em consideração coisas como CPU de host, a memória e as informações de carga.
Se um pequeno número de máquinas virtuais estiverem se tornando HA em poucos
computadores físicos, utilizar RHEL HA pode ser a melhor solução, porque menos infra-estrutura
adicional é necessária. A solução do menor RHEL HA VM precisa de dois hosts físicos de um
cluster de dois nós. A solução do menor RHEV requer quatro nós: 2 para proporcionar HA para o
servidor RHEVM e 2 para agir como hospedeiros VM.
Não há nenhuma orientação estrita sobre quantos hosts ou máquinas virtuais seria considerado
um " grande número" . Mas tenha em mente que o número máximo de hosts em um único RHEL HA
Cluster é de 16, e que qualquer cluster com oito ou mais hosts irá precisar de uma análise da
arquitetura do Red Hat para determinar a capacidade de suporte.
Uso de máquina Virtual:
Se sua HA MVs estiverem fornecendo serviços que sejam utilizados para fornecer infraestrutura
compartilhada, utilize o RHEL HA ou RHEV.
Caso você precise fornecer serviço HA para um conjunto pequeno de serviços críticos que
estejam sendo executados dentro da MVs, utilize o RHEL HA ou RHEV.
Caso esteja pensando em fornecer infraestrutura para permitir provisionamento rápido de MVs,
você deve utilizar o RHEV.
RHEV VM HA deve ser dinâmico. Pode-se adicionar novas MVs ao 'cluster' RHEV facilmente e
é totalmente suportado.
RHEL VM HA não deve ser um ambiente altamente dinâmico. D eve-se estabelecer um cluster
com um conjunto fixo de MVs e o mesmo não deve adicionar ou remover MVs por todo o seu
tempo de vida.
32
⁠Capít ulo 7 . Virt ualiz ação e Alt a Disponibilidade
RHEL HA não deve ser usado para fornecer a infraestrutura para criar ambientes como o cloud,
devido à natureza estática da configuração do cluster assim como conta máxima baixa de nós
físicos (16 nós)
RHEL 5 suporta duas plataformas de virtualização. O Xen é suportado desde o lançamento de RHEL
5.0. No RHEL 5.4, foi introduzido o KVM.
RHEL 6 suporta somente o KVM como uma plataforma de virtualização.
RHEL 5 AP Cluster suporta ambos KVM e Xen para uso ao executar máquinas virtuais que sejam
gerenciadas pela infraestrutura do cluster host.
RHEL 6 HA suporta KVM para uso ao executar máquinas virtuais que sejam gerenciadas pela
infraestrutura do cluster host.
Estas listas incluem os cenários de implementação que são suportados atualmente por Red Hat:
RHEL 5.0+ suporta Xen junto com o RHEL AP Cluster
RHEL 5.4 apresentou suporte para máquinas virtuais do KVM como recursos gerenciados em
RHEL AP Cluster como uma Amostra de Tecnologia.
RHEL 5.5+ eleva suporte para máquinas virtuais do KVM para totalmente suportadas.
RHEL 6.0+ suporta máquinas virtuais do KVM como recursos altamente disponíveis no RHEL 6
High Availability Add-On.
RHEL 6.0+ não suporta máquinas virtuais do Xen com o RHEL 6 High Availability Add-On, pois o
RHEL 6 não suporta mais o Xen.
Nota
Para informações atualizadas e notas especiais sobre cenários de implementação
suportados, consulte a seguinte entrada do Red Hat Knowledgebase:
https://access.redhat.com/kb/docs/D OC-46375
Os tipos de máquinas virtuais que são executados como recursos gerenciados não importam.
Qualquer convidado que seja suportado pelo Xen ou KVM in RHEL pode ser usado como um
convidado altamente disponível. Isto inclui variantes do RHEL (RHEL3, RHEL4, RHEL5) e diversas
variantes do Microsoft Windows. Verifique a documentação do RHEL para encontrar a lista mais
recente de sistemas operacionais convidados suportados sob cada hipervisor.
7.1.1. Recomendações Gerais
No RHEL 5.3 e anterior a este, o rgmanager utilizava as interfaces nativas Xen para o
gerenciamento do Xen domU (convidados). No RHEL 5.4 ele passou a utilizar o libvirt tanto para
o Xen quanto para KVM hypervisors para fornecer uma interface consistente entre os dois tipos
de hypervisor. Além dessa mudança de arquitetura houveram inúmeras correções de bugs
lançados em RHEL 5.4 e 5.4.z, por isso é aconselhável atualizar seus clusters de host para, pelo
menos, os últimos pacotes RHEL 5.5 antes de configurar os serviços gerenciados do Xen.
Para obter serviços gerenciados do KVM você deve atualizar para RHEL 5.5, pois é a primeira
versão do RHEL onde esta função é totalmente suportada.
33
Sempre verifique a errata do RHEL mais recente antes de implementar um Cluster para se
certificar de que você possui os reparos mais recentes para problemas ou bugs conhecidos.
A mistura de hosts de tipos de hipervisors diferentes não é suportado. O cluster do host deve ser
baseado em todos os Xen ou todos os KVM.
A acomodação do hardware deve ser provisionado de tal forma que eles sejam capazes de
absorver convidados realocados de vários outros hosts falhos, sem causar uma série de
sobrecarga de memória ou CPUs virtuais. Se ocorrerem muitas falhas, que causem a sobrecarga
de memória de CPUs virtuais, isso pode levar a degradação do desempenho grave e falha de
cluster.
O uso direto do xm ou ferramentas libvirt (virsh, virt-manager) para gerenciar (live migrar, stop.
start) máquinas virtuais que estão sob o controle do rgmanager, não é suportado ou
recomendável, pois isso iria ignorar a pilha de gerenciamento de cluster.
Cada nome de VM deve ser de amplitude única de cluster, incluindo local-only / non-cluster VMs.
Libvirtd somente impõe nomes exclusivos em cada host . Se você clonar uma VM manualmente,
você deverá alterar o nome no arquivo de configuração do clone.
7.2. Clust ers de Convidados
Isso se refere ao RHEL Cluster / HA sendo executado dentro de convidados virtualizados em uma
variedade de plataformas de virtualização. Neste caso de uso, o RHEL Clustering / HA é usado
principalmente para fazer as aplicações em execução dentro dos convidados altamente disponíveis.
Este caso de uso é semelhante à forma como RHEL Clustering / HA sempre foi usado em hosts
tradicionais bare-metal. A diferença é que o Clustering é executado dentro de convidados em seu
lugar.
A seguir, uma lista de plataformas de virtualização e do nível de apoio disponível atualmente para a
execução de conjuntos de convidado usando RHEL Cluster / HA. Na lista abaixo, RHEL 6 Guests
abrangem tanto o High Availability (core clustering) e Resilient Storage Add-Ons (GFS2, clvmd e
cmirror).
Os Hosts RHEL 5.3+ Xen suportam totalmente a execução de clusters convidados onde os
sistemas operacionais convidados são também RHEL 5.3 ou posteriores:
Os clusters convidados do Xen podem usar tanto o fence_xvm ou fence_scsi para fencing de
convidado.
O uso do fence_xvm/fence_xvmd requer que um cluster do host esteja em execução para
suportar o fence_xvmd e o fence_xvm deve ser usado como agente de fencing convidado em
todos os convidados em cluster.
Armazenamento compartilhado pode ser fornecido pelos dispositivos de bloco
compartilhados iSCSI ou Xen salvos pelo armazenamento de bloco ou pelo armazenamento
de arquivo salvo (imagens brutas).
Hosts de RHEL 5.5+ KVM não suportam a execução de clusters de convidados.
Os Hosts RHEL 6.1+ KVM suportam totalmente a execução de clusters convidados onde os
sistemas operacionais convidados são RHEL 6.1+ ou RHEL 5.6+. RHEL 4 e não são suportados.
É permitido misturar nós de cluster bare metal com nós de cluster que sejam virtualizados.
Os clusters convidados do RHEL 5.6+ podem usar tanto o fence_xvm ou fence_scsi para
fencing de convidado.
34
Os clusters convidados do RHEL 6.1+ podem usar tanto o fence_xvm ( no pacotefencevi rt) ou fence_scsi para fencing de convidado.
Os hosts RHEL 6.1+ devem usar o fence_virtd se o cluster convidado estiver usando o
fence_virt ou fence_xvm como agente do fence. Se o cluster convidado estiver usando o
fence_scsi, não será necessário usar o fence_virtd nos hosts.
fence_virtd pode operar em três modos:
Não é permitido o modo standalone onde o host para mapear o convidado é codificado e
a migração de convidados é instantânea.
O uso do serviço Openais Checkpoint para rastrear migrações ativas de convidados em
cluster. Isto requer que um cluster de host seja executado.
Utilizando o Qpid Management Framework (QMF) fornecido pelo pacote libvirt-qpid. Ele
utiliza o QMF para rastrear migração de convidado sem requerer a presença de um cluster
de host total.
compartilhados iSCSI ou KVM salvos pelo armazenamento de bloco ou pelo armazenamento
de arquivo salvo (imagens brutas).
Red Hat Enterprise Virtualization Management (RHEV-M) versões 2.2+ e 3.0 suportam atualmente
os convidados em cluster RHEL 5.6+ e RHEL 6.1+ .
Os clusters convidados devem ser homogêneos (tanto todos os convidados RHEL 5.6+ ou
todos os convidados RHEL 6.1+).
O Fencing é fornecido pelo fence_scsi em RHEV-M 2.2+ e por ambos fence_scsi e fence_rhevm
no RHEV-M 3.0. O fencing é suportado utilizando o fence_scsi como descrito abaixo:
Uso de fence_scsi com armazenamento iSCSI é limitado a servidores iSCSI que suportam
SCSI 3 Reservas Persistentes com o comando preempt-and-abort. Nem todos os
servidores iSCSI suportam esta funcionalidade. Verifique com o seu fornecedor de
armazenamento para garantir que o servidor é compatível com o suporte do SCSI 3
Reserva Persistente. Observe que o servidor iSCSI distribuído com o Red Hat Enterprise
Linux atualmente não suporta SCSI 3 Reservas Persistentes, por isso não é adequado
para uso com fence_scsi.
VMware vSphere 4.1, VMware vCenter 4.1, VMware ESX e ESXi 4.1 suportam a execução de
clusters convidados , onde os sistemas operacionais convidados são RHEL 5.7+ ou RHEL 6.2+.
Versão 5.0 do VMware vSphere, vCenter, ESX e ESXi também são suportados; no entanto, devido
a um esquema WD SL incompleto fornecido na versão inicial do VMware vSphere 5.0, o utilitário
fence_vmware_soap não funciona na instalação padrão. Consulte o Red Hat Knowledgebase
https://access.redhat.com/knowledge/ para procedimentos atualizados para corrigir esse
problema.
Os clusters convidados devem ser homogêneos (tanto todos os convidados RHEL 5.7+ ou
todos os convidados RHEL 6.1+).
O agente fence_vmware_soap requer um VMware perl APIs de terceiros. Este pacote de
software package deve ser baixado do Website do VMware e instalado nos convidados em
cluster do RHEL .
35
Como forma alternativa, o fence_scsi pode ser usado para fornecer isolamento como descrito
abaixo.
compartilhados iSCSI ou VMware bruto.
Uso dos clusters convidados do VMware ESX usando um fence_vmware_so_ap ou fence_scsi.
Uso dos clusters convidado do Hyper-V não é suportado no momento.
7.2.1. O uso do fence_scsi e iSCSI Shared St orage
Em todos os ambientes de virtualização acima, pode-se se utilizar o fence_scsi e armazenamento
iSCSI no lugar do armazenamento compartilhado nativo e os dispositivos de fence nativo.
fence_scsi pode ser usado para fornecer fencing de E/S para armazenamento compartilhado
fornecido sob sob iSCSI se o alvo iSCSI suportar adequadamente as reservas persistentes do
SCSI 3 e o comando preempt e abort. Verifique se seu fabricante de armazenamento determina se
sua solução de iSCSI suporta a função acima.
O software servidor iSCSI distribuído com o RHEL não suporta as reservas persistentes do SCSI
3, portanto não pode ser usado com o fence_scsi. No entanto, é adequado para utilizar como
uma solução de armazenamento compartilhado no conjunto com outros dispositivos do fence
como o fence_vmware or fence_rhevm.
Ao usar o fence_scsi em todos os convidados, um cluster de host não é necessário (em casos de
uso do RHEL 5 Xen/KVM e RHEL 6 KVM Host)
Se o fence_scsi é usado como agente do fence, todo o armazenamento compartilhado deve ser
acima de iSCSI. Mesclar o iSCSI com o armazenamento compartilhado nativo não é permitido.
7.2.2. Recomendações Gerais
Como mencionado acima, recomendamos atualizar ambos host e convidado para os pacotes
mais recentes do RHEL antes de utilizar as capacidades de virtualização, pois houveram muitas
melhorias e reparos de erros.
A mescla de plataformas de virtualização (hipervisors) abaixo de clusters convidados, não é
suportada. Todos os hosts adjacentes devem usar a mesma tecnologia de virtualização.
Não há suporte para executar todos os convidados em um cluster de convidado em um único
host físico, pois isso não fornece alta disponibilidade no caso de uma falha de host único. No
entanto, esta configuração pode ser usada para fins de protótipos ou de desenvolvimento.
Melhores práticas incluem o seguinte:
Não é necessário ter um único host por convidado, mas essa configuração fornece o mais
alto nível de disponibilidade, pois uma falha de host só afeta um único nó no cluster. Se você
tem um 2 à 1 mapeamento (dois convidados em um único cluster por host físico), isso
significa que uma única falha de host resulta em duas falhas de convidados. Portanto, é
aconselhável obter o mais próximo possível de 1 à 1 mapeamento.
Mesclar clusters de convidados independentes múltiplos no mesmo conjunto de hosts físicos,
não é suportado no momento ao utilizar os agentes fence_xvm/fence_xvmd ou
fence_virt/fence_virtd.
36
Mesclar clusters de convidados independentes múltiplos no mesmo conjunto de hosts físicos,
funcionará usando o armazenamento fence_scsi + iSCSI iy se utilizar fence_vmware +
VMware (ESX/ESXi and vCenter).
Executar os hóspedes que não são agrupados no mesmo conjunto de hosts físicos como um
cluster convidado, é suportado, mas desde que os hosts cerquem fisicamente uns aos outros
se um cluster de host for configurado, esses outros convidados também serão encerrados
durante uma operação de fencing de host.
O hardware do host deve ser provisionado de tal forma que a memória ou overcommit virtual
CPU seja evitado. A sobrecarga de memória ou CPU virtual irá resultar na degradação do
desempenho. Se a degradação do desempenho tornar-se crítica a pulsação do cluster
poderá ser afetada, o que pode resultar em falha de cluster.
37
Apêndice A. Histórico de Revisões
R evisão 1- 15.2
pt-BR is 100% translated
Wed Sep 2 2015
G lau cia C in t ra
R evisão 1- 15.1
Wed Sep 2 2015
G lau cia C in t ra
Tradução de arquivos sincronizados com a versão 1-15 de fontes do XML
R evisão 1- 15
T u e D ec 16 2014
St even Levin e
Atualizando para implementar o sort_order na página inicial do RHEL 6
R evisão 1- 13
Wed O ct 8 2014
Lançamento do GA para Red Hat Enterprise Linux 6.6
St even Levin e
R evisão 1- 12
T h u Au g 7 2014
Lançamento do Beta para Red Hat Enterprise Linux 6.6
St even Levin e
R evisão 1- 11
Fri Au g 1 2014
Resolve: #852720
Problemas editoriais pequenos
St even Levin e
R evisão 1- 10
Fri Ju n 6 2014
Rascunho do Red Hat Enterprise Linux 6.6
St even Levin e
R evisão 1- 7
Wed N o v 20 2013
Lançamento para GA do Red Hat Enterprise Linux 6.5
Jo h n H a
R evisão 1- 4
Mo n Feb 18 2013
Jo h n H a
R evisão 1- 3
Mo n Ju n 18 2012
Jo h n H a
R evisão 1- 2
Fri Au g 26 2011
Atualização para o lançamento de 6.2
Jo h n H a
R evisão 1- 1
Lançamento Inicial
Pau l K en n ed y
38
Wed N o v 10 2010

Visão Geral dos Complementos de Alta Disponibilidade

Transcrição

Documentos relacionados

RELEASE O Cluster 11ª edição - 29 de março

Uma Arquitetura para Submissão e Gerenciamento de jobs em

compreensão do conceito de luz por cegos congênitos: um estudo

An ncio Desespero

Uma Introdução à Mineração de Informações.

Guia de Modelagem de Dados - DATASUS

Red Hat Enterprise Linux 5 Deployment Guide

Prática certificada

Red Hat Enterprise Linux 5 Visão Geral do Cluster Suite

cefaléia em salvas.p65 - Sociedade Brasileira de Cefaleia