Integração de Sistemas Paulo Marques Departamento de Eng. Informática Universidade de Coimbra 2008/2009 9. Confiabilidade 9.1. Conceitos.

Apresentação em tema: "Integração de Sistemas Paulo Marques Departamento de Eng. Informática Universidade de Coimbra 2008/2009 9. Confiabilidade 9.1. Conceitos."— Transcrição da apresentação:

1 Integração de Sistemas Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2008/2009 9. Confiabilidade 9.1. Conceitos Básicos

2 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 Fronteira observável do sistema Componente onde ocorre uma falta: esta pode ou não torna-se observável

3 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 4 Exemplo de Replicação: Redundância Modular Tripla Tarefa Votador A A B A

5 5 Exemplo de Redundância: RAID AA RAID 1

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

7 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 8 Outro Exemplo... Mars Climate Orbiter, crashed into Mars on Sep 23, 1999 Cost US$125 million dollars 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)

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

10 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. Its suspended since it cannot violate the other thread lock. Medium priority threads comes to execute and preempts the low priority one. Since it doesnt 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. A B C starts to execute and gets the lock starts to execute tries to get the lock and is suspended continues to execute is preempted as medium priority gets to execute watchdog timer resets the machine as the high priority one doesnt get to execute

11 11 Leitura MUITO Interessante...

12 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 13 9999s

14 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] XY

15 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 Integração de Sistemas Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2008/2009 9. Confiabilidade 9.2. Algumas Técnicas

17 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 18 Suporte de Hardware Utilização de RAID / Disk Arrays... E.g. RAID 1, RAID 3, RAID 5 Muitas vezes, hot-swappable

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

20 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 21 Falhas de Rede / Quebra de Ligação Utilização de Interfaces Redundantes Re-tentativas de ligação antes de falhar NIC-1 NIC-2 NIC-1 NIC-2 NIC-1 NIC-2 NIC-1 NIC-2

22 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 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 24 Configurações típicas... 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) Load Balancer

25 25 Configurações típicas (2)... PRIMARY / ACTIVE BACKUP Existe um servidor primário e um backup. Apenas o primário trata dos pedidos. Periodicamente, o primário envia um Im alive ao secundário Caso o backup não receba uma mensagem Im 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 Im alive No caso de um COOL BACKUP, a inicialização/ configuração será manual (... em diferentes gradações...)

26 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 27 Muitas vezes... NIC-1 NIC-2 NIC-1 NIC-2 cross cable Rede de operação Heart-beats e, eventualmente, informação de estado/sincronização Em sistemas High Availability é comum utilizarem-se duas ligações de heart-beat...

28 Integração de Sistemas Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2008/2009 9. Confiabilidade 9.3. O mundo real...

29 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 30 Racks e Racks 40 PCs/rack 40 Racks No google, a aborgagem à redundância é utilizar um conjunto maciço de máquinas completas!

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

32 32 Disponibilidade (2)

33 33 Why do Internet Services Fail?

34 34 Caracteristicas dos Serviços

35 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 36 As implementações...

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

38 38 A parte interessante...

39 39 Resultados Globais...

40 40 Resultados Globais (2)

41 41 Bibliografia Reliability and Availability Basics http://www.eventhelix.com/RealtimeMantra/FaultHandling/reliability_av ailability_basics.htm http://www.eventhelix.com/RealtimeMantra/FaultHandling/reliability_av ailability_basics.htm System Reliability and Availability http://www.eventhelix.com/RealtimeMantra/FaultHandling/system_relia bility_availability.htm http://www.eventhelix.com/RealtimeMantra/FaultHandling/system_relia bility_availability.htm RAID Levels http://www.acnc.com/04_01_00.html Computer Organization and Design, 3rd Ed. D. Patterson & J. Hennessy Morgan 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 42 Bibliografia (2) Blueprints for High Availability, 2nd Ed. by Evan Marcus, Hal Stern Wiley, ISBN 0471430269, Sep/2003