Instituto Superior de Engenharia do Porto Departamento de Engenharia Informática
Licenciatura em Engenharia Informática
Projecto
�
��
�
�
��
�
Elaborado por:
i970306 – Américo Silva
Orientado por:
Eng. André Moreira
Setembro 2002
Instituto Superior de Engenharia do Porto Departamento de Engenharia Informática
Licenciatura em Engenharia Informática
Projecto
�
��
�
Setembro 2002
Índice
1 Introdução ------------------------------------------------------------------ 6
2 - Clustering------------------------------------------------------------------ 7
2.1 Definição------------------------------------------------------------------------------- 7
2.2 Clustering – Quem necessita? -------------------------------------------------- 8
2.3 Clustering – Porque é importante?-------------------------------------------- 9
2.4 Alta Disponibilidade, quem necessita?-------------------------------------11
2.5 Redundância, elasticidade ... -------------------------------------------------12
2.6 Clustering– Outras aplicações-------------------------------------------------14
3 Modelos de Clustering ----------------------------------------------------17
4 Linux Clustering ------------------------------------------------------------19
4.1 Estrutura Cluster---------------------------------------------------------------------20
4.2 Características ----------------------------------------------------------------------27
4.3 Recuperação -----------------------------------------------------------------------27
4.4 Cluster API ----------------------------------------------------------------------------28
4.5 Negociar a morte do cliente --------------------------------------------------28
4.6 Segurança----------------------------------------------------------------------------29
4.7 Atribuição de nomes aos nós--------------------------------------------------30
4.8 Serviços recuperáveis ------------------------------------------------------------31
4.9 Entrega de eventos assíncronos ----------------------------------------------32
5 Ferramentas de Clustering em Linux -------------------------------------34
5.1 Cluster Server 6 – TurboLinux----------------------------------------------------34
5.2 ClusterWorX 2.1 – Linux NetworX ----------------------------------------------45
5.3 DataGuard Convolo Cluster ---------------------------------------------------54
5.4 Kimberlite Cluster – Mission Critical Linux -----------------------------------67
5.5 LifeKeeper para Linux-------------------------------------------------------------79
5.6 Maui ------------------------------------------------------------------------------------86
5.7 MOSIX ----------------------------------------------------------------------------------89
5.8 Piranha – Red Hat Linux ----------------------------------------------------------99
6 Análise das ferramentas ------------------------------------------------ 103
6.1 Planeamento de manutenção --------------------------------------------- 106
6.2 Crash do sistema ----------------------------------------------------------------- 107
6.3 Falha de comunicações ------------------------------------------------------ 107
6.4 Sistema “pendurado” ---------------------------------------------------------- 109
7 Conclusão --------------------------------------------------------------- 111
8 Bibliografia --------------------------------------------------------------- 112
9 Glossário ----------------------------------------------------------------- 113
Agradecimento
A realização deste trabalho de final de licenciatura é considerado
como um último esforço para a conclusão do curso e de um objectivo
pessoal. Por isso, gostaria de agradecer a todos os que me apoiaram,
principalmente à minha esposa Susana, aos meus pais, e aos meus
colegas de curso. A todos os que contribuíram directa ou
indirectamente o meu Muito Obrigado.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux - Introdução 6
1 Introdução
O termo clustering refere-se actualmente a um número variado de
diferentes tecnologias e configurações. Um cluster é um grupo de
servidores e outros recursos que se encontram ligados por hardware,
software ou redes e que conduzem a um único sistema.
Este sistema obriga a tarefas de administração por vezes bastante
complexas. Para simplificar o trabalho dos responsáveis pela
implementação e manutenção de um sistema deste tipo, existe hoje
em dia, um conjunto de ferramentas destinadas às realização de
tarefas em clusters Linux.
Tendo em conta o interesse pessoal por este tema resolvi elaborar
este trabalho que visa sobretudo dar a conhecer quais são e como
funcionam algumas das ferramentas de clustering em Linux existentes.
Para tal decidi começar por fazer uma breve introdução ao termo
cluster, assim como a sua aplicação e importância nos dias de hoje.
Seguidamente será feita uma abordagem um pouco mais profunda
acerca do funcionamento de um cluster Linux, estrutura e modelos
existentes. O restante do trabalho baseia-se na apresentação das
ferramentas escolhidas, características e funcionalidades. Será feita
uma análise em jeito de comparação sobre as qualidades mais
importantes de cada ferramenta.
Portanto, o objectivo deste trabalho é fundamentalmente dar a
conhecer quais as opções existentes para este tema, como
funcionam e para que servem.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux - Clustering 7
2 Clustering
2.1 Definição
“A cluster is a set of interconnected computers serving a specific
need”
Quando se ouve as palavras clustering ou server cluster, pensa-se
em grupos de computadores de alta performance usados para
investigação. Todavia, isto é apenas um modo de clustering existente.
Para pessoas que necessitam de alta performance, em vez de
comprarem grandes servidores (bastante caros) para executarem
cada vez mais tarefas, a concentração de muitos computadores
“baratos” resolve bastantes problemas: os computadores trabalham
pouco (em paralelo). Nesta base, a ideia é criar um largo número de
máquinas individuais que actuem como uma única máquina muito
poderosa. Este tipo de cluster destina-se a resolver grandes e
complexos problemas que requerem enormes capacidades de
computação. Aplicações de previsão de tempo, astronomia e
investigação criptográfica são as principais candidatas para clusters
de alta performance.
O segundo tipo de clustering permite a uma rede de servidores
partilhar o tráfego dos seus clientes. Através do balanceamento deste
tráfego ao longo de um array de servidores, os tempos de acesso
melhoram e a confiança aumenta. Adicionalmente, como existem
vários servidores a assegurar o trabalho, uma falha não causará
paragens catastróficas. Este tipo de serviço tem um valor
importantíssimo para empresas que possuem web sites extremamente
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux - Clustering 8
visitados.
Outro tipo importante de clustering envolve a existência de
servidores que actuam como cópias de segurança uns dos outros. Isto
é chamado de clustering de alta disponibilidade (HA clustering) ou
clustering redundante. Através da constante análise da performance
e da estabilidade dos outros servidores, o cluster tende a aumentar os
system uptimes. Isto pode ser crucial para os e-business sites de
elevado tráfego, assim como, para o de outras aplicações críticas.
Os clusters Load Balancing e HA partilham muitos componentes em
comum, e alguns fazem uso de ambos os tipos de clustering.
A escalabilidade corresponde às necessidades das plataformas
flexíveis poderem crescer de acordo com os requisitos de tráfego de
uma forma suave e sem reconsideração da arquitectura corrente. A
escalabilidade é um assunto bastante importante para a maioria das
plataformas de Internet Hosting, uma vez que o número de utilizadores
é muito variável e pode aumentar num curto período de tempo.
2.2 Clustering – Quem necessita?
O clustering destina-se aos utilizadores mais intensos.
Tem particular interesse na indústria, investigação / supercomputação:
• Indústria Automóvel e aéreoespacial: simulações de
acidentes;
• Laboratórios de investigação, indústrias científicas,
biologia molecular e previsões de tempo;
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux - Clustering 9
• Gráficos 3D, desenho;
• Finanças: Análises de riscos.
Assim como, na área de Internet Hosting:
• ISPs, ASPs;
• Internet e Intranet para grandes contas.
2.3 Clustering – Porque é importante?
Alta Disponibilidade - 24x7x365
A necessidade de existirem sistemas centrais e os seus
concomitantes (companheiros) servidores WEB front-end a correr
literalmente a todo o instante significa que a alta disponibilidade
impera. É aqui que uma solução de clustering é brilhante. O
clustering fornece backups transparentes e tolerância a falhas,
criando redundância de sistemas, periféricos e informação.
Integração de Servidores
- Servidores WEB;
- Servidores de aplicações;
- Servidores de transacções de informação;
- Servidores de Ficheiros;
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux - Clustering 10
Adicionalmente, um negócio baseado num ambiente WEB, obriga
a que as empresas não utilizem uma única máquina “gigante” para
processar toda a informação necessária – mesmo que um servidor
possa provavelmente ser comprado para armazenar toda a
informação da companhia.
Muitas aplicações requerem que os recursos do servidor estejam
dispostos de diferentes modos para servirem vários propósitos.
Na generalidade, existem três classes de cargas de trabalho que
requerem diferentes servidores dinâmicos:
Servidores WEB: gerem a experiência do utilizador final;
Servidores de aplicações: gerem funções de rede
específicas;
Servidores de transacção de informação: gerem os
processos centrais de negócio.
Aqui, todas as aplicações que correm nas diferentes classes de
cargas de trabalho (as quais, por conseguinte, são provavelmente
implementadas em servidores separados) necessitam de aceder,
partilhar e actualizar a informação em tempo real.
Também é verdade que as funções que têm por tradição estar
directamente ligadas a servidores individuais, como ligações de rede
e de armazenamento, sendo propositadamente desenvolvidas
centralmente no sentido de fornecer uma utilização mais eficiente,
facilmente escalonável e de maior flexibilidade.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux - Clustering 11
O clustering elegantemente resolve o problema de integrar estes
três tipos de servidores com redes centralizadas e recursos de
armazenamento. E, desta forma, o clustering permite gerir estes
servidores separados como se de um único servidor se tratasse.
2.4 Alta Disponibilidade, quem necessita?
A disponibilidade pode ser medida do modo “100% operacional” ou
“sem falhas” . Quase toda a gente já ouviu falar dos “cinco noves”.
Um 9 significa 90% activo, dois 9s significa 99%, três 9s significa 99,9%,
etc. Quatro 9s deverá significar que o sistema estará pelo menos 1
hora inactivo durante todo o ano. Cinco 9s é considerado o ponto de
arranque das soluções consideradas de alta disponibilidade (High
Availability). “Cinco 9s (que representam 5,39 minutos de inactividade
por ano) pode ser considerado o “Holy Grail” da alta disponibilidade
para sistemas distribuídos, de acordo com Ron Anderson, que escreve
para a “Oses & Network Services”. Segundo ele, cinco 9s activo é
bastante caro e complexo, mas é bem merecido para companhias
que vivem ao segundo, como é o caso da Amazon.com”. Uma vez
que uma paragem de poucos segundos numa empresa como esta
poderia causar graves prejuízos económicos.
A tecnologia de cluster fornece disponibilidade e performance
ao modelo tradicional de Data Center. Níveis de serviço formalizados
dentro das empresas e entre negócios estão-se a tornar uma prática
corrente. A disponibilidade, a performance, e a fiabilidade são as
principais medidas adoptadas. A disponibilidade contínua num nível
técnico tende a reduzir os custos de planeamento do negócio. Isto
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux - Clustering 12
inclui a disponibilidade aplicacional, batch versus backup, sistemas de
suporte à decisão, uso de outros acessórios para executar o que
poderia ser feito apenas com disaster recovery e reconstrução point-
in-time. Estes aspectos são interessantes na medida em que evitam
custos, no entanto, são custos tangíveis que se devem ter em conta.
2.5 Redundância, elasticidade ...
Visto que um sistema consiste em várias partes, todas elas
necessitam de estar presentes para que a totalidade esteja
operacional, muito planeamento para alta disponibilidade centra-se
nas questões de backup e tolerância a falhas de processamento e no
acesso e armazenamento de informação. Para o armazenamento,
um array de discos independentes (RAID) é um aproximar. Uma
recente aproximação é a Storage Area Network (SAN). Uma SAN é
uma rede de alta velocidade que interliga vários tipos de dispositivos
de armazenamento com servidores de dados em favor de um largo
número de utilizadores da rede.
Para obter uma disponibilidade contínua, é necessário mais do que
um robusto sistema de disponibilidade. A informação e as aplicações
críticas devem também ser resistentes a falhas. As duas devem estar
acessíveis ao longo do cluster mesmo quando a máquina responsável
pelo recurso falha. Um solução completa é obtida quando a
informação e as aplicações críticas são criadas como sendo recursos
elásticos e estão sempre disponíveis. A elasticidade dos dados
assegura que uma cópia dos dados está sempre acessível para os
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux - Clustering 13
utilizadores finais do cluster. A elasticidade das aplicações assegura
que os serviços fornecidos pela aplicação estão sempre acessíveis aos
utilizadores finais do cluster. A elasticidade da aplicação é fornecida
através endereços IP.
Similarmente, todos os outros pontos de falhas que podem
interromper a disponibilidade devem ser eliminados. Então, a
redundância é crítica ao longo do sistema, incluindo a rede, a
corrente eléctrica e a ligação à Internet.
Se ocorrer uma quebra no sistema ou uma perda de um site, as
funções fornecidas numa base de dados do sistema de cluster podem
ser desviadas para um sistema chamado sistema backup que contém
uma cópia corrente (réplica) da aplicação crítica ou que se torna o
ponto primário do acesso para o dispositivo elástico que contém essa
informação critica. A tolerância a falhas pode ser automática se
acontecer uma falha no sistema, ou é possível controlar como e
quando a transferência será feita, iniciando manualmente o desvio
(switching).
Toda esta redundância permite não apenas a tolerância a falhas,
mas também tolerância a desvios. Uma tolerância a um desvio ocorre
se manualmente o utilizador desviar o acesso de um sistema para
outro. Isto é altamente conveniente quando é necessário melhorar o
funcionamento do sistema, assim como a aplicação de programas de
correcções temporárias (PTFs), instalando uma nova versão, ou
executando uma actualização do sistema.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux - Clustering 14
2.6 Clustering – Outras aplicações
Para além da alta disponibilidade existem ainda outras aplicações
para um sistema de clustering.
Balanceamento
O balanceamento resume-se à distribuição do trabalho que um
servidor tem de fazer entre dois ou mais computadores para mais
rapidamente executar esse mesmo trabalho. O Balanceamento pode
ser implementado através de hardware, software, ou uma
combinação dos dois, sendo esta uma boa razão que leva à escolha
de soluções de clustering. Quando há necessidade de balancear
cargas de trabalho que chegam de uma página da WEB, cada
pedido é encaminhado para diferentes servidores (diferentes
endereços) numa tabela de DNS, estilo Round-Robin.
Escalabilidade
Na tecnologia de informação, a escalabilidade envolve a
habilidade para “guardar” níveis de performance quando é
necessário adicionar suavemente novos componentes ao longo do
crescimento do negócio. Parece evidente que a razão que faz com
que se adicionem mais processadores e discos para armazenamento
é o crescimento do volume de negócios. Mas, hoje em dia, em
ambientes de negócio baseado na WEB, os volumes de negócios
retirados dos servidores WEB tornam-se rapidamente imensos, que a
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux - Clustering 15
escalabilidade pode muitas vezes ser resolvida através de um sistema
sofisticado de clustering e de técnicas de balanceamento. Isto porque
a escalabilidade agora deve suportar grandes pedidos (exigências) e
não apenas os pedidos normais.
Capacidade de resposta a pedidos
Capacity on Demand (CoD), actualmente fornece uma nova
forma de escalabilidade horizontal. Neste ambiente, a tecnologia de
clustering necessita de estar apta para “alocar” e “desalocar”
recursos (ex. servidores, discos), com as diferentes cargas de trabalho.
Necessita também de estar pronta para rapidamente “abraçar” um
novo serviço, não planeado.
Gestão de sistemas
A administração simplificada de servidores pode ser melhorada
através de clustering. Efectivamente permitindo a gestão de grupos
de sistemas como um simples sistema ou uma simples base de dados.
Características como a gestão e administração intuitiva, detecção e
recuperação por falhas, e a capacidade de adicionar ou eliminar
recursos sem uma interrupção de todo o serviço são requeridas em
soluções de gestão de sistemas de clusters.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux - Clustering 16
Processamento paralelo de alta performance
Para muitas aplicações, as instruções de um programa podem ser
divididas por múltiplos processadores, reduzindo dramaticamente o
tempo total de funcionamento do programa. Em sistemas de
multiprocessamento simétrico (SMP) cada processador é igualmente
capaz e responsável pela gestão do fluxo de trabalho ao longo do
sistema. Os sistemas de processamento paralelo massivo (MPP)
fornecem também capacidades de processamento paralelo, este
verdadeiramente excede-se quando usado em ambientes que
envolvem muitas operações independentes em largas quantidades
de informação, como o caso do data mining e das tarefas de
inteligência artificial. Todavia, o clustering pode fornecer um
processamento de relativo baixo custo para aplicações científicas
que concedem elas próprias para operações paralelas (ex.
transacções de base de dados, simulação científica e data mining).
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Modelos de Clustering 17
3 Modelos de Clustering
3.1 Load-Balancing Cluster
Com este modelo de clustering, o número de utilizadores (ou o
número de transacções) podem ser “alocadas” (via algoritmo Load-
Balancing) ao longo de um número de instâncias para assim
aumentar a capacidade transaccional.
Este modelo é facilmente redimensionado à medida que o volume
de utilizadores e de transacções aumenta.
Fig. 1- Modelo Load-Balancing
3.2 High Availability Cluster
Este modelo de cluster estende-se ao simples modelo de
balanceamento apresentado anteriormente. Este não apenas fornece
balanceamento de carga, como também fornece alta
disponibilidade através da redundância de aplicações e dados. Este
requere pelo menos dois nós – um principal e um backup.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Modelos de Clustering 18
Neste modelo, os nós podem ser considerados active-passive ou
active-active. No cenário active-active, um servidor faz a maior parte
do trabalho enquanto que o outro gasta a maior parte do tempo em
operações de replicação. Neste cenário, ambos os servidores
executam trabalhos primários e ambos estão replicados que até
parecem os mesmos.
Como o modelo anterior, este modelo é facilmente escalonável
consoante o volume de utilizadores e transacções aumenta. Um
aumento no volume implica apenas uma simples replicação, não
sendo necessária qualquer alteração nas aplicações.
Figura 2 - Modelo High Availability
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Linux Clustering 19
4 Linux Clustering
Os objectivos principais de um projecto de infra-estrutura em cluster
são:
Fornecer funcionalidades que permitam a coordenação
de services arbritários.
Fornecer um forte conceito de comunidade, com
transições sincronizadas entre estados do cluster quando um
novo nó se une ao cluster ou um nó existente morre.
O termo “imaginário” inclui muito do que não é antecipado na
implementação inicial. Alguns destes serão programados para futuras
implementações. Os serviços de clustering são necessários para
favorecer serviços terceiros que não fazem parte do próprio cluster,
mas ser-lhes-ão atribuídos certos requisitos em clustering, o que é
necessário ter em conta. É particularmente necessário abordar os
seguintes aspectos:
Escalabilidade, para cima ou para baixo. A criação de um
cluster a partir de máquinas 486s por exemplo para serviços WEB de
alta disponibilidade num departamento. Ou então, criar um cluster
com um grande número de nós (dezenas ou milhares) para
processamento paralelo massivo (MPP), como anteriormente
abordámos.
Sistema de ficheiros de cluster escalonável, em apenas um
segmento de cluster, GFS é a maneira usada para se desenvolver um
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Linux Clustering 20
sistema de ficheiros de cluster externo, com acesso a discos
partilhados sobre dispositivos de cluster partilhados e software de RAID
partilhado.
No topo disto, é necessário um mecanismo como o AFS ou o
CODA para migrar os ficheiros entre os segmentos do cluster: O
modelo de discos partilhados não executa o escalonamento
correctamente uma vez que envolve a distância dos nós.
Providenciar um conjunto de APIs suficientes, sem realmente
reforçar a maneira como são usadas, em que ninguém considerará
usar alguma outra infra-estrutura de cluster básica para basear as suas
soluções de HA (High Availability).
4.1 Estrutura Cluster
Os componentes seguintes formam o núcleo da estrutura de cluster:
Camada de canal;
Camada de ligação;
Camada de integração;
Camada de recuperação;
Existem também quatro serviços chave que são importantes para as
APIs básicas de cluster:
JDB: guarda
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Linux Clustering 21
Camada de Quorum: determina quem é o quorum
Serviços de barreira;
4.1.1 Camada de Canal
É a camada física de comunicação de baixo nível. Esta camada
mantém múltiplas interfaces (que podem ser IP, série, SCSI, por
exemplo). A descoberta da vizinhança é feita em cada interface via
broadcast, e depois de um vizinho ser encontrado, é gerado um
handshake que cria um canal ponto-a-ponto para esse vizinho sobre
uma dada interface. O canal suporta entrega de dados sequencial,
verificação de estado de ligação permanente, e reset controlado em
caso de erro. As interfaces são totalmente independentes umas das
outras. Se a mesma máquina é encontrada em múltiplas interfaces (ie.
Existem múltiplas conexões para aquele host), a conexão na interface
é mantida independentemente das outras. Cada canal de baixo nível
tem uma métrica que determina o quão “bom” que um canal é para
conduzir tráfego do cluster. Um ligação de baixa performance está
definido como tendo métrica negativa: linhas serial devem ter esta
propriedade, por exemplo.
4.1.2 Camada de Ligação
Criada na camada de canal, a camada de ligação constrói um
mecanismo de comunicação de alto nível que liga todas os canais
disponíveis a um dado host. A ligação pode estar num de quatro
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Linux Clustering 22
estados a qualquer momento:
DOWN: Sem conexão para o host remoto;
RESET: Aconteceu um erro e todos e os canais estão a reiniciar;
DEGRADED: Pelo menos um canal está em cima, mas a métrica é
negativa;
UP: Pelo menos um “bom” canal está em cima e a correr.
Quando se constrói um novo estado de cluster, as camadas mais
altas usarão uma ligação degradada para executar uma transição
limpa excluindo um dos nós nessa ligação do cluster. É possível utilizar
a ligação degradada para executar esta acção de uma forma clara,
ajustando o quorum de modo a ter em conta a sua partida.
4.1.3 Camada de Integração
Esta camada executa transições por toda a topologia de cluster,
juntando clusters vizinhos, excluindo membros mortos ou de mau
comportamento e assegurando transições transaccionais entre
topologias cluster.
É necessário definir muito cuidadosamente o que é um cluster no
seu contexto. Um cluster é um acordo entre um conjunto de nós em
que esses nós podem comunicar uns com os outros e estão aptos a
formar um trabalho conjunto útil. O Cluster não é apenas o conjunto
de transições, como a entrada de um novo nó no cluster, são
operações atómicas em que todos os nós concordam coma nova
topologia do grupo. Estas transições são transaccionais e atómicas.
Aqui, um conceito chave é o Cluster ID. O ID é único para uma
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Linux Clustering 23
simples “encarnação” do cluster. Sempre que um cluster se parte em
múltiplos bocados, alguns subclusters sobreviventes que têm mais de
metade dos votos do cluster antigo ou que guardam o seu cluster ID:
todas as outras máquinas são excluídas do cluster e têm que obter um
novo cluster ID.
Um cluster ID novo é gerado sempre que a máquina entra pela
primeira vez na camada de integração. Igualmente a máquina
avalia-se a si própria para formar um cluster de nó único. Como
resultado, nunca é necessário negociar ao aceder ou à saída do
cluster: apenas é necessário negociar com a totalidade dos cluster
acedendo ou saindo uns dos outros.
O Cluster ID inclui o nome do nó que gerou o ID, e a hora. Isto é feito
para gerar um cluster ID que seja único para sempre.
Cada cluster contém, também, um número sequencial que é
incrementado em cada transição, fornecendo aplicações com um
modo simples de votação para potenciais estados de cluster
alterados.
4.1.4 Camada de Recuperação
Esta é a camada que integra o “coração” do cluster com o “resto
do mundo”.
O trabalho principal da camada de transição é “recuperar” do
cluster as transições terminadas pela camada de integração. A
recuperação constitui uma multidão de operações.
Recuperação interna de todos os serviços permanentes
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Linux Clustering 24
registados deve ser executada. Isto geralmente envolve a
reconstrução do estado global desse serviço baseado num (a)
conjunto de nós do novo cluster e nas diferenças entre esse e o
conjunto anterior, e (b) no estado deste serviço nesses nós.
Recuperação de serviços do utilizador. Estes serviços não
necessitam de estar a correr a todo o instante, e não
necessitam obrigatoriamente de possuir um estado global
interno. Numa transição de cluster, é necessário estar-se apto a
permitir serviços de utilizador tenham desaparecido do cluster
para serem reinstanciados num novo nó, ou para notificar
serviços que estejam a correr sobre a alteração do estado.
Mais importante, é necessário gerir a ordem em que estes serviços
são reiniciados.
A camada de transição deve então conhecer as dependências
entre os serviços. As dependências devem estar condicionadas pelo
uso dos nomes no Cluster Namespace: O Namespace pode fornecer
uma dependência de informação para o gestor das transições se
apropriado. Todavia, o namespace por ele próprio não consegue
controlo da recuperação: isto é o gestor da transição que permite
serviços separados para coordenar a recuperação passo a passo
controlada ao longo do cluster.
Um trabalho final do gestor da transição é o facto de ele necessitar
estar apto para retirar o acesso a alguns serviços do cluster até que a
recuperação esteja completa ( com ou sem a cooperação do serviço
interessado). É inteiramente possível que uma aplicação possa
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Linux Clustering 25
continuar cegamente ao longo da transição do cluster como se nada
tivesse acontecido (isto representa a Alta Disponibilidade a funcionar),
mas obviamente que quaisquer pedidos dessa aplicação ao sistema
de ficheiros do cluster têm de ser deferidos, enquanto esses serviços
são ajustados na recuperação.
4.1.5 JDB
Para guardar o estado local é requerida uma base de dados
transaccional. Todos os nós com um voto diferente de zero requerem
a existência uma JDB no seu local de armazenamento de
leitura/escrita em que a camada de quorum pode executar
actualizações seguras para simples configuração e informação de
estados.
4.1.6 Camada de Quorum
O Quorum é necessário para proteger o cluster na partilha de
estados persistentes. É essencial para evitar problema quando existe
uma “partição de cluster”: um possível tipo de falha em que alguns
dos membros do cluster perdem as comunicações com os restantes,
mas onde os nós, eles próprios continuam a trabalhar. Num cluster
particionado, é necessário um mecanismo em que se possa confiar de
modo a garantir que pelo menos uma partição tem o direito de
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Linux Clustering 26
actualizar o estado do cluster. (Este estado pode ser um disco
partilhado, por exemplo).
O Quorum é mantido pela atribuição de cluster, e o um número de
votos a cada nó. Isto é uma propriedade da configuração do nó. O
gestor do quorum guarda dois contadores de votos separados: o
cluster votes, que é o somatório de todos os nós que são membros do
cluster, e o expected votes, que é o somatório dos votos em todos os
nós que foram consultados por qualquer membro “votador” do cluster
(o armazenamento destes registos é a razão pela qual a camada de
quorum requer a JDB no seu desenho).
O cluster tem quorum se, e só se, possuir mais de metade de votos
separados. Isto garante que nós conhecidos que não estejam no
cluster não tenham a possibilidade de formar o quorum neles próprios.
4.1.7 Serviços de Barreira
Os serviços de barreira fornecem um básico mecanismo de
sincronização para qualquer grupo de processos do cluster. Uma
operação de barreira envolve todos os processos cooperantes que
esperam na mesma barreira: apenas quando todos eles alcançarem
a barreira é que podem prosseguir.
A operação de barreira é extensivamente requerida através do
código de recuperação para outros serviços, que é o que justifica esta
inclusão como serviço central do cluster.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Linux Clustering 27
4.2 Características
Na maior parte dos sistemas de cluster existentes, a recuperação é
um processo iniciado directamente depois e uma transição com
sucesso.
É necessário fazer uma clara distinção entre diferentes eventos que
possam ocorrer num cluster.
Transição: É o evento quando a lista de membros do cluster se
altera.
Recuperação: É a recuperação iniciada com respeito a essa lista
de membros.
Recuperação de pares: É a recuperação iniciada com respeito a
todos os pares do cluster.
Recuperação satélite: É a recuperação iniciada com respeito
aos satélites cujo nó é responsável.
4.3 Recuperação
Uma vez iniciada a recuperação pelo cluster, é necessário sinalizar
os vários daemons para recuperar em qualquer ordem. Obviamente a
tarefa de iniciar o cluster em primeiro lugar também obriga a
estabelecer os serviços numa ordem, e a ordem neste caso é ditada
pelas várias dependências dos serviços. Por outra palavras, o arranque
dos serviços do cluster quando um novo nó entra no cluster está
relacionado com a recuperação.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Linux Clustering 28
4.4 Cluster API
Neste capítulo serão apresentados aspectos relevantes para a
criação de APIs para clustering. Estes assuntos apenas se referem a API
expressa num único nó.
Aspectos a respeitar:
Aquando do desenho da API para o cluster existe um número de
problemas específicos que necessitam ser resolvidos:
Negociar com os clientes “mortos”.
Segurança.
Nomeação dos nós do cluster.
As necessidades especiais para serviços de recuperação.
APIs consistentes.
Isolamento da complexidade futura de clusters hierárquicos.
Implementação flexível. Todas as aplicações a serem
desenvolvidas devem ser capazes de ser implementadas em espaço
kernel e em espaço user se necessário.
4.5 Negociar a morte do cliente
É absolutamente imperativo que o código que implementa o
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Linux Clustering 29
serviço em cada nó está apto a detectar a morte do processo cliente
que detém um recurso do cluster, deste modo ele pode libertar o
recurso. Se o serviço está a ser implementado no kernel, então
obviamente é fácil para determinar a morte do processo, mas esta
funcionalidade é também necessária para serviços implementados
por daemons.
Um caminho de obtenção desta notificação, é o serviço ser
implementado sobre sockets. Os sockets de domínio unix têm uma
eficiência razoável para intercomunicação de processos locais, e o
servidor pode facilmente detectar a morte de um processo
conectado por um socket.
A implementação em kernel da funcionalidade de cluster
provavelmente utiliza chamadas de sistema dedicadas, mas as
implementações kernel têm sempre mais liberdade para aperfeiçoar
a funcionalidade necessária. Isto é a implementação do user space
que é mais restringido pela funcionalidade unix disponível.
4.6 Segurança
Porque é necessária a segurança?
Os nossos sistemas de ficheiros, filas de impressoras utilizarão recursos
do cluster. Todos eles requerem barreiras para recuperação; alguns
requerem bloqueios de cluster. Se for necessário permitir acesso não
restrito a estes recursos por utilizador, então é dado o acesso a um
utilizador não privilegiado para violar a integridade do cluster.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Linux Clustering 30
O mapeamento por Unix UID (user ID) não é suficiente para resolver
o problema da segurança. Em grandes clusters hierárquicos devem
existir muitos UID’s a participar no cluster. É também necessário
suportar namespaces particionados: não apenas os recursos
individuais devem estar inacessíveis ao utilizador errado, é necessário
algumas vezes que o namespace não seja localizável para os clientes
não privilegiados: desta maneira é necessário uma protecção no
namespace, e não apenas protecção do UID em objectos individuais.
Para desenvolvimento de API’s do core do cluster, é proposto um
simples mecanismo para permitir domínios de segurança múltiplos:
simplesmente usa o sistema de ficheiros para mediar a comunicação
entre processos cliente e serviços críticos do cluster, e utiliza nomes de
ficheiros para a atribuição de nomes aos domínios de segurança.
4.7 Atribuição de nomes aos nós
Considerando um cluster hierárquico que contém o nível de topo
ORG, e sub-clusters seguintes ORG/UK/EDIN/DEV/TESTE/TESTE1. Um nó
neste cluster (ORG/UK/EDIM/DEV/TESTE/TESTE1/TEXTBOX2) pode querer
participar nos serviços do cluster em qualquer um destes níveis. Para
isso, é necessário ser especificado exactamente qual destes clusters
nos estamos a referir em todas as chamadas da API ao recurso do
cluster. Afortunadamente, o acesso aos serviços do cluster é baseado
no nome proposto para os domínios de segurança é também ideal
para separar o acesso aos diferentes clusters: simplesmente inclui-se o
componente nome do cluster no caminho usado para aceder ao
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Linux Clustering 31
socket do cluster. Deste modo aparece um requisito que obriga que
qualquer nome do cluster não pode aparecer mais do que uma vez
num cluster hierárquico, uma vez que estes nomes representam
referências únicas a um nível específico de um cluster hierárquico num
dado nó.
4.8 Serviços recuperáveis
As coisas são mais complexas quando se trata de recuperação. As
API’s devem estar disponíveis a continuar a trabalhar selectivamente
durante a recuperação. Como um exemplo, a API de barreira deverá
ser usada por um par de processos do utilizador cooperativos em dois
nós diferentes, quando um terceiro nó entra ou sai do cluster. Esta
transição do cluster não afecta a barreira, deste modo as aplicações
do utilizador não deverão notar qualquer alteração: a API de barreira
deverá aguardar temporariamente durante a transição. Todavia, um
serviço interno do cluster, como o serviço de namespace, é uma
matéria completamente diferente: este confia na API de barreira de
modo a sincronizar a sua própria recuperação.
Similarmente, o bloqueio do gestor de tráfego deve ser suspenso
durante a transição, mas um sistema de ficheiros de cluster deve
poder executar as suas próprias operações de gestão de bloqueios
durante o período de recuperação.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Linux Clustering 32
4.9 Entrega de eventos assíncronos
Uma das funcionalidades importantes que uma API de cluster
deverá estar apta a executar, é a entrega de eventos assíncrona a
processos. As transições do cluster, privam-se da barreira se um nó
participante ou um processo morre ou uma notificação de que um
processo quer retirar o bloqueio, são todos eventos assíncronos que
um processo que utilize a API cluster deverá negociar.
Deste modo, como é possível dirigir as chamadas de retorno do
cluster para o processo do utilizador? O mecanismo normal para isto é
usar sinais. Contudo, existem vários problemas, sendo eles:
Não é necessário que o serviço crítico do cluster corra com
privilégios para matar todos os processo nos sistema ;
É impossível passar a informação arbitrária através de um sinal
que não implemente sinais em filas POSIX;
O cliente não pode especificar quantos sinais foram
recebidos;
Existe um número limite de sinais disponíveis, mas
arbitrariamente muitos eventos diferentes que podem ocorrer num
cluster.
Estes problemas podem ser todos resolvidos com a utilização de
sockets. É possível permitir que o cliente forneça um cookie de
informação ao servidor para ser associado com um potencial evento
futuro. Se esse evento ocorrer, o servidor simplesmente retornará esse
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Linux Clustering 33
evento ao cliente via socket reservado para essas chamadas de
retorno. Mesmo se a implementação do Unix a ser utilizada apenas
suportar SIGIO, que é suficiente para a parte local da bibioteca da API
apanha o IO, decifrar o cookie e executar o “callback”.
Isto obviamente restringe a liberdade do chamador para usar o
SIGIO. Isto é inevitável se o SIGIO não estiver disponível. Em recentes
Kernel’s Linux é possível usar filas de SIGIO em tempo real para utilizar
diferentes sinais de “callback” assíncrono para o socket, para evitar
interferências com os sinais normais.
Obviamente, é requerido um mecanismo que bloqueie os sinais,
que deverá ser exposto de um modo manual ao utilizador.
Mais do que um problema, é preciso ter um modo de sincronizar os
cookies com outros eventos de primeiros plano. É esta a
responsabilidade da biblioteca de API’s no processo utilizador (user
process). Por exemplo, se um utilizador criar um bloqueio com uma
chamada de retorno, e depois apaga esse bloqueio, existe uma
chance de que o servidor tenha já enviado de volta a chamada
nesse bloqueio: a API deve, quando está a decifrar o cookie, detectar
que a chamada já não é válida e deve silenciosamente abandoná-la
antes de a entregar à aplicação.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 34
5 Ferramentas de Clustering em Linux
As ferramentas de clustering em Linux que de seguida serão
apresentadas representam uma pequena amostra das soluções
comerciais existentes no mercado actual. Segundo especialistas na
matéria, a maioria destas ferramentas encontram-se no top ten de
soluções de clustering em Linux.
5.1 Cluster Server 6 – TurboLinux
O Cluster Server 6 é considerado líder no mercado de soluções de
software para Linux. Esta ferramenta fornece aos clientes alta
disponibilidade, redundância do sistema, escalabilidade e segurança.
Esta ferramenta permite ao administrador “clusterizar” outros
servidores Linux.
O CS6 é apenas instalado em servidores designados ATM
(Advanced Traffic Managers), como os Turbo Linux ou o Red Hat 6.2.
Todos os outros servidores do cluster não requerem software adicional
para clustering.
O diagrama seguinte mostra os possíveis servidores que podem
participar num cluster e que servidores podem suportar o ATM.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 35
Fig. 3 – Servidores possíveis
Este produto contém duas características fundamentais: gestor de
tráfego avançado e a consola de gestão do cluster.
5.1.1 Gestor de tráfego avançado
Fig. 4 – Esquema do gestor de trafego avançado
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 36
O gestor de tráfego avançado (ATM) é o software responsável pelo
seguinte:
Configuração do cluster
O ATM primário lê o ficheiro de configuração e estabelece a rede
cluster baseada nessas configurações. Se algum dos nós são Linux,
então o ATM comunica directamente com esses servidores para
iniciar do encaminhamento de tráfego. Para os nós não Linux, o
administrador tem de configurar a informação separadamente.
Administração do cluster
O ATM primário responde a todos os pedidos da consola de gestão
do cluster (CMC) com informação apropriada. O ATM deve ter uma
conexão estabelecida com o CMC quer localmente na mesma
máquina ou remotamente via rede segura.
Gestão do tráfego
O ATM primário recebe os pedidos de conexão iniciais dos clientes
e encaminha-os para o nó apropriado baseando-se no esquema de
encaminhamento de tráfego e no esquema de balanceamento da
carga, anteriormente escolhidos.
Uma vez estabelecida a conexão, o ATM não mais interfere no
tráfego entre o nó servidor e o tráfego do cliente, a menos que o
administrador seleccione a metodologia NAT (Network Address
Translation).
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 37
Sincronização
O ATM primário é capaz de sincronizar toda a informação de
configuração com o ATM de backup, bem como todos os nós Linux
do cluster. Esta funcionalidade é activada pelo administrador na CMC
e deve ser executada depois de qualquer alteração na configuração
do cluster.
Endereçamento Virtual
Para a comunidade Web, todo o cluster é o ATM com um endereço
IP único. Esta característica permite ao administrador facilmente
colocar o serviço requerido na Internet, com o mínimo de trabalho
para o número de servidores envolvidos.
Verificação de aplicações
O ATM monitoriza todos os serviços a correr no cluster e executa
uma determinada acção se um problema é encontrado. O ATM
executa todos os agentes de aplicações registados para os serviços
que o administrador quer monitorizados.
Verificação de servidores
O ATM monitoriza os problemas de hardware dos respectivos nós. Se
algum nó falhar, todo o tráfego para esse servidor é re-encaminhado
para outros servidores e uma mensagem é enviada para o
administrador via CMC.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 38
Relatórios
O ATM primário guarda o relatório (log) de toda a informação
pedida seleccionada pelo administrador. Estes logs podem ser
sincronizados com os ATM backup se desejado pelo administrador.
Servidor ATM
O ATM primário e os seus backups podem também participar como
servidores dentro do cluster. Isto causa um impacto no desempenho
do clientes agarrados a esse servidor, como o ATM necessita de
processar a entrada de tráfego periodicamente, causando a divisão
do tempo de processamento entre servidores de clientes e operações
de clientes Web. Contudo, os testes feitos pela TurboLinux indicam que
este impacto é mínimo permitindo ao administrador tirar vantagem de
todos os servidores disponíveis.
Failover do ATM primário
Os “ATMs” de segurança (backup) verificam periodicamente a
disponibilidade do ATM primário e rapidamente elegem um novo ATM
primário se algum problema for encontrado ou se o ATM primário fica
subitamente indisponível.
5.1.2 Consola de gestão do cluster
A consola de gestão do cluster (CMC) é um utilitário baseado no
ambiente Web que contém as seguintes funcionalidades:
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 39
Configuração do cluster
A CMC permite ao administrador criar e actualizar o ficheiro de
configuração do cluster. Uma vez feitas as alterações, o administrador
pode activar o cluster ou simplesmente adicionar novos servidores ao
cluster.
Monitorização em tempo real
A CMC contém um utilitário de monitorização em tempo real que
permite ao administrador visualizar o desempenho do cluster sem
causar impacto no acesso dos clientes. Esta ferramenta apresenta ao
administrador a seguinte informação:
Desempenho dos nós;
Desempenho da carga;
Monitorização de serviços;
Monitorização de “sites”
Sincronização
A CMC fornece ao administrador a capacidade para sincronizar a
configuração do ATM primário para os ATM de segurança. A
informação é também enviada para todos os servidores Linux do
cluster, mas não é enviada para servidores Windows 2000/NT ou
servidores UNIX. A CMC também sincroniza conteúdos ao longo de
todos os nós.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 40
Activação de Logs
A consola permite ao administrador consultar os ficheiros de log
como estão a ser gerados. As entradas mais recentes são mostradas
ao administrador. Se o administrador necessitar de um histórico maior,
este está disponível na consola do ATM primário.
Os administradores podem também activar o ficheiro do log
“speelink” a partir da linha de comandos. Estes ficheiro mostra todo o
tráfego IP de entrada. No entanto, este log causa um grande impacto
na performance e só deverá ser activado se for necessária uma
gestão detalhada.
Acesso local e remoto
A CMC pode estar localizada em qualquer localização do cluster,
usualmente no ATM primário ou no servidor remoto. Todas as conexões
remotas usam tecnologia de encriptação SSL, o que faz com que o
URL seja https:// ... em vez de http:://... .
Acesso seguro
A consola de gestão usa uma tecnologia de encriptação standard
para proteger toda a informação que é transferida entre o ATM
primário e o servidor CMC.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 41
5.1.3 Características tecnológicas
Gestão de tráfego
O CS6 trabalha com três métodos de comunicação cliente-servidor
mais comuns.
“Routing” directo: Esta metodologia de comunicação
fornece a melhor performance. Contudo, o ATM primário e o nó
servidor têm de correr na mesma sub-rede. O ATM primário notifica
o nó do endereço IP do cliente e o nó executa uma conexão
directa com o cliente sem a necessidade de enviar qualquer
informação. O diagrama seguinte mostra uma simples conexão
utilizando este método.
Fig. 5 – Conexão através de routing directo
Todos os nós, independentemente da plataforma do sistema
operativo, necessitam de estar configurados para este serviço correr
de forma correcta. O ATM primário automaticamente configura todos
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 42
os nós Linux; contudo os servidores UNIX e Windows 2000/NT
necessitam de configuração adicionais por parte do administrador.
Túnel: Este método de comunicação permite uma
performance óptima quando o ATM primário e os seus nós estão
localizados em diferentes sub-redes. Similarmente ao routing
directo, o nó comunica directamente com o cliente como mostra
o seguinte diagrama.
Fig. 6 – Comunicação por túnel
NAT (Network address translation): Este método de
comunicação é comum em redes Windows e não requere
configuração manual de nós individuais pelo administrador. Um
benefício do NAT é que ajuda a preservar o número de endereços
IP. Contudo, o NAT não permite uma comunicação directa entre o
cliente e o servidor, logo todo o tráfego do nó para o cliente tem
de passar pelo ATM primário. Isto diminui o desempenho e deve ser
considerado quando se desenha uma solução cluster. A figura
seguinte mostra o NAT em acção.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 43
Fig. 7 – Comunicação via Network Address Translation (NAT)
Balanceamento
Todas as soluções de clustering escolhem a alta disponibilidade e a
redundância do sistema como características e benefícios principais.
Estas características são aperfeiçoadas usando a configuração do
balanceamento da carga de trabalho ou a configuração do failover.
Load Balancing: Esta configuração tira vantagens de
todos os servidores do cluster e maximiza a disponibilidade de
computação no cluster. Cada pedido de um cliente ao ATM
primário é transferido para um servidor disponível baseado em dois
algoritmos: Round Robin ou Round Robin Pesado.
Estes algoritmos são seleccionados e configurados pelo
administrador baseando-se na solução requerida. O Round Robin
simplesmente escolhe o próximo servidor do cluster para
igualmente espalhar todos os pedidos entre os servidores. O Round
Robin Pesado, permite seleccionar os servidores para receberem
mais conexões de clientes. O balanceamento da carga suporta
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 44
alta disponibilidade e redundância, porque qualquer servidor que
falhe é imediatamente ignorado diante do cluster.
Failover: O failover, no CS6, significa que um serviço é
colocado no modo “Stand by” noutro servidor activo. Este
método é basicamente um esquema Round Robin Pesado de
dois servidores, com um servidor a receber um peso de 100 e o
outro servidor 0. Se o servidor com maior peso falha, então os
pesos são alterados e o servidor de backup fica com o peso
100.
Agentes aplicacionais
O TurboLinux Cluster Server 6 trabalha com vários agentes
aplicacionais que monitorizam aplicações específicas no sentido de
garantir que o serviço está operacional. Estes agentes aplicacionais
correm no ATM primário e continuamente garantem que os nós do
cluster estão a operar correctamente.
Uma característica importante deste produto é proporcionar aos
administradores a criação e inclusão de agentes para uma aplicação
específica. Esta inclusão faz do CS6 completa em termos de
disponibilidade aplicacional.
Configuração
O Cluster Server 6 fornece uma enorme flexibilidade no
estabelecimento de clusters de ATMs, nós e até mesmo sub-clusters. O
utilitário CMC permite uma construção simples de “pools” para simples
administração e configuração.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 45
Routing Pools: A colecção dos ATM primários e backups é
chamada de “routing pool”. O administrador pode seleccionar um
ATM como primário e os restantes como backups ou permitir aos
servidores que eles próprios elejam um ATM para funcionar como
primário dinamicamente no arranque.
Server Pools: O conjunto de nós, independentemente do
sistema operativo, é chamado de “server pool”. Estes “pools”
podem conter todos os nós disponíveis ou dividir os servidores em
subgrupos para simplificar a administração.
Outra funcionalidade é a criação de uma pool de servidores
balanceados e pools separadas para pares servidores configurados
como servidores de failover.
5.2 ClusterWorX 2.1 – Linux NetworX
Os sistemas de clusters de hoje em dia trabalham com dezenas,
centenas e mesmo milhares de processadores, o que torna a gestão
exponencialmente complexa, podendo ser uma preocupação para
qualquer organização. Para manter o software actualizado e
monitorizar o estado do hardware é requerido um esforço significante.
Para reduzir este esforço, a Linux NetworX desenvolveu o ClusterWorX,
que fornece uma simples e amigável solução para a administração
de um cluster. O software de gestão torna as organizações mais
eficientes, permitindo dedicar recursos às suas aplicações, em vez da
gestão do sistema.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 46
O ClusterWorX fornece aos administradores um modo simples de
gestão e controlo do seu cluster. A arquitectura flexível e escalonável
do software permite aos utilizadores facilmente adicionarem nós à
medida que o sistema necessita. O ClusterWorX está designado para
ser fácil de configurar e estender para obedecer aos requisitos dos
administradores. O software usa um motor de eventos, permitindo aos
utilizadores configurarem a notificação automática para uma
variedade de variáveis. A clonagem integrada permite aos
administradores carregarem e actualizarem o sistema operativo e
outras aplicações de cluster em nós singulares ou no cluster interno
simultaneamente.
5.2.1 Características
Monitorização baseada em grupos de nós ou clusters inteiros;
Motor de eventos para administração automática do sistema;
Acesso remoto e seguro via SSL sobre Apache;
Controlo completo dos nós;
Monitorização do CPU, largura de banda da rede e
capacidades SWAP.
Notificação automática ao administrador em caso de falha;
Clonagem de discos integrada e gestão da imagem;
Fácil uso, GUI personalizado com tabuladores para um fácil
configuração;
Completa integração com hardware do tipo “Ice Box”;
Gestão de licenciamento;
Comunicação IP a “Ice Box” para maior escalabilidade;
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 47
Suporte de sensores LM para monitorização;
Comunicação SSH e série para os nós;
Controlos CLI baseados em SSH, e paralelos;
5.2.2 Arquitectura
O ClusterWorX é composto por três tipos de software:
Um GUI baseado num browser, uma monitor de Java Servlet a residir
no nó de instalação e um agente a residir em cada nó do cluster
(como demonstra a figura seguinte).
Fig. 8 – Arquitectura do ClusterWorx
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 48
O cliente GUI, construído com o componente Java Swing, fornece
um interface profissional aos administradores através do seu browser.
De modo a optimizar o desempenho de arranque, o cliente guarda
em cache o GUI. Logo depois do download inicial, o ClusterWorX
iniciará rapidamente, independentemente da velocidade da
correcção.
O software é composto pelo Java Servlet e por uma base de dados
para guardar informação da monitorização. O agente ClusterWorX,
desenvolvido em C++, reside nos nós e desempenha tarefas de
monitorização e administração, directamente através do host.
Geralmente, os três tipos são desenvolvidos e mantidos como módulos
independentes por razões de portabilidade, permitindo a qualquer
tipo ser actualizado ou modificado de uma forma independente.
Esta arquitectura de software cria uma plataforma modular, em que
os clientes podem criar as suas próprias aplicação, para trabalharem
dentro do ambiente ClusterWorX. Esta arquitectura é vital em termos
de segurança e possibilidade de acesso remoto.
5.2.3 Monitorização
A monitorização avançada do ClusterWorX permite aos
administradores consultarem mais de 50 detalhes dos sistema,
incluindo a utilização do CPU, o tipo de CPU, a largura de banda da
rede, a utilização de memória e o tempo de funcionamento. Os
detalhes do sistema estão agrupados em tabuladores, permitindo
várias funções de monitorização.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 49
Fig. 9 – Ecrã de monitorização dos detalhes do sistema
O ClusterWorX monitoriza por defeito a energia, a temperatura e a
conectividade da rede. As propriedades da monitorização são
definidas pelo administrador através de intervalos entre os agentes
que correm em nós individuais até aos “servlets” no servidor hosts. Estes
valores são guardados no servidor e reencaminhados para os clientes
como pedido. Em contraste às tecnologias de monitorização de
servidores, o cliente faz todo o trabalho gráfico de monitorização de
informação e cálculo de médias. O ClusterWorX fornece aos
administradores informação extensa acerca do poder dos seus
clusters através dos seus sensores LM. Estes permitem monitorizar o
consumo de energia, a velocidade e a temperatura da placa mãe.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 50
5.2.4 Eventos/Administração automática
Quando aparecem problemas no cluster, os administradores
podem configurar o ClusterWorX para automaticamente desligar,
reiniciar ou parar o nó em mau funcionamento. Isto é executado
através de um monitor de eventos, uma característica que permite
aos administradores escolherem os limites dos valores abaixo
demonstrados.
Fig. 10 – Criação de eventos/administração automática
Isto é uma acção correctiva a ser tomada antes dos problemas se
tornarem críticos.
Se os limites definidos pelo administrador são excedidos, o
ClusterWorX automaticamente executa uma acção. As acções por
defeito incluem o corte da corrente eléctrica e o reinicio do nó. Por
exemplo, o motor de eventos pode reportar e executar uma acção
definida pelo administrador, como por exemplo desligando o nó,
quando os processadores atingem uma determinada temperatura, ou
se a média de carga é muito alta. Os eventos são configurados pelos
administradores e permitem-lhes escolher a notificação a receber
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 51
quando um evento ocorre. Os eventos são também extensíveis no
sentido em que executam a monitorização dos valores definidos pelo
administrador e executam os “plug-ins” também por eles definidos. As
acções de personalização podem ser criadas através de scripts,
programas e outros.
Utilizando um algoritmo de notificação activo, o ClusterWorX
notifica os administradores dos problemas sem despejar e-mails
desnecessários. O e-mail informa os administradores que o cluster está
em mau funcionamento, o nome do evento accionado, o nó que
está com problemas, e a acção (se existir) que foi tomada, como se
pode verificar na figura abaixo. É enviado um e-mail por cada evento
accionado. Se o nó é reparado pelo administrador, mas falha mais
tarde, o evento é automaticamente accionado, sem que haja
qualquer intervenção administrativa. Para os que desejarem, os e-
mails podem ser direccionados para dispositivos sem fio, como é o
caso dos pagers ou dos telemóveis.
Fig. 11 – Mensagem de notificação do evento accionado
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 52
5.2.5 Plug-Ins/Arquitectura extensiva
Através de plug-ins os administradores podem adicionar
características e funcionalidades extra ao ClusterWorX. Um plug-in é
uma extensão a um programa que pode ser adicionado em tempo
de execução. Os plug-ins podem ser scripts Perl ou programas binários
e são executados pelo agente ClusterWorX. Todas as comunicações e
o host são dirigidas pela estrutura de trabalho dos plug-ins. Não há
necessidade do administrador programar qualquer das
comunicações. Para manter os nós em boa execução, são removidos
automaticamente os plug-ins zombie depois de um determinado
tempo. O ClusterWorX suporta três tipos de plug-ins: o execute, o
monitor e o startup.
Execute: Este plug-in executa uma acção em cada nó e
actua quando um evento é accionado pelo motor de eventos.
O “execute” pode ocorrer sem intervenção administrativa.
Monitor: Este plug-in recolhe continuamente estatísticas
vitais do cluster. Inclui a percentagem de utilização do CPU,
conexões de rede, e percentagens de memória utilizada. Estes
valores são continuamente actualizados em intervalos definidos
pelo administrador. Os administradores que desejem criar o seu
próprio “monitor” devem criá-lo em Perl.
Startup: Este plug-in recolhe informação estatística acerca
dos “reboots” de cada nós. Esta informação é guardada na
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 53
base de dados do ClusterWorX. Os valores estatísticos incluem o
tipo de CPU, a versão do sistema operativo e a informação da
memória.
5.2.6 Gestor da imagem
A consistência da imagem do disco é realizada através da
clonagem de discos – um processo de cópia rápida da imagem do
sistema de um host ClusterWorX para um nó individual do cluster. O
gestor de imagem do ClusterWorX permite aos administradores
correrem o sistema operativo e outras aplicações do cluster em nós
singulares ou em todo o cluster simultaneamente. Os administradores
constróem a funcionalidade que querem numa imagem, e depois
carregam o sistema operativo e as aplicações para um nó. Então, o
ClusterWorX clona a imagem para os nós seleccionados, poupando
tempo aos administradores, reduzindo o esforço que seria feito numa
instalação interactiva. No gestor de imagem, os administradores
podem criar diferentes tipos de imagens de discos – alguns são
especificamente voltados para configurações em cluster. As imagens
são guardadas no host para uso de leitura, criando uma imagem no
host que usualmente demora 15 minutos ou menos. Uma vez criado o
ficheiro, os nós individuais podem ser clonados em 3 minutos. O
ClusterWorX também suporta NFS, o que permite que os nós corram
sem disco (Disklessly).
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 54
5.3 DataGuard Convolo Cluster
O DataGuard fornece a disponibilidade aplicacional e a
integridade de informação que qualquer negócio em crescimento
necessita. Desenvolvido por engenheiros na “Mission Critical Linux,
Inc.” com provas dadas nas tecnologias de clustering em UNIX, o
DataGuard corre sobre hardware SCSI partilhado ou armazenamento
em FibreChannel, e pode ser utilizado em muitas aplicações
comerciais. Se o DataGuard detectar um problema de hardware ou
de software num membro de um sistema de cluster, as aplicações são
automaticamente reiniciadas num outro membro em funcionamento.
O DataGuard é especialmente útil para serviços heterogéneos de
ficheiros como NFS e SMB/CIFS, aplicações de bases de dados, e
servidores Web de conteúdos dinâmicos. Em adição, o DataGuard
pode ser usado em conjunto com outras aplicações de alta
disponibilidade de Linux, como o Linux Virtual Server (LVS), sendo
então possível desenvolver um site de comércio electrónico de alta
disponibilidade com uma integridade de dados e disponibilidade de
aplicações completa, em adição às capacidades de
balanceamento da carga de trabalho.
Um cluster DataGuard é constituído por dois membros sistema que
correm o software DataGuard e estão conectados a uma zona de
armazenamento partilhada e a uma rede comum. Estes sistemas
fornecem clientes com acesso a aplicações de alta disponibilidade,
mantendo a disponibilidade mesmo quando ocorre uma falha de
hardware ou de software. Um algoritmo avançado e um mecanismo
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 55
de monitorização de cluster robusto asseguram uma rápida tolerância
a falhas e completa integridade dos dados a todo o instante.
Para criar uma aplicação ou informação altamente disponível num
cluster DataGuard, os administradores configuram o serviço de cluster,
que consiste num grupo de propriedades e recursos. As propriedades
pode incluir o membro sistema em que o serviço vai correr. Os recursos
podem incluir uma aplicação script de “start and stop”, o
armazenamento de discos partilhados, e um endereço IP, que dá um
acesso transparente ao serviço. Por exemplo, pode-se configurar um
serviço cluster que exporta sistemas de ficheiros de alta
disponibilidade ou que proporciona clientes de rede com acesso a
uma base de dados de alta disponibilidade ou até um servidor Web.
Depois de adicionado o serviço, o cluster inicia-o no sistema membro.
Cada sistema membro pode correr qualquer serviço de cluster e
aceder à informação do serviço numa zona de armazenamento
partilhada. Para manter a integridade dos dados, o cluster assegura
que o serviço corre apenas num membro a cada momento.
O DataGuard proporciona a configuração do modo active-active ,
em que cada membro do sistema corre diferentes serviços. É possível
também, executar uma configuração Hot-standby, em que o membro
primário corre todos os serviços, e o membro de backup é accionado
apenas se o primário falhar. A figura seguinte mostra uma
configuração cluster do tipo active-active.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 56
Fig. 12 – Configuração “active-active”
O DataGuard utiliza vários mecanismos de monitorização para
obter uma “ideia” considerável acerca do estado dos membros do
cluster. Se o cluster detecta uma falha que faz com que o membro
não consiga executar os serviços, o sistema é desactivado, e os
serviços são reiniciados noutro membro do sistema. O processo que
paragem automática e reinicio de um serviço é chamado de Service
Failover (Tolerância a falhas para serviços). Durante o failover,
nenhuma informação do serviço é perdida, significando apenas uma
pequena ruptura para os utilizadores.
Por exemplo, na figura anterior, se o membro da esquerda falhar, o
cluster reiniciará o serviço A e B no outro membro do sistema. O
serviço C não será afectado, continuando a sua execução.
Quando um sistema que falhou arranca novamente apresentando
o requisitos para membro do cluster, este pode reentrar e correr
novamente os serviços. O DataGuard fará um novo balanceamento
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 57
dos serviços ao longo dos membros do sistema, caso os serviços
estejam configurados para este aspecto. Também, um administrador
pode manualmente parar um serviço e reiniciá-lo noutro membro do
sistema. Este procedimento é chamado de service relocation
(realocação de serviços). Esta nova alocação permite que
manualmente se balanceie os serviços ao longo dos membros do
cluster e manter a disponibilidade dos serviços no caso de um sistema
necessitar de manutenção.
5.3.1 Características principais
Alta Disponibilidade para NFS, SMB/CIFS, e aplicações
comerciais
O DataGuard proporciona a criação de muitas aplicações
comerciais de informação intensiva, altamente disponível. Assim, é
possível configurar um serviço cluster para criar uma base de dados
Oracle, DB2, Sybase, Informix, PosgreSQL, ou MySQL de alta
disponibilidade.
Também é possível configurar um serviço de cluster para fornecer
uma partilha de ficheiros e serviços de impressoras para Linux, Unix, e
clientes Windows heterogénea. O DataGuard incluí um suporte
integrado para NFS V2 e serviços V3, e também serviços Samba, que
fornecem partilha de ficheiros baseada em SMB/CIFS a clientes
Windows.
A infra-estrutura do DataGuard para serviços do NFS assegura que
toda a informação relevante do estado do acesso do cliente é
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 58
tolerada juntamente com o serviço, a fim fornecer clientes com o
acesso ininterrupto e transparente aos dados do sistema. O
DataGuard é o único na indústria do Linux a fornecer esta
potencialidade. Além disso, quando um serviço do Samba falha, toda
a informação relacionada com a configuração do Samba é mantida
pelo cluster, de modo que os administradores não necessitem de
executar operações de configuração em cada membro do sistema.
Suporte da maior parte de distribuições Linux
O DataGuard suporte uma variedade de distribuições Linux,
incluíndo as distribuições RPM e baseadas em DEB. Embora não
obrigatório, é recomendado correr a mesma distribuição do Linux em
todos os membros do cluster. Contudo, é necessário correr a mesma
versão do Kernel em cada membro.
É possível escolher o hardware para configurar o cluster de acordo
com a “carteira” de cada um e a disponibilidade e integridade
necessária para as aplicações a utilizar. O DataGuard suporta desde
configurações de hardware de baixos custos até grandes
configurações (bastante caras) sem um único ponto de falha.
Minimamente, um cluster DataGuard requer dois membros, uma
conexão ethernet entre os sistemas, e pelo menos uma disco externo
partilhado para partições e informação dos serviços. Os membros do
sistema não necessitam de ser idênticos, mas devem ter subsistemas
de armazenamento simétricos. Através da retenção de cópias
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 59
privadas do sistema operativo, enquanto partilha informação vital dos
serviços, os membros do sistema podem ser encerrados sem que a
operação do cluster e a disponibilidade dos serviços sejam afectadas.
Um cluster pode incluir ligações SCSI ou conectores fibra óptica
para aceder à zona de armazenamento partilhada. Porque o
DataGuard não está dependente de características de
armazenamento de baixo nível como o Target Mode ou as reservas
SCSI para manter a integridade dos dados, existem muitas opções de
armazenamento à escolha. Também, o DataGuard acede a
armazenamento partilhado através de partições individuais, logo um
simples disco pode ser usado para múltiplos fins.
Os ambientes que não toleram os momentos de inactividade
devem duplicar os seus componentes hardware vitais de modo a
garantirem que uma falha no disco, na controladora, na rede, ou na
corrente eléctrica não cause a indisponibilidade do sistema.
O DataGuard suporta também uma automática tolerância a falhas
numa interface de rede. Se forem configuradas múltiplas interfaces de
rede num membro e a interface primária falhar, o DataGuard atribuirá
o endereço IP a outra interface que esteja a funcionar, sem
interrupções do cluster, clientes, ou aplicações. Ainda é possível,
configurar o DataGuard para ultrapassar falhas ao nível do MAC
address.
Instalação e administração simples
O DataGuard inclui scripts de configuração que orientam o
utilizador durante a configuração do cluster e um utilitário de
verificação que facilita a verificação do estado da configuração do
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 60
cluster.
Outro aspecto relativo à administração é o facto de o DataGuard
fornecer interfaces multi-utilizador. O utilitário cluadmin e o interface
gráfico (GUI) ajuda a configurar os serviços, monitorizar a actividade
do cluster, e a realocar serviços, quando necessário. Utilizando o GUI,
é possível executar as operações de cluster a partir de um browser
qualquer.
Como o GUI, o DataGuard também apresenta um CLI (Command
Line Interface) para todos os utilitários usados para configurar e gerir o
cluster e os seus serviços. Uma CLI pode estar incluída em scripts shell,
e facilmente integrada com várias estruturas de gestão do sistema.
Sempre que a configuração do cluster é alterada, a BD do cluster é
actualizada e as modificações são automaticamente propagadas
para todos os membros do sistema, eliminando a necessidade de
executar operações em duplicado em cada membro. Em adição, o
event log ajuda a detectar e a resolver problemas antes mesmo de
afectarem a disponibilidade do serviço.
5.3.2 Serviço de tolerância a falhas e balanceamento da
carga de trabalho
Para garantir alta disponibilidade e integridade de informação,
caso um membro não consiga correr serviços, o DataGuard executará
um failover automático, e reiniciará esses serviços no membro em bom
funcionamento
O serviço de failover deve ocorrer rapidamente sempre que um
problema aparece. Contudo, é importante que o cluster não conclua
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 61
erradamente que um membro de sistema falhou, o que provoca um
failover desnecessário.
O DataGuard usa inúmeros mecanismos de monitorização para
avaliar o estado dos membros. Periodicamente, cada membro do
sistema escreve o seu estado (“up” ou “down”) e a hora para as
partições do quorum na zona de armazenamento partilhada. Cada
membro também monitoriza o estado e a hora escritos pelo outro
membro, e envia os sinais vitais pela ethernet e pelos canais de série,
de modo a determinar se o sistema é capaz ou não de correr serviços.
Se o estado de um membro é “down” ou se o sistema não actualiza
a hora num determinado período de tempo, o DataGuard retirará os
serviços a esse membro.
O DataGuard também apoia os administradores na paragem
manual de serviços e na colocação destes noutro sistema membro.
Isto permite fazer um balanceamento de serviços e da carga de
trabalho ao longo dos sistemas membros. Também permite executar
tarefas de manutenção num sistema, mantendo todos os serviços do
cluster disponíveis. Por exemplo, caso seja necessário executar um
upgrade do hardware de um membro, é possível recolocar os seus
serviços noutro sistema membro, efectuar o upgrade, e depois voltar a
colocá-los no membro inicial.
É também possível, configurar um serviço para correr num membro
preferido, caso o membro esteja disponível. Isto permite ao
DataGuard a fazer a distribuição automática de serviços do mesmo
modo ao longo dos sistemas membros. Por exemplo, se o membro
preferido de um serviço reentra no cluster depois de ter falhado, o
DataGuard automaticamente recoloca o serviço no seu membro
preferido.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 62
5.3.3 Painel de configuração de serviços
O DataGuard fornece um simples painel para criar serviços cluster.
O utilitário cluadmin e o GUI permitem adicionar os serviços e fazer a
sua gestão. Através da configuração de serviços múltiplos numa
configuração do tipo active-active, é possível utilizar todos os recursos
de computação de um cluster.
Um serviço pode ter um único propósito, como a partilha de um
conjunto de sistemas de ficheiros, ou múltiplos propósitos, como o
caso de fornecimento de acesso a uma base de dados, e partilha de
sistemas de ficheiros. Existe uma grande variedade de tipos de serviços
que são possíveis de configurar.
Um serviço NFS exporta um ou mais sistema de ficheiros de alta
disponibilidade para clientes UNIX ou Linux. A cada serviço NFS é
atribuído um endereço IP virtual, que os clientes usam para acederem
a esse serviço. O membro do sistema que corre o serviço NFS responde
a este endereço IP e exporta o sistemas de ficheiros que estão
localizados em discos partilhados. Se o serviço NFS passar para outro
membro por motivo de falha, este sistema responderá ao endereço IP.
Esta mudança é transparente para os clientes, que apenas notarão
uma pequena pausa, uma vez que o DataGuard mantém as
permissões de acesso completo.
É possível também configurar o serviço SAMBA, que permite
partilhar um ou mais sistemas de ficheiros para clientes Windows. Assim
como o NFS, ao serviço SAMBA é atribuído um endereço IP virtual que
os clientes utilizam para aceder ao serviço.
O serviço de Base de Dados fornece um acesso de alta
disponibilidade a informação, como por exemplo o Oracle, MySQL,
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 63
DB2 EE, PostgreSQL, Informix, ou Sybase. Isto permite aos clientes,
incluindo os servidores Web, acederem a uma base de dados de alta
disponibilidade através da rede. Se um serviço falha, a aplicação de
base de dados pode continuar a aceder aos discos partilhados, e a
base de dados estará disponível para os clientes.
É também possível configurar um serviço que sobrepõe um Apache
em caso de falha. A cada serviço Apache é atribuído endereço IP
flutuante. A infra-estrutura cluster liga este endereço IP à interface de
rede no sistema membro que está actualmente corre o serviço. O
endereço IP flutuante assegura que sistema membro que executa o
Apache é transparente para os clientes http, em termos de acesso.
O DataGuard gere os serviços através da utilização de scripts para
iniciar e parar serviços nos membros do sistema. Por exemplo, quando
uma aplicação baseada em serviços falha, o cluster corre o serviço
script com o argumento para reiniciar a aplicação num membro
sistema em funcionamento. Quando um serviço NFS ou Samba falha,
o cluster executa um script para redireccionar o endereço IP flutuante
do serviço.
Para adicionar um serviço ao cluster utiliza-se o utilitário interactivo
cluadmin ou CLI, ou o GUI do DataGuard. O utilitário interactivo pede
a informação acerca do serviço especifico, enquanto o CLI permite a
inserção de toda a informação através de uma linha de comandos.
Com o GUI a informação sobre o serviço é introduzida através de
caixas de diálogo. Depois de o serviço ser adicionado o DataGuard
actualiza a base de dados do cluster com a informação do serviço e
propaga por todos os membros.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 64
Os serviços de cluster podem incluir as propriedades e os recursos
seguintes:
Service Name Cada serviço tem que ter um nome único
Preferred
Member e
Relocation
Policy
Um serviço pode incluir um membro preferido, que é o membro
escolhido para correr o serviço, a não ser que tenha ocorrido uma
falha ou que manualmente tenha sido recolocado noutro
membro.
IP Address Um serviço pode incluir um ou mais endereços IP. É também
possível especificar a máscara de rede e endereços de
broadcast para cada endereço IP.
File Systems O serviço pode incluir um ou mais sistemas de ficheiros.
File System
Exports
Deve ser especificado um mais directórios para exportação, e
para cada directório exportado pode-se especificar um ou mais
clientes de exportação e suas opções.
Samba Shares Para sistemas de ficheiros com partilhas para clientes windows,
deve ser especificado o nome da partilha e do directório.
Start and Stop
Script Location
Para serviços que contornam a falha de uma aplicação, é
necessário a especificação dos scripts de arranque e paragem
dos serviços.
A janela do GUI que permite adicionar informação inicial sobre um
serviço de cluster é apresentada de seguida:
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 65
Fig. 13 – DataGuard Graphical User Interface
Depois de adicionar o serviço ao cluster, o DataGuard escolhe o
membro para correr o serviço. Se o membro preferido estiver em
funcionamento, o cluster iniciará o serviço neste nó.
O cluster monitoriza constantemente o estado do membro. Se o
membro estiver inactivo ou se o sistema não actualizar o conjunto de
timestamp no determinado espaço de tempo, o DataGuard
transporta os serviços que estão a correr para outro membro. Se forem
usadas fontes de alimentação redundantes, o cluster
automaticamente reiniciará os serviços num membro funcional e
reinicia o membro que falhou, logo que este esteja operacional,
retoma a execução dos serviço apenas se puder actualizar a
informação em ambos os nós.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 66
5.3.4 Administração do Cluster
Depois dos serviços serem adicionados ao cluster, pode-se utilizar
vários utilitários ou o GUI do DataGuard para monitorizar os serviços e
o estado do cluster. Pode-se também recolocar os serviços de um
membro para outro. Por exemplo, se for necessário fazer manutenção
num membro pode-se transferir os serviços para outro membro.
Também, pode-se parar e arrancar serviços, backup e restore da base
de dados de cluster, e modificar o rigor do conteúdo dos logs do
cluster.
O DataGuard também permite modificar algumas das variáveis de
configuração e definir o tempo de detecção de falhas para melhor
responder as necessidades do sistema e das aplicações. Em alguns
casos, pode-se reduzir o tempo de falha dos serviços.
A janela Dataguad GUI que mostra o estado do cluster e dos
serviços é a seguinte:
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 67
Fig. 14 – DataGuard GUI – Estados do cluster e dos serviços
5.4 Kimberlite Cluster – Mission Critical Linux
Utilizando a tecnologia de cluster Kimberlite que a “Mission Critical
Linux coloca disponível para a comunidade “Open Source” uma
ferramenta de alta disponibilidade destinada a aplicações de
negócio críticas.
Para responder às necessidades do mercado, um cluster deve
garantir uma completa integridade dos dados e também fornecer a
capacidade para manter a disponibilidade da aplicação no caso de
uma falha de hardware ou de sofware. Desenvolvido por engenheiros
com provas dadas na tecnologia de clustering para Unix, o Kimberlite
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 68
utiliza componentes de hardware redundantes, armazenamento em
discos partilhados, dispositivos de gestão de energia eléctrica, canais
de comunicação cluster robustos, e um mecanismo de tolerância a
falhas para reduzir estes requisitos.
Especialmente desenvolvido para aplicações de Base de Dados e
servidor web de conteúdos dinâmicos, é possível utilizar o cluster
Kimberlite em conjunto com outro sistema Linux de alta
disponibilidade, como o Linux Virtual Server (LVS), para criar um site de
comércio electrónico de alta disponibilidade com completa
integridade dos dados e disponibilidade de aplicações, em adição às
capacidades de balanceamento da carga.
A base da tecnologia do cluster Kimberlite é um algoritmo
avançado. Este algoritmo garante que o cluster mantém a completa
integridade dos dados a todo o momento através da utilização de
vários mecanismos de comunicação inter-nós:
Partições de quorum na zona de armazenamento partilhada
para proteger o estado do sistema;
Conexões ethernet e serial entre os sistemas cluster para
mensagens (heartbeat).
Para fazer uma aplicação e informação altamente disponíveis num
cluster, é necessário configurar um serviço de cluster, que é um grupo
discreto de propriedades de serviços e recursos, como as aplicações e
o armazenamento de discos partilhados. Por exemplo, é possível
configurar um serviço de cluster que forneça clientes com acesso à
informação da base de dados altamente disponível. A figura seguinte
mostra um exemplo de um cluster Kimberlite.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 69
Fig. 15 – Exemplo de um cluster Kimberlite
Ambos os sistemas cluster podem correr qualquer serviço e aceder
à informação na zona de armazenamento partilhada. Contudo um
sistema pode correr em apenas um cluster a cada momento de modo
a manter a integridade dos dados. É possível executar uma
configuração do tipo active-active em que ambos os sistemas cluster
correm os serviços, ou uma configuração hot-standby em que o
cluster primário corre todos os serviços, e o cluster backup comanda
apenas se o primário falhar.
Se ocorrer uma falha de Hardware ou de software, o cluster
desactiva o sistema que falhou para garantir que ele não continua a
receber e a executar pedidos à zona de armazenamento partilhada,
reinicia os serviços noutro cluster do sistema. A capacidade do serviço
de tolerância a falhas assegura que não são perdidos dados, e que
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 70
apenas haverá uma curta ruptura para os utilizadores. Quando o
sistema que falhou recupera, o cluster pode rebalancear os serviços
pelos dois sistemas.
Um administrador do cluster pode também claramente parar os
serviços que correm num cluster, e reiniciá-los noutro sistema. Este
serviço de recolocação permite manter a disponibilidade de
aplicação e dados quando são requeridas tarefas de manutenção.
5.4.1 Funcionalidades
Um cluster kimberlite inclui as seguintes funcionalidades:
Configuração no-single-point-of-failure
É possível configurar um cluster que inclui-a um array com dupla
controladora raid, múltiplos canais de comunicação serial, e sistemas
interruptos de corrente eléctrica (UPS) para garantir que nenhuma
simples falha resulte na perda de dados.
Alternativamente, é possível configurar um cluster de baixo custo
que forneça menor disponibilidade do que um no-single-point-of-
failure. Por exemplo, pode-se configurar um cluster com
armazenamento JBOD (just a bunett of disks), e mesmo com esta
configuração de baixo custo, o cluster mantém sempre a integridade
dos dados.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 71
Área de trabalho para configuração de serviços
O cluster kimberlite permite ao administrador facilmente configurar
os serviços que tornam a informação e as aplicações altamente
disponíveis. Através da especificação dos recursos usados no serviço e
outras propriedades do serviço, incluindo o nome do serviço, script de
arranque e de paragem e partições de disco. Quando é adicionado
um serviço, o cluster insere a informação na base de dados do cluster,
podendo esta ser acedida por ambos os sistemas cluster.
O cluster fornece uma área de trabalho fácil de usar para
aplicações de base de dados. Por exemplo, um serviço de base de
dados serve dados para uma aplicação de base de dados. A
aplicação a correr no cluster fornece acesso de rede a clientes da
aplicação, como o caso dos web servers. Se o serviço falha e “salta”
para outro cluster, a aplicação pode continuar a partilhar os dados. A
uma base de dados acessível por rede é usualmente atribuído um
endereço IP, que também “salta” juntamente com o serviço de modo
a manter um acesso transparente para os clientes.
Esta área de trabalho pode ser facilmente extendida a outras
aplicações, como aplicações de mail ou impressão.
Integridade dos dados
Para assegurar a integridade dos dados, apenas um cluster pode
correr um serviço e aceder aos dados de cada vez. Cada sistema
cluster pode estar directamente ligado à sua fonte de alimentação e
remotamente ligado a outra fonte de alimentação de outro sistema
cluster. Esta ligação remota permite a cada cluster desactivar
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 72
completamente o outro sistema cluster antes de reiniciar os serviços, o
que permite que um serviço corra em múltiplos sistemas e
possivelmente corromper informação.
Interface de administração
Uma interface de utilização simplifica a administração do cluster e
permite facilmente criar, iniciar e parar serviços, e monitorizar sistemas
e serviços. Um GUI está também disponível para monitorização do
cluster.
Capacidades de comunicação extensiva
Os sistemas clusters usam vários mecanismos de comunicação para
detectar eventos e manter as aplicações e os dados disponíveis. Por
exemplo, se um sistema cluster adquire um estado “pendurado” o
outro sistema desactivará completamente o sistema pendurado antes
de reiniciar os serviços. Isto previne o sistema pendurado de executar
operações de I/O a uma zona de armazenamento e de corromper
dados uma vez abandonado o estado.
Cada cluster monitoriza a capacidade da fonte de alimentação
remota e envia “pings” através da rede e canais série para monitorizar
a capacidade do outro cluster. Também cada cluster guarda
periodicamente informação acerca do estado do cluster em duas
partições de quorum localizadas na zona de armazenamento
partilhada.
A informação sobre o estado do sistema inclui qual dos dois é o
membro do cluster activo. Inclui também, qual o cluster onde corre o
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 73
serviço. Cada cluster verifica se o estado do outro está actualizado.
Para garantir uma operação de cluster correcta, se um sistema não
conseguir escrever em ambas as partições de quorum na altura do
arranque, ele não terá permissão para entrar no cluster. Também, se
um sistema cluster estiver a actualizar o seu timestamp e se os
heartbeats ao sistema falharem, o sistema cluster será removido do
cluster.
Capacidade de tolerância a falhas
Se ocorrer uma falha de hardware ou software, o cluster tomará
uma acção apropriada no sentido de manter a disponibilidade dos
dados e das aplicações. Por exemplo, se um cluster está impedido de
aceder ao serviço de partilha devido a uma falha de hardware, o
sistema será desligado (se possível) e reiniciado novamente o que o
obriga a iniciar num estado limpo. Os serviços que estavam a correr no
sistema que falhou num cluster restante. Os serviços que já corriam
neste cluster não serão afectados.
Capacidade de realocação manual de serviços
O cluster Kimberlite permite aos administradores facilmente e sem
consequências para os serviços num cluster e depois reinicia-los noutro
sistema. Isto permite aos administradores executarem tarefas de
manutenção num cluster, enquanto as aplicações e os dados
continuarem disponíveis.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 74
Relatório de eventos
Para garantir que os problemas são detectados e resolvidos antes
que afectem a disponibilidade dos serviços, é guardado um log de
mensagens através do syslog que é um sistema linux. É possível
também personalizar o nível de mensagens a serem guardadas.
5.4.2 Configuração do hardware do cluster
Uma configuração do hardware do kimberlite consiste no número
de componentes de hardware necessários. Para alta disponibilidade,
é possível expandir a configuração mínima e incluir hardware que
proporcione uma configuração sem um único ponto de falha. Uma
configuração típica deste tipo inclui os seguintes componentes:
Dois sistemas cluster com:
- Adaptador SCSI para ligação SCSI na zona de armazenamento;
- Placa de rede para acesso a clientes;
- Placa de rede para Heartbeats de rede ponto-a-ponto;
- Interface serie para ligação a fonte de alimentação remota;
- Interface serie para ligação a terminal server ou outro dispositivo
de consola.
Duas fontes de alimentação
As fontes de alimentação permitem que um cluster forneça energia
a outro cluster. A funcionalidade para remotamente desactivar um
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 75
sistema garante a integridade dos dados em qualquer condição de
falha. O cabo de energia para cada cluster está ligado a uma fonte
de alimentação. Também, cada sistema está remotamente ligado à
fonte de alimentação, que fornece energia ao outro cluster através
de ligação por porta serie. Esta conexão por série é utilizada para
remotamente reiniciar um cluster.
Armazenamento partilhado
Os serviços de cluster requerem um armazenamento partilhado que
possa ser acedido por todos os clusters. Para obter o máximo de
disponibilidade, pode-se ligar os sistemas cluster a um array com dupla
controladora RAID, e espelhar os discos ao longo das controladoras.
Para uma solução de baixo custo, é possível ligar os clusters para um
armazenamento JBOD.
Network switch
É recomendado que a configuração do cluster inclua um switch de
rede para facilitar as operações de rede. É também possível ligar
cada membro a uma rede.
Terminal server
É recomendado que a configuração do cluster inclua um terminal
server ou um KUM (keyboard, video, monitor) switch para facilitar
operações de consola para o cluster.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 76
UPS
Embora as UPS não sejam requeridas para a operação de cluster,
estes sistemas de alimentação são muito recomendados para
fornecer energia aos servidores e à zona de armazenamento, em caso
de falha.
A figura seguinte mostra um exemplo de uma configuração de
hardware de um cluster Kimberlite.
Fig. 16 – Exemplo de configuração de hardware de um cluster Kimberlite
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 77
5.4.3 Configuração do serviço do cluster
O interface do utilizador permite facilmente adicionar serviços de
cluster à base de dados de cluster através da especificação dos
recursos utilizados no serviço e nas propriedades do serviço. Isto inclui
o seguinte:
Nome do serviço: Cada serviço tem um nome que é único, e que
fornece um modo conveniente para identificar e gerir o serviço.
Endereço IP: Um endereço IP é utilizado para fornecer um acesso
transparente aos clientes.
Armazenamento: É necessário especificar as partições que serão
usadas no serviço, em adição às permissões de acesso, owner, e
group para cada dispositivo.
Localização da script: Se estiver a ser utilizado um script para
iniciar ou parar serviços, é necessário especificar o caminho completo
da sua localização.
Suporte desactivação: Isto permite ao administrador colocar um
serviço disponível por um período de tempo, sem que ele seja
eliminado.
Membro preferido: É possível especificar que um serviço corre
num nó particular a não ser que tenha ocorrido um failover ou que
seja movido manualmente.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 78
Política de boot no membro preferido: É possível escolher que o
serviço seja automaticamente relocalizado para o seu membro
preferido quando o sistema entra no cluster.
5.4.4 Administração do serviço de Cluster
Depois de criado o serviço, pode-se utilizador o interface do
utilizador para gerir os serviços do cluster. Por exemplo, é possível
executar as seguintes tarefas:
A amostragem do estado do sistema: é possível consultar o
estado de um serviço específico ou de todos os serviços, incluindo se o
serviço está a correr, desactivo ou em erro. Também é possível ver
informação detalhada acerca dos recursos e propriedades dos
serviços.
Modificação de um serviço: se necessário, pode-se alterar
qualquer recurso ou propriedade especificada aquando da criação
do serviço. Pode-se também adicionar mais recursos para um serviço.
Por exemplo, é possível alterar o endereço IP ou adicionar mais
sistemas de ficheiros.
Desactivar um serviço
Activar um serviço
Recolocar um serviço
Apagar um serviço
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 79
5.5 LifeKeeper
Hoje em dia, a maioria dos negócios vivem entre a necessidade de
sistemas que suportem aplicações críticas e as pressões para reduzir o
custo total das infra-estruturas. O LifeKeeper permite o melhor de
ambos através da alta disponibilidade em Linux.
5.5.1 Características principais
Alta Disponibilidade
O LifeKeeper para Linux é uma aplicação que garante a
disponibilidade continua de aplicações. O LifeKeeper mantém essa
alta disponibilidade de sistemas Linux em cluster através de um sistema
de monitorização, mantendo uma conectividade com o cliente e
fornecendo ininterruptamente acesso a informação acerca do local
onde os clientes residem – seja na Internet, Intranet ou Extranet.
Para activar o sistema automático e a recuperação de aplicações
caso o sistema falhe, o LifeKeeper permite às aplicações executar o
failover para outros servidores (nós) do cluster. Isto ajuda o LK a
minimizar o risco de um único ponto de falha e permite aos sistemas
Linux conhecerem os requisitos de disponibilidade de operações
críticas através de um ambiente de falhas elástico.
Elasticidade
O LifeKeeper fornece elasticidade para ambientes Linux, permitindo
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 80
a outros servidores de um cluster apanharem as aplicações que
falharam noutro nó. O custo total é reduzido, porque o LK suporta uma
configuração active-active. Este modelo elimina a necessidade de
servidores extra dedicados a grandes backups e permite aos clientes e
às aplicações “saltarem” para outros servidores em produção.
Protecção Pro-activa
Com o LifeKeeper, uma falha de um componente de hardware ou
de uma aplicação é detectada antecipadamente da falha completa
do sistema através de múltiplos mecanismos de detecção de falhas. O
LifeKeeper monitoriza os clusters Linux, executando processos
inteligentes e múltiplos “batimentos” na LAN. Através do envio de sinais
redundantes entre nós servidores para determinar a capacidade do
sistema e das aplicações, o LK confirma o estado do sistema antes de
executar qualquer acção. Isto reduz o risco de um único ponto de
falha e minimiza os falsos “saltos” para outro nó. O LK também limita
failovers desnecessários recuperando as aplicações que falharam sem
um completo failover para outro servidor, se o hardware continuar
activo.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 81
Fig. 17 – Funcionamento do LifeKeeper
Failover transparente
Se um evento causar uma interrupção na disponibilidade de um
servidor, o LifeKeeper automaticamente move os recursos protegidos
e as aplicações para outro servidor do cluster. Sendo esta
movimentação transparente para os clientes, uma falha no sistema nó
causa impacto na produtividade dos utilizadores. O LK migra todas as
aplicações e transfere a conectividade da mesma forma, de modo
que os clientes continuam com acesso às aplicações e aos dados. Isto
assegura que os clientes que não são afectados por falhas qualquer
falha imprevista.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 82
Escalabilidade
O LifeKeeper fornece uma estrutura de trabalho que permite que o
número de utilizadores suportados por uma aplicação possa ser
aumentado através de uma simples aplicação de nós ao cluster. Para
assegurar protecção a falhas, o LK também suporta escalabilidade ao
nível aplicacional. Quando LK é instalado com uma configuração
multi-direccional, as aplicações que estão a correr numa máquina
podem ser “partidas” e passadas para máquinas separadas.
Fig. 18 – Demonstração da escalabilidade da aplicação
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 83
Acesso e integridade de informação
No ambiente de armazenamento partilhado do LikeKeeper, o
armazenamento está separado dos servidores do cluster. Toda a
informação está guardada num array de discos partilhados. Esta
independência permite o acesso aos dados sem se saber qual servidor
está a ser usado pela aplicação. Adicionalmente, o mecanismo de
bloqueio de armazenamento partilhado ajuda a manter a integridade
dos dados bloqueando a unidade de leitura de modo a que apenas
uma aplicação possa aceder a uma informação específica de cada
vez.
Operações de recuperação
O LK fornece protecção para ambientes Linux de tolerância a
desastres, falhas múltiplas do sistema ou rápida recuperação,
incluíndo:
Recuperação multi-direccional: O LK para Linux suporta
clusters de 4 nós com uma configuração multidireccional
de failover no contexto de 2 nós ligados ao mesmo disco
partilhado.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 84
Fig. 19 – Recuperação Multi-Direccional
Suporte de dados partilhados: O LK trabalha com uma
configuração do tipo n+1. Também suporta até 2 nós SCSI
partilhados. Isto permite a recuperação de aplicações
baseadas em discos SCSI partilhados entre dois nós do cluster
que estejam ligados ao mesmo disco partilhado. Nesta
configuração, um servidor, numa regra active-active, fornece
cópia de segurança para failovers a partir de qualquer um dos
nós do cluster.
Fig. 20 – Recuperação de dados partilhados
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 85
Failover em cascata: O LifeKeeper permite um failover em
cascata para 32 nós activos, para assegurar o acesso continuo
dos clientes no caso de falha de uma aplicação ou mesmo do
sistema.
Fig. 21 – Failover em cascata
Kits de recuperação de aplicações
O LifeKeeper fornece também ferramentas específicas para várias
aplicações, no sentido de monitorizar a capacidade da aplicação e
a recuperação automática em caso de falha.
Funcionamento durante upgrades ou tarefas de manutenção
Esta ferramenta permite a realização de actualizações e de todas
as tarefas de manutenção através de um failover manual. Com o LK o
tempo de realização destas tarefas é significadamente reduzido.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 86
5.6 Maui
O Maui é um programador avançado com um largo conjunto de
características apropriadas para plataformas de computação de alto
desempenho (HPC), incluindo os cluster Alpha e PC, SP, e sistemas
O2K. Usa políticas agressivas de agenda para optimizar a utilização de
recursos e minimizar o tempo de resposta. Simultaneamente, fornece
um controlo administrativo extenso sobre os recursos e cargas de
trabalho permitindo um alto nível de configuração nas áreas de
prioridades de trabalho, calendarização, alocação, clareza e políticas
de reserva. O mecanismo de QOS (Quality of Service) do Maui permite
entrega directa de recursos e serviços, dispensa de políticas, e acesso
controlado a características especiais. O Maui também possui uma
infra-estrutura avançada de reserva permitindo aos sites controlar
exactamente quando, e por quem os recursos são utilizados. Esta infra-
estrutura também proporciona suporte total de meta calendarização
não intrusiva. A interface Allocation Bank integrada fornece
funcionalidades adicionais permitindo a um site gerir a alocação de
recursos em tempo real com partilha de alocação em grupo,
expirações de alocação, etc.
O Maui foi desenhado baseado na experiência colectiva dos
centros HPC mais avançados do mundo. Fornece as ferramentas que
necessitam para controlar, seguir, e optimizar a utilização dos seus
recursos. Uma colecção de estatísticas extensivas e ferramentas de
perfil, operação de teste, e uma avançada simulação permite aos
sites em produção testar as alterações e configurações de modo
totalmente seguro, sem riscos. O Maui foi também desenvolvido para
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 87
ser altamente maneável com suporte de classificação detalhada,
diagnósticos internos, e ferramentas de análise de estados inteligentes
para permitir a um administrador inexperiente saber o porquê de
algumas questões comuns.
O Maui foi criado para oferecer uma gestão de trabalho e agenda
permitindo aos utilizadores continuar “o negócio habitual”. De facto,
os utilizadores não precisam de alterar nada no caminho que
tomaram e seguindo normalmente os seus trabalhos quando o Maui é
instalado. Todavia, se um utilizador quiser, existem muitas novas
funcionalidades e comandos que podem ser utilizadas no sentido de
aumentar a habilidade dos utilizadores para correr trabalhos quando,
onde, e como eles desejarem.
O schedule Maui, como o próprio nome indica, é um programador.
Não é um gestor de recursos. Um gestor de recursos, como o caso do
PBS, LoadLever, ou LSF, gere a fila de trabalho e os nós
computacionais. Um programador diz ao gestor de recursos o que
fazer, quando executar trabalhos e onde. Tipicamente, os utilizadores
submetem trabalhos e averiguam o estado da máquina e dos
trabalhos através do gestor de recursos. Quando o Maui está activo,
os utilizadores podem continuar a lançar os mesmos comandos do
gestor de recursos, como anteriormente. Todavia, O Maui também
oferece comandos para fornecer alguma informação e capacidades
adicionais.
As capacidades do Maui incluem muitos mecanismos internos para
melhorar o desempenho da agenda de tarefas, permitindo aos
utilizadores executarem mais trabalhos no mesmo sistema e obter os
resultados de volta mais rapidamente. Adicionalmente, o Maui
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 88
permite aos utilizadores fazerem reservas de recursos que garantem a
disponibilidade de recursos em horas particulares.
BackFill
Backfill é uma aproximação da agenda que permite que alguns
trabalhos “corram” fora de ordem de tal maneira que não respeitam
os trabalhos de prioridade mais alta. No sentido de determinar se um
trabalho deve esperar, cada trabalho deve possuir uma estimativa do
tempo que necessitará para correr. Esta estimativa, conhecida por
“limite do relógio de parede”, é uma estimativa do tempo de
“choque” ,isto é, o tempo desde o inicio do trabalho até ao seu fim. É
muitas vezes prudente no calculo exagerado deste limite, porque o
programador deve estar configurado para terminar trabalhos que
excedam os seus “limites do relógio de parede”. Contudo,
exagerando muito no tempo de wallclock prevenirá o programador
de estar disponível para optimizar a fila de trabalhos tanto como
possível.
O Maui também fornece o comando showbf no sentido de os
utilizadores verem exactamente quais os recursos que estão
disponíveis para uso imediato. Isto pode permitir aos utilizadores
configurarem um trabalho que estará apto a executar tão depressa
como ele é submetido apenas pela utilização de recursos disponíveis.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 89
5.7 MOSIX
Mosix é um conjunto de algoritmos adaptativos de recursos
partilhados que são gerados para melhorar a escalabilidade num
sistema de computação em cluster de qualquer tamanho, onde o
único componente partilhado é a rede. O “coração” da tecnologia
Mosix é a capacidade de múltiplos nós ( workstations e servers,
incluíndo SMP’s) trabalharem cooperativamente como se parte de
um simples sistema.
Para entender o que o Mosix faz, é feita uma comparação entre o
Multicomputador de Memória Partilhada (SMP) e a computação em
cluster. Num sistema SMP, muitos processadores partilham a memória.
As principais vantagens são o aumento do volume de processamento
e a rápida comunicação entre os processos (via memória partilhada).
Os SMPs podem ajudar muitos processos que correm
simultaneamente, com eficiente alocação e partilha de recursos.
Cada vez que um processo é iniciado, terminado, ou há alterações no
seu perfil computacional, o sistema adapta-se instantaneamente ao
ambiente de execução resultante. Ao contrário dos SMPs, a
computação em cluster é feita de colecções de workstations e
servidores, com diferentes velocidades e quantidades de memória,
possivelmente de diferentes gerações. Em sistemas de computação
em cluster o utilizador é responsável pela alocação dos processos aos
nós e pela gestão dos recursos do cluster. Em muitos sistemas CC,
mesmo que todos os nós corram o mesmo sistema operativo, a
cooperação entre os nós é bastante limitada porque a maioria dos
serviços dos sistemas operativos estão localmente restringidos a cada
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 90
nó. Os principais pacotes de software para o processo de alocação
nos CC são o PVM e o MPI. O LSF e o Extreme Linux fornecem serviços
semelhantes. Estes pacotes fornecem um ambiente de execução que
requere uma adaptação da aplicação e do conhecimento do
utilizador. Incluem ferramentas para atribuição de processos a nós.
Estes pacotes correm ao nível de utilizador, tal como as aplicações
comuns, estas são incapazes de responder a flutuações da carga ou
de outros recursos, ou para redistribuir adaptativamente a carga de
trabalho.
Na prática, o problema da alocação de recursos é muito mais
complexo porque existem muitos e diferentes tipos de recursos, ex.
CPU, memória, I/0, Inter Process Communication (IPC), etc. onde cada
recurso é usado de maneira diferente e na maioria dos casos o seu
uso é imprevisível.
Para o utilizador, os sistemas SMP garantem um eficiente e
balanceado uso de recursos entre todos os processos em execução,
indiferentemente dos requisitos dos recursos. Os SMP são fáceis de usar
porque empregam uma gestão de recursos adaptativa, o que é
completamente transparente para o utilizador. Os CC’s de hoje em
dia necessitam destas capacidades. Confiam na alocação estática
controlada pelo utilizador, o que é inconveniente e pode penalizar o
desempenho devido aos balanceamentos da carga.
O Mosix é um conjunto de algoritmos que suportam partilha de
recursos adaptativa num CC escalonável por migração dinâmica de
processos. Por estar disponível para alocar recursos globalmente, e
distribuir a carga de trabalho dinamicamente e eficientemente,
simplifica o uso da CC aliviando o utilizador da carga de gerir os
recursos de um cluster. Isto é particularmente evidente em ambientes
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 91
multi-utilizador, partilha de tempo e não uniformes CC.
5.7.1 O que é o Mosix?
Mosix é uma ferramenta para Linux constituída por algoritmos
adaptativos de partilha de recursos. Permite múltiplos Uni-
Processadores (UP) e SMP’s (nós) a serem executados no mesmo
kernel para trabalharem em cooperação fechada. Os algoritmos de
partilha de recursos do Mosix estão desenhados para responder on-
line às variações da utilização de recursos ao longo dos nós. Isto é
executado através da migração de processos de um nó para o outro,
preemptivamente e transparentemente para balanceamento da
carga de trabalho. O objectivo é o melhoramento do desempenho
do sistema cluster e a criação de um ambiente de multi-utilizador e de
partilha de tempo conveniente para a execução de aplicações
sequenciais e paralelas. O ambiente standard do Mosix é um CC, em
que os recursos do cluster estão disponíveis em cada nó.
Desactivando o processo automático de migração, o utilizador pode
alterar a configuração para um CC plano, ou mesmo para um modo
MPP (single-user).
A implementação corrente do Mosix está designada para correr em
clusters de workstations baseadas em X86/Pentium. Possíveis
configurações podem ir de um pequeno cluster de máquinas ligadas
por uma ethernet, até um sistema de alta performance, com um largo
número de servidores SMP (Pentium) que estão ligados por uma LAN
Gigabit (ex. Myrinet).
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 92
5.7.2 A tecnologia
A tecnologia do Mosix divide-se em duas partes: O mecanismo
Preemptivo (transparente) de Migração de Processos (PPM) e um
conjunto de algoritmos para partilha de recursos adaptativos. Ambas
as partes são implementadas ao nível do Kernel, usando um módulo
de carregamento, tal que o interface do Kernel não é modificado.
Desta maneira é completamente transparente ao nível de aplicação.
O PPM pode migrar qualquer processo, em qualquer momento,
para qualquer nó disponível. Usualmente, as migrações são baseadas
em informação fornecida por um dos algoritmos de partilha de
recursos, mas os utilizadores devem sobrepor quaisquer decisões
automáticas do sistema e migrar os seus processos manualmente.
Assim, uma migração manual pode tanto ser iniciada por um processo
sincronizado ou por um pedido explícito de outro processo do mesmo
utilizador (ou super utilizador). O processo de migração manual pode
ser útil para implementar uma política particular ou para testar
diferentes algoritmos de calendário.
Cada processo tem um único Home-Node (UHN) onde ele é criado.
Normalmente este é o nó onde o utilizador se validou. O modelo de
imagem do sistema do Mosix é um CC, em que todos os processos
parecem correr no seu UHN, e todos os processos da sessão do
utilizador partilham o ambiente de execução do UHN. Os processos
que migram para outros nós (remotos) usam (num nó remoto) recursos
sempre que possível, mas interagem com o ambiente do utilizador
através do UHN. Por exemplo, assume-se que um utilizador executa
variados processos, alguns deles migram para fora do UHN. Se o
utilizador executa o comando “ps”, é reportado o estado de todos os
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 93
processos, incluindo os processos que estão a correr nos nós remotos.
Se um dos processos migrados ler a hora actual, isto é, invocar o
gettimeofday(), obterá a hora corrente no UHN.
O PPM é a ferramenta principal para os algoritmos de gestão de
recursos. Tão longo como os requisitos para os recursos, assim como o
CPU ou a memória principal estão abaixo de um certo limiar, os
processos do utilizador estão limitados ao UHN. Quando os requisitos
para os recursos excedem alguns níveis, então alguns processos
devem ser migrados para outros nós, para tirar vantagem de recursos
remotos disponíveis. O objectivo fundamental é maximizar o
desempenho através de uma utilização eficiente dos recursos da
rede.
A granularidade da distribuição de trabalho no Mosix é o processo.
Os utilizadores podem correr aplicações paralelas iniciando múltiplos
processos num nó, e então permitir ao sistema atribuir estes processos
aos melhores nós disponíveis nessa altura. Se durante a execução dos
processos novos recursos ficam disponíveis, então os algoritmos de
partilha de recursos são designados a usar esses novos recursos para
uma possível nova atribuição dos processos ao longo dos nós. A
capacidade para atribuir e reatribuir processos é particularmente
importante para o fácil uso e para fornecer um ambiente de
execução multi-utilizador e partilha de tempo eficiente.
O Mosix não tem um controlo central ou uma relação mestre –
escravo entre os nós: cada nó pode operar como um sistema
autónomo, e isto faz todas as decisões de controlo
independentemente. Este estilo permite uma configuração dinâmica,
onde os nós podem entrar ou deixar a rede com rupturas mínimas. Os
algoritmos para a escalabilidade asseguram que o sistema corre bem
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 94
em grandes configurações da mesma forma que em configurações
pequenas. A escalabilidade é activada pela incorporação de
aleatoriadade nos algoritmos de controlo do sistema, onde cada nó
baseia a suas decisões no conhecimento parcial acerca do estado
dos outros nós.
5.7.3 Algoritmos de partilha de recursos
Os principais algoritmos de partilha de recursos do Mosix são o
balanceamento da carga de trabalho e tratamento da memória. O
algoritmo dinâmico de balanceamento da carga de trabalho tenta
continuamente reduzir as diferenças de cargas entre os pares de nós,
migrando para isso processos de nós de cargas elevadas para nós de
cargas mais pequenas. Este esquema está descentralizado – todos os
nós executam os mesmos algoritmos, e a redução das diferenças de
cargas é desempenhada independentemente por pares de nós. O
número de processadores em cada nó e a sua velocidade são
factores importantes para o algoritmo de balanceamento de cargas.
Este algoritmo responde alterações nas cargas dos nós. O algoritmo
de tratamento da memória é gerado para colocar um número
máximo de processos em memória RAM, para garantir tanto quanto
possível o trashing ou o swapping dos processos. O algoritmo é
activado accionado quando um nó apresenta um paging excessivo
devido à falta de memória livre. Neste caso, o algoritmo sobrepõe o
algoritmo de balanceamento e tenta migrar o processo para um nó
com memória livre suficiente, mesmo que esta migração resulte numa
distribuição de carga desigual.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 95
5.7.4 Migração de processos
O Mosix suporta a migração de processos preemptiva
(completamente transparente). Depois de uma migração, o processo
continua a interagir com o seu ambiente indiferentemente da sua
localização. Para implementar o PPM, o processo de migração está
dividido em dois contextos: O contexto do utilizador que pode ser
migrado, e o contexto de sistema – que é dependente do UHN, e não
deve ser migrado.
O contexto do utilizador, chamado “remoto”, contém o código
do programa, a stack, a informação, os mapeamentos de memória e
registos do processo. O “remoto” encapsula o processo quando está a
correr no nível de utilizador. O contexto sistema, chamado
“delegado”, contém a descrição dos recursos a que o processo está
ligado, e a “Kernel-Stack” para a execução de código do sistema em
proveito do processo. O “delegado” encapsula o processo quando
ele está a correr no Kernel. Detém a parte do contexto sistema do
processo, por isso necessita permanecer no UHN do processo.
Enquanto o processo pode migrar muitas vezes entre diferentes nós, o
“delegado” nunca é migrado.
O interface entre o contexto “utilizador” e o contexto “sistema”
está bem definido. Por conseguinte, é possível interceptar todas as
interacções entre estes contextos, e encaminhá-las ao longo da rede.
Isto é implementado na camada de ligação, com um canal de
comunicação especial para interacção. A figura seguinte mostra dois
processos que partilham um UHN.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 96
Fig. 22 – Migração de um processo
Na figura, o processo da esquerda é um processo regular em Linux
enquanto o processo da direita está “separado”, com a sua parte
“remoto” migrada para outro nó.
O tempo de migração é um componente fixo, para estabelecer
uma nova frame de processo no novo local (remoto), e um
componente linear, proporcional ao número de páginas de memória
a serem transferidos. Para minimizar o overhead da migração apenas
a tabela de páginas e as páginas de processos “sujos” são
transferidas.
Durante a execução de um processo no Mosix, é activada a
localização transparente através do encaminhamento de chamadas
dependentes do sistema para o “delegado” no UHN. A chamadas do
sistema são uma forma síncrona de integração entre os dois
contextos de processos. Todas as chamadas do sistema que são
executadas pelo processo são interceptadas pela camada de
ligação de locais remotos. Se a chamada do sistema é independente
do local ela é executada pelo “remoto” localmente. Por outro lado, a
chamada de sistema é encaminhada para o “delegado” que
executa a chamada de sistema em proveito do processo no UHN. O
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 97
“delegado” retorna os resultados para o local remoto, que então
continua para executar o código do utilizador.
Outras formas de interacção entre os dois contextos de processos
são a entrega de sinais e eventos de “levantar” processos, exemplo:
quando chega informação da rede. Estes eventos requerem que o
“delegado” localize sincronamente e integra com o “remoto”. Este
requisito de localização é encontrado através do canal de
comunicação entre eles. Num cenário típico, o kernel no UHN informa
o “delegado” sobre o evento. O “delegado” verifica qual a acção a
tomar, e caso necessário, informa o “remoto”. O “remoto” monitoriza
o canal de comunicação para reportar os eventos assíncronos, ex.
sinais. De notar que este aspecto é robusto, e não é afectado mesmo
por grandes modificações do Kernel.
5.7.5 A implementação
Na parte principal do projecto, foi implementado o código para
suportar as operações transparentes de processos “partidos”, com o
contexto “utilizador” a correr no nó “remoto”, suportado pelo
“delegado”, que corre na UHN. Ao mesmo tempo, é escrita a
camada de comunicação que faz a conexão entre dois contextos de
processos e desenhado o protocolo de interacção. A ligação entre os
dois contextos é implementada no topo de uma simples, mas
exclusiva, conexão TCP/IP. Depois disto, é implementado o
mecanismo de migração de processos, incluindo a migração para
fora do UHN e entre dois locais remotos. Então, o módulo de
disseminação de informação é criado activando trocas de
informação de estados ao longo dos nós. Usando esta facilidade, os
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 98
algoritmos para processamento e migração automática são
activados. Finalmente, é desenhado e implementada a API através do
/proc.
5.7.6 A API Mosix
A API do Mosix foi tradicionalmente implementada através de um
reservado conjunto de “chamadas de sistema”, que são usadas para
configurar, questionar e operar o Mosix. Em linha com a convenção
do Linux, a API foi modificada para ser mostrada via sistema de
ficheiros /proc. Isto também previne possíveis incompatibilidades
binárias dos programas entre diferentes versões de Linux.
5.7.7 Conclusões sobre o Mosix
O Mosix fornece uma nova dimensão de escalonamento para
computação em cluster com Linux. Permite a construção de um CC
de alta-performance e escalonável. A principal vantagem do Mosix
relativamente a outros é a capacidade de resposta em tempo real a
pedidos irregulares de recursos por vários utilizadores.
As maiores propriedades de execução de aplicações no Mosix
são a política de distribuição de recursos adaptativa, a simetria e a
flexibilidade de configuração. O efeito combinado destas
propriedades implica que os utilizadores não necessitam de conhecer
o estado corrente da utilização dos vários nós, ou mesmo o seu
número. Aplicações paralelas pode ser executadas permitindo ao
Mosix atribuir e re-atribuir processos aos melhores nós possíveis, como
um SMP.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 99
5.8 Piranha – Red Hat Linux
O Piranha é estritamente uma implementação de alta
disponibilidade. Piranha é o nome do package cluster, e também do
GUI de administração para o cluster. O sistema cluster é inteiramente
modular por natureza e pode ser completamente configurado e
executado em modo de texto, com interface de linha de comandos.
Os pedidos para serviço do Piranha são enviados para um
endereço virtual do servidor: um único triplicado consistindo num
protocolo, num endereço IP e número de porta. Dependendo do
papel que ele tenha, um computador num cluster Piranha ou é um
router ou é um servidor real. O router recebe pedidos de trabalhos e
redirecciona esses pedidos para os servidores reais que actualmente
processam os pedidos.
O sistema de clustering Piranha inclui os seguintes componentes:
Código Kernel IPVS;
Daemon IVS para gerir a tabela de routing IPVS via ferramente
IPVSADM.
Daemon Nanny para monitorizar servidores e serviços nos
servidores reais do cluster.
Daemon impulso para controlar os outros daemons e executar
failovers entre tabelas de routing IPVS.
Piranha GUI para administrar e gerir o ambiente cluster.
Todos estes daemons usam o mesmo ficheiro de configuração,
chamado /etc/lvs.cf por defeito. A função primária do Piranha é
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 100
iniciar e parar impulsos interactivamente e editar os conteúdos do
ficheiro de configuração.
O código IPVS fornece inteligência controlada. Ele procura tráfego
para entrada para servidores virtuais definidos e redirecciona cada
pedido para o servidor real, baseando-se num algoritmo de
calendarização adaptativo. O calendário suporta duas classes de
calendarização, cada uma com versão pesada e não pesada. Existe
o calendário básico Round Robin, que simplifica as rotações entre
todos os servidores reais activos. O calendário mais complexo,
conexões mínimas (Least Connections) guarda o histórico de
conexões abertas a todos os servidores reais e envia novos pedidos ao
servidor real com o número mínimo de conexões abertas.
As versões pesadas destes dois calendários, permitem ao
administrador misturar hardware heterogéneo e Osses como os
servidores reais, e têm a redistribuição da carga a refletir as diferenças
físicas entre as máquinas. Como benefício adicional, o Piranha
modificará adaptativamente este peso baseado nas médias da
carga dos servidores reais.
O IPVS suporta três tipos de configurações de rede: Network Address
Translation (NAT), tunneling e routing directo. O NAT requere que seja
atribuído um endereço público para o servidor(es) virtual(ais) e uma
sub-rede privada para os servidores reais. O Tunneling usa
encapsulamento IP e reencaminha os pacotes para servidores reais.
Este método requer que os servidores reais suportem um dispositivo de
tunneling para descodificar os pacotes. O routing directo reescreve a
informação do cabeçalho IP e depois reenvia o pacote directamente
para o servidor real. Cada serviço que corre no servidor real e que é
encaminhado como uma parte do servidor virtual é monitorizado por
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 101
um processo nanny que corre no router IPVS activo. Este serviço de
monitorização segue-se a um processo de dois passos. Em primeiro, a
ligação hardware/rede é verificada para garantir que o servidor real
está a responder à rede; segundo é enviada uma ligação para a
porta do servidor real que tem o serviço de monitorização a correr.
Uma vez conectado, o Nanny envia uma string de pedido e verifica-a
para ter a certeza que recebeu a string de volta. Este processo repete-
se a cada dois segundos. Se passar tempo suficiente sem existirem
ligações com sucesso, o servidor real é dado como “morto” e é
removido da tabela de routing IPVS. O nanny continua a monitorizar o
servidor real e quando o serviço volta a permanecer activo num
determinado espaço de tempo, o lugar do servidor na tabela de
routing IPVS é restaurado.
O router IPVS é considerado como um único ponto de falha (SPOF).
Quando configurado como “à espera”, a máquina inactiva mantém
uma cópia corrente do ficheiro de configuração do cluster e
heartbeats ao longo da rede pública entre este e o nó activo do
router IPVS. Se, depois de um determinado espaço de tempo, o router
activo falha a resposta aos heartbeats, o nó inactivo executará um
failover. O processo de failover consiste na recriação da última tabela
de routing IPVS conhecida e “roubo” dos endereços IP virtuais de que
o cluster é responsável. Isto também retira o IP de gateway privado
aos servidores reais. Isto traz esses IPs para as suas redes pública e
privada, e envia ARPs gratuitos para anunciar o novo endereço MAC
para os IPs recolocados. Isto também inicia o processo nanny para
monitorizar os serviços nos servidores reais.
Hoje em dia, o Piranha apenas suporta o modelo NAT do código
IPVS. A outra limitação significante do Piranha são os sistemas de
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Ferramentas de Clustering 102
ficheiros. São requeridos conteúdos estáticos correntes nos servidores.
Qualquer conteúdo dinâmico deve vir de outro sistema de ficheiros
partilhado. Para a maioria dos web sites, o conteúdo das páginas é
principalmente estático através de actividades de CGI e os conteúdos
dinâmicos são trazidos das base de dados.
Os serviços primários suportados dentro de um ambiente Piranha
são servidores Web e Ftp. Com o modelo NAT, os servidores reais
podem ter qualquer sistema operativo em qualquer plataforma de
hardware. As capacidades de ajuste dinâmico de pesos não são
utilizáveis nos Oses que não suportem logins RSH (ou similar) para
adquirir CPU. O número de servidores reais que podem ser suportados
são teoricamente limitados; todavia, as limitações da rede podem ser
conseguidas com 8 ou 12 servidores no máximo, dependendo da
ligação de rede e dos tipos de dados do servidor.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Análise das ferramentas 103
6 Análise das ferramentas
Com uma variedade de serviços de clustering no mercado, é
necessária uma capacidade para escolher a solução que melhor se
adapta ao tipo de negócio.
No ambiente competitivo dos nossos dias, a expressão “tempo é
dinheiro” aplica-se com todo o sentido. Manter a informação do
negócio on-line e acessível é o fundamento destes sistemas. Quer
sejam aplicações de base de dados, servidores web ou sistemas de
ficheiros de rede (NFS) utilizados como directórios de e-mail e
utilizador, as falhas no armazenamento de dados tendem a ser
catastróficas.
Depois de estudadas as soluções apresentadas denotei que a
implementação de um cluster tolerante a falhas é a melhor solução
para aumentar a confiança de um site. Os clusters failover envolvem a
criação de um conjunto de computadores, em que cada um é um
candidato para o sistema de ficheiros, base de dados ou aplicações.
Cada uma destas máquinas deve monitorizar as capacidades dos
outros. Em caso de falha de um membro, os outros tornam-se
responsáveis pelos serviços do servidor que falhou. Este failover deverá
ser executado de uma forma transparente para os clientes.
Uma implementação típica de um cluster failover consiste em
múltiplos sistemas ligados a um conjunto de unidades de
armazenamento partilhado, tal como discos, ligados a um barramento
SCSI partilhado ou fibre channel. Cada um dos clusters membros
geralmente monitorizam a capacidade dos outros via rede (ex.
ethernet) e/ou conexões série ponto-a-ponto.
Depois de anos de investigação acerca dos produtos existentes
para a tecnologia de clustering em Linux chega-se à conclusão que
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Análise das ferramentas 104
existem pelo menos quatro cenários de falha que devem ser
contemplados em qualquer solução, de modo a fornecerem a
segurança e a confiança que qualquer administrador de um cluster
em Linux necessita.
1. Planeamento de manutenção;
2. Crash de sistema;
3. Falha de comunicações
4. Sistema “Pendurado”
Estes cenários serão discutidos em detalhe, mas antes de os
apresentar é essencial ter a percepção do que é a realidade da
integridade dos dados. Os pontos fundamentais da integridade da
informação é a sua correcção e a sua actualização. Num ambiente
cluster, preservar a integridade da informação é de extrema
importância e supera mesmo a disponibilidade dos dados. Utilizando
exemplos ajuda a ilustrar este ponto. O diagrama seguinte representa
um cluster com dois nós, com os membros A e B ligados a um
barramento SCSI partilhado com um disco (Disk 1).
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Análise das ferramentas 105
Fig. 23 – Exemplo de um cluster com 2 nós ligados a um barramento SCSI partilhado
Os sistemas operativos típicos fornecem acesso ao armazenamento
via sistemas de ficheiros que, por sua vez, acedem ao
armazenamento em disco. Usualmente, o sistema de ficheiros cria o
volume do disco e depois trata do acesso do utilizador. Em termos de
desempenho, as implementações de sistemas de ficheiros,
tipicamente, guardam as cópias recentes dos dados do sistema de
ficheiros em memória. Consequentemente, a versão actualizada dos
dados (no Servidor A), é actualmente a combinação do que é
guardado na memória do sistema A mais os dados em disco.
Estendendo este exemplo para o outro membro (nó B). Se o nó B
quiser criar o mesmo volume no sistema de ficheiros e a ele aceder, o
verdadeiro conteúdo do sistema de ficheiros consiste agora nos dados
guardados na memória do nó A, mais os dados guardados na
memória do nó B, mais os dados em disco. Para que isto funcione
correctamente é necessário implementar um sistema de ficheiros que
coordene a informação da memória com a informação do disco. Este
modelo, onde todos os membros do cluster podem correctamente
criar um volume do sistema de ficheiros é chamado de sistema de
ficheiros do cluster (cluster file system).
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Análise das ferramentas 106
Na ausência deste modelo podem acontecer as seguintes
situações:
Dados incorrectos;
Crash de sistema.
Os conceitos acima referidos acerca da necessidade dos membros
do cluster sincronizarem o seu acesso aos dados do sistema de
ficheiros, para protecção contra a corrupção dos dados, é também
aplicado às bases de dados.
Um modo de fugir a esta situação, baseia-se na escolha de uma
implementação em cluster que garante que um sistema de ficheiros
individual ou uma base de dados possa ser servida por um membro de
cada vez. Esta é o modo de funcionamento de todas as ferramentas
apresentadas anteriormente.
Em seguida são descritos os quatro cenários de falha apresentados
anteriormente.
6.1 Planeamento de manutenção
Um dos maiores benefícios de um cluster de alta disponibilidade, é
a capacidade para transparentemente migrar serviços de um
membro para outro e então executar as tarefas de manutenção sem
causar interrupção no acesso dos clientes. Por exemplo, isto permite
executar um upgrade do servidor para a última versão ou mesmo
adicionar memória enquanto o site continua operacional.
A maioria das ferramentas apresentadas suportam a migração
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Análise das ferramentas 107
manual dos serviços de um nó para o outro, em especial o DataGuard
Conuolo Cluster, Kimberlite e do LifeKeeper, uma vez que possuem
interfaces de planeamento de tarefas de manutenção.
6.2 Crash do sistema
Em resposta a um crash do sistema, os outro membros do cluster
devem concluir que o seu servidor não está a responder e de imediato
assumir formalmente os serviços do nó que falhou. Esta situação está
prevista em todas as ferramentas apresentadas, uma vez que é
considerado um dos tipos de falha mais habitual.
6.3 Falha de comunicações
As implementações típicas de clusters de alta disponibilidade
consistem num conjunto de membros, cada um monitorizando a
capacidade dos outros sobre uma variedade de interligações de
cluster. Geralmente, os criadores dos produtos têm de depender do
hardware existente para as suas “interligações de cluster”. Enquanto
isto fornece uma implementação em cluster sólida, tende por
natureza a ser muito cara e obriga a ter um único criador. Para
fornecer uma alternativa de custos, existem implementações de
cluster que monitorizam a capacidade do sistema acerca das
interligações de rede disponíveis (geralmente ethernet) e ligações
porta de série. Nestas configurações os membros do cluster
periodicamente trocam mensagens, e baseando-se nas respostas,
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Análise das ferramentas 108
concluem se os outros membros estão activos ou não. Esta troca de
mensagem é geralmente chamada de heartbeat.
Algumas das ferramentas apresentadas “preocupam-se” com o
estado das comunicações, em especial o ClusterWorx e o Kimberlite
que monitorizam a performance das ligações, através do interface de
monitorização e do suporte de múltiplas ligações.
Um problema comum com os clusters baseados em heartbeat
(batimentos) é a comunicação de partições. Isto acontece quando
os membros do cluster estão activos mas não são capazes de
comunicar com o outro.
O diagrama seguinte mostra o exemplo de um cluster com dois nós,
com ligações de ethernet e série entre si, para troca de mensagens
heartbeat.
Fig. 24 – Exemplo de cluster com 2 nós ligados via ethernet e série
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Análise das ferramentas 109
Para resolver os problemas com as falhas de comunicações, uma
ferramenta de clustering para Linux deve suportar interligações de
comunicação múltiplas para eliminar a possibilidade de uma partição
na comunicação.
6.4 Sistema “pendurado”
Este é o cenário mais importante que deve ser confrontado com
qualquer implementação cluster.
Assim como, misteriosamente os computadores “penduram”,
também voltam ao seu estado normal, o que acontece em quase
todos os sistemas operativos.
A questão principal na avaliação de produtos cluster é perceber
como é que um cluster responde num cenário de pendurado/livre.
No cenário “pendurado”, o nó A não responde, e não interessa se
existem 50 ligações entre os nós, pois nenhuma vai funcionar. Em
resposta a isto, o nó B denota que o nó A falha a resposta aos
heartbeats e conclui que este está em baixo. Seguidamente o nó B
executa o mount do sistema de ficheiros ou inicia as bases de dados
servidas pelo nó A.
Neste ponto, o nó A pode voltar ao seu funcionamento normal e
iniciar e actualizar o sistema. Isto resulta numa situação em que dois
nós concorrentemente tentam modificar o mesmo sistema de
ficheiros, originando uma violação da integridade dos dados.
Para este cenário é necessário que o nó que remota os serviços do
que falhou bloqueie o nó em falha antes de assegurar o serviço, de
modo a evitar o problema. Este bloqueio é chamado de I/O fencing
ou I/O barrier.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Análise das ferramentas 110
A maior parte dos fabricantes deste tipo de software ignoram este
cenário, considerando-o infrequente. No entanto, o Kimberlite que foi
anteriormente apresentado inclui uma capacidade de resposta para
estes cenários.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Conclusão 111
7 Conclusão
O clustering é por vezes tratado como uma super máquina que
mantém o sistema intacto em caso de falha. Mas, esta solução não é
apenas isso. Para que um cluster tenha sucesso, é necessário que um
conjunto de requisitos sejam cumpridos. Para o cumprimento desses
requisitos existem muitas ferramentas no mercado actual, cuja função
principal é responder a um leque situações através de uma gestão
avançada dos serviços e tarefas.
Este relatório teve como principal fundamento a apresentação de
algumas ferramentas de clustering para Linux. A escolha das
ferramentas foi baseada numa pesquisa através da Internet, assim
como a toda a recolha de informações acerca do produtos.
Paralelamente às soluções apresentadas existem alguns projectos
não comerciais, como é o caso do Beowulf ou do LVS (Linux Virtual
Server) que decidi não incluir, mas que também são consideradas
excelentes ferramentas de clustering para Linux.
Como todos sabemos, a importância de um cluster num sistema
Linux é tal, que se torna imprescindível a utilização de uma ou mais
ferramentas de clustering.
O facto de nunca ter aprofundado os meus conhecimentos acerca
desta matéria e a percepção que este assunto é cada vez mais
importante, ajudou-me na escolha, e deu-me grande motivação para
a realização deste trabalho de final de curso.
Por tudo isto julgo ter cumprido os objectivo que inicialmente
propus.
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Bibliografia 112
8 Bibliografia
http://www.mosix.cs.huji.ac.il/
http://www.turbolinux.com
http://www.redhat.com/
http://www.supercluster.org
http://www.clusterresources.com
http://linux-ha.org
http://oss.missioncriticallinux.com
http://www.mvista.com/white/highavailability.html
http://www.ibm.com
http://linuxjournal.com
http://www.linux-mag.com/
http://www.msclinux.com
http://linuxnetworx.com
http://www.steeleye.com/
http://linuxvirtualserver.com
http://www.beowulf.org
Instituto Superior de Engenharia do Porto Projecto
Ferramentas para clustering em Linux – Glossário 113
9 Glossário
Cluster Namespace – Tal como gestor de nomes.
Daemons – Processos servidores que correm num cluster Linux.
Disaster Recovery – Operação de recuperação do sisterma em caso de
perda.
Front-end – Termo atribuído aos servidores directamente acessíveis pelos
clientes.
Heartbeats – Mensagens trocadas entre nós que servem para monitorizar
outros nós.
Mount – Atribuição de uma unidade lógica a um sistema de ficheiros
externo.
Plug-in – Aplicação que integra com outro software para executar
determinada funcionalidade.
Swapping – Processo de transferência de segmentos de dados do disco
para a memória.
System Uptimes – Espaços temporais em que o servidor está disponível.
Timestamp – Marcações de tempos, regista a hora a que as operações
são realizadas. Se não for actualizado num determinado
espaço temporal, pode-se considerar a ocorrência de uma
falha no membro do cluster.