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

88 CAPÍTULO 6. NÚCLEO DO SISTEMA DOORS Para garantir estas propriedades, adicionou-se ao coobjecto de filiação uma operação de dissemina- ção e execução, detalhada no apêndice A.1.5. Esta operação permite executar uma acção dada como parâmetro apenas após a réplica do volume num servidor reflectir todas as operações conhecidas num dado conjunto de servidores no momento da submissão da operação de disseminação e execução. O protocolo de eliminação de um identificador, detalhado no apêndice A.1.6, é iniciado pelo patro- cinador da remoção e consiste nos seguintes passos. Primeiro, o patrocinador usa a operação de disse- minação e execução para garantir que nos vários servidores, apenas se inicia o processo de eliminação do servidor após terem sido propagadas todas as operações de todos os coobjectos recebidas do servidor removido. Segundo, cada servidor notifica os outros quando verifica que nenhum coobjecto necessita do identificador do servidor removido. Terceiro, quando num servidor se verifica que nenhum servidor activo necessita do identificador de um servidor, é submetida a operação de eliminação do identificador. Protocolo de saída forçada do grupo de replicadores Em geral, um servidor apenas cessa a repli- cação de um volume por sua iniciativa. No entanto, existem circunstâncias em que pode ser necessário forçar a remoção de um servidor do grupo de replicadores — por exemplo, porque o servidor ficou danificado e a memória estável na qual estava armazenado o estado dos coobjectos é irrecuperável. O protocolo de saída forçada do grupo de replicadores, detalhado no apêndice A.1.7, usa a seguinte aproximação. Primeiro, qualquer servidor pode sugerir a remoção de um (ou mais) servidor(es), mas o processo apenas prosseguirá se todos os outros servidores concordarem com a remoção. Segundo, após eleger um servidor como patrocinador da remoção, é necessário garantir que esse servidor recebe todas as operações conhecidas provenientes do servidor a remover. Terceiro, o servidor informa todos os coobjectos do volume da remoção do servidor e, de seguida, executa a operação de remoção no coobjecto de filiação no âmbito do protocolo local de mudança de vista. Protocolo de sincronização de vistas No sistema DOORS, dois servidores apenas podem comunicar para sincronizar o estado dos coobjectos se se encontrarem na mesma vista. Assim, dois servidores, i e j, que se encontrem em vistas diferentes devem executar previamente um protocolo de sincronização de vistas. Este protocolo consiste na sincronização das operações do coobjecto de filiação conhecidas pelos dois servidores — quando cada um dos servidores recebe o conjunto de operações enviadas pelo parceiro efectua o protocolo local de mudança de vista. No final do protocolo, conhecidas as mesmas operações relativas ao coobjecto de filiação, os dois servidores encontram-se na mesma vista. Durante a sincronização das operações conhecidas, cada servidor envia para o parceiro apenas as operações que sabe que ele não conhece — usando o sumário das operações conhecidas no parceiro (ou à falta deste sumário) o identificador da vista, que é igualmente um sumário das operações de inserção e remoção que o parceiro conhece.

6.2. SERVIDORES 89 6.2.2 Sincronização epidémica dos servidores Os servidores sincronizam as réplicas dos coobjectos de um volume durante sessões de sincronização epidémica [38] estabelecidas entre pares de servidores. Durante estas sessões, os servidores propagam entre si as operações de modificação que conhecem (independentemente do servidor no qual foram rece- bidas pela primeira vez). Desta forma, cada servidor recebe, para cada coobjecto, todas as modificações submetidas em todos os servidores, directa ou indirectamente. No sistema DOORS, considera-se que duas réplicas de um mesmo coobjecto estão sincronizadas quando conhecem o mesmo conjunto de ope- rações (e os sumários das operações conhecidas e executadas localmente e das operações conhecidas nos outros servidores são idênticos). No sistema DOORS, definiram-se dois protocolos de propagação epidémica. O primeiro protocolo é bilateral e durante a sua execução cada um dos servidores propaga as operações que conhece para o parceiro. O segundo protocolo é unilateral e apenas um dos servidores propaga as operações conhecidas para o parceiro. Protocolo de propagação epidémica bilateral O protocolo de propagação epidémica bilateral, de- talhado no apêndice A.2.2, consiste numa sequência de passos executados assincronamente — em cada um dos passos um servidor processa as mensagens recebidas e envia mensagens para o seu parceiro. Em cada um dos passos, e relativamente a cada um dos coobjectos a sincronizar, é possível: (1) solicitar o envio das operações não reflectidas num sumário; (2) enviar um conjunto de operações e solicitar o envio das operações não reflectidas num sumário; (3) solicitar o envio de uma cópia do coobjecto; (4) enviar uma cópia do coobjecto; (5) enviar a informação que o coobjecto foi eliminado. O protocolo de sincronização bilateral é iniciado com o servidor i a pedir que o parceiro lhe envie, para cada um dos coobjectos a sincronizar, as operações não reflectidas no sumário das operações co- nhecidas em i (este processo é optimizado para que não seja trocada informação relativa aos coobjectos estáveis, i.e., que não foram modificados recentemente). O protocolo continua por mais três passos, em que cada um dos parceiros responde aos pedidos recebidos e solicita o envio da informação necessária à sincronização das réplicas dos coobjectos. Protocolo de propagação epidémica unilateral No protocolo de propagação epidémica unilateral, detalhado no apêndice A.2.3, um servidor, i, envia para outro servidor, j, a informação que permite a j sincronizar o estado de j com o estado de i (i.e., o servidor j deve ficar a conhecer todas as operações conhecidas em i). Para tal, o servidor i envia para j todas as operações (e novos coobjectos) que, de acordo com o sumário das operações conhecidos nos outros servidores, não sabe serem conhecidas em j.

6.2. SERVIDORES 89<br />

6.2.2 Sincronização epidémica dos servidores<br />

Os servidores sincronizam as réplicas dos coobjectos <strong>de</strong> um volume durante sessões <strong>de</strong> sincronização<br />

epidémica [38] estabelecidas entre pares <strong>de</strong> servidores. Durante estas sessões, os servidores propagam<br />

entre si as operações <strong>de</strong> modificação que conhec<strong>em</strong> (in<strong>de</strong>pen<strong>de</strong>nt<strong>em</strong>ente do servidor no qual foram rece-<br />

bidas pela primeira vez). Desta forma, cada servidor recebe, para cada coobjecto, todas as modificações<br />

submetidas <strong>em</strong> todos os servidores, directa ou indirectamente. No sist<strong>em</strong>a DOORS, consi<strong>de</strong>ra-se que<br />

duas réplicas <strong>de</strong> um mesmo coobjecto estão sincronizadas quando conhec<strong>em</strong> o mesmo conjunto <strong>de</strong> ope-<br />

rações (e os sumários das operações conhecidas e executadas localmente e das operações conhecidas nos<br />

outros servidores são idênticos).<br />

No sist<strong>em</strong>a DOORS, <strong>de</strong>finiram-se dois protocolos <strong>de</strong> propagação epidémica. O primeiro protocolo<br />

é bilateral e durante a sua execução cada um dos servidores propaga as operações que conhece para o<br />

parceiro. O segundo protocolo é unilateral e apenas um dos servidores propaga as operações conhecidas<br />

para o parceiro.<br />

Protocolo <strong>de</strong> propagação epidémica bilateral O protocolo <strong>de</strong> propagação epidémica bilateral, <strong>de</strong>-<br />

talhado no apêndice A.2.2, consiste numa sequência <strong>de</strong> passos executados assincronamente — <strong>em</strong> cada<br />

um dos passos um servidor processa as mensagens recebidas e envia mensagens para o seu parceiro. Em<br />

cada um dos passos, e relativamente a cada um dos coobjectos a sincronizar, é possível: (1) solicitar o<br />

envio das operações não reflectidas num sumário; (2) enviar um conjunto <strong>de</strong> operações e solicitar o envio<br />

das operações não reflectidas num sumário; (3) solicitar o envio <strong>de</strong> uma cópia do coobjecto; (4) enviar<br />

uma cópia do coobjecto; (5) enviar a informação que o coobjecto foi eliminado.<br />

O protocolo <strong>de</strong> sincronização bilateral é iniciado com o servidor i a pedir que o parceiro lhe envie,<br />

para cada um dos coobjectos a sincronizar, as operações não reflectidas no sumário das operações co-<br />

nhecidas <strong>em</strong> i (este processo é optimizado para que não seja trocada informação relativa aos coobjectos<br />

estáveis, i.e., que não foram modificados recent<strong>em</strong>ente). O protocolo continua por mais três passos, <strong>em</strong><br />

que cada um dos parceiros respon<strong>de</strong> aos pedidos recebidos e solicita o envio da informação necessária à<br />

sincronização das réplicas dos coobjectos.<br />

Protocolo <strong>de</strong> propagação epidémica unilateral No protocolo <strong>de</strong> propagação epidémica unilateral,<br />

<strong>de</strong>talhado no apêndice A.2.3, um servidor, i, envia para outro servidor, j, a informação que permite a j<br />

sincronizar o estado <strong>de</strong> j com o estado <strong>de</strong> i (i.e., o servidor j <strong>de</strong>ve ficar a conhecer todas as operações<br />

conhecidas <strong>em</strong> i). Para tal, o servidor i envia para j todas as operações (e novos coobjectos) que, <strong>de</strong><br />

acordo com o sumário das operações conhecidos nos outros servidores, não sabe ser<strong>em</strong> conhecidas <strong>em</strong><br />

j.

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

Saved successfully!

Ooh no, something went wrong!