Integração deSistemas

Paulo MarquesDepartamento de Eng. InformáticaUniversidade de Coimbrapmarques@dei.uc.pt

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 Coimbrapmarques@dei.uc.pt

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 Coimbrapmarques@dei.uc.pt

2008

/200

9

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

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