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

84 CAPÍTULO 6. NÚCLEO DO SISTEMA DOORS n_seq identifica univocamente a sequência de operações no conjunto das sequências de operações recebi- das nesse servidor. Com base nestes identificadores, cada coobjecto mantém um sumário (vector versão) das operações conhecidas localmente, um sumário (vector versão) das operações executadas localmente, e um sumário (vector versão ou matriz) das operações que se sabe serem conhecidas nas outras réplicas. Estes sumários são actualizados durante as sessões de sincronização e aquando da recepção e execução das operações. O sumário das operações executadas localmente (conjuntamente com o identificador da vista no qual ele é válido) chama-se versão do coobjecto. 6.1.6 Sistema de nomes A camada de designação simbólica permite às aplicações usar nomes simbólicos para se referirem aos volumes e aos coobjectos. Assim, esta camada define um conjunto de funções que permitem manipular os volumes e os coobjectos usando nomes simbólicos. Estas funções convertem os nomes simbólicos nos identificadores únicos usados pelo sistema e invocam as operações respectivas na API do sistema. O nome simbólico de um coobjecto tem a seguinte forma: [//servidor][/volume :]nome, com servidor o nome do servidor em que o nome deve ser resolvido, volume o nome do volume e nome o nome do coobjecto que se pretende designar. Cada volume possui um identificador único gerado automaticamente aquando da sua criação e um nome simbólico especificado pelo utilizador. Quando se usa um nome simbólico para identificar um volume, o nome é resolvido no servidor indicado. Caso o servidor não seja indicado, o nome é resolvido localmente. Ocorre um erro caso não se conheça nenhum volume com o nome indicado ou se existir mais do que um volume com esse nome. Nestes casos, a aplicação deve usar uma função do sistema (listVolumeIds) para obter a lista de identificadores de volumes com um dado nome — o resultado desta operação não é necessariamente completo (a execução da operação recorre ao serviço de descoberta que se apresenta na secção 6.2.3). Os identificadores dos volumes são expostos como cadeias de caracteres compostas pelo nome simbólico e por uma representação do identificador único. Estes identificadores podem ser usados para designar um volume de forma única. Cada volume define um espaço hierárquico de nomes (semelhante ao espaço de nomes definido num sistema de ficheiros), em que cada nome é associado a um identificador único de um coobjecto. Esta associação é mantida no coobjecto directório global, idêntico ao descrito na secção 3.3.10 3 Este coobjecto tem um identificador único bem-definido no volume (igual para todos os volumes). Quando um coobjecto é gravado pela primeira vez, a camada de designação adiciona ao directório 3 Relativamente à descrição da secção 3.3.10, este coobjecto permite a definição adicional de ligações simbólicas (symbolic links) através de um subobjecto criado para o efeito.

6.2. SERVIDORES 85 global a associação entre o nome atribuído pela aplicação e o identificador único do coobjecto. A in- terpretação de um nome simbólico é efectuada obtendo, no coobjecto directório global, o identificador único associado a esse nome. Quando se executa a função da API do sistema (definida na camada de designação) para remover um coobjecto, remove-se adicionalmente a associação entre o nome e o identificador desse coobjecto (submetendo a operação de remoção respectiva no directório global). Quando um coobjecto removido é “ressuscitado” pela existência de operações concorrentes com a operação de remoção, é criada uma nova associação entre um nome pertencente a um directório especial e o identificador único do coobjecto. A adição do novo nome é submetida apenas no servidor que recebeu a operação de remoção do coobjecto. Esta responsabilidade é delegada (no patrocinador) no caso de o servidor cessar a replicação do volume. 6.2 Servidores Os servidores replicam volumes de coobjectos usando uma estratégia optimista. Esta aproximação per- mite fornecer aos clientes um elevada disponibilidade dos dados para operações de leitura e escrita, permitindo mascarar (algumas) falhas nos servidores e no sistema de comunicações. Um servidor é responsável por gerir a cópia local de cada volume, incluindo uma cópia de cada coobjecto contido no volume replicado. Os servidores comunicam entre si para sincronizar o estado das réplicas locais. Adicionalmente, os servidores fornecem uma interface para administrar o servidor e aceder aos coobjectos. Assim, os utilizadores (administradores do sistema) podem criar novos volumes e gerir o conjunto de servidores que replicam cada volume. Para tal, os utilizadores submetem as operações que desejam efectuar num cliente que as propaga para o(s) servidor(es) apropriado(s). Os clientes podem ainda obter cópias de coobjectos e submeter operações de modificação (em consequência das acções executadas pelos utilizadores). Nesta secção descreve-se o funcionamento do servidor, incluindo os vários protocolos executados no protótipo do sistema DOORS. 6.2.1 Volumes e filiação Um volume é um contentor de coobjectos replicado por um grupo variável de servidores. Um volume é criado num servidor em resultado de uma operação (createVolume) submetida por um utilizador (admi- nistrador do sistema). Um servidor inicia ou cessa a replicação de um volume em resultado de operações (replicateVolume e unreplicateVolume respectivamente) submetidas pelos utilizadores. Estas operações levam à execução de protocolos de inserção/remoção de um servidor no grupo de replicadores de um volume. Estes protocolos são iniciados pelo servidor que inicia/cessa a replicação do volume e têm a participação de apenas um outro servidor, que se designa de patrocinador.

6.2. SERVIDORES 85<br />

global a associação entre o nome atribuído pela aplicação e o i<strong>de</strong>ntificador único do coobjecto. A in-<br />

terpretação <strong>de</strong> um nome simbólico é efectuada obtendo, no coobjecto directório global, o i<strong>de</strong>ntificador<br />

único associado a esse nome.<br />

Quando se executa a função da API do sist<strong>em</strong>a (<strong>de</strong>finida na camada <strong>de</strong> <strong>de</strong>signação) para r<strong>em</strong>over<br />

um coobjecto, r<strong>em</strong>ove-se adicionalmente a associação entre o nome e o i<strong>de</strong>ntificador <strong>de</strong>sse coobjecto<br />

(submetendo a operação <strong>de</strong> r<strong>em</strong>oção respectiva no directório global). Quando um coobjecto r<strong>em</strong>ovido é<br />

“ressuscitado” pela existência <strong>de</strong> operações concorrentes com a operação <strong>de</strong> r<strong>em</strong>oção, é criada uma nova<br />

associação entre um nome pertencente a um directório especial e o i<strong>de</strong>ntificador único do coobjecto. A<br />

adição do novo nome é submetida apenas no servidor que recebeu a operação <strong>de</strong> r<strong>em</strong>oção do coobjecto.<br />

Esta responsabilida<strong>de</strong> é <strong>de</strong>legada (no patrocinador) no caso <strong>de</strong> o servidor cessar a replicação do volume.<br />

6.2 Servidores<br />

Os servidores replicam volumes <strong>de</strong> coobjectos usando uma estratégia optimista. Esta aproximação per-<br />

mite fornecer aos clientes um elevada disponibilida<strong>de</strong> dos <strong>dados</strong> para operações <strong>de</strong> leitura e escrita,<br />

permitindo mascarar (algumas) falhas nos servidores e no sist<strong>em</strong>a <strong>de</strong> comunicações.<br />

Um servidor é responsável por gerir a cópia local <strong>de</strong> cada volume, incluindo uma cópia <strong>de</strong> cada<br />

coobjecto contido no volume replicado. Os servidores comunicam entre si para sincronizar o estado<br />

das réplicas locais. Adicionalmente, os servidores fornec<strong>em</strong> uma interface para administrar o servidor e<br />

ace<strong>de</strong>r aos coobjectos. Assim, os utilizadores (administradores do sist<strong>em</strong>a) po<strong>de</strong>m criar novos volumes e<br />

gerir o conjunto <strong>de</strong> servidores que replicam cada volume. Para tal, os utilizadores submet<strong>em</strong> as operações<br />

que <strong>de</strong>sejam efectuar num cliente que as propaga para o(s) servidor(es) apropriado(s). Os clientes po<strong>de</strong>m<br />

ainda obter cópias <strong>de</strong> coobjectos e submeter operações <strong>de</strong> modificação (<strong>em</strong> consequência das acções<br />

executadas pelos utilizadores). Nesta secção <strong>de</strong>screve-se o funcionamento do servidor, incluindo os<br />

vários protocolos executados no protótipo do sist<strong>em</strong>a DOORS.<br />

6.2.1 Volumes e filiação<br />

Um volume é um contentor <strong>de</strong> coobjectos replicado por um grupo variável <strong>de</strong> servidores. Um volume é<br />

criado num servidor <strong>em</strong> resultado <strong>de</strong> uma operação (createVolume) submetida por um utilizador (admi-<br />

nistrador do sist<strong>em</strong>a). Um servidor inicia ou cessa a replicação <strong>de</strong> um volume <strong>em</strong> resultado <strong>de</strong> operações<br />

(replicateVolume e unreplicateVolume respectivamente) submetidas pelos utilizadores. Estas operações<br />

levam à execução <strong>de</strong> protocolos <strong>de</strong> inserção/r<strong>em</strong>oção <strong>de</strong> um servidor no grupo <strong>de</strong> replicadores <strong>de</strong> um<br />

volume. Estes protocolos são iniciados pelo servidor que inicia/cessa a replicação do volume e têm a<br />

participação <strong>de</strong> apenas um outro servidor, que se <strong>de</strong>signa <strong>de</strong> patrocinador.

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

Saved successfully!

Ooh no, something went wrong!