Baixe Modelos de Comunicação e Tolerância a Falhas em Sistemas Distribuídos e outras Notas de estudo em PDF para Probabilidade, somente na Docsity!
Escalonamento e Balanceamento de Carga
em
Ambientes Paralelos e Distribuídos
Prof. Mario Dantas
EmentaEmenta
- Introdução ao escalonamento e balanceamento
de carga
•Granularidade e particionamento de tarefas
Ementa Ementa
- Ferramentas de escalonamento
- Balanceamento de carga
- Mecanismos para migração de processos
- Índices de Carga
Bibliografia :
- Scheduling and Load Balancing in Parallel
and Distributed Systems , Shirazi-Hurson, Kavi,
IEEE Press, 1995.
- Parallel Computing : Theory and Practice,
M. Quinn, McGraw-Hill, 1994.
Bibliografia :
- High-Performance Cluster Computing - Architectures
and Systems, R. Buyya, Prentice-Hall, 1999.
- Parallel Computer Architecture: A Hardware/
Software Approach , D. Culler, Morgan Kaufmann,
Bibliografia :
- The Grid Blueprint for a New Computing
Infrastruture , Ian Foster and Karl Kessemman,
Morgan Kaufmann, 1999.
- Grid Computing: Making The Global Infrastructure
a Reality, Fran Berman, Geoffrey Fox , Tony Hey ,
John Wiley & Sons, 2003, ISBN 0470853190.
O emprego de paralelismo para resolver um problema pode ser feito em diferentes níveis.
Os níveis de paralelismo podem ser estabelecidos com base na quantidade de código que é passível de ser paralelizada.
Esta quantidade de código é conhecida como grão. O tamanho do grão define sua granularidade, que pode ser dividida em categorias como mostra a próxima tabela
I - ProgramaI - Programaçãção Paralelao Paralela
Granularidade Unidade de Código
Nível de Paralelismo Muito Fina Instrução Instrução
Fina Loop/Bloco de Instrução
Dados
Média Função Controle
Grande Processo ou Tarefa
Tarefa
GranularidadeGranularidade de Cde Cóódigo e Ndigo e Nííveis de Paralelismoveis de Paralelismo
Em uma mesma aplicação o paralelismo pode ser detectado em diferentes níveis, sendo possível explorar as abordagens aplicáveis a cada nível de forma complementar.
Dentro de um mesmo nível o tamanho do grão pode sofrer grande variação, pois as categorias de granularidade são apenas relativas.
O ajuste da performance de uma aplicação paralela é um problema que depende, entre outras coisas, de encontrar o tamanho de grão apropriado para a aplicação.
Em cada nível pode-se abordar o paralelismo de duas formas:
- uma automatizada, como é feito, a nível de instruções, nos microprocessadores superescalares;
- outra manual, como é feito, a nível de processos, ao empregar-se troca de mensagens.
Estas são as duas abordagens básicas de paralelismo:
Paralelismo implícito : a aplicação é paralelizada sem a intervenção do programador, que não especifica, e também não controla, a decomposição e o escalonamento das tarefas e a colocação dos dados.
Comumente suportado por hardware, por linguagens de programação paralelas e por compiladores paralelizadores;
- Paralelismo explícito : o programador é responsável pela maior parte do esforço de paralelização (decomposição e/ou escalonamento de tarefas, comunicação, etc.).
Essa abordagem se baseia na hipótese de que o programador é a pessoa que reúne as melhores condições para decidir como paralelizar sua aplicação.
Usualmente é dito que esta abordagem permite obter melhores resultados.
Decomposição Funcional: neste caso, a ênfase é dada na divisão da computação envolvida no problema. Primeiro procura-se particionar o processamento em tarefas disjuntas, depois é feita a análise dos dados necessários a cada tarefa.
Caso os dados possam ser divididos em conjuntos disjuntos, a decomposição está completa. Caso contrário, pode-se tentar outro particionamento do processamento, replicação dos dados ou compartilhamento dos mesmos.
Caso a sobreposição de dados seja grande, pode ser mais indicado o emprego da decomposição de domínio.
1.1.2 -1.1.2 -^ ComunicaComunicaçãção (o (CommunicationCommunication))
O particionamento do problema é feito com a intenção de executar as tarefas definidas de forma concorrente e, se possível, de forma independente.
Contudo, a computação associada a uma tarefa tipicamente envolve dados associados a uma outra tarefa, o que requer o estabelecimento da comunicação entre as mesmas.
Esta fase tem por objetivo analisar o fluxo de informações e de coordenação entre as tarefas, definindo uma estrutura de comunicação.
A natureza do problema e o método de decomposição empregado serão determinantes na escolha do modelo de comunicação entre tarefas a ser utilizado.
Foster divide os modelos de comunicação em quatro categorias (ortogonais):
Local/Global: no modelo de comunicação local cada tarefa se comunica com um pequeno grupo de outras tarefas (suas “vizinhas”), enquanto que no modelo global as tarefas podem comunicar-se arbitrariamente;
- Estruturado/Não estruturado: no modelo estruturado as tarefas formam uma estrutura regular (e.g. árvore), já no modelo não estruturado elas formam grafos arbitrários;
- Estático/Dinâmico: no modelo estático a comunicação se dá sempre entre as mesmas tarefas, enquanto que no modelo dinâmico a comunicação não possui parceiros definidos, dependendo dos valores calculados em tempo de execução;
- Síncrono/Assíncrono: há, no modelo síncrono, uma coordenação entre as tarefas comunicantes, enquanto no modelo assíncrono não existe coordenação na comunicação.
1.1.3- Aglomeraçã 1.1.3- Aglomeração (o (AgglomerationAgglomeration))
Neste passo, as tarefas e a estrutura de comunicação definida nos passos anteriores são avaliados em termos de custo de implementação e requisitos de performance. Se for necessário tarefas podem ser combinadas, ou aglomeradas, em tarefas maiores a fim de reduzir o custo de implementação ou aumentar a performance.
Pelo mesmo motivo pode-se efetuar a replicação de dados e/ou processamento.
Três objetivos, algumas vezes conflitantes, devem nortear as decisões por aglomeração e/ou replicação:
- Aumento daAumento da GranularidadeGranularidade:: redureduçãção dos custos de comunicao dos custos de comunicaçãçãoo pelo aumento dapelo aumento da granularidadegranularidade do processamento e da comunicado processamento e da comunicaçãção;o;
- PreservaPreservaçãção da Flexibilidade:o da Flexibilidade:^ aa granularidadegranularidade deve ser controladadeve ser controlada por um parpor um parââmetro em tempo de execumetro em tempo de execuçãção ou de compilao ou de compilaçãção, a fim de que oo, a fim de que o nnúúmeromero dede tarefastarefas possapossa serser adaptadoadaptado aoao nnúúmeromero dede elementoselementos dede processamento;processamento;
ReduReduçãção dos custos de engenharia de software:o dos custos de engenharia de software: deve se buscar odeve se buscar o aproveitamento de caproveitamento de cóódigo, sempre que possdigo, sempre que possíível, e avel, e a compatibilizacompatibilizaçãçãoo comcom mmóódulos jdulos jáá existentes.existentes.
1.1.4 - Mapeamento (1.1.4 - Mapeamento (MappingMapping) ou Escalonamento) ou Escalonamento
Neste passo faz-se a atribuição de tarefas a elementos de processamento, de forma a minimizar o tempo de execução.
Como objetivos intermediários, busca-se também maximizar a utilização dos recursos computacionais disponíveis (e.g. CPU) e minimizar os custos relativos à comunicação. Este é o problema que a literatura denomina de escalonamento (ou scheduling ).
Os diferentes métodos de escalonamento são comumente classificados segundo a taxonomia apresentada por Casavant e Kuhl, que encontra-se representada na próxima figura.
Scheduling
Local Global
Estático Dinâmico
Ótimo Sub-Ótimo
Aproximado Heurístico
Não Distribuído Distribuído
Cooperativo Não Cooperativo
Sub-Ótimo
Aproximado Heurístico
Ótimo
ClassificaClassificaçãção dos mo dos méétodos de escalonamentotodos de escalonamento
Seguindo a taxomia apresentada, inicialmente os métodos de escalonamento (ou scheduling) são divididos em local e global.
Escalonamento local refere-se ao problema de atribuição das fatias de tempo (time-slices) de um processador aos processos. É aquele realizado normalmente pelo sistema operacional.
O escalonamento global refere-se ao problema de decidir à cerca de onde executar um processo sendo, portanto, seus métodos aplicáveis a sistemas distribuídos. Em face disto, veremos a seguir os dois grandes grupos nos quais se dividem os métodos de escalonamento globais.
Escalonamento Estático
Neste grupo, a atribuição de processos a processadores é realizada antes do início da execução do programa. Para isto é necessário que se tenha informações à cerca dos tempos de execução dos processos e dos elementos de processamento disponíveis, em tempo de compilação.
Uma vez realizado o escalonamento, ele não poderá ser alterado em tempo de execução, mesmo que ocorra defeito de algum EP (elemento de processamento) envolvido no escalonamento.
- Política de Colocação: identifica o EP para qual o processo deve ser transferido. (^) As decisões relativas ao balanceamento de carga podem ser tomadas de
forma centralizada ou distribuída, ou ainda por uma combinação destas duas. Por exemplo, em um determinado algoritmo, a política de informação pode ser centralizada (um único EP recebe as informações de carga) enquanto que as de transferência e colocação podem ser distribuídas, sendo da responsabilidade de cada EP.
No caso do balanceamento de carga distribuído, caso os EP tomem suas decisões de forma totalmente independente diz-se que realizam escalonamento não cooperativo.
Um exemplo disto é o emprego de uma política de colocação aleatória.
No escalonamento cooperativo, ao contrário, o EP toma suas decisões de forma consoante com os demais EP, de forma a atingir um objetivo global para o sistema.
No caso da política de colocação, corresponde ao caso em que a escolha do EP é feita com base na informação de carga.
IIII –– Paradigmas de ProgramaParadigmas de Programaçãção Paralelao Paralela
Face ao tipo de paralelismo inerente ao problema e aos recursos computacionais disponíveis, os algoritmos paralelos desenvolvidos acabam por apresentar semelhanças em suas estruturas de controle. Com base nestas semelhanças surgiram os paradigmas (ou modelos) de programação paralela.
Podemos então definir paradigma, neste contexto, e segundo Hansen, como sendo uma classe de algoritmos que possuem a mesma estrutura de controle.
Na literatura, há várias propostas diferentes de classificação dos paradigmas.
Buyya e Silva analisam várias delas e os autores apresentam o que consideram ser um superconjunto de paradigmas, quais sejam:
- Master/Slave (ou Task-Farming): é o modelo das aplicações trivialmente paralelas, que corresponde à execução independente de componentes de um mesmo programa. Apresentamos na próxima figura
Master
Slave 1 Slave 2 Slave 3 Slave n
Comunicação
Processamento
Distribuição das tarefas
Coleta de Resultados
Finalização
Estrutura do ModeloEstrutura do Modelo MasterMaster//SlaveSlave
Single-Program Multiple-Data (SPMD): segundo este paradigma, todos os processos executam o mesmo código, mas em partes diferentes dos dados.
Os processos necessitam comunicar-se a fim de manter o sincronismo da execução, como na próxima figura
Distribuição de Dados
Processamento Comunicação Processamento
Coleta de Resultados
Processamento Comunicação Processamento
Processamento Comunicação Processamento
EstruturaEstrutura BBáásicasica de umde um PProgramarograma SPMD.SPMD.
Pipelining de Dados : neste paradigma o problema é dividido em uma seqüência de passos. Cada passo vira um processo e é executado por um EP diferente. A próxima figura é um exemplo de pipelining de dados.
Cabe salientar que na literatura as definições apresentadas não são unânimes e que a tradução dos termos empregados, do inglês para o português, dá margens ora à neologismos ora a sinonímias.
Desta forma, os termos em português serão apresentados acompanhados, por ocasião da sua definição, do original em inglês, a fim de manter clara a correlação com os vocábulos empregados originalmente.
O primeiro deles, que é exatamente o que exprime a relação de dependência, é o termo dependabilidade (do inglês dependability ).
É uma propriedade dos sistemas computacionais que pode ser definida como a capacidade de prestar um serviço no qual se pode, justificadamente, confiar.
O serviço prestado por um sistema é o seu comportamento, tal qual percebido pelos usuários deste sistema. O usuário (do serviço) é um outro sistema (eventualmente o próprio homem) que interage com o primeiro através da interface do serviço. A função de um sistema traduz aquilo para o qual foi feito, e é descrita na especificação do sistema.
Diz-se que um serviço é correto quando implementa a especificação do sistema.
A caracterização da dependabilidade envolve ainda um conjunto de conceitos que alguns autores dividem em três grupos: os atributos, os meios (pelos quais será alcançada), e as ameaças.
Dependabilidade
Atributos
Meios
Ameaças
Disponibilidade ( Availability ) Confiabilidade ( Reliability ) Segurança ( Safety ) Confidencialidade ( Confidentiality ) Integridade ( Integrity ) Reparabilidade ( Maintainability ) Prevenção de Falhas ( Fault Prevention ) Tolerância à Falhas ( Fault Tolerance ) Remoção de Falhas ( Fault Removal ) Previsão de Falhas ( Fault Forecasting ) Falhas ( Faults ) Erros ( Errors ) Defeitos ( Failures )
Taxonomia da Dependabilidade As Ameaças a Dependabilidade
Um sistema apresenta defeito quando não é capaz de prestar um serviço correto, ou seja, seu serviço se desvia da especificação do sistema. O defeito é o evento que causa a transição de estado do serviço de um sistema de correto para serviço incorreto (i.e., um que não implementa a especificação do sistema). A restauração do serviço é o evento que faz o serviço de um sistema retornar ao estado de serviço correto.
Serviço Correto
Serviço Incorreto
Defeito
Restauração do Serviço
Transição de estados em um sistema devido à ocorrência de defeito.
O defeito só ocorre quando um erro existente no sistema alcança a interface do serviço e altera o serviço prestado. O erro é um estado indesejado do sistema , que pode vir a causar um defeito.
Desta forma, um sistema pode ter um ou mais erros e continuar apresentando serviço correto, ou seja, sem defeito. O tempo entre o surgimento de um erro e a manifestação do defeito é chamado de latência de erro e sua duração pode variar consideravelmente.
A falha é a causa do erro. Ela provoca no sistema uma transição de estado não planejada (indesejada) levando o mesmo para um estado de erro. Um sistema pode possuir uma ou mais falhas e não apresentar erros. Neste caso, a falha é chamada de latente.
Quando ela efetivamente produz um erro passa a ser chamada de falha ativa. O tempo entre o surgimento da falha e sua ativação (produção do erro) é chamado de latência de falha.
Os tipos de falhas e as suas origens são bastante variados. Um curto circuito em uma porta lógica é uma falha. A conseqüência (alteração do resultado da operação lógica) é um erro, que poderá ou não vir a causar um defeito. Uma pessoa que ao operar um sistema realiza um procedimento inapropriado gera uma falha. O resultado de sua ação é o erro, que pode ser a alteração de um dado (informação).
Como último exemplo, uma perturbação eletromagnética (e.g., um raio) pode ser uma falha se possuir energia suficiente para, por exemplo, alterar (por indução) uma informação que esteja trafegando em um cabo metálico. Neste caso o erro é a informação distorcida que chegará para o destinatário
Avizienis apresenta um sistema de classificação defalhas bastante abrangente, que está reproduzido na próxima figura.
Falhas
Causa Fenomenológica
Intenção
Domínio
Falhas naturais Falhas humanas
Fase de Criaçãoda Ocorrência
Fronteiras do Sistema
Persistência
Falhas acidentais Falhas deliberadas, não maliciosas Falhas deliberadamente maliciosas Falhas no desenvolvimento Falhas na produção Falhas operacionais Falhas físicas Falhas da informação Falhas internas Falhas externas Falhas permanentes Falhas transientes
Classes de falhasClasses de falhas
Confiabilidade
Probabilidade R( t ) de um sistema apresentar serviço correto continuadamente durante um intervalo de tempo t , dado que o mesmo apresentava serviço correto em t =0. Em outras palavras, é a probabilidade do sistema não apresentar defeito durante o intervalo de tempo considerado.
Seja X o tempo para o sistema apresentar defeito, ou seja, a duração da “vida” de um sistema. X pode ser considerada como uma variável aleatória contínua, pois seu valor não pode ser previsto a partir de um modelo deteminístico. Na análise de sistemas computacionais, segundo alguns autores, a variável X possui função de distribuição exponencial. A probabilidade apresentada acima pode então ser expressa da seguinte forma:
t
Rt PX t e
− λ
Probabilidade R(t).
O parâmetro λ é chamado de taxa de defeito do sistema e possui valor constante (devido à propriedade de ausência de memória da distribuição exponencial, que desconsidera o desgaste do sistema).
Outra forma muito comum de se expressar à confiabilidade de um sistema é pelo cálculo do seu tempo médio para a ocorrência de defeito , ou MTTF ( Mean Time To Fail ), que corresponde ao tempo de vida esperado do sistema: λ
1 MTTF = E [ X ]=
Tempo médio para a ocorrência de defeito
A expressão anterior fornece o MTTF de um sistema, trabalhando isoladamente.
De maneira geral, contudo, um sistema é composto por componentes que, por sua vez, podem ser considerados (sub)sistemas compostos por componentes e assim sucessivamente.
Desta forma, a confiabilidade de um sistema depende da confiabilidade de seus componentes. Vamos analisar, então, o MTTF de dois sistemas básicos a partir do MTTF de seus componentes.
Consideremos primeiramente um sistema formado por n componentes ligados em série. Neste caso, o sistema apresentará defeito caso algum de seus componentes apresente defeito. A probabilidade R(t) para este sistema fica da seguinte forma:
t n
R t R t R t R t e ( n )
1 2
()= ()× ()×Λ× ()= −λ^1 +λ^2 +Λ+^ λ
Probabilidade R(t) para um sistema em série
E desta maneira, seu MTTF é expresso pela equação abaixo:
∑
= n
i
i
MTTFsérie
1
Tempo médio para a ocorrência de defeito em um sistema em série.
Da equação podemos concluir que a confiabilidade de um sistema em série é menor que a confiabilidade de qualquer um de seus componentes.
Consideremos agora um sistema formado por n componentes ligados em paralelo e que, desta forma, o sistema apresentará defeito somente quando todos os componentes apresentarem defeito. A probabilidade R(t) deste sistema é expressa da seguinte forma :
∏^ [^ ]
=− −
n
i
R t Ri t 1
() 1 1 ()
Probabilidade R(t) para um sistema em paralelo
Assumindo que todos os componentes possuam confiabilidade com distribuição exponencial e mesmo parâmetro λ, a fórmula acima fica equivalente a:
[ ] tn
R ( t )= 1 − 1 − e −^ λ
Probabilidade R(t) para um sistema em paralelo, com distribuição exponencial e parâmetro λ.
Neste sentido, definimos a disponibilidade α de um sistema como o limite de A( t ) quando t tende a infinito (formalmente chamado de limite da disponibilidade ).
lim A ( t ) t →+∞
α=
Disponibilidade de um sistema.
Utilizando o tempo médio para a ocorrência de defeito ( MTTF ), apresentado anteriormente, e o
tempo médio para reparo ( MTTR , Mean Time To Repair ),
podemos exprimir a disponibilidade α como sendo
MTTF MTTR
MTTF
Disponibilidade em função do MTTF e do MTTR
Segurança (contra catástrofes)
É a probabilidade S 1 ( t ) de um sistema não apresentar defeito que acarrete conseqüências catastróficas contra os usuários ou contra o meio ambiente, em um intervalo de tempo t.
Confidencialidade
Probabilidade C( t ) de não ocorrer divulgação não autorizada de informação, em um intervalo de tempo t.
Integridade Probabilidade I( t ) de não ocorrer alterações impróprias de estado em um sistema, em um intervalo de tempo t.
Reparabilidade
Probabilidade M( t ) de um sistema estar restaurado (retornar ao estado de serviço correto) no tempo t, dado que o mesmo apresentou defeito em t =0. Em outras palavras, é a capacidade que um sistema tem de passar por reparos e modificações.
Segurança (security)
Além dos atributos mencionados acima, citamos também o da segurança, que é um atributo obtido através da combinação de três outros:
- disponibilidade, para usuários autorizados; b) confidencialidade; e c) integridade, com “impróprio” significando “não autorizado”.
Segurança pode ser definida como a probabilidade S 2 ( t ) de que não ocorra acesso ou manipulação indevidos no estado do sistema, em um intervalo de tempo t.
Os Meios para se Alcançar a Dependabilidade
A fim de se desenvolver um sistema dependável, é necessário o emprego combinado de quatro técnicas:
- a prevenção de falhas (que permite prevenir a introdução ou ocorrência de falhas);
- a tolerância a falhas (que permite que seja apresentado serviço correto na presença de falhas);
- a remoção de falhas (que permite reduzir o número ou a severidade das falhas); e
•a previsão de falhas (que permite estimar a quantidade atual, a incidência futura, e as prováveis conseqüências das falhas).
Prevenção de Falhas
Na prevenção de falhas o objetivo é aumentar a confiabilidade dos sistemas através, basicamente, do emprego de técnicas de controle da qualidade nas etapas de projeto e desenvolvimento dos mesmos.
Uma vez que não há como, através da prevenção, eliminar todas as falhas possíveis (e.g., falhas de operação do sistema, fim da vida útil de componentes, etc.) e pelo fato desta técnica não fazer uso de redundância, é assumido que, eventualmente, irão ocorrer defeitos no sistema.
Desta forma, são previstos procedimentos manuais de reparo a fim de restaurar o sistema à condição de serviço correto.
Isto faz com que a prevenção de falhas, por si só, seja insuficiente para alguns sistemas atingirem a dependabilidade desejada devido, principalmente, às seguintes conseqüências: a interrupção do serviço (para reparos) pode estender-se por períodos de tempo inaceitáveis para os usuários do mesmo (e.g., sistemas de tempo real); para o reparo manual, há necessidade de se ter acesso ao sistema, o que nem sempre é possível (e.g., naves automatizadas de exploração do espaço); o reparo pode representar um custo elevado (e.g., sistema bancários, de defesa, de suporte à vida).
A fim de minimizar estas conseqüências pode-se complementar o uso da prevenção de falhas com o emprego da tolerância a falhas, que é uma técnica que faz uso da redundância para substituir o reparo manual do sistema pelo reparo e reconfiguração automatizados, o que aumenta a confiabilidade e a disponibilidade do sistema.
Tolerância a Falhas
Tolerância à falhas é a habilidade que um sistema tem de apresentar um comportamento muito bem definido na ocorrência de falhas ativas.
Este comportamento apresentado pode ser dividido em quatro grandes categorias ou formas de tolerância à falhas, de acordo com o atendimento ou não do que considera ser duas das propriedades comportamentais principais dos sistemas:
- a segurança contra catástrofes (safety); e •a “vitalidade” (liveness), no sentido de permanecer ou não operacional.
Segurança garantida
Mascaramento Defeito seguro (fail safe)
Segurança não garantida
Sem mascaramento
Não tolerância
Propriedades do Sistema
Operacionalidade garantida
Operacionalidade não garantida
Formas básicas de tolerância à falhas
Classificação da redundância em sistemas tolerantes à falhas.
As duas formas de redundância na estrutura se baseiam na replicação de partes componentes de um sistema (ou até no sistema como um todo).
As réplicas podem ser idênticas (em sua constituição) ou não, mas sempre possuem a mesma função. Segundo alguns pesquisadores é a única forma de redundância capaz permitir a tolerância de falhas permanentes.
A utilização de duas ou mais versões de um mesmo algoritmo, programados de forma independente, para comparação das saídas e escolha (por maioria) do resultado correto – técnica conhecida como N-version programming – é um exemplo de redundância na estrutura baseada em software.
Sua contrapartida em hardware, onde ao invés de versões de um mesmo algoritmo temos cópias de um mesmo módulo de hardware, é chamada de N-modular redundancy (NMR).
Nem sempre é necessário duplicar um módulo inteiro para se obter tolerância à falhas. Às vezes, a utilização da redundância na informação pode ser suficiente. A técnica pela qual é mais comumente empregada se baseia na aplicação da teoria dos códigos corretores de erro, que acrescentam informação redundante ao conteúdo original de forma a permitir a detecção e a correção de erros. Como exemplos desta técnica podemos citar os códigos de paridade, de CRC ( Cyclic Redundancy Check ) e de checksum ( SUMmation CHECK ).
Por fim, pode-se ainda lançar mão da redundância no tempo, na qual a mesma atividade é repetida uma ou mais vezes.
As repetições baseiam-se no pressuposto de que a causa do problema é de natureza temporária.
E de fato, como já foi provado, a utilização da redundância no tempo mostra-se mais adequada para detectar erros que resultem da ocorrência de falhas transientes. Um exemplo desta forma de redundância é a retransmissão de mensagens que ocorre em protocolos de comunicação (como o TCP) quando o remetente da mensagem deixa de receber a confirmação do recebimento pelo destinatário.
Vimos até agora que no projeto de um sistema tolerante a falhas é necessário definir as falhas que serão toleradas e o comportamento desejado para o sistema na ocorrência delas.
Vimos também que tornar um sistema tolerante a falhas implica no emprego de pelo menos uma das formas de redundância apresentadas.
Agora veremos quais são as atividades normalmente desenvolvidas pelos sistemas na implementação da tolerância à falhas.
O ponto de partida é a detecção de erros. Isto é devido ao fato de que a ocorrência de falhas não pode ser observada diretamente e, sendo assim, tem de ser deduzida a partir da presença de erros [Jalote].
Como os erros são uma propriedade do estado do sistema, existem testes que podem ser conduzidos a fim de se provar a existência ou não deles.
Em conseqüência, um esquema de tolerância a falhas será tão eficaz quanto for o seu mecanismo de detecção de erros.
De acordo com [Jalote], o teste ideal para se detectar a presença de erros deve satisfazer três importantes propriedades: primeiro, o teste não deve ser influenciado pela implementação do sistema, devendo basear-se apenas na especificação do mesmo; segundo, deve ser completo e correto, devendo identificar todos os erros de fato existentes; por último, o teste deve possuir independência do sistema com relação à ocorrência de falhas, caso contrário a falha que acarreta um erro no sistema pode vir a causar um erro também no teste.
No mundo real, infelizmente, estas propriedades são muito difíceis de serem satisfeitas.
Desta forma, ao invés de testes ideais, normalmente são empregados testes de aceitação , que são aproximações dos testes ideais.
Neste caso, não há garantias de que os testes realizados vão ser capazes de detectar todos os erros existentes.
Depois de detectado o erro, é necessário realizar a recuperação do sistema , a fim de levá-lo de volta a um estado onde não haja erros detectados e nem falhas que possam ser ativadas, vindo a causar erros novamente. A recuperação, desta forma, consiste de duas ações: o tratamento dos erros e o tratamento das falhas.
O tratamento dos erros ( error handling ) visa colocar o sistema de novo em um estado correto. Ele pode atuar de duas formas: rollback , que leva o sistema de volta a um estado anterior, identificado como correto, a partir de algum dos checkpoints (gravações periódicas do estado do sistema) que possua; rollforward , que leva o sistema a um estado novo, no qual ainda não esteve, sem erros detectáveis.
Já o tratamento das falhas ( fault handling ) tem por objetivo impedir que as falhas por ventura localizadas venham a ativar-se novamente, causando erros outra vez. Para atingir seu objetivo, o tratamento das falhas se divide em quatro etapas: o diagnóstico das falhas , que localiza e identifica o tipo da(s) causa(s) do(s) erro(s); o isolamento das falhas , que realiza a exclusão (física ou lógica) dos componentes (diagnosticados com falhas) da participação no serviço do sistema; a reconfiguração do sistema , que realiza a ativação de um componente em reserva ou a redistribuição de tarefas entre os componentes restantes; e a reinicialização do sistema , que verifica, atualiza e grava a nova configuração do sistema.
