1

CENTRO UNIVERSITRIO DE ANPOLIS CURSO SISTEMAS DE INFORMAO

TOLERNCIA A FALHAS EM SISTEMAS DISTRIBUDOS

ANPOLIS GO DEZMBRO 2011

FABRCIO FARIA BRAS MAYCON ALESSANDER MARTINS MILAGRE KLEYSON LUCAS MENDES RENATO LUIZ OLIVEIRA MEDEIRO

TOLERNCIA A FALHAS EM SISTEMAS DISTRIBUDOS

ANPOLIS GO DEZEMBRO 2011

SUMRIO

INTRODUO ..........................................................................................................01 I TOLERNCIA A FALHAS EM SISTEMAS DISTRIBUDOS ...............................02 1.1 Conceitos Bsicos ..............................................................................................02 1.1.1 Classificao de falhas .....................................................................................03 1.1.2 Aplicaes que demandam tolerncia a falhas ................................................04 1.1.3 Fases do processo de tolerncia a falhas ........................................................05 1.2 Sistemas Distribudos .........................................................................................06 1.3 Tcnicas de Tolerncia a Falhas em Sistemas Distribudos ..............................07 1.3.1 Tcnica de Recuperao..................................................................................07 1.3.2 Tcnicas de Replicao ...................................................................................09 1.3.3 Tcnica de gerenciamento de grupos ..............................................................11 1.4 Validao de Tcnicas de Tolerncia a Falhas ...................................................12 CONCLUSO ...........................................................................................................14 REFERNCIAS BIBLIOGRFICAS .........................................................................15

INTRODUO

Nos tempos atuais, de grande relevncia o crescimento da rea de Sistemas Distribudos. Isto se deve ao fato de que vrios padres de middleware tm surgido, facilitando cada vez mais o desenvolvimento e o gerenciamento de Sistemas Distribudos. As principais empresas que deram um grande passo no surgimento destes middlewares foram: a Microsoft, a Sun, a International Business Machines (IBM) e o Object Management Group (OMG). Mas, com o crescimento contnuo do uso deste padro, a OMG tem voltado suas pesquisas para os requisitos mais importantes deste tipo de tecnologia, como Segurana e Tolerncia a Falhas. Este ltimo ponto essencial para os sistemas que so projetados para funcionar de forma ininterrupta. Em se falando de Sistemas Distribudos este ponto de vital importncia, pois as tcnicas de tolerncia a falhas devem manter o sistema funcionando mesmo que um ou mais componentes do mesmo falhem. Este trabalho pretende, portanto, discutir os problemas de tolerncia a falhas em Sistemas Distribudos.

I - TOLERNCIA A FALHAS EM SISTEMAS

DISTRIBUDOS

Na busca de sistemas mais confiveis, alguns meios foram desenvolvidos para oferecer mais confiana aos sistemas, entre eles est a tolerncia a falhas. Tendo em mente que falhas so inevitveis, procura-se atribuir aos sistemas a capacidade de tolerar a ocorrncia de falhas, apresentando funcionamento desejado ou pr-definido, evitando assim danos ao usurio.

1.1 Conceitos Bsicos

Na rea de tolerncia a falhas, os termos falha, erro e defeito (ou falta) apresentam diferentes significados. Uma falha uma condio fsica anmala, causada por erros de projeto, problemas de fabricao ou distrbios externos (ANTNIO, 1999), como por exemplo: uma flutuao na fonte de alimentao. Erro a manifestao de uma falha no sistema, causando disparidade nas respostas apresentadas que diferem do valor previsto (ANTNIO, 1999), como por exemplo: devido falha citada anteriormente, um terminal de um circuito integrado deveria receber o bit 0, mas recebeu o bit 1, e isto causaria um resultado errado. No necessariamente as falhas presentes no sistema resultaro em erros, pois podero existir dispositivos que corrijam a falha. Defeito ou falta corresponde a um erro no tratado (ANTNIO, 1999). Para o melhor entendimento, esses conceitos podem ser representados utilizando- se o Modelo de Trs Universos (WEBER, 2000b, Sld 5) (SANTOS & CAVALCANTE, 2000, Cap 2. p.10) (Figura 1). O primeiro o Universo Fsico, que compreende os dispositivos semicondutores, elementos mecnicos, fontes de energia, ou qualquer outra entidade fsica. Uma falha ocorre nesse universo. O Universo da Informao compreende os dados manipulados pelo sistema, e onde um erro pode ocorrer, em virtude da existncia de alguma falha no Universo Fsico. O ltimo universo o Externo ou do Usurio. neste onde o usurio final percebe que o sistema apresentou comportamento indesejado e, portanto, possui um defeito.

Figura 1 - Modelo dos Trs Universos

Como podemos perceber na figura acima, uma falha pode acarretar em um erro e um erro pode acarretar em um defeito (TEIXEIRA & MERCER, 2000, cap. 9). Mas, segundo (WEBER, 2000b, Sld 6), existe entre uma falha e um erro, e entre um erro e um defeito uma fase chamada latncia. Esta latncia pode ser:

- Latncia de falha: o perodo de tempo entre a ocorrncia da falha at a manifestao do erro devido quela falha - Latncia de erro: o perodo de tempo entre a ocorrncia do erro at a manifestao do defeito devido quele erro. 1.1.1 - Classificao de falhas

Segundo (WEBER, 2000b, Sld 7) (SANTOS & CAVALCANTE, 2000, Cap 2. p.10), as falhas podem ser classificadas quanto sua origem em: - Fsicas: As falhas fsicas so causadas por fenmenos naturais como desgaste do material, problemas de interconexo ou quaisquer outros que afetem a estrutura mecnica ou eletrnica do sistema. As falhas fsicas podem ainda ser subclassificadas quanto durao em: Permanentes uma vez que se manifestam sempre o faro. Temporrias no-permanentes, podendo ser intermitentes, normalmente causadas pelo processo de degradao do componente e que fatalmente se tornaro permanentes com o tempo; ou transitrias, geralmente relacionadas interferncia de sistemas externos.

- Humanas: As falhas humanas so aquelas introduzidas no sistema pela ao do homem. Podem ser subdivididas em: Falhas de Projeto so introduzidas na fase de projeto do sistema. Falhas de Interao ocorrem durante a interao dos usurios com o sistema. Considera-se que as falhas nunca so introduzidas pelo usurio. Este

apenas causaria a manifestao de uma falha j existente no sistema, originadas por erros de projeto.

1.1.2 - Aplicaes que demandam tolerncia a falhas

Segundo (WEBER, 2000b, Sld 28) (SANTOS & CAVALCANTE. Cap 2. p.11), os sistemas que devem apresentar caractersticas de tolerncia a falhas podem ser categorizados em quatro reas de aplicaes: - Longa Vida: So aplicaes que foram projetadas para estar em operao por um grande perodo. considerado grande, um perodo que ultrapasse dez anos. Exemplos de aplicaes de Longa Vida so os satlites e sondas espaciais. - Computao Crtica: talvez a categoria de aplicao onde a tolerncia a falhas mais aplicada. Compreendem sistemas que, se apresentarem

funcionamento inadequado, podem levar a conseqncias catastrficas, seja pondo em risco vidas humanas, seja causando altos danos materiais. Exemplos clssicos de aplicaes de Computao Crtica so os sistemas de controle de trfego areo, sistemas de msseis teleguiados e de controle de indstrias qumicas.

- Adiamento de Manuteno: So aplicaes cuja manuteno extremamente cara, inconveniente ou difcil de executar. Para sistemas como esses se deseja que a manuteno seja feita periodicamente e enquanto isso, o sistema por si s consiga evitar e tratar as falhas que ocorram durante sua execuo. Um exemplo de aplicao desse tipo o sistema de estaes de comutao telefnicas. - Alta Disponibilidade: So aplicaes cuja disponibilidade um fator

crtico. Exemplos clssicos so os terminais de caixa eletrnicos dos bancos.

1.1.3 - Fases do processo de tolerncia a falhas Segundo (WEBERSLD, 2000b, Sld 26) (SANTOS & CAVALCANTE, 2000, Cap 2. p.11), h vrias fases para o processo de tolerncia a falhas nos sistemas. As fases sero mais bem detalhadas a seguir: - Deteco de Erros: A primeira fase do processo de tolerncia a falhas claramente a deteco de erros no sistema. Todo o mecanismo de tolerncia a falhas empregado no sistema depender da eficincia do seu mdulo de deteco de erros. O mdulo de deteco de erros deve observar o funcionamento do sistema sendo capaz de perceber desvios de comportamento a partir da especificao inicial. Existem algumas propriedades que um mecanismo ideal para deteco de erros deve apresentar: Independncia o mdulo de deteco de erros no deve ser influenciado pela estrutura interna do sistema, pois os erros existentes no sistema poderiam afetar tambm este mdulo. Completo deve detectar todos os erros possveis. Correto no pode considerar um comportamento esperado como um comportamento anmalo, ou seja, sempre que um erro for detectado, pode-se ter certeza da existncia de falhas no sistema.

- Confinamento de Erros: Aps a deteco do erro, deve-se identificar o mdulo ou componente falho do sistema. Com as passagens de informaes entre os mdulos e componentes, os erros podem propagar-se pelo sistema. Assim, todo o fluxo de informao originado do mdulo ou componente falho deve ser observado e as conseqncias das aes devem ser delimitadas, determinando as partes do sistema que foram corrompidos pela manifestao da falha. Este o objetivo desta fase. - Recuperao de Erros: Detectado o erro e identificada sua extenso pelo sistema, as alteraes de estado devem ser removidas para levar o sistema a um estado aceitvel evitando o mau funcionamento do sistema futuramente. Nesta fase, o sistema deve restabelecer um estado livre de erros aps uma

falha. Existem duas abordagens para a recuperao de erros:

Por avano se a natureza dos erros pode ser completamente avaliada, ento se pode remover estes erros do estado do processo e habilit-lo a prosseguir. Por retorno se no for possvel remover todos os erros do estado do processo, ento o processo deve ser restaurado para um estado prvio livre de erros. Normalmente, so utilizados checkpoints nessa fase.

- Tratamento de Falhas: Nas trs primeiras fases, o erro detectado, sua extenso avaliada e removido deixando o sistema livre de erros. Isso pode ser suficiente se a causa erro foi uma falha transitria. Se as falhas forem permanentes, ento o mesmo erro poder ocorrer novamente em processamento futuro. O objetivo desta fase, tambm conhecida como reconfigurao, identificar o componente falho e remov-lo do sistema para no mais ser utilizado. O componente causador da falha pode ter a granularidade variada, podendo corresponder a um chip ou a uma placa inteira, por exemplo. 1.2 Sistemas Distribudos

Um Sistema Distribudo aquele que roda em um conjunto de mquinas sem memria compartilhada, criando uma iluso para o usurio de que somente existe uma mquina executando o processo por ele requisitado (ANTNIO, 1999). Os Sistemas Distribudos permitem que uma aplicao seja dividida em diferentes partes, que se comunicam atravs de linhas de comunicao, e cada parte podendo ser processada em um sistema ( hardware e software ) independente. Mas, a partir do momento em que estas partes esto distribudas em diferentes mquinas, que por sua vez possuem dispositivos de armazenamento susceptveis a falhas, h uma necessidade de utilizar tcnicas especficas de tolerncia a falhas. Como percebemos, os sistemas distribudos possuem caractersticas naturais que induzem ao uso de tolerncia a falhas, pois estando vrias partes de um sistema distribudo em diferentes computadores de uma rede mantm uma maior confiabilidade no que diz respeito ao funcionamento contnuo de um processamento, pois pelo menos uma das partes estar processando a requisio do usurio caso

haja ocorrncia de falhas nos hosts (servidores).

1.3 - Tcnicas de Tolerncia a Falhas em Sistemas Distribudos

A distribuio de partes de um sistema por diferentes meios de armazenamento leva a um problema intrnseco de sistemas distribudos que a inconsistncia e a falta de integridade dos dados (WEBER, 2000a, Item 7). Para resolver este problema so utilizadas vrias tcnicas que garantem que todas as partes sejam consistentes, ou seja, que eles possuam o mesmo estado no momento em que houver uma falha e uma outra parte possa assumir o processamento a partir do ponto em que ocorreu a falha.

1.3.1 - Tcnica de Recuperao

Para que um sistema no sofra pane total, ao ser detectada uma falha o sistema deve ser automaticamente reconfigurado, ou seja, um processo que estava sendo executado deve ser realocado para outros caminhos alternativos que mantenham a comunicao contnua. Mas, para que o processo de recuperao no reduza a performance do sistema e seja o mais transparente possvel para o usurio, a tcnica de recuperao por avano bastante utilizada e requer permanentemente um estado consistente entre as partes de um sistema. Os mecanismos utilizados na tcnica de recuperao so (LUNG, 2000, Sld 59):

- Logging: O logging o mecanismo pelo qual as requisies feitas pelos usurios a uma parte do sistema que est distribudo em algum meio fsico so gravadas em arquivo log, para que no caso de uma falha, uma outra parte do sistema que assumir o lugar do anterior possa obter o estado corrente e da continuar o processo normalmente.

- Checkpoint: O checkpoint um determinado ponto no qual o estado atual de uma parte do sistema que est no arquivo log verificado e copiado no arquivo de log das demais partes. Isto faz com que todas as partes distribudas do sistema estejam sempre atualizadas, mantendo-se assim consistentes. Para uma melhor

visualizao do funcionamento destes dois mecanismos, vejamos a figura 2.

Figura 2 - Checkpoint e Logging Como vemos na figura 2, o checkpoint realizado a cada tempo t, que pode ser definido pelo usurio ou fixado na implementao do sistema. Durante este intervalo de tempo t, vrias requisies de usurios so realizadas e gravadas no arquivo de log. Um exemplo da utilizao da tcnica de recuperao uma transao bancria onde um cliente requisita a transferncia de um determinado valor de uma conta X para uma conta Y. Nesta transao ocorrem duas operaes: uma de dbito da conta X, e uma de crdito na conta Y. Suponhamos que no intervalo de tempo entre o dbito e o crdito ocorra uma falha e s tenha sido realizado o dbito da conta X, ento haveria a uma inconsistncia de dados, pois o valor debitado da conta X estaria perdido. Mas, com o uso do checkpoint e logging isto resolvido da seguinte maneira: suponhamos que temos partes do sistema que realiza esta operao de transferncia em vrios meios fsicos confiveis, como por exemplo: em dois servidores de aplicao (um ativo e um outro como backup). Quando o cliente requisita a operao de transferncia, o servidor ativo assume a operao e o mecanismo de logging grava esta requisio em um servidor de log . Se o intervalo de checkpoint for

suficientemente curto, esta requisio ser repassada para um arquivo de log no servidor backup. No momento em que ocorre uma falha como a descrita anteriormente, o cliente logo redirecionado para o servidor backup e o mecanismo

de recuperao (recovery) consulta o log para verificar qual foi a ltima operao realizada, e a partir deste ponto continuar a operao, sem causar transtornos para o cliente. 1.3.2 - Tcnicas de Replicao

A tcnica de replicao consiste em facilitar a criao de rplicas ou cpias de um mesmo objeto em meios fsicos diferentes, garantindo assim que, no caso de uma falha em um dos dispositivos, o cliente seja redirecionado de forma transparente para outro que tenha uma rplica do objeto ativa (JATENE, 1999). As tnicas de replicao podem ser resumidas em dois tipos bsicos (JATENE, 1999):

- Replicao passiva: Neste tipo de replicao, h apenas um objeto que recebe as requisies dos clientes, este objeto chamado primrio. Os outros objetos so chamados secundrios ou backups, e constantemente so informados pelo primrio sobre o estado atual do mesmo. Para isto, esta replicao utiliza os mecanismos de checkpoint e logging. Na figura 3 podemos visualizar melhor o funcionamento desta replicao.

Figura 3 - Replicao Passiva

Como podemos perceber na figura 3, somente o objeto primrio recebe as requisies, e atravs do mecanismo de checkpoint estas requisies so salvas nos arquivos de log dos objetos backups ou secundrios. No caso de uma falha do objeto primrio, um dos dois objetos secundrios assume o lugar do primrio, continuando assim o processamento.

10

- Replicaco ativa: Neste tipo de replicao no so utilizadas as tcnicas de recuperao, pois todas as rplicas so primrias, ou seja, todas elas recebem a requisio cliente, processam e devolvem os resultados de forma simultnea. Neste caso, a replicao deve obedecer s propriedades de atomicidade (todas as rplicas recebem as requisies num mesmo instante) e de ordenao (todas as rplicas recebem as requisies na mesma ordem). Na figura 4, podemos perceber melhor o funcionamento da replicao ativa.

Figura 4 - Replicao Ativa

Podemos perceber que este tipo de replicao pode gerar inconsistncia dos dados no momento em que todas as rplicas enviam os resultados dos seus processamentos para o cliente, pois pode ocorrer de uma resposta chegar antes da outra, causando assim mltiplos resultados para o cliente. Para resolver este problema, comum utilizar uma variao deste mtodo chamada replicao ativa com votao, no qual ocorre uma votao e somente uma das respostas retorna para o cliente. Podemos perceber tambm que neste tipo de replicao h uma melhora de performance no funcionamento dos sistema, pois no teramos mecanismos de recuperao que causaria um certo atraso no processamento, principalmente quando se trata de sistemas de tempo real como sistema clnicos, onde uma demora de milissegundos pode ser fatal. Mas, como podemos perceber, este tipo de replicao apesar de ser mais confivel, causa um trfego de informaes razovel na rede, pois haveria uma difuso da requisies para todas as mquinas da rede (broadcast) e as mesmas responderiam ao mesmo tempo. Para resolver este

11

problema, foi criada a tcnica de gerenciamento de grupos.

1.3.3 - Tcnica de gerenciamento de grupos

Uma das dificuldades encontradas nas tcnicas de replicao que vimos anteriormente o trfego na rede. Mas, outro problema surge quando precisamos tornar transparente para o cliente a localizao das rplicas no caso de uma falha, pois teramos que criar uma referncia para cada rplica criada. Para resolver estes problemas, foi criada uma definio de grupos de objetos, onde os objetos so integrados em sub-grupos diferentes, contendo cada grupo uma referncia nica. Com isto resolveramos tanto o problema da localizao das rplicas pelos clientes, como tambm o trfego excessivo na rede, pois nesta tcnica j estaria implementado a primitiva de comunicao multicast, onde apenas um determinado grupo de objetos receberia as requisies, ao contrrio da primitiva de comunicao broadcast , onde todas os objetos replicados recebem requisies (JATENE, 1999). Tambm chamada de Group Membership (WEBER, 2000a) (JATENE,

1999) ou associao de grupos, esta tcnica visa tambm facilitar a manipulao de rplicas, onde podemos cadastrar e excluir rplicas de um grupo, alm de aumentar a confiabilidade no tratamento de tolerncia a falhas, principalmente quando temos redes particionadas, ou seja, sub-redes interconectadas por um roteador, gateway etc. Vejamos na figura 5 como definida a tcnica de gerenciamento de grupo.

Figura 5 - Grupo de Rplicas de Objetos

12

Como percebemos na figura 5, cada conjunto de rplicas associadas formam um grupo. Estes grupos podem ser comparados a domnios de tolerncia a falhas, ou seja, uma grande rede particionada por sub-redes e interconectadas por hubs, switches ou roteadores. Cada grupo possui uma referncia nica (JATENE, 1999), ou seja, quando um cliente requisitar uma operao a um dos objetos, a aplicao no ir mais procurar por referncias individuais de cada objeto, mas pela referncia do grupo como um todo.

1.4 - Validao de Tcnicas de Tolerncia a Falhas

Vimos nos itens anteriores deste captulo vrias tcnicas de tolerncia a falhas mais comuns utilizadas em sistemas distribudos. Mas, quando estamos tratando de sistemas muito complexos e altamente crticos, h uma necessidade de se testar as tcnicas de tolerncia a falhas, tentando simular situaes de falhas mais prximas possveis da realidade em que sero submetidas. A esses testes damos o nome de injeo de falhas. (WEBER) (LEME, MARTINS & RUBIRA, 1998). H trs categorias de injeo de falhas, que so mostradas abaixo (WEBER, 2000) (LEME, MATINS & RUBIRA, 1998): - Injeo de falhas por hardware: Neste tipo de injeo o hardware forado a erros atravs de mudanas de valores lgicos no prprio circuito. Exemplo: um determinado pino de um CI (circuito integrado) deve receber o nvel lgico 1, e para forarmos a uma falha, injetamos um nvel lgico 0. - Injeo de falhas por software: Neste tipo de injeo so utilizados softwares que tentam corromper o cdigo do sistema, modificar caractersticas de comunicao, etc. - Injeo de falhas por simulao: Neste tipo de injeo, h uma simulao de possveis falhas que possam ocorrer no sistema ainda mesmo em tempo de projeto.

13

Pela descrio dos tipos de injeo de falhas mais utilizados, podemos perceber que a injeo de falhas por software a mais adequada, pois possui custos mais baixos que a injeo por hardware e o que mais se aproxima das condies de falhas diversas que o sistema em teste ir tratar.

14

CONCLUSO

Ao final da pesquisa, notamos a grande importncia no s de ter feito a pesquisa em si, mas sim do grande aprendizado que absorvemos de tudo que foi envolvido na pesquisa, principalmente do trabalho em grupo, mas um grande aprendizado em tcnicas pra evitar falhas em sistemas distribudos.

15

REFERNCIAS BIBLIOGRFICAS

ANTNIO, Marco. Sistemas Distribudos. 1999. Disponvel <http://orbita.starmedia.com/~brodowski/sem2.htm> Acesso em 04 dez. 2011.

em:

LEME, Nelson G. M; MARTINS, Eliane; RUBIRA, Ceclia M. R. Um Sistema de Padres para Injeo de Falhas por Software. 1998. Disponvel em: <http://www.ic.unicamp.br/~nelsongm/IIWTFAbstractR2.doc>. Acesso em 05 dez. 2011. SANTOS, Ana Carla dos Oliveira; CAVALCANTE, Srgio Vanderlei. Tolerncia a Falhas em Sistemas Embarcados. 2000. Disponvel em: <http://www.cin.ufpe.br/~acos/tg/relatorio.doc> Acesso em 06 dez. 2011. WEBER, Taisy Silva. Tolerncia a Falhas em Sistemas Distribudos: Um Texto Introdutrio. 2000. Disponvel em: <http://www.inf.ufrgs.br/~taisy/projetos/TFSDcon ceitos.htm> Acesso em 06 dez. 2011.