T
U
T
O
R
IA
L
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 dispo-ní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 HACluster. Trata-se da versão de código
aberto do Solaris Cluster, produto que roda em Solaris 10 e versões an-teriores. 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óxi-ma seção dará inforpróxi-mações básicas
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úl-tiplos nós físicos reais, há certas exi-gê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 progra-ma. 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
ha-cluster-full em todas as máquinas.
O colunista Alexandre Borges já explicou diversos detalhes do sis-tema 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.
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 ex-plicar por que ela é desejável. A res-posta é 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 dis-positivos 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 pro-cessadores múltiplos, mas sempre há falhas de sistema, como o barramento ou o kernel do sistema operacional. Assim, há um limite para a disponi-bilidade de um único computador físico. Embora falhas eventuais em laptops e desktops talvez não sejam tão alarmantes, os sistemas que for-necem 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 cons-tante. 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 ine-rentes aos sistemas? Uma resposta é unir duas ou mais máquinas físicas e usar o hardware redundante para superar qualquer falha a qualquer
momento, desde uma falha na pla-ca 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 chama-dos de clusters de alta disponibilida-de (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 ope-racional, ou ambos. Esse software oferece alta disponibilidade, moni-torando todo o sistema desde o es-tado do hardware até a “saúde” dos aplicativos. Se o software do cluster detecta um problema, ele pode rei-niciar 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 auto-mática, de forma que a intervenção do administrador não seja necessária. Além disso, esse serviço de recupe-raçã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 re-quisitos específicos de configuração de hardware. A boa notícia, porém, é que o Open HA Cluster usa hard-ware comum – não há necessidade de discos rígidos especializados, inter-conexõ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 consi-deração as redes, o armazenamento e as configurações de dispositivos de quorum devem ser considerados. A arquitetura típica do cluster é mos-trada 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ó tam-bém deve ser capaz de se comunicar com todos os demais nós do cluster, de preferência através de uma cone-xão dedicada, para garantir comuni-caçã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: bas-ta 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 vir-tuais de rede no OpenSolaris estão disponíveis em [5].
Armazenamento
A maioria dos aplicativos usa dados armazenados no disco. Ao serem exe-cutados 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 fi-gura 1 mostra essa configuração;
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, ex-porte 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 armaze-namento 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
divi-dido). 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 funcio-nando e se comunicando com a rede pública. Como cada subconjunto do cluster é incapaz de diferenciar entre uma falha no outro subconjun-to 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 modifi-cações simultâneas de dados compar-tilhados, 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
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 conti-nuar a prover o serviço. No entan-to, 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 verda-de, 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
dispo-sitivos de quorum.
A primeira opção de arbitragem é um dispositivo de disco conectado diretamente a ambos os nós do clus-ter, 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 clus-ters 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âne-as de nós. Portanto, o último psimultâne-asso da configuração do hardware é es-colher o mecanismo de arbitragem e configurá-lo.
Na figura 1, o dispositivo de quo-rum é uma parte do armazenamen-to 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 anteriormen-te, os aplicativos podem ser disponi-bilizados no Open HA Cluster sem modificações. Em vez disso, cada aplicativo requer uma camada de “cola”, chamada de agent (agen-te). 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 favo-rito, 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 dispo-nível qualquer serviço OpenSolaris SMF, novamente sem qualquer programação ou scripts. Consulte as páginas de manual SUNW.gds(5) e
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 funcio-nalidade 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 geren-ciamento 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 ini-ciada 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 (tam-bé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 exe-cutados 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 re-curso offline não está funcionando. O grupo de recursos é a unidade de gerenciamento e failover do cluster.
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 alta-mente 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ên-cias entre recursos, para controlar a ordem de inicialização e para-da 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 de-pendê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 libe-rar o armazenamento em disco para todos os nós do cluster. Mas isso é apenas o primeiro passo. Também é necessário disponibilizar o siste-ma de arquivos para os aplicativos em todos os nós em que são exe-cutados. O Open HA Cluster su-porta os sistemas de arquivos UFS e ZFS. No caso do UFS, o cluster
Figura 1 Arquitetura típica do cluster HA.
Rede pública Interconexão privada do cluster Nós físicos distintos Armazenamento compartilhado redundante com caminhos para cada nó
tem de montar o sistema de arqui-vos 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 gerenciamen-to do cluster. O Open HA Cluster inclui um tipo de recurso especial chamado HAStoragePlus (HASP). Recursos desse tipo podem geren-ciar sistemas de arquivos UFS ou zpools ZFS quando estes são mon-tados ou impormon-tados 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 exe-cutado, 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 configura-dos nos nós em que são executaconfigura-dos 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 armaze-namento HASP, chamado logical
hostname. Esse recurso gerencia
um endereço IP, fazendo-o funcio-nar 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 exigi-dos estejam disponíveis em toexigi-dos os nós em que haja aplicativos em execução. Consulte a página de manual clreslogicalhostname(1CL)
para mais detalhes.
Conclusão
Este artigo fornece algumas noções sobre clusters de alta disponibili-dade, e introduz o Open HA Clus-ter 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 as-pectos não abordados, consulte as referências abaixo. n
Gostou do artigo?
Queremos ouvir sua opinião. Fale conosco em
cartas@linuxmagazine.com.br
Este artigo no nosso site:
http://lnm.com.br/article/3287
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.
