Impacto em aplicativos habilitados para diretório

Versão Skew

A distorção de versão ocorre quando os aplicativos leem os mesmos objetos de réplicas diferentes antes que uma alteração seja replicada. Os aplicativos que leem a réplica remota reconhecem o objeto inalterado. A distorção de versão é um problema quando um determinado aplicativo ou conjunto de aplicativos usa os dados no diretório para interoperar.

Por exemplo, um Serviço RPC pode publicar seus pontos de extremidade no diretório usando APIs RPC padrão (como RpcNsBindingExport). Os clientes se conectam ao serviço pesquisando o ponto de extremidade desejado no diretório ( RpcNsBindingLookupBegin, RpcNsBindingLookupNext e assim por diante) e vinculando-se a ele.

Suponha que um RPC Service S₁ publique o ponto de extremidade Es₁ e, posteriormente, mova para um computador diferente. O ponto de extremidade original Es₁ é alterado para E_s2, refletindo o endereço do novo computador. Os clientes que leem réplicas remotas do serviço de diretório não conseguem se conectar ao serviço até que o ponto de extremidade atualizado seja replicado. No entanto, mover um serviço de um computador para outro é uma ocorrência rara; Portanto, essa interrupção/atraso raramente deve ser encontrada, especialmente se a movimentação do serviço for bem planejada.

Atualizações parciais

Em geral, a atualização parcial ocorre quando um aplicativo está lendo um conjunto de dados enquanto outro aplicativo está gravando nesse mesmo conjunto de dados. Esta é uma situação que pode ocorrer com qualquer aplicativo em um sistema multi-mastered. Há muitas maneiras de isso ocorrer. Você pode ter mais de um aplicativo gravando no mesmo conjunto de dados ao mesmo tempo. Se você olhar dessa maneira, o serviço de replicação de diretório é apenas outro aplicativo que pode estar gravando no mesmo conjunto de dados que outro aplicativo pode estar lendo. Isso pode ser um problema potencial para um aplicativo. No entanto, a janela de tempo em que uma atualização parcial pode afetar seu aplicativo é relativamente pequena. Isso raramente ou nunca deve ser um problema para aplicativos que não dependem da sincronização de vários objetos. Se o aplicativo for altamente dependente da sincronização de um conjunto relacionado de objetos, você deverá considerar os efeitos de uma atualização parcial no design do aplicativo.

Em termos de replicação de diretório, a atualização parcial ocorre quando os aplicativos leem o mesmo conjunto de objetos de réplicas diferentes enquanto a replicação está em andamento. Os aplicativos na réplica remota veem algumas, mas não todas, as alterações.

Observação

A janela na qual a atualização parcial pode afetar um aplicativo é pequena: o aplicativo deve começar a ler objetos enquanto a replicação de entrada está em andamento, depois que um ou mais dos objetos alterados relacionados tiverem sido recebidos, mas antes que todos tenham sido recebidos. O tempo entre as atualizações na réplica de origem afeta diretamente o tamanho dessa janela — as atualizações que ocorrem juntas no tempo são replicadas juntas no tempo. A atualização parcial pode ser um problema quando um aplicativo usa um conjunto relacionado de objetos.

 

Por exemplo, um serviço de acesso remoto pode usar o diretório para armazenar dados de política e perfil. Os dados da política são armazenados em um conjunto de objetos e o perfil em outro conjunto. Quando um usuário se conecta ao serviço de acesso remoto, o serviço de acesso remoto lê a diretiva para determinar se o usuário tem permissão para se conectar e, em caso afirmativo, qual perfil aplicar à sessão do usuário. A atualização parcial pode afetar o serviço de acesso remoto de várias maneiras:

• Se a diretiva for complexa e consistir em vários objetos, o serviço de acesso remoto poderá ler uma diretiva parcialmente atualizada, resultando em negação incorreta ou concessão de serviço ao usuário, incapacidade de processar a diretiva devido à inconsistência interna e assim por diante.
• Se a política e os perfis tiverem sido atualizados, o serviço poderá processar corretamente a política, mas aplicar um perfil obsoleto, porque os objetos de política foram replicados, mas os objetos de perfil não.
• Se o perfil for complexo e consistir em vários objetos, o serviço poderá processar corretamente a política, mas aplicar um perfil parcialmente atualizado porque os objetos de política foram replicados, mas apenas alguns dos objetos de perfil o fizeram.

Colisões

As colisões ocorrem quando os mesmos atributos de duas ou mais réplicas de um determinado objeto são alterados durante o mesmo intervalo de replicação. O processo de replicação reconcilia a colisão; Devido à reconciliação, um usuário ou aplicativo pode "ver" um valor diferente daquele que ele escreveu.

Um exemplo simples são as informações de endereço do usuário: um usuário altera um endereço de correspondência na réplica R1 e um administrador altera o mesmo endereço de correspondência na réplica R2. Um valor escrito se propaga até que outro valor seja selecionado sobre esse valor pelo mecanismo de reconciliação de colisão. Enquanto um valor continuar a "ganhar" contra outros valores no processo de resolução de colisão, o valor continuará a se propagar. Em última análise, esse valor "vencedor" será propagado para R1,R2 e todas as outras réplicas se nenhuma outra alteração for feita.

A resolução de colisão é um problema para aplicativos que fazem suposições sobre a consistência interna de objetos ou conjuntos de objetos. Por exemplo, um serviço de gerenciamento de alocação de largura de banda de rede armazena dados de largura de banda de rede para um determinado segmento de rede no diretório em um objeto O1. O objeto contém a largura de banda disponível em bits por segundo e a largura de banda máxima que qualquer usuário pode reservar. O serviço espera que a largura de banda reservável pelo usuário seja sempre menor ou igual à largura de banda disponível.

Considere a seguinte sequência de eventos:

• O objeto no estado inicial totalmente replicado fornece a largura de banda disponível como 56 kilobits por segundo e a largura de banda reservável pelo usuário como 9.600 bits por segundo.
• Um administrador na réplica R₁ altera os valores para 64k e 19.200, respectivamente.
• Um administrador na réplica R₂ altera os valores para 10 milhões e 1 milhão, respectivamente, antes da atualização de R₁ chegar.

Supondo que os atributos em questão tenham números de versão iguais quando as atualizações ocorrem, há uma pequena, mas real, possibilidade de que o objeto acabe com uma largura de banda máxima de 64k e um máximo de reserva de usuário de 1 milhão — se o aplicativo executar as atualizações como operações de gravação separadas. O aplicativo deve sempre atualizar ambas as propriedades em uma única operação.