gestão de dados partilhados em ambientes de computação móvel

gestão de dados partilhados em ambientes de computação móvel gestão de dados partilhados em ambientes de computação móvel

asc.di.fct.unl.pt
from asc.di.fct.unl.pt More from this publisher
11.04.2013 Views

200 APÊNDICE A. DOORS lado, na cópia j, tem-se necessariamente v[m] < n, porque a execução de op j, posterior a opi, impede esta de ser executada (e a ordem definida garante que nenhuma outra operação submetida no servidor identificado por m pode ser executada). Nesta cópia, é impossível que o servidor associado a m tenha sido removido (porque o modo de funcionamento do coobjecto garante que uma operação de remoção apenas é executada após a execução de todas as operações submetidas nesse servidor). Desta forma, a execução de dois conjuntos diferentes de operações leva a que o identificador da vista seja igualmente diferente. A.1.2 Protocolo local de mudança de vista O protocolo local de mudança de vista é executado localmente num servidor sempre que é necessário modificar o estado do coobjecto de filiação. Este protocolo executa, de forma atómica, as actualizações necessárias nos identificadores dos servidores usados em todos os coobjectos do volume. No fim da execução do protocolo diz-se que foi instalada a vista definida pelo coobjecto de filiação. O protocolo local de mudança de vista consiste nos seguintes passos executados no servidor i, dado um conjunto de operações a executar sobre o coobjecto de filiação: 1. Qualquer acesso à cópia do volume no servidor i é impedido (incluindo os acessos aos coobjectos pertencentes a esse volume). 2. São executadas as operações desejadas no coobjecto de filiação (que podem incluir operações recebidas de outro servidor). O estado final do coobjecto define a nova vista que vai ser instalada na cópia do volume. 3. Se um novo identificador de vista foi definido (i.e., se foi executada alguma operação que al- tere a filiação), todos os coobjectos são informados da nova vista e das mudanças necessárias para converter os identificadores antigos nos novos. Normalmente, os identificadores já existentes mantêm-se e não é necessário executar nenhuma acção nos coobjectos. 4. O protocolo termina e permite-se, de novo, o acesso à cópia do volume. Se durante a execução do protocolo existir alguma falha no servidor, o protocolo volta a ser reiniciado no ponto onde falhou. As falhas na execução do protocolo são detectadas da seguinte forma. O início do protocolo é registado em memória estável, onde se guarda a data de início — após a conclusão do protocolo esta informação é removida. Quando um servidor é reiniciado, qualquer registo de início do protocolo na memória estável corresponde a uma execução não terminada. Uma falha durante o passo 2 é detectada pelo facto de o estado do coobjecto de filiação guardado em memória estável ter uma data são submetidas).

A.1. FILIAÇÃO 201 anterior à de início de protocolo. A detecção de falhas durante a execução do passo 3 é efectuada de forma idêntica para cada coobjecto. A.1.3 Protocolo de entrada no grupo de replicadores de um volume O protocolo de entrada no grupo de replicadores de um volume controla a entrada de um novo servidor no grupo de servidores que replicam um volume. Nesta situação, é necessário actualizar o coobjecto de filiação e propagar um cópia do volume para o novo servidor. O protocolo de entrada no grupo de replicadores de um volume v do servidor i, tendo como patroci- nador o servidor j pertencente ao grupo de replicadores de v, tem os seguintes passos: 1. i comunica a j o desejo de entrar no grupo e indica-lhe o identificador único que usará idi. Até à conclusão do protocolo, o servidor j fica impedido de participar em protocolos de remoção voluntária do grupo de replicadores. 2. O servidor j executa o protocolo local de mudança de vista no volume v usando a operação de inserção no grupo do servidor i com identificador único idi. 3. O servidor j envia para o servidor i o estado actual da sua cópia do volume durante uma sessão de sincronização epidémica, incluindo uma cópia de todos os coobjectos existentes — quando uma cópia de um coobjecto é instanciada pela primeira vez num servidor, é executada uma operação na interface do coobjecto a informar o coobjecto dessa situação. Após a recepção do coobjecto de filiação, o servidor i pode iniciar imediatamente a sua operação (embora se espere pela recepção de todo o estado do volume, a menos que exista alguma falha). Se durante a execução do protocolo existir alguma falha, o protocolo é reiniciado, reexecutando o passo em que falhou — as falhas no passo 2 são resolvidas como explicado anteriormente. As falhas durante a propagação do estado do volume são resolvidas através da execução de uma nova sessão de sincronização epidémica. A.1.3.1 Condições suficientes para a ordenação correcta de operações usando técnicas de verifi- cação da estabilidade da ordem Quando um novo servidor se junta ao grupo de replicadores de um volume, o seu identificador é provi- sório até se garantir que a operação de inserção executada no coobjecto de filiação não será desfeita no futuro. Assim, quando se usam as técnicas de estabilidade descritas na secção 4.1, não se deve usar a informação relativa aos servidores que têm identificadores provisórios 3 . 3 O identificador de um servidor adicionado ao grupo de replicadores de um volume pela operação de adição com identifica- dor (srvvol,n_seq) é provisório sse essa operação de adição ainda não foi ordenada de forma definitiva na réplica do coobjecto

200 APÊNDICE A. DOORS<br />

lado, na cópia j, t<strong>em</strong>-se necessariamente v[m] < n, porque a execução <strong>de</strong> op j, posterior a opi, impe<strong>de</strong><br />

esta <strong>de</strong> ser executada (e a or<strong>de</strong>m <strong>de</strong>finida garante que nenhuma outra operação submetida no servidor<br />

i<strong>de</strong>ntificado por m po<strong>de</strong> ser executada). Nesta cópia, é impossível que o servidor associado a m tenha<br />

sido r<strong>em</strong>ovido (porque o modo <strong>de</strong> funcionamento do coobjecto garante que uma operação <strong>de</strong> r<strong>em</strong>oção<br />

apenas é executada após a execução <strong>de</strong> todas as operações submetidas nesse servidor). Desta forma, a<br />

execução <strong>de</strong> dois conjuntos diferentes <strong>de</strong> operações leva a que o i<strong>de</strong>ntificador da vista seja igualmente<br />

diferente.<br />

A.1.2 Protocolo local <strong>de</strong> mudança <strong>de</strong> vista<br />

O protocolo local <strong>de</strong> mudança <strong>de</strong> vista é executado localmente num servidor s<strong>em</strong>pre que é necessário<br />

modificar o estado do coobjecto <strong>de</strong> filiação. Este protocolo executa, <strong>de</strong> forma atómica, as actualizações<br />

necessárias nos i<strong>de</strong>ntificadores dos servidores usados <strong>em</strong> todos os coobjectos do volume. No fim da<br />

execução do protocolo diz-se que foi instalada a vista <strong>de</strong>finida pelo coobjecto <strong>de</strong> filiação.<br />

O protocolo local <strong>de</strong> mudança <strong>de</strong> vista consiste nos seguintes passos executados no servidor i, dado<br />

um conjunto <strong>de</strong> operações a executar sobre o coobjecto <strong>de</strong> filiação:<br />

1. Qualquer acesso à cópia do volume no servidor i é impedido (incluindo os acessos aos coobjectos<br />

pertencentes a esse volume).<br />

2. São executadas as operações <strong>de</strong>sejadas no coobjecto <strong>de</strong> filiação (que po<strong>de</strong>m incluir operações<br />

recebidas <strong>de</strong> outro servidor). O estado final do coobjecto <strong>de</strong>fine a nova vista que vai ser instalada<br />

na cópia do volume.<br />

3. Se um novo i<strong>de</strong>ntificador <strong>de</strong> vista foi <strong>de</strong>finido (i.e., se foi executada alguma operação que al-<br />

tere a filiação), todos os coobjectos são informados da nova vista e das mudanças necessárias<br />

para converter os i<strong>de</strong>ntificadores antigos nos novos. Normalmente, os i<strong>de</strong>ntificadores já existentes<br />

mantêm-se e não é necessário executar nenhuma acção nos coobjectos.<br />

4. O protocolo termina e permite-se, <strong>de</strong> novo, o acesso à cópia do volume.<br />

Se durante a execução do protocolo existir alguma falha no servidor, o protocolo volta a ser reiniciado<br />

no ponto on<strong>de</strong> falhou. As falhas na execução do protocolo são <strong>de</strong>tectadas da seguinte forma. O início<br />

do protocolo é registado <strong>em</strong> m<strong>em</strong>ória estável, on<strong>de</strong> se guarda a data <strong>de</strong> início — após a conclusão do<br />

protocolo esta informação é r<strong>em</strong>ovida. Quando um servidor é reiniciado, qualquer registo <strong>de</strong> início do<br />

protocolo na m<strong>em</strong>ória estável correspon<strong>de</strong> a uma execução não terminada. Uma falha durante o passo 2<br />

é <strong>de</strong>tectada pelo facto <strong>de</strong> o estado do coobjecto <strong>de</strong> filiação guardado <strong>em</strong> m<strong>em</strong>ória estável ter uma data<br />

são submetidas).

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!