Comunicação Não Confiável em Detectores de Defeitos com Falhas por Crash

Transcrição

1 Comunicação Não Confiável em Detectores de Defeitos com Falhas or Crash Luiz Angelo Barchet Estefanel 1 Ingrid Jansch-Pôrto {angelo,ingrid}@inf.ufrgs.br Programa de Pós-Graduação em Comutação Curso de Mestrado em Ciência da Comutação Instituto de Informática - UFRGS Porto Alegre - RS - Brasil Resumo A definição dos detectores de defeitos ara ambientes com falhas or crash aresenta restrições severas, mesmo nos mais fracos detectores. Ainda assim, a oeração dos detectores em sistemas distribuídos assíncronos é ossível, mediante certas adatações como, or exemlo, a utilização de timeouts. Um fator imortante ara a construção dos detectores é a necessidade de comunicação confiável; mesmo que esta seja requerida ela definição dos detectores, exeriências ráticas demonstram que se ode utilizar comunicação não confiável ara a sua imlementação. Este artigo toma como base os rotocolos TCP e UDP, resectivamente confiável e não confiável, que reresentam as oções nativas da maioria dos sistemas oeracionais, ara avaliar o imacto de seu uso no funcionamento dos detectores de defeitos. Abstract The definition of failure detectors to be used on environments with crash failure hyothesis has some severe restrictions even in its weaker imlementations. Yet, failure detectors are ossible in distributed asynchronous systems, if we use technics to circumvent these restrictions, like the timeouts. During the construction of failure detectors, the need of reliable communication is an imortant factor: even if the definition if the failure detectors requires reliable communication, ractical exeriences show that we can use unreliable communication in its construction. This aer focuses on the native choices for reliable and unreliable communication, TCP and UDP, examining their imact on failure detectors' behavior. 1 Introdução Quanto mais genérico um sistema distribuído, mais amla é a sua ossibilidade de adatação aos diversos ambientes de oeração, e os sistemas distribuídos uramente assíncronos reresentam o modelo mais genérico utilizado. Há, no entanto, algumas restrições nesse modelo que aumentam a comlexidade das oerações nele realizadas, sobretudo na ossibilidade de falhas. Por exemlo, é conhecida a incaacidade de garantir o fechamento de uma oeração de consenso, uma das mais significativas oerações de acordo entre rocessos, em ambientes assíncronos sujeitos a falhas. Isso se deve à imossibilidade de determinar se um rocesso encontra-se falho ou aenas mais lento que os demais. Essa restrição, conhecida como Imossibilidade FLP (em homenagem aos seus autores, Fischer, Lynch e Paterson), ocasiona que, devido à falta de conhecimento sobre o sistema, o algoritmo de consenso deve eserar a resosta dos demais rocessos, sob risco de tornar as decisões inconsistentes. No caso da falha de um integrante do consenso, o algoritmo irá eserar indefinidamente. Essa restrição não afeta somente o consenso; muitas outras oerações freqüentemente utilizadas, como a votação e a difusão atômica, são tão ou mais comlexas que o consenso, e ficam sujeitas à mesma restrição de oeração. 1 Bolsista CNPq.

2 Existem algumas técnicas que objetivam contornar tais restrições, como or exemlo o sincronismo arcial e o assincronismo temorizado [GUE 97]. Tais roostas, entretanto, servem aenas a situações esecíficas, não contemlando as diversas ossibilidades do sistema. Chandra e Toueg [CHA 96] rouseram um modelo de assincronismo auxiliado or um detector de defeitos, que demonstrou ser mais abrangente e adatável que os demais [GUE 97]. Tais detectores funcionam através da manutenção de uma lista local, contendo os rocessos suseitos de falhas, baseada em mensagens trocadas entre os detectores. Esse controle dá-se de tal forma que, se um rocesso incorretamente considerado suseito voltar a enviar mensagens, este será retirado da lista de suseitos tantas vezes quanto necessário. Como ode-se erceber, os detectores não odem determinar com exatidão o estado dos rocessos do sistema, mas sua utilização aumenta o conhecimento sobre os demais elementos, auxiliando na finalização das oerações de consenso em temo hábil, sem que suosições incorretas sejam mantidas. 2 Detectores de Defeitos Chandra e Toueg definiram os detectores de defeitos através de duas roriedades a serem reseitadas: comleteness (abrangência, comleteza) e accuracy (recisão). A roriedade comleteness refere-se à caacidade do detector identificar todos os rocessos que estão falhos, enquanto accuracy determina a recisão desta suseita, a fim de evitar a inclusão de rocessos corretos nas listas de suseitos. Ao reseitar essas duas roriedades, um detector de defeitos garante que os algoritmos que o utilizem não erderão a consistência das decisões, nem ficarão indefinidamente bloqueados (reservando as roriedades safety e liveness, resectivamente). Segundo essas roriedades, um detector que continuamente inclua e remova os rocessos da sua lista de suseitos não é caaz de garantir as condições mínimas ao consenso, ois tal comortamento constitui uma violação da roriedade de accuracy dos detectores (or exemlo, accuracy em um detector considerado mais "fraco", Eventually Weak - <, diz que "há um instante de temo aós o qual um rocesso correto não é considerado suseito or nenhum rocesso correto"). A indeterminação que acomanha um ambiente assíncrono imediria a definição de um timeout adequado ao sistema, uma vez que semre oderia haver um rocesso mais lento. Os autores afirmam, entretanto, que em situações ráticas tais detectores oderão considerar timeouts "suficientemente longos", de modo que todos os rocessos corretos consigam resonder a temo. Outra oção, quando não é ossível determinar o máximo timeout suortável, é o uso de timeouts adatativos, onde o atraso de uma mensagem faz com que o temo de esera ela róxima seja incrementado em algumas unidades. Aesar dessa solução, a observação dos modelos de detectores mais utilizados (Push, Pull) indica que comumente utiliza-se timeouts fixos, ao invés de adatativos. A oção majoritária or soluções que utilizam timeout fixo leva a crer que mesmo nesses casos as suseitas incorretas são "aceitáveis" nos sistemas. De fato, tais situações devem-se ao rório comortamento dos detectores e ao ambiente de utilização mais comum deles. Quando um detector comete um engano, suas características fazem com que um rocesso correto seja suseito de falhas, e não o contrário, onde um rocesso falho é considerado correto. Como o exemlo mais usado do emrego dos detectores envolve os algoritmos de consenso, onde os detectores são usados ara acusar quando o coordenador está falho, uma detecção incorreta leva ao cancelamento da oeração, reservando as roriedades de safety e liveness da alicação. O trabalho que definiu os detectores de defeitos teve or objetivo demonstrar quais as situações onde o consenso é solúvel, e or conseguinte, determinou o ambiente de falhas (crash) eo modelo de comunicação (confiável) onde estas demonstrações eram ossíveis. Este artigo roõe uma análise esecífica do funcionamento dos detectores, ois estes aresentam exigências diferentes dos demais comonentes do sistema, de tal forma que algumas oções de imlementação (no caso deste estudo, a comunicação) oderiam ser alicadas nos detectores de modo diferente dos demais subsistemas.

3 3 Comunicação Confiável versus Comunicação Não Confiável Antes de mais nada, é necessário definir comunicação confiável. Este trabalho considera a definição de Aguilera [AGU 97]. Ele afirma que, quando um rocesso s invoca uma chamada de envio send r (m) e retorna à execução, assando a tarefa do envio aos níveis mais baixos do sistema oeracional, costuma-se dizer que o rocesso s comletou o envio da mensagem m ara r, sendo r o rocesso destino. Entretanto, o simles envio da mensagem não garante o recebimento, ois ode ocorrer que, logo aós s retornar da invocação, este rocesso entre em colaso (crash), antes que a mensagem seja realmente enviada ara r. Nesse instante, ode ocorrer uma inconsistência entre os dois rocessos. Para evitar isso, rimitivas de comunicação confiável estabelecem que se s enviou a mensagem m, er é um rocesso não falho (também chamado de correto), então r irá receber a mensagem, mesmo aós o crash de s. As roriedades que determinam essas características da comunicação confiável são as seguintes [AGU 97]: Integridade: ara todo k B 1, se r recebe a mensagem m de skvezes, então s enviou anteriormente a mensagem elo menos k vezes; No Loss (Sem Perdas): ara todo k B 1, se r é um rocesso correto e s comletou o envio da mensagem m ara r exatamente k vezes, então r receberá m de s ao menos k vezes. A maneira mais comum de construir tais rimitivas de envio confiável envolve a retransmissão sistemática da mensagem m até que o rocesso r devolva um ACK, confirmando o recebimento da mensagem. Só então, com a confirmação de r, é que a invocação de envio retorna o rocessamento ara s. Sob tais condições, s somente considerará a mensagem entregue aós a resosta de r. Casos falhe aós a resosta de r mas antes de retornar da invocação, quando s se recuerar, irá aenas enviar uma mensagem reetida, que é facilmente descartada or r. Numa rimeira análise, ode-se observar no funcionamento dos detectores de defeitos que eles não necessitam garantir a consistência com outros detectores durante sua oeração. De fato, é exlícito que os detectores trabalham aenas sobre suas erceções locais, odendo ter listas de suseitos comletamente diferentes em um mesmo instante de temo [CHA 96]. A formação desta "visão" local de cada detector deve ocorrer de modo instantâneo, ou seja, a cada momento a lista de suseitos ode mudar, exressando a erceção das novas mensagens recebidas. Essa ossibilidade de corrigir os enganos é uma característica essencial ara que os detectores sejam atos ao auxílio das oerações em sistemas distribuídos uramente assíncronos, e em sistemas ráticos odem ser considerados detectores que mudem suas listas de suseitos tantas vezes quantas forem necessárias. Quando se utiliza timeout ara detectar os defeitos, esse eríodo de temo deve ser estabelecido de forma que a detecção ocorra com o menor atraso ossível, orém sem induzir um número excessivo de falsas suseitas (como, or exemlo, na resença de rocessos mais lentos). De fato, utilizando-se aenas timeouts ara as mensagens, é imossível distinguir os casos de rocessos lentos ou falhos dos casos de mensagens extraviadas. Nos ambientes que suortam falhas or erdas de mensagens, os rotocolos que utilizam os detectores (o consenso, esecialmente) costumam agregar técnicas ara mascarar essas erdas, tal como a retransmissão de mensagens erdidas. Chandra e Toueg, quando analisaram um detector ara sistemas arcialmente síncronos com erda de mensagens, verificaram que, embora o detector de defeitos continuasse oeracional, já não era ossível imlementar o algoritmo de consenso sem que houvesse esse mascaramento das mensagens erdidas. Assim, mesmo que o algoritmo de consenso necessite a retransmissão de mensagens, sobre os detectores o efeito da retransmissão de mensagens terá o mesmo imacto do recebimento de novas mensagens, de forma que o uso de retransmissão ode vir a sobrecarregar a rede sem que a qualidade das mensagens influencie na detecção. Além disso, do onto de vista temoral, somente as mensagens novas oderão efetivamente auxiliar na recisão da detecção. Se além do uso de retransmissão de mensagens for realizado um ordenamento, comum em transmissões confiáveis, ode-se tornar o detector inadequado à oeração com rocessos de velocidades relativas muito diferentes. Um exemlo claro desta inadequação ode ser encontrado

4 numa das formas de imlementar o detector Pull. Neste modelo, um rocesso inicialmente questiona um rocesso q sobre seu estado, enviando mensagens do tio Are you alive?. Quando q recebe tais mensagens e encontra-se oeracional, envia uma resosta contendo algo como Yes, I am!. Imaginando um cenário onde um dos rocessos (no caso q) é muito lento, como mostra a figura 1, verifica-se que a lista de rocessos suseitos é corrigida aenas quando chegam as rimeiras resostas, no momento t n. Considerando que o rocesso q, a artir deste momento, irá resonder todas as mensagens em intervalos determinados or sua velocidade, este será retirado da lista de suseitos, ois estará resondendo dentro de um intervalo de temo eserado [SCH 00]. Se fosse utilizado um controle sobre o número de seqüência, à resosta da rimeira mensagem seria atribuído um atraso muito suerior ao limite de temo considerado, o que levaria à suseita do rocesso q mesmo que todas as suas mensagens chegassem em ordem a artir desse momento. Além disso, devido à menor velocidade de rocessamento de q, torna-se interessante rover o detector com timeout adatativo, sob o risco de causar um overhead nas oerações com a constante inclusão e remoção deste rocesso da lista de suseitos. T q suseito t n não há mais suseitos q atraso de q Are you alive? Yes, I am! Figura 1 - Exemlo de Funcionamento 4 Alternativas Exloradas elos Sistemas Práticos Os sistemas ráticos estudados costumam utilizar comunicação confiável, sobretudo ara mascarar ossíveis falhas no meio de comunicação. A não ser que o ambiente de falhas ermita a erda de mensagens, subentende-se que a mensagem deve chegar ao seu destino. Alguns exemlos de sistemas que se enquadram neste ambiente (comunicação confiável e meio não confiável) são: detector HeartBeat [AGU 97] - subentende uma conexão quase confiável, onde algumas mensagens odem ser erdidas, sem no entanto constituir uma artição na rede; o sistema de comunicação de gruo Bast [GAR 98] - considera o uso de fair lossy links, que também odem sofrer erdas eventuais de mensagens. detector ara ambientes com falhas or Muteness [DOU 99] - requer comunicação confiável ara distinguir o comortamento dos rocessos; sistema de comunicação de gruo OGS [FEL 98] - utiliza TCP devido ao ambiente CORBA ara que foi rojetado (embora ossa escolher entre chamadas RPC ou one-way); sistema de comunicação de gruo TOTEM [MOS 96] - mesmo utilizando multicast UDP, obriga o envio confiável das mensagens, ara controlar os timeouts e disarar as suseitas sobre os rocessos. De modo geral, verifica-se que a comunicação confiável é utilizada indistintamente ara todos os rotocolos do sistema, devido às restrições que o ambiente de falhas imõe. De fato, em certos rotocolos há a necessidade do mascaramento das falhas do meio de comunicação, sobretudo orque a consistência das decisões está em jogo. Este artigo questiona somente a necessidade deste

5 mascaramento no nível da detecção de defeitos, já que não há contribuição ara uma melhor detecção, nem a erda de mensagens constitui uma fonte de informações incorretas que levem à inconsistência dos rotocolos sueriores. Um detector cujas mensagens odem ser extraviadas ainda consegue ser suficientemente correto ara que não induza a inconsistência do sistema, sem que no entanto sua imlementação exija um grau de comlexidade mais elevado. 5 Imacto da Comunicação Não Confiável no Desemenho do Sistema Um asecto adicional do uso de comunicação não confiável refere-se ao desemenho do detector (ou mais esecificamente, o imacto do detector no desemenho global do sistema). Na rática, muitos sistemas distribuídos são construídos utilizando as rimitivas de comunicação fornecidas elos sistemas oeracionais, sobretudo os rotocolos TCP/IP e UDP/IP, confiável e não confiável, resectivamente. Embora não sejam ideais ara a utilização junto aos detectores de defeitos (é ossível, or exemlo, construir rotocolos confiáveis tão eficientes ou mais que o UDP), tais rotocolos ilustram bem as diferenças entre o uso de comunicação não confiável, com seu envio não bloqueante, mas sem garantia de entrega, e o uso de comunicação confiável, com garantia de entrega e retransmissão de mensagens erdidas, mas com características de envio bloqueante. Utilizando-se uma comaração entre os rotocolos TCP e UDP ode-se extrair diversos ontos onde o uso do TCP torna o sistema menos eficiente, odendo até comrometer a recisão da detecção: estabelecimento da conexão - se cada transmissão entre os detectores exigir um novo estabelecimento de conexão, o rotocolo TCP irá executar diversos hand-shakings antes de enviar as mensagens. Se for decidido criar uma conexão ermanente, há a necessidade de uma estrutura esecífica ara sua ersistência. O UDP aenas envia o datagrama, e confia que os níveis inferiores da rede irão transmitir a mensagem até seu destino; envio bloqueante - somente quando a confirmação de recebimento das mensagens chegar, o rotocolo TCP irá retornar o controle à alicação. Isso ode acarretar um grande atraso no envio da mensagem ara outros rocessos (esecialmente no caso de falhas de transmissão), odendo causar suseitas incorretas devido à falta de envio no razo eserado; entrega ordenada - o TCP faz uso de números de seqüência ara garantir a entrega ordenada das mensagens, e quando uma mensagem é erdida ou está atrasada, as outras somente serão entregues à alicação quando esta mensagem for recebida. Aesar do rotocolo TCP utilizar técnicas de slide windows ara minimizar este roblema, ode ocorrer um atraso na entrega das mensagens, atraalhando a instantaneidade da formação da lista de suseitos. Em outros subsistemas que não os detectores de defeitos, o estabelecimento de conexões do TCP oderia comor uma grande vantagem, devido à quantidade de dados a enviar. Entretanto, o conteúdo das mensagens dos detectores costuma ser mínimo, não justificando os esforços ara manter essas conexões abertas, ou ara reará-las caso uma detecção se mostre incorreta. A utilização de um rotocolo de comunicação confiável esecífico ara este roblema é a solução ótima ara os detectores, mas estes rotocolos normalmente não são nativos nos sistemas oeracionais e ossivelmente teriam que ser imlementados elo rório desenvolvedor do detector. Não obstante, nestes casos o rotocolo esecializado constitui uma solução bem mais adequada do que o uso dos rotocolos TCP ou UDP. Quando o desenvolvedor for obrigado a escolher entre os rotocolos nativos dos sistemas oeracionais, o TCP aresenta características que raticamente inviabilizam uma boa oeração de um detector. 6 Conclusões A conceção de um sistema distribuído normalmente inicia ela definição do modelo de falhas a ser tratado. Enquanto a escolha de um modelo mais restritivo facilita a conceção, ao mesmo temo aumenta a comlexidade da imlementação, ois as técnicas utilizadas ara adequar um sistema real ao modelo de falhas escolhido exigem níveis de comlexidade comatíveis com o que se deseja (um

6 exemlo é o uso de retransmissão ara esconder erdas de mensagens). Essa diferença de comlexidade usualmente faz com que cada modelo de falhas tenha imlementações esecíficas, e se tornou comum rescrever todos os comonentes do sistema, sem verificar o nível de comlexidade exigido ara cada comonente. Este artigo tentou demonstrar que, em sistemas ráticos, os detectores de defeitos odem ser construídos utilizando comunicação não confiável ara o suorte a sistemas com falhas or crash, uma vez que as erdas ocasionais de mensagens não levam a inconsistências do sistema, e a sua construção é bem menos comlexa do que utilizando comunicação confiável. Os demais subsistemas continuariam com comunicação confiável segundo suas exigências, mas os detectores oderiam ser construídos com rotocolos menos exigentes. O uso do rotocolo de comunicação não confiável nativo da maioria dos sistemas oeracionais (UDP), quando não existe nenhum rotocolo esecializado, ode tornar o imacto dos detectores de defeitos bem menor no desemenho final da alicação do que o corresondente rotocolo de comunicação confiável (TCP). Referências [AGU 97] AGUILERA, Marcos Kawazoe; CHEN, Wei; TOUEG, Sam. Heartbeat: a timeout-free failure detector for quiescent reliable communication. In: 11 th International Worksho on Distributed Algorithms, Proceedings..., Setembro Também ublicado como Technical Reort, Cornell University, Maio Disonível or WWW em htt://cstr.cs.cornell.edu:80 /Dienst/UI/1.0/Dislay/ncstrl.cornell/TR (11 Janeiro 2000) [CHA 96] CHANDRA, Tushar Deeak.; TOUEG, SAM. Unreliable Failure Detectors for Reliable Distributed Systems. Journal of the ACM, v. 43, n. 2, g , Março Também disonível or WWW em htt://cs-tr.cs.cornell.edu:80/dienst/ UI/1.0/Dislay /ncstrl.cornell/tr (12 Janeiro 2000) [DOU 99] DOUDOU, A.; GARBINATO, Benoît; GUERRAOUI, Rachid; and SCHIPER, André. Muteness Failure Detectors: Secification & Imlementation. In: Third Euroean Deendable Comuting Conference (EDCC-3), Proceedings..., Sringer Verlag, Suíça, Setembro Também disonível or WWW em htt:// ublications/rint_versions/df/dou99-1.df (9 Maio 2000) [FEL 98] FELBER, Pascal. The CORBA Object Grou Service, Tese de Doutorado, École Polytechnique Fédérale de Lausanne, Suíça, Disonível or WWW em htt://lsewww.efl.ch/ogs/thesis/ (12 Janeiro 2000) [FIS 85] FISCHER, Michael J.; LYNCH, Nancy A.; PATERSON, Michael S. Imossibility of distributed consensus with one faulty rocess. Journal of the ACM, v. 32, n. 2, g , [GAR 98] GARBINATO, Benoît. Protocol Objects and Patterns for Structuring Reliable Distributed Systems, Tese de Doutorado, École Polytechnique Fédérale de Lausanne, Suíça, Disonível or WWW em htt://lsewww.efl.ch/garbinato/phd/ (11 Janeiro 2000). [GUE 97] GUERRAOUI, Rachid; SCHIPER, André. Consensus: The Big Misunderstanding. In: IEEE International Worksho on Future Trends in Distributed Comuting Systems (FTDCS'97), Outubro Proceedings... Também disonível or WWW em htt://lsewww.efl.ch/~rachid/aers/ftdcs2-97.s (12 Janeiro 2000) [MOS 96] MOSER, L. E.; MELLIAR-SMITH, P. M.; AGARWAL, D. A.; BUDHIA, R. K., LINGLEY-PAPADOPOULUS, C. A. Totem: A Fault-Tolerant Multicast Grou Communication System. Communications of the ACM, v. 39, n. 4, g 54-63, Abril [SCH 00] SCHIPER, André. Imlementação de um detector Pull, Março Comunicação essoal or .