Upload
internet
View
133
Download
10
Embed Size (px)
Citation preview
Integração deSistemas
Paulo MarquesDepartamento de Eng. InformáticaUniversidade de [email protected]
2008
/200
9
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
Fronteira observáveldo sistema
Componenteonde ocorre umafalta: esta podeou não torna-seobservável
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»
«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 denão ser esse o termo de “uso comum”...
4
Exemplo de Replicação: Redundância Modular Tripla
TarefaVotador
A
A
B
A
5
Exemplo de Redundância: RAID
A A
RAID 1
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...
Mars Climate Orbiter, crashed into Mars on Sep 23, 1999Cost 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
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.
A
B
C
starts toexecuteand getsthe lock
starts toexecute
tries to get the lock and is suspended
continuesto execute
is preempted asmedium prioritygets to execute
watchdog timer resets the machine as the high priorityone doesn’t get toexecute
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).
MTTRMTBF
MTBFidadeDisponibil
MTBF = Mean Time Between FailuresMTTR = 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
BA idadeDisponibilidadeDisponibilidadeDisponibil
15
Combinação de Sistemas: Em paralelo...
X
Y
)1()1(1 BA idadeDisponibilidadeDisponibilidadeDisponibil (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!!!]
Integração deSistemas
Paulo MarquesDepartamento de Eng. InformáticaUniversidade de [email protected]
2008
/200
9
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-2
NIC-1
NIC-2
NIC-1
NIC-2
NIC-1
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
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
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 “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
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...
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” é comumutilizarem-se duas ligações de heart-beat...
Integração deSistemas
Paulo MarquesDepartamento de Eng. InformáticaUniversidade de [email protected]
2008
/200
9
9. Confiabilidade9.3. O mundo real...
29
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
40 PCs/rack40 Racks
No google, a aborgagemà redundância é utilizar umconjunto maciço de máquinascompletas!
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