Sistemas Distribudos:

O que so?
uma coleo de computadores autnomos interconectados por uma rede,
com software projetado para produzir uma aplicao integrada.
Sincronizao:
A sincronizao entre processos to importante quanto comunicao entre
processos em sistemas distribudos. Por exemplo, como as regies crticas so
implementadas em um sistema distribudo e como estes recursos so
alocados?
Em sistemas de uma nica CPU, regies crticas, excluso mtua, e outros
problemas de sincronizao so geralmente resolvidos usando mtodos como
semforos e monitores. Estes mtodos no so recomendados para serem
usados em sistemas distribudos porque eles invariavelmente contam
(implicitamente) com a existncia de uma memria compartilhada. Por
exemplo, dois processos que esto interagindo usando um semforo, ambos
devem ser capazes de acessar o semforo. Se eles esto rodando na mesma
mquina, eles podem compartilhar o semforo tendoo armazenado no Kernel,
e executar chamadas de sistema (system calls) para acess-lo. Se, entretanto,
eles estiverem rodando em diferentes mquinas, este mtodo no mais
funcionar e outras tcnicas devem ser utilizadas. Mesmo parecendo
problemas simples, como determinar se o evento A aconteceu antes ou depois
do evento B, requer bastante cuidado.
Sincronizao de Relgio:
A sincronizao em sistemas distribudos mais complicada do que em
sistemas centralizados porque em sistemas distribudos necessrio utilizar
algoritmos distribudos. No usualmente possvel (ou desejvel) coletar todas
as informaes sobre o sistema em um nico lugar e depois deixar que alguns
processos examinemna e tomem uma deciso como feito no caso
centralizado.
Em geral, algoritmos distribudos possuem as seguintes propriedades:

a. A informao relevante est espalhada em mltiplas mquinas

b. Processos tomam decises baseadas somente nas informaes locais
c. Um nico ponto de falha no sistema deve ser evitado
d. No existe um relgio em comum ou outro tipo preciso de tempo global
Os primeiros trs pontos significa dizer que inaceitvel colecionar todas as
informaes em um nico local para o processamento. Por exemplo, para fazer
alocao de recursos, no aceitvel enviar todas as requisies para um
nico processo gerenciador, o qual examina as requisies e permite ou nega
as requisies baseadas nas informaes contidas em suas tabelas. Em
sistemas grandes, esta soluo coloca uma carga pesada neste nico
processo.
Alm do mais, tendo um nico ponto de falha como este torna o sistema no
confivel.
Idealmente, um sistema distribudo deve ser mais confivel do que as
mquinas individuais. Se uma mquina sair do ar, o restante deve ser capaz de
continuar funcionando.
Atingir a sincronizao sem centralizao requer fazer coisas de um modo
diferente dos sistemas operacionais tradicionais.
Nos sistemas centralizados, o tempo no ambguo. Quando um processo
quer saber o tempo, ele faz uma chamada ao sistema e o Kernel responde. Se
o processo A pergunta pelo tempo e ento o prximo processo B pergunta pelo
tempo, o valor de B ser maior (ou possivelmente) igual ao de A. Ele
certamente no ser menor. Em um sistema distribudo, atingir a concordncia
do tempo no trivial.
Em suma, a ordem de eventos que ocorrem em processos distintos pode ser
crtica em uma aplicao distribuda (ex: make, protocolo de consistncia de
rplicas). Em um sistema com n computadores, cada um dos n cristais ter
uma frequncia prpria, fazendo com que os n relgios percam seu
sincronismo gradualmente.
Relgios Lgicos:

Quase todos os computadores possuem um circuito para manterse a par do

tempo. O timer utilizado nos computadores geralmente produzido a partir de
cristal de quartzo. Quando mantido sob tenso, o cristal de quartzo oscila em
uma freqncia bem definida que depende do tipo de cristal, como cortado, e
a quantidade de tenso. Associado a cada cristal existem dois registros, um
counter e um holding register. Cada oscilao do cristal decrementa o counter
por um. Quando o counter chega a zero, uma interrupo gerada e o counter
recarregado pelo holding register. Deste modo, possvel programar o timer
para gerar uma interrupo 60 vezes por segundo, ou qualquer outra
freqncia desejada. Cada interrupo chamada clock tick.
Quando o sistema inicializado, ele usualmente pergunta ao operador para
entrar com a data e hora, o qual ento convertido para o nmero de ticks
depois da data conhecida e armazenada na memria. A todo clock tick, o
servio de interrupo adiciona uma unidade ao tempo armazenado na
memria. Deste modo, o software clock mantido atualizado.
Com um nico computador e um nico clock, no importa muito se este relgio
estiver um pouco fora do tempo. Desde que todos os processos na mquina
usem o mesmo relgio, eles ainda estaro internamente consistentes. Por
exemplo, se o arquivo input.c tem o tempo 2151 e o arquivo input.o tem o
tempo 2150, o make ir recompilar o arquivo fonte, mesmo se o relgio estiver
fora do tempo correto por 2 unidades de tempo sendo o tempo correto igual a
2153 e 2154, respectivamente.
Tudo o que realmente importa so os tempos relativos. Assim que mltiplas
CPUs so introduzidas, cada qual com seu prprio relgio, a situao muda.
Embora a freqncia na qual o oscilador de cristal roda usualmente estvel,
no possvel garantir que os cristais nos diferentes computadores rodaro na
mesma freqncia. Na prtica, quando um sistema possui n computadores,
todos os n cristais rodaro em taxas ligeiramente diferentes, levando os
relgios a ficarem gradualmente fora de sincronismo. Esta diferena em valores
de tempo chamada clock skew. Como conseqncia deste clock skew,
programas que esperam o tempo associado com um arquivo, objeto, processo,
podem falhar.

Princpios:
a. Somente processos que interagem precisam sincronizar seus relgios.
b. No necessrio que todos os processos observem um nico tempo
absoluto;
c. eles somente precisam concordar com relao ordem em que os eventos
ocorrem.
Relgio Fsico:
Em alguns sistemas (por exemplo, sistemas de temporeal), o tempo real
importante.
Para estes sistemas relgios fsicos externos so necessrios. Por razes de
eficincia

redundncia,

mltiplos

relgios

fsicos

so

geralmente

considerados desejveis, os quais trazem dois problemas:

a. Como ser feito a sincronizao deles com os relgios do mundo real;
b. Como sincronizar os relgios entre si.
Existem vrias variantes para medir o tempo, a saber:
- GMT: Greenwich Mean Time
- BIH: Bureau Internacional de lHeure
- TAI: International Atomic Time
- UTC: Universal Coordinated Time
- NIST: National Institute of Standard Time
- WWV: Estao de rdio de ondas curtas
- GEOS: Geostationary Environment Operational Satellite
Existe tambm uma srie de algoritmos desenvolvidos para prover o
gerenciamento do relgio:

a. Algoritmo de Berkeley:
A rede no dispe de uma mquina com um receptor WWV. Dispe de um time
server quefaz polling nas outras mquinas a fim de obter a hora marcada por
cada uma, fazer uma mdia entre essas horas e divulgar essa mdia para
todas as mquinas.
b. NTC: Network Time Protocol:
uma sub-rede hierrquica de sincronizao com servidores primrios (WWV)
e secundrios.
c. Algoritmo de Cristian:
A rede dispe de um time server (receptor WWV). Uma mquina cliente envia
uma mensagem pedindo a hora certa ao time Server e ao receber a mensagem
resposta do time server, o cliente adiciona o tempo mdio de envio de
mensagens hora recebida. Esse tempo mdio calculado pelo prprio cliente
considerando as horas de envio e recebimento das mensagens e ainda o
tempo gasto pelo time server para processar o pedido.
Relgios Sincronizados:
Est havendo, recentemente, uma fcil disponibilidade de hardware e software
para sincronizao de clocks em larga escala (Ex. sob a Internet). Novos e
interessantes algoritmos que fazem uso da sincronizao so cada vez mais
freqentes. Um exemplo deste tipo de algoritmo o algoritmo de consistncia
de cache com base em clock.
Na maioria dos sistemas existentes desejado que cada usurio tenha uma
cpia local de arquivos por questes de desempenho. Entretanto, o cache
introduz problemas de inconsistncia se dois clientes modificam o mesmo
arquivo ao mesmo tempo. A soluo mais adequada distinguir entre cache de
arquivos para leitura e cache de arquivos para escrita. A desvantagem deste
esquema que se um cliente tem um arquivo "cacheado" para leitura, antes de
conceder uma cpia de escrita para um outro cliente, o servidor precisa
primeiro dizer ao cliente detentor da cpia de leitura para anulla.
Este overhead extra pode ser eliminado usando relgios sincronizados.

Sincronizao Fsica de Relgios:

Est havendo, recentemente, uma fcil disponibilidade de hardware e software
para sincronizao de clocks em larga escala (Ex. sob a Internet). Novos e
interessantes algoritmos que fazem uso da sincronizao so cada vez mais
freqentes. Um exemplo deste tipo de algoritmo o algoritmo de consistncia
de cache com base em clock. Na maioria dos sistemas existentes desejado
que cada usurio tenha uma cpia local de arquivos por questes de
desempenho. Entretanto, o cache introduz problemas de inconsistncia se dois
clientes modificam o mesmo arquivo ao mesmo tempo. A soluo mais
adequada distinguir entre cache de arquivos para leitura e cache de arquivos
para escrita. A desvantagem deste esquema que se um cliente tem um
arquivo "cacheado" para leitura, antes de conceder uma cpia de escrita para
um outro cliente, o servidor precisa primeiro dizer ao cliente detentor da cpia
de leitura para anulla.
Este overhead extra pode ser eliminado usando relgios sincronizados.
Sincronizao Fsica de Relgios:
Segundo Tanembaum, esta sincronizao pode resultar em dois problemas
principais.
Primeiro, um relgio no pode voltar atrs (se estiver marcando 300, o relgio
no poder ser corrigido para 299, tendo em vista que vrias aplicaes
dependem desta semntica). Desta forma, se um computador necessita
sincronizarse com outro computador cujo relgio est atrasado, ele ter que
reduzir a freqncia de seu clock de modo que trabalhe um pouco mais lento e
possa se igualar ao clock do computador com o qual est se sincronizando.
Segundo, em sistemas distribudos, no se pode determinar com preciso o
delay de transmisso da rede. Por exemplo: Um cliente desejando
sincronizarse com um servidor envia uma requisio. O servidor responde
devolvendo o tempo atual de seu clock. O problema que quando o cliente
recebe de volta a mensagem, o tempo retornado j est desatualizado.
Alguns algoritmos foram propostos para tentar amenizar os problemas de
sincronizao, como o algoritmo de Cristian e o algoritmo de Berkeley.

Excluso Mtua:
Sistemas envolvendo mltiplos processos so mais facilmente programveis
usando regies crticas. Quando um processo tem que ler ou atualizar
determinadas estruturas de dados compartilhados, ele primeiro entra na regio
crtica para atingir a excluso mtua e garantir que nenhum processo ir usar
as estruturas de dados compartilhadas no mesmo tempo. Em sistemas de um
nico processador, regies crticas so protegidas usando semforos,
monitores, e construes similares. Sero apresentados alguns exemplos de
como regies crticas e excluses mtuas podem ser implementadas em
sistemas distribudos.
Algoritmos Centralizados:
Sistemas envolvendo mltiplos processos so mais facilmente programveis
usando regies crticas. Quando um processo tem que ler ou atualizar
determinadas estruturas de dados compartilhados, ele primeiro entra na regio
crtica para atingir a excluso mtua e garantir que nenhum processo ir usar
as estruturas de dados compartilhadas no mesmo tempo. Em sistemas de um
nico processador, regies crticas so protegidas usando semforos,
monitores, e
O caminho mais rpido para atingir excluso mtua em sistemas distribudos
similar ao feito em sistema com um nico processador. Um processo eleito
como o coordenador (por exemplo, um rodando na mquina com o maior
endereo da rede). Sempre que um processo quiser entrar na regio crtica, ele
envia uma requisio de mensagem para o coordenador declarando qual
regio ele quer entrar e requisitando permisso. Se nenhum outro processo
estiver atualmente naquela regio crtica, o coordenador envia uma resposta de
volta dando permisso. Quando a resposta chega, o processo de requisio
entra na regio crtica.
Quando o processo 1 sair da regio crtica, ele envia uma mensagem para o
coordenador liberando o acesso exclusivo. O coordenador toma a requisies
da fila de requisies, e envia ao processo uma mensagem de permisso. Se o
processo ainda estiver bloqueado (por exemplo, a primeira mensagem para
ele), ele desbloqueado e entra na regio crtica.

Este algoritmo garante excluso mtua: o coordenador somente deixa um

processo, por tempo, entrar na regio crtica. tambm junto, desde que as
concesses as requisies so feitas na ordem na qual elas so recebidas.
Nenhum processo espera para sempre. O esquema fcil de implementar,
tambm, e requer somente trs mensagens para uso da regio crtica
(requisio, concesso, liberao).
Pode tambm ser usado para alocao mais geral dos recursos ao invs de
somente gerenciar regies crticas.
A abordagem centralizada tambm possui problemas. O coordenador um
nico ponto de falha, logo se ela quebrar, todo o sistema pode vir abaixo. Se os
processos normalmente bloquearem depois de fazer uma requisio, eles no
podero distinguir um coordenador "morto" de uma "permisso negada" desde
que em ambos nenhuma mensagem retorna. Em adio, em sistemas grandes,
um nico coordenador pode tornar um gargalo da performance.
Algoritmos Distribudos:
Tendo um nico ponto de falhar inaceitvel, logo pesquisadores tem estudado
algoritmo para excluso mtua distribuda.
O algoritmo de Ricard e Agrawala requer que haja uma ordem total de todos os
eventos no sistema. Ou seja, para qualquer par de eventos, como mensagens,
no deve haver ambiguidade na qual o primeiro acontece. O algoritmo de
Lamport apresentado antes um modo de alcanar esta ordenao e pode ser
usada para fornecer timestamp para a excluso mtua distribuda.
O algoritmo funciona como segue. Quando um processo quer entrar na regio
crtica, ele constri uma mensagem contendo o nome da regio crtica que est
interessado, o nmero do processo, e o tempo corrente. Ele envia a mensagem
para todos os outros processos, conceitualmente incluindo o. Um grupo
confivel de comunicao se disponvel, pode ser usado ao invs de
mensagens individuais.
Quando um processo recebe uma requisio de outro processo, a ao que
toma depende do seu estado com relao regio crtica nomeada na
mensagem. Trs casos devem ser distinguidos:

a. Se o receptor no a regio crtica e no quer entrar na regio crtica, ele

retorna um OK para o transmissor.
b. Se o receptor estiver na regio crtica, ele no responder. Ao invs, ele
enfileira a requisio.
c. Se o receptor quiser entrar na regio crtica mas no o fez ainda, ele
compara o timestamp da mensagem com o contendo na mensagem que ele
enviou para todos. A menor ganha. Se a mensagem que chegar tiver menor
prioridade, o receptor envia uma mensagem de OK. Se sua prpria mensagem
tiver um timestamp inferior, o receptor enfileira a mensagem e no envia nada.
Depois de enviar as requisies pedindo autorizao para entrar na regio
crtica, um processo espera at que todos tenham dado permisso. Assim que
todas as permisses cheguem, ele poder entrar na regio crtica. Quando ele
sai da regio crtica, ele envia um OK para todos os processos da sua fila e os
deleta de sua fila. Se no h um conflito, ele funcionar corretamente.
Algoritmo Token Ring:
Uma abordagem totalmente diferente para obter a excluso mtua em um
sistema distribudo apresentada em barramento (por exemplo, Ethernet), sem
ordenao dos processos.
Por software, um anel circular construdo no qual cada processo associado
a uma posio no anel. As posies no anel podem ser alocadas em uma
ordem numrica dos endereos da rede ou de outra forma. No importa qual
a ordem. O que importa que cada processo saiba quem o prximo no anel.
Quando o anel inicializado, o processo recebe um token. O token circula pelo
anel.
Passa pelo processo K para o processo K + 1 em mensagens pontoaponto.
Quando um processo adquire o token do processo vizinho, ele checa para ver
se precisa entrar na regio crtica. Se precisar, o processo entra na regio
crtica, efetua o trabalho a ser feito, e libera a regio. Depois de sair, ele passa
o token para o anel. No permitido entrar numa segunda regio crtica
usando o mesmo token.

Se o processo recebe o token de seu vizinho e no est interessado em entrar

na regio crtica, ele somente passa o token para frente. Como conseqncia,
quando nenhum processo quer entrar em nenhuma regio crtica, o token
somente circula em alta velocidade ao longo do anel. Deste modo, somente um
processo tem o token em qualquer instante, logo somente um processo pode
estar na regio crtica, visto que o token circula pelos processos em uma ordem
bem definida. Uma vez que um processo decide entrar na regio crtica, no pior
caso ele ter que esperar que todos os outros processos entrem na regio
crtica e a liberem.
Como sempre, este algoritmo tambm possui problemas. Se o token for
perdido, ele deve ser gerado novamente. No entanto, detectar que o token foi
perdido difcil, visto que o tempo entre sucessivas aparies do token da
rede ilimitado. O fato de que o token no foi avistado por uma hora no
significa que ele foi perdido. Algum pode ainda estar utilizandoo.
O algoritmo tambm tem problemas se um processo falha, mas a recuperao
mais fcil do que os outros casos. Um processo ao passar o token para seu
visinho pode perceber, se for o caso, que ele est fora do ar. Neste ponto, o
processo fora do ar pode ser removido do grupo, e o processo que possui o
token enviar para o prximo processo no anel. Para isso, necessrio que
todos mantenham a configurao atual do anel.
Comparao dos trs algoritmos:
O algoritmo centralizado o mais simples e tambm o mais eficiente. Ele
necessita somente de trs mensagens para entrar e liberar a regio crtica:
uma requisio e a autorizao e a liberao para sair. O algoritmo distribudo
requer n1 requisies, uma para cada processo, e um adicional de n1
autorizaes, para um total de 2(n1).
Com o algoritmo do anel de token, o nmero varivel. Se todos os processos
constantemente quiserem entrar na regio crtica cada token passado resultar
em uma entrada e sada, para uma mdia de uma mensagem por entrada na
regio crtica. Em outro extremo, o token poderia algumas vezes circular por
horas sem ningum estar interessado nele. Neste caso, o nmero de
mensagens por entrada na regio crtica no limitado.

O tempo que o processo aguarda para entrar na regio crtica at a entrada

varia nos trs algoritmos. Quando regies crticas so pequenas e raramente
usadas, o fator dominante na espera o mecanismo corrente para entrar na
regio crtica. Quando so longas e freqentemente usadas, o fator dominante
esperar que todos tenham sua vez.
Finalmente, todos os trs algoritmos reagem mal a eventos de quebra. Medidas
especiais e complexidade adicional devem ser introduzidas para impedir que
uma quebra faa com que todo o sistema saia do ar. um pouco irnico que os
algoritmos distribudos so mais sensveis a falhas do que os centralizados. Em
um sistema tolerante a falhas, nenhum deles seria indicado, mas se as falhas
no so muito freqentes, eles so aceitveis.
Algoritmos de Eleio:
Em muitos algoritmos de sistemas distribudos existe a necessidade de que um
processo desempenhe funes especiais tais como coordenar, inicializar,
seqenciar, etc. Semelhante ao j visto nos sistemas centralizados em
algoritmos de excluso mtua. Em geral no importa qual o processo toma
para si a responsabilidade, mas algum tem que desempenhar este papel.
A seguir seguem alguns algoritmos para a eleio de um coordenador. Para
isso preciso, distinguir um processo eleito dos outros, j que nenhum dele
possui uma caracterstica distinta.
[TANEMBAU1995] diz que cada processo possui uma identificao nica, por
exemplo, o endereo de rede. Em geral, para eleger o coordenador procurase
pelo processo que tenha o nmero de rede mais alto. Existem diferentes
maneiras para fazer est localizao.
Alm disso, ser assumido que todo processo conhece o nmero dos outros
processos e que os processos no sabem quais deles esto correntemente
ativos ou no. A meta da eleio assegurar que aps o incio da eleio os
processos concordem entre si quem o novo coordenador.
Algorimo de Bully:
Segundo Tanembaum, este algoritmo quando verifica que o coordenador est
morto, inicia uma eleio da seguinte forma:

a. P envia uma mensagem de ELEIO para todos os processos.

b. Se nenhum processo responde ento ele se torna o coordenador
c. Se algum que responder tiver o nmero maior do que o de P, ento P ser
tomado sobre ele.
Em qualquer momento um processo de menor nmero pode enviar uma
mensagem de ELEIO. Quando isto acontece o processo coordenador de
maior nmero responde ao sender com uma mensagem de OK, indicando que
ele est ativo e assim o processo sender se cala.
Entretanto, se o processo que enviou a mensagem de ELEIO for um nmero
maior do que o coordenador. O processo sender ser eleito como o novo
coordenador. Desta forma, garante que se um processo de maior nmero ficar
inativo ou crasher temporariamente, ele poder voltar a ser o novo
coordenador. Assim sempre ficar no topo o processo de maior nmero por
isso chamado "Algoritmo do Valento".
Algoritmo do Anel:
Outro modelo de eleio do coordenador utilizando um anel, mas sem a
presena do
token.
Os processos esto ordenados logicamente ou fisicamente. Desta forma cada
processo sabe quem seu sucessor. Quando um processo percebe que o seu
coordenador est desativado, ele constri uma mensagem ELEICO com o
seu identificador e a passa para o seu sucessor. Se o seu sucessor estiver
inativo a mensagem passar para o prximo e assim por diante at que a
mensagem volte ao processo que enviou. Durante este processo cada
processo coloca o seu identificador. Aps a mensagem circular por todos os
processos, o processo que enviou a mensagem altera a mensagem para o tipo
COORDENADOR, colocando novamente para circular para que todos
reconheam quem o coordenador e quais os novos membros do anel.
Logo que a mensagem retornar ao processo transmissor, ela retirada do anel
e todos voltam a trabalho novamente.

Deadlock:
Um deadlock causado pela situao onde um conjunto de processos est
bloqueado permanentemente, isto , no consegue prosseguir a execuo,
esperando um evento que somente outro processo do conjunto pode causar.
Condies necessrias para ocorrer o Deadlock no sistema:
- Excluso mtua;
- Segura e espera;
- No preempo;
- Espera circular.
Estratgias mais utilizadas para trabalhar o Deadlock:
- Algoritmo do avestruz (ignorar o problema);
- Deteco (permite que o deadlock ocorra, detecta e tenta recuperar);
- Preveno (estaticamente faz com que o deadlock no ocorra);
- Espera circular (evita deadlock alocando recursos cuidadosamente).
Algoritmo de Deteco Distribuda:
O algoritmo de deteco funciona da seguinte maneira: O algoritmo
executado quando um processo tem que esperar por algum recurso em funo
de outro processo que esta utilizando o mesmo.
Quando esta situao ocorre, uma mensagem especial enviada (probe
message) para o processo que esta utilizando o recurso, sendo composta de
trs partes:
- informaes sobre o nmero do processo que est bloqueando;
- o nmero do processo que esta enviando a mensagem; e o
- nmero do processo para quem a mensagem est sendo enviada.

Quando a mensagem chega a um processo, o processo verifica se est

esperando por algum recurso que esta em uso por outro processo. Se estiver,
ento a mensagem atualizada, mantendose o primeiro campo, mas
trocando o segundo campo por seu nmero de processo e o terceiro pelo
nmero do processo que est esperando pelo desbloqueio do recurso. Se este
est bloqueado devido a diversos processos, ento a mensagem enviada
para todos os processos que detm o recurso que o processo necessita. Se a
mensagem d toda a volta e chega ao processo que iniciou a mensagem,
existe um ciclo, logo o sistema est em deadlock.

Tolerncia a falhas em Sistemas Distribudos:

O que um sistema tolerante a falhas?
um sistema que continua provendo corretamente os seus servios mesmo na
presena de falhas de hardware ou de software. Defeitos no so visveis para
o usurio, pois o sistema detecta e mascara (ou se recupera) defeitos antes
que eles alcancem os limites do sistema (ponto de fuga da especificao).
Na rea de tolerncia a falhas, os termos falha, erro e defeito (ou falta)
apresentam diferentes significados. Uma falha uma condio fsica anmala,
causada por erros de projeto, problemas de fabricao ou distrbios externos
(ANTNIO, 199?), como por exemplo: uma flutuao na fonte de alimentao.
Erro a manifestao de uma falha no sistema, causando disparidade nas
respostas apresentadas que diferem do valor previsto (ANTNIO, 199?) , como
por exemplo: devido falha citada anteriormente, um terminal de um circuito
integrado deveria receber o bit 0, mas recebeu o bit 1, e isto causaria um
resultado errado. No necessariamente as falhas presentes no sistema
resultaro em erros, pois podero existir dispositivos que corrijam a falha.
Defeito ou falta corresponde a um erro no tratado (ANTNIO, 199?). Para o
melhor entendimento, esses conceitos podem ser representados utilizando o
Modelo de Trs Universos (WEBER, 2000b, Sld 5) (SANTOS & CAVALCANTE,
2000, Cap 2. p.10) (Figura 1).

O primeiro o Universo Fsico, que compreende os dispositivos semicondutores, elementos mecnicos, fontes de energia, ou qualquer outra
entidade fsica. Uma falha ocorre nesse universo. O Universo da Informao
compreende os dados manipulados pelo sistema, e onde um erro pode
ocorrer, em virtude da existncia de alguma falha no Universo Fsico. O ltimo
universo o Externo ou do Usurio. neste onde o usurio final percebe que o
sistema apresentou comportamento indesejado e, portanto, possui um defeito.
Como podemos perceber na figura acima, uma falha pode acarretar em um
erro e um erro pode acarretar em um defeito (TEIXEIRA & MERCER, 2000,
cap. 9). Mas, segundo (WEBER, 2000b, Sld 6), existe entre uma falha e um
erro, e entre um erro e um defeito uma fase chamada latncia. Esta latncia
pode ser:
- Latncia de falha: o perodo de tempo entre a ocorrncia da falha at a
manifestao do erro devido quela falha.
- Latncia de erro: o perodo de tempo entre a ocorrncia do erro at a
manifestao do defeito devido quele erro.
Classificao de Falhas:
Segundo (WEBER, 2000b, Sld 7) (SANTOS & CAVALCANTE, 2000, Cap 2.
p.10), as falhas podem ser classificadas quanto sua origem em:
- Fsicas: As falhas fsicas so causadas por fenmenos naturais como
desgaste do material, problemas de interconexo ou quaisquer outros que
afetem a estrutura mecnica ou eletrnica do sistema. As falhas fsicas podem
ainda ser subclassificadas quanto durao em:

 Permanentes uma vez que se manifestam sempre o faro.

Temporrias no-permanentes, podendo ser intermitentes,
normalmente causadas pelo processo de degradao do componente e
que fatalmente se tornaro permanentes com o tempo; ou transitrias,
geralmente relacionadas interferncia de sistemas externos.
- Humanas: As falhas humanas so aquelas introduzidas no sistema pela ao
do homem. Podem ser subdivididas em:
Falhas de Projeto so introduzidas na fase de projeto do sistema;
Falhas de Interao ocorrem durante a interao dos usurios com o
sistema. Considera-se que as falhas nunca so introduzidas pelo
usurio. Este apenas causaria a manifestao de uma falha j existente
no sistema, originadas por erros de projeto.
Aplicaes que demandam tolerncia a falhas:
Segundo (WEBER, 2000b, Sld 28) (SANTOS & CAVALCANTE. Cap 2. p.11), os
sistemas que devem apresentar caractersticas de tolerncia a falhas podem
ser categorizados em quatro reas de aplicaes:
- Longa Vida: So aplicaes que foram projetadas para estar em operao
por um grande perodo. considerado grande, um perodo que ultrapasse dez
anos. Exemplos de aplicaes de Longa Vida so os satlites e sondas
espaciais.

- Computao Crtica: talvez a categoria de aplicao onde a tolerncia a

falhas mais aplicada. Compreendem sistemas que, se apresentarem
funcionamento inadequado, podem levar a conseqncias catastrficas, seja
pondo em risco vidas humanas, seja causando altos danos materiais.
Exemplos clssicos de aplicaes de Computao Crtica so os sistemas de
controle de trfego areo, sistemas de msseis teleguiados e de controle de
indstrias qumicas.
-

Adiamento

de

Manuteno:

So

aplicaes

cuja

manuteno

extremamente cara, inconveniente ou difcil de executar. Para sistemas como

esses se deseja que a manuteno seja feita periodicamente e enquanto isso,

o sistema por si s consiga evitar e tratar as falhas que ocorram durante sua
execuo. Um exemplo de aplicao desse tipo o sistema de estaes de
comutao telefnicas.
- Alta Disponibilidade: So aplicaes cuja disponibilidade um fator crtico.
Exemplos clssicos so os terminais de caixa eletrnicos dos bancos.
Fases do Processo de Tolerncia a Falhas:
Segundo (WEBERSLD, 2000b, Sld 26) (SANTOS & CAVALCANTE, 2000, Cap
2. p.11), h vrias fases para o processo de tolerncia a falhas nos sistemas.
As fases sero mais bem detalhadas a seguir:
- Deteco de Erros: A primeira fase do processo de tolerncia a falhas
claramente a deteco de erros no sistema. Todo o mecanismo de tolerncia a
falhas empregado no sistema depender da eficincia do seu mdulo de
deteco de erros.
O mdulo de deteco de erros deve observar o funcionamento do sistema
sendo capaz de perceber desvios de comportamento a partir da especificao
inicial.
Existem algumas propriedades que um mecanismo ideal para deteco de
erros deve apresentar:
Independncia o mdulo de deteco de erros no deve ser
influenciado pela estrutura interna do sistema, pois os erros existentes
no sistema poderiam afetar tambm este mdulo.
Completo deve detectar todos os erros possveis.
Correto no pode considerar um comportamento esperado como um
comportamento anmalo, ou seja, sempre que um erro for detectado,
pode-se ter certeza da existncia de falhas no sistema.
- Confinamento de Erros: Aps a deteco do erro, deve-se identificar o
mdulo ou componente falho do sistema. Com as passagens de informaes
entre os mdulos e componentes, os erros podem propagar-se pelo sistema.
Assim, todo o fluxo de informao originado do mdulo ou componente falho
deve ser observado e as conseqncias das aes devem ser delimitadas,

determinando as partes do sistema que foram corrompidos pela manifestao

da falha. Este o objetivo desta fase.
- Recuperao de Erros: Detectado o erro e identificada sua extenso pelo
sistema, as alteraes de estado devem ser removidas para levar o sistema a
um estado aceitvel evitando o mau funcionamento do sistema futuramente.
Nesta fase, o sistema deve restabelecer um estado livre de erros aps uma
falha. Existem duas abordagens para a recuperao de erros:
Por avano se a natureza dos erros pode ser completamente
avaliada, ento se pode remover estes erros do estado do processo e
habilit-lo a prosseguir.
Por retorno se no for possvel remover todos os erros do estado do
processo, ento o processo deve ser restaurado para um estado prvio
livre de erros. Normalmente, so utilizados checkpoints nessa fase.
- Tratamento de Falhas: Nas trs primeiras fases, o erro detectado, sua
extenso avaliada e removido deixando o sistema livre de erros. Isso pode ser
suficiente se a causa do erro foi uma falha transitria. Se as falhas forem
permanentes,

ento

mesmo

erro

poder

ocorrer

novamente

em

processamento futuro. O objetivo desta fase, tambm conhecida como

reconfigurao, identificar o componente falho e remov-lo do sistema para
no mais ser utilizado. O componente causador da falha pode ter a
granularidade variada, podendo corresponder a um chip ou a uma placa inteira,
por exemplo.
Tcnicas de Tolerncia a Falhas em Sistemas Distribudos:
A distribuio de partes de um sistema por diferentes meios de armazenamento
leva a um problema intrnseco de sistemas distribudos que a inconsistncia e
a falta de integridade dos dados (WEBER, 2000a, Item 7). Para resolver este
problema so utilizadas vrias tcnicas que garantem que todas as partes
sejam consistentes, ou seja, que eles possuam o mesmo estado no momento
em que houver uma falha e uma outra parte possa assumir o processamento a
partir do ponto em que ocorreu a falha.
- Tcnica de Recuperao:

Para que um sistema no sofra pane total, ao ser detectada uma falha o
sistema deve ser automaticamente reconfigurado, ou seja, um processo que
estava sendo executado deve ser realocado para outros caminhos alternativos
que mantenham a comunicao contnua. Mas, para que o processo de
recuperao no reduza a performance do sistema e seja o mais transparente
possvel para o usurio, a tcnica de recuperao por avano bastante
utilizada e requer permanentemente um estado consistente entre as partes de
um sistema. Os mecanismos utilizados na tcnica de recuperao so (LUNG,
2000, Sld 59):
Logging: O logging o mecanismo pelo qual as requisies feitas pelos
usurios a uma parte do sistema que est distribudo em algum meio
fsico so gravadas em um arquivo log, para que no caso de uma falha,
uma outra parte do sistema que assumir o lugar do anterior possa obter
o estado corrente e da continuar o processo normalmente.
Checkpoint: O checkpoint um determinado ponto no qual o estado
atual de uma parte do sistema que est no arquivo log verificado e
copiado no arquivo de log das demais partes. Isto faz com que todas as
partes distribudas do sistema estejam sempre atualizadas, mantendo-se
assim consistentes.

O checkpoint realizado a cada tempo t, que pode ser definido pelo usurio ou
fixado na implementao do sistema. Durante este intervalo de tempo t, vrias
requisies de usurios so realizadas e gravadas no arquivo de log. Um
exemplo da utilizao da tcnica de recuperao uma transao bancria
onde um cliente requisita a transferncia de um determinado valor de uma
conta X para uma conta Y. Nesta transao ocorrem duas operaes: uma de
dbito da conta X, e uma de crdito na conta Y. Suponhamos que no intervalo
de tempo entre o dbito e o crdito ocorra uma falha e s tenha sido realizado
o dbito da conta X, ento haveria a uma inconsistncia de dados, pois o valor
debitado da conta X estaria perdido. Mas, com o uso do checkpoint e logging
isto resolvido da seguinte maneira: suponhamos que temos partes do sistema
que realiza esta operao de transferncia em vrios meios fsicos confiveis,
como por exemplo: em dois servidores de aplicao (um ativo e um outro como
backup). Quando o cliente requisita a operao de transferncia, o servidor
ativo assume a operao e o mecanismo de logging grava esta requisio em
um servidor de log. Se o intervalo de checkpoint for suficientemente curto, esta
requisio ser repassada para um arquivo de log no servidor backup. No
momento em que ocorre uma falha como a descrita anteriormente, o cliente
logo redirecionado para o servidor backup e o mecanismo de recuperao
(recovery) consulta o log para verificar qual foi a ltima operao realizada, e a
partir deste ponto continuar a operao, sem causar transtornos para o cliente.
- Tcnicas de Replicao:
A tcnica de replicao consiste em facilitar a criao de rplicas ou cpias de
um mesmo objeto em meios fsicos diferentes, garantindo assim que, no caso
de uma falha em um dos dispositivos, o cliente seja redirecionado de forma
transparente para outro que tenha uma rplica do objeto ativa (JATENE, 1999).
As tcnicas de replicao podem ser resumidas em dois tipos bsicos
(JATENE, 1999):
Replicao passiva: Neste tipo de replicao, h apenas um objeto que
recebe as requisies dos clientes, este objeto chamado primrio. Os outros
objetos so chamados secundrios ou backups, e constantemente so
informados pelo primrio sobre o estado atual do mesmo. Para isto, esta
replicao utiliza os mecanismos de checkpoint e logging.

Como podemos perceber somente o objeto primrio recebe as requisies, e

atravs do mecanismo de checkpoint estas requisies so salvas nos
arquivos de log dos objetos backups ou secundrios. No caso de uma falha do
objeto primrio, um dos dois objetos secundrios assume o lugar do primrio,
continuando assim o processamento.
Replicao ativa: Neste tipo de replicao no so utilizadas as tcnicas de
recuperao, pois todas as rplicas so primrias, ou seja, todas elas recebem
a requisio do cliente , processam e devolvem os resultados de forma
simultnea. Neste caso, a replicao deve obedecer s propriedades de
atomicidade (todas as rplicas recebem as requisies num mesmo instante) e
de ordenao (todas as rplicas recebem as requisies na mesma ordem).

Podemos perceber que este tipo de replicao pode gerar inconsistncia dos
dados no momento em que todas as rplicas enviam os resultados dos seus
processamentos para o cliente, pois pode ocorrer de uma resposta chegar
antes da outra, causando assim mltiplos resultados para o cliente. Para
resolver este problema, comum utilizar uma variao deste mtodo chamada
replicao ativa com votao, no qual ocorre uma votao e somente uma das
respostas retorna para o cliente.
Podemos perceber tambm que neste tipo de replicao h uma melhora de
performance no funcionamento dos sistema, pois no teramos mecanismos de
recuperao que causaria um certo atraso no processamento, principalmente

quando se trata de sistemas de tempo real como sistema clnicos, onde uma
demora de milissegundos pode ser fatal. Mas, como podemos perceber, este
tipo de replicao apesar de ser mais confivel, causa um trfego de
informaes razovel na rede, pois haveria uma difuso da requisies para
todas as mquinas da rede (broadcast) e as mesmas responderiam ao mesmo
tempo. Para resolver este problema, foi criada a tcnica de gerenciamento de
grupos.
- Tcnica de gerenciamento de grupos:
Uma das dificuldades encontradas nas tcnicas de replicao que vimos
anteriormente o trfego na rede. Mas, outro problema surge quando
precisamos tornar transparente para o cliente a localizao das rplicas no
caso de uma falha, pois teramos que criar uma referncia para cada rplica
criada. Para resolver estes problemas, foi criada uma definio de grupos de
objetos, onde os objetos so integrados em sub-grupos diferentes, contendo
cada grupo uma referncia nica. Com isto resolveramos tanto o problema da
localizao das rplicas pelos clientes, como tambm o trfego excessivo na
rede, pois nesta tcnica j estaria implementado a primitiva de comunicao
multicast, onde apenas um determinado grupo de objetos receberiam as
requisies, ao contrrio da primitiva de comunicao broadcast, onde todas os
objetos replicados recebem requisies (JATENE, 1999).
Tambm chamada de Group Membership (WEBER, 2000a) (JATENE, 1999) ou
associao de grupos, esta tcnica visa tambm facilitar a manipulao de
rplicas, onde podemos cadastrar e excluir rplicas de um grupo, alm de
aumentar a confiabilidade no tratamento de tolerncia a falhas, principalmente
quando temos redes particionadas, ou seja, sub-redes interconectadas por um
roteador, gateway, etc. Vejamos na figura 5 como definida a tcnica de
gerenciamento de grupo.

Como podemos perceber cada conjunto de rplicas associadas formam um

grupo. Estes grupos podem ser comparados a domnios de tolerncia a falhas,
ou seja, uma grande rede particionada por sub-redes e interconectadas por
hubs, switches ou roteadores. Cada grupo possui uma referncia nica
(JATENE, 1999), ou seja, quando um cliente requisitar uma operao a um dos
objetos, a aplicao no ir mais procurar por referncias individuais de cada
objeto, mas pela referncia do grupo como um todo.

Validao de Tcnicas de Tolerncia a Falhas:

Vimos nos itens anteriores vrias tcnicas de tolerncia a falhas mais comuns
utilizadas em sistemas distribudos. Mas, quando estamos tratando de sistemas
muito complexos e altamente crticos, h uma necessidade de se testar as
tcnicas de tolerncia a falhas, tentando simular situaes de falhas mais
prximas possveis da realidade em que sero submetidas. A esses testes
damos o nome de injeo de falhas. (WEBER) (LEME , MARTINS & RUBIRA,
199?) 27 H trs categorias de injeo de falhas, que so mostradas abaixo
(WEBER, 2000a) (LEME , MATINS & RUBIRA, 199?):
- Injeo de falhas por hardware: Neste tipo de injeo o hardware forado
a erros atravs de mudanas de valores lgicos no prprio circuito. Exemplo:
um determinado pino de um CI (circuito integrado) deve receber o nvel lgico
1, e para forarmos a uma falha, injetamos um nvel lgico 0.
- Injeo de falhas por software: Neste tipo de injeo so utilizados
softwares que tentam corromper o cdigo do sistema, modificar caractersticas
de comunicao, etc.
- Injeo de falhas por simulao: Neste tipo de injeo, h uma simulao
de possveis falhas que possam ocorrer no sistema ainda mesmo em tempo de
projeto.
Replicao e Consistncia:
O que ? O uso de mltiplas cpias de dados ou servios (e estado associado).
Porqu? Essencialmente por razes de 3 ordens:
1. disponibilidade (availability): se um servio no estiver acessvel, pode-se
tentar aceder a uma sua rplica;
2. fiabilidade (reliability): mantendo rplicas em locais distintos, a capacidade
de sobrevivncia dos dados a acidentes srios, p.ex. tremores de terra,
maior;
3. desempenho (performance): a carga pode ser distribuda pelas diferentes
rplicas, possivelmente mais prximas dos clientes.
Replicao: Casos Particulares
Caches
tipicamente mantidas por clientes;
procuram explorar a localidade de referncia:
posteriores acessos aos mesmos dados usaro a cpia local.
Proxy Servers:
mantm tambm uma cache, que partilhada por vrios clientes;
pressupem localidade de referncia, e principalmente homogeneidade
dos clientes;
permitem, ou facilitam, por exemplo:
reduzir a latncia na resposta a pedidos;

utilizar mais eficientemente a largura de banda da rede;

implementar polticas de segurana globais.

Replicao: Problemas Bsicos:

Transparncia;
Consistncia.
Replicao Transparncia:
O acesso a servios/dados replicados dever ser semelhante ao de
servios/dados no replicados:
um cliente dever aceder a um servio replicado da mesma
maneira que a um servio no-replicado, i.e. no precisa de saber
que o servio replicado.
E se o cliente fr replicado?
i.e. transparncia tambm um problema do servidor.

Replicao: Consistncia:
Idealmente, a semntica dum servio replicado deveria ser idntica
dum servio no-replicado

 No mnimo, o valor das rplicas dever convergir, se no se aplicar

qualquer operao varivel replicada. Mas,
Qual o valor final?
Quais os valores (intermdios) visveis?
Consistncia e Concorrncia:
So problemas ortogonais:
Problemas de concorrncia so independentes da
existncia de mltiplas cpias.
Problemas de consistncia podem ocorrer mesmo que
no haja concorrncia i.e. mesmo que exista um
nico thread de execuo:
Rpl. 1 Rpl. 2 (5) // valor inicial (5) // valor inicial x = 2; (2) //
valor final x += 3; (8) // valor final
Modelos de Consistncia:
Definio Um modelo de consistncia um contrato entre um sistema e os
seus utilizadores:
- especificando resultado das operaes que suporta na presena de
replicao;
- assumindo que os utilizadores seguem determinadasregras.
- Conceptores de sistemas tm que escolher/conceber um modelo de
consistncia fcil de usar e com bomdesempenho.
- Utilizadores de sistemas tm que conhecer o modelo de consistncia
suportado pelo sistema para evitar surpresas desagradveis.

Modelos de Consistncia:

Consistncia Estrita (Strict Consistency)

Consistncia Sequencial (Sequential Consistency)
Consistncia Fraca (Weak Consistency)
One-copy Serializability
Client-centric Consisteny Models

Bibliografia:
http://www-usr.inf.ufsm.br/~ceretta/elc895/02_fundamentos.pdf

https://andreyhlb.files.wordpress.com/2010/04/tolerancia_a_falhas.pdf

http://www.ppgia.pucpr.br/~alcides/Teaching/SistemasDistribuidos/TOF/01_conc
eitosbasicos.pdf

http://www.tlc-networks.polito.it/oldsite/anapaula/Aula_Cap01.pdf

http://ricardobarcelar.com.br/aulas/sd/7-sincronizacao.pdf
http://web.fe.up.pt/~pfs/aulas/sd2009/at/20cons.pdf