Baixe o app para aproveitar ainda mais
Prévia do material em texto
ARQUITETURA DE SISTEMAS DISTRIBUÍDOS Prof. Carlos Alves disciplinas@linuxconsult.com.br Tratamento de falhas Mundo ideal x Mundo real IDEAL Sistemas computacionais são totalmente confiáveis e cem por cento disponíveis REAL Confiabilidade e disponibilidade absolutas estão muito longe de serem alcançadas Equipamentos e serviços de Qualidade Falhas são inevitáveis Suas consequências podem ser evitadas Usuários e desenvolvedores devem arcar com o custo do emprego de técnicas de tolerância a falhas Preocupação com falhas Sistemas robustos Eram preocupação de sistemas críticos Aviões, sondas espaciais e controles industriais de tempo real Com a popularização de redes Aumento da dependência tecnológica Diversos serviços oferecidos Mercado Existe um mercado mundial que se preocupam com falhas Não só sistemas de tempo real mas também sistemas de missão crítica Empresas começam a investir em soluções de alta disponibilidade Mercado Exemplo Microprocessadores Intel 80x86, desde o i486, incorporam uma gama de recursos para tolerância a falhas Porém, pelo custo e pela carência de uma cultura de confiabilidade esses recursos não são plenamente aproveitados Em um sistema de computação Desejável ter confiabilidade e disponibilidade Defeitos podem levar a grandes catástrofes Controle de tráfego terrestre e aéreo Controle de usinas de geração de energia Manutenção de dados sigilosos sobre a vida e a finança de cidadãos e empresas Telecomunicação Transações comerciais internacionais de todo tipo Defeitos O software e os procedimentos de projetos cada vez mais complexos Muitas falhas Não adianta apenas ter um hardware de qualidade Muitos bugs em sistemas demoram a ser descobertos Defeitos na literatura Na guerra do Golfo em fevereiro de 1991 foram noticiado vários relatos de falhas em mísseis Em novembro de 1992 houve um colapso no sistema de comunicação do serviço de ambulâncias em Londres Em junho de 1993, durante dois dias, não foi autorizada nenhuma operação de cartão de crédito em toda a França Defeitos na literatura 28 de Julho de 1962: Falha na sonda Mariner 1. Um bug no software de vôo da sonda Mariner 1 provocou um desvio no curso pré-establecido (o foguete foi destruído); 1982: Explosão num gasoduto soviético; 1985-1987: Acelerador médico Therac-25; 1988-1996: Gerador de números aleatórios de Kerberos; 1993: Divisão de números com ponto flutuante no Pentium. Defeitos na literatura Várias missões da Nasa a Marte terminaram em fracasso total ou parcial Todos foram investigados Suas causas foram determinadas Não é garantido que algo semelhante possa voltar a ocorrer. Desafios atuais (1/7) Como evitar, detectar e contornar bugs no projeto de hardware e software? Desafios atuais (2/7) Como gerenciar a altíssima complexidade dos sistemas atuais de computação construídos com dezenas de chips de milhões de transistores e com software de centenas de milhares de linhas de código? Desafios atuais (3/7) Como explorar paralelismo para aumentar o desempenho sem comprometer a qualidade dos resultados, mesmo no caso de falha de um ou mais componentes do sistema? Desafios atuais (4/7) Como aproveitar novas tecnologias mais rápidas, baratas e eficientes (mas ainda não totalmente provadas e testadas) sem saber ainda seu comportamento em situações inesperadas sob falha ou sobrecarga? Desafios atuais (5/7) Como aproveitar, para aplicações críticas e para operação em tempo real, o modelo de sistemas distribuídos construídos sobre plataformas não confiáveis de redes, contornando os problemas de perdas de mensagens, particionamento de rede e intrusão de hackers? Desafios atuais (6/7) Como desenvolver computadores móveis e sistemas embarcados, garantindo confiabilidade e segurança nesses dispositivos, e assegurando simultaneamente baixo consumo de potência, sem recorrer a técnicas usuais de replicação de componentes que aumentam peso e volume? Desafios atuais (7/7) Finalmente, como conciliar alta confiabilidade e alta disponibilidade com as crescentes demandas por alto desempenho? Desafios atuais Todos esses desafios ainda permanecem sem uma solução definitiva. Falhas em Sistemas Distribuídos São falhas parciais: alguns componentes falham, enquanto outros continuam funcionando tratamento de falhas é particularmente difícil Falhas em Sistemas Distribuídos Conceitos A computação é recente Termos e conceitos Não estão consolidados Não são amplamente aceitos Falha x Erro x Defeito Falhas em Sistemas Distribuídos Esquema Falhas em Sistemas Distribuídos Falha A causa física ou algorítmica do erro São inevitáveis Componentes físicos Envelhecem Sofrem com interferências externas O software, os projetos de software e hardware, Alta complexidade Fragilidade humana Trabalha com grande volume de detalhes ou com deficiências de especificação Falhas em Sistemas Distribuídos Erro Interpretação incorreta de uma informação que leva a um defeito no sistema Falhas em Sistemas Distribuídos Defeito Definido como um desvio da especificação Não podem ser tolerados, mas deve ser evitado que o sistema apresente defeito São evitados quando tratamos falhas Falhas em Sistemas Distribuídos Exemplo Um chip de memória, que apresenta uma falha do tipo grudado-em-zero (stuck-at-zero) em um de seus bits (falha no universo físico), pode provocar uma interpretação errada da informação armazenada em uma estrutura de dados (erro no universo da informação) e como resultado o sistema pode negar autorização de embarque para todos os passageiros de um vôo (defeito no universo do usuário). Falhas em Sistemas Distribuídos Observar que uma falha não necessariamente leva a um erro (aquela porção da memória pode nunca ser usada) e um erro não necessariamente conduz a um defeito (no exemplo, a informação de vôo lotado poderia eventualmente ser obtida a partir de outros dados redundantes da estrutura). Latência de falha e de erro De falha Tempo da ocorrência da falha até a manifestação do erro devido àquela falha De erro Tempo desde a ocorrência do erro até a manifestação do defeito devido aquele erro Classificação de falhas Falhas físicas Falhas de componentes Falhas humanas Falhas de projeto e falhas de interação Causas de falhas o Problemas de especificação o Problemas de implementação o Componentes defeituosos o Imperfeições de manufatura o Fadiga dos componentes físicos o Distúrbios externos como radiação o Interferência eletromagnética o Variações ambientais (temperatura, pressão, umidade) o Problemas de operação Definindo uma falha Natureza Falha de hardware, falha de software, de projeto, de operação, e etc. Duração ou persistência Permanente ou temporária (intermitente ou transitória) Extensão Local a um módulo ou global Valor Determinado ou indeterminado no tempo Falhas humanas maliciosas Intenção de provocar danos ao sistema Tratadas por técnicas de segurança computacional TRATAMENTO DE FALHAS EM SISTEMAS DISTRIBUÍDOS Técnicas de tratamento (1/5) Detecção de falhas Algumas falhas podem ser detectadas Exemplos: Somas de verificação podem ser utilizadas para detectar dados danificados em uma mensagem ou em um arquivo Dois componentes idênticos e um comparador Técnicas de tratamento (2/5) Mascaramento de falhas Algumas falhas detectadas podem ser ocultas ou se tornar menos sérias Exemplos: mensagens podem ser retransmitidas quando não chegam; dados de arquivos podem ser gravados em dois discos, para que, se um estiver danificado, o outro ainda possa estar correto Técnicas de tratamento (3/5) Tolerância a falhas A maioria dos serviços na Internet apresenta falhas não é prático detectar e mascarar todos Clientes e usuários podem ser projetados para tolerarfalhas Exemplos: Quando um navegador não consegue contatar um servidor web, ele não faz o usuário esperar indefinidamente, ele informa o problema e deixa o usuário livre para tentar novamente Técnicas de tratamento (4/5) Recuperação de falhas Envolve projetar software de modo que o estado dos dados permanentes possa ser recuperado ou retrocedido, após a falha de um servidor Exemplos: Computações realizadas por alguns programas ficarão incompletas quando ocorrer uma falha e os dados permanentes que eles atualizam podem não estar em um estado consistente Técnicas de tratamento (4/5) Recuperação de falhas Técnicas de tratamento (5/5) Redundância Os serviços podem se tornar tolerantes a falhas com o uso de: Componentes redundantes Programação n-versões Blocos de recuperação Técnicas de tratamento (5/5) Redundância – Exemplos Sempre deve haver pelo menos duas rotas diferentes entre dois roteadores quaisquer na Internet No Domain Name System (DNS), toda tabela de correspondência de nomes é replicada em pelo menos dois servidores diferentes (Master e Slave) Técnicas de tratamento (5/5) Técnicas de tratamento (5/5) Redundância – Exemplos Um banco de dados pode ser replicado em vários servidores, para garantir que os dados permaneçam acessíveis após a falha de qualquer servidor. Os servidores podem ser projetados de forma a detectar falhas em seus pares; quando uma falha é detectada em um servidor, os clientes são redirecionados para os servidores restantes Próxima aula Classificação de Flynn
Compartilhar