Lista de exercícios 8 - Respostas

Prévia do material em texto

Sistemas Distribuídos 
Prof. Fábio M. Costa 
Aluno: Orlando da Cruz Pereira Júnior 
 
Lista de Exercícios 8 
 
1. Qual a diferença entre disponibilidade (availability) e confiabilidade (reliability). Dê 
exemplos. 
 
Disponibilidade é definida como a propriedade que um sistema está pronto para ser utilizado 
de imediato. Em geral, refere-se a probabilidade de que o sistema está operando 
corretamente a qualquer momento e está disponível para desempenhar as suas funções em 
nome de seus usuários. Em outras palavras, um sistema altamente disponível é aquele que 
provavelmente vai estar trabalhando em um dado instante no tempo. 
 
Confiabilidade refere-se à propriedade de que um sistema pode funcionar continuamente sem 
falhas. Em contraste com a disponibilidade, a confiabilidade é definida em termos de um 
intervalo de tempo, em vez de um instante no tempo. Um sistema altamente confiável é 
aquele que provavelmente irá continuar a trabalhar sem interrupção durante um período 
relativamente longo de tempo. Esta é uma diferença sutil, mas importante quando comparado 
à disponibilidade. Se um sistema desce em média, para um milissegundo, aparentemente, tem 
uma disponibilidade de mais de 99,9999 por cento, mas ainda não é confiável. Da mesma 
forma, um sistema que não cai, mas é desligado por duas semanas em agosto tem alta 
confiabilidade, mas a disponibilidade apenas 96 por cento. Os dois não são o mesmo. 
 
2. Defina tolerância a falhas. 
 
Ser tolerante a falhas está fortemente relacionado aos chamados sistemas confiáveis. 
Confiabilidade é um termo que abrange uma série de requisitos úteis para sistemas 
distribuídos, incluindo os seguintes [Kopetz e Veríssimo, 1993]: 
• Disponibilidade 
• Confiabilidade 
• segurança 
• Manutenção 
 
3. Por que a detecção de falhas seria mais simples em sistemas distribuídos síncronos? Quais 
os requisitos para que esse tipo de sistema seja possível? Isso seria possível na Internet? 
 
Em um sistema assíncrono, há suposições sobre velocidades de execução de processo ou os 
prazos de entrega de mensagens são feitas. A consequência disso é que quando o processo de 
P já não percebe nenhuma ação de Q, não se pode concluir que Q caiu. Em vez disso, só ele 
pode ser lento ou suas mensagens podem ter sido perdidas. 
Em um sistema síncrono, velocidades de execução de processo e tempos mensagem de 
entrega são delimitadas. Isto também significa que, quando Q não mostra mais atividade 
quando espera-se a fazê-lo, o processo P pode legitimamente concluir que Q caiu. 
 
4. Defina e dê exemplos dos cinco tipos de falhas descritos na Tabela 8.2 (pág. 428). 
 
Crash failure (Falha acidental) 
Uma Crash failure ocorre quando um servidor para prematuramente, mas estava funcionando 
corretamente até que parou. Um aspecto importante é que uma vez que o servidor foi 
interrompido, não se vê mais nada. Um exemplo típico de uma falha de acidente é um sistema 
operacional que vem a uma parada, e para o qual existe apenas uma solução: reiniciá-lo. 
Muitos sistemas de computadores pessoais sofrem de falhas com tanta frequência que as 
pessoas passaram a esperar que eles sejam normais. 
 
omission failure (Falha de omissão) 
receive-omission failure: 
Uma falha de omissão ocorre quando um servidor não responde a uma solicitação. Várias 
coisas podem dar errado. Possivelmente o servidor nunca recebeu a solicitação em primeiro 
lugar. Observe que pode muito bem acontecer que a conexão entre um cliente e um servidor 
tenha sido estabelecida corretamente, mas que não houvesse nenhum segmento ouvindo 
solicitações recebidas. Além disso, essa falha geralmente não afetará o estado atual do 
servidor, pois o servidor não está ciente de qualquer mensagem enviada a ele. 
 
send-omission failure: 
Da mesma forma, uma falha de omissão de envio acontece quando o servidor fez seu trabalho, 
mas de alguma forma falha no envio de uma resposta. Tal falha pode acontecer, por exemplo, 
quando um buffer de envio estourar enquanto o servidor não estava preparado para tal 
situação. Como conseqüência, se o envio de sua resposta falhar, o servidor deve estar 
preparado para o cliente reemitir sua solicitação anterior. 
 
Timing failures (falhas de temporização) 
Outra classe de falhas está relacionada ao tempo. As falhas de temporização ocorrem quando 
a resposta está fora de um intervalo de tempo real especificado. Por exemplo, no caso de 
streaming de vídeo, o fornecimento de dados em breve pode causar problemas para um 
destinatário se não houver espaço suficiente no buffer para armazenar todos os dados 
recebidos. Mais comum, no entanto, é que um servidor responde muito tarde e, nesse caso, 
ocorre uma falha de desempenho. 
 
Response failure (falha na resposta) 
Um tipo grave de falha é uma falha na resposta, pelo qual a resposta do servidor é 
simplesmente incorreto. Dois tipos de falhas de resposta podem acontecer. No caso de uma 
falha de valor, um servidor simplesmente fornece a resposta errada a um pedido. Por 
exemplo, um motor de busca que retorna sistematicamente páginas Web não relacionadas 
com qualquer um dos termos de busca utilizados. 
 
State-transition failure (falha de transição de estado) 
O outro tipo de falha de resposta é conhecida como uma falha de transição de estado. Este 
tipo de falha acontece quando o servidor reage de forma inesperada para uma solicitação de 
entrada. Por exemplo, se um servidor recebe uma mensagem que não pode reconhecer, uma 
falha de transição de estado acontece se não foram tomadas medidas para lidar com essas 
mensagens. Em particular, um servidor com defeito incorretamente pode tomar ações padrão 
que nunca deveria ter iniciado. 
 
Arbitrary failures (falhas arbitrárias) 
O mais grave são as falhas arbitrárias, também conhecidas como falhas bizantinas. Com efeito, 
quando ocorrem falhas arbitrárias, os clientes devem estar preparados para o pior. Em 
particular, pode acontecer que um servidor que se encontra em produção e nunca deveria ter 
produzido, mas que não pode ser detectado como sendo incorreto. Falhas bizantinas foram 
primeiro analisadas por Pease et al. [1980] e Lamport et al. [1982]. 
 
5. Quais destas falhas podem ser tratadas e como? 
 
send-omission failure: 
Pode- se retransmitir a mensagem. 
 
Crash failure (Falha acidental) 
Revisões periódicas e atualização do sistema. 
 
6. Discuta o uso de redundância para o mascaramento de falhas. 
 
Se um sistema deve ser tolerante a falhas, o melhor que pode fazer é tentar ocultar a 
ocorrência de falhas de outros processos. A principal técnica para mascarar falhas é usar 
redundância. Três tipos são possíveis: redundância de informações, redundância de tempo e 
redundância física (ver também Johnson [1995]). Com redundância de informações, bits extras 
são adicionados para permitir a recuperação de bits distorcidos. Por exemplo, um código 
Hamming pode ser adicionado aos dados transmitidos para se recuperar do ruído na linha de 
transmissão. 
 
Com a redundância de tempo, uma ação é executada e, se necessário, é executada 
novamente. As transações usam essa abordagem. Se uma transação for anulada, ela poderá 
ser refeita sem danos. Outro exemplo bem conhecido é retransmitir uma solicitação para um 
servidor quando falta uma resposta esperada. A redundância de tempo é especialmente útil 
quando as falhas são transitórias ou intermitentes. 
 
Com a redundância física, equipamentos ou processos extras são adicionados para possibilitar 
que o sistema como um todo tolere a perda ou o mau funcionamento de alguns componentes. 
A redundância física pode, assim, ser feita em hardware ou em software. Por exemplo, 
processos extras podem ser adicionados ao sistema para que, se um pequeno número deles 
falhar, o sistema ainda funcione corretamente. Em outras palavras, replicando processos, um 
alto grau de tolerância a falhas pode ser alcançado.