1 / 42

9. Confiabilidade 9.1. Conceitos Básicos

9. Confiabilidade 9.1. Conceitos Básicos. Noção de Falha e Falta. Falta Um desvio interno no comportamento do sistema que, teoricamente, não deveria acontecer. E.g. divisão por zero, ficheiro não presente, quebra de uma ligação a uma base-de-dados, etc. Falha

vivek
Télécharger la présentation

9. Confiabilidade 9.1. Conceitos Básicos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 9. Confiabilidade9.1. Conceitos Básicos

  2. Noção de Falha e Falta • Falta • Um desvio interno no comportamento do sistema que, teoricamente, não deveria acontecer. • E.g. divisão por zero, ficheiro não presente, quebra de uma ligação a uma base-de-dados, etc. • Falha • Quanto uma falta se torna observável nas fronteiras do sistema • E.g. um “crash” devido à divisão por zero, inexistência de um ficheiro ou quebra da ligação à base-de-dados Componente onde ocorre uma falta: esta pode ou não torna-se observável Fronteira observável do sistema

  3. Objectivo da Tolerância a Falhas (... FALTAS) • Tipicamente utiliza-se “duplicação” para tolerar as faltas. • Atenção: a “Falha de um” pode ser a “Falta de outro”... • Replicação: • Utilizar múltiplas instâncias, idênticas, que realizam as mesmas tarefas. O resultado correcto é escolhido com base em quorum. E.g. Sistema de votação nos computadores de controlo do voo de um avião. • Redundância: • Utilizar múltiplas instâncias, transferindo o trabalho para uma das restantes em caso de falha. E.g. Backup Server. • Diversidade: • Utilizar diferentes implementações da mesma especificação, utilizando-as como um sistema replicado, de forma a lidar com os problemas de uma instância em particular. «O objectivo da Tolerância a Falhas* é “mascarar” as faltas por forma a que não se transformem em falhas» * Correctamente, em Português, deverá dizer-se tolerância a faltas, apesar de não ser esse o termo de “uso comum”...

  4. Exemplo de Replicação: Redundância Modular Tripla A Votador A A Tarefa B

  5. Exemplo de Redundância: RAID RAID 1 A A

  6. Exemplo de Diversidade • Redundância Modular Tripla • Em que cada versão do software/sistema é diferente.

  7. Desenvolvimento de Software • Uma das principais causas do software ser “não confiável” é o SOFTWARE, não o HARDWARE! (visão de 1994...)

  8. Outro Exemplo... “The Mars Climate Orbiter Spacecraft was lost because one NASA team used Imperial units while another used metric units for a key spacecraft operation” (BBC Online Report, 1999/09/30) Mars Climate Orbiter, crashed into Mars on Sep 23, 1999 Cost  US$125 million dollars

  9. Ainda mais um exemplo... Mars Path Finder

  10. The Mars PathFinder Problem • Priority Inversion Problem (in Mars Path Finder): • Low priority thread locks a semaphore. • High priority thread starts to execute and tries to lock the same semaphore. It’s suspended since it cannot violate the other thread lock. • Medium priority threads comes to execute and preempts the low priority one. Since it doesn’t need the semaphore, it continues to execute. • Meanwhile the high priority one is starving. After a while, a watchdog timer detects that the high priority one is not executing and resets the machine. tries to get the lock and is suspended watchdog timer resets the machine as the high priority one doesn’t get to execute starts to execute A B C continues to execute starts to execute and gets the lock is preempted as medium priority gets to execute

  11. Leitura MUITO Interessante...

  12. Disponibilidade • Disponibilidade: • Percentagem do tempo em que o sistema está em operação e em capacidade de realizar as operações que se esperam dele (e.g. atender pedidos de clientes). MTBF = Mean Time Between Failures MTTR = Mean Time to Repair

  13. 9999’s

  14. Combinação de Sistemas: Em série... • A disponibilidade do conjunto é sempre inferior à disponibilidade dos sistemas individuais!!! • Exemplo: • Disponibilidade(A) = 99% [3.65 dias/ano] • Disponibilidade(B) = 99% [3.65 dias/ano] • Disponibilidade Total = 98% [7.26 dias/ano] X Y

  15. Combinação de Sistemas: Em paralelo... X Y (i.e. 1 – a probabilidade de ambas as partes não estarem disponíveis) • A disponibilidade do conjunto é sempre superior (em muito) à disponibilidade dos sistemas individuais!!! • Exemplo: • Disponibilidade(A) = 99% [3.65 dias/ano] • Disponibilidade(B) = 99% [3.65 dias/ano] • Disponibilidade Total = 99.96% [3.5 horas/ano!!!]

  16. 9. Confiabilidade9.2. Algumas Técnicas

  17. Algumas falhas comuns em sistemas informáticos • Falha do disco rígido • Falha da fonte de alimentação • Falha da memória • Falha de rede / Quebra de Ligação • “Envelhecimento do Software” E, infelizmente...  Erros do Operador/Utilizador  Erros de Software (Programação)

  18. Suporte de Hardware Utilização de RAID / Disk Arrays... • E.g. RAID 1, RAID 3, RAID 5 • Muitas vezes, hot-swappable

  19. Suporte de Hardware (2) Utilização de fontes redundantes... Utilização de UPS

  20. Suporte de Hardware (3) Utilização de memória “registada” Utilização de memória com correcção de erros (ECC) • Requisito em arquitecturas com Intel XEON

  21. Falhas de Rede / Quebra de Ligação Utilização de Interfaces Redundantes “Re-tentativas de ligação antes de falhar” NIC-1 NIC-1 NIC-2 NIC-2 NIC-1 NIC-1 NIC-2 NIC-2

  22. O Software Também Envelhece... • IMENSAS causas... • Memory Leaks • Graphic Handler Leaks • Global Process Table Entry Leaks • Shared-memory leaks • Thread handler leaks • ... Mesmo com software correctamente programado isso acontece: - Instalação de versões incompatíveis de software / “upgrades” - Alteração de bibliotecas - ...

  23. Rejuvenescimento de Software • Quando o sistema está num momento “adequado”, fazer uma re-inicialização: • A um módulo... • Da aplicação... • Do sistema operativo como um todo... • ... até mesmo da instalação! • Pode ser necessário guardar os dados da aplicação antes de fazer a sua re-inicialização • Pode ser necessário re-direccionar a carga para outras máquinas

  24. LOAD SHARING Existe um load-balancer que distribui a carga por várias máquinas As máquinas partilham a carga; se uma das máquinas for abaixo, as restantes mantêm o sistema em funcionamento Tipicamente, os servidores falam com um ou mais servidores de base-de-dados ou têm acesso a um conjunto de discos partilhados (e.g. uma SAN) Configurações típicas... Load Balancer

  25. PRIMARY / ACTIVE BACKUP Existe um servidor primário e um backup. Apenas o primário trata dos pedidos. Periodicamente, o primário envia um “I’m alive” ao secundário Caso o backup não receba uma mensagem “I’m alive” no tempo correcto, executa um protocolo de eleição No caso de duas máquinas, elege-se a si próprio... Problema de “split-brain”! Tem de existir uma forma de redireccionar os pedidos para a máquina backup E.g. toma conta do IP, redireccionamento a nível do DNS, redireccionamento a nível dos clientes, etc. O backup tem de ter acesso a toda a informação necessária para o processamento Enviada pelo primário Acesso aos mesmos discos/serviços Configurações típicas (2)... I’m alive “No caso de um COOL BACKUP, a inicialização/ configuração será manual (... em diferentes gradações...)

  26. Watch-Dog Timer / Checkpointing & Restart • Mecanismo de re-inicialização de componentes falhadas • Existe um timer que é constantemente decrementado • Uma componente de software periodicamente faz a sua re-inicialização • Caso a aplicação “empanque”, não é feita a realização, sendo activado um reset na máquina (ou do processo) • Suportado a nível de software ou hardware • Checkpointing & Restart • Em muitos casos as aplicações escrevem periodicamente o seu estado para disco • Caso a aplicação empanque, é possível fazer-lhe um reset, começando o processamento do ponto onde se encontrada • O re-iniciar pode ser manual ou via watch-dog timer • Nos sistemas empresariais, as bases-de-dados assumem o papel do “API de checkpointing” • Na verdade, as estruturas “undo-log” e “redo-log” são exactamente isso!

  27. Muitas vezes... Heart-beats e, eventualmente, informação de estado/sincronização cross cable NIC-1 NIC-1 NIC-2 NIC-2 Rede de “operação” Em sistemas “High Availability” é comum utilizarem-se duas ligações de heart-beat...

  28. 9. Confiabilidade9.3. O mundo real...

  29. Google • Cluster da GOOGLE • Tem de servir 1000 queries/segundo, cada query não demorando mais de 0.5s! • 8 biliões de páginas indexadas (8.058.044.651, 01/Maio/2005) • Técnica para manter a indexação: Tabelas Invertidas (ver TC/BD) • Todas as páginas são revisitadas mensalmente • Máquinas do cluster GOOGLE • PCs “baratos” com processadores Intel, c/ 256MB RAM • Cerca de 6.000 processadores, 12.000 discos (1 PByte de espaço, 2 discos por máquina) • Linux Red Hat • 2 sites na Califórnia e 2 na Virgínia • Ligação à rede • Cada site tem uma ligação OC48 (2.5 Gbps) à Internet • Entre cada par de sites existe um link de backup de OC12 (622 Mbps)

  30. Racks e Racks No google, a aborgagem à redundância é utilizar um conjunto maciço de máquinas completas! 40 PCs/rack 40 Racks

  31. Disponibilidade Computer Organization and Design, 3rd Ed, Capítulo 9D. Patterson & J. Hennessy, Morgan Kaufmann, ISBN 1-55860-604-1, 2004

  32. Disponibilidade (2)

  33. Why do Internet Services Fail?

  34. Caracteristicas dos Serviços

  35. Arquitectura Global • Utilização de sites geograficamente dispersos • Utilização de redirecção de DNS num caso e “cooperação do cliente” nos outros Load Balancing Tier Stateless Front-end Tier Back-end Data Tier

  36. As implementações...

  37. As implementações (2)...

  38. A parte interessante...

  39. Resultados Globais...

  40. Resultados Globais (2)

  41. Bibliografia • “Reliability and Availability Basics” • http://www.eventhelix.com/RealtimeMantra/FaultHandling/reliability_availability_basics.htm • “System Reliability and Availability” • http://www.eventhelix.com/RealtimeMantra/FaultHandling/system_reliability_availability.htm • “RAID Levels” • http://www.acnc.com/04_01_00.html • Computer Organization and Design, 3rd Ed.D. Patterson & J. HennessyMorgan Kaufmann, ISBN 1-55860-604-1 August 2004 • Secção 9.8: GOOGLE! • D. Oppenheimer, A. Ganapathi, D. Patterson, "Why do Internet services fail, and what can be done about it?", in Proc. of the 4th USENIX Symposium on Internet Technologies and Systems (USITS'03), 2003 • D. Costa, J. Carreira, J. G. Silva, ARTIGO - "WinFT: Using Off-the-Shelf Computers on Industrial Environments", in Proc. 6th International Conference on Emerging Technologies and Factory Automation (ETFA '97), IEEE Press, 1997

  42. Bibliografia (2) • Blueprints for High Availability, 2nd Ed. by Evan Marcus, Hal Stern • Wiley, ISBN 0471430269, Sep/2003

More Related