Instituto Superior de Engenharia do Portopaf/proj/Set2002/Clustering_Linux.pdfsoftware ou redes e que conduzem a um único sistema. Este sistema obriga a tarefas de administração

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.


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



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;



• 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;



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.



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



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



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.



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



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.



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).


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.


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


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



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



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



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



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



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



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



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.



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.



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



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.



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



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.



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



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.


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.



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



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).



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.



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:



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.



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.



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



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.



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



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.



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.



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;



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



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.



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.



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



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



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



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).



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



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.



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



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 é



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



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



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



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.



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,



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.



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:



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.



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:



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



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.



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



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.



Á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



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



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.



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



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.



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



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.



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



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



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.



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.



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



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.



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



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.



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



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



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.



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



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



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).



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



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



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.



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.



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



“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



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.



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 é



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



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



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.


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



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).



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).



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



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,



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



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.



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.


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.


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

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/


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.

Documents

Instituto Superior de Engenharia do Portopaf/proj/Set2002/Clustering_Linux.pdfsoftware ou redes e que conduzem a um único sistema. Este sistema obriga a tarefas de administração