2003 Altadisponibilidade PDF

UNAMA UNIVERSIDADE DA AMAZNIA
CCET CENTRO DE CINCIAS EXATAS E TECNOLGIA

BACHARELADO EM CINCIA DA COMPUTAO
TRABALHO DE CONCLUSO DE CURSO - TCC

Olavo Jos Vidal Barros
Thiago Rodrigues de Souza Costa

Alta Disponibilidade em Servidores Linux

Belm/PA
2003

Thiago Rodrigues de Souza Costa


Trabalho apresentado como requisito
parcial para a obteno do Grau de
Bacharel em Cincia da Computao.
Orientador: Prof. MsC. Josivaldo
Arajo.

UNAMA
Belm/PA
2003

UNAMA UNIVERSIDADE DA AMAZNIA
CCET CENTRO DE CINCIAS EXATAS E TECNOLGICAS
BACHARELADO EM CINCIA DA COMPUTAO
TRABALHO DE CONCLUSO DE CURSO - TCC

Thiago Costa Rodrigues


DATA DA DEFESA: 01/12/2003

BANCA EXAMINADORA:

___________________________________
Prof. MsC. Josivaldo Arajo - Orientador

___________________________________
Prof. MsC. Afonso Cardoso MEMBRO
UNAMA / CCET

___________________________________
Prof. Dr. Carlos Renato Lisboa Francs - MEMBRO
UFPA / DI

A todos os que demonstraram confiana
e pacincia. Desde nosso orientador
Josivaldo at nossos familiares e
amigos.

Dedico este trabalho especialmente para
Vanderliane, pois em vrios momentos
no pude disponibilizar minha ateno, e
sempre demonstrou ter pacincia e
disposio para incentivar-me.
Entretanto, agradeo a minha me por
todos os momentos difceis desde o
inicio de minha criao para chegar at a
este trabalho.
Olavo Barros

Agradeo a Deus por me ajudar nesta
etapa da minha vida, a minha me Graa,
ao meu pai Paulo, a minha av Oscarina
pela compreenso e esforo para minha
educao. Agradeo a Beatriz por toda
pacincia e incentivo, nos momentos
mais difceis.
Thiago Rodrigues

"Tudo na vida, se no progride, retrgrado."
(Fernando Pessoa)

SUMRIO

LISTA DE FIGURAS ........................................................................................ x
LISTA DE TABELAS ........................................................................................ xi
LISTA DE SIGLAS E ABREVIATURAS ..................................................... xii
RESUMO ............................................................................................................. xiv
ABSTRACT ........................................................................................................ xv
1. INTRODUO .............................................................................................. 16
2. SISTEMAS PARALELOS E DISTRIBUDOS ....................................... 18
2.1. CONSIDERAES INICIAIS ............................................................... 18
2.2. PARALELISMO COMPUTACIONAL ................................................... 18
2.2.1. SISD (Single Instruction Single Data) 19
2.2.2. SIMD (Single Instruction Multiple Data) . 20
2.2.3 MISD (Multiple Instruction Single Data) .. 20
2.2.4. MIMD (Multiple Instruction Multiple Data) .. 20
2.2.4.1. Arquitetura MIMD com Memria Compartilhada ....... 20
2.2.4.2. Arquitetura MIMD com Memria Distribuda .............. 21
2.3. ARQUITETURA PARALELA ................................................................ 22
2.4. SISTEMAS DISTRIBUDOS ................................................................. 23
2.5. AMBIENTE DE COMUNICAO ......................................................... 24
2.5.1. PVM (Parallel Virtual Machine) ............................................. 25
2.5.2. MPI (Message Passing Interface) ......................................... 26
3. CLUSTERS DE COMPUTADORES ........................................................ 28
3.1. CONSIDERAES INICIAIS ............................................................... 28
3.2. SURGIMENTO DOS CLUSTERS DE COMPUTADORES .................. 29
3.3. TIPOS DE CLUSTERS ........................................................................ 30

3.3.1. Cluster com Alta Disponibilidade (HA) .................................. 30
3.3.2. Balanceamento de Carga ..................................................... 31
3.3.2.1. Round Robin ........................................................... 32
3.3.2.2. Least Connections .................................................. 33
3.3.2.3. Weighted Fair .......................................................... 33
3.3.3. Processamento Distribudo ou Processamento Paralelo ....... 34
3.3.4. Combinao de Alta Disp. e Balanceamento de Carga.......... 34
3.4. ABSTRAES EM CLUSTERS ......................................................... 35
3.4.1. N .......................................................................................... 36
3.4.2. Recursos ............................................................................... 36
3.4.3. Dependncias de Recursos ................................................. 36
3.4.4. Arquitetura de Clusters ........................................................ 37
3.5. CARACTERSTICAS DE SISTEMAS PARALELOS .......................... 38
3.5.1. Transparncia ....................................................................... 38
3.5.2. Confiabilidade ....................................................................... 39
3.5.3. Desempenho ......................................................................... 39
3.5.4. Escalabilidade e Flexibilidade.............................................. 39
3.5.5. Paralalelismo ........................................................................ 40
3.6. PROTOCOLOS DE COMUNICAO.................................................. 40
3.6.1 Meios de Comunicao......................................................... 40
4. ALTA DISPONIBILIDADE ......................................................................... 41
4.1. CONSIDERAES INICIAIS .............................................................. 41
4.2. CONCEITOS BSICOS DE HA ........................................................... 42
4.2.1. Avaria ..................................................................................... 42
4.2.2. Erro ........................................................................................ 42
4.2.3. Falha ...................................................................................... 43
4.2.4. Failover ................................................................................. 44

4.2.5. Failback ................................................................................. 45
4.3. SISTEMAS DE CORREO DE FALHAS ......................................... 46
4.3.1 SPOF - Single Point of Failure ........................................ 48
4.4. TIPOS DE DISPONIBILIDADE .................................................. 49
4.4.1. Disponibilidade Bsica .............................................. 49
4.4.2. Alta Disponibilidade ................................................... 49
4.4.4. Disponibilidade Contnua .............................................. 50
4.5. ESTADOS DE DISPONIBILIDADE ............................................ 50
4.5.1. Mean Time to Failure MTTF .............................................. 50
4.5.2. Mean Time to Repair MTTR .............................................. 51
4.5.3. Mean Time Between Failures MTBF ................................ 51
4.6. REGRA DOS NOVES .......................................................................... 52
4.7. CONFIABILIDADE X DISPONIBILIDADE .......................................... 53
4.8. SOLUES DE SOFTWARES PARA AMBIENTES DE HA ............. 54
5. ESTUDO DE CASO: IMPLEMENTAO ............................................ 56
5.1. CONSIDERAES INICIAIS .............................................................. 56
5.2. INSTALAO ...................................................................................... 56
5.3. CONFIGURAES ............................................................................. 58
5.3.1. Heartbeat .............................................................................. 58
5.3.2. Copyfiles ............................................................................... 59
5.3.3. OpenSSH .............................................................................. 60
5.4. FUNCIONAMENTO ............................................................................. 61
5.3.1. Funcionamento do Copyfiles ................................................. 61
5.3.2. Funcionamento do Heartbeat ................................................. 62
5.5. AMBIENTE DE TESTES ..................................................................... 63
5.6. TESTE DO AMBIENTE ....................................................................... 64
5.6.1. Situao 1 Ambiente Normal ............................................... 65

5.6.2. Situao 2 Fala no Servidor Primrio ................................. 66
5.6.3. Situao 3 Volta do Servidor Primrio ................................ 67
5.7. CONSIDERAES FINAIS ................................................................. 67
6. CONCLUSO ................................................................................................ 68
REFERNCIAS BIBLIOGRFICAS ...................................................................... 69

LISTA DE FIGURAS

Figura 2.1 - Representao de um Sistema Paralelo ......................................... 19
Figura 2.2 - Arquitetura MIMD com memria compartilhada. .............................. 21
Figura 2.3 - Arquitetura MIMD com memria distribuda ................................... 22
Figura 2.4 Sistema Distribudo .......................................................................... 24
Figura 3.1 - Cluster de Alta Disponibilidade ....................................................... 30
Figura 3.2 - Alg. Round Robin : Recursividade das conexes de entrada .......... 33
Figura 3.3 - Aplicao utilizando a combinao HA e Load Balancing ............ 35
Figura 4.1 - Representao Grfica dos tipos de falhas ...................................... 44
Figura 5.1 - Instalao do Heartbeat 0.4.9-1 ...................................................... 57
Figura 5.2 Descompactao do Copyfiles ......................................................... 57
Figura 5.3 - Criao das Chaves ......................................................................... 60
Figura 5.4 - Configurao de IP do servidor primrio ......................................... 64
Figura 5.5 - Ambiente de rede em estado normal .............................................. 65
Figura 5.6 - Portas abertas no servidor secundrio ........................................... 65
Figura 5.7 - Ambiente de rede depois da falha do servidor primrio ................ 66
Figura 5.8 - Portas abertas no servidor secundrio Situao 2 ...................... 67

x

LISTA DE TABELAS

Tabela 2.1 - Comparao entre alguns tipos de arquiteturas paralelas ................ 23
Tabela 4.1 - HA utilizando a regra dos noves ........................................................ 53
Tabela 5.1 - Configurao do Heartbeat ................................................................ 58
Tabela 5.2 - Configurao do haresources ............................................................ 59
Tabela 5.3 - Configurao do authkeys ................................................................. 59
Tabela 5.4 - Configurao do copyfiles .................................................................. 59
Tabela 5.5 - Configurao do sshd_config ............................................................ 61

xi

LISTA DE SIGLAS E ABREVIATURAS

CESDIS Centro de Excelncia em Dados Espaciais e Informaes
Cientficas
CPU Central Processor Unit
CRC Cyclic Redundancy Checks
DRBD Distributed Raid Block Device
CTE Cincias da Terra e do Espao
FTP File Transfer Protocol
GHz Gigahertz
HA High Availability
HD Hard Disk
HTTP Hipertext Transport Protocol
IDE Integrated Drive Electronics
IP Internet Protocol
IPC InterProcess Communication
JDB Java Debugger
KB Kilobyte
LAN Local Area Network
MB MegaByte
MFLOPS Mega Flops
MIMD Multiple Instruction Multiple Data
MISD Multiple Instruction Single Data
MPI Message Passing Interface
xii

MTBI Mean Time Between Interruptions
MPMD Multiple Program Multipe Data
MTTB Mean Time Between Failures
MTTF Mean Time to Failure
MTTR Mean Time to Repair
PC Personal Computer
PVM Parallel Virtual Machine
RAID Redundant Array of Inexpensive Disks
RAM Random Access Memory
RPC Remote Procedure Call
SD Sistemas Distribudos
SIMD Single Instruction Multiple Data
SISD Single Instruction Single Data
SMP Simetric Multiple Processor
SO Sistema Operacional
SPMD Single Program Multipe Data
SPOF Single Point of Failure
SSH Secure Shell
TCP Transmition Control Protocol
TI Tecnologia da Informao
UDP User Datagram Protocol
VS Virtual Server

xiii

RESUMO

Atualmente a competitividade no sistema comercial cria a necessidade de
servios que atendam as expectativas de todos aqueles que esto inseridos neste
contexto, sejam disponibilizando ou acessando servios. Com isso, as empresas
precisam de equipamentos e sistemas que possam atender as necessidades dos seus
clientes com rapidez, qualidade e segurana a qualquer momento, sem interrupes.
A cada dia, novas pesquisas so desenvolvidas em sistemas de alta
disponibilidade, as tecnologias de clusters so aperfeioadas e os sistemas de cdigo
aberto so aprimorados para que as empresas passem a ter acesso s solues com
baixo custo e com maior eficincia.
Este trabalho utiliza o software free GNU/Linux e dois servidores, em um exemplo
de implementao de sistema de alta disponibilidade que pode ser aplicado em
empresas dos mais variados segmentos. Todos os componentes aqui utilizados, podem
ser adquiridos e utilizados por qualquer instituio que tenha interesse e, principalmente
necessidade, de um sistema que funcione ininterruptamente.

xiv

ABSTRACT

Currently the competitiveness in the commercial system creates the necessity of
services that take care of to the expectations of all those that are inserted in this context,
are availabiliting or having access services. With this, the companies need equipment
and systems that can take care of the necessities of its customers with rapidity, quality
and security at any time, without interruptions.
To each day, new research is developed in systems of high availability, the
technologies of clusters are perfected and the systems of open code are improved so
that the companies start to have access to the solutions with low cost and bigger
efficiency.
This work is use software free GNU/Linux and two servers, in an example of
implementation of system of high availability that can be applied in companies of the
most varied segments. All the components used here, can be acquired and be used by
any institution that has interest and, mainly necessity, of a system that functions
uninterruptedly.

xv

16

CAPTULO 1

INTRODUO

H alguns anos, as solicitaes por servios tolerantes a falhas eram poucas.
Com o tempo, outros servios na rea de informtica foram surgindo e com isso as
necessidades de um sistema com uma maior disponibilidade aumentaram.
Empresas disponibilizando portas para servios on-line como e-commerce e e-
bussiness so alguns exemplos de instituies do sculo XXI, dominado pelo uso de
computadores e tendo a necessidade dos mesmos operarem sem parar, sendo
chamados tambm, de servidores de misso crtica.
A participao do Linux em servidores crticos at pouco tempo, era bastante
restrito devido a questes estruturais, basicamente por no ser um sistema robusto o
suficiente, isto , no possua ferramentas que pudessem vir a ser utilizadas em
sistemas de Alta Disponibilidade. Com isto, houve um movimento em busca da criao
de recursos, que provessem um aumento da disponibilidade de servios atravs de
tcnicas computacionais, podendo ser tanto atravs de software, como de hardware.
Com o intuito de haver um sistema altamente disponvel a um baixo custo,
juntou-se os softwares de alta disponibilidade com o sistema operacional Linux,
tornando-o uma soluo eficiente e de baixo custo.
Alta Disponibilidade no mais simplesmente uma preferncia das corporaes,
crtico para o seu sucesso. Especialmente agora, onde uma grande quantidade de
informaes vitais de companhias so transmitidas eletronicamente entre empregados,
consumidores, parceiros e fornecedores. O mnimo downtime (tempo de parada) pode
resultar em perdas de faturamento.
Independente do investimento em TI (Tecnologia da Informao), a
disponibilidade dos sistemas um dos critrios mais importantes, seno o mais
importante para o e-business de uma empresa. Mesmo uma rede altamente segura, por
exemplo, tem pouco valor se no pode oferecer acesso a todos os usurios a qualquer
momento.

17

Com o objetivo de prevenir essas falhas em servidores crticos, o surgimento da
Alta Disponibilidade em Linux uma soluo vivel e com um baixo custo, sendo assim
uma excelente opo para empresas que queiram diminuir, ou at mesmo extinguir, ao
mximo seu tempo de downtime.
Este trabalho esta dividido em seis captulos: O segundo captulo apresenta
conceitos bsicos sobre Sistemas Paralelos e Distribudos; O terceiro captulo, trata de
Clusters, abordando uma viso geral e comentando sobre os principais conceitos; O
quarto trata da Alta Disponibilidade, conceitos e solues; O quinto captulo trata da
implementao de um sistema de Alta Disponibilidade, sendo a soluo baseada em
servidores linux para e-business. No sexto captulo, so apresentadas as concluses,
as consequncias e as sugestes para trabalhos futuros.

18

CAPTULO 2

SISTEMAS PARALELOS E DISTRIBUDOS

2.1. Consideraes Iniciais
Geralmente utilizado por instituies que trabalham com uma grande quantidade
de processamento matemtico, os sistemas paralelos vm em uma evoluo contnua
para facilitar tanto o manuseio de dados complexos quanto para a disponibilidade de
servios. Esse tipo de sistema trabalha com processamento de informaes de forma
simultnea, ou seja, utiliza vrios processadores para executar as tarefas de forma
paralela.
Os conceitos bsicos de um sistema paralelo podem ser aplicados a qualquer
rea da informtica que necessitem de ambiente de tolerncia a falhas e/ou
processamento de dados elevado. No se pode, hoje em dia, utilizar a prtica deste tipo
de sistema para um determinado setor de informtica.
A utilizao de tcnicas de paralelismo traz uma nova perspectiva de
desenvolvimento de programas e aplicativos, possibilitando a resoluo de problemas
que antes no eram resolvidos de forma eficiente, atravs de abordagens seqenciais.

2.2. Paralelismo Computacional

O paralelismo uma tcnica utilizada para solucionar problemas complexos e de
grandes volumes no menor tempo possvel. Para isso, divide-se o problema em tarefas
menores que sero distribudas entre os vrios processadores, para serem
solucionadas, cooperativamente, conforme esquema mostrado na Figura 2.1.

19

Figura 2.1. Representao de um Sistema Paralelo

Para a computao, o paralelismo uma estratgia computacional utilizada para
obter, mais rapidamente, resultados de tarefas de grande complexidade, que exigem
um processamento elevado. O paralelismo tem por objetivo dividir uma tarefa em vrias
tarefas menores, e envi-las para serem processadas por vrios processadores
diferentes de maneira simultnea, diminuindo consideravelmente o tempo de
processamento. Essa operao pode ser realizada tanto em mquinas
multiprocessadas, quanto utilizando um conjunto de computadores.
Para se entender melhor o conceito de paralelismo pode-se utilizar a taxonomia
de Flynn que baseada atravs da anlise do fluxo de instrues e do fluxo de dados.
O fluxo de instrues a seqncia de instrues executadas pelo computador e o
fluxo de dados a seqncia de dados sobre os quais operam as instrues. (ALMASI,
1994).

2.2.1. SISD (Single Instruction Single Data)

So mquinas que executam uma nica instruo por vez e com isso, acabam
por manipular, tambm, apenas um nico dado, por possurem apenas um
processador. So mquinas que seguem o modelo de Von Neumann (PEIXOTO, 2002).

TAREFA
COMPLEXA
Tarefa 2
Tarefa 1
Tarefa 3
Processador
C
Processador
A
Processador
B

20

2.2.2. SIMD (Single Instruction Multiple Data)

Neste tipo utilizam-se vrios processadores conectados unidade de controle,
que por sua vez interpreta a seqncia de instrues e envia para os processadores a
instruo interpretada. Os processadores executaro as instrues ao mesmo tempo,
porm, cada processador utilizar uma seqncia de dados diferentes (PEIXOTO,
2002).

2.2.3. MISD (Multiple Instruction Single Data)

A unidade de controle interpretar vrias seqncias de instrues, utilizando
somente uma seqncia de dados. No foram encontrados computadores enquadrados
nesta categoria (PEIXOTO, 2002).

2.2.4. MIMD (Multiple Instruction Multiple Data)

Cada unidade de controle interpreta uma seqncia de instrues e envia para
um processador ligado a ela. Havendo vrias unidades de controle, cada uma com um
processador, nota-se que h vrios fluxos de instrues e de dados. Esse tipo pode
ainda ser subdivido em outros dois: arquitetura MIMD com memria compartilhada e
arquitetura MIMD com memria distribuda (PEIXOTO, 2002).

2.2.4.1. Arquitetura MIMD com Memria Compartilhada

Caracteriza as mquinas paralelas propriamente ditas (mquinas com mais de
um processador). Possui algumas desvantagens, tais como difcil manuteno e pouca
escalabilidade. Podendo haver situaes em que um processador entra em conflito ao
acessar reas de memria que esto sendo utilizadas por outros processadores. Essa
arquitetura pode, tambm, subdividir-se em outras duas categorias: UMA e NUMA. Na
figura 2.2 mostra-se uma arquitetura de MIMD compartilhada.

21

Figura 2.2 Arquitetura MIMD com memria compartilhada.

UMA (Uniform Memory Access Acesso Uniforme Memria): Todos os
processadores tm o mesmo tipo de acesso memria.
NUMA (Non Uniform Memory Access Acesso No Uniforme Memria):
Todos os processadores tm o mesmo tipo de acesso memria, porm o
acesso torna-se mais lento dependo da rea da memria que esta sendo
acessada.

2.2.4.2. Arquitetura MIMD com memria Distribuda

composta por mquinas multiprocessadas, cada mquina com sua prpria
memria, tambm chamada de multicomputadores. Para que seja feita a comunicao
entre os ns so utilizados dispositivos de entrada/sada (como placas de rede comuns
utilizadas em PCs comuns. Essa arquitetura caracteriza um cluster, pois se tm vrias
CPUs e cada CPU possui sua prpria memria (memria distribuda) como mostra a
figura 2.3.

22

Figura 2.3 Arquitetura MIMD com memria distribuda.

2.3. Arquitetura Paralela

Existem hoje vrias arquiteturas paralelas, cada uma com caractersticas
prprias. Algumas das arquiteturas mais comuns so (ALMASI, 1994):
Sistemas Distribudos: utilizam a capacidade de processamento de vrios
computadores espalhados e separados por longas distncias.
Clusters: formado por vrias mquinas (denominados ns) conectadas atravs
de uma rede simples e utilizando bibliotecas de passagem de mensagens para
a comunicao entre elas.
Multiprocessadores Simtricos (SMP): So constitudos de processadores
comerciais conectados a uma memria compartilhada (MC), geralmente atravs
de um barramento de alta velocidade.

Abaixo, a tabela 2.1 mostra o comparativo das principais arquiteturas de
processamento paralelo:

23

Tabela 2.1 - Comparao entre alguns tipos de arquiteturas paralelas.
Caractersticas SMP Cluster Sist. Distribudos
Quantidade de
ns
Dezenas Dezenas e
Centenas
Centenas e
Milhares
Complexidade Granulao fina
ou Grossa
Granulao mdia Grande
Abrangncia
Comunicao Centralizada e
Memria
compartilhada
Passagem de
Mensagem
Arquivos
compartilhados,
RPC, Passagem de
mensagem e IPC
Poltica de
Segurana
Desnecessrias Necessrias Necessrias

2.4. Sistemas Distribudos

Atualmente, em todos os setores da sociedade, h uma crescente necessidade
de informao. Essa necessidade aliada aos avanos tecnolgicos na rea de redes de
comunicao fez crescer o desenvolvimento de sistemas distribudos. Tais sistemas,
so compostos por partes geograficamente ou funcionalmente separadas, onde
utilizam-se de um meio de comunicao para a troca de informao, como mostrado na
Figura 2.4. (ALMASI, 1994).
Sistemas distribudos no so sinnimos de redes de computadores. Uma rede
de computadores pode fornecer a infraestrutura computacional para um sistema
distribudo, mas nem toda aplicao de rede necessariamente distribuda.

24

Figura 2.4 - Sistema Distribudo

Um Sistema Distribudo o resultado da integrao de sistemas computacionais
autnomos combinados de forma a atingir um objetivo comum. Baseado neste conceito
pode-se citar, algumas caractersticas importantes, como:
Compartilhamento de recursos: Hardware e de dados.
Sistemas abertos (openness): independncia
Extenses de Hardware: perifricos adicionais, interfaces de comunicao ou
memria.
Extenses de Software: adio de caractersticas aos S.O e servios de
compartilhamento de recursos.
Concorrncia de Recursos
O acesso concorrente e a atualizao dos recursos compartilhados so
sincronizados;

2.5. Ambiente de Comunicao

O ambiente de computao paralela caracteriza-se como sendo um sistema de
computadores ligados em rede, geralmente local, porm, a maneira com que esta

25

comunicao se estabelece fundamental para se poder identificar um ambiente de
processamento paralelo.
A comunicao entre os ns, atravs de passagem de mensagem, fez com que
fosse possvel a utilizao da computao paralela em sistemas distribudos. Esses
ambientes tm se desenvolvido muito desde sua primeira utilizao em mquinas MIMD
com memria distribuda, ou seja, cada processador utiliza um dispositivo de memria
local, para a execuo de uma tarefa (PEIXOTO, 2002).
A comunicao e o sincronismo entre os processos em mquinas MIMD com
memria distribuda, so feitos atravs da utilizao de interfaces de troca de
mensagens. Diferente das mquinas paralelas, as quais utilizam memria
compartilhada, essa interface, na verdade, um conjunto de comandos formulados
para possibilitar essa comunicao.
Um programa paralelizado executado em mquinas com memria distribuda,
pode ser dividido em subprogramas, sendo processado pelos processadores que se
comunicam atravs de instrues padronizadas pr-definidas, chamadas bibliotecas de
passagem de mensagem. O programa que ser executado entre os processadores
pode ser classificado em: MPMD (Multiple Program Multipe Data) e SPMD (Single
Program Multipe Data).
No SPMD o mesmo programa executado entre as mquinas do cluster, mas
neste caso, cada processador executa uma parte do programa. J no MPMD,
programas diferentes so executados entre as mquinas diferentes, estes programas
poderiam ser executados em uma s mquina, mas iriam acarretar perda de
desempenho e diminuio do Speed Up, ou seja, diminuio do ndice utilizado para
calcular a eficincia de uma implementao em paralelo. (CENAPAD, 1998).
Alguns exemplos de ambientes de passagem de mensagem so o PVM, MPI,
entre outros.

2.5.1. PVM (Parallel Virtual Machine)

um conjunto integrado de bibliotecas e de ferramentas de softwares para que
possam atuar como uma "Mquina Paralela Virtual", ou seja, como se fosse uma nica
mquina.

26

Surgido em 1989 nos laboratrios da Emory University e Oak Ridge National
Laboratory, onde nasceu com o objetivo de criar e executar aplicaes paralelas em um
hardware j existente (CENAPAD, 1998).
O PVM teve grande difuso, tornou-se um ambiente de passagem de mensagem
padro devido a sua flexibilidade. Atingiu os objetivos inicialmente desejveis que eram
unir uma coleo de computadores heterogneos a comportarem-se como se fosse um
nico recurso computacional expansvel e concorrente, criando uma mquina virtual
(Virtual Machine).
O sistema permite executar aplicaes na linguagem C, C++ e FORTRAN devido
a maioria das aplicaes que poderiam ser paralelizadas encontrarem-se nestas
linguagens. O PVM suporta aplicaes em SPMD e MPMD e a mistura entre os dois
(CENAPAD, 1998).
Cada tarefa do PVM baseada em processos do Unix, com isso pode-se
explicar parcialmente a alta portabilidade do sistema para computadores de arquiteturas
to diferentes. Os Tasks so as unidades bsicas de execuo do PVM.
O PVM composto e dividido em duas partes:

O pvmd3 um daemon, tambm chamado de pvmd. Este daemon est
presente em todos os hosts que trabalham juntos para criar a mquina virtual.
Bibiblioteca de rotinas de interface ou biblioteca Libpvm que foi desenvolvida
com o intuito de torn-la to pequena quanto possvel, visto que compartilha
o espao de endereamento com o cdigo desenvolvido pelo usurio. Estas
rotinas podem ser chamadas para efetuar passagem de mensagens, solicitar
a gerao de processos, coordenao de tarefas e solicitar modificaes na
mquina virtual.

2.5.2. MPI (Message Passing Interface)

Com o objetivo de demonstrar que o esforo no processo de padronizao era
vlido, composto por membros de universidades, organizaes, empresas, entre outros,
para publicarem em 1992 a primeira verso do MPI, chamado MPI1 (CENAPAD, 1998).

27

O objetivo deste grupo era montar uma sintaxe, semntica e um conjunto de
rotinas padro para troca de mensagens e que aproveitasse as principais
caractersticas de todas as arquiteturas, criou-se ento o Frum MPI. Em 1995, foi
atualizada esta verso para o MPI 1.1, porm a verso utilizada atualmente a 2.0.
O MPI possui rotinas que provem funcionalidades e suporte para grupo de
processos, contextos de comunicao e topologia de processos.
O MPI divide os processos em grupos e classifica-os dentro desses grupos. Eles
recebem uma numerao que denominada de rank. O MPI possui rotinas de criao e
destruio de grupos de processos, sendo que um processo no MPI identificado por
um grupo e por um rank dentro deste grupo.
Para se referenciar a um determinado grupo de contexto o programador utiliza o
communicator, um objeto que o programador cria para se referenciar aquele
determinado grupo.

28

CAPTULO 3

CLUSTERS DE COMPUTADORES


Nos dias atuais, empresas que funcionam ininterruptamente no podem ter seus
servios computacionais comprometidos, seja por uma hora, ou at por alguns minutos.
Um pequeno perodo fora de operao pode representar grandes prejuzos. Uma
estrutura redundante se faz necessria, a fim de diminuir os riscos de ocorrncia de
prejuzos.
Clusters tem como natureza, uma estrutura distribuda, redundante e
homognea, pois um conjunto de mquinas independentes, chamadas ns, que
cooperam umas com as outras para atingir um determinado objetivo comum. Uma vez
interligadas, estas mquinas devem se comunicar umas com as outras a fim de
coordenar e organizar todas as aes a serem tomadas. E desta forma, para um
usurio externo, a distribuio de trabalhos entre estas mquinas visto como um
nico sistema. Este conceito denominado transparncia do sistema.
De modo geral, cluster definido como um sistema multicomputacional capaz de
realizar grandes tarefas de forma conjunta com outras mquinas que o compem
(SPECTOR, 2000). Como caractersticas fundamentais para a construo destas
plataformas incluem-se elevaes da: confiana, distribuio de carga e desempenho.
Na configurao fsica do clusters de HA, os servidores se comunicam atravs
de uma conexo cross-over ethernet, com o uso de discos compartilhados (storage)
com tolerncia a falhas e recursos de fibra ptica. A configurao lgica do cluster
consiste no servidor virtual - com nome IP e recursos compartilhados - sendo que as
estaes de trabalho permanecem conectadas a um recurso virtual (como Exchange ou
SQL), sem necessidade de configuraes adicionais nas estaes caso ocorra falha em
um dos servidores. Em caso de paralisao no equipamento, a prpria ferramenta move

29

os recursos virtuais de um servidor fsico para o outro, tornando a operao ininterrupta
e transparente ao usurio.
A busca por um sistema de tolerncia a falhas (performance inalterada de suas
tarefas mesmo na presena de falhas de software ou hardware), o grande objetivo
dos que procuram estabilidade e bom desempenho. Contudo, pode-se dizer que um
sistema de cluster um sistema de tolerncia falhas, mas no convm dizer que o
inverso seja verdadeiro (FILHO, 2002).

3.2. Surgimento dos Clusters de Computadores

Em 1993, Donald Becker e Thomas Sterling comearam a elaborar um projeto
alternativo que fosse mais vivel financeiramente para substituir os
supercomputadores. Em 1994, quando Donald Becker e Thomas Sterling, trabalhando
na CESDIS (Centro de Excelncia em Dados Espaciais e Informaes Cientficas),
construram uma rede computadores, consistindo de 16 computadores Intel 486 DX4,
rodando o sistema operacional Linux cuja performance era de 4,5 Mflops, placa me
SiS471 com cache de 256KB, memria RAM de 16MB, disco rgido de 540MB IDE, 2
placas de rede 10Mbps (10baseT ou 10base2) chegando a uma performance total de
60 Mflops, conectados por uma interface de rede Ethernet denominando-a de Beowulf
(STERLING, 2002).
O projeto Beowulf estava ligado intimamente com o projeto das Cincias da
Terra e do Espao (ESS), onde o objetivo determinar a aplicabilidade de
computadores paralelos para problemas envolvendo grandes quantidades de dados.
De imediato, este projeto tornou-se um sucesso, pois provia servios especficos,
satisfazendo assim exigncias computacionais de alto nvel em locais como a NASA e
ambientes acadmicos e de pesquisas do mundo inteiro.
As circunstncias histricas que levaram ao sucesso dessa forma de
computao so:
A popularizao de computadores pessoais, e acessibilidade de
componentes como memria a melhores custos;

30

Desenvolvimento na rede de comunicao digital e disponibilidade de redes
de alta velocidade, surgimento de sistemas operacionais e programas de livre
acesso e sem custo como GNU-LINUX e softwares baseados na licena
pblica GNU, programas e bibliotecas de processamento paralelo com PVM e
MPI que podem ser executados em vrios ambientes.

3.3. Tipos de Clusters

Os clusters so divididos em quatro categorias: (TORRES, 2003)

3.3.1. Cluster com Alta Disponibilidade (HA)

Em sistemas de Alta Disponibilidade os servios apresentados mantm-se
sempre ininterruptos no sistema, no havendo em nenhum momento interrupo no
fornecimento dos servios, conforme pode ser visto na Figura 3.1. Esta disponibilidade
do sistema possvel atravs do uso da redundncia implcita ao sistema (STERLING,
2002).
A idia geral que se um n do cluster vier a falhar, aplicaes ou servios
possam estar disponveis em outro n. Estes tipos de clusters so utilizados para base
de dados de misses crticas, correio, servidores de arquivos e aplicaes.

Figura 3.1. Cluster de Alta Disponibilidade.

31

3.3.2 - Balanceamento de Carga

Este modelo distribui, de forma equilibrada, o trfego e os servios entrantes ou
requisies de recursos provenientes dos nodos que executam os mesmos programas
entre as mquinas que compem o cluster (PITANGA, 2003).
Neste sistema cada n responsabiliza-se por uma determinada parte da tarefa.
Todos os nodos esto responsveis em controlar os pedidos. Caso ocorra uma ruptura
no sistema, causado pela falha de um n, as requisies so redistribudas entre os ns
disponveis no momento. O mesmo ocorre se o n que ocorreu a falha voltar ao servio,
ou seja, h uma nova redistribuio nas tarefas.
Os sistemas de clusters baseados em balanceamento de carga integram seus
nodos para que todas as requisies provenientes dos clientes sejam distribudas de
maneira equilibrada entre os nodos. Os sistemas no trabalham juntos em um nico
processo, mas redirecionando as requisies de forma independente assim que
chegam baseados em um escalonador e um algoritmo prprio (PITANGA, 2003).
Este tipo de cluster especialmente utilizado em servios de comrcio eletrnico
e provedores de internet que necessitam solucionar diferenas de carga provenientes
de mltiplas requisies de entrada em tempo real.
Quando no for feito um balanceamento de carga entre servidores que possuem
a mesma capacidade de resposta a um cliente, comea-se a ter problemas, pois um ou
mais servidores podem responder a requisies feitas e a comunicao fica
prejudicada. Por isso deve-se colocar o elemento que far o balanceamento entre os
servidores e os usurios e configur-lo para isso. Entretanto pode-se colocar mltiplos
servidores, que para o usurio que estiver utilizando o servio, aparentar somente
uma nica mquina.
O elemento referido acima capaz de evitar o desequilbrio do balanceamento
dever ser um software dedicado a fazer todo esse gerenciamento, ou poder ser um
equipamento de rede que combine performance do hardware e software para fazer a
passagem dos pacotes e o balanceamento de carga em um s equipamento. Baseado

32

nas afirmaes para o sucesso do balanceamento, pode-se salientar alguns pontos
principais (PITANGA, 2003):

Um algoritmo deve ser utilizado para este balanceamento, onde dever levar
em considerao como feito o balanceamento entre os servidores e fazer
com que todo o processo de escolha e resposta do servidor de servios feita
pelo cliente torne-se transparente para este cliente, atravs de um endereo
virtual(VS).
Deve ser criado um mtodo que verifique constantemente se os servidores
esto ativos ao decorrer do tempo para que a comunicao no seja
interrompida ou que a comunicao no seja redirecionada para um n que
acabou de ocorrer falha.
Criar um mtodo utilizado para se ter certeza que um cliente acessa o mesmo
servidor quando quiser.

Alguns algoritmos para balanceamento de cargas so fatores preponderantes
para a robustez deste balanceamento, tais como:

3.3.2.1. Round Robin

Este algoritmo utiliza a tcnica de repassar as requisies para um
servidor prximo disponvel, sempre de forma seqencial circular. As conexes de
entrada so dirigidas para o servidor 1 e em seguida para servidor 2 e at chegar no
servidor 3, ocorrendo uma recursividade, pois aps o servidor 3 as conexes voltam a
ser dirigidas ao servidor 1, como pode-se verificar na figura 3.

33

Figura 3.2 : Algoritmo Round Robin : Recursividade das conexes de entrada

3.3.2.2. Least Connections
Este mtodo baseia-se no menor nmero de requisies por conexes de
cada servidor. A partir do momento de uma requisio, este algoritmo calcula o servidor
que est recebendo menor quantidade de requisies/conexes e assim direciona tal
requisio de servios (STERLING, 2002).

3.3.2.3. Weighted Fair
Esta tcnica direciona as solicitaes de pedido para os servidores
baseados na carga de requisies de cada um, e na capacidade de resposta ou
processamento dos mesmos (desempenho).
Por exemplo, se um determinado servidor quatro vezes mais rpido em
atendimento e em tempo de resposta aos pedidos de outro servidor, o administrador,
representado pelo algoritmo, estabelece um peso maior de trabalho para o servidor
mais eficiente, impondo assim, uma prioridade por ordem de peso.

SERVIDOR
1
SERVIDOR
2
Requisio

SERVIDOR
3
Conexo de entrada

34

3.3.3. Processamento Distribudo ou Processamento Paralelo

Ocorre uma diviso (integral ou em fraes de uma mesma tarefa) e uma
distribuio de tarefas para cada n da rede, onde sero processadas de forma
paralela e distintas.
As grandes tarefas de computao so as favorecidas neste modelo, pois a
performance e a disponibilidade para tais aplicaes podem ser divididas em pequenas
tarefas computacionais e distribudas para cada estao (n).
Como aplicao deste tipo de cluster, pode-se citar o uso da NASA com seus
projetos e clculos espaciais juntamente com computao cientfica. Pode-se associ-lo
tambm, com anlises financeiras que exijam um alto nvel de processamento.

3.3.4. Combinao de Alta Disponibilidade e Balanceamento de Carga.

Trata-se de uma combinao envolvendo caractersticas de aplicaes de alto
Desempenho (HA) e Balanceamento de Carga, proporcionando ao sistema segurana e
bom desempenho nas aplicaes. Este tipo de configurao de cluster bastante
utilizado em servios com os de web, mail, ftp e etc.
Este tipo de cluster apresenta caractersticas como (LVS, 1998):
Redirecionamento de solicitaes, dos ns que apresentam falhas para os
ns ativos, os chamados ns reservas;
Melhoria na qualidade dos servios para as aplicaes tpicas de rede;
Sistema disponvel tanto para alto desempenho quanto para replicao de
informaes em outros locais (servidor).
Disponibiliza uma arquitetura de framework altamente escalvel.

35

Figura 3.3: Aplicao utilizando a combinao HA e Load Balancing

3.4. Abstraes em Clusters

Dentro deste tipo de processamento paralelo, pode-se citar os elementos
fundamentais para a montagem da estrutura de cluster. Tais elementos, juntos com sua
arquitetura, fornecem a funcionalidade desejada do sistema.
Uma abstrao dos elementos necessria para se poder compreender qual o
comportamento de cada um deles, e em seguida ver-se- o conjunto das
funcionalidades atravs da arquitetura de clusters (FILHO, 2002).

36

3.4.1. N

Como visto durante este trabalho, o n a unidade bsica do cluster; o conjunto
de ns formam um cluster. Tais ns, estabelecem comunicao de rede para formar um
cluster, onde esta comunicao se d por mensagem.
Esta comunicao diretamente monitorada por Time-Out de comunicao a fim
de detectar de imediato um n fora do ar.

3.4.2. Recursos

representado pela funcionalidade de cada n da rede, ou seja, a
funcionalidade com que um certo n pode oferecer para a rede. Como exemplo, pode-
se mencionar uma impressora como sendo um recurso fsico ou um IP como sendo um
recurso lgico. Os recursos so as unidades bsicas de gerenciamento dos ns, e
podem migrar de um n a outro, onde esta migrao chamada de failover.
Como tratamento das falhas de recursos, utiliza-se em clusters monitores para
observar o status em que cada servio de um n se encontra, pois, dependendo da
situao verificada, atitudes desejadas podem ser tomadas para garantir as
funcionalidades adequadas.
O principal objetivo dos recursos gerenciar o cumprimento de cada funo dos
ns. Atravs disso que os recursos associam-se a si um tipo, que descreve seus
atributos e seu comportamento, que por sua vez associa-se a um mecanismo de
inicializao/parada que sejam corretamente manipulados.

3.4.3. Dependncias de Recursos
a forma pela qual um recurso disponibilizado a partir da dependncia em
outro recurso. Freqentemente, recursos dependem da disponibilidade de outros
recursos. Ou seja, um servidor HTTP depende da presena de uma interface de rede

37

online e de um sistema de arquivos operacional para fornecer os arquivos. Por outro
lado, um sistema de arquivos pode depender de um volume manager.

3.4.4. Arquitetura de Clusters

Atravs desta arquitetura que se v como e quais so os elementos de um
cluster, pois isoladamente, tais elementos no podem oferecer funcionalidade. Segundo
Tweedi (2000), esta estrutura de componente forma-se pelos elementos abaixo:
Camada de Comunicao: trata das comunicaes ponto-a-ponto entre os
ns.
Camada de Ligao: agrupa canais de comunicao em uma nica ligao
entre dois ns.
Camada de Integrao: forma a topologia do cluster.
Camada de Recuperao: executa a recuperao (failover) e a
inicializao/parada controlada de servios depois de uma transio do
cluster.
Alm dos elementos acima, existem ainda quatro servios chaves para um
cluster:
JDB: armazena estados persistentes internos ao cluster (e usados para o
banco de dados do quorum). Nada mais do que um repositrio de
informaes local a cada n do cluster.
Camada de Qurum: determina qual partio do cluster possui autorizao
para prosseguir com sua execuo.
Servio de Barreiras: prov um mecanismo bsico de sincronizao para
qualquer grupo de processos no cluster.
Servio de Nomes: uma estrutura hierrquica no-persistente, na qual
qualquer n pode registrar nomes. Atravs dela, processos podem tanto

38

registrar e consultar nomes, como definir dependncias baseadas nestes
nomes.

3.5. Caractersticas Sistemas Paralelos

Algumas caractersticas de Sistemas Paralelos so conceituadas para melhorar
a compreenso:

3.5.1.Transparncia

Um nico ambiente virtual: O processo de um usurio pode ser executado em
qualquer mquina da rede, sendo escolhida pelo sistema, conforme a
disponibilidade do momento.
Transparncia localizao: os usurios no devem saber onde os recursos
se encontram, tanto de hardware quanto de software. O nome do recurso no
pode ser codificado de forma a revelar sua localizao.
Transparncia migrao: ocorre na medida em que tais recursos podem ser
movimentados de um lugar para outro sem que haja necessidade de se
alterar os nomes.
Transparncia replicao: o sistema operacional poder fazer cpias
adicionais de arquivos e outros recursos, sem que o usurio tenha
conhecimento do que est acontecendo e de quantas cpias existem de
determinado arquivo ou recurso.
Transparncia concorrncia: vrios usurios podem compartilhar
automaticamente os recursos sem que um usurio note a presena dos
outros.
Transparncia ao paralelismo: podem ocorrer atividades paralelas sem que
os usurios venham a saber, devendo ser tratada como o principal objetivo de
todos os projetistas de sistemas distribudos.

39

3.5.2. Confiabilidade

Disponibilidade: Refere-se frao de tempo que um sistema pode ser
utilizado plenamente, podendo ser aprimorada atravs de um projeto que no
requer o funcionamento simultneo de um grande nmero de componentes
crticos.
Segurana: Proteger os recursos dos acessos no autorizados, pois em
sistemas distribudos isto se torna mais crtico, j que o servidor no tem uma
forma simples de saber quem est pedindo servio.
Tolerante a falhas: Ser capaz de manipular as falhas automaticamente.
possvel fazer um projeto em que o usurio no perceba a perda de um ou
dois servidores se um servio for realmente construdo a partir de um grupo
de servidores que cooperem intimamente.

3.5.3. Desempenho

Compartilhamento de recursos com uma melhor utilizao da carga de
processamento entre todas as mquinas.
A construo de SD transparente, flexvel e confivel, de nada vai servir se o
prprio for lento.
Uma aplicao particular em SD, executada normalmente, no deve ter um
melhor resultado quando se executa em um nico processador.

3.5.4. Escalabilidade e Flexibilidade:

Capacidade de agregar novos recursos ao sistema - sistemas abertos -
(openness) - crescimento incremental sem prejudicar o desempenho do
sistema.

40

3.5.5. Paralelismo:

Um processo pode ser distribudo entre vrias mquinas.

3.6. Protocolos de Comunicao

Tem a funo bsica de estabelecer um canal de comunicao entre dois ou
vrios computadores, fazendo com que os mesmos possam se comunicar.
Cada computador em uma rede deve obedecer a um conjunto de regras ou
poltica para que haja comunicao. A este conjunto de regras d-se o nome de
protocolo de comunicao. Um protocolo de comunicao descreve o modo que a
informao deve ser empacotada e enviada de um computador a outro.

3.6.1. Meios de Comunicao

um meio fsico por onde a comunicao ser realizada. As ligaes fsicas de
uma rede podem ser de dois tipos (SOARES, 1995):

Ponto-a-ponto: caracterizado pela presena de apenas dois pontos de
comunicao, presentes nas extremidades da ligao.
Multiponto: caracterizado pela presena de trs ou mais pontos de
comunicao. Ligados em um nico meio de transmisso.

41

CAPTULO 4

ALTA DISPONIBILIDADE


Para entender os conceitos que envolvem a alta disponibilidade (High Availability
HA), faz-se necessrio, antes de mais nada, perceber que ela no apenas um
produto ou uma aplicao que se instale, e sim uma caracterstica de um sistema
computacional. Existem mecanismos e tcnicas que podem ser utilizados para
aumentar a disponibilidade de um sistema, no entanto, a simples utilizao destas
tcnicas no garante este aumento se elas no forem acompanhadas de um completo
estudo e projeto de configurao.
Um sistema de alta disponibilidade, deve englobar muito mais do que um simples
sistema de redundncia de recursos. Pode-se montar um sistema que seja altamente
disponvel em casos como: falta de luz, defeito no hardware, link quebrado e at
mesmo terremoto. O nvel desta disponibilidade diretamente proporcional ao gasto
com a sua soluo e ao trabalho para a sua total implementao.
A HA est ligada diretamente a crescente dependncia aos computadores, pois
agora, eles possuem um papel fundamental, principalmente em empresas cuja maior
funcionalidade exatamente a oferta de servios computacionais, o que faz com que
elas no possam sofrer interrupes em suas aplicaes, como por exemplo, empresas
de e-business, notcias, banco de dados, dentre outras. No entanto, so essas
empresas que mais sofrem com as paradas no planejadas, o que acaba por
comprometer a qualidade de servio e principalmente, o prejuzo financeiro.
Para evitar interrupes no desejadas, o cluster de alta disponibilidade visa
manter a funcionalidade dos servios prestados por um sistema computacional,
replicando servios e servidores, atravs da redundncia de hardware, com sistemas

42

raid
1
, e com um ambiente de rede que suporte a duplicao em suas conexes e
reconfigurao de software, o que evita mquinas paradas e ociosas, esperando
apenas a outra falhar.

4.2 - Conceitos bsicos de Alta Disponibilidade

A principal finalidade da Alta Disponibilidade mascarar uma falha, para que o
usurio no sinta nenhuma diferena e que o sistema permanea normal para o
mesmo. Para tanto, alguns conceitos so necessrios para um melhor entendimento.

4.2.1 - Avaria (failure)

Ocorre quando seu comportamento desvia do normal de suas
especificaes, ou seja, o sistema est avariado quando ele no pode prover o servio
desejado (FILHO, 2002).

4.2.2 - Erro (error)

a parte do estado do sistema que est sujeita a levar a avarias subseqentes.
Se h um erro no estado do sistema, ento existe uma seqncia de aes que podem
ser executadas e que levaro a avarias, a no ser que medidas de correes sejam
tomadas e o sistema retorne ao seu funcionamento.
A causa de um erro uma falha (fault). Como erro uma propriedade do estado
do sistema, ele pode ser observado e avaliado. J uma avaria no um propriedade do
sistema, e no pode ser facilmente observada. Assim, a ocorrncia de uma avaria
deduzida detectando-se a ocorrncia de algum erro no sistema. Como tipicamente no

1
Mtodo para separar informao por um conjunto de discos, onde, de acordo com o nvel
escolhido aumenta a capacidade e redundncia.

43

vivel avaliar todo o estado do sistema para determinar a ocorrncia de erros, deve-
se escolher cuidadosamente qual parte do estado ser avaliado, a fim de se detectar a
maioria das avarias. As falhas so associadas com a noo de defeitos: um sistema
defeituoso aquele que contm falhas (RUIZ, 2000).

4.2.3. Falha (fault)

So os defeitos que possuem o potencial de gerar erros. De acordo com
sua durao e momento de ocorrncia, as falhas podem ser classificadas como
transientes ou permanentes: (FILHO, 2002).

Falhas transientes: so aquelas de durao limitada, causadas por mal
funcionamento temporrio ou por alguma interferncia externa. Tais falhas
podem ser tambm intermitentes, ocorrendo repetidamente por curtos
intervalos de tempo.

Falhas permanentes: so aquelas que uma vez que o componente falha, ele
nunca volta a funcionar corretamente. Muitas tcnicas de tolerncia a falhas
assumem que os componentes falham permanentemente.
Ainda, em um sistema de alta disponibilidade, possvel classificar as falhas
de acordo com o comportamento do componente defeituoso:

Falhas de Travamento: (Crash Faults). So aquelas falhas que causam o
travamento ou a perda do estado interno do componente defeituoso. Com este
tipo de falha, um componente nunca se submete a alguma transio incorreta
de estado quando falha.
Falhas de Omisso: (Omission Faults). So aquelas que fazem com que um
componente no responda a algumas requisies.
Falhas de Timing: (Timing Faults). So aquelas que fazem com que um

44

componente responda ou muito cedo ou muito tarde. Tambm so chamadas
de falhas de performance.
Falhas Bizantinas: (Byzantine Faults). So aquelas falhas que fazem com que
o componente se comporte de uma maneira totalmente arbitrria.

A figura 4.1 representa, graficamente, os vrios tipos de falhas.

Figura 4.1 Representao Grfica dos tipos de falhas

4.2.4 Failover

O processo no qual uma mquina assume ou derruba os servios de outra,
quando esta ltima apresenta falha, chamado failover. O failover pode ser automtico
ou manual, sendo o automtico o que normalmente se espera de uma soluo de alta
disponibilidade. Ainda assim, algumas aplicaes no crticas podem suportar um
tempo maior at a recuperao do servio, e portanto podem utilizar failover manual.
Alm do tempo entre a falha e a sua deteco, existe tambm o tempo entre a deteco
e o restabelecimento do servio.
Para se executar o failover de um servio, necessrio que as duas mquinas
envolvidas possuam recursos equivalentes. Um recurso pode ser uma placa de rede,
um disco rgido, ainda mais importante, os dados neste disco, e todo e qualquer
elemento necessrio prestao de um determinado servio. vital que uma soluo
de alta disponibilidade mantenha recursos redundantes com o mesmo estado ou nvel,
de forma que o servio possa ser retomado sem perdas.
Crash Omission Timing Byzantine

45

Dependendo da natureza do servio, executar um failover significa interromper
as transaes em andamento, perdendo-as, sendo necessrio reinici-las. Em outros
casos, significa apenas um retardo at que o servio esteja novamente disponvel.
Nota-se que o failover pode ou no ser um processo transparente, dependendo da
aplicao envolvida.
Em alguns casos h a necessidade de ser fazer um IP takeover, que far com
que a mquina, ou um servio dessa mquina saia totalmente do ar e uma segunda
mquina assuma seu endereo IP, passando a responder por ela. Muitas vezes
necessrio este procedimento devido a mquina no ter sado totalmente do ar e com
isto faz-se propositadamente uma parada geral na mquina primria.
Ao ser percebida a falha de um servidor, alm do failover obviamente
necessrio que se faa manuteno no servidor falho. Ao ser recuperado de uma falha,
este servidor ser recolocado em servio, e ento se tem a opo de realizar o
processo inverso do failover, que se chama failback.
Nos dias de hoje, existem failovers intercontinentais, entre o continente
americano e a europa. Cada vez que maior a distncia entre as mquinas, isso
acabar aumentando o tempo em que ser efetuada o failover.

4.2.5. Failback

O failback portanto o processo de retorno de um determinado servio de
uma outra mquina para sua mquina de origem. Tambm pode ser automtico,
manual ou at mesmo indesejado. Em alguns casos, em funo da possvel nova
interrupo na prestao de servios, o failback pode no ser atraente.
Os processos de failover e failback s entram em ao quando existem uma
parada no meio da misso de uma empresa. Pode-se dizer que, misso, o perodo de
tempo no qual o sistema deve desempenhar suas funes sem interrupes. Por
exemplo, uma empresa que trabalhe das 08:00 at 17:00. Se houver uma parada fora
deste perodo, pode no influenciar em nada o funcionamento da empresa. Agora, com

46

uma empresa trabalhando 24 horas com trocas de informaes, rotinas de backup,
acesso a internet, onde caracteriza uma misso contnua, qualquer parada dever ser
mascarada.
A alta disponibilidade visa eliminar as paradas no planejadas. Porm, no
primeiro caso, as paradas planejadas no devem acontecer dentro do perodo de
misso. Paradas no planejadas decorrem de defeitos, j paradas planejadas so
aquelas que se devem a atualizaes, manuteno preventiva e atividades correlatas.
Desta forma, toda parada dentro do perodo de misso pode ser considerada uma falha
no clculo da disponibilidade (WEBER, 2003).

4.3. Sistemas de Correo de Falhas

A complexidade de um sistema de alta disponibilidade est no software, que
deve monitorar, constantemente outra mquina da rede, saber que servios esto
sendo executados, quem os est executando, e como proceder em caso de uma falha.
Perdas na performance ou na capacidade de processamento so normalmente
aceitveis; o objetivo principal no parar. Existem algumas excees, como sistemas
de tempo real e de misso crtica.
A execuo da alta disponibilidade dividida em:

Manual Masking (MM) Aps o sistema falhar, a troca por um sistema
secundrio feita manualmente, deixando-o com um down at que o
administrador faa a mudana, o que deixa o sistema com o downtime maior
(FILHO, 2002).

Cold Standby (CS) - Aps uma falha, usurios do componente afetado so
desconectados e perdem todo trabalho em progresso (isto , ocorre um
rollback para o ltimo estado consistente de seu trabalho). Um failover
automtico do servio ocorre, porm, como o componente redundante estava

47

desativado, este precisa ser inicializado para poder comear a operar. Um
exemplo um cluster de duas mquinas, onde a standby (secundria)
permanece desligada. Quando ocorre uma falha de algum recurso, ela ligada
e inicializada para poder oferecer os servios (FILHO, 2002).

Warm Standby (WS) - Assim como no Cold Standby, os usurios so
desconectados e perdem o trabalho em progresso. Um failover automtico
ocorre, s que desta vez o componente redundante j est inicializado e
rodando. Ainda, o standby pode compartilhar algum estado com o recurso que
apresentou falha, possibilitando ento a recuperao (parcial ou no) do
trabalho que estava em progresso. O tempo de deteco da falha o mesmo
no caso anterior, mas o tempo de take over drasticamente reduzido (FILHO
2002).

Hot Standby (HS) / Active Replication (AR) - Os componentes redundantes e
ativos esto fortemente agrupados e (logicamente) indistinguveis a usurios.
O estado do processamento ativo e completamente compartilhado entre os
componentes do grupo. Aps uma falha, os usurios do componente
defeituoso no so desconectados e no observam erro algum, pois o trabalho
em progresso continua com os componentes restantes. Assim, neste modelo a
transparncia completa e a recuperao se torna instantnea, j que os
usurios no notam nenhuma parada no funcionamento do sistema (FILHO,
2002).
Uma ramificao da Alta Disponibilidade o Balanceamento de Carga (Load
Balancing). Ele um mecanismo usado para atingir escalabilidade, dividindo a carga de
processamento entre um conjunto de servidores, que pode ser chamado de fazenda de
servidores (server farm). De modo geral, os conceitos so muito ligados, mas no
pode-se dizer que alta disponibilidade com balanceamento de carga a melhor opo
para sistemas crticos. Alguns autores observam que o investimento feito para se
adquirir sistemas redundantes para alta disponibilidade no pode ser justificado se o

48

equipamento adicional esteja ocioso, ou est aumentando a demanda de trabalho
executado no servidor primrio, com muita troca de mensagens (FILHO, 2002).
Diferentemente de clusters de alta performance, esta diviso de carga feita em
alto nvel, ou seja, cada solicitao de um cliente atendida completamente por um
servidor; a idia dividir as solicitaes, e no as sub-tarefas nelas envolvidas. O
problema dessa abordagem que dificulta o design de ambos aspectos (HA e Load
Balancing), j que tal sistema no pode ser otimizado para as duas situaes.
A soluo de possuir um server farm que estar preparado tanto para substituir
servidores defeituosos em caso de falha, como tambm para dividir a carga de trabalho
em uma situao normal, boa at que no haja perda de rendimento. Por exemplo, se
houver dois servidores com Load Balancing e um desses servidores falha, tem-se uma
perda significativa de rendimento deste sistema, pois s uma mquina responder a
todas requisies, sendo assim impossvel de ser mascarada ao usurio final, devido a
sensvel lentido (FILHO, 2002).
A alta disponibilidade tem como caracterstica a no percepo de que houve
algum problema no sistema, por isso, requer um servidor primrio igual ao
secundrio(s) para que haja um perfeito transparncia da falha ao usurio.

4.3.1. SPOF Single Point of Failure

Em um estudo do sistema para torn-lo altamente disponvel, deve-se verificar os
pontos nicos de falhas (SPOF) que existem dentro do sistema. Neste conceito pode-se
englobar qualquer ponto que possa possibilitar uma falha do sistema, como: na parte de
hardware: hubs, switches, roteadores; na parte eltrica: empresa geradora de energia
eltrica; e at mesmo localizao de seus servidores, pois, por exemplo, catstrofes
metereolgicas existem e podem acarretar indisponibilizao do sistema.
Acabar com todos os SPOF torna-se uma tarefa impossvel, pois existem
solues que so inviveis estrutural e financeiramente. A soluo ideal diminuir ao
mximo os SPOF, at onde seja possvel. No entanto, pontos de falhas ficaro
existindo no sistema, s que bem mais difceis de acontecer que outros.

49

4.4. Tipos de Disponibilidade

A disponibilidade de um sistema computacional, est relacionada
diretamente ao nvel da sua soluo de alta disponibilidade para mascarar uma falha e
com isso, pode-se obter por A(t), a probabilidade de que este sistema esteja
funcionando e pronto para uso em um dado instante de tempo t. Esta disponibilidade
pode ser enquadrada em trs classes, de acordo com a faixa de valores desta
probabilidade. As trs classes so: Disponibilidade Bsica, Alta Disponibilidade e
Disponibilidade Contnua.

4.4.1. Disponibilidade Bsica
A Disponibilidade Bsica aquela encontrada em mquinas comuns, sem
nenhum mecanismo especial, em software ou hardware, que vise de alguma forma
mascarar as eventuais falhas destas mquinas. Costuma-se dizer que mquinas nesta
classe apresentam uma disponibilidade de 99% a 99,9%. Isto equivale a dizer que em
um ano de operao a mquina pode ficar indisponvel por um perodo de 9 horas a
quatro dias. Estes dados so empricos e os tempos no levam em considerao a
possibilidade de paradas planejadas, porm so aceitas como o senso comum na
literatura da rea (CONECTIVA, 2002).

4.4.2. Alta Disponibilidade

Adicionando-se mecanismos especializados de deteco, recuperao e
transparncia de falhas, pode-se aumentar a disponibilidade do sistema, de forma que
este venha a se enquadrar na classe de alta disponibilidade. Nesta classe as mquinas
tipicamente apresentam disponibilidade na faixa de 99,99% a 99,999%, podendo ficar
indisponveis por um perodo de pouco mais de 5 minutos at uma hora em um ano de

50

operao. Aqui se encaixam grande parte das aplicaes comerciais de Alta
Disponibilidade, como centrais telefnicas (CONECTIVA, 2002).

4.4.3 - Disponibilidade Contnua

Com a adio de noves se obtm uma disponibilidade cada vez mais prxima de
100%, diminuindo o tempo de inoperncia do sistema de forma que este venha a ser
desprezvel ou mesmo inexistente. Chega-se ento na Disponibilidade Contnua, o que
significa que todas as paradas planejadas e no planejadas so mascaradas, e o
sistema est sempre disponvel (CONECTIVA, 2002).

4.5 - Estados de Disponibilidade

Em um sistema real, durante sua vida til, um componente pode ser considerado
como estando em um destes estados: funcionando ou em reparo. O estado
funcionando indica que o componente est operacional, ou seja, est up, enquanto que
o estado em reparo significa que este falhou e foi substitudo por outro.
Em caso de defeitos, o estado do sistema muda de funcionando para em reparo
e quando a substituio feita ele volta para o estado funcionando. Sendo assim, pode-
se dizer que o sistema apresenta ao longo de sua vida Mean Time to Failure (MTTF),
Mean Time to Repair (MTTR) e Mean Time Between Failures (MTBF).

4.5.1 - Mean Time to Failure - MTTF

o tempo em que esperado uma falha no sistema. Com este dado, tem-se
idia de quanto tempo um sistema pode ficar uptime sem obter nenhuma parada
inesperada por motivo de falha (VARGAS, 2003).
Para calcularmos este tempo, usa-se a frmula: 1 / X, sendo X o tempo.

51

4.5.2 - Mean Time to Repair - MTTR

o tempo mdio de reparo do sistema. Este tempo o somatrio de trs aes:
o tempo que se leva para detectar a falha, o tempo para obter a soluo do problema e
o tempo de verificao de funcionamento do sistema (VARGAS, 2003).
Este tempo calculado com a seguinte frmula: 1 / Y, sendo Y a quantidade de
tempo necessrio para a resoluo do problema. Este tempo geralmente dado depois
de testes simulando falhas ou at mesmo com a experincia de um profissional
especializado no sistema, obtendo assim um tempo de reparo.
Por no haver um sistema que possa possibilitar um resultado exato do tempo de
reparo, difcil obter o com exatido resultado de MTTR.

4.5.3 - Mean Time Between Failures - MTBF

a medida em que pode-se obter o tempo entre duas consecutivas falhas. Este
tempo , normalmente, dado em horas. As variaes tpicas de MTBF so:

MTBF de Hardware - Refere-se ao tempo entre duas falhas de hardware
consecutivas. Esta varivel pode ser diminuda com redundncia de hardware.
Caso falhe uma memria, tem-se sempre uma outra para ser usada
automaticamente, diminuindo sensilvemente esta varivel (VARGAS, 2000).

MTBF de Sistema - o tempo mdio entre defeitos no sistema. Esse valor pode
ser aumentado levando em conta a quantidade de redundncia de hardware que
se tem. Quanto mais redundncia do mesmo hardware tiver no sistema, menor
ser seu MTBF de hardware, pois tem-se mais opes de falha de hardware
(VARGAS, 2000).

52

Mean Time Between Interruptions - MTBI o termo gasto para haver uma
interrupo ou instabilidade no sistema. No MTBI encaixam-se as falhas que no
precisam de reparos, onde o sistema automaticamente conserta o erro. (FILHO,
2000)

4.6 - Regra dos Noves

Para se obter uma classificao de tempo de disponibilidade do sistema, criou-se
a regra dos noves, que dar base para comparaes e medidas nesta rea. Em termos
tcnicos, a disponibilidade de certo servio dita como sendo a probabilidade de
encontr-lo operando normalmente em determinado momento. Portanto, tal
probabilidade leva em conta qual o provvel uptime e o provvel downtime. Tambm
muito comum utilizar-se uma notao diferente, baseada nesta probabilidade da
disponibilidade, com uma abordagem mais voltada ao marketing: mede-se a
disponibilidade a partir do nmero de noves do uptime que uma soluo prov.
De forma simplificada, diz-se que a disponibilidade de um sistema a relao
entre o tempo de vida til deste sistema e seu tempo total de vida. Isto pode ser
representado pela frmula abaixo:

Disponibilidade = MTTF / (MTTF + MTTR). (1)

O quadro abaixo, mostrar a relao da quantidade de noves (disponibilidade em
porcentagem) com o perodo que o sistema permanecer fora de operao (downtime).
Ele feito de acordo com a frmula do clculo da disponibilidade. (VARGAS, 2003)

53

Tabela 4.1 - HA utilizando a regra dos noves
Disponibilidade Downtime (por ano)
99,00%
87,6 horas
99.9%
8,76 horas
99.99%
52.6 minutos
99999,00%
5.26 minutos
99.9999%
31.5 segundos
99.99999%
3.15 segundos

Seu tempo de vida uma sucesso de MTTFs e MTTRs, medida que vai
falhando e sendo reparado. O tempo de vida til do sistema a soma dos MTTFs nos
ciclos MTTF+MTTR j vividos. De forma simplificada, diz-se que a disponibilidade de
um sistema a relao entre o tempo de vida til deste sistema e seu tempo total de
vida.
Na avaliao de solues para alta disponibilidade, importante levar em
considerao se na medio do MTTF so observadas, como falhas, as possveis
paradas planejadas pelo administrador.

4.7 - Confiabilidade x Disponibilidade

Confiabilidade uma medida que pode-se usar para falta de falhas. Quanto
menos o uso da alta disponibilidade maior ser a confiabilidade do seu sistema, pois ele
no apresenta falhas para haver o uso do servidor secundrio. Neste atributo, mesmo
pequenas medidas de perodos inoperantes do sistema so inaceitveis.
A confiabilidade representada mais freqentemente como um nmero ou uma
frmula que estima o tempo mdio at a falha acontecer, ou um MTTF probabilstico.
Quanto maior for o MTTF, maior ser sua confiabilidade, logo as avarias, os erros, e as
falhas so as circunstncias que comprometem a confiabilidade do sistema e por sua

54

vez sua disponibilidade. Pela definio, o uso desta medida de uma confiana
limitada, desde que probabilstico, pois falhas so fenmenos aleatrios no sistema.
No se pode confundir confiabilidade com disponibilidade, pois um sistema pode ser
altamente disponvel, mesmo com pequenos perodos de inoperncia.
A disponibilidade uma medida completamente diferente. Ela a medida da
probabilidade de um servio est disponvel para o uso em todo o instante. A
disponibilidade permite a falha do servio, com a presuno que a restaurao do
servio imediata. Com a disponibilidade elevada deve-se minimizar os intervalos da
restaurao.

4.8 - Solues de Softwares para Ambientes de HA

Quando utiliza-se um ambiente de alta disponibilidade um conceito adquirido.
O conceito de endereo IP virtual. O endereo IP virtual o endereo em que
prestado determinado servio. Nesta idia, pode-se dizer que o servio HTTP por
exemplo, funciona em um IP especfico e no em cima de um servidor. Com isso, este
endereo poder ser assumido por uma mquina secundria igual quando ocorrer
alguma falha no servidor primrio, sendo transparente para o usurio a mudana de
mquina.
Alm deste conceito, ferramentas sero utilizadas para obtermos a alta
disponibilidade. O sistema de arquivos journaled utilizado, por padro, pelo Linux
Conectiva 9 ext3. Ele oferece compatibilidade com o ext2, eliminando a necessidade
de se recriar o filesystem, com isso ele fica sendo a melhor opo, apesar de alguns
testes mostrarem uma leve superioridade do reiserfs sobre o ext3, mas esta diferena
no chega a ser to grande para suplantar a facilidade e segurana na mudana de
filesystem.
O heartbeat um programa feito em bash script que faz o monitoramento em
ambientes de alta disponibilidade. Ele verifica o sinal de vida, como o nome j diz, do
servidor primrio por meio de ping. Caso no haja retorno (resposta do ping), ele faz um
failover no servidor primrio, configura o endereo IP e inicia os servios no servidor

55

secundrio. Alm disso, tambm presta os servios de comunicao intra-cluster, que
fazem a troca de mensagens entre os servidores. (MILZ, 1998). ele tambm que
determinar qual o servidor assumir o papel do primrio, incluindo a inicializao de
servios previamente configurados. O heartbeat s comporta o uso de duas mquinas
na sua soluo.
Para uma soluo de alta disponibilidade alm de ter-se programas que faam a
monitorao do servidor primrio, precisa-se de um programa que faa a copia dos
dados e arquivos de configurao do servidor primrio, deixando assim idnticos entre
si. O copyfiles desempenha esta funo. Um programa feito em bash script transfere os
dados atravs de um canal de backup, por uma conexo SSH, de maneira
criptografada, deixando assim sua copia de dados, bastante segura.
Para computadores com um volume muito grande de dados de escrita, convm
utilizar um utilitrio para fazer RAID 1. O DRBD o programa ideal para isto. Ele far o
espelhamento do HD do servidor primrio para o HD do servidor secundrio atravs de
uma rede. Neste processo a ateno tem que ser redobrada, pois um erro na
configurao inicial, pode causar a perda total da partio onde esto os dados.

56

CAPTULO V

ESTUDO DE CASO: IMPLEMENTAO


Um estudo sobre diversas ferramentas que podem ser utilizadas em um
ambiente de Alta Disponibilidade e, tambm, de como modelar estas ferramentas no
seu ambiente de rede de fundamental importncia para que seja feita a implantao
deste sistema.
Para se implantar um sistema com Alta Disponbilidade, primeiro define-se o
servidor primrio e depois, o secundrio. O ideal possuir hardwares e softwares,
assim como, as configuraes de sistema operacional semelhantes.
Em estudos realizados, optou-se por utilizar neste trabalho a soluo utilizando o
heartbeat. Outras solues existem e podem ser utilizadas para solucionar diversos
outros problemas.

5.2. Instalao

Uma instalao bsica do Conectiva 9.0 nos dois servidores para e-business,
com Apache (servidor web) feita igualmente em cada uma das mquinas para se
modelar um sistema de Alta Disponibilidade. O copyfiles no vem na instalao padro
do Conectiva, por isso necessrio fazer a cpia dele e efetuar a sua instalao. O
Heartbeat e o OpenSSH (padro) vem na distribuio do Conectiva Linux 9.0.
feita a cpia do pacote heartbeat-0.4.9.1-1cl.i386.rpm do CD Conectiva 9.0
para o servidor secundrio. Depois feita a instalao deste pacote como mostra a
figura abaixo.

57

Figura 5.1 Instalao do Heartbeat 0.4.9-1

Para a instalao do copyfiles.tar.gz, tem-se que escolher um diretrio onde ser
instalada a ferramenta. Depois da escolha do diretrio, s descompact-la.

Figura 5.2 Descompactao do Copyfiles

58

5.3 - Configuraes

necessrio fazer algumas configuraes nas ferramentas que sero utilizadas
para um sistema de Alta Disponibilidade, para que se possa definir de que maneira as
ferramentas iro ser comportar.

5.3.1 Heartbeat

O arquivo de configurao do heartbeat pode ser achado em /etc/ha.d/ha.cf.
Dentro dele, tem-se que configurar algumas linhas comentadas abaixo:

Tabela 5.1 - Configurao do Heartbeat
Keepalive 2 Tempo em segundos entre duas verificaes de vida
consecutivas da mquina primria.
Deadtime 10 Tempo em segundos para determinar que a mquina
primria est morta.
Udpport 694 A porta UDP que este servio ir utilizar.
Nice_failback off Desativa a opo failback.
UDP eth0 Por qual interface de rede ser feito este
monitoramento.
Node secundrio Neste campo coloca-se o nome da mquina
secundria.
Node primrio Neste campo coloca-se o nome da mquina primria,
a qual ser monitorada.

Uma vez configurado o ha.cf, precisa-se configurar o arquivo haresources,
encontrado dentro de /etc/ha.d. Este arquivo especifica os servios do cluster. Para
este trabalho, assumir-se- que os servios so Apache e MySQL. O arquivo ir
precisar de uma linha de configurao:

59

Tabela 5.2 - Configurao do haresources
Primario 10.1.1.1 http Ir configurar o IP do servidor secundrio para
10.1.1.1 e iniciar o servio HTTP.

O terceiro arquivo para configurar determina sua autenticao, o authkeys,
encontrado dentro de /etc/ha.d. Existem trs mtodos de autenticao disponveis: crc,
md5 e sha1. Caso o heartbeat rode em uma rede segura, como neste caso, um cabo
cruzado por exemplo, optar-se- usar crc. Este o mtodo mais barato do ponto de
vista de recursos. Se a rede insegura, deve-se usar md5. O sha1 para rede
insegura tambm, s que bem mais robusto, trabalhando com autenticao, sem se
preocupar com recursos de CPU.
O arquivo authkeys da seguinte maneira:

Tabela 5.3 - Configurao do authkeys
auth 1 Autenticao com opo 1.
1 crc 1 o nmero da autenticao para CRC.

5.3.2. Copyfiles

O arquivo de configurao do copyfiles estar dentro de onde descompactar o
arquivo. O seu nome copyfiles.cfg. Dentro dele precisa-se configurar os arquivos e
diretrios que sero copiados para a mquina secundria. Alguns exemplos so:

Tabela 5.4 - Configurao do copyfiles
/root/temp Copiar o arquivo temp.
/root/banco/* Copiar todos os arquivos e diretrios dentro do
diretrio /root/banco .

60

5.3.3. OpenSSH

O OpenSSH ter papel importante no cluster de Alta Disponbilidade. por meio
dele que ser feita a cpia criptografada dos arquivos do servidor primrio para o
secundrio. Como necessrio a passagem de parmetro de login e senha para a
conexo entre os servidores via protocolo SSH, este procedimento ser feito atravs de
chaves pblica e privada, no necessitando assim a passagem de nenhum parmetro.
Primeiramente, tero que ser criadas as chaves pblica e privada no servidor
secundrio de um usurio que tenha permisso de leitura nos diretrios que iro ser
copiados. Estas chaves sero criadas com passphrase em branco, deixando assim
automtica a conexo via SSH. Na experincia criou-se as chaves para o usurio root.

Figura 5.3 Criao das Chaves

Depois do processo de criao das chaves, surgiro dois arquivos: id_dsa.pub
(chave pblica) e id_dsa (chave privada). Com a chave pblica criada no arquivo citado
anteriormente, ela ter que ser renomeada para authorized_keys transferida para o

61

servidor primrio, dentro do diretrio /root/.ssh. neste arquivo onde ficam as chaves
pblicas que tero acesso via SSH.
O prximo passo fazer a configurao do sshd_config, encontrado dentro do
diretrio /etc/ssh. Altera-se a seguinte linha:

Tabela 5.5 - Configurao do sshd_config
AuthorizedKeysFile .ssh/authorized_keys Descomenta-se esta linha
habilitando a conexo por chave.

5.4. Funcionamento

O funcionamento das ferramentas feito de maneira integrada, pois cada uma
desempenhar papel importante em uma soluo de alta disponibilidade. As trs
ferramentas so comentadas detalhadamente abaixo.

5.4.1. Funcionamento do Copyfiles

O canal de backup, que ser um cabo cross-over entre as mquinas, far com
que os arquivos, sejam copiados via este canal para o servidor secundrio. Pode-se
estipular um tempo adequado apartir da quantidade de dados que sero checados e
enviados. Coloca-se o script copyfiles na cron do Conectiva Linux com o intervalo de
tempo previamente estipulado, para que seja feita a execuo do script
automaticamente, sem precisar da iterao humana.
O canal de backup no ir fazer com que congestione a placa de rede principal
dos servidores, por onde so feitas as requisies de servios. Ficando este canal,
ligados em placas de rede com esta funo especfica.
Quando ocorrer alguma alterao em arquivos do servidor primrio, a alterao
s ser efetuada no servidor secundrio, quando o copyfiles for executado novamente,
pois ele um script de cpia de arquivos e no de espelhamento de HD.

62

Em ambientes com servio de alta disponibilidade utilizam bancos de dados,
onde recomendvel fazer a utilizao do DRBD, que far esse espelhamento
esperado.
O copyfiles utilizar o canal de backup para copiar os arquivos escolhidos dentro
do seu arquivo de configurao. Na primeira utilizao dele, ele far a cpia de todos os
arquivos. A partir da segunda, ele s copiar arquivos do servidor primrio que no
existem no servidor secundrio, ou, que tenham sofrido alguma mudana, diminuindo
assim o trfego de dados.

5.4.2. Funcionamento do Heartbeat

Os servidores primrio e secundrio, ficam trocando mensagens entre si para a
verificao de resposta atravs do barramento principal, pois por ele que
respondida as requisies do servio. Esta a maneira que o heartbeat trabalha,
monitorando as mensagens recebidas do outro servidor como se fossem pulsos do
corao.
Em uma situao onde o servidor primrio falhar, o heartbeat do servidor
secundrio no recebe a mensagem de resposta que deveria. Com isso, assume-se
que o servidor principal falhou, logo o servidor secundrio passa a responder pelo IP
virtual e pelo seus servios. As sesses de servios ativas no servidor principal so
perdidas e as novas sesses sero abertas agora no servidor secundrio, que passa a
ser o responsvel por atender os servios. Tudo isso sendo transparente ao usurio.
As mensagens continuam sendo enviadas pelo servidor operante at que o
servidor que apresentou a falha volte a operar. Quando isso acontece, o heartbeat
decide, baseado na configurao de nice_failback (ligada ou desligada) do arquivo de
configurao do heartbeat, qual dos dois deve assumir o IP virtual. Se estiver ligada, os
servidores trocam de papel, fazendo com que o servidor primrio assuma o papel de
secundrio ao voltar a operar. Se estiver desligada, o servidor secundrio continua a
responder as requisies destinadas ao IP virtual.

63

A falha mais grave que pode acontecer em um sistema de Alta Disponibilidade,
quando a falha ocorre somente no meio fsico utilizado pelo heartbeat para a troca das
mensagens. Por exemplo, quando se retira o cabo TP de um dos servidores por onde
esta sendo feito o monitoramento, o heartbeat e o servidor continuam em operao e
como deixa de receber as mensagens, interpreta que o outro servidor falhou e assume
o IP virtual. Nesse ponto, ainda no h problema, pois um dos servidores est sem
comunicao com a rede. Porm, se o cabo de rede for religado, o ambiente ser
levado a um estado inconsistente, pois os dois servidores estaro respondendo pelos
servios e a um IP virtual. Nesse caso necessrio a reconfigurao do servidor
secundrio, sendo desligada a sua placa de rede.
A estrutura de rede tem que estar bem condicionada, com equipamentos em
bom estado e em revises peridicas para evitar-se este tipo de problema, que pode
ocorrer.

5.5. Ambiente de Testes

Neste ambiente de testes de Alta Disponibilidade de um servio e-business, foi
utilizado os seguinte equipamentos e softwares:

Servidores: Pentium IV, 2.0 GHz, 128 MB de RAM, HD 20GB e placa de rede.
- Servidor Primrio:
eth0: 192.168.0.1 / 255.255.255.0 (Rede Local LAN)
eth1: 10.1.1.1 / 255.255.255.252 (Rede do Canal de Backup)
eth2: 10.2.2.1 / 255.255.255.252 (Rede para acesso ao Banco de Dados)
- Servidor Secundrio:
eth0: 192.168.0.2 / 25.255.255.0 (Rede Local LAN)
eth1: 10.1.1.2 / 255.255.255.252 (Rede do Canal de Backup)
eth2: 10.2.2.2 / 255.255.255.252 (Rede para acesso ao Banco de Dados)
Sistema Operacional: Conectiva Linux 9.0

64

Ferramentas: Heartbeat-0.4.9.1-1, Copyfiles, OpenSSH-server-3.5p1-6, HTTPd-
2.0.40-21 (Apache) e MySQL-server-3.23.54a-11.
O ambiente de rede construdo para este trabalho representado na figura 5.4.

5.6. Teste do Ambiente

Para se verificar a situao do estado do sistema, ir verificar-se as informaes
da placa de rede e portas abertas, para depois, comparar quais as diferenas que
ocorreram.
Dividir-se- em trs situaes o teste do ambiente:

Teste do ambiente normal, ou seja, mquina primria funcionando
normalmente.
Teste do ambiente com falha no servidor primrio, onde a mquina
secundria responde requisies da mquina primria.
Teste do ambiente com a volta do servidor primrio, quando ela volta ao seu
estado de funcionamento normal, depois de um reparo.
Figura 5.4 Ambiente de rede utilizado para o teste.

65

5.6.1 - Situao 1 Ambiente normal

Verifica-se o estado do ambiente em situao de normalidade do servidor
primrio. Neste momento o servidor primrio responde ao ping do servidor secundrio,
mostrando que esta disponvel para o uso, figura 5.5.
O canal de backup est em funcionamento, fazendo a cpia dos arquivos
periodicamente de acordo com a cron do sistema operacional, como mostra a figura
5.6.
Figura 5.5 Ambiente de rede em estado normal.

Figura 5.6 Portas abertas no servidor secundrio (situao 1).

66

Pode-se verificar na figura 5.6, a porta UDP 694 aberta no servidor secundrio,
caracteriza a existncia do hearbeat startado neste servidor. Esta porta a padro do
software.

5.6.2. Situao 2 Falha no servidor primrio

Verificar-se- o estado do ambiente em situao de falha do servidor primrio e
funcionamento do servidor secundrio. Neste momento o servidor primrio deixar de
responder ao ping e ento o servidor secundrio assume o endereo IP e as
requisies do servio de HTTP, como pode verificar na figura 5.7.

Figura 5.7 Ambiente com o servidor principal.

Neste momento, o servidor secundrio se auto-configura com o endereo IP do
servidor primrio, na interface de rede eth0:0, pois a eth0 j esta ocupada com o IP
192.168.1.2, por onde feito o monitoramento do sinal de vida.
O heartbeat continua startado (iniciado), como pode-se observar na figura 5.8,
com a porta UDP 694 aberta.

67

Figura 5.8 Portas abertas no servidor secundrio (situao 2).

5.6.3 - Situao 3 Volta do Servidor Primrio

Depois de verificar e solucionar o problema do servidor primrio, tem-se que ter
muito cuidado na hora de recolocar ele a responder pelo IP virtual. Se no houver uma
prvia reconfigurao no servidor secundrio, desconfigurando a interface criada pelo
heartbeat (eth0:0), o sistema entra em conflito, devido duas mquinas com um mesmo
IP virtual, podendo at, a conrromper o banco de dados usado pelo sistema, no caso
MySQL.
Quando o servidor secundrio j esta configurado, agora sim pode-se colocar o
servidor primrio respondendo as requisies do servio. A sua placa de rede eth0 volta
a ter o IP 10.1.1.1.
O canal de backup continua com seu funcionamento normal neste teste, no
tendo nenhum problema.

5.7 - Consideraes Finais

Com o canal de backup entre as duas mquinas, o heartbeat faz o backup e o
monitoramento do sinal de vida do servidor primrio. Quando o servidor primrio no
responde mais ao ping, ele far o failover, adicionando assim o IP do servidor primrio
no seu ambiente.

68

Caso haja um problema de indisponibilidade no canal de backup, o sistema no
tratar esta falha, pois o monitoramento est restrito apenas a disponibilidade do
servidor primrio para a rede.
Com este ambiente de sistema, tem-se uma disponibilidade bastante
considervel, deixando o servio crtico altamente disponvel, diminuindo assim o
prejuzo da empresa que oferece servios de e-business, necessitando de um tempo
mximo de uso de seus servidores.

69

6 - CONCLUSO

Neste trabalho, utilizou-se solues de sistemas que ofeream segurana e alto
desempenho ao usurio. Onde estas qualidades foram mostradas com um baixo custo,
ao passe que um supercomputador custa alguns milhes de reais para se alcanar uma
qualidde semelhante aos sistemas com alta disponibilidade.
Durante a elaborao deste trabalho, foram enfrentados problemas que
dificultaram, mas que no impediram o seu desenvolvimento. Dentre os quais, escasso
material de pesquisa na rea.
Como foi mostrado no captulo 5, na implementao obtem-se sucesso graas a
sistemas operacionais editveis, que no caso utiliza-se o GNU/Linux, onde este foi
capaz de facilitar ao mximo a instalao e o controle de hardware, alm de ter se
mostrado estvel e de fcil configurao.
No se pode dizer que exista somente uma soluo ideal para se ter um sistema
de Alta Disponibilidade instalado e funcionando. Tanto que as ferramentas necessrias
para esta implantao, pode ser adequadas de acordo com a necessidade e ao
ambiente de rede.
A imaginao de como prevenir possveis falhas, far com que as ferramentas
sejam organizadas e alocadas para uma soluo segura e vivel entre servidores Linux.

70

REFERNCIAS BIBLIOGRFICAS

ALMASI, G. High Parallel Computing. The Benjamin Cummings Publishing
Company, Inc., 1994.
CENAPAD, N. Apostila do Workshop MPI, Fevereiro, 1998.
<http://www.cenapad.unicamp.br>
CONECTIVA S.A, 2003. Disponvel em: <http://www.conectiva.com.br>. Acesso
em: 28/09/2003.
ERNESTO, M. Projeto CLUSTER KAMINARI. Universidade Federal de Sergipe,
Projeto de Criao de Cluster Departamento de Fsica da UFSE , Aracaj 1999.
FILHO, N. Linux, Clusters e Alta Disponibilidade. Universidade de So Paulo,
2002. Disponvel em: <http://www.ime.usp.br/~nelio/publications/linuxha/html/>.
Acesso em 10/08/2003.
HIGH AVAILABILITY, Linux Project. Linux-HA, 2003. Disponvel em:
<http://www.linux-ha.org>. Acessado em: 03/05/2003.
HIGH AVAILABILITY. LVS, 1998. Disponvel em:
http://www.linuxvirtualserver.org/HighAvailability.html. Acesso em: 23/05/2003.
MILZ, H. Linux High Availability HOWTO. Ibiblio, 1998. Disponvel em:
<http://www.ibiblio.org/pub/Linux/ALPHA/linux-ha/High-Availability-HOWTO.html>.
Acesso em 26/03/2003.
PEIXOTO, L., Escalonamento Adaptativo em Sistemas Paralelos. Proposta de
Dissertao de Mestrado. Universidade do Minho Campus de Gualtar Portugal
2002
RUIZ, A. Alta disponibilidade em servidores Linux. Revista do Linux, 2000.
Disponvel em: <http://www.revistadolinux.com.br/ed/006/alta.php3>. Acesso em:
13/08/2003.
STERLING, T. Beowulf Cluster Computing with LINUX. Massachusetts
Institute of Technology. The MIT Press, 2002.

71

PITANGA, MARCOS. Clube do Hardware, 2003. Disponvel em:
<http://www.gabrieltorres.com.br/clusters>. Acesso em: 09/07/2003
VARGAS, E. High Availability Fundamentals. Sun Microsystems, San Antonio,
2000. Disponvel em:<http://www.sun.com/blueprints/1100/HAFund.pdf>. Acesso
em: 30/06/2003.

JALOTE, P. Fault Tolerance in Distribuited Systems. Prentice-Hall. Englewood
Cliffs, New Jersey, 1994.

2003 Altadisponibilidade PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

2003 Altadisponibilidade PDF

Încărcat de

Drepturi de autor:

Formate disponibile

UNAMA UNIVERSIDADE DA AMAZNIA

CCET CENTRO DE CINCIAS EXATAS E TECNOLGIA

S-ar putea să vă placă și