ࡱ> |V( / 0DArialngsRo^RL[Rv 0( 0DTimes New Roman[Rv 0( 0 DWingdingsRoman[Rv 0( 0 b$0. @n?" dd@  @@`` 0/ () ** ()       !"#$%&'()*+,-./ 0AA@8H9ʚ;w8ʚ;g4JdJdv 0&ppp@ <4dddd` 0L\R <4!d!d 0Lg4EdEdv 0p@ pp80___PPT10 pp?  %O  = GH$Universidade da Beira Interior?Fiabilidade de Sistemas Informticos Nuno Magarreiro n. 14805:%&,I%Processos Recuperveisndice: Introduo Resilient Remote Procedure Call (RPC recupervel) Primary Site Approach Invocao replicada Uma abordagem mista Execuo sem falhas Execuo com falhas >(*  1      ) '   t  V& IntroduoNuma aplicao distribuda, onde vrios processos trabalham em conjunto para elaborar uma tarefa, se um n falha, os processos que esto a executar nesse n deixam de estar disponveis. Isto pode causar a falha de toda a computao distribuda. O objectivo dos processos recuperveis assegurar que a computao distribuda continua a executar mesmo depois das falhas de alguns processos. Sem processos recuperveis o sistema teria que ser reiniciado, o que no aceitvel em aplicaes crticas.  9& &  &Q&  ` :   S' IntroduoVai-se assumir que os ns so fail stop e que os processos so determinsticos. Pode ser usado um mtodo baseado em checkpoints para suportar processos recuperveis. Neste mtodo so criados checkpoints do sistema distribudo e estes so guardados em memria estvel. Assim, se algum n falhar, todo o sistema volta atrs para o ltimo checkpoint global. Os mtodos que vo ser considerados posteriormente no precisam de checkpoints globais e no obrigam todos os processos a voltar a um estado antigo quando ocorrem erros.Z'&&&& &    U& & K @   D \( IntroduoSe o sistema consiste em processos que no comunicam uns com os outros, o problema simples. Para cada processo criado um checkpoint periodicamente, e, se o processo falhar, este restaurado para o estado em que se encontrava na altura do ltimo checkpoint. Apenas o processo que falhou precisa de voltar a um estado antigo. Esta abordagem simples para suportar processos recuperveis , claramente, insuficiente em sistemas onde os processos comunicam uns com os outros. \_&& && &B s  )1Resilient Remote Procedure Call (RPC recupervel)22H  bUm processo que executado num n pode invocar um procedimento que executado noutro n. Quando um procedimento  A chama um procedimento  B , o  A chamado de  direct caller do  B . Tipicamente, o procedimento  A fica suspenso at receber a informao de que pode continuar a executar. Desde que dois processos estejam envolvidos na computao, pode ocorrer uma falha numa parte da computao devido falha de um dos ns.\&& F&& i&& &,+1Resilient Remote Procedure Call (RPC recupervel)22H  Especificamente, possvel que o n que est a executar o procedimento remoto falhe, o que manter o procedimento que o chamou suspenso para sempre. Similarmente, o direct caller pode falhar, ficando-se na situao em que o procedimento remoto fica sem ligao ao processo para o qual deveria devolver os resultados. O objectivo dos esquemas aqui apresentados tornar a computao baseada em RPC resistente a falhas de ns. ~&& &&& m&,,Primary Site Approach$Esta abordagem usa processos pares para suportar resilincia. Um dos processos o primrio e o outro o backup. Quando um servio pedido, a mensagem primeiro enviada para o processo primrio. Se este processo no existir, a mensagem falha e o pedido enviado para o segundo processo. Quando o processo primrio recebe o pedido para uma operao, ele actualiza o seu checkpoint enviando uma mensagem para o processo backup.>&& 3&&& &  &  & z /-Primary Site Approach$Esta mensagem assegura que o backup tem toda a informao e que se o processo primrio falhar, o backup consegue satisfazer o pedido.,&& .Invocao replicada Outro mtodo para tornar uma invocao remota de procedimentos resistente a falhas de ns replicar os procedimentos remotos em vrios ns e, quando um procedimento remoto chamado, todas as rplicas so executadas simultaneamente. Neste mtodo, um mdulo replicado em vrios ns. O conjunto das rplicas dum mdulo chamado de troupe. Sempre que uma invocao feita a um mdulo, todos os membros da troupe executam o pedido. && c&&&& B&&&,OF/Invocao replicada A troupe do mdulo que faz a invocao dum procedimento remoto chamada de client troupe, e a troupe do mdulo para o qual a invocao feita chamada de server troupe. Quando um mdulo faz uma invocao para um mdulo remoto, cada membro da client troupe faz uma invocao para todos os elementos do server troupe. Assim, cada membro da server troupe obtm mltiplas cpias do pedido e envia a resposta ao pedido para todos os elementos da client troupe.&&D& &&&8& &&& && &D?M5 Z0Invocao replicada VA semntica desejada que, para cada membro do server troupe o pedido seja efectuado apenas uma vez, e cada membro da client troupe receba todos os resultados. Estas semnticas so chamadas  exactly-once execution of all troupe members . Isto acontece porque os mdulos so determinsticos. Isto garante que cada membro da server troupe vai executar a instruo e tambm que ser necessrio o uso de nmeros de sequncia.&& O&& 5&& &7:>  bV1Invocao replicada DUm membro da client troupe tem de esperar por todas as respostas antes de continuar a sua execuo. Claro que, se esse membro for informado da falha dum n da server troupe, ele no esperar mais tempo pela mensagem desse n. A client troupe espera por todas as mensagens de volta. Isto proporciona aos membros da client troupe um mtodo para detectar erros e consegui-los corrigir, desde que cada membro possa  votar nos resultados. Por outro lado, isto implica que a resposta vai ser to lenta quanto o membro mais lento da server troupe. d#&& && l& :I2Invocao replicada Se a deteco e correco de erros no forem desejadas deve ser usada a abordagem first-come em que cada membro da client troupe continua a executar assim que recebe a primeira mensagem. Mais uma vez, isto requer o uso de nmeros de sequncia para que as mensagens de novas invocaes possam ser distinguidas das mensagens de invocaes anteriores. claro que com este mtodo de replicao fcil esconder falhas de ns, desde que no falhem todos os elementos da troupe.d&& && }&PR V3Invocao replicada oEste mtodo um pouco caro em termos de nmero de mensagens. Se a client troupe possui m membros e a serve troupe contm n membros, ento o nmero total de mensagens necessrias O(m*n). Por outro lado, se a rede suportar multicasting, em que, no envio de uma mensagem esta pode ser enviada para vrios destinos, ento sero necessrias apenas O(m+n) mensagens. dp>&& && &tDC( n4Uma abordagem mistaAgora vai-se descrever um mtodo que utiliza uma combinao entre a Replicated call e a Primary site approach. No esquema proposto, a tolerncia a falhas fornecida atravs da existncia de cpias dos procedimentos em vrios ns. Cpias de procedimentos juntas so chamadas de clusters. As cpias esto organizadas numa cadeia linear. Para a i-sima cpia, a cpia (i+1) o seu backup. p&& y&& :&& h&tD >'5Uma abordagem mistaO pedido feito para a primeira cpia, que a primeira cpia que no falhou de toda a cadeia. A primeira cpia envia a invocao para o seu backup, que tambm envia a invocao para o seu backup. Desta maneira todas as cpias so invocadas. O resultado da cpia enviado para o cliente atravs da cpia primria. Se a primeira falhar, o seu backup assume o papel da primria e responde para o cliente.\a&& && &6Uma abordagem mistaApenas a cpia primria ir realmente fazer a invocao; as outras cpias que fazem invocaes apenas esperam pelo resultado. O resultado recebido pela primeira propagado para todas as cpias que fazem invocaes. Se a cpia primria falhar no reconhecimento do resultado, outra cpia do resultado deve ser enviada para a sua cpia backup. Existem quatro tipos de mensagens para o esquema proposto: Call message, result message, done message e ack message 9&& && ;&& 9&&& 7Uma abordagem mistaSe no se receber a mensagem de reconhecimento num intervalo de tempo definido, o processo que est a enviar a mensagem verifica o estado do processo que est a receb-la. Se este falhar, a mesma mensagem ser enviada para o backup deste receptor. Estas simples operaes ajudam a assegurar que todas as cpias no cluster recebero a mesma mensagem no caso da ocorrncia de erros. l&& M&& && >>8Uma abordagem mista Execuo sem falhas Neste esquema as cpias secundrias tm um papel activo. Todas as cpias no cluster que chamado executam a invocao, e todas as cpias no cluster que faz a invocao recebem a cpia do resultado. Mesmo assim, desde que a primeira cpia que recebe a invocao no falhe, a cpia que fez a invocao faz uma invocao simples e apenas uma cpia do resultado enviada para o cluster que efectuou a invocao. Todas as comunicaes entre os clusters so suportadas pelas suas cpias primrias. '& :&& && && U&& Pc:</9Uma abordagem mista}Execuo com falhas Depois de enviar uma invocao RPC para o receptor primrio, a cpia que efectuou o pedido espera pela ack message. Se, o tempo limite para mensagem ser recebida for atingido, a cpia que fez a invocao envia a mesma mensagem para o backup. Se o backup j tiver recebido uma mensagem igual da antiga cpia primria, ele reconhece a mensagem mas ignora-a. i'& u&& && r&& ,|:Uma abordagem mista^Execuo com falhas Se a cpia primria que recebeu a invocao falhar depois de ter enviado os resultados mas antes de enviar a done message para a cpia secundria, a cpia que efectuou a invocao poder receber mais do que uma mensagem com os mesmos resultados. A cpia primria que efectuou o pedido reconhece a mensagem duplicada mas ignora-a.`J'& I&& ,/h["\#$%&')*+,-./012345678. ` Ot{h______` M <ff33̙3` +ffO=ff̙H7` fff3f̙` Tff33ff` 0Ky{kOz` )R{f` GiIfff̙fR` ̙|̙3f` 3ff~>?" dd@'?lFd@  nK'o`P( n?" dd@   @@``PT     o (`0p>> ''(  ZB  c $D"`   6#R "M } R ]%Clique para editar o estilo do ttulo&& D  0&R "; ` R nClique para editar os estilos de texto do modelo global Segundo nvel Terceiro nvel Quarto nvel Quinto nvel8  o   0+R "` ` R ^*    0p1R "`  R V*    05R "` ` R V*  T     "`h2   s *"`h2   s *"h2   s *"@h2   s *"0`h2   s *"0h2  s *"0@h2  s *"`0h2  s *"`h2  s *"h2  s *"@h2  s *"`n2  0" h2  s *"``h2  s *"`h2  s *"@`n2  0"``h2  s *"`h2  s *"n2  0"@n2  0"`h2  s *" h2  s *"`@n2  0"@n2   0"@@h2 ! s *"`@n2 " 0"``n2 # 0"`h2 $ s *"`@h2 % s *"``h2 & s *" h2 ' s *"` H  0޽h ? 3ff~___PPT10i. s+D=' = @B + H1_Modelo de apresentao predefinido   7/@(((  ZB  c $D"   6I "&wf I ]%Clique para editar o estilo do ttulo&&   0I "wQ  I v>Faa clique para editar o estilo do subttulo do modelo global??   0DI "` ` I ^*    0I "`  I V*    0!I "` ` I V*  T `]   "]p h2   s *"`]h2   s *"]h2   s *"]Eh2   s *"`h2   s *"h2  s *"Eh2  s *"yh2  s *"`B h2  s *"B h2  s *"EB h2  s *"yB n2  0",B h2  s *"`u  h2  s *"u  h2  s *"u E n2  0"yu  h2  s *"`(  h2  s *"(  n2  0"( E n2  0"y(  h2  s *",(  h2  s *"` Z n2  0" Z n2   0" EZ h2 ! s *"y Z n2 " 0"`  n2 # 0"  h2 $ s *" E h2 % s *"y  h2 & s *"A  h2 ' s *"yA  `B ( s *D"H  0޽h ? 3ff~___PPT10i. s+D=' = @B +60 `F(    0 ] P    X*   0a     Z* d  c $ ?  2  0d  0  nClique para editar os estilos de texto do modelo global Segundo nvel Terceiro nvel Quarto nvel Quinto nvel8   o  6Hi _P   X*   6j _   Z* H  0޽h ? 3380___PPT10.-" 0<(  ~  s *2I&wf I ~  s *3Itv I H  0޽h ? 33___PPT10i.eѢ+D=' = @B + # p0(  x  c $M'}   x  c $d;`  H  0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + $ l0(  lx l c $dAM }   x l c $ B;`  H l 0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + % t0(  tx t c $\MM }  M x t c $M;` M H t 0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + & |0(  |x | c $03MM }  M x | c $3M;` M H | 0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + ' 0(  x  c $eM }   x  c $f;`  H  0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + ) 0(  x  c $[MM }  M x  c $\M;` M H  0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + * 00(  x  c $M }   x  c $;`  H  0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + + P0(  x  c $MM }  M x  c $8M;` M H  0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + , p0(  x  c $M }   x  c $;`  H  0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + - 0(  x  c $܋MM }  M x  c $x;` M H  0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + . 0(  x  c $MM }  M x  c $;` M H  0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + / 0(  x  c $/M }   x  c $0;`  H  0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + 0 0(  x  c $QM }   x  c $PR;`  H  0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + 1 0(  x  c $ܕM }   x  c $t;`  H  0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + 2 00(  x  c $0`M }   x  c $`;`  H  0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + 3 P0(  x  c $zM }   x  c $z;`  H  0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + 4 p0(  x  c $M }   x  c $;`  H  0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + 5 0(  x  c $OJM }  J x  c $7J;` J H  0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + 6 0(  x  c $M }   x  c $X;`  H  0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + 7  0(  x  c $TIM }  I x  c $I;` I H  0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B + 8  0(   x   c $RM }  R x   c $R;` R H   0޽h ? 3ff~___PPT10i.jpG҇+D=' = @B +$0 P$ (  $X $ C     $ S @z 0   " H $ 0޽h ? 3380___PPT10.'lU%0 ( (  (X ( C    R ( S HDR 0  R " H ( 0޽h ? 3380___PPT10.'ln_(&0 p8(  p^ p S    M p c $$F 0  M .Process Resiliency (Processos recuperveis) Numa aplicao distribuda, onde vrios processos trabalham em conjunto para elaborar uma tarefa, se um n falha, os processos que esto a executar nesse n deixam de estar disponveis. Isto pode causar a falha de toda a computao distribuda mesmo que toda a informao fique disponvel, porque uns processos podem depender de outros (eventualmente h processos dependentes dum processo que falhou), para efectuarem algumas tarefas. O objectivo dos processos recuperveis assegurar que a computao distribuda continua a executar mesmo depois das falhas de alguns processos. Os processos recuperveis so, obviamente, importantes em aplicaes crticas onde o processamento no pode parar. Sem processos recuperveis, mesmo que a informao ficasse disponvel, o sistema teria que ser reinicializado e reiniciado o que no aceitvel em aplicaes crticas. .- L  ^=H p 0޽h ? 3380___PPT10.'ln_|'0 x(  x^ x S    M x c $,ͺ 0  M  Este trabalho vai-se focar nas falhas dos processos causadas por falhas nos ns e assumir que os ns so fail stop (estes ns quando falham param a sua execuo). A menos que seja determinado o contrrio, vai-se assumir tambm que os processos so determinsticos, no sentido que, quando se encontram no mesmo estado, se receberem os mesmos dados, vo executar a mesma sequncia de instrues. Pode ser usado um mtodo baseado em checkpoints para suportar processos recuperveis. Neste mtodo so criados checkpoints do sistema distribudo e estes so guardados em memria estvel. Assim, se algum n falhar, todo o sistema volta atrs para o ultimo checkpoint global mas esta ideia requer checkpoints globais, que so caros, e isto limita o seu uso para suporte a process resiliency. Os mtodos que vo ser considerados posteriormente no precisam de checkpoints globais e no obrigam todos os processos a voltar a um estado antigo quando ocorrem erros. t0$ $ V$w$ jB @          @  D ]H x 0޽h ? 3380___PPT10.'ln_(0 :2(  ^  S    M,  c $ 0  M  Se o sistema consiste em processos que no comunicam uns com os outros, o problema simples. Para cada processo criado um checkpoint periodicamente, e, se o processo falhar, este restaurado para o estado em que se encontrava na altura do ltimo checkpoint. Apenas o processo que falhou precisa de voltar a um estado antigo. Esta abordagem simples para suportar processos recuperveis , claramente, insuficiente em sistemas onde os processos comunicam uns com os outros. Tem de ser feito algo mais para alm de reverter o processo que falhou para um estado anterior. Neste trabalho, vo ser discutidos alguns mtodos para suportar processos recuperveis em sistemas de comunicao que usam remote procedure call para comunicao entre processos. Fq$ $ ^b~ s  $H  0޽h ? 3380___PPT10.'ln_)0  (  ^  S    M  c $+ 0  M  Nesta seco vo ser apresentadas tcnicas para tornar um sistemas que usam invocao remota de procedimentos para comunicao resistente a falhas de ns. Um processo que executado num n pode invocar um procedimento que executado noutro n. Quando um procedimento  A chama um procedimento  B , o  A chamado de  direct caller do  B . Tipicamente, o procedimento  A fica suspenso at receber a informao de que pode continuar a executar. Desde que dois processos (ou mais, no caso de invocaes remotas de procedimentos aninhadas) estejam envolvidos na computao, pode ocorrer uma falha numa parte da computao devido falha de um dos ns.$~,AAH  0޽h ? 3380___PPT10.'ln_+0 yq  (  ^  S    Mk  c $ 0  M  Especificamente, possvel que o n que est a executar o procedimento remoto falhe, o que manter o procedimento que o chamou suspenso para sempre (a no ser que algo seja feito para evitar isso). Similarmente, o direct caller pode falhar, ficando-se na situao em que o procedimento remoto fica sem ligao ao processo para o qual deveria devolver os resultados. O objectivo dos esquemas apresentados aqui tornar a computao baseada em RPC resistente a falhas de ns. Nos esquemas aqui descritos, assume-se que os procedimentos so determinsticos. Isto , para um dado estado inicial e um dado input, vai ser sempre efectuada a mesma sequncia de instrues. Deve-se notar que as invocaes remotas de procedimentos tambm permitem a possibilidade de chamadas concorrentes a um procedimento, situao que no acontece nas invocaes de procedimentos ordinrias. Por exemplo, dois procedimentos, A e B, executados independentemente podem fazer invocaes para um procedimento remoto C concorrentemente. Isto requer algum mecanismo de controlo da concorrncia como o locking, por exemplo. Os problemas provocados por invocaes concorrentes no sero discutidos.PwYH  0޽h ? 3380___PPT10.'ln_ ,0   @ (  ^  S    M|   c $F 0  M   Nesta seco vai-se descrever uma abordagem para fazer com que processos que usam RPC para comunicao sejam resistentes a falhas de ns atravs do uso do mtodo  primary site approach . O mtodo descrito parte dum sistema de tolerncia a falhas, que esconde a falha de um nico componente, incluindo falhas no bus, falhas elctricas, falhas transitrias, falhas no canal de I/O, falhas de memria, etc. Aqui vo ser discutidos apenas os aspectos relacionados com tornar processos resistentes a falhas. assumido que os processos usam mensagens para comunicar em que o processo que envia a mensagem fica espera da resposta. Esta abordagem usa processos pares para suportar resilincia. Um dos processos o primrio e o outro o backup. Quando um servio pedido, a mensagem enviada, primeiro para o processo primrio. Se este processo no existir, ou j no for o processo primrio, a mensagem falha e o pedido enviado para o segundo processo. Quando o processo primrio recebe o pedido para uma operao, ele actualiza o seu checkpoint enviando uma mensagem para o processo backup (se este existir). >W BH  0޽h ? 3380___PPT10.'ln_-0 VN`(  ^  S    H  c $P9 0    Esta mensagem assegura que o backup tem toda a informao e que se o processo primrio falhar, o backup consegue satisfazer o pedido. Este mtodo pode provocar que operaes de pedidos de servios sejam realizadas duas vezes  uma pelo processo primrio e outra pelo backup. Embora seja aceitvel em algumas situaes, existem outras situaes em que isto no aceitvel. Para evitar isto, associado um nmero sequencial aos pedidos executados por um processo e, quando o servidor verificar que a operao no repetida, os resultados da operao so gravados. Isto feito pelo processo primrio para se ir mantendo o checkpoint actualizado depois de cada operao. Se o processo primrio falhar durante a operao e o backup se tornar primrio, ento o novo processo primrio usa a informao do checkpoint para efectuar as operaes.,q  H  0޽h ? 3380___PPT10.'ln_.0 6.(  ^  S    M(  c $: 0  M Invocao replicada Outro mtodo para tornar uma invocao remota de procedimentos resistente a falhas de ns replicar os procedimentos remotos em vrios ns e, quando um procedimento remoto chamado, todas as rplicas so executadas simultaneamente. Aqui vai ser descrito uma abordagem chamada de circus. No mtodo circus, um mdulo replicado em vrios ns. O conjunto das rplicas dum mdulo chamado de troupe. Sempre que uma invocao feita a um mdulo, todos os membros da troupe executam o pedido. No circus, a replicao de mdulos feita de um modo transparente para o utilizador. Do ponto de vista deste, a replicao est escondida e a nica diferena que este nota a maior disponibilidade e confiana do sistema. RkCb0WDH  0޽h ? 3380___PPT10.'ln_ /0 j b (  ^  S    M\  c $ 0  M  A troupe do mdulo que faz a invocao dum procedimento remoto chamada de client troupe, e a troupe do mdulo para o qual a invocao feita chamada de server troupe. Quando um mdulo faz uma invocao para um mdulo remoto, cada membro da client troupe faz uma invocao para todos os elementos do server troupe executando assim uma invocao um-para-vrios. Assim, a mesma invocao enviada por cada membro da client troupe para cada membro da server troupe fazendo com que cada membro da server troupe recebe mltiplas cpias do pedido  uma por cada um dos membros da client troupe  resultando numa invocao vrios-para-um para a client troupe. Globalmente, existe uma invocao vrios-para-vrios do client troupe para o server troupe.\D 8 DD?K5 8'D$H  0޽h ? 3380___PPT10.'ln_00 6.(  ^  S    M(  c $s 0  M  Numa ligao vrios-para-vrios, a semntica desejada que, para cada membro do server troupe o pedido seja efectuado apenas uma vez, e cada membro da client troupe receba todos os resultados. Estas semnticas so chamadas  exactly-once execution of all troupe members . Isto acontece porque os mdulos so determinsticos, e se lhes for dado o mesmo input eles executam a mesma sequncia de instrues. Isto garante que cada membro da server troupe vai executar a instruo e tambm que ser necessrio o uso de nmeros de sequncia (todas as rplicas devem ter o mesmo nmero de sequncia inicialmente). 9:<  SWH  0޽h ? 3380___PPT10.'ln_610 F(  ^  S    J   c $ 0  J <  Na implementao do circus, um membro da client troupe que tenha feito uma invocao um-para-vrios tem de esperar por todas as respostas antes de continuar a sua execuo. Claro que, se esse membro for informado da falha dum n da server troupe, ele no ficar mais tempo espera da mensagem desse n. Numa invocao vrios-para-um cada rplica do servidor recebe uma mensagem de cada membro da troupe client. Por outro lado, todas elas so rplicas da mesma invocao, e suposto que o mdulo execute a operao pedida apenas uma vez. Se a operao for efectuada mais que uma vez o sistema pode atingir um estado invlido. Assim, quando uma mensagem chega, os membros da server troupe devem identificar se as diferentes invocaes so cpias da mesma invocao ou no. Para implementar esta ideia so usados nmeros sequenciais para identificar mensagens que provenham do mesmo troupe. Na implementao do circus, a server troupe normalmente espera at que todas as mensagens sejam recebidas, ou melhor, espera at receber todas as mensagens excepto aquelas das quais recebeu a notificao que o n da client troupe falhou, antes de executar as instrues. Neste mtodod, a client troupe espera por todas as mensagens de volta. Isto proporciona aos membros da client troupe um mtodo para detectar erros e consegui-los corrigir, desde que cada membro possa  votar nos resultados. Por outro lado, isto implica que a resposta vai ser to lenta quanto o membro mais lento da server troupe. pL@ 1IH  0޽h ? 3380___PPT10.'ln_;20 K(  ^  S    J  c $D 0  J A Se a deteco e correco de erros no forem desejados deve ser usada a abordagem first-come em que cada membro da client troupe procede assim que recebe a primeira mensagem. Isto requer o uso de nmeros de sequncia para as invocaes para que as mensagens de novas invocaes possam ser distinguidas das mensagens de invocaes anteriores. claro que com este mtodo de replicao fcil esconder falhas de ns, desde que no falhem todos os elementos da troupe. PS LH  0޽h ? 3380___PPT10.'ln_30  (  ^  S      c $ 0    H  0޽h ? 3380___PPT10.'ln_40 @(  ^  S    J  c $ 0  J  H  0޽h ? 3380___PPT10.'ln_50 `(  ^  S      c $l 0    H  0޽h ? 3380___PPT10.'ln_260 B(  ^  S    J  c $  0  J 8` Existem quatro tipos de mensagens para o esquema proposto. Uma call message provoca uma invocao do RPC. Uma result message contm os valores da resposta duma call message. Uma done message enviada para informar uma cpia secundria, que a invocao foi terminada. Estes trs tipos de mensagens necessitam de reconhecimento (com uma ack message). @#$H  0޽h ? 3380___PPT10.'ln_70 (  ^  S    I  c $JI 0  I  H  0޽h ? 3380___PPT10.'ln_H80 X(  ^  S    R  c $(uR 0  R NExecuo sem falhas Neste esquema as cpias secundrias tm um papel activo. Todas as cpias no cluster que chamado executam a invocao, e todas as cpias no cluster que faz a invocao recebem a cpia do resultado. Mesmo assim, desde que a primeira cpia que recebe a invocao no falhe, a cpia que fez a invocao faz uma invocao simples e apenas uma cpia do resultado enviada para o cluster que efectuou a invocao. Todas as comunicaes entre os clusters so suportadas pelas suas cpias primrias. Uma cpia secundria apenas ir interagir com processos externos se todas as cpias superiores a ela falharem, passando esta assim a assumir o papel de primria.6$Pa::H  0޽h ? 3380___PPT10.'ln_90 w(  ^  S    Rq  c $̃R 0  R [Execuo com falhas Depois de enviar uma invocao RPC para o receptor primrio, a cpia que efectuou o pedido espera pela ack message. Se, o tempo limite para mensagem ser recebida for atingido, a cpia que fez a invocao envia a mesma mensagem para o backup. Se o backup j tiver recebido uma mensagem igual da antiga cpia primria, ele reconhece a mensagem mas ignora-a. Se a cpia primria falhar antes de enviar a ack message, a cpia que efectuou a invocao no faz nada. A cpia imediatamente a seguir da cpia primria executar as operaes e enviar o resultado para a cpia que a invocou.6\u~$UP|H  0޽h ? 3380___PPT10.'ln_:0 <4(  ^  S    R.  c $ԢR 0  R  Se a cpia primria que recebeu a invocao falhar depois de ter enviado os resultados mas antes de enviar a done message para a cpia secundria, a cpia que efectuou a invocao poder receber mais do que uma mensagem com os mesmos resultados. A nova cpia primria no ciente que a antiga cpia primria falhou depois de j ter enviado o resultado, enviando assim, outra cpia. A cpia primria que efectuou o pedido reconhece a mensagem duplicada mas ignora-a. Se a cpia secundria que recebe a mensagem falhar antes de reconhecer a call message, a cpia superior enviar a mesma mensagem para a cpia seguinte cpia que falhou. Entre o envio da call message e da done message, uma cpia no precisa de saber qual o estado da seguinte cpia. Se uma cpia que recebe a mensagem falhar no reconhecimento da done message, a mensagem ser enviada para a cpia seguinte. Se a cpia primria que efectua a invocao falhar antes de receber e espalhar o resultado, a cpia seguinte assume o papel de principal e envia a mesma mensagem. O cluster que recebe as invocaes poder receber mensagens duplicadas da mesma mensagem. Os pedidos duplicados so ignorados embora os resultados dessas mensagens sejam enviados para a nova cpia primria. A cpia que efectuou a invocao no sabe o estado das restantes invocaes antes da propagao do resultado da invocao. Se uma cpia que efectua a invocao falhar no reconhecimento do resultado, a mesma mensagem enviada para a cpia seguinte.ngH  0޽h ? 3380___PPT10.'ln_r0Vo H [ NߒpH#E֤g{ 9w$(<Ͷ*,.^93P5:?% kHOh+'0P hp  Bla blanunolaNetwork Paula Prata128Microsoft Office PowerPoint@Y_@pņ@s!kG6g  -& &&#TNPP 2OMi & TNPP &&TNPP    --- !---&oJ--%pH--&&/&~w@, ww0- &Gy& &: 3f--P):--3f--PG:1--3f--Pe:N--3f--n)X--3f--nGX1--3f--neXN--f--nXl--3f--)v--3f--Gv1--f--evN--f--vl----v--3f--)--f--G1--f--eN----l--f--)--f--G1----eN----l------f--)----G1----eN----l----)----G1----eN----l----!G 1----! l--&&'*--% ((--&--1!-- @Arialw@ +ww0- 3f.(2 >Universidade da Beira .'#$$'$'$'$.$$. 3f.2 Interior'$'.--j@Y-- 3f@Arialw@, ww0- .2 ~Fiabilidade de $!$$!$!$!. .'2 gSistemas Informticos'!!4!!$#4!!#!.@Arialw@ 0ww0- .-2 ScNuno Magarreiro n. 14805     .--"System 0-&TNPP &՜.+,0    On-screen Show.-soI ArialTimes New Roman Wingdings%1_Modelo de apresentao predefinidoUniversidade da Beira InteriorProcessos Recuperveis Introduo Introduo Introduo2Resilient Remote Procedure Call (RPC recupervel)2Resilient Remote Procedure Call (RPC recupervel)Primary Site ApproachPrimary Site ApproachInvocao replicada Invocao replicada Invocao replicada Invocao replicada Invocao replicada Invocao replicada Uma abordagem mistaUma abordagem mistaUma abordagem mistaUma abordagem mistaUma abordagem mistaUma abordagem mistaUma abordagem mista  Fonts UsedDesign Template Slide Titles#_KI Paula PrataPaula Prata  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root EntrydO)Current UserSummaryInformation(PowerPoint Document(oIDocumentSummaryInformation8