XI Workshop de Testes e TolerÃ¢ncia a Falhas (WTF) - SBRC 2010

More documents

Recommendations

Info

6 Anais consenso para o modelo assíncrono, desenvolvidos a partir de algoritmos existentes para o modelo de falhas crash-stop. O algoritmo Paxos, apresentado por Lamport em [Lamport 1998, Lamport 2001], executa sobre um sistema assíncrono dotado de um mecanismo para eleição de líder que apresente a propriedade mínima de que em algum momento de sua execução irá indicar como líder um processo que não irá falhar, o que irá garantir a terminação do protocolo. O Paxos tolera a recuperação de defeitos, desde que uma maioria dos processos esteja correta, para garantir tanto a terminação quanto o acordo uniforme. Diferente destes algoritmos propostos para o consenso, assumimos um modelo híbrido de sistema distribuídos, no qual existem componentes síncronos e assíncronos. 3. Modelo Spa (Partitioned Synchronous) Um sistema é composto por conjunto Π = {p 1 , p 2 , ..., p n } de processos que estão distribuídos em sítios possivelmente distintos de uma rede de computadores e por um conjunto χ = {c 1 , c 2 , ..., c m } de canais de comunicação. Sítios computacionais formam topologias arbitrárias e processos se comunicam por meio de protocolos de transporte fim-a-fim. A comunicação fim-a-fim define canais que podem incluir várias conexões físicas no nível da rede. Portanto, um canal de comunicação c i conectando processos p i e p j define uma relação do tipo "é possível se comunicar" entre p i e p j , ao invés de uma conexão ao nível da rede entre as máquinas que hospedam p i e p j . Assumimos que o sistema definido por processos e canais de comunicação forma o grafo simples e completo DS(Π, χ) com (n × (n − 1))/2 arestas. Particionamento de rede não é considerado em nosso modelo. Um processo tem acesso a um relógio local com taxa de desvio limitado por ρ. Processos e canais de comunicação podem ser timely ou untimely. Timely/untimely é equivalente a synchronous/asynchronous como apresentado em [Dwork et al. 1988]. Contudo, os modelos parcialmente síncronos considerados em [Dwork et al. 1988] não consideram configurações híbridas onde alguns processos/canais são síncronos e outros assíncronos. Um processo p i é dito timely se existe um limite superior (upper-bound) φ para a execução de um passo de computação por p i . De forma análoga, um canal c i é timely se existe um limite superior δ para o atrazo de transmissão de uma mensagem em c i , e c i conecta dois processos timely. Caso essas condições não se verifiquem, processos e canais são ditos untimely e os respectivos limites superiores são finitos, porém arbitrários. Um canal c i = (p i , p j ) implementa transmissão de mensagem em ambas as direções, de p i para p j e de p j para p i . δ and φ são parâmetros do sistema computacional subjacente, fornecidos por mecanismos adequados de sistemas operacionais e redes de tempo real. Também assumimos que os processos em Π sabem a QoS de todos os processos e canais antes da execução da aplicação. É assumido a existência de um oráculo de timeliness definido pela função QoS que mapeia processos e canais para valores T ou U (timely ou untimely). Portanto, tal oráculo informa os processos sobre a QoS atual em termos de timeliness de processos e canais de comunicação. O oráculo é assumido ser preciso: a execução de QoS(x) no instante t retorna T/U se e somente se a QoS do elemento x (processo ou canal) no instante t for timely/untimely. Uma vez que assumimos que a QoS dos processos e canais é estática e conhecida, uma implementação trivial para o oráculo pode ser realizada durante uma fase de inicialização do
XI Workshop de Testes e Tolerância a Falhas 7 sistema: por exemplo, mantendo dois arrays binários, um para processos e outro para canais, cujo valor "1" or "0" representa timely e untimely, respectivamente. Canais de comunicação são assumidos como confiáveis: não perdem ou alteram mensagens. Processos falham por parada silenciosa, mas podem recuperar-se (crash/recovery). Como em [Aguilera et al. 1998], assumimos que processos podem falhar e se recuperar seguidamente, apresentando um comportamento instavel. Estes processos podem manter este comportamento instável durante o tempo todo, ou a partir de algum momento no tempo se tornar permanentemente em execução, ou em crash. Um processo que não falha durante um intervalo de tempo de interesse, ou que após um tempo de instabilidade não mais falha, é considerado correto. Sub-grafos Síncronos e Assíncronos Dado Π ′ ⊆ Π, Π ′ ≠ ∅ e χ ′ ⊆ χ, um sub-grafo de comunicação conectado C(Π ′ , χ ′ ) ⊆ DS(Π, χ) é síncrono se ∀p i ∈ Π ′ and ∀c j ∈ χ ′ , p i e c j são timely. Se essas condições não se verificam, C(Π ′ , χ ′ ) é dito não síncrono. Utilizamos a notação Cs para denotar um sub-grafo síncrono e Ca para um sub-grafo não síncrono. Partições Síncronas Dado Cs(Π ′ , χ ′ ), definimos partição síncrona como o maior sub-grafo P s(Π ′′ , χ ′′ ), tal que Cs ⊆ P s. Em outras palavras, DS não contém Cs ′ (Π ′′′ , χ ′′′ ) ⊃ Cs com |Π ′′′ | > |Π ′′ |. Assumimos que existe pelo menos um processo correto em cada partição síncrona 1 . No sistema distribuido Spa, a propriedade de strong partitioned synchrony é necessaria para implementar detecção perfeita de defeitos como demonstrado em [Macêdo and Gorender 2009] strong partitioned synchrony: (∀p i ∈ Π)(∃P s ⊂ DS)(p i ∈ P s). Observamos ainda que o fato de P s ⊂ DS exclui dessa especificação sistemas tipicamente síncronos com uma única partição com todos os processos do sistema. Em Spa, mesmo que strong partitioned synchrony não possa ser satisfeita, é possível tirar proveito das partições síncronas existentes para implementar detectores parcialmente perfeitos, desde que alguma partição síncrona exista [Macêdo and Gorender 2009]. Definimos essa propriedade a seguir. weak partitioned synchrony: o conjunto não vazio de processos que pertencem a partições síncronas é um sub-conjunto próprio de Π. Mais precisamente, assumindo que existe pelo menos uma partição síncrona P s x : (∃p i ∈ Π)(∀P s x ⊂ DS)(p i /∈ P s x ). No que se segue exploramos as propriedades de strong partitioned synchrony e weak partitioned synchrony sobre Spa para implementar um algoritmo de consenso onde processos podem falhar e se recuperar. 4. Consenso com Recuperação no Modelo Spa Como já visto anteriormente, assumimos o modelo de falhas crash-recovery, no qual os processos podem falhar por colapso, e se recuperar, voltando a executar protocolos distribuídos 1 Observe que essa hipótese é bastante plausível se consideramos clusters (partições síncronas) com tamanhos razoáveis - digamos, com mais de três unidades por cluster
Page 1 and 2: XXVIII Simpósio Brasileiro de Rede
Page 3 and 4: XI Workshop de Testes e Tolerância
Page 13: XI Workshop de Testes e Tolerância
Page 16 and 17: 4 Anais tais problemas. Portanto, h
Page 20 and 21: 8 Anais em andamento (por exemplo,
Page 22 and 23: 10 Anais cada partição síncrona,
Page 24 and 25: 12 Anais A tarefa T 4 é executada
Page 26 and 27: 14 Anais • Assumimos que o proces
Page 28 and 29: 16 Anais Veríssimo, P. and Casimir
Page 30 and 31: 18 Anais Entretanto, em caso de fal
Page 32 and 33: 20 Anais à aplicação: SafeSendT
Page 34 and 35: 22 Anais Na fase de inicialização
Page 36 and 37: 24 Anais acesso a C e nem a C d . E
Page 38 and 39: 26 Anais Prova. 1. Se t + 1 /∈ C
Page 40 and 41: 28 Anais algoritmo de término. Vá
Page 42 and 43: 30 Anais instantânea. Além disso,
Page 44 and 45: 32 Anais [Chandra and Toueg 1996].
Page 46 and 47: 34 Anais Every JXTA-FD instance exe
Page 48 and 49: 36 Anais 3.4. GossipTask A rotina G
Page 50 and 51: 38 Anais mecanismo foi adotado para
Page 52 and 53: 40 Anais Tempo de Detecção e Recu
Page 54 and 55: 42 Anais nout em relação à exati
Page 56 and 57: 44 Anais Fischer, M. J., Lynch, N.
Page 58 and 59: 46 Anais 1. Introdução Sistemas d
Page 60 and 61: 48 Anais canais de comunicação co
Page 62 and 63: 50 Anais Figura 1. Interface do QoS
Page 64 and 65: 52 Anais onde as aplicações solic
Page 66 and 67: 54 Anais • QOSP _REGIST ER: Esta
Page 68 and 69:
56 Anais O DSCP utilizado para o Se
Page 70 and 71:
58 Anais seu destino, enquanto que
Page 73 and 74:
XI Workshop de Testes e Tolerância
Page 75 and 76:
Page 77 and 78:
Page 79 and 80:
Page 81 and 82:
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101:
Page 104 and 105:
92 Anais geralmente baseados nos gr
Page 106 and 107:
94 Anais Os parâmetros podem repre
Page 108 and 109:
96 Anais Um exemplo de configuraç
Page 110 and 111:
98 Anais E. Evolução O Módulo Ev
Page 112 and 113:
100 Anais Tabela 1: Cobertura obtid
Page 114 and 115:
102 Anais ineditismo, o que parece
Page 116 and 117:
104 Anais Evaluation of Novel Appro
Page 118 and 119:
106 Anais protocolo; (2) verificaç
Page 120 and 121:
108 Anais Uma MEF pode ser represen
Page 122 and 123:
110 Anais se dá em uma seqüência
Page 124 and 125:
112 Anais 1 2 3 4 5 Data: MEF M e C
Page 126 and 127:
114 Anais (a) Variação do número
Page 128 and 129:
116 Anais Fujiwara, S., Bochman, G.
Page 131 and 132:
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Page 149 and 150:
Page 151 and 152:
Page 153 and 154:
Page 155 and 156:
Page 157:
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
Page 167 and 168:
Page 169 and 170:
Page 171 and 172:
Page 173 and 174:
Page 175 and 176:
Page 177 and 178:
Page 179 and 180:
Page 181 and 182:
Page 183 and 184:
Page 185 and 186:
Page 187 and 188:
Page 189:
show all

XI Workshop de Testes e TolerÃ¢ncia a Falhas (WTF) - SBRC 2010

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?