Monte um cluster OpenSolaris para alta disponibilidade
TUTORIAL
OpenSolaris
em conjunto
No OpenSolaris, a alta disponibilidade depende do Open HA Cluster.
Conheça toda a flexibilidade dessa solução da Sun.
por Nicholas Solter
U
ma forma de garantir que os
seus serviços estejam disponíveis quase 100% do tempo
é executá-los em um cluster de alta
disponibilidade (HA, na sigla em
inglês). Existem diversas soluções
para criação de clusters HA de código aberto. No caso do Linux HA,
o componente Heartbeat do Linux
está disponível em muitas distribuições populares. O foco deste artigo,
no entanto, é o cluster HA disponível para OpenSolaris: o Open HA
Cluster. Trata-se da versão de código
aberto do Solaris Cluster, produto
que roda em Solaris 10 e versões anteriores. Com o Open HA Cluster, é
possível tornar altamente disponíveis
a maioria dos aplicativos de código
aberto sem modificá-los.
Se você já conhece clusters HA
em geral, já usou o Linux HA ou
qualquer outro cluster HA, já pode
começar a usar o Open HA; a próxima seção dará informações básicas
58
para iniciar. No entanto, se esse for
um conceito novo, é melhor ler as
informações da seção “Por que alta
disponibilidade?”.
Experimentos
Embora seja possível testar o Open
HA Cluster em um cluster de múltiplos nós físicos reais, há certas exigências de hardware que envolvem
rede e armazenamento e podem
atrapalhar a experiência inicial com
o software. Por isso, geralmente é
melhor testar o Open HA Cluster
em nós virtuais instalados em uma
única máquina física. Apesar de essa
configuração não alcançar uma alta
disponibilidade de fato, ela permite
conhecer um pouco mais do programa. O Open HA Cluster pode ser
usado até em clientes VirtualBox
[1], portanto, é possível usá-lo sem
uma máquina dedicada.
As instruções escritas pela equipe
da Sun especificamente para utilizar
o Open HA Cluster com VirtualBox
encontram-se em [2].
Para experimentar o Open HA
Cluster, é necessário baixar e instalar
o OpenSolaris [3] em todas as máquinas (físicas ou virtuais) do cluster.
O Open HA Cluster está disponível
no repositório de pacotes em http://
pkg.sun.com. Para obtê-lo, é preciso
registrar-se em https://pkg.sun.com/
register/ e seguir as instruções de
configuração em todas as máquinas
do cluster.
Em seguida, instale o pacote hacluster-full em todas as máquinas.
O colunista Alexandre Borges já
explicou diversos detalhes do sistema de pacotes IPS [4]. Consulte
a documentação do OpenSolaris
para mais detalhes sobre o uso do
sistema de pacotes IPS. Por fim,
execute /usr/cluster/bin/scinstall
em uma das máquinas do cluster e
siga as instruções de configuração
que são exibidas.
http://www.linuxmagazine.com.br
Open HA Cluster | TUTORIAL
Ao final dessa etapa, o cluster já
está funcional e pode começar a usar
seus recursos, que serão descritos em
seguida com mais detalhes.
Por que HA?
Se você não tem familiaridade com
clusters HA, talvez valha a pena explicar por que ela é desejável. A resposta é que os computadores falham.
Todos eles. Discos, processadores,
memória, barramento, placas de rede
e todos os outros componentes físicos
estão sujeitos às mesmas limitações
físicas de qualquer objeto. Não é
uma questão de se, é uma questão
de quando. Além disso, falhas em
softwares desde os aplicativos até o
sistema operacional e drivers de dispositivos podem derrubar serviços ou
a máquina inteira. Por último, um
erro de usuário pode desativar um
sistema inteiro.
Muitos sistemas têm embutida
redundância de hardware, como processadores múltiplos, mas sempre há
falhas de sistema, como o barramento
ou o kernel do sistema operacional.
Assim, há um limite para a disponibilidade de um único computador
físico. Embora falhas eventuais em
laptops e desktops talvez não sejam
tão alarmantes, os sistemas que fornecem serviços a outras pessoas e
empresas precisam permanecer no
ar ininterruptamente. Os clientes
desses serviços, sejam eles bancos de
dados de empresas ou blogs pessoais,
esperam uma disponibilidade constante. A inatividade desses serviços
pode levar à insatisfação dos clientes,
à diminuição da satisfação do usuário e à perda de receita.
Clusters para HA
Com todas essas considerações, como
garantir a disponibilidade consistente
dos serviços, dadas as limitações inerentes aos sistemas? Uma resposta é
unir duas ou mais máquinas físicas
e usar o hardware redundante para
superar qualquer falha a qualquer
Linux Magazine #63 | Fevereiro de 2010
momento, desde uma falha na placa de rede até uma pane completa
no sistema. Desta forma, é possível
proporcionar maior disponibilidade
do sistema como um todo, mais do
que seria possível com um único
componente. Sistemas configurados
dessa forma geralmente são chamados de clusters de alta disponibilidade (ou clusters HA). A infraestrutura
de um cluster HA consiste em dois
componentes principais: o hardware
redundante e o software do cluster.
O software do cluster faz parte do
próprio sistema operacional ou está
diretamente acima do sistema operacional, ou ambos. Esse software
oferece alta disponibilidade, monitorando todo o sistema desde o estado do hardware até a “saúde” dos
aplicativos. Se o software do cluster
detecta um problema, ele pode reiniciar o aplicativo na máquina ou
passar o serviço para outra máquina
“saudável” no cluster.
O software do cluster também
garante que a detecção de falhas e a
recuperação ocorram de forma automática, de forma que a intervenção
do administrador não seja necessária.
Além disso, esse serviço de recuperação não é visível para os clientes,
ou seja, os clientes do serviço não
sabem em qual máquina do cluster o
serviço está realmente funcionando.
Em certo sentido, pode-se pensar em
um cluster HA como uma miniatura
da computação em nuvem.
Hardware
Como mencionado anteriormente,
o Open HA Cluster tem alguns requisitos específicos de configuração
de hardware. A boa notícia, porém,
é que o Open HA Cluster usa hardware comum – não há necessidade
de discos rígidos especializados, interconexões ou outros componentes. O
cluster é composto por duas ou mais
máquinas físicas, chamadas de nós.
Para configurar um cluster de dois
nós, são necessárias duas máquinas da
mesma arquitetura (SPARC ou x86/
x64) na mesma sub-rede. Além das
máquinas, é preciso levar em consideração as redes, o armazenamento
e as configurações de dispositivos de
quorum devem ser considerados. A
arquitetura típica do cluster é mostrada na figura 1.
Rede
Cada nó do cluster deve ser capaz de
se comunicar com a rede pública, a
fim de prestar serviços a clientes fora
da sub-rede do cluster. Cada nó também deve ser capaz de se comunicar
com todos os demais nós do cluster,
de preferência através de uma conexão dedicada, para garantir comunicação rápida e detecção de falhas.
Assim, se disponível, recomenda-se
dedicar uma ou duas placas de rede
de cada máquina para a comunicação privada entre os nós e cabeá-los
de tal forma que esse tráfego privado
seja separado da rede pública. No
entanto, ainda é possível formar um
cluster mesmo que haja apenas um
adaptador de rede em cada nó e que
não haja cabeamento privado: basta utilizar o recurso de placa virtual
de rede do OpenSolaris. A figura 1
mostra uma arquitetura típica, com
uma interconexão privada entre os
dois nós.
Mais informações sobre placas virtuais de rede no OpenSolaris estão
disponíveis em [5].
Armazenamento
A maioria dos aplicativos usa dados
armazenados no disco. Ao serem executados em um cluster, os aplicativos
não usam o disco local diretamente,
pois ele não está obrigatoriamente
disponível no mesmo nó do cluster
onde os aplicativos são executados.
Para isso, há várias soluções possíveis:
use um ou mais discos rígidos
ligados diretamente ao nó, ou
SANs que possam ser acessadas
por todos os nós do cluster. A figura 1 mostra essa configuração;
59
TUTORIAL | Open HA Cluster
disponibilize dispositivos NAS
que possam ser acessados por
todos os nós do cluster;
em um cluster com mais de dois
nós, conecte diretamente um
disco ou SAN a dois ou mais
nós, mas disponibilize-o para
todos os nós usando o sistema
de arquivos global do cluster;
em um cluster com dois nós, exporte o disco local de cada um
dos nós como um alvo iSCSI e
monte um espelho ZFS sobre
eles [6], acessível aos dois nós
do cluster.
Mais informações sobre armazenamento na documentação do Open
HA Cluster [7].
Dispositivos
de quorum
Um problema clássico em sistemas
distribuídos é o que se chama de
condição split-brain (cérebro dividido). Esse cenário pode ocorrer
como resultado de uma partição de
rede: quando dois subconjuntos de
nós do cluster têm problemas para se
comunicar, mas continuam funcionando e se comunicando com a rede
pública. Como cada subconjunto
do cluster é incapaz de diferenciar
entre uma falha no outro subconjunto e uma falha na outra partição da
rede, cada subconjunto pode tentar
hospedar todos os serviços prestados
pelo cluster.
O split-brain pode levar a modificações simultâneas de dados compartilhados, o que causaria a corrupção
destes dados. Por exemplo, imagine
os erros que poderiam ocorrer em
um banco de dados se o servidor
funcionasse em dois nós do cluster
ao mesmo tempo, sem que um se
comunicasse com o outro.
A fim de resolver esse problema, o
Open HA Cluster usa o conceito de
quorum para garantir que apenas uma
das partições do cluster permaneça
60
ativa no cenário acima. Em geral, o
quorum exige a maioria de nós do
cluster. Assim, em um cluster de três
nós, dois nós teriam que fazer parte
de uma partição para poder continuar a prover o serviço. No entanto, esse algoritmo não funciona em
um cluster de dois nós. Se um nó
parar de funcionar, o outro precisa
ser capaz de continuar oferecendo
o serviço, caso contrário, não existe
alta disponibilidade. Mas como o
nó restante conseguiria distinguir
uma falha legítima no nó de uma
falha na partição de rede? Na verdade, ele não consegue; portanto, um
cluster de dois nós exige algum tipo
de arbitragem de terceiros. O Open
HA Cluster suporta duas formas de
arbitragem, ambas formas de dispositivos de quorum.
A primeira opção de arbitragem
é um dispositivo de disco conectado
diretamente a ambos os nós do cluster, funcionando como um voto de
desempate no caso de uma partição
de rede; o nó que chegar primeiro
ao dispositivo reserva-o e exclui o
outro nó. Essa opção é chamada de
disco de quorum.
A segunda opção de arbitragem
do Open HA Cluster é semelhante a
um dispositivo de quorum, mas usa
o serviço de um software executado
em uma terceira máquina, em vez
de um dispositivo de hardware. Isso
é chamado de servidor de quorum.
Embora o disco ou servidor de
quorum só seja necessário em clusters de dois nós, também é possível
usá-los em clusters com mais nós
para otimizar a disponibilidade no
caso de múltiplas falhas simultâneas de nós. Portanto, o último passo
da configuração do hardware é escolher o mecanismo de arbitragem
e configurá-lo.
Na figura 1, o dispositivo de quorum é uma parte do armazenamento que está conectado diretamente.
Para mais detalhes sobre quorum
e dispositivos de quorum, confira a
documentação oficial do Cluster
Solaris [8].
Agentes
Agora que já abordamos a instalação
do Open HA Cluster, a teoria por
trás de tudo isso e a instalação do
hardware, vejamos outros recursos
e detalhes.
Como mencionado anteriormente, os aplicativos podem ser disponibilizados no Open HA Cluster sem
modificações. Em vez disso, cada
aplicativo requer uma camada de
“cola”, chamada de agent (agente). Ele não faz parte do próprio
aplicativo e não precisa ser escrito
pela mesma pessoa ou equipe que
o produziu, mas sabe como iniciar,
parar e controlar o aplicativo, e
também sabe como se comunicar
com a plataforma de cluster. O
Open HA Cluster inclui agentes
para diversos aplicativos populares,
como Apache, Apache Tomcat,
MySQL, NFS e outros de código
aberto. Consulte a documentação
do Open HA Cluster [9] para uma
lista completa. Os agentes também
são chamados, às vezes, de data
services (serviços de dados).
Se você não conseguir encontrar
um agente para seu aplicativo favorito, não se desespere. Há uma série
de maneiras de tornar seu aplicativo
altamente disponível, mesmo sem
escrever uma única linha de código.
A abordagem mais fácil é usar o
Serviço Genérico de Dados (Generic
Data Service – GDS). Esse agente
permite que você registre o comando
de inicialização e a porta de escuta
de um aplicativo (além de outras
propriedades opcionais), e o GDS
cuida do resto. O Open HA Cluster
inclui também um agente genérico
similar chamado SMF Proxy agent,
que permite tornar altamente disponível qualquer serviço OpenSolaris
SMF, novamente sem qualquer
programação ou scripts. Consulte as
páginas de manual SUNW.gds(5) e
http://www.linuxmagazine.com.br
Open HA Cluster | TUTORIAL
SUNW.Proxy_SMF_failover(5) para
mais detalhes.
Para exercer mais poder sobre o
agente, é possível escrever scripts
sofisticados que tiram vantagem
do GDS, ou escrever seus próprios
agentes com o Agent Builder, seja
pela interface gráfica ou pela linha
de comando. No entanto, a funcionalidade básica do GDS e do SMF
Proxy deve ser suficiente para a
maioria dos aplicativos.
Gerenciamento
de serviços
Além dos recursos esperados em
um cluster HA, o Open HA Cluster
fornece uma plataforma de gerenciamento de serviços. Para usá-la, é
preciso primeiramente entender os
conceitos e a terminologia usados
pelo Open HA Cluster.
Em primeiro lugar, todo o serviço
gerenciado pelo cluster é chamado
de recurso. Apesar de um recurso
geralmente ser um aplicativo como
um servidor web ou um servidor de
banco de dados, um recurso pode
ser qualquer coisa que possa ser iniciada e parada em uma máquina,
incluindo até mesmo coisas como
um endereço de rede ou um sistema
de arquivos. A configuração estática
de cada recurso é definida por seus
agentes ou serviços de dados (também chamada de tipo de recurso). Em
termos de programação orientada a
objetos, o recurso é a instanciação do
tipo de recurso. Por fim, os recursos
são agrupados em grupos de recursos.
Recursos e grupos de recursos têm
propriedades, tais como o número
de nós em que eles podem ser executados simultaneamente, e estão
sempre em um estado, como online
ou offline, em cada nó. Um recurso
que estiver online em um nó está
sendo executado nesse nó. Um recurso offline não está funcionando.
O grupo de recursos é a unidade de
gerenciamento e failover do cluster.
Linux Magazine #63 | Fevereiro de 2010
Isto é, todo recurso em um grupo
de recursos é colocado online ou
offline em um nó ao mesmo tempo
(embora seja possível personalizar
esse comportamento desabilitando
recursos individuais).
Depois de determinar um agente
para o aplicativo que deve ser altamente disponibilizado, é preciso
criar um grupo de recursos e um
recurso para o aplicativo. O grupo
de recursos é composto pelo recurso
do aplicativo e, opcionalmente, os
recursos de armazenamento e rede.
Esses tipos de recursos serão vistos
nas próximas duas seções.
O Open HA Cluster também
permite a criação de dependências entre recursos, para controlar
a ordem de inicialização e parada dos serviços subjacentes. Por
exemplo, é possível definir que o
recurso de um aplicativo dependa
de um recurso de rede, de modo
que o recurso de rede será sempre
inicializado antes e parado depois
do recurso do aplicativo. Essas dependências têm vários “sabores”
diferentes, incluindo dependências
de reinicialização, para reiniciar
um recurso caso outro recurso do
qual ele depende seja reiniciado.
As dependências também podem
abranger os grupos de recursos. Ou
seja, o recurso dependente e o alvo
da dependência não precisam estar
no mesmo grupo de recursos. Além
disso, o Open HA Cluster suporta
o conceito de afinidades entre os
grupos de recursos, para controlar
a localização de grupos de recursos
nos nós do cluster.
O Open HA Cluster possui um
conjunto de comandos orientados
a objetos para manipular objetos do
cluster, incluindo o clresource(1CL),
o clresourcegroup(1CL) e assim por
diante. Consulte a documentação
desses comandos para mais detalhes.
Armazenamento
Como mencionado anteriormente,
existem vários mecanismos para liberar o armazenamento em disco para
todos os nós do cluster. Mas isso é
apenas o primeiro passo. Também
é necessário disponibilizar o sistema de arquivos para os aplicativos
em todos os nós em que são executados. O Open HA Cluster suporta os sistemas de arquivos UFS
e ZFS. No caso do UFS, o cluster
Rede pública
Nós físicos
distintos
Interconexão
privada do cluster
Armazenamento
compartilhado redundante
com caminhos para cada nó
Figura 1Arquitetura típica do cluster HA.
61
TUTORIAL | Open HA Cluster
tem de montar o sistema de arquivos no nó em que o aplicativo está
sendo executado. No caso do ZFS,
o cluster deve importar o zpool no
nó em questão. Esses dois sistemas
de arquivos podem ser gerenciados
como recursos do cluster usando a
estrutura de serviço de gerenciamento do cluster. O Open HA Cluster
inclui um tipo de recurso especial
chamado HAStoragePlus (HASP).
Recursos desse tipo podem gerenciar sistemas de arquivos UFS ou
zpools ZFS quando estes são montados ou importados em nós que
precisem deles.
Para usar o HASP, é necessário
criar um recurso do tipo HASP no
mesmo grupo de recursos do seu
aplicativo. Em seguida, em todos
os nós em que o aplicativo for executado, o HASP irá garantir que o
sistema de arquivos utilizado também
esteja disponível. Veja a página de
manual SUNW.HAStoragePlus(5)
para mais detalhes.
Rede
Tal como acontece com o sistema
de arquivos, o cluster também deve
assegurar que os endereços IP usados
pelos aplicativos estejam configurados nos nós em que são executados
e sejam derrubados nos nós onde os
aplicativos não estão funcionando.
O Open HA Cluster fornece um
tipo de recurso para os endereços
IP similar ao recurso de armazenamento HASP, chamado logical
hostname. Esse recurso gerencia
um endereço IP, fazendo-o funcionar em um nó onde o recurso está
online, e derrubando-o no nó em
que está offline. É possível utilizar
os recursos desse tipo do mesmo
modo como se usa o HASP, para
garantir que os endereços IP exigidos estejam disponíveis em todos
os nós em que haja aplicativos em
execução. Consulte a página de
manual clreslogicalhostname(1CL)
para mais detalhes.
62
Conclusão
Este artigo fornece algumas noções
sobre clusters de alta disponibilidade, e introduz o Open HA Cluster do OpenSolaris. No entanto,
pelo fato do Open HA Cluster ser
um sistema de software complexo
(como são todos os clusters HA),
este artigo se manteve apenas na
superfície. Muitos recursos, tais
como o software de balanceamento
de carga, “cercamento” de discos,
atualizações etc., ficaram de fora.
Para mais detalhes sobre os assuntos
abordados neste artigo, e também
para uma infinidade de outros aspectos não abordados, consulte as
referências abaixo. n
Mais informações
[1]Download do VirtualBox: http://www.virtualbox.org/
[2]Open HA Cluster com VirtualBox: http://opensolaris.org/os/project/
colorado/files/Whitepaper-OpenHAClusterOnOpenSolaris-external.pdf
[3]OpenSolaris: http://www.opensolaris.com
[4]Alexandre Borges, “OpenSolaris, parte 4”:
http://lnm.com.br/article/2969
[5]Placas virtuais de rede no OpenSolaris:
http://opensolaris.org/os/project/crossbow/
[6]iSCSI e ZFS no OpenSolaris:
http://opensolaris.org/os/community/storage/
[7]Armazenamento e Open HA Cluster:
http://docs.sun.com/app/docs/doc/820-7821
[8]Documentação de quorum:
http://docs.sun.com/app/docs/doc/820-4676/cacfchja?a=view
[9]Documentação do Open HA Cluster: http://stage.opensolaris.
org/os/community/ha-clusters/translations/ptBR/ohac_pt_BR/
[10]Comunidade Open HA Cluster:
http://opensolaris.org/os/community/ha-clusters/ohac/
[11]Blog Sun Cluster: http://blogs.sun.com/SC
[12]Nicholas A. Solter, Gerald Jelinek e David Miner,
“OpenSolaris Bible”. Wiley, 2009.
Sobre o autor
Nicholas A. Solter é autor dos livros “OpenSolaris Bible” e “Professional C++””. Ele trabalha há
nove anos com software de alta disponibilidade na Sun Microsystems e é mestre em Ciência da
Computação pela Universidade de Stanford.
Gostou do artigo?
Queremos ouvir sua opinião. Fale conosco em
[email protected]
Este artigo no nosso site:
http://lnm.com.br/article/3287
http://www.linuxmagazine.com.br
Livro C
e r t i fi c
ição
d
e
ª
2
2
I
P
L
o
ã
aç
A Linux Magazine está lançando
a 2ª edição revisada e ampliada
do livro que te prepara para a
Certificação LPIC-2 com as
seguintes novidades:
• Exercícios em todos os tópicos
• Todo conteúdo ampliado para
a nova versão da prova,
atualizada em abril/2009
Garanta já o seu pelo site da Linux Magazine
www.linuxmagazine.com.br