RESUMO

ESTEVAM JNIOR, Joo; HONRIO, Marcelo Vieira. Sistema de monitorao de servios em um cluster de alta disponibilidade. 2004. 126f. Trabalho de Concluso de Curso (Graduao em Cincia da Computao) Universidade de Franca, Franca.

Desde sua criao, o Linux trouxe muita ateno ao movimento open-source e concreta possibilidade de se usar solues de baixo custo em misses crticas. Nos ltimos anos, esta possibilidade tornou-se real com a criao de vrios sistemas para clusters de alta disponibilidade, tanto open-source quanto comerciais. No desenvolvimento desse projeto foram realizadas pesquisas por solues baseadas em software livres existentes para criao de um ambiente de alta disponibilidade, no entanto, as encontradas so muito limitadas, porem passam por aperfeioamentos. A soluo escolhida para realizao desse trabalho foi o Heartbeat, uma ferramenta de monitoramento de estado operacional dos ns pertencentes a um cluster de Alta Disponibilidade, a qual fica apenas verificando se um n esta ativo ou no. Essa ferramenta no possui uma gerncia de servios, ou seja, ela no leva em considerao o estado dos servios que esto sendo executados, podendo causar problemas e conflitos. Esse trabalho visa apresentar conceitos relativos a sistemas distribudos, clusters e alta disponibilidade. Com estes conceitos definidos, ser desenvolvido um subsistema de monitorao e gerenciamento de servios para trabalhar em conjunto com o Heartbeat, suprindo uma grande deficincia do mesmo.

Palavras-chave: clusters; alta disponibilidade; tolerncia falhas; heartbeat.

ABSTRACT

ESTEVAM JNIOR, Joo; HONRIO, Marcelo Vieira. Sistema de monitorao de servios em um cluster de alta disponibilidade. 2004. 126f. Trabalho de Concluso de Curso (Graduao em Cincia da Computao) Universidade de Franca, Franca.

Since its creation, Linux has called lots of attention to the open-source movement and to the concrete possibility of using low cost solutions in critical missions. In the last few years, this possibility became real with the creation of several systems to clusters of high availability, as open-sources as business. In the development of this project researches were carried out to find open source existing solutions for the creation of a high availability environment, however, the findings are much limited, but they pass through improvements. The chosen solution to the accomplishment of this assignment was the Heartbeat, a special tool of computers monitoring belonging to a High Availability cluster, in which stays only checking if there is an active knot, and not taking for granted the condition of its services. This assignment aims to show concepts about shared systems, clusters and high availability. With these given concepts, it will be developed a monitoring and managing system of services to work together with Heartbeat.

Key words: clusters; high availability; tolerance to failure; heartbeat.

SUMRIO

1 1.1 1.2 1.3 2 2.1 2.1.1

INTRODUO .............................................................................................................. 14 DESCRIO DO OBJETIVO DA PESQUISA .......................................................... 16 RELEVNCIA DA PESQUISA .................................................................................. 17 ORGANIZAO DO TRABALHO ........................................................................... 18 REFERNCIAS TERICAS........................................................................................ 20 SISTEMAS DISTRIBUDOS ...................................................................................... 20 Sistemas de arquivos distribudos ............................................................................ 22 Princpios dos sistemas de arquivos distribudos ..................................................... 23 Exemplos de sistemas de arquivos distribudos ....................................................... 25 AFS (Andrew File System) .................................................................................. 26 PVFS (Parallel Virtual File System) .................................................................... 27 GFS (Global File System) .................................................................................... 31 Coda (Constant Data Availability) ....................................................................... 32 Network File System ............................................................................................ 33

2.1.1.1 2.1.1.2 2.1.1.2.1 2.1.1.2.2 2.1.1.2.3 2.1.1.2.4 2.1.1.2.5 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.4.1

CLUSTER .................................................................................................................... 38 Tipos de clusters ....................................................................................................... 41 Benefcios de um cluster........................................................................................... 43 Princpios de um cluster ........................................................................................... 44 Elementos de um cluster ........................................................................................... 45 N ............................................................................................................................. 45

2.2.4.2 2.2.4.3 2.2.4.4 2.2.5 2.2.5.1 2.2.5.2 2.2.5.3 2.2.5.4 2.2.5.5 2.2.5.6 2.2.5.7 2.2.5.8 2.2.6 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.3.5.1 2.3.5.2 2.3.5.3 2.3.6 2.3.6.1 2.3.6.2

Recurso ..................................................................................................................... 46 Dependncia de recursos .......................................................................................... 46 Grupos de recursos ................................................................................................... 47 Arquitetura de um cluster ......................................................................................... 48 Camada de comunicao .......................................................................................... 49 Camada de ligao .................................................................................................... 50 Camada de integrao ............................................................................................... 50 Camada de recuperao ............................................................................................ 51 Servio de Informaes (JDB) ................................................................................. 52 Camada de quorum ................................................................................................... 52 Servio de barreiras .................................................................................................. 53 Servio de nomes ...................................................................................................... 53 Cluster hierrquicos .................................................................................................. 54 ALTA DISPONIBILIDADE ........................................................................................ 55 Clculo da disponibilidade ....................................................................................... 60 Dependabilidade ....................................................................................................... 62 Confiabilidade .......................................................................................................... 62 Segurana.................................................................................................................. 63 Classes de disponibilidade ........................................................................................ 64 Disponibilidade bsica (Basic Availability) ............................................................. 64 Alta disponibilidade (High Availability) .................................................................. 65 Disponibilidade continua (Continuous Availability)................................................ 67 Defeitos, erros e falhas ............................................................................................. 67 O modelo de trs universos ...................................................................................... 69 Classificao de falhas.............................................................................................. 70

2.3.7 2.3.7.1 2.3.7.1.1 2.3.7.1.2 2.3.7.1.3 2.3.7.1.4 2.3.8 2.3.8.1 2.3.8.2 2.3.8.3 2.4 2.4.1 2.4.2 2.5 3 3.1 3.2 3.2.1 3.2.2 3.2.3 4

Tolerncia falhas .................................................................................................... 71 Fases na tolerncia falhas ...................................................................................... 72 Deteco de erros.................................................................................................. 72 Confinamento de danos ........................................................................................ 73 Recuperao de erros ............................................................................................ 74 Tratamento da falha e continuidade dos servios ................................................. 75 Cluster de alta disponibilidade ................................................................................. 76 Compartilhamento de recursos de armazenamento .................................................. 78 Cluster VS. Sistemas Distribudos ........................................................................... 79 Clusters Linux .......................................................................................................... 80 FERRAMENTAS PARA CLUSTERS DE ALTA DISPONIBILIDADE .................. 81 Modelo de funcionamento do Heatbeat .................................................................... 83 Software Mon ........................................................................................................... 84 XML ............................................................................................................................. 85 PROJETO DE IMPLEMENTAO ........................................................................... 88 FORMATO DE MENSAGENS XML ......................................................................... 88 ESQUEMA DE FUNCIONAMENTO PROPOSTO ................................................... 96 Evento alterao de estado de um host ................................................................... 100 Evento para checar estado de servio ..................................................................... 105 Evento de recebimento de uma nova mensagem .................................................... 109

RESULTADOS ............................................................................................................. 115

CONCLUSO....................................................................................................................... 121 REFERNCIAS ................................................................................................................... 124

LISTA DE FIGURAS

Figura 1 - Exemplo de um Sistema Distribudo Figura 2 - Dependncia de recursos em um servidor HTTP Figura 3 - Custo da disponibilidade Figura 4 - Modelo de 3 Universos Figura 5 - Exemplo de Cluster Figura 6 - Modelo funcionamento atual do Heartbeat Figura 7 - Exemplo de arquivo XML Figura 8 - Modelo mensagem xml_active. Figura 9 - Modelo mensagem xml_accept. Figura 10 - Exemplo mensagem xml_replyaccept. Figura 11 - Modelo mensagem xml_migrate. Figura 12 - Modelo mensagem xml_replymigrate. Figura 13 - Formato mensagem xml_running. Figura 14 - Modelo mensagem xml_replyrunning. Figura 15 - Modelo de arquivo de configurao. Figura 16 - Viso dos hosts no estado Em Execuo. Figura 17 - Situao dos hosts antes do Estado de Transio. Figura 18 - Imagem do cluster no estado em Transio. Figura 19 - Imagem do cluster em Transio com migrao de IP. Figura 20 - Imagem do cluster em Transio com migrao de servio.

22 47 59 69 77 84 87 89 90 90 91 91 92 92 96 99 102 103 104 104

Figura 21 - Imagem de host enviando mensagem xml_active aps Transio. Figura 22 - Imagem da situao atual do cluster. Figura 23 - Imagem do host_1 efetuando a checagem de estado do recurso_1. Figura 24 - Host_1 envia mensagem xml_active para host_2 e host_3. Figura 25 - Fluxo da mensagem xml_active. Figura 26 - Fluxo da mensagem xml_accept. Figura 27 - Fluxo da mensagem xml_replyaccept. Figura 28 - Fluxo da mensagem xml_migrate. Figura 29 - Fluxo da mensagem xml_replymigrate. Figura 30 - Fluxo da mensagem xml_running. Figura 31 - Fluxo da mensagem xml_replyrunning. Figura 32 - Tela contendo informaes do estado atual dos hosts. Figura 33 - Tela aps envio de mensagem xml_active. Figura 34 - Tela aps recebimento de mensagem xml_active.

105 107 107 108 111 112 112 112 113 114 114 116 117 118

Figura 35 - Tela com solicitao de mensagem xml_running e resposta xml_replyrunning. 119 Figura 36 - Computador executando programa cliente. 120

LISTA DE TABELAS

Tabela 1 - Medindo a disponibilidade Tabela 2 - Exemplos de confiabilidade, disponibilidade e segurana Tabela 3 - Tabela de hosts no Estado Inicial. Tabela 4 - Tabela de hosts no Estado Inicial com host inativo. Tabela 5 - Tabela de recursos no Estado Inicial. Tabela 6 - Tabela de hosts ativos. Tabela 7 - Tabela de recursos ativos. Tabela 8 - Tabela de hosts quando o cluster entra em Transio. Tabela 9 - Tabela de servios quando o cluster entra em Transio. Tabela 10 - Tabela de servio com cluster finalizando Transio. Tabela 11 - Tabela da situao atual dos hosts. Tabela 12 - Tabela da situao atual dos servios no cluster. Tabela 13 - Tabela de recursos aps checagem de estado. Tabela 14 - Tabela de servios atualizada pela mensagem xml_active. Tabela 15 - Tabela de servios atualizada aps a migrao de servios.

60 64 98 98 98 102 102 103 103 104 106 107 108 111 113

LISTA DE QUADROS

Quadro 1 - Exemplos de sistemas e suas disponibilidades necessrias Quadro 2 - Clusters vs Sistemas Distribudos Quadro 3 - Exemplo de software para cluster Linux Quadro 4 - Caractersticas dos computadores utilizados no ambiente de trabalho

61 79 81 115

LISTA DE ABREVIATURAS

AFS API CODA COTS FTP GFS HTTP IP MTTF MTTR NFS NLM PVFS RPC SAD SPOF VFS

Andrew File System Application Program Interface Constant Data Availability Commodity Off the Shelf File Transfer Protocol Protocolo de Transferncia de Arquivos Global File System Hyper Text Internet Protocol Mean Time to Failure Maximum Time To Repair Network File Systems Network Lock Manager Protocol Parallel Virtual File System Chamada de Procedimento Remoto Sistemas de Arquivos Distribudos Single Point of Failure Sistema de Arquivos Virtual

14

INTRODUO

Nos dias atuais, empresas que precisam funcionar vinte e quatro horas por dia no podem ter seus sistemas computacionais fora do ar, seja por umas horas ou at mesmo por alguns minutos, pois isso pode significar grandes prejuzos para a mesma. Uma estrutura de disponibilidade se faz necessria, a fim de minimizar os riscos da ocorrncia de falhas no ambiente computacional. Grandes corporaes como a IBM e a Microsoft j perceberam a importncia dessa abordagem e, segundo Pereira Filho (2004), estas duas empresas j iniciaram um investimento significativo no desenvolvimento de produtos para satisfazer os requerimentos de uma maior disponibilidade dos sistemas computacionais. Em adio s solues proprietrias, alguns esforos de desenvolvimento de softwares livres comearam a demonstrar uma maturidade funcional. Apesar da idia de se fazer software livre ser antiga, somente agora ela est popularizando-se. O Linux, um sistema operacional de cdigo aberto criado por Linus Torvalds, vem recebendo ajuda e aceitao de programadores e empresas do mundo todo, o que tem contribudo muito para o crescimento do software livre. At pouco tempo atrs, sua participao em servidores de aplicaes crticas se restringia por no ser um sistema operacional confivel o suficiente e por no oferecer recursos de alta disponibilidade. Esta situao est mudando rapidamente pois os esforos de desenvolvimento da comunidade Linux vem apresentando resultados de estabilidade e confiabilidade crescentes, alm do que torna-se cada vez mais evidente que solues de baixo custo so necessrias e atraentes. O sistema operacional Linux possui tais ingredientes bsicos, o que tem ocasionado um grande crescimento do n-

15 mero de aplicativos de software livre para Linux. A alta disponibilidade, segundo Pitanga (2003), consiste em um conjunto de tcnicas com o objetivo de aumentar a disponibilidade dos servios prestados por um sistema computacional, replicando servios e servidores atravs da redundncia de hardware e reconfigurao de software, sendo que perdas na performance ou na capacidade de processamento so normalmente aceitveis pois o objetivo principal evitar a interrupo dos servios. Um Cluster um conjunto de mquinas fracamente acopladas que trabalham em parceria para atingir um objetivo em comum. Um Cluster de Servidores consiste de um conjunto de computadores e aplicativos de servio que trabalham de modo coordenado, tendo como objetivo atingir um alto desempenho ou uma alta disponibilidade na execuo dos seus servios, ou mesmo ambos. Clusters de servidores de alta disponibilidade, ou simplesmente Clusters de Alta Disponibilidade, o assunto deste trabalho. Os conceitos e tcnicas relativos a Clusters de Alta Disponibilidade tem suas origens h alguns anos, havendo diversos produtos comerciais proprietrios disponveis no mercado. Porm, as empresas perceberam a importncia e o valor da disponibilidade de seus sistemas de informao e dos dados que eles armazenam apenas recentemente, e assim os clusters de alta disponibilidade surge como uma soluo para tal necessidade e vem tornandose essenciais para as empresas que desejam garantir a confiabilidade e a alta disponibilidade de seus sistemas. Para aqueles interessados na criao de clusters de alta disponibilidade utilizando como plataforma o sistema operacional Linux, existem diversos projetos de pequenos sistemas de cdigo aberto visando tal finalidade. No entanto, cada um deles foi desenvolvido de forma independente e com foco especfico sobre alguma rea do problema, o que deixa em todos algumas limitaes. Este fato foi a motivao bsica para a realizao deste trabalho, e em funo disso, ao invs de iniciar um novo projeto para a implementao de um sistema de

16 cluster de alta disponibilidade para Linux, foi escolhido estudar um dos sistemas de cdigo aberto j existente e largamente empregado, adicionando ao mesmo novos recursos a fim de melhorar suas caractersticas e prover maior funcionalidade.

1.1

DESCRIO DO OBJETIVO DA PESQUISA

Foram realizadas pesquisas por sistemas e ferramentas de software que permitam a criao de clusters de alta disponibilidade com o sistema operacional Linux e que sejam distribudas livremente e com cdigo aberto. No entanto, as que foram encontradas ou so limitadas ou possuem configuraes extensas e muito complexas. Nessa ltima categoria, podemos citar o sistema Linux Failsafe (FAILSAFE, 2004), o qual consiste em uma soluo completa porm ainda em fase experimental. As demais ferramentas apresentam-se muito limitadas, pois no atendem a todos os requisitos e no apresentam todas as funcionalidades para um sistema de alta disponibilidade em cluster, ou seja, resolvem parcialmente os problemas atuais. Sendo assim, tomamos por objetivo de trabalho o desenvolvimento e ampliao de uma dessas ferramentas tendo como meta a sua melhoria a fim de que esta possa melhor atender os requisitos e necessidades de um ambiente de alta disponibilidade. Foi decidido pela realizao de um projeto de implementao de um sistema de cluster de alta disponibilidade a partir de aprimoramentos em um sistema de software de monitoramento de clusters pr-existente e largamente empregado. Aps anlises, foi selecionado para tal finalidade um software de cluster de alta disponibilidade denominado Heartbeat. Ao estud-lo e entender as funcionalidades do referido sistema, percebeu-se que o mesmo um monitor de estado operacional dos ns do cluster, o qual permite

17 a tomada de aes em caso de falha em um deles. Porm, no existe uma gerncia de servios de cluster, ficando a cargo de scripts elaborados pelo administrador do cluster a tomada de decises a referente a tomada e execuo de servios em cada n, o que vem a ser uma soluo bastante restrita e sujeita a problemas e conflitos. Foi escolhido ento realizar o desenvolvimento de um sub-sistema integrado ao Heartbeat para monitoramento e gerenciamento dos servios do cluster, operando em conjunto com o mesmo atravs de chamadas sua API . Este subsistema consiste de um monitor de servios distribudo e coordenado, o qual monitora o estado operacional de cada servio e implementa um protocolo de coordenao, migrao e tomada de servios no cluster. Por ser integrado ao heartbeat, ele pode tomar decises sobre os servios baseado tambm na ocorrncia de falhas nos ns do cluster.

1.2

RELEVNCIA DA PESQUISA

Devido informatizao das empresas atravs do uso das tecnologias e dos sistemas de informao, com a evoluo da Internet, do comercio eletrnico e da necessidade constante de informaes on-line, a confiabilidade e disponibilidade de sistemas, dados e informaes so grandes diferenciais oferecidos pelas empresas. De certa maneira, a disponibilidade dos sistemas de informao empresariais torna-se cada vez mais crtica, tanto do ponto de vista do sucesso da mesma em alcanar seus objetivos quanto de sua prpria sobrevivncia. Mas infelizmente sistemas computacionais falham e podem torn-se inoperantes e indisponveis. Um bom projeto de informatizao deve prever a possibilidade de ocorrncia de tais falhas e, portanto, planejar uma forma de contorn-las, caso ocorram. a onde se deve aplicar a alta disponibilidade, a qual consiste em mtodos e tcnicas com o objetivo

18 aumentar a disponibilidade de um servio. A alta disponibilidade pode ser conseguida tanto atravs da aplicao de componentes de hardware quanto de software. No entanto, devido ao alto custo de solues por hardware, tem sido realizadas diversas pesquisas com o objetivo de se conseguir alta disponibilidade por software, com a aplicao em clusters de alta disponibilidade. A utilizao do sistema operacional Linux tem crescido muito nos ltimos anos. No entanto, ainda no existe uma ferramenta satisfatria e que seja distribuda livremente para prover alta disponibilidade para o mesmo. O sistema Heartbeat implementa um servio com o intuito de fornecer alta disponibilidade um cluster de mquinas rodando o sistema Linux, sendo sua funo monitorar o estado operacional dos ns (servidores). No entanto, ele no monitora individualmente cada servio em execuo no cluster, o que uma falha em um ambiente de produo pois pode acontecer de apenas determinado servio parar de funcionar, e no todo o n, deixando o servio indisponvel. Com o intuito de suprir essa deficincia do Heartbeat desenvolvemos neste trabalho um sistema para monitorao e gerenciamento de servios do cluster, com a finalidade de aumentar o seu grau de disponibilidade.

1.3

ORGANIZAO DO TRABALHO

No captulo 2 sero apresentados os conceitos relacionados a sistemas distribudos, clusters, alta disponibilidade e tolerncia falhas, conceitos fundamentais para o entendimento desse trabalho. No captulo 3 ser apresentado o modelo proposto de desenvolvimento do sis-

19 tema de monitorao de recursos em um cluster de alta disponibilidade. No ltimo captulo ser apresentado um captulo com os resultados a respeito do subsistema implementado e do funcionamento do sistema como um todo.

20

REFERNCIAS TERICAS

Neste capitulo ser apresentado toda teoria utilizada para a elaborao deste trabalho, com enfoque especial em clusters de alta disponibilidade.

2.1

SISTEMAS DISTRIBUDOS

Segundo Pereira Filho (2004), embora existam muitas definies de Sistemas Distribudos, as aplicaes tpicas esto nos servios de Arquivos e Distribuio de Carga de Processamento entre vrios computadores, o que tem aberto campo para uma sub-classe: os Clusters. Os conceitos de Clusters surgiram a alguma dcadas, mas somente agora esta se tornado foco de ateno e pesquisas, com a grande demanda por processamento e disponibilidade. O tema principal desse projeto voltado a Clusters de Alta Disponibilidade, no entanto, antes de abordarmos diretamente esse tema, daremos uma introduo a Sistemas Distribudos. Segundo Kirner (1988), os termos Sistemas Distribudos, Processamento Distribudo, Computao Distribuda e Processamento de Dados Distribudo tm sido definidos por muitas pessoas de forma diversificada. comum denominar-se Sistemas Distribudos como aqueles que possuem terminais inteligentes ou processadores de entrada e sada ou pro-

21 cessados front-end ou processados de uso geral interligados atravs de uma rede. No entanto, Kirner (1988) afirma que a principal caracterstica que distingue os sistemas de processamento distribudo dos sistemas de arquiteturas clssicas est na descentralizao do controle. A importncia dos Sistemas Distribudos tem aumentado nos ltimos anos, sob a influncia de vrios fatores, dentre eles a evoluo das tecnologias de hardware e software, que causaram a baixa de preos, o aumento da flexibilidade em sua utilizao e a introduo do seu uso em setores cada vez mais abrangentes da sociedade. Segundo Pitanga (2003), a evoluo dessas tecnologias e a utilizao de mecanismos de cooperao entre processos vm propiciando a multiplicidade de recursos computacionais a custos acessveis, os quais tm sido utilizados para aumentar a eficincia, confiabilidade e disponibilidade de sistemas. De modo geral, as principais caractersticas de Sistemas Distribudos so: mltiplos computadores e/ou recursos agrupados, para aumento de de-

sempenho, tolerncia falhas e/ou disponibilidade do sistema; os componentes de hardware das maquinas que compe o sistema so

fracamente agrupados, sendo a comunicao realizada atravs de uma rede de comunicao entre os componentes do sistema distribudo; possibilidade de expanso para crescimento incremental; os componentes de software que compe o sistema so fortemente a-

grupados, ou seja, so transparentes aos usurios: aparenta ser um sistema centralizado, mas na realidade o Sistema Operacional executa em processadores mltiplos e independentes; mecanismos de deteco de erros e redundncia para obter disponibili-

dade e tolerncia falhas;

22 Exibimos na Figura 1 o esquema de um sistema distribudo, de acordo com as caractersticas acima listadas.

Figura 1 - Exemplo de um Sistema Distribudo Fonte: PEREIRA FILHO, 2004, p. 38.

2.1.1

Sistemas de arquivos distribudos

Os sistemas de arquivos distribudos (SAD) tm sido umas das reas mais ativas em pesquisas nas ultimas duas dcadas. Agora que os clusters esto se tornando mais comuns, a necessidade de sistemas de arquivos que se utilizam desses recursos vem crescendo, assim como o estudo para aumentar a velocidade desses sistemas, j que a velocidade do trfego de dados pelos meios de comunicao no costumam acompanhar o aumento da velocidade dos processadores e memrias. No existe um sistema de arquivos distribudo completo que se adapte a qual-

23 quer tipo de aplicao. Por isso, para decidir qual utilizar, a melhor soluo escolher entre os candidatos quais se adaptam resoluo do problema, alm das vantagens e desvantagens dentre as plataformas existentes. Em geral existem sistemas de arquivos distribudos para todos os tipos de aplicaes e problemas que se deseje resolver. Alguns so mais tradicionais, por isso ganham mais respeito e so mais largamente utilizados, outros mais inovadores e criados para resolver problemas especficos, o que os tornam menos populares, porm no deixam de ganhar crdito. Alm disso, necessrio tambm analisar o custo de cada soluo ao adot-las, pois algumas delas necessitam de hardware especial.A principal meta de um sistema de arquivos distribudos permitir o compartilhamento de informaes aos usurios de uma rede por meio de um sistema de arquivos comum. Eles so desenvolvidos em nvel de usurio, preocupando-se com caractersticas como tolerncia a falhas, transparncia e escalabilidade, fatores esses primordiais para se trabalhar em um ambiente de clusters de computadores. Ele deve fornecer um servio de armazenamento de arquivos em uma memria secundria e tratar da alocao e administrao desse espao dinamicamente, devendo tambm se preocupar com operaes sobre arquivos de forma individualizada, implementando funes de mecanismo de cache, controles de acesso, mecanismos de replicao, semntica de compartilhamento, controles de concorrncia, um servio de diretrio e um mtodo de mapeamento entre nome de arquivos para referncias de arquivos.

2.1.1.1 Princpios dos sistemas de arquivos distribudos

Um sistema de arquivo distribudo dever prover algumas caractersticas fun-

24 damentais em sua implementao:

Transparncia quanto localizao: os usurios podem ter acesso aos

seus arquivos por meio de diferentes computadores. O usurio pode simplesmente se autenticar (logar) em qualquer mquina e ter a mesma viso do sistema de arquivos no precisando estar preocupados se seus arquivos so locais ou esto localizados em um servidor remoto, podendo usar o mesmo conjunto de operaes independente da localizao. Um dos principais benefcios de uma transparncia localizao permitir a implementao de mtodos para balanceamento de carga entre servidores de arquivos, onde servidores sobrecarregados podem migrar tarefas para outros menos congestionados sem que o usurio sequer tenha a noo que isto esteja acontecendo;

Replicao: este conceito a capacidade de disponibilizar diversas c-

pias (rplicas) de pedaos de seu sistema de arquivos e, se por algum motivo o mesmo tornar-se indisponvel, ento de forma instantnea e transparente rplicas ficaro disponveis aos usurios sem interromper suas tarefas. A operao de desconexo o termo usado para descrever a capacidade de acessar um ou mais arquivos quando desconectado do servidor. Cpias locais dos diretrios e arquivos so automaticamente ressincronizados com as cpias no servidor quando houver uma reconexo ao sistema. Esta caracterstica muito usada por usurios mveis que utilizam notebooks e laptops. Portanto um sistema de arquivos distribudos escalvel e tolerante a falhas deve disponibilizar vrios servidores independentes;

25 Autenticao orientada rede: no conceito de transparncia quanto

localizao, podemos observar que um usurio pode se registrar em qualquer mquina e obter a mesma viso do sistema de arquivos, portanto mecanismos de autenticao em rede tornam-se imprescindveis. Solues como NIS, NIS+ e Kerberos permitem uma melhor proteo como recursos de autenticao orientados rede.

Um fator muito importante em projetos de sistemas de arquivos distribudos que todas as estaes tenham a mesma viso do sistema de arquivos. O NFS utiliza o recurso de ter vrios servidores de arquivos espalhados pela rede, onde cada cliente monta sua estrutura, de acordo com a sua necessidade, atravs de operaes de montagem remota, o que dificulta uma viso localizada do sistema, apesar de serem mais fceis de se implementar. A melhor soluo seria adotar mecanismos para se ter a mesma viso do sistema a todos os usurios e processos, coordenando o espao de nomes para arquivos em ambientes distribudos. Claro que isto tem um preo, pois um grande esforo de programao requerido, mas em compensao, evita a possibilidade de existirem inconsistncias nos arquivos.

2.1.1.2 Exemplos de sistemas de arquivos distribudos

Segundo Pitanga (2003), os Sistemas de Arquivos Distribudos mais conhecidos atualmente so:

26 2.1.1.2.1 AFS (Andrew File System)

Projeto iniciado na Universidade de Carnegie Mellon no ano de 1983, financiado pela IBM, sua principal meta era desenvolver e implementar um SAD para o meio acadmico para compartilhar a rvore de diretrios entre diversos clientes espelhados pelo campus. Como sempre, o maior desafio em projetos de sistemas de arquivos distribudos se d no tpico segurana. Com tantos usurios e clientes era meio problemtico criar uma relao de confiana entre seus utilizadores. A incluso de um protocolo para autenticao (Kerberos), permitiu resolver esse problema de autenticidade entre clientes e servidores. Quando um arquivo do AFS aberto, todo o arquivo levado para o cliente, passando grande parte do trabalho dos servidores de arquivos aos seus clientes, aumentando assim a escalabilidade do sistema. Todas as operaes de leitura e escrita so realizadas na cpia local do arquivo. Somente quando o arquivo fechado, desde que ele tenha sido modificado, que retorna para o servidor. Uma conseqncia desta tcnica que o AFS utiliza uma semntica de sesso, ou seja, um cliente s poder perceber a alterao de um arquivo feita por um outro cliente quando aquele abrir o arquivo depois que este j o tiver fechado. O AFS suporta um esquema de replicao simples, que pode ser usado para realizar um backup automtico dos arquivos dos usurios e para replicao de diretrios read-only (somente leitura). O AFS-2 trouxe o conceito de callback, que permite ao cliente abrir e fechar um arquivo vrias vezes sem precisar acessar o servidor. Quando um cliente receber um arquivo do servidor, ele tambm recebe um callback, que uma promessa de que ele est com a verso mais recente do arquivo. Um callback pode ser quebrado quando um cliente atualiza um arquivo ou quando o servidor recebe uma nova verso do arquivo de um outro cliente. A cpia local pode ser utilizada quantas vezes se quiser, contanto que o cliente possua um callback vlido.

27 2.1.1.2.2 PVFS (Parallel Virtual File System)

Como j comentado no inicio destes capitulo, os clusters esto se tornando cada vez mais populares para aplicaes paralelas e, com isso, a demanda por software para esse tipo de plataforma tem crescido tambm. Na atualidade podemos encontrar todo tipo de software para o ambiente de computao paralela, como sistemas operacionais confiveis, compiladores, depuradores, sistemas de armazenamento de dados local e sistemas de envio de mensagens. Porm, existe uma rea que no esta to avanada, que a de sistemas de I/O paralelo. O Sistema de Arquivos Virtual Paralelo (PVFS Parallel Virtual File System) um sistema de arquivos paralelo, que permite que aplicaes, tanto seriais quanto paralelas, as utilizem para armazenamento e recuperao de arquivos, que esto distribudos por diversos servidores. Isso se deve crescente evoluo do desempenho de dispositivos de armazenamento de dados e processadores, sendo o gargalo os dispositivos que necessitam manipular grandes quantidades de dados pelas aplicaes cada vez mais avanadas, e que necessitam de mais velocidade e transparncia em um sistema de arquivos. Em geral, o PVFS promete quatro caractersticas:

Um espao de nomes consistente para todo o cluster; Acesso transparente para programas e aplicaes j existentes, sem ter

que recompil-los; Distribuio fsica de dados em mltiplos discos e ns; Alta performance de acesso em modo usurio.

28 Para que o sistema de arquivos paralelos possa ser usado facilmente, ele deve prover um espao de nomes nico em todo o cluster e deve ser possvel acess-lo atravs dos utilitrios mais comuns. Para prover alta performance de acesso para os clientes do cluster, os dados armazenados no PVFS so distribudos entre vrios ns que compem o cluster, usando algoritmos de distribuio diferentes. Cada um desses ns chamado de I/O node. Separando os dados em vrios ns, as aplicaes passam a ter muitos caminhos para encontr-los, atravs da rede e atravs dos discos em que esto armazenados. Isso elimina o gargalo de I/O e aumenta o potencial total da banda para mltiplos clientes. Usar mecanismos tradicionais de chamadas ao sistema para acesso a arquivos pode ser bem conveniente, mas pode causar um overhead muito grande para o kernel. Assim, possvel acessar os arquivos do PVFS usando uma API prpria. Existem bibliotecas com as operaes UNIX mais usadas, que contactam diretamente os servidores PVFS, evitando ter que acessar o kernel local. Essas bibliotecas, como a ROMIO MPI-IO, podem ser usadas pelas aplicaes ou por outras bibliotecas para acesso de alta velocidade ao PVFS. O servidor de meta-dados (metadata server) um daemon que gerencia todos os dados que constituem as informaes, mas no o contedo dos arquivos, como seu nome, sua localizao na hierarquia de diretrios, seu domnio, seus atributos, e como seus dados esto distribudos entre os vrios ns de dados do sistema. Esse daemon realiza todas as operaes sobre os meta-dados dos arquivos atomicamente, evitando assim ter que implementar esquemas complexos de concorrncia, locks, consistncia, etc., para mltiplos acessos simultneos. O servidor de dados (I/O server) gerencia o armazenamento do contedo dos arquivos, bem como a recuperao dos mesmos nos discos locais conectados nos ns. Esse servidor grava os dados dos arquivos do PVFS num sistema de arquivos local, usando as funes tradicionais, como read, write e mmap, para acess-los. Isso significa que pode-se utili-

29 zar qualquer tipo de sistema de arquivos local, como ext2, ext3 ou reiser. Adicionalmente possvel usar suporte a RAID para que cada n possua tolerncia a falhas de disco de forma transparente e confivel para todo o sistema. A API nativa do PVFS possibilita acesso em modo usurio aos servidores do PVFS. Esta biblioteca, denominada libpvfs, cuida das operaes necessrias para mover dados entre os clientes e servidores, mantendo-os totalmente transparentes para o usurio. Para operaes que necessitam de meta-dados a biblioteca se comunica diretamente com o servidor de meta-dados. Para acesso aos dados dos arquivos, o servidor de meta-dados deixado de lado e os servidores de dados so acessados diretamente. Essa a chave de prover uma escalvel performance agregada. O suporte no kernel do Linux para o PVFS prov as funcionalidades necessrias para se poder usar o comando mount nos clientes. Isso permite acesso aos arquivos do PVFS sem necessidade de alterao das aplicaes ou programas j existentes. Esse suporte no necessrio para se usar o PVFS, mas ele traz uma enorme convenincia para a interatividade com o sistema. Para isso, necessrio instalar um mdulo no kernel do Linux (existe um patch para eliminar o mdulo e carreg-lo diretamente no kernel), e um daemon (pvfsd) que se encarrega de buscar os dados para as aplicaes. Ele utiliza a biblioteca libpvfs para realizar essas operaes. Alm disso, existe a implementao da interface ROMIO MPI-IO para o PVFS, possibilitando que aplicaes paralelas utilizem o PVFS sem precisar passar pelo kernel, alm de poderem usar outras funes mais especficas desse SAD que possibilitam um ajuste mais fino no armazenamento dos arquivos. Existem alguns problemas relacionados segurana no acesso aos dados, j que se o cliente souber onde os dados esto, basta requisit-los para os ns de dados que eles respondero sem se preocupar com nenhum tipo de validao para permisso de acesso.

30 Quem cuida da permisso o servidor de meta-dados, e mesmo assim no muito sofisticada. Outro problema existente se o servidor de meta-dados cair. Somente os arquivos j abertos continuaro podendo ser acessados, at serem fechados. Todos os outros arquivos do sistema no podero ser acessados. Alm disso, o servidor de meta-dados pode representar um gargalo no sistema, j que ele nico. Em comparao com o NFS, o PVFS ganhou em acesso a arquivos grandes e ficou pouco atrs no acesso a arquivos pequenos (talvez porque o PVFS costuma dividir os arquivos em vrias partes entre os ns de dados, independentemente do tamanho deles). O projeto do PVFS1 foi totalmente redesenhado para uma nova verso de um sistema de arquivos paralelo, o PVFS2. Algumas de suas caractersticas so:

Servidores de meta-dados distribudos; Suporte modular para mltiplos protocolos de rede (inicialmente

TCP/IP e GM); Suporte modular para diversos dispositivos de armazenamento e mto-

dos de acesso; Mecanismos de distribuio de dados modulares; Servidores Multi-threaded; Escalonamento atualizado; Operaes em estilo banco de dados integrados no sistema de arquivos; Operaes mais flexveis em I/O como o MPI-IO; Semnticas de consistncia mais afinadas.

por isso e muito mais que a equipe da Universidade de Clemson vem tornando esse sistema de arquivos parte integrante e oficial dos sistemas em clusters de alta perfor-

31 mance espalhados pelo mundo.

2.1.1.2.3 GFS (Global File System)

O GFS um sistema de arquivos desenvolvido pela Sistina Software Inc., que pode ser acessado usando-se comandos e utilitrios comuns do UNIX. A idia principal compartilhar fisicamente o sistema de armazenamento de dados. O GFS v o seu sistema de armazenamento como um Network Storage Pool (NSP), que uma coleo de dispositivos de armazenamento ligados em rede e logicamente agrupados para prover aos clientes um espao de armazenamento unificado. Esses dispositivos de armazenamento no so controlados e nem pertencem a nenhuma das mquinas da rede, mas so compartilhados com todos os clientes e dispositivos. O objetivo do GFS prover velocidade de banda e altssima capacidade de armazenamento para aplicaes multimdia, cientfica e visualizao. A integrao dos chips com o sistema de arquivos transformou os dispositivos de armazenamento em unidades sofisticadas, o suficiente para serem capazes de distribuir todas as responsabilidades de manipulao de arquivos entre os clientes e os servidores, quando antes era tudo centralizado no servidor. Esses dispositivos de armazenamento so altamente capacitados para gerenciar arquivos muito grandes. Para isso, seus cachs foram criados para guardar megabytes de dados, enquanto o cach dos clientes s guarda os arquivos durante o processamento dos dados. Depois de processados os dados pelos clientes, o arquivo ento devolvido ao dispositivo de armazenamento pelo GFS, que informa quais dados so bons para deixar no seu

32 cache (como meta-dados, que so freqentemente acessados). Para manter a consistncia dos dados, o GFS usa um esquema de lock controlado pelo dispositivo de armazenamento, que implementa o conjunto de operaes readmodify-write como sendo atmico. O GFS tambm pode atuar como um servidor NFS, o que facilita a integrao dele com sistemas UNIX em geral, alm de torna-lo compatvel com vrias ferramentas j existentes no mercado.

2.1.1.2.4 Coda (Constant Data Availability)

Este sistema de arquivos distribudo desenvolvido em 1987 pela Carnagie Melon University baseado no Andrew File System 2, possui vrias caractersticas que so desejveis para sistemas de arquivos em rede. Destacam-se os seguintes tpicos no encontrados no AFS2:

Operao de desconexo para computao mvel; Totalmente livre sobre licena prpria; Alta performance atravs de persistncia de cach do lado cliente; Replicao de servidor; Um modelo de segurana baseado em autenticao, encriptao e con-

trole de acesso; vidor; Operao contnua durante falhas parciais na rede por meio de um ser-

33 Adaptao largura de banda da rede; Boa escalabilidade; Semntica muito bem definida para compartilhamento, mesmo na pre-

sena de falhas na rede.

2.1.1.2.5 Network File System

O sistema NFS (Network File System

Sistema de Arquivo em Rede) foi

proposto pela SUN Microsystems Inc. A verso 2 da especificao do protocolo NFS est descrita na RFC 1094 de maro de 1989, e a verso de nmero 3 foi lanada em junho de 1993. Segundo Tanenbaum (2002), ele permite uma estao de trabalho realizar acesso transparente a um arquivo remoto atravs da rede. Uma estao cliente pode operar sobre arquivos que residem em uma variedade de servidores, arquiteturas e sistemas operacionais. O NFS fortemente baseado no conceito de sistema de arquivos do sistema operacional UNIX, assumindo portanto, um sistema de nomes hierrquicos. O objetivo principal do sistema NFS permitir que um conjunto de estaes de trabalho compartilhem um sistema de arquivos de forma comum e transparente. Cada servidor NFS exporta um ou mais arquivos do seu sistema de arquivos para permitir o acesso dos clientes. Os clientes acessam os arquivos que esto em servidores NFS atravs da chamada ao sistema mount, que requisita um handle de arquivo para o prprio sistema de arquivos. Uma vez que o sistema de arquivos foi montado pelo cliente, o servidor emite um handle de arquivo para cada arquivo (ou diretrio), que o cliente acessa ou cria. Se

34 o arquivo de algum modo removido no servidor, o handle de arquivo torna-se expirado (stale). O NFS faz uso de trs protocolos cliente-servidor:

Protocolo de Montagem (MOUNT); Protocolo de Acesso (NFS); Protocolo do Gerenciador de Lock (NLM).

O protocolo de Montagem (Mount) foi projetado utilizando-se o paradigma de Chamada de Procedimento Remoto (RPC). O comando mount do Unix/Linux pode ser utilizado para comunicao com o servidor de Mount. Um cliente NFS envia um nome de diretrio para o servidor mount e requisita permisso para montar aquele diretrio em sua hierarquia de diretrios local. Como desvantagens do protocolo MOUNT podemos dizer que:

Sistemas de arquivos montados no sobrevivem a quedas (crashs) de

clientes, pois o cliente NFS que constri a hierarquia de arquivos local; nas. No h uma uniformizao de espao de nomes entre diferentes maqui-

O protocolo de Acesso (NFS) tambm projetado utilizando-se RPC, assim como o protocolo MOUNT. O NFS procura alcanar toda a semntica do sistema das operaes usuais em arquivos e diretrios. O servidor NFS desprovido de estado (stateless), ou seja, o sistema NFS no armazena as informaes acerca do estado de uma operao no cliente, toda a informao que

35 o servidor precisa esta contida no handle de arquivo. Por exemplo, se um cliente envia uma mensagem requisitando ao servidor a leitura de um arquivo, tal mensagem deve conter o handle desse arquivo a ser lido, o deslocamento dentro do arquivo e o numero de bytes desejado. O fato de o servidor NFS ser desprovido de estado traz como conseqncias algumas vantagens, tais como: O servidor no tem que lembrar nada acerca de conexes abertas entre mensagens consecutivas enviadas a ele. Se um servidor derrubado (crash), nenhuma informao sobre arquivos abertos perdida, simplesmente porque ele no mantm nenhuma. Um servidor desprovido de estado pode escalonar muito mais clientes, posto que ele no precisa manter informaes sobre conexes correntemente abertas. Em virtude de o protocolo NFS ser desprovido de estado, um protocolo adicional se faz necessrio para suportar a operao de locking no sistema NFS. Tal protocolo o chamado NLM (Network Lock Manager Protocol). O NLM suporta operaes de lock em arquivos remotos montados com o protocolo NFS. O gerenciador de lock isola uma operao inerentemente provida de estado (statefull) em um protocolo separado. Cada servidor NFS um programa que exporta uma interface RPC (conjunto de rotinas). A interface do servidor NFS formada por vinte e dois procedimentos que procuram alcanar o mximo a semntica das operaes em arquivos. A SUN implementa o conceito de read-ahead, que nada mais do que a leitura de blocos de discos adjacentes ao previamente requisitado. Isso aumenta o desempenho nas operaes de entrada/sada. O servidor mantm um cach de arquivos mais recentemente utilizados. Um fato importante que o reboot de um servidor (e a conseqente perda de sua memria cache) no influi nas operaes dos clientes. Embora a implementao dos cdigos do servidor e do cliente seja independen-

36 te do protocolo, interessante fazer aqui um estudo de caso, levando em conta a implementao no sistema SUN. A implementao no sistema SUN baseia-se em trs camadas de software:

Camada de Chamadas ao Sistema Operacional; Camada de Sistema de Arquivos Virtual (VFS); Camada de Acesso a Arquivos.

A Camada de Chamadas ao Sistema Operacional (System Calls) manipula chamadas como open, read e close. A tarefa da Camada VFS manter uma tabela com uma entrada para cada arquivo aberto, analogamente tabela de i-nodes para arquivos abertos no UNIX. Cada entrada nessa tabela uma estrutura denominada v-node, que indica se um arquivo local ou remoto. Todo arquivo aberto tem um v-node associado que aponta ou para um r-node ou para um inode. A Camada de Acesso a Arquivos representada ou pelo sistema operacional ou pelo cliente NFS, dependendo se o arquivo referenciado local ou remoto. Para transparecer melhor este conceito do processo de comunicao entre essas trs camadas, vamos tentar explicar o que acontece quando uma seqncia de chamadas s funes mount, open e read acontece. Para montar um sistema de arquivos remoto, o administrador executa o programa mount, especificando o diretrio remoto, o diretrio local sobre o qual deve ocorrer a montagem e outras informaes. O programa mount analisa o nome do diretrio remoto a ser montado e descobre o nome da mquina que exporta tal diretrio. Ele ento contacta aquela mquina remota e requisita um handle de arquivo para o diretrio remoto. Se o diretrio exis-

37 te e est disponvel para montagem remota, o servidor NFS retorna um handle de arquivo para o diretrio. Finalmente, ele invoca a system call MOUNT passando o handle de arquivo para o ncleo do sistema operacional. O ncleo ento constri um v-node para o diretrio remoto e requisita ao cliente NFS a criao de um r-node (remote i-node) em suas tabelas internas para armazenar o handle de arquivo. Cada v-node na camada VFS ir finalmente conter ou um ponteiro para um r-node no cdigo do cliente NFS ou um ponteiro para um i-node. Sendo assim, a partir de um v-node, possvel saber se um arquivo ou diretrio local ou remoto, e se ele remoto, encontrar o seu handle de arquivo. Quando um arquivo remoto aberto, em algum ponto durante a anlise do nome de caminho, o ncleo alcana o diretrio onde o sistema de arquivos remoto est montado. Ele v que esse diretrio remoto e atravs de seu v-node, encontra o ponteiro para o r-node. Ele ento pede ao cliente NFS para abrir o arquivo. O cliente NFS analisa (lookup) o restante do nome de caminho no servidor remoto associado com o diretrio remoto e retorna um handle de arquivo para tal diretrio. Ele cria um r-node para o arquivo remoto em suas tabelas e o reporta de volta camada VFS, que pe em suas tabelas um v-node que aponta para o r-node. A funo chamadora da camada de chamadas ao sistema recebe um descritor de arquivo para o arquivo remoto. Este descritor de arquivo mapeado para o v-node atravs de tabelas na camada VFS. Quando o descritor de arquivos usado em uma chamada de funo subseqente (read, por exemplo), a camada VFS localiza o v-node correspondente e, a partir deste, determina se o arquivo local ou remoto e tambm qual i-node ou r-node o descreve. O NFS verso quatro o mais novo sistema de arquivos distribudo bem similar s verses anteriores, com melhorias tais como: recuperao de erros simplificada e independncia dos protocolos da camada de transporte e dos sistemas operacionais para acesso a

38 arquivos em uma rede heterognea. Diferente das verses anteriores, o novo protocolo integra um sistema de lock de arquivos, segurana forte, operaes integradas e capacidade de delegao para aumentar desempenho de clientes que compartilham aplicaes com dados pequenos em redes com grande largura de banda. As funcionalidades de delegao e locking criam um NFS baseado em estado (stateful), mas simplifica o design de manter uma semntica de recuperao bem definida em face de falhas que possam ocorrer nos clientes, servidores ou na rede local.

2.2

CLUSTER

Para compreender bem o tema de alta disponibilidade, necessrio entender primeiro o que so e como funcionam os clusters. Segundo Pereira Filho (2004), apesar de no se depender totalmente de clusters para se montar um ambiente tolerante a falhas, recorrese freqentemente a eles devido a sua natureza distribuda, redundante e homognea. Cluster ou aglomerado uma coleo de computadores que trabalham visando prover um sistema de grande capacidade. Em outras palavras, cluster um conjunto de mquinas independentes, chamadas ns, que cooperam umas com as outras para atingir um objetivo comum. Os ns do cluster so transparentes aos usurios externos, ou seja, eles tm uma viso como se fosse um nico servidor. Em um ambiente de cluster qualquer mquina pode substituir qualquer outra mquina. Por serem maquinas distintas, interligadas apenas por meio de uma rede de comunicao, para atingir este objetivo eles devem possuir mecanismos muito bons de comunicao para coordenar e organizar aes a serem tomadas. Para prover tolerncia falhas os ns de-

39 vem compartilhar alguns recursos de hardware, tais como unidades de armazenamento, impressora, etc. A motivao pela explorao de clusters antiga, desenvolvida nos anos 60 pela IBM quando duas de suas mquinas, HASP (Houston Automatic Spooling Priority) e JES (Job Entry System), permitiram a interligao entre mainframes a um custo moderado. Entretanto, a computao baseada em clusters s comeou a ganhar espao e importncia a partir dos anos 80, motivada principalmente por trs fatores: a construo de processadores de alto desempenho, o surgimento de redes de comunicao de baixa latncia e a padronizao de ferramentas para computao paralela e distribuda. Portanto, a computao em clusters no uma rea nova, mas sim um aperfeioamento de pesquisas dentro da computao paralela e distribuda. Adicionalmente, a necessidade crescente de poder de processamento por parte das aplicaes e o custo elevado das arquiteturas paralelas dedicadas, que as tornavam inacessveis para a grande maioria das empresas e usurios, fomentou o desejo de se prover alto poder de processamento empregando-se hardware comum, ou seja, componente originalmente desenvolvidos para outros fins, mas que, se combinados, poderiam atingir o desempenho esperado para a execuo de aplicaes paralelas e distribudas. O desafio nesse momento era ento o emprego de componentes e sistemas de propsito geral (hardware e software de prateleira COTS Commodity Off The Shelf), tais como redes de estaes de trabalho, em contraste ao uso de arquiteturas especializadas, tais como Cray e SGI, de forma que se pudessem obter taxas de desempenho prximas das disponibilizadas pelos supercomputadores proprietrios, mas com um custo bem mais baixo. O emprego de hardware genrico de prateleira combinado com o uso de software de cdigo aberto foi uma das primeiras alternativas pensadas para a realizao desta meta. O nmero de recursos computacionais ou ns dentro do cluster poderia ser de-

40 finido sob demanda, diferentemente do que acontecia com mquinas paralelas dedicadas, e por causa desta filosofia que este ambiente vem crescendo, pelo simples fato de que se pode conseguir aquilo que o mercado empresarial mais gosta de ouvir: bom, bonito e barato. Aos poucos, as primeiras plataformas experimentais foram surgindo dentro de laboratrios e universidades. Eram plataformas pequenas, compostas por poucos ns. Nesse momento, o desafio passou a ser ento o software utilizado em tais arquiteturas. Se por um lado o software usado para programao paralela em supercomputadores no podia ser empregado, visto sua construo muito especfica, por outro lado, o software utilizado para programao distribuda em redes de computadores tambm no era adequado, visto sua implementao no otimizada que acarretava um baixssimo desempenho. Essa situao levou ao desenvolvimento de um nmero cada vez maior de pesquisadores advindos de universidades, laboratrios e da prpria indstria, resultando em avanos tecnolgicos tais como interfaces de rede programveis, rede de comunicao rpida, arquiteturas multiprocessadas e em propostas de software eficientes e modulares, capazes de extrair o mximo de desempenho possvel do hardware empregado. Ao longo dos anos 90 observou-se uma rpida multiplicao de arquiteturas baseadas em clusters e diferentes grupos de pesquisas desenvolveram suas arquiteturas, empregando componentes de hardware diferentes e desenvolvendo software bsico e aplicaes para elas. Diversas questes relativas computao paralela e distribuda comearam a serem investigadas nesse novo cenrio, tais como a obteno de altas taxas de desempenho, a reduo da latncia de comunicao entre os ns, aspectos de tolerncia falhas, confiabilidade, entre outros. medida que os clusters foram aumentando o seu nmero de ns, questes relativas ao gerenciamento da arquitetura e das aplicaes tornaram-se igualmente importantes, levando assim ao desenvolvimento de ferramentas para instalao, configurao e ge-

41 renciamento. A disponibilizao de diferentes tecnologias de comunicao, o envolvimento de um nmero cada vez maior de pesquisadores de diferentes lugares, o conhecimento adquirido e a soluo de alguns problemas pertinentes a esse tipo de arquitetura resultaram em plataformas de testes e ambientes de programao e gerenciamento extremamente confiveis e eficientes, capazes de prover todas as funcionalidades requeridas pelas aplicaes. De uma forma geral, a computao baseada em clusters j ocasionou o desenvolvimento de dezenas de ambientes de programao e gerenciamento, o teste de vrias tecnologias para interconexo de ns, o desenvolvimento e at mesmo a reimplementao de bibliotecas e aplicaes j desenvolvidas, a produo de inmeros artigos e o estabelecimento de grupos de trabalhos ao redor do mundo. O ponto desfavorvel que todo o conhecimento produzido est espalhado por vrias fontes e cresce rapidamente, o que dificulta, s vezes, um entendimento mais amplo ou atualizado desse cenrio.

2.2.1

Tipos de clusters

Um cluster pode possuir vrios tipos de configuraes diferentes, tanto na montagem do hardware quanto na configurao do sistema. Os tipos mais comuns de Cluster linux so:

Cluster de Alta Disponibilidade: Visa manter a disponibilidade dos ser-

vios prestados por um sistema computacional, atravs da redundncia de hardware e reconfigurao de software. Vrios computadores juntos agindo

42 como um s, cada um monitorando os outros e assumindo seus servios caso algum deles venha a falhar. A complexidade do sistema deve estar no software, que deve se preocupar em monitorar outras mquinas de uma 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;

Cluster de Balanceamento de Carga: De modo geral, a diviso das ta-

refas entre um grupo de servidores com funcionalidade similar, utilizando-se de maneira inteligente os recursos disponveis e permitindo o processamento de mais informaes em menos tempo. A ao pode ser baseada em fatores como carga de trabalho do servidor, quantidade de conexes ativas do servidor, sincronizao de dados ou necessidade de servios especficos;

Combinao de Alta Disponibilidade e Balanceamento de Carga: Co-

mo o prprio nome sugere, combina as caractersticas dos dois tipos de clusters, aumentando assim a disponibilidade e a escalabilidade de servios e recursos. Este tipo de configurao de cluster bastante utilizado em servidores de web, mail, news ou ftp;

Cluster de Processamento Paralelo ou Processamento Distribudo: Es-

se modelo de cluster aumenta a disponibilidade e a performance das aplicaes, particularmente as grandes tarefas computacionais. Uma grande tarefa computacional pode ser dividida em pequenas tarefas que so distribudas ao redor das estaes, como se parecesse um supercomputador massivamente paralelo.

43 Estes clusters so usados para computao cientfica ou anlise financeiras, tarefas tpicas para exigncia de alto poder de processamento.

2.2.2

Benefcios de um cluster

H quatro benefcios que podem ser obtidos com a organizao de clusters:

Escalabilidade absoluta: possvel criar clusters muito grandes, cuja

capacidade de computao ultrapassa vrias vezes a capacidade da maior mquina individual;

Escalabilidade incremental: um cluster configurado de maneira que

seja possvel adicionar novos sistemas, expandindo-o de forma incremental. Desse modo, um usurio pode comear com um sistema mais modesto e expandi-lo medida que crescem suas necessidades, sem precisar fazer a substituio completa do sistema menor por um maior;

Alta disponibilidade: como cada n um computador independente,

uma falha em um n no significa perda total de servio;

Melhor relao custo/desempenho: devido facilidade de construir o

sistema a partir de elementos ou ns bsicos comercialmente disponveis, possvel obter um cluster com poder de computao igual ou maior que uma

44 nica mquina de grande porte, com um custo menor.

2.2.3

Princpios de um cluster

Para ser til, um cluster precisa seguir alguns princpios bsicos:

1. Comodidade: Os ns em um cluster devem ser mquinas normais interconectadas por uma rede genrica. O sistema operacional deve ser padro, sendo que o software de gerenciamento deve estar acima dele como uma aplicao qualquer;

2. Escalabilidade: Adicionar aplicaes, ns, perifricos e interconexes de rede deve ser possvel sem interromper a disponibilidade dos servios dos clusters;

3. Transparncia: Apesar de ser constitudo por um grupo de ns fracamente agrupados, um cluster parece como um s sistema a clientes externos. Aplicaes clientes interagem com o cluster como se fosse um s servidor de alta performance ou de alta disponibilidade;

4. Confiabilidade: O cluster deve ter capacidade de detectar falhas internas ao grupo, assim como tomar atitudes para que estas falhas no parem os servios oferecidos;

5. Gerenciamento e Manuteno: Uma das principais dificuldades em se trabalhar com cluster seu gerenciamento. A configurao e a manuteno de clusters so muitas

45 vezes tarefas complexas e propensas a gerar erros. Um fcil mecanismo de gerenciamento do ambiente deve existir a fim de que o cluster no seja um grande sistema complexo com um rduo trabalho de administrao.

2.2.4

Elementos de um cluster

Um cluster possui vrios elementos que, juntos com sua arquitetura, fornecem a funcionalidade desejada. Uma abstrao dos elementos necessria para se poder compreender qual o comportamento de cada um deles.

2.2.4.1 N

Como visto anteriormente, cada maquina que faz parte do cluster denominado n, sendo ele a unidade bsica do cluster. Grupos de ns formam um cluster. Em um cluster, um n comunica-se com os outros atravs de mensagens sobre conexes de rede, e falhas em ns podem ser detectadas atravs de timeouts de comunicao.

46 2.2.4.2 Recurso

Representa uma funcionalidade oferecida a um n. Este recurso pode ser fsico como uma impressora ou lgico como um endereo IP. a unidade bsica de gerenciamento e podem migrar de um n para outro. O processo de migrao de um recurso de um n para outro chamado de failover. Estes recursos podem vir a falhar ento monitores devem sempre estar observando o status destes recursos a fim de tomar atitudes em caso de falhas. Ex. iniciar o servio em outro n. Cada tipo de recurso deve ter associado a si um mecanismo de inicializao e parada, para que possam ser corretamente manipulados pelo cluster.

2.2.4.3 Dependncia de recursos

quando um recurso depende da disponibilidade de outro recurso. Por exemplo, um servidor HTTP, FTP ou MAIL depende de interface de rede on-line e de um sistema operacional em funcionamento para prover seus servios. Estas dependncias so descritas por um grafo de dependncias de recursos, este grafo descreve a seqncia na qual os recursos devem ser inicializados. Ainda, durante uma migrao de recursos, ele descreve quais recursos devem ser migrados em conjunto. Uma representao grfica do grafo de dependncias do exemplo acima apresentada na Figura 2.

47

Figura 2 - Dependncia de recursos em um servidor HTTP Fonte: PEREIRA FILHO, 2004, p. 9.

2.2.4.4 Grupos de recursos

simplesmente a definio de quais recursos fazem parte de um determinado grupo, servindo para garantir que todo o grupo faa a migrao em conjunto. Devido natureza fracamente acoplada do cluster, necessrio que haja uma arquitetura que una todos os elementos e fornea o funcionamento que cada um espera do outro, sendo uma abstrao ideal uma arquitetura baseada em componentes.

48 2.2.5 Arquitetura de um cluster

Isoladamente, os elementos descritos acima no provem a funcionalidade desejada do cluster. necessrio que haja uma arquitetura que una todos os elementos e fornea o funcionamento que cada um espera do outro. Ou seja, necessrio uma arquitetura que defina como estes componentes conversam entre si, alm de definir uma srie de servios internos ao cluster necessrios para sua operao. Como cada cluster pode ter um objetivo diferente, sua arquitetura pode variar bastante. Entretanto, existem muitos componentes comuns, e que podem ser estudados para compreendermos uma arquitetura bsica. Atualmente no existe uma padronizao de arquiteturas para clusters, mas muitas propostas assemelham-se em vrios sentidos. Tal estrutura seria formada pelas seguintes camadas bsica, segundo Weber (2003).

ns;

Camada de Comunicao: Trata das comunicaes ponto a ponto entre

Camada de Ligao: Agrupa canais de comunicao em uma ligao

entre dois ns;

Camada de Integrao: Forma a topologia do cluster;

Camada de Recuperao: Executa a recuperao (failover) e a iniciali-

zao ou parada controlada dos servios depois de uma transio do cluster.

49 Existem ainda quatro servios chave para um cluster:

Servio de Informaes (JDB): Armazena estados persistentes internos

ao cluster. Nada mais do que um repositrio de informaes local a cada n do cluster;

Camada de Quorum: Determina qual participao do cluster possui au-

torizao para prosseguir com sua execuo;

cluster;

Servio de Barreiras: Prov um servio de sincronizao global ao

Servio de Nomes: Prov um servio de nomes global ao cluster.

2.2.5.1 Camada de comunicao

Esta a camada de comunicao de baixo nvel. Esta camada mantm mltiplas interfaces (podem ser IP, serial ou SCSI). A descoberta de vizinhana feita em cada interface, a qual totalmente independente uma da outra. Aps uma conexo ponto-a-ponto permanente ser estabelecida, vrios tipos de mensagens so permitidos: entrega seqencial de informaes, verificao de estado do link e reinicializao controlada. Cada canal pode ainda ter uma mtrica que determina sua qualidade para transportar o trfego do cluster.

50 2.2.5.2 Camada de ligao

Construda sobre a camada de comunicao, a camada de ligao estabelece um mecanismo de ligao de alto nvel, o qual associa todos os canais para um dado host em um nico link. Este um link virtual, pois a informao ainda trafega pelos meios de comunicao estabelecidos na camada de comunicao. Dadas as mtricas dos canais de comunicao, o link pode ter vrios estados, os quais determinam sua possibilidade de operao. A grande utilidade desta camada abstrair a comunicao de dados e suas particularidades entre dois ns, a fim de tornar a tarefa de trocar mensagens mais simples para as camadas superiores.

2.2.5.3 Camada de integrao

Esta camada realiza transies na topologia do cluster, aglomerando clusters vizinhos, despejando membros inativos ou com mau comportamento. Toda a vez que esta lista de membros do cluster alterada todos os ns membros devem tomar conhecimento desta modificao. Deste modo, esta camada realiza transies na formao do cluster, aglomerando clusters vizinhos, despejando membros inativos ou com mau comportamento, e garantindo transies transacionais entre as formaes do cluster.

51 2.2.5.4 Camada de recuperao

Esta a camada que integra o ncleo do cluster com os servios que ele fornece. A principal tarefa da camada de recuperao como o prprio nome diz recuperar-se de transies completadas pela camada de transio. A recuperao constituda de uma srie de operaes:

Recuperao interna de todos os servios permanentes registrados: Ba-

sicamente envolve a reconstruo do estado global (variveis globais e seus valores), baseado no conjunto de novos ns no cluster, e o estado dos servios nos novos ns. Por exemplo, um gerenciador de lock distribudo poderia recalcular a funo de hash usada para distribuir os diretrios de lock nos ns disponveis, e ento reconstruir seu banco de dados baseado no conjunto de locks mantidos em cada n;

Recuperao de servios do usurio: Estes servios no esto necessari-

amente rodando o tempo todo, e podem no possuir estados globais. Deve-se possibilitar que servios de usurios que desapareceram aps uma transio sejam reiniciados em outro n, sempre respeitando a ordem estabelecida no grafo de dependncias.

Esta camada deve ser capaz de desabilitar o acesso ao servio at que a recuperao esteja completa.

52 2.2.5.5 Servio de Informaes (JDB)

Um banco de dados transacional necessrio para armazenar estados locais. Em um cluster onde os ns podem votar para tomar certas decises, todo o n com um voto vlido deve possuir uma rea de armazenamento persistente, a fim de que possam ser executadas alteraes confiveis em suas informaes de estado e configurao.

2.2.5.6 Camada de quorum

Em qualquer momento um cluster pode ser particionado em um ou mais subclusters. Estes particionamentos podem ser gerados por vrios motivos, como falhas em ns ou canais de comunicao. Cada n possui uma viso da lista de membros deste sub-cluster, acreditando que esta a lista correta de membros do cluster. Em uma situao como esta o que no se deseja que mais de uma partio acredite ser o cluster ativo e comece a fornecer concorrentemente os mesmos servios. A camada de quorum responsvel por determinar que somente uma destas parties seja considerada o novo cluster, isto , que somente um sub-cluster possua quorum. Assim, as parties que no possurem quorum iro parar seu processamento assim que perceberem que a lista de membros no vlida. Freqentemente, tal deciso feita de duas maneiras:

Votao: atravs de uma eleio entre os membros do sub-cluster, po-

53 der-se concluir se este grupo possui ou no a maioria dos membros originais do cluster;

Recurso de Quorum: o grupo que possuir um certo recurso ser consi-

derado a partio ativa (isto , partio com quorum), independente de seu nmero de ns membros. Este mtodo til em situaes em que o necessrio para poder prosseguir com o processamento o acesso a uma rede ou a repositrio de dados externo, por exemplo.

2.2.5.7 Servio de barreiras

O servio de barreiras prov um mecanismo bsico de sincronizao para qualquer grupo de processos no cluster. Uma operao de barreira envolve todos os processos que se cooperam a esperar pela mesma barreira: somente quando todos eles tiverem atingido esta barreira que algum deles ter permisso para prosseguir. Desta maneira este servio o ncleo para sincronizar transies do cluster.

2.2.5.8 Servio de nomes

O espao de nome do cluster uma estrutura hierrquica no-persistente, na qual qualquer n pode registrar nomes. Atravs dela processos podem tanto registrar e consul-

54 tar nomes, como definir dependncias baseadas nestes nomes.

2.2.6

Cluster hierrquicos

Quando lidamos com clusters muitos grandes, certamente a freqncia de transies tende a aumentar. Digamos que estamos trabalhando com um cluster de 1000 ns. Nesta situao, no queremos que devido sada de um n do grupo, todo o cluster passe por um processo de transio que possa parar todo seu processamento. Desejamos restringir esta transio somente aqueles ns que se relacionavam diretamente com o n que acabou de sair. Esta a idia por trs de um cluster hierrquico, que um tipo de cluster mais complexo, que envolve os conceitos discutidos anteriormente. Um cluster plano uma entidade virtual nascida da colaborao entre ns em uma rede de comunicao. Podemos chamar este cluster de cluster de primeiro nvel; estes ns so seus membros, e juntos formam sua lista de membros. Em cada momento, um cluster possui um nico n privilegiado chamado de lder do cluster, que possui um papel de coordenador em suas transies. Quando desejamos combinar clusters em unidades maiores, necessrio tolerar a associao de clusters em um nico cluster de alto nvel, ou metacluster. Ele formado aglomerando-se os lderes dos clusters membros em um novo cluster; Estes lderes formam a lista de membros do metacluster. Assim, h dois tipos de transies:

Transies em um sub-cluster, que no alteram o lder do grupo. Este

tipo de transio no afeta a lista de membros do metacluster, e, portanto, no

55 causa mais nenhuma transio no cluster hierrquico;

Transies em um sub-cluster, que alteram o lder do grupo. Este tipo

de transio altera a lista de membros do metacluster, e, portanto, dispara uma transio no cluster hierrquico.

Assim, um cluster hierrquico nada mais do que um cluster de clusters. Esta associao entre clusters pode se estender por muitos outros nveis, criando clusters de segundo, terceiro, ou at mesmo dcimo nvel. A grande vantagem de se criar clusters hierrquicos o ganho expressivo de escalabilidade. Por exemplo, em uma grande rede de uma corporao, administrada como um cluster, no desejamos que mquinas de teste que param de funcionar causem transies; queremos restringir as transies s reas de um cluster onde elas faam sentido. Em um metacluster, transies dentro de um sub-cluster que no afetam seu lder no causam nenhuma modificao na formao do metacluster, implicando em uma melhor performance. O metacluster sofrer uma transio somente se algum de seus membros (que so os lideres dos subclusters) for modificado.

2.3

ALTA DISPONIBILIDADE

Segundo Pitanga (2003), os computadores possuem uma forte tendncia a parar quando voc menos espera, principalmente no momento em que voc mais necessita dele. raro no encontrar um administrador que nunca recebeu um telefonema no meio da madruga-

56 da com a triste notcia de que o sistema de misso critica ficou fora do ar, ocasionando assim um deslocamento ao local para providenciar o reparo e reativao do sistema. No so raras situaes em que discos, fontes de alimentao, interfaces de rede e outras partes do sistema comeam a apresentar falhas entre 30.000 e 80.000 horas de uso. Quando isso acontece e seu trabalho comea a ser penalizado, j hora de pensar em uma soluo que seja tolerante a falhas e que apresente uma boa relao custo/benefcio. A alta disponibilidade est ligada diretamente a nossa crescente dependncia aos computadores. Com o avano das atividades que contam com recursos computacionais, cada vez maior o transtorno causado pela eventual falha destes sistemas. Desde sistemas bancrios at supermercados, os computadores tm papel crtico, principalmente em empresas cuja maior funcionalidade exatamente a oferta de algum servio computacional, como ebusiness, notcias, sites web, etc. Para que se entenda a alta disponibilidade faz-se necessrio, antes de tudo, perceber que a alta disponibilidade 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. A simples utilizao dessas tcnicas, entretanto, no garantem este aumento se no for acompanhado de um completo estudo e projeto de configurao. A alta disponibilidade uma forma de manter os servios prestados por um sistema a outros elementos, mesmo que o sistema em si venha a se modificar internamente por causa de uma falha. A est implcito o conceito de mascaramento de falhas, atravs de redundncia de hardware ou reconfigurao de software. Um determinado servio que se quer altamente disponvel colocado por trs de uma camada de abstrao que permite mudanas em seus mecanismos internos mantendo intacta a interao com os elementos externos. Em um sistema de alta disponibilidade, vrios computadores trabalham juntos

57 agindo como um s, cada um monitorando os outros e assumindo seus servios caso perceba que algum deles falhou, sendo que perdas na performance ou na capacidade de processamento so normalmente aceitveis. Entre diversos pontos positivos, encontra-se a capacidade de conseguir sistemas de alta disponibilidade com computadores simples, como os que se pode comprar at em um supermercado. A complexidade esta apenas no software: mais fcil de desenvolver que o hardware, o software de alta disponibilidade quem se preocupa em monitorar outras mquinas de uma rede, saber que servios esto sendo prestados, quem os est prestando, e o que fazer quando uma falha percebida. Segundo Weber (2004), um sistema tolerante a falhas se ele pode mascarar a presena de falhas no sistema. Ainda, conforme Weber (2004) demonstra, no possvel tolerar falhas sem redundncias. Redundncia em um sistema pode ser hardware, software ou tempo. Redundncia de hardware compreende os componentes de hardware adicionados para tolerar falhas. Redundncia de software inclui todos os programas e instrues que so usadas na tolerncia falhas. Uma tcnica comum de tolerncia falhas executar certa instruo vrias vezes. Esta tcnica necessita redundncia de tempo, isto , tempo extra para executar tarefas para tolerar falhas. Devemos compreender que a redundncia de recursos um pr-requisito para se atingir um alto grau de disponibilidade, pois ela necessria para se eliminar os pontos nicos de falha (single point of failures- SPOF). importante lembrarmos que os SPOF no se restringem somente aos recursos do hardware das mquinas, existindo tambm nas:

Redes de Computadores (Switches, roteadores, hubs, cabeamento, etc)

que disponibilizam os servios ao mundo externo;

58 Redes Eltricas que alimentam as mquinas. Ainda, nada adianta utili-

zar mais de uma rede eltrica para alimentar as mquinas se elas saem na rua de um mesmo poste, cuja destruio poderia comprometer todos os servios;

Localizao de Recursos. Deve-se lembrar que desastres (terremotos,

furaces ataques terroristas, etc) podem inviabilizar toda a operao de uma companhia, se esta tiver suas informaes e sistemas operando em somente um lugar fsico.

Segundo Vigliazzi (2004), muitos projetos de alta disponibilidade no so bem elaborados, deixando sem contingncia os recursos quando ocorre alguma falha nos itens acima. Nada adianta ter todos os servidores crticos redundantes e preparados para contornar qualquer falha, se os itens acima no estiverem preparados. Assim, fica claro que quando dizemos sistema de alta disponibilidade, este deve englobar muito mais do que um simples sistema de redundncia de recursos. claro que isto depende do grau de disponibilidade que desejamos atingir, por exemplo, raramente se planeja um sistema visando uma disponibilidade no caso de ataques terroristas. Tambm fcil percebermos que quanto maior o grau de disponibilidade que desejamos garantir, maiores sero os gastos com esta soluo. A Figura 3 exibe um grfico que detalha o aumento de investimento necessrio para se atingir certos nveis comuns de disponibilidade.

59

Figura 3 - Custo da disponibilidade Fonte: PEREIRA FILHO, 2004, p. 17.

Estes nveis de disponibilidade so:

Sistemas Bsicos: Tais sistemas no utilizam medidas especiais para se

protegerem de falhas. Cpias de segurana das informaes existem, mas necessria interveno humana para corrigir o sistema; Informao Redundante: Algum nvel de redundncia da informao

utilizada, como redundncia de discos; Failover do Sistema: Um modelo onde existe um sistema em stand-by,

pronto para assumir caso o sistema principal falhe; Recuperao de Desastres: Alm dos sistemas no local principal, existe

um segundo conjunto de sistemas em um local secundrio.

60 2.3.1 Clculo da disponibilidade

Outro detalhe a ser abordado sobre a alta disponibilidade como medi-la. Em termos tcnicos, a disponibilidade de certo servio a probabilidade de encontr-lo operando normalmente em determinado momento. Portanto, tal probabilidade leva em conta qual o provvel uptime (tempo em que os servios estaro funcionando) e provvel downtime (tempo em que os servios ficaro fora do ar). Uma notao muito usual atualmente a que leva em conta o numero de noves de disponibilidade. Tal notao mais voltada a sistemas de alta disponibilidade de mercado, e no a estudos acadmicos. Nesta notao, dizer que uma soluo oferece 5 noves de disponibilidade significa dizer que seu uptime 99.999%. Na Tabela 1 ser apresentada medidas de disponibilidade, enquanto que no Quadro 1 ser apresentado exemplos de uso para essas disponibilidades.

Tabela 1 - Medindo a disponibilidade

Fonte: PEREIRA FILHO, 2004, p. 19.

61
Quadro 1 - Exemplos de sistemas e suas disponibilidades necessrias

Fonte: PEREIRA FILHO, 2004, p. 19.

Em um sistema real, se um componente falha ele reparado ou substitudo por um novo componente. Se este novo componente falha substitudo por outro e assim por diante. O componente reparado tido como no mesmo estado que um componente novo. 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 e o estado em reparo significa que ele falhou e ainda no foi substitudo por um novo componente. Em caso de defeitos, o sistema vai de funcionando para reparo e quando a substituio feita ele volta para o estado funcionando. Sendo assim, segundo (CONECTIVA) pode-se dizer que o sistema apresenta ao longo de sua vida um tempo mdio at apresentar falha (MTTF) e um tempo mdio de reparo (MTTR). 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 e seu tempo total de vida. Isto pode ser representado pela formula abaixo: Disponibilidade = MTTF / (MTTF + MTTR) Ao avaliar uma soluo de alta disponibilidade, importante levar em considerao se na medio do MTTF so observadas como falhas possveis paradas planejadas.

62 2.3.2 Dependabilidade

Segundo Weber (2004), a dependabilidade (dependability) de um sistema computacional representa sua habilidade de entregar um servio de maneira confivel. O servio entregue por um sistema seu comportamento, conforme percebido pelo(s) seu(s) usurio(s); um usurio um sistema fsico ou um ser humano que interage com o sistema atravs de uma interface. A funo de um sistema o que esperado que ele realize, conforme descrito em sua especificao. Em outras palavras, o termo dependabilidade mede a qualidade do servio fornecido por um dado sistema e a confiana depositada no servio fornecido.

2.3.3

Confiabilidade

A confiabilidade (reliability) a probabilidade de um sistema no falhar em um determinado perodo de tempo. Supe-se que o sistema est operando no instante inicial e que as condies ambientais do sistema permaneam as mesmas nesse perodo. Confiabilidade a medida mais usada em sistemas crticos, ou seja, nos seguintes tipos de sistemas:

Sistemas em que mesmo curtos perodos de operao incorreta so ina-

ceitveis; Sistemas em que reparos so impossveis.

63 Exemplos de sistemas confiveis so sistemas de aviao e de explorao espacial.

2.3.4

Segurana

Segurana a probabilidade do sistema estar em uma das seguintes condies:

Estar operacional e executar sua funo corretamente; Descontinuar suas funes de forma a no provocar danos a outros sis-

temas que dele dependam.

A segurana de um sistema representa sua capacidade de se comportar sem falhas (failsafe). Em um sistema failsafe, ou sada correta ou sistema levado a um estado seguro. Um exemplo de um sistema failsafe um sistema de transporte ferrovirio, onde os controles de um trem providenciam sua desacelerao e parada automtica quando no conseguirem garantir o seu funcionamento correto. A Tabela 2 ilustra os trs termos vistos acima. Nela, para cada situao descrita, identificamos quais propriedades so asseguradas. Uma interrogao indica que, baseado na descrio da situao, nada pode ser afirmado.

64
Tabela 2 - Exemplos de confiabilidade, disponibilidade e segurana

Fonte: WEBER, 2004, p. 11.

2.3.5

Classes de disponibilidade

Muitos termos distintos so encontrados na literatura para se referir alta disponibilidade. Apesar de diferentes, muitos possuem o mesmo significado, outros so usados para denotar diferentes aspectos da disponibilidade. Nesta seo apresentaremos tais termos, a fim de formarmos um vocabulrio padro da rea.

2.3.5.1 Disponibilidade bsica (Basic Availability)

Um sistema possui Disponibilidade Bsica se foi desenhado, implementado e implantado com um nmero suficiente de componentes (hardware, software e procedimentos)

65 para satisfazer sua funcionalidade, e nada alm disso. Tal sistema fornecer os servios corretamente, desde que falhas e operaes de manuteno no sejam executadas.

2.3.5.2 Alta disponibilidade (High Availability)

Um sistema possui alta disponibilidade se foi desenhado, implementado e implantado com um nmero suficiente de componentes (hardware, software, e procedimentos) para satisfazer sua funcionalidade, alm de possuir redundncia suficiente nos componentes para mascarar algumas falhas definidas. Esta uma definio ambgua, que permite classificarmos uma srie de configuraes como Alta Disponibilidade.

Mascarar uma falha significa impedir sua visualizao por um observador externo. A idia no impedir a ocorrncia de falhas, e sim a sua observao. Tal objetivo alcanado atravs de redundncia: quando um certo componente falha, deve existir outro igual para substitu-lo. O nvel de transparncia neste processo pode levar a grandes variaes de sistemas caracterizados como de Alta Disponibilidade:

Mascaramento Manual (Manual Masking MM): Aps uma falha, al-

guma interveno manual necessria para colocar o componente redundante em funcionamento. Enquanto isto no acontece, o sistema est indisponvel;

Cold Stand-By (CS): Aps uma falha, usurios do componente afetado

so desconectados e perdem todo trabalho em progresso (isto , ocorre um rol-

66 lback para o ltimo estado consistente de seu trabalho). Um failover automtico do servio ocorre. Porm, como o componente redundante estava desativado, este precisa ser inicializado para poder comear a operar. Um exemplo um cluster de duas mquinas, onde a stand-by permanece desligada; quando ocorre uma falha de algum recurso, ela ligada e inicializada para poder oferecer os servios;

Warn Stand-By (WS): Assim como no Cold Stand-By, os usurios so

desconectados e perdem o trabalho em andamento. Um failover automtico ocorre, s que desta vez o componente redundante j est inicializado e rodando. Ainda, o componente que apresentou falha permanece ligado, 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 takeover1 drasticamente reduzido;

Hot Stand-By (HS)/Replicao Ativa (RA): Os componentes redundan-

tes e ativos esto fortemente agrupados e (logicamente) indistinguveis aos usurios. O estado do processamento ativa 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 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.

Takeover o processo executado para o componente redundante assumir os recursos que apresentaram falhas.

67 Suficiente reflete a necessidade do sistema por alta disponibilidade. Por exemplo, em certo sistema poderia ser necessrio mascarar somente falhas de hardware e no de software, e isto seria o suficiente. Ainda, suficiente tambm reflete quantas vezes ser possvel mascarar a falha. Por exemplo, em um sistema onde cada componente possui n rplicas, possvel mascarar n falhas simultneas, isto , falhas que ocorrem durante o perodo de recuperao de um mesmo componente. Algumas, como usado acima, um atestado de que no possvel mascarar todas as falhas. Assim deve ser especificado o conjunto de falhas que sero compensadas por um sistema de alta disponibilidade.

2.3.5.3 Disponibilidade continua (Continuous Availability)

Disponibilidade Contnua estende a definio apresentada de Alta Disponibilidade: como apresentado at ento, sistemas de alta disponibilidade s mascaram falhas, isto , paradas no planejadas dos servios. Atravs de CA deseja-se tambm mascarar paradas planejadas dos servios. Ainda, este modelo de disponibilidade deve ser exclusivamente HS/RA, para qualquer tipo de parada dos servios.

2.3.6

Defeitos, erros e falhas

At agora, vimos que um sistema de alta disponibilidade mascara falhas para o

68 usurio final. Entretanto, o termo falha foi usado muito vagamente, e nesta seo faremos sua devida explicao. Para uma melhor compreenso das causas e conseqncias que anomalias no sistema podem causar, necessrio distinguir e identificar alguns termos utilizados para a definio de tolerncia falhas. Tais anomalias dentro do contexto de sistemas computacionais so:

Falha: um comportamento inesperado em uma situao aparentemente

normal. Ocorre no universo fsico;

Erro: manifestao visvel da falha, que pode ser percebida pelo usurio

ou desenvolvedor do sistema. Um erro aquela parte do estado do sistema que responsvel por induzir a uma falha subseqente. Com isso, novas falhas podem ser geradas. Um erro acontece no universo lgico;

Defeito: causado pelo erro, onde o sistema passa a oferecer resultados

ou respostas erradas e inesperadas. Ocorre quando h um desvio no comportamento das especificaes do sistema. , por fim, a manifestao perceptvel ao usurio de que uma falha ocorre.

Por exemplo, suponha que em um dado momento uma placa de rede retorne o valor 1 para um determinado bit em um pacote quando deveria retornar 0. Devido a uma falha no dispositivo de placa de rede, um erro ocorreu (valor 1 ao invs de 0), desse modo o resultado final apresentado ao usurio incorreto (o defeito). Felizmente os erros podem ser diagnosticados por serem propriedades do sis-

69 tema, diferentemente das falhas. Um defeito pode ser observado somente se o erro que o causou tambm est sendo observado. Em geral quando algo vai contra o que atribumos ser correto um defeito. Embora isso seja correto, nem sempre possvel observar um erro durante o perodo de observao, deixando-se a impresso que o sistema encontra-se em estado estvel. O inverso tambm verdadeiro, j que, aps a deteco de um erro, conclui-se que o sistema encontrase em estado de falha.

2.3.6.1 O modelo de trs universos

Os conceitos de defeito, erro e falha podem ser melhor exibidos usando-se um modelo de 3 universos. A Figura 4 descreve este modelo.

Figura 4 - Modelo de 3 Universos Fonte: WEBER, 2004, p. 9.

Neste modelo existem trs universos distintos. O primeiro universo o universo fsico, no qual a falha acontece. Ele contm as entidades fsicas que constituem o sistema.

70 Uma falha um defeito fsico ou alteraes de comportamento de componentes no universo fsico. O segundo universo o universo da informao, e nele que os erros acontecem. Erros afetam unidades de informao dentro do computador. O terceiro universo o universo exterior ou universo do usurio. nele que o usurio de um sistema percebe a ocorrncia de erros, atravs do aparecimento de defeitos.

2.3.6.2 Classificao de falhas

Para classificao das falhas podemos utilizar os seguintes critrios:

Natureza ou Causa: de acordo com sua natureza, as falhas podem ser classificadas em falhas fsicas e falhas humanas:

Falhas fsicas so aquelas causadas por algum mau funcionamento de um componente fsico. Este mau funcionamento pode ser originado por diversas razes, tais como curto-circuito, perturbaes eletro-magnticas, mudana de temperaturas, etc. Falhas humanas so imperfeies que podem ser:

Falhas de projeto, cometidas durante as fases de projeto e planejamento

do sistema ou durante a execuo de procedimentos de operao ou manipulao; Falhas de interao, cometidas por violar inadvertidamente ou delibera-

damente procedimentos de operao ou manuteno.

71 Durao ou Persistncia: de acordo com sua durao e momento de ocorrncia, as falhas podem ser classificadas como transientes ou permanentes:

Falhas transientes so aquelas de durao limitada, causadas por mau funcionamento temporrio ou por alguma interferncia externa. Tais falhas podem ser tambm intermitentes, ocorrendo repetidamente por curtos intervalos de tempo. Falhas permanentes so aquelas em que uma vez que o componente falha, ele nunca mais volta a funcionar corretamente. Muitas tcnicas de tolerncia falhas assumem que os componentes falham permanentemente.

2.3.7

Tolerncia falhas

Como visto anteriormente, um sistema tolerante a falhas tenta evitar a ocorrncia de defeitos no sistema mesmo na ocorrncia de falhas. Evitar as falhas torna-se caro e no atinge a totalidade do domnio dos problemas que podem ocorrer durante o tempo de vida de um sistema computacional. Sendo assim, quando falhas ocorrem, necessrio, de alguma forma, que o sistema continue operante e torne este acontecimento transparente ao usurio, ou seja, que ele no perceba as alteraes e medidas tomadas durante este estado de inconsistncia. A meta dos sistemas tolerantes falhas evitar defeitos nos sistemas mesmo na presena de falhas. Uma importante tcnica para atingir isso a redundncia, tanto do software quanto de hardware. Podemos identificar se estamos diante de um sistema tolerante falhas quando o comportamento do sistema, na ocorrncia de defeito de algum componente, est consistente

72 com as suas especificaes e o defeito do componente mascarado, ou seja, no percebido pelo usurio e no reflete no comportamento externo do sistema.

2.3.7.1 Fases na tolerncia falhas

No h uma regra geral na construo de sistemas tolerante s falhas. Podemos, entretanto, utilizar alguns princpios de maneira mais eficiente para o desenvolvimento de sistemas dessa natureza. Quatro fases so identificadas na construo de sistemas tolerantes falhas: deteco de erros, confinamentos de dados, recuperao de erros, e tratamento da falha e continuidade de servio do sistema.

2.3.7.1.1 Deteco de erros

fase mais importante para o nosso sistema. Ter capacidade de identificao dos erros to importante quanto s medidas de recuperao e mascaramento. Estas s podem ser executadas depois da deteco dos erros. Apenas os erros previamente especificados podem ser detectados. A construo de um sistema que fosse capaz de detectar todos os erros imaginveis torna-se muito caro e invivel. No entanto, para todos os erros especificados, devem ser implementados mecanismos de verificao a fim de realizar se o erro ocorre ou no. A qualidade, desempenho e efici-

73 ncia de sistemas tolerantes esto diretamente relacionados a estes testes. H algumas propriedades que devem ser verificadas na deteco de erros. Em primeiro lugar, as verificaes devem fazer parte do sistema para uma maior eficincia. Em segundo lugar, uma verificao deve ser completa e correta, ou seja, o mecanismo de verificao deve estar apto a identificar todos os erros possveis e existentes para uma determinada falha. Como praticamente impossvel prever todos esses erros, quando uma falha no prevista pelo sistema ocorre, assume-se que tal falha no existe, ou pelo menos que esta no interessa ao domnio do sistema tolerante a falhas em questo. Uma outra propriedade a independncia do sistema de verificao de erros propriamente dito, assim o mecanismo no deve falhar quando o sistema estiver em falha, seno este no nos fornece um resultado prtico e vlido.

2.3.7.1.2 Confinamento de danos

Ao detectar-se um erro, sabe-se que uma falha ocorreu em algum componente, e um defeito ou ocorreu ou est para ocorrer. Como um intervalo pode ocorrer entre o acontecimento de uma falha e a deteco do erro (devido natureza discreta destes mecanismos), a interao entre os componentes pode causar propagao do erro pelo sistema e afetar outras partes. Esta fase tenta dimensionar os estragos causados pela falha e, conseqentemente os erros, identificando quais partes foram afetadas. Isto pode ser feito observando-se a arquitetura do sistema a fim de apontar aonde e quando uma falha ocorreu. Uma tcnica a insero de pontos de checagem (checkpoints). Um checkpoint

74 uma marcao que contm o estado do sistema em algum momento. Assim, quando um erro determinado em algum checkpoint, provvel que esse erro no tenha afetado outros estados alm desse, e a correo torna-se mais fcil.

2.3.7.1.3 Recuperao de erros

Aps as fases de deteco, dimensionamento dos estragos, localizao espacial e temporal do erro, faz-se necessrio livrar o sistema desse erro, ou seja, torn-lo livre de erros novamente. Para isso necessrio encontrar um estado que esteja consistente. Isso pode ser feito atravs de duas tcnicas: Recuperao por Retrocesso (backward recovery): Neste modelo o sis-

tema em erro restaurado a um estado anterior livre de erros. Tais estados podem ser adicionados com os checkpoints. Quando h essa regresso, diz-se que houve um rollback do sistema. Nem sempre o estado imediatamente anterior um estado consistente, pois considere que uma falha ocorreu e foi percebida apenas depois de alguns checkpoins. Nesse caso, vrios rollbacks sero feitos para que um estado satisfatrio, onde os servios possam ser executados corretamente, seja atingido. Esta tcnica utilizada devido a sua facilidade de implementao j que os checkpoints so instaurados de maneira esttica, em intervalos de tempo definidos. Uma desvantagem a sobrecarga em manter vrios estados armazenados, alm do esforo computacional para a realizao de um rollback;

75 Recuperao por Avano (forward recovery): Neste modelo o sistema

no guarda os estados anteriores. Ao detectar um erro, o sistema tenta por si s se recuperar do erro tentando construir um sistema livre de erros. Isso reduz a sobrecarga de armazenamento anterior, no entanto causa uma maior complexidade ao sistema sendo, portanto, pouco utilizado.

2.3.7.1.4 Tratamento da falha e continuidade dos servios

Ao trs fases anteriores focaram-se no erro. hora de tratar da falha inicial e elimin-la do sistema. Para falhas transientes, a reinicializao do sistema pode ser suficiente, entretanto, para falhas permanentes, outras medidas devem ser tomadas para evitar que o erro volte novamente. Essas medidas incluem localizar a falha e fazer o reparo da mesma. S aps isso o sistema poder continuar como nada houvesse acontecido.

Localizao da Falha: nesta fase o componente defeituoso precisa ser

identificado. Se no for possvel sua localizao, no ser possvel reparar o sistema para que o erro no ocorra novamente. Tipicamente, aps detectarmos o erro, o componente defeituoso identificado como sendo aquele mais prximo da origem do erro.

Reparo do Sistema: nesta fase o sistema reparado para que o compo-

nente defeituoso no seja usado novamente. Deve ser notado que a manuteno feita on-line, sem interveno manual, sendo o reparo realizado por um sis-

76 tema de reconfigurao dinmica. Em linhas gerais, tal sistema consiste em usar a redundncia presente em sistemas distribudos para substituir o componente defeituoso.

2.3.8

Cluster de alta disponibilidade

Como visto anteriormente, clusters so uma sub-classe de sistemas distribudos. Geralmente eles so grupos de computadores homogneos em menor escala, dedicados a um nmero pequeno e bem definido de tarefas, nas quais o cluster atua com uma nica mquina. Arquiteturas de clusters so ideais para o fornecimento de servios altamente disponveis. Em clusters de alta disponibilidade (HA-clusters), alguns nodos permanecem prontos para a qualquer momento assumir a carga de trabalho de nodos que apresentarem defeito, sem contribuir para o aumento de desempenho. Esses clusters tambm facilitam as tarefas de manuteno. Um nodo pode ser retirado, desligado ou substitudo sem interrupo de servio. Clusters de alta disponibilidade geralmente no compartilham a carga de processamento como os clusters de alto desempenho, nem distribuem trfego como clusters que balanceiam carga. Em clusters rodando servios altamente disponveis, alm da base de dados replicada, o sistema operacional automaticamente migra os servios de um nodo defeituoso para um nodo operacional e, automaticamente, reinicia as aplicaes. A Figura 5 exibe o modelo mais simples de cluster de alta disponibilidade.

77 Neste exemplo, h um cluster duas mquinas servindo arquivos para uma rede de computadores. H uma mquina denominada servidor primrio e outra denominada servidor de reserva. Em todo momento existe somente um n do cluster servindo arquivos. Em caso de defeito no servidor primrio, o servidor de reserva assume o servio, de maneira transparente para os usurios. Neste contexto, a transferncia de controle entre os servidores pode ter duas denominaes:

Failover: quando o controle transferido do servidor primrio para o servidor de reserva (backup);

Failback: quando o controle transferido do servidor de reserva para o servidor primrio.

Cluster com transferncias automticas de recursos (failover e failback) ajudam a evitar paradas planejadas e no planejadas do sistema.

Figura 5 - Exemplo de Cluster Fonte: PEREIRA FILHO, 2004, p. 38.

78 2.3.8.1 Compartilhamento de recursos de armazenamento

Clusters so semelhantes a sistemas distribudos e como tal no possuem memria compartilhada. Compartilhamento de dados pode ser realizado simplesmente atravs de troca de mensagens ou por armazenamento de arquivos em um disco comum. Em funo do compartilhamento de disco, clusters podem ser descritos como:

Sistemas de disco compartilhado: necessitam de um gerenciador de

bloqueio para organizar as requisies de acesso simultneo a arquivos. Um arquivo sendo escrito por um nodo do cluster no pode ser aberto para escrita em outro nodo;

Sistemas que no compartilham armazenamento: cada nodo no cluster

efetivamente independente, toda a interao por troca de mensagens.

Existem sistemas, algumas vezes classificados como cluster, que apresentam memria compartilhada atravs de hardware especial. Nesse caso, os nodos usam um barramento rpido de memria compartilhada, o que d a cada nodo acesso ao espao de memria de todo o sistema. Entretanto, esses nodos precisam estar muito prximos fisicamente uns dos outros, enquanto que nodos em sistemas que no compartilham memria podem estar geograficamente distantes uns dos outros. Sistemas sem armazenamento compartilhado so os mais populares. Nesse caso, os nodos so servidores efetivamente independentes, unidos por uma rede de alta velocidade e coordenados pelo software de cluster.

79 Uma barreira para a efetiva independncia entre os nodos a necessidade de conectar os servidores a altas velocidades. Uma Fast Ethernet pode ser suficiente para recuperao de falhas. Mas se desejado suporte a alto desempenho e longas distncias, ento uma largura de banda muito maior e no contenciosa deve ser usada.

2.3.8.2 Cluster VS. Sistemas Distribudos

Para melhor compreenso, como j tratamos o tema Sistemas Distribudos anteriormente, enumeramos algumas diferenas entre cluster e sistemas distribudos no Quadro 2. Analisando este quadro, podemos concluir que um cluster nada mais do que um sistema distribudo especializado para determinada funo.

Quadro 2 - Clusters vs Sistemas Distribudos

Fonte: PEREIRA FILHO, 2004, p. 40.

Assim, qualquer tcnica utilizada em sistemas distribudos tambm se aplica a clusters. Estas tcnicas so tanto modelos de desenvolvimento de sistemas, como tambm

80 mtodos de comunicao e gerenciamento do grupo de computadores.

2.3.8.3 Clusters Linux

Servidores independentes executando o sistema operacional Linux podem ser agrupados em um cluster sem necessidade de hardware adicional, exceto uma conexo de alta velocidade. Um cluster Linux pode ser baseado puramente em software. Nem todos os pacotes para cluster suportados por Linux so de software livre e independentes de hardware especial. Por exemplo, o Linux Network Evolocity um produto comercial que compreende hardware e software. O RHHAS (Red Hat Hight Availability Server) tambm um produto comercial cujo ncleo formado pelo software livre Piranha. A IBM tambm vem desenvolvendo produtos para cluster Linux, como sistema de arquivos: IBM General Parallel File Sistem (GPFS) for Linux, software de gerncia de cluster: IBM Cluster System Management (CSM) for Linux e inclusive hardware especial: IBM eServer Cluster 1300. A ferramenta desenvolvida no projeto Linux-HA, denominada Heartbeat, permite configurar um nodo de secundrio para qualquer outro nodo em um cluster. O funcionamento simples e usa uma antiga tcnica de tolerncia falhas: o nodo secundrio monitora continuamente o funcionamento do nodo primrio enviando para esse sinais peridicos (pings por exemplo), caso o nodo primrio falhe, o secundrio assume o seu lugar. A troca de um nodo por outro se d pela fabricao de pacotes ARP (Address Resolution Protocol), onde o nodo secundrio assume o lugar do principal, enganando os demais nodos na rede. No Quadro 3 ser apresentado outras alternativas de pacotes de software diri-

81 gidos a servidores Linux, para construo de clusters de alta disponibilidade.

Quadro 3 - Exemplo de software para cluster Linux

Fonte: WEBER, 2004, p. 44.

2.4

FERRAMENTAS PARA CLUSTERS DE ALTA DISPONIBILIDADE

Alguns dos projetos mais conhecidos atualmente, segundo Pereira Filho (2004), so:

Linux High-Availability (Heartbeat): provavelmente o mais famoso sis-

tema open-source, o linux-ha muito simples no que se refere a servio de pertinncia e a cluster de alta disponibilidade. Este um sistema que suporta cluster de 2 ns, onde um n envia continuamente mensagens ao outro n, indicando que ele esta vivo (heartbeat). A falta do recebimento dessas mensagens indica que o outro n falhou e que no deve mais pertencer ao cluster, ou seja, o linux-ha trata a incluso de um n ao grupo como sendo a juno deste n ao meio de comunicao, e a sada de um n do cluster como sendo sua sada do

82 meio de comunicao. Por possuir um servio de pertinncia muito limitado, provvel que acontea uma situao de inconsistncia (sndrome do crebro dividido), na qual os dois ns no recebem os heartbeats e ambos passam a criar sub-clusters independentes que se consideram a remanescncia do cluster original. Por no possuir um Servio de Quorum para decidir qual sub-cluster deve prosseguir com sua execuo, o linux-ha baseia-se em recursos de hardware para resolver o problema. Ele utiliza dispositivos que permitem que uma mquina desligue ou reinicialize remotamente a outra. Tais dispositivos so conhecidos pela sigla STONITH (Shoot The Other Node In The Head). Entretanto, o linux-ha no garante que uma situao onde os dois ns se desligam no acontecer;

Mission Critical Linux Kimberlite: igualmente ao linux-ha, o Kimber-

lite permite somente clusters de dois ns, onde ambos enviam continuamente mensagens de Keepalive (heartbeats) ao seu parceiro, para indicar que est operando normalmente. Ainda, no existe um algoritmo distribudo para o servio de pertinncia. Um n excludo do cluster se ele parar de enviar seus heartbeats ao outro n. Para poder resolver o impasse de uma situao de crebro dividido, em cluster kimberlite deve existir um repositrio estvel que persiste a falhas, o qual os dois ns podem acessar. Ele ser usado como um recurso de quorum, pois a partir da acessibilidade momentnea dos ns ao repositrio e a partir das informaes armazenadas nele, um n pode saber se ele deve prosseguir ou no com sua execuo. Desta maneira, dispositivos STONITH no so os nicos mecanismos de se evitar sub-clusters que funcionam paralelamente;

83 Linux FailSafe: o FailSafe foi originalmente desenvolvido para IRIX e

portado posteriormente para o Linux. Ele o mais avanado sistema de clusters de alta disponibilidade open-source. Ele permite clusters com at 16 ns, e grandes possibilidades para lidar com falhas nos servios oferecidos. Diferentemente do heartbeat e kimberlite, o FailSafe o nico a monitorar a funcionalidade de servios oferecidos pelos clusters, e no somente se certo n continua enviando mensagens de keepalive. Ele possui um Servio de Pertinncia distribudo, o qual elege um n lder para gerenciar o estabelecimento de uma nova viso no grupo. Em casos de particionamentos no grupo, o FailSafe possui um Servio de Quorum que decide se o sub-cluster possui autorizao para prosseguir sua execuo. Tal deciso baseada simplesmente no nmero de ns desta nova lista, de maneira que a partio que possuir a maioria dos ns do cluster original continuar a executar. Entretanto, ele no tolera a quebra do grupo em mais do que duas partes.

2.4.1

Modelo de funcionamento do Heatbeat

No modelo de funcionamento atual do Heartbeat, existem dois servidores, de preferncia de configuraes idnticas, onde o n principal fica executando todos os servios e o secundrio fica em Standby, monitorando o n principal, atravs do envio de sinais de vida (heatbeat) de tempos em tempos. Na Figura 6 ser demonstrado o esquema de funcionamento atual do Heartbeat.

84

Figura 6 - Modelo funcionamento atual do Heartbeat Fonte: SHERRILL, 2004.

Caso o servidor principal pare de funcionar, o servidor secundrio inicia localmente o(s) servio(s) e assume a funo de servidor principal. Algumas desvantagens deste modo de funcionamento so:

Servidor secundrio fica apenas monitorando o principal, desperdian-

do sua capacidade de processamento, at que o servidor principal pare de funcionar; tro. No existe a opo de migrar os servios de um servidor (n) para o ou-

2.4.2

Software Mon

Segundo Garcia (2004), o software Mon um conjunto de scripts escrito em Perl, com a finalidade de monitorar os servios de um cluster de alta disponibilidade, com-

85 plementando as funcionalidades do Heartbeat. O Mon trabalha com monitores e alertas, sendo que os monitores verificam o estado e os alertas executam as aes. Quando o monitor detecta algum problema, o Mon efetua o shutdown do heartbeat, levando o outro n assumir o endereo IP e os servios do n que parou de funcionar. O problema com essa soluo que ele no um sistema distribudo, sendo que a deciso que o Mon toma em um n no fica sendo de conhecimento do Mon que est sendo executado nos outros ns. Outro problema que quando algum servio para de funcionar, o Mon efetua o shutdown do heartbeat, significando para o heartbeat que o n inteiro parou de funcionar. Por causa disso, assume-se que deve ter somente um servio executando em cada n.

2.5

XML

Segundo Marchal (2000), XML (extensible Markup Language) linguagem de marcao de dados (meta-markup language), a qual permite descrev-los de forma estruturada. Essa forma de marcao de dados facilita declaraes mais precisas de contedo e resultados mais significativos de busca atravs de mltiplas plataformas. Alm disso, o XML tambm permitiu o surgimento de uma nova gerao de aplicaes de manipulao e visualizao de dados via internet. O XML permite a definio de um nmero infinito de tags, enquanto no HTML as tags podem ser usadas para definir a formatao de caracteres e pargrafos. Os arquivos XML so arquivos texto, mas no so to destinados leitura por

86 um ser humano como o HTML . Os documentos XML so arquivos texto porque facilitam que os programadores ou desenvolvedores "debuguem" mais facilmente as aplicaes, de forma que um simples editor de textos pode ser usado para corrigir um erro em um arquivo XML. As regras de formatao para documentos XML so muito mais rgidas do que para documentos HTML. Uma tag esquecida ou um atributo sem aspas torna o documento inutilizvel, enquanto que no HTML isso tolerado. As especificaes oficiais do XML determinam que as aplicaes no podem tentar adivinhar o que est errado em um arquivo (no HTML isso acontece), mas sim devem parar de interpret-lo e reportar o erro. Algumas das reas onde o XML ser til em curto prazo so:

Manuteno de grandes sites web; Troca de informaes entre organizaes; Descarga e recarga de bancos de dados; Aplicaes de comrcio eletrnico, onde diferentes organizaes cola-

boram para atender um cliente.

Na Figura 7 ser apresentado um exemplo de arquivo XML, onde a primeira linha padro, informando que um arquivo xml e a verso utilizada. Na segunda linha existe uma tag chamada message, a qual possui um atributo chamado type, com o valor running. Como possvel visualizar, todas as tags abaixo esto de forma estruturada, sendo possvel visualiza-lo em formato de blocos: tem um bloco principal chamado message com diversos blocos dentro dele. O primeiro uma tag denominado host e tem um valor nico (host03), enquanto que o bloco resources contem dois blocos chamados resource, sendo que o mesmo possue dois outros blocos: as tags name e started, cada uma com o seu respectivo valor.

87

Figura 7 - Exemplo de arquivo XML

88

PROJETO DE IMPLEMENTAO

Atualmente existem diversos grupos desenvolvendo projetos open source de Alta Disponibilidade, no entanto, esses grupos iniciaram projetos de forma independente, sendo que cada um trata determinado assunto de uma forma diferente, o que faz com que nenhum desses projetos realmente formem um completo ambiente de Alta Disponibilidade. Ao invs de iniciar um novo projeto, foi proposto neste trabalho a melhoria de uma ferramenta j existente. Aps anlises, foi selecionado para tal finalidade um software de cluster de alta disponibilidade denominado Heartbeat. Ao estud-lo e entender as funcionalidades do referido sistema, percebeu-se que o mesmo um monitor de estado operacional dos ns do cluster, o qual permite a tomada de aes em caso de falha em um deles. Porm, no existe uma gerncia de servios de cluster, ficando a cargo de scripts elaborados pelo administrador a tomada de decises a respeito de assumir e executar os servios em cada n, o que vem a ser uma soluo bastante restrita e sujeita a problemas e conflitos. Para aumentar o grau de disponibilidade de servios, foi proposto um sistema para monitoramento e gerenciamento de servios, o qual funcionar em conjunto com o Heartbeat, utilizando-se das funes de sua API para verificar o status dos ns.

3.1

FORMATO DE MENSAGENS XML

A comunicao entre o programa monitor que estar sendo executado local-

89 mente e o programa monitor que estar sendo executado em outros computador (ns), dever ser efetuada atravs da troca de mensagens no formato XML. Para cada situao haver um tipo de mensagem, conforme especificado abaixo.

xml_active: essa mensagem ser utilizada quando um host tiver que in-

formar aos demais quais os servios que esto sendo executados localmente, sendo que para cada servio que estiver ativo dever existir um bloco denominado resource, contendo os campos name, para o nome do recurso e host, para o nome do computador onde esta sendo executado. Na Figura 8 ser demonstrada o modelo dessa mensagem:

Figura 8 - Modelo mensagem xml_active.

xml_accept: essa mensagem ser utilizada quando um host quiser dele-

gar a execuo de determinado servio a outro host, sendo que na mensagem dever conter os campos fromhost, que ser informado em qual host est sendo executado o servio, resource, para o nome do recurso e tohost, que ser o host de destino. Na Figura 9 ser apresentado o modelo dessa mensagem:

90

Figura 9 - Modelo mensagem xml_accept.

xml_replyaccept: essa mensagem ser utilizada para responder a men-

sagens do tipo xml_accept, contendo a resposta se host aceitou ou no a delegao de servio. Ela dever conter os campos resource, para o nome do recurso e o campo reply, contendo a resposta que poder ser ok caso o host aceite a delegao de servio ou notok caso ele no aceite. Na Figura 10 ser apresentado um modelo da mensagem xml_replyaccept:

Figura 10 - Exemplo mensagem xml_replyaccept.

xml_migrate: essa mensagem ser utilizada quando a mensagem x-

ml_replyaccept tiver como resposta (reply) o valor ok, ou seja, quando o host aceitou a delegao de servio. Como o host aceitou a delegao do servio, a execuo do mesmo ser finalizada no host de origem e, aps a finalizao, ser enviada essa mensagem informando ao host de destino que ele j pode iniciar o servio. Essa mensagem dever conter os campos resource, para o nome do servio e o campo message, contendo a mensagem start, a qual permite a inicializao do servio no host destino. Para demonstrar a mensagem xml_migrate, ser apresentado um modelo da mesma na Figura 11:

91

Figura 11 - Modelo mensagem xml_migrate.

xml_replymigrate: aps ter recebido a mensagem xml_migrate, a qual

autoriza o host a iniciar o servio localmente, ser efetuado a tentativa de iniciar o servio, devendo a resposta da inicializao ser enviada atravs dessa mensagem. Essa mensagem dever conter os campos resource, para o nome do servio e reply, para a resposta da inicializao, podendo conter o valor ok para sucesso ou fail para falhas. Na Figura 12 ser apresentado um modelo da mensagem xml_replymigrate:

Figura 12 - Modelo mensagem xml_replymigrate.

xml_running: essa mensagem dever ser enviada por algum programa

cliente, quando o administrador desejar saber os servios que fazem parte do cluster e os seus estados. Como todos os hosts possuem os estados de todos os servios, essa mensagem poder ser enviada a qualquer host pertencente ao cluster. Ela dever ter o campo host, contendo o nome do host onde os servios devem estar executando, sendo possvel informar all para obter as informaes referentes a todos os hosts. Para demonstrao, na Figura 13 ser apresentado um modelo dessa mensagem:

92

Figura 13 - Formato mensagem xml_running.

xml_replyrunning: essa mensagem dever ser enviada como resposta a

mensagem xml_running, contendo todos os servios que esto sendo executados no cluster e os seus estados. Ela ter um bloco host para cada host do cluster, sendo que o campo hostname ser o nome do host e hoststatus o seu estado atual. Dever existir um bloco resources, onde para cada servio dever existir um outro bloco chamado resource, com os campos name, para o nome do recurso e status, para o estado atual do servio. Ser apresentado abaixo a Figura 14, exemplificando o formato dessa mensagem:

Figura 14 - Modelo mensagem xml_replyrunning.

Alm dessas mensagens, o sistema ter um arquivo de configurao, tambm no formato XML, o qual demonstrado um exemplo na Figura 15. O contedo do arquivo XML deve ser:

93 dever existir um bloco general, contendo configuraes gerais do pro-

grama. Essas configuraes so: port, que ser a porta UDP na qual o programa dever enviar e receber mensagens e log, que deve ser o destino das mensagens de log, podendo assumir o valor syslog, para gravao de mensagens no arquivo de log do sistema ou um nome de arquivo com caminho relativo, pois o mesmo ser gravado dentro do diretrio de logs do Linux (/var/log/); dever existir um bloco hosts e para cada host que fizer parte do cluster

ser necessrio um sub-bloco host, com os campos number, para o nome do host e address, para o seu endereo IP; dever existir um bloco reources, sendo que para cada servio haver

um sub bloco chamado resource, contendo os campos: o name: dever ser o nome do recurso (servio). Por exemplo, pa-

ra um servidor de pginas web (apache), o nome do recurso poderia ser http; o address: dever ser o endereo no qual esse recurso estar dis-

ponvel. Por exemplo, para o servidor web funcionar corretamente pode ser necessrio que ele esteja executado no host que tenha o endereo 172.21.7.10; o port: caso o recurso utilize alguma porta, essa porta dever ser

informado nesse campo. Por exemplo, para um servidor de pginas web normalmente a porta 80; o priority: essa ser a lista de prioridade para a execuo do recur-

so. Por exemplo, supondo que essa lista possua o valor host_1 host_2 host_3 , o sistema entender que quem executar o recurso primeiro ser o host_1, sendo que, na ocorrncia de alguma falha desse host que o

94 impossibilite de continuar com a execuo do recurso, quem possuir o direito de assumir com a execuo ser o host_2. Caso tambm no seja possvel para o host_2 continuar com a execuo do servio, o responsvel por assumir sua execuo ser o host_3; o script: esse campo dever conter o script responsvel pela exe-

cuo do recurso. Seguindo o padro de inicializao e parada de servios do Linux, esse script dever tratar os parmetros start e stop, para inicializar ou parar o servio, respectivamente; o interval: esse campo estar dentro do sub bloco test, sendo que

nesse campo ser informado, em segundos, de quanto em quanto tempo dever ser efetuado o teste para saber se o servio esta ativo ou no. Por exemplo, caso deseje verificar o estado do servio de pginas web a cada 30 segundos, este campo dever conter o valor: 30; o timeout: esse campo ser utilizado para informar aos outros host

o tempo limite para recebimento de mensagens informando o estado do servio. Por exemplo, supondo que o servidor de pginas web dever ser testado a cada 30 segundos e o timeout esteja configurado com 5 segundos, ento os outros hosts aguardaro uma nova mensagem informando o estado do servio durante os 35 segundos posteriores ao recebimento da ultima mensagem. Caso no chegue nenhuma mensagem durante esse tempo ento ser assumido que o servio no est ativo, conforme conceito apresentado nas referencias tericas que um n ou recurso tomado como inativo pela ocorrncia de timeouts de comunicao; o script: como os servios no so idnticos, o estado de um re-

95 curso deve ser analisado de forma diferente para cada servio. Sendo assim, nesse campo dever conter um script ou programa responsvel por analisar o estado do servio em questo. Por exemplo, caso exista um script ou programa que teste o servio de pginas web em /etc/monitor.d/httpd.sh, ento esse dever ser o valor desse campo. Ateno: esse script ou programa dever retornar um valor informando o estado atual do servio; o expect: esse campo ser o valor que o script de teste dever re-

tornar quando o servio estiver ativo, ou seja, se o valor retornado pelo script for igual a esse campo, ento o servio ser assumido como ativo. Por exemplo, supondo que o recurso seja o servidor de pginas web, com o script de teste localizado em /etc/monitor.d/httpd.sh e com retorno igual a 0 sempre que o servio estiver ativo, ento esse campo dever conter o valor 0. Quando o script for executado, ser retornado o resultado do teste, sendo que se o resultado for 0, ser assumido que o servio esta ativo, caso contrrio, como inativo. Modelo A: (resultado(script) = 0), servio ativo. Modelo B: (resultado(script) <> 0), servio inativo.

96

Figura 15 - Modelo de arquivo de configurao.

3.2

ESQUEMA DE FUNCIONAMENTO PROPOSTO

Ser demonstrado um esquema de funcionamento do sistema, detalhando o que poder ocorrer em cada situao. Para melhor entendimento, ser demonstrado um ambiente com trs hosts e trs servios, conforme configurao abaixo:

97 Configurao de hosts:

host_1: o host_1 dever fazer parte do cluster, possuindo o endereo IP

172.21.7.1 ; host_2: o host_2 dever fazer parte do cluster, possuindo o endereo IP

172.21.7.2 ; host_3: o host_3 dever fazer parte do cluster, possuindo o endereo IP

172.21.7.3 .

Configurao de recursos:

recurso_1: o recurso_1 dever ser um recurso provido pelo cluster, sen-

do o seu IP 172.21.7.10. Cada recurso dever conter uma lista de prioridade, informando qual a ordem que os hosts utilizaro para assumir a execuo do servio. Para esse servio a lista de prioridade ser: host_1 host_2 host_3 ; recurso_2: o recurso_2 dever ser um recurso provido pelo cluster, sen-

do o seu IP 172.21.7.11. Cada recurso dever conter uma lista de prioridade, informando qual a ordem que os hosts utilizaro para assumir a execuo do servio. Para esse servio a lista de prioridade ser: host_2 host_1 host_3 ; recurso_3: o recurso_3 dever ser um recurso provido pelo cluster, sen-

do o seu IP 172.21.7.10. Cada recurso dever conter uma lista de prioridade, informando qual a ordem que os hosts utilizaro para assumir a execuo do servio. Para esse servio a lista de prioridade ser: host_3 host_2 host_1 .

Ao iniciar o programa em determinado host, ele assumir o estado denominado

98 Estado Inicial. Nesse estado ele ir verificar quais os hosts fazem parte do cluster, de acordo com o arquivo de configurao, e o estado de cada um, atravs da API do Heartbeat. Aps verificar os hosts o sistema passar a possuir uma tabela com cada computador e o seu estado, conforme tabela abaixo.

Tabela 3 - Tabela de hosts no Estado Inicial.

Numero 1 2 3

Host host_1 host_2 host_3

IP 172.21.7.1 172.21.7.2 172.21.7.3

Status Active Active Active

Caso algum computador no esteja ativo, o campo Status ter o valor down ao invs de active, conforme o modelo abaixo:
Tabela 4 - Tabela de hosts no Estado Inicial com host inativo.

Numero 1 2 3

Host host_1 host_2 host_3

Endereo 172.21.7.1 172.21.7.2 172.21.7.3

Estado Active Down Active

Com a tabela de hosts definida, o sistema efetuar a leitura dos recursos e verificar quais ficaram sob sua responsabilidade e ento executar os scripts de teste para saber o estado de cada um. Supondo que o programa iniciou a execuo as 11:00:00 hrs no host_1, o sistema dever ter a seguinte tabela em memria:

Tabela 5 - Tabela de recursos no Estado Inicial.

Nome

Endereo

Rodando Lista prioridade

Ult.Msg

Intervalo Estado

99 Recurso_1 172.21.7.10 host_1 Recurso_2 172.21.7.11 host_2 Recurso_3 172.21.7.12 host_3 host_1 host_2 host_3 host_2 host_1 host_3 host_3 host_2 host_1 11:00:00 20 11:00:00 30 11:00:00 60 Active Active Active

Depois de montado as tabelas iniciais, o sistema iniciar a escuta por novas mensagens, criando um socket udp na porta especificada no arquivo de configurao. Essas mensagens podero ser recebidas do programa monitor que esteja executando em outro host ou de um programa cliente. Aps o socket ser criado, o sistema ficar no estado Em Execuo, conforme o modelo da figura abaixo.

Figura 16 - Viso dos hosts no estado Em Execuo.

No estado Em Execuo, o sistema ficar aguardando que ocorra algum evento, o qual pode ser:

ocorrncia de alterao de estado em algum host do cluster, sendo o a-

nuncio dessa alterao fornecido ao sistema atravs de uma funo de callback da API do Heartbeat; o intervalo entre a ltima checagem de execuo para algum recurso for

igual ou superior ao ultimo teste mais o campo intervalo; o sistema pode receber uma nova mensagem atravs do socket udp, po-

100 dendo essa mensagem ter sido enviada por um programa que esteja executando em outro host ou por um programa cliente.

Quando ocorrer algum desses eventos, o sistema dever realizar algumas aes. Os detalhes dessas aes sero apresentados abaixo, para cada tipo de evento.

3.2.1

Evento alterao de estado de um host

Conforme explicado anteriormente, pode ser que algum host tenha seu estado alterado, o que ativa uma funo de callback do Heartbeat, que reporta o host e seu novo estado a todos os hosts do cluster. Quando esse evento ocorrer o sistema dever:

alterar em sua tabela o host que sofreu alterao, mudando o seu estado

atual para o novo estado, o qual informado pelo Heartbeat; caso o estado anterior fosse ativo e o novo estado inativo, o sistema ve-

rificar em sua tabela de servios se algum estava executando no host que ficou inativo; se existir algum, ele verificar na lista de prioridade se ele o prximo

host com permisso de iniciar o servio. Caso no seja, ele verifica se o prximo host esta ativo ou no, sendo que caso no esteja, ele vai passando um a um at que encontre um host ativo ou chegue sua vez ou ento que a lista termine. Como a lista ser uma lista circular, ou seja, caso o ultimo elemento seja encontrado ele voltar para o primeiro elemento, o fim da lista ser entendido

101 como sendo host onde o servio estava executando; caso seja ele o host que dever executar o servio (podendo ser ele o

prximo ou o prximo ativo da lista), o sistema dever primeiramente ativar o endereo IP no qual o servio deve ser executado. Com o endereo IP ativo, o sistema ento dever executar o script de inicializao do servio, passando como parmetro o valor start; se o servio for iniciado com sucesso, ento o sistema enviar a todos

os outros hosts ativos a mensagem xml_active, informando os servios ativos localmente, inclusive o servio que acabou de ser inicializado; se ocorrer alguma falha iniciando o servio ento o sistema ir desativar

o IP que tinha ativado anteriormente para o servio e enviar para o prximo host da lista de prioridade a mensagem xml_accept, solicitando-lhe que aceite a delegao de execuo desse servio. Caso ele aceite, sero executados os passos anteriores at que algum host consiga iniciar o servio; caso nenhum host ativo possua permisso de executar o servio ou caso

os que possuam no consigam inicializa-lo, ser ento gerado um alerta ao administrador e o estado do servio ser alterado para inativo; caso o estado do host fosse inativo e passe para ativo, se o host tiver al-

gum servio que deveria estar sendo executado localmente mas que por motivo de migrao, ocorrido automtica ou manualmente, esteja sendo executado em outro host, quem dever selecionar em qual host o servio dever continuar executando ser o administrador do sistema, pois pode ocorrer desse host ainda estar em estado de falha, ou seja, esse sistema ir considerar algum tipo de falha como falha permanente, at que o administrador informe o contrrio.

102 Para um melhor entendimento, tomaremos como exemplo que todos os hosts e servios estavam ativos, de acordo com as Tabelas e a Figura abaixo:

Tabela 6 - Tabela de hosts ativos.

Numero 1 2 3 host_1 host_2 host_3

Host

IP 172.21.7.1 172.21.7.2 172.21.7.3 Active Active Active

Status

Tabela 7 - Tabela de recursos ativos.

Nome

Endereo

Rodando

Lista prioridade host_1 host_2 host_3 host_2 host_1 host_3 host_3 host_2 host_1

Ult.Msg

Intervalo

Estado Active Active Active

Recurso_1 172.21.7.10 host_1 Recurso_2 172.21.7.11 host_2 Recurso_3 172.21.7.12 host_3

11:00:00 20 11:00:00 30 11:00:00 60

Figura 17 - Situao dos hosts antes do Estado de Transio.

Assumindo que o computador host_3 pare de funcionar as 11:10:00 hrs, o cluster passar para o estado Em Transio, onde teremos a seguinte situao:

103
Tabela 8 - Tabela de hosts quando o cluster entra em Transio.

Numero 1 2 3 host_1 host_2 host_3

Host

IP 172.21.7.1 172.21.7.2 172.21.7.3 Active Active Down

Status

Tabela 9 - Tabela de servios quando o cluster entra em Transio.

Nome

Endereo

Rodando

Lista prioridade

Ult.Msg Intervalo

Estado Active Active Transio

Recurso_1 172.21.7.10 host_1 Recurso_2 172.21.7.11 host_2 Recurso_3 172.21.7.12 host_3

host_1 host_2 host_3 11:00:00 20 host_2 host_1 host_3 11:00:00 30 host_3 host_2 host_1 11:10:00 60

Figura 18 - Imagem do cluster no estado em Transio.

Nessa situao, tanto o computador host_1 quanto o host_2 devero analisar a lista de prioridade do servio recurso_3. O host_1 ir analisar a tabela e ver que quem deve assumir o servio o host_2, o qual se encontra ativo. Sendo assim ele no ir fazer mais nada, enquanto que o host_2, sabendo que deve assumir a execuo do servio, ir assumir o IP 172.21.7.12, o qual foi designado para o servio recurso_3.

104

Figura 19 - Imagem do cluster em Transio com migrao de IP.

Com o IP ativo, o sistema que esta executando no host_2 ir tentar iniciar o servio, executando o script de inicializao do servio. Caso o servio seja iniciado com sucesso, as 11:10:10 hrs, ele ir alterar sua tabela de servios, mudando a situao e host do servio recurso_3.

Tabela 10 - Tabela de servio com cluster finalizando Transio.

Nome

Endereo

Rodando

Lista prioridade host_1 host_2 host_3 host_2 host_1 host_3 host_3 host_2 host_1

Ult.Msg

Intervalo

Estado Active Active Active

Recurso_1 172.21.7.10 host_1 Recurso_2 172.21.7.11 host_2 Recurso_3 172.21.7.12 host_2

11:00:00 20 11:10:10 30 11:10:10 60

Figura 20 - Imagem do cluster em Transio com migrao de servio.

105 Tendo iniciado o servio e j alterado suas tabelas de controle, o sistema enviar a todos os hosts ativos a mensagem xml_active, a qual contem todos os servios que esto sendo executados localmente. Como no nosso exemplo os nicos hosts ativos so o host_1 e o host_2, o host_1 ser o nico a receber a mensagem, o qual efetuar a leitura e far a alterao em suas tabelas, ficando iguais s do host_2. O cluster voltar ento para o estado Em Execuo.

Figura 21 - Imagem de host enviando mensagem xml_active aps Transio.

3.2.2

Evento para checar estado de servio

Conforme explicado anteriormente, o sistema ficar monitorando o estado de todos os servios que esto sendo executados no cluster de tempos em tempos, o qual ser definido pelo administrador. Quando o momento atual for maior ou igual ao momento da ultima checagem mais o campo intervalo de um recurso qualquer, o sistema ter que efetuar uma nova checagem, conforme os passos descritos abaixo.

o sistema verificar em sua tabela de servio se o mesmo esta sendo e-

106 xecutado local ou remotamente. Caso esteja sendo executado localmente, o sistema verificar qual o script de checagem deve ser executado e o retorno esperado dessa checagem; o script ser executado e o seu retorno comparado com o valor espera-

do. Caso sejam iguais, ser assumido o estado do servio como ativo, caso contrrio como inativo. O sistema gravar em sua tabela de servio o horrio que foi executado o teste e efetuar a comparao do estado anterior com o novo estado, sendo que, caso sejam diferentes, o mesmo ser atualizado para o novo estado; o sistema enviar a todos os hosts do cluster uma mensagem do formato

xml_active, informando aos outros hosts o estado de seus servios; se o estado do servio for inativo, ento os outros hosts sabero desse

novo estado, pois o servio no far parte da mensagem xml_active, ento eles entraro no processo Em Transio, conforme descrito a partir do passo 3 do evento: alterao de estado de um host. Para um melhor entendimento, ser demonstrado os passos que devero ser realizados na ocorrncia desse evento. Para isso, teremos como base situao onde os trs hosts esto ativos, cada um executando um servio, sendo que a ultima checagem de estado dos servios ocorreu as 11:00:00.

Tabela 11 - Tabela da situao atual dos hosts.

Numero 1 2 3 host_1 host_2 host_3

Host

IP 172.21.7.1 172.21.7.2 172.21.7.3 Active Active Active

Status

107
Tabela 12 - Tabela da situao atual dos servios no cluster.

Nome

Endereo

Rodando

Lista prioridade host_1 host_2 host_3 host_2 host_1 host_3 host_3 host_2 host_1

Ult.Msg

Intervalo

Estado Active Active Active

Recurso_1 172.21.7.10 host_1 Recurso_2 172.21.7.11 host_2 Recurso_3 172.21.7.12 host_3

11:00:00 20 11:00:00 30 11:00:00 60

Figura 22 - Imagem da situao atual do cluster.

Supondo que o momento atual seja 11:00:20, o sistema ter que efetuar a checagem do recurso_1. Como o servio recurso_1 esta sendo executado pelo host_1, o mesmo ter que executar o script de checagem de servio e comparar o seu retorno com o retorno esperado para esse tipo de checagem.

Figura 23 - Imagem do host_1 efetuando a checagem de estado do recurso_1.

Caso o retorno obtido seja idntico ao esperado, o host_1 assumir que o servio esta ativo e ir alterar a sua tabela de servios, ficando igual ao modelo abaixo:

108
Tabela 13 - Tabela de recursos aps checagem de estado.

Nome

Endereo

Rodando

Lista prioridade host_1 host_2 host_3 host_2 host_1 host_3 host_3 host_2 host_1

Ult.Msg

Intervalo

Estado Active Active Active

Recurso_1 172.21.7.10 host_1 Recurso_2 172.21.7.11 host_2 Recurso_3 172.21.7.12 host_3

11:00:20 20 11:00:00 30 11:00:00 60

Com essa tabela montada, o host_1 enviar uma mensagem xml_active para todos os outros hosts ativos, que nesse caso sero o host_2 e o host_3.

Figura 24 - Host_1 envia mensagem xml_active para host_2 e host_3.

Imediatamente aps o recebimento dessa mensagem eles tambm iro alterar sua tabela de servios, modificando o campo Ultima Mensagem para o momento em que receberam a mensagem de servios ativos. Sendo assim, todos os hosts sempre tero o estado consistente de todos os servios do cluster.

109 3.2.3 Evento de recebimento de uma nova mensagem

Conforme explicado anteriormente, o sistema estar sendo executado em cada host ativo no cluster, sendo assim, dever existir um meio para que eles se comuniquem, para manter um estado consistente no cluster. Essa comunicao ser efetuada pela troca de mensagens XML, atravs de um socket udp. Assim que o sistema receber uma dessas mensagens, ele dever efetuar um tratamento para elas, o qual ser detalhado abaixo.

quando o sistema receber uma nova mensagem, ele efetuara a leitura da

mensagem para saber o tipo da mesma; caso a mensagem seja uma mensagem do tipo xml_active, o sistema de-

ver ler quais os servios que fazem parte dessa mensagem e alterar em sua tabela de recursos os campos Ultima Mensagem, que ser utilizado para armazenar o momento do recebimento da ultima mensagem informando seu estado e o campo Estado, que ser utilizado para armazenar o estado atual do servio. Esse tipo de mensagem dever ser enviado somente pelo sistema, quando ele estiver em execuo em outro host, e no possuir nenhum retorno; se a mensagem for do tipo xml_accept, significa que esta sendo solici-

tado a migrao de um servio. Essa mensagem pode ser enviada tanto pelo sistema, quando estiver em execuo em outro host quanto por um programa cliente. Sendo assim, o sistema ir ler o campo ToHost, para saber em que host essa mensagem deve ser processada. Caso seja um host diferente do atual, o sistema ir encaminhar a mensagem para o host correto. Estando no host certo, o sistema ir verificar o seu estado e ir responder ao host onde o servio esta

110 sendo executado com uma mensagem do tipo xml_replyaccept, informando se aceita executar o servio ou no. Caso ele aceite, ficar aguardando que o host de origem (FromHost) pare de executar o servio e lhe encaminhe uma mensagem do tipo xml_migrate, informando que j pode iniciar o servio. O sistema tentar ento iniciar o servio, executando o script de inicializao. Aps a execuo do script de inicializao, o sistema dever enviar uma mensagem do tipo xml_replymigrate, informando ao host de origem (FromHost) o resultado da inicializao; quando a mensagem for do tipo xml_running, significa que algum pro-

grama cliente esta solicitando o estado dos servios que esto sendo executados, sendo que se o campo host possuir um valor diferente de all, ento que dizer que o cliente deseja saber o estado somente desse host, enquanto que se o valor for igual a all, o cliente deseja o estado de todo o cluster. Todos os hosts devem ter um estado consistente, ou seja, todos devem saber do estado do cluster, ento, o host que recebeu essa mensagem deve responde-la com uma mensagem do tipo xml_replyrunning, informando ao cliente as informaes solicitadas.

Para exemplificar o fluxo de mensagens, abaixo ser mostrado como o sistema dever se portar ao recebimento de uma nova mensagem. Supondo que as 11:00:00 o sistema teve uma atualizao geral, ficando todos os hosts com o mesmo estado. Se as 11:00:20 o sistema do host_1 enviar ao host_2 e host_3 uma mensagem do tipo xml_active, reportando o estado de seus servios, ento os hosts que receberem essa mensagem devero atualizar a sua tabela de servios, ficando semelhante a informada abaixo.

111
Tabela 14 - Tabela de servios atualizada pela mensagem xml_active.

Nome

Endereo

Rodando Lista prioridade host_1 host_2 host_3 host_2 host_1 host_3 host_3 host_2 host_1

Ult.Msg

Intervalo Estado Active Active Active

Recurso_1 172.21.7.10 host_1 Recurso_2 172.21.7.11 host_2 Recurso_3 172.21.7.12 host_3

11:00:20 20 11:00:00 30 11:00:00 60

Esse tipo de mensagem no possui nenhuma resposta, ento o seu fluxo dever ser igual ao da Figura abaixo:

Figura 25 - Fluxo da mensagem xml_active.

Para exemplificar o uso da mensagem xml_accept, iremos supor que o host_1 tentar delegar a execuo do servio recurso_1 para o host_2, o qual aceitar a execuo, respondendo isso na mensagem xml_replyaccept. Aps o host_1 finalizar a execuo do servio recurso_1, ele enviar uma mensagem do tipo xml_migrate, para que o host_2 inicie o servio. Depois do servio iniciado, o host_2 enviar a confirmao de inicializao para o host_1 com uma mensagem do tipo xml_replymigrate.

112

Figura 26 - Fluxo da mensagem xml_accept.

Figura 27 - Fluxo da mensagem xml_replyaccept.

Figura 28 - Fluxo da mensagem xml_migrate.

113

Figura 29 - Fluxo da mensagem xml_replymigrate.

Supondo que esse processo de migrao de recursos tenha terminado as 11:00:30, a tabela de servios do cluster dever ser igual a Tabela abaixo:

Tabela 15 - Tabela de servios atualizada aps a migrao de servios.

Nome

Endereo

Rodando Lista prioridade host_1 host_2 host_3 host_2 host_1 host_3 host_3 host_2 host_1

Ult.Msg

Intervalo Estado Active Active Active

Recurso_1 172.21.7.10 host_2 Recurso_2 172.21.7.11 host_2 Recurso_3 172.21.7.12 host_3

11:00:30 20 11:00:30 30 11:00:30 60

Agora para exemplificar o fluxo da mensagem xml_running, iremos supor que um cliente qualquer solicitou ao host_1 a situao geral do cluster, atravs da mensagem xml_running. Como explicado anteriormente, o estado do cluster deve ser conhecido por todos os hosts, ento mesmo que o host_1 no tenha nenhum recurso executando, ele saber a situaao atual, podendo responder ao cliente com a mensagem xml_replyrunning.

114

Figura 30 - Fluxo da mensagem xml_running.

Figura 31 - Fluxo da mensagem xml_replyrunning.

115

RESULTADOS

O ambiente de trabalho utilizado durante o desenvolvimento e teste do sistema foi montado utilizando-se trs microcomputadores do tipo IBM-PC, localizados no CDI (Centro Discente de Informtica) da Unifran (Universidade de Franca). As principais caractersticas dos microcomputadores utilizados esto no quadro abaixo.

Quadro 4 - Caractersticas dos computadores utilizados no ambiente de trabalho

Processador Memria S.O Placa de Rede

Pentium 4 128 MB Linux Fedora Core 1 10/100M

A administrao do cluster feita por intermdio de uma ferramenta cliente desenvolvida em linguagem Java, que possibilita ao administrador visualizar os ns e servios que compe o cluster, mostrando o estado atual de cada um. Existe tambm nesse programa cliente a opo de solicitar que um servio que est executando em determinado n migre para outro. Depois de instalado e configurado o ambiente com o Linux Fedora Core 1, Heartbeat 1.2.2 e o sistema Monitor, o prximo passo foi a realizao de testes do sistema. Em um ambiente de testes no possvel simular todos o problemas que podem ocorrer em um sistema em produo. Sendo assim, foram efetuadas simulaes referente

116 aos problemas mais conhecidos em um sistema de alta disponibilidade.

Figura 32 - Tela contendo informaes do estado atual dos hosts.

Na Figura 32 possvel observar que o sistema trabalha em conjunto com o Heartbeat, sendo assim, o sistema tem um estado atualizado de cada host que compe o cluster.

117

Figura 33 - Tela aps envio de mensagem xml_active.

Na Figura 33 esta sendo executado no host sala64_05 o servio squid, e quando o momento atual maior ou igual ao tempo da ltima checagem de estado mais o tempo configurado para testar, o sistema executa o script de teste de estado e posteriormente envia uma mensagem do tipo xml_active para os outros hosts ativos.

118

Figura 34 - Tela aps recebimento de mensagem xml_active.

Atravs da Figura 34 possvel observar que no host sala64_04 foi realizado um teste de estado do servio web e posteriormente enviado uma mensagem do tipo xml_active. O host sala64_05 recebeu esta mensagem e atualizou em sua tabela o estado o servio.

119

Figura 35 - Tela com solicitao de mensagem xml_running e resposta xml_replyrunning.

Na Figura 35 demonstrado que um cliente solicitou o estado atual do cluster, atravs da mensagem xml_running. O sistema montou a mensagem xml_replyrunning, retornando para o cliente as informaes solicitadas.

120

Figura 36 - Computador executando programa cliente.

Na Figura 36 mostrado um computador executando o programa cliente, o qual mostra o estado dos hosts e seus servios.

121

CONCLUSO

Este trabalho cobriu conceitos desde sistemas distribudos at clusters, apresentando seus principais conceitos e onde possvel aplic-los. Houve um aprofundamento maior em cluster de alta disponibilidade, onde foi possvel entender como estes funcionam e quais os recursos oferecidos. Foi possvel compreender que um cluster de alta disponibilidade visa exclusivamente manter os servios prestados por um sistema computacional o maior tempo possvel disponvel, no levando em considerao o desempenho. Depois de realizado todos estes estudos, foi possvel fazer vrias concluses:

o Linux um timo sistema operacional para se trabalhar com clusters,

devido a grande quantidade de pesquisas e ferramentas para sistemas distribudos e clusters, com base nesse sistema operacional; dos; o Heartbeat uma ferramenta que vem sendo muito utilizado para monos clusters so muito poderosos, mas de modo geral, so pouco utiliza-

tar clusters de alta disponibilidade em Linux, no entanto, ainda necessrio muitas melhorias e o desenvolvimento de vrias funcionalidades; o software Mon so scripts que se prope a monitorao de servios, no

entanto ele no possui um estado consistente, ou seja, ele no um sistema distribudo. Com isso, o Mon no fica ciente das atitudes tomadas pelo software

122 em outro n, o que pode causar desastres em um ambiente de cluster; necessrio que exista um padro para clusters, pois cada ferramenta

encontrada os trata de uma forma diferente, sendo difcil efetuar a escolha de alguma delas; testar um sistema de alta disponibilidade no uma tarefa fcil, pois em

um ambiente de teste no ocorre os tipos de problemas que podem ocorrer em um sistema em produo.

Foi possvel concluir que um cluster de alta disponibilidade no um sistema simples. Para um sistema de alta disponibilidade ser realmente til e completo, ele precisa oferecer mais do que garantias de disponibilidade de recursos. Assuntos como replicao de dados e sincronizao de estado tambm precisam ser endereados. Cada um destes assuntos tambm ir possuir seus detalhes, aumentando assim a complexidade envolvida com cluster de alta disponibilidade. Desta maneira, um sistema de alta disponibilidade completo pode tornar-se muito complexo, sendo que muitas necessidades no pedem toda esta complexidade. Antes de optar por uma soluo complexa de disponibilidade deve-se analisar se realmente precisa desse tipo de soluo.

Este trabalho e o projeto OCF

O Open Cluster Framework (OCF) um projeto open-source que visa a padronizao de clusters. Segundo OCF (2004), a idia desse projeto criar um padro de APIs, de forma que seja possvel a construo de aplicaes para clusters altamente portveis, liberando ento os desenvolvedores de plataformas e solues proprietrias.

123 Como o formato das APIs ainda no esta totalmente definido e no momento da realizao desse trabalho o projeto no apresentava andamento nessas definies, foi escolhido no adotar esse padro por enquanto. No entanto, como pesquisas futuras, esse trabalho dever ser convertido para o padro OCF, assim que as APIs forem definidas e implementadas.

124

REFERNCIAS

BARAK, A. Mosix. Disponvel em: <http://www.mosix.org/>. Acesso em: 23 fev. 2004.

BAR, M. OpenMosix. Disponvel em: <http://openmosix.sourceforge.net/>. Acesso em: 24 fev. 2004.

CONECTIVA. Alta disponibilidade. Disponvel em: <http://www.conectiva.com/doc/livros/ online/9.0/servidor/ha.html>. Acesso em: 5 mar. 2004.

FAILSAFE. Linux FailSafe Project. Disponvel em: <http://w ww.oss.sgi.com/projects/failsafe/>. Acesso em: 28 de set. 2004.

GARCIA, S. HA Alta disponibilidade. Disponvel em: <http://ha.underlinux.com.br>. Acesso em: 22 fev. 2004.

Linux-HA Project Web Site. Disponivel em: <http://linux-ha.org>. Acesso em: 25 mar. 2004.

KIRNER, C.; MENDES, S. B.T. Sistemas operacionais distribudos: aspectos gerais e anlise de sua estrutura. Rio de Janeiro: Campus, 1988.

MARCHAL, B. XML conceitos e aplicaes. So Paulo: Berkeley, 2000.

MITCHELL, M.; OLDHAM, J.; SAMUEL, A. Advanced Linux Programming. New York: New Riders, 2001.

OCF. Open Cluster Framework (OCF). Disponvel em: <http://www.ocf.org>. Acesso em: 28 jul. 2004.

PEREIRA FILHO, N. A. Servios de pertinncia para clusters de alta disponibilidade. 2004. 275 f. Dissertao (Mestrado em Cincia da Computao) Universidade de So Paulo, So Paulo.

125

PITANGA, M. Computao em Cluster: o estado da arte da computao. Rio de Janeiro: Brasport, 2003.

PITANGA, M. Supercomputadores caseiros: construindo clusters com o Linux. Disponvel em: <http://www.multipinguim.underlinux.com.br/artigos.htm>. Acesso em: 4 mar. 2004.

SCHILDT, H. C, Completo e total. So Paulo: Pearson Makron Books, 1997.

SHERRILL, W. LVS cluster configuration HOWTO. Disponvel em: <http://www.redhat .com/support/resources/howto/piranha/index.html>. Acesso em: 10 mar. 2004.

TANENBAUM, A. S.; STEEN, M. V. Distributed Systems: Principles and Paradigms. New Jersey: Prentice Hall, 2002.

TANENBAUM, A. S. Distributed Operationg Systems. New Jersey: Prentice Hall, 1995.

VIGLIAZZI, Douglas. Alta disponibilidade (High Availability) em sistemas GNU/Linux. Disponvel em: <http://www.vivaolinux.com.br/artigos/verAtigo.php?codigo=52 >. Acesso em: 10 abr 2004.

VOLKERDING, P.; FOSTER-JOHNSON, E.; REICHARD, K. Programando para Linux: Tudo sobre programao para Linux. So Paulo: Makron Books do Brasil, 1998.

VRENIOUS, A. Linux Cluster Architecture. Indianapolis: SAMS, 2002.

WEBER, T. Cluster de alta disponibilidade. Disponvel em: <http://www.inf.ufrgs.br/ ~taisy/disciplinas/TFslides/TFgrad06cluster.pdf>. Acesso em: 8 mar. 2004.

WEBER, T. Sistema distribudo. Disponvel em: <http://www.inf.ufrgs.br/~taisy/disciplinas/ TFslides/TF06sd.pdf>. Acesso em: 12 mar. 2004.

WEBER, T. Um roteiro para explorao dos conceitos bsicos de tolerncia falhas. Disponvel em: <http://www.inf.ufrfs.br/~taisy/disciplinas/Tfslides/Tfgrad02cluster.pdf>. Acesso em: 9 mar. 2004.

ZACHARIAS, D. C. Funcionamento de um cluster Linux. Disponvel em: <http://www.vivao

126 linux.com.br/artigos/impressora.php?codigo=733>. Acesso em: 3 mar. 2004.