Tem havido muita confusão envolvendo os obituários armazenados no diretório e, como resultado, algumas pessoas desenvolveram práticas de negócios inadequadas para tratar esse assunto. Ao contrário de alguns produtos de diretório, o eDirectory garante a integridade referencial entre os objetos. Por exemplo, se o Grupo A tiver um membro, o Usuário B, e esse usuário for apagado posteriormente, o diretório removerá automaticamente do Grupo A a referência ao Usuário B. Os obituários existem como atributos operacionais colocados nos objetos pelo eDirectory como uma outra maneira de garantir a integridade referencial durante operações de exclusão, movimentação, renomeação e restauração, entre outras.
Há três classificações gerais para obituários: primário, secundário e monitoramento. Os obituários Primários incluem obituários do tipo Inativo (0001), Restaurado (0000), Movido (0002), RDN novo (0005) e Novo RDN da árvore (0008). Os obituários Secundários estão geralmente associados a um obituário Primário e representam os agentes e as partições que precisam receber notificações sobre a operação especificada no obituário Primário. Os obituários Secundários incluem os tipos Back link (0006), Usado por (000C) e Mover árvore (000a). Os obituários de Acompanhamento incluem Inibir movimentação (0003), RDN antigo (0004) e RDN antigo da árvore (0007).
Os obituários, com exceção dos de Acompanhamento, devem se mover ao longo de um conjunto de estados de sincronização:
Os estados são registrados no campo Flags do atributo do obituário. Para que um obituário possa se mover para o estado seguinte, o estado atual deve ter sido sincronizado com todas as réplicas do objeto real. Para determinar se todas as réplicas do anel detectaram um determinado estado do obituário, um vetor é calculado a partir do Vetor transitivo. No eDirectory 8.6 e posterior, um Vetor de obituário não armazenado é utilizado. Em versões anteriores do eDirectory, o Vetor de purgação é utilizado. Se a MTS (Modificação da marcação do horário) no obituário for mais antiga que o vetor corrompido, o servidor responsável por esse obituário poderá movê-lo para o estado seguinte.
Para um obituário Secundário do tipo Back link, o agente que mantém a réplica master do objeto com o obituário é responsável pelo avanço dos estados. Para um obituário Secundário do tipo Usado por, o agente da réplica que o criou é responsável pelo avanço dos estados do obituário, desde que essa réplica ainda exista. Se ela não existir, o agente que mantém o master dessa partição assumirá a responsabilidade de avançar os estados para o obituário Usado por. Para um obituário Mover árvore, o master da partição raiz é responsável pelo avanço dos estados.
Os obituários Primários apenas poderão ser avançados em seus estados depois que todos os obituários Secundários tiverem avançado em todos os seus respectivos estados. Depois que o obituário Primário atingir seu último estado, e esse estado for sincronizado com todos os servidores no anel, tudo o que permanecerá será o objeto vazio, ou seja, um objeto sem atributos e que pode ser subsequentemente purgado do sistema pelo Processo de purgação. Os obituários de Acompanhamento serão removidos depois que obituário Primário estiver pronto para ser removido. Ou, no caso de Inhibit_move, o obituário de Acompanhamento será removido depois que o obituário Primário tiver movido para o estado OBF_NOTIFIED na réplica master.
A réplica responsável pelo processamento de obituários realiza essa tarefa em um processo em segundo plano (o Processo de obituário), que é programado para cada partição depois que uma partição específica termina um ciclo de sincronização de entrada. Se não houver outras réplicas da partição, o Processo de replicação de saída ainda permanecerá programado no intervalo de heartbeat. Em seguida, o Processo de replicação de saída inicia o Processo de obituário. O Processo de obituário não pode e não precisa ser manualmente programado. Enquanto a sincronização ocorre, os Vetores transitivos são atualizados, avançando consequentemente o Vetor de purgação e o Vetor de inatividade. Conforme esses vetores avançam, os estados do obituário também têm permissão para avançar. Isso, juntamente com a programação automática realizada após a sincronização de entrada, conclui o ciclo de processamento de obituários. Portanto, a essência do processamento de obituários é a sincronização de objetos.
Para um objeto que está sendo removido, quando todos os obituários, cujo obituário Primário associado for do tipo DEAD (Inativo), tiverem avançado para o último estado (Purgável) e depois que esse estado tiver sido sincronizado com todas as réplicas, um novo processo será responsável pela remoção do objeto vazio de entrada restante do banco de dados. O Processo de purgação é executado automaticamente para remover esses objetos vazios. É possível programar manualmente o Processo de purgação e modificar seu intervalo de programação automática utilizando
a página Configuração do agente no iMonitor.Esta seção contém os seguintes exemplos:
Se o obituário for Primário e não houver obituários Secundários, e se o horário de modificação do atributo (MTS) no obituário for mais antigo que o do Vetor de purgação, significa que todos os servidores viram a modificação e o obituário será removido.
Se o obituário for do tipo Back link e o servidor for o master, este último será responsável pelo processamento desse obituário.
Execute a operação necessária para esse estado se ela não tiver sido feita. Na maioria das vezes, isso é feito por meio do envio de uma notificação para uma referência externa.
Se o obituário for do tipo Usado por e a exclusão (determinada pela comparação do número de réplica no MTS do obituário com o nosso número de réplica) tiver ocorrido neste servidor, este último será responsável pelo processamento desse obituário.
A operação Mover é muito semelhante à operação Apagar, com exceção das seguintes variações:
Os objetos com obituários são levados em consideração sempre que uma saída de agente é sincronizada e também pelo processo de obituário, que está programado para execução no final de um ciclo de sincronização de entrada.
Execute regularmente o relatório Informações sobre o servidor iMonitor. Esse relatório percorre toda a árvore, comunica-se com cada servidor NCP que encontrar e informa todos os erros que detectar. Você pode utilizá-lo para diagnosticar problemas de limber e de sincronização de horários ou para descobrir se o servidor atual é capaz de se comunicar com todos os outros servidores a partir da perspectiva desse servidor. Se estiver selecionado na página de configuração, esse servidor também poderá gerar informações sobre a Saúde do agente do NDS para cada servidor na árvore. Consulte Configuração de relatório para obter mais informações sobre como executar o relatório Informações sobre o servidor.
Se estiver utilizando o iMonitor 2.0 ou posterior, verifique se as seguintes opções de relatório estão habilitadas: Sub-relatório de erros e da saúde. Os itens a seguir serão verificados. É necessário pesquisar o relatório e verificar se não existem erros.
Se estiver utilizando o iMonitor 1.5, selecione a opção Relatório de erros. Os itens a seguir serão verificados. É necessário pesquisar o relatório e verificar se não existem erros.
Utilizando o relatório Lista de obituários do iMonitor ou o relatório Estatísticas do objeto do iMonitor, é possível localizar todos os obituários no sistema. Se forem localizados obituários e você achar que eles não estão sendo processados, consulte Dicas de solução de problemas.
As duas razões gerais pelas quais os obituários não são processados são: o óbito tornou-se órfão (isto é, o obituário existe em alguns servidores, mas não em todos) ou o obituário está parado (isto é, ele existe em todos os servidores, mas seus estados não avançam, por algum motivo).
Utilize os itens a seguir para solucionar problemas com obituários órfãos ou travados:
problemas de comunicação -625, -622, -634 e -635. Consulte o Relatório de informações sobre o servidor para obter mais detalhes.
-601 e -603, especificando os servidores que foram incorretamente removidos ou indicando que o objeto Servidor pode ter uma classe de base do tipo Desconhecida.
Utilize a solução apropriada indicada em Dicas para solução de problemas.
Antes de utilizar qualquer uma dessas soluções, verifique se os seus dados estão seguros. Talvez seja necessário fazer o backup dos arquivos de banco de dados do diretório, da configuração dos servidores e dos trustees. Para aumentar a probabilidade de êxito e minimizar problemas futuros, faça um upgrade para os support packs mais recentes do eDirectory.
- Método preferencial: Se o eDirectory 8.6 ou posterior estiver em um dos servidores no anel de réplicas, vá até o objeto no iMonitor e selecione Enviar entrada única. Esse procedimento executará um envio não autorizado a todas as outras réplicas.
- Método menos indicado: Habilite o Modo avançado no iMonitor, procure até localizar o objeto e selecione Opções avançadas. Em seguida, escolha Entrada de marcação de horário. Isso fará com que o objeto existente nesse servidor transforme-se na cópia autorizada. Por uma questão de prática, a Novell não recomenda a transformação de objetos em objetos autorizados.
- Método ainda menos indicado: Se todos os servidores no anel de réplicas que possuem uma cópia do obituário órfão forem anteriores ao eDirectory 8.6, carregue DSBrowse com a opção –a, procure até localizar o objeto e, em seguida, selecione Reenviar o objeto selecionado de forma a criar uma marcação de horário para a entrada. Isso fará com que o objeto existente nesse servidor transforme-se na cópia autorizada. Por uma questão de prática, a Novell não recomenda a transformação de objetos em objetos autorizados.
Resolvendo obituários órfãos nas Extrefs
- Método preferencial: Execute a versão mais atual de DSRepair com a opção -XK3 selecionada. Entretanto, verifique primeiramente se todas as operações executadas por -XK3 são aceitáveis.
- Método menos indicado: Mova uma réplica real para o servidor, aguarde sua ativação e, em seguida, aguarde o processamento do obituário. Se o obituário não for processado, utilize as informações em Dicas para solução de problemas para solucionar o problema, agora que o objeto está em uma réplica real. Após o processamento do obituário, a réplica poderá ser removida se você desejar.
Resolvendo obituários OBT_INHIBIT_MOVE
- Método preferencial: Se o objeto de destino estiver completo, verifique se a origem ainda existe. Se o objeto de origem existir e ainda tiver o atributo OBT_MOVED, solucione o problema que impediu a conclusão de OBT_MOVED. Se não houver um objeto de origem, utilize as opções do Modo avançado do iMonitor para liberar OBT_MOVE_INHIBIT na réplica master do objeto de destino. Se o objeto de destino estiver incompleto, libere OBT_MOVE_INHIBIT e remova esse objeto de destino.
No passado, várias estratégias diferentes foram empregadas para fazer a limpeza de obituários travados. Algumas dessas estratégias envolvem operações caras de particionamento ou o uso de recursos não documentados que poderiam causar problemas no futuro. Muitas das estratégias relacionadas a seguir não devem ser utilizadas.
A primeira estratégia era alterar a réplica que mantinha o master. Isso poderia funcionar em alguns casos, pois o master corresponde ao agente responsável pela movimentação dos obituários Back link ao longo de seus diversos estados. No caso em que a réplica era inconsistente e o master não continha o objeto apagado, a troca dos masters para um agente que continha a entrada apagada com seus obituários daria ao novo agente a licença para passar os obituários pelos seus estados, com uma eventual purgação. A opção Enviar entrada única é uma maneira muito mais organizada e menos perigosa de resolver os obituários que estão travados devido à inconsistência na réplica.
A segunda estratégia utilizada é executar DSRepair com determinadas comutações para apagar todos os obituários. (Existe um aplicativo de terceiros que faz a limpeza de obituários travados iniciando DSRepair.) A equipe de desenvolvimento do eDirectory não recomenda essa estratégia. O uso dessas comutações apagará todos os obituários nesse agente, ou seja, os obituários que não estão travados também podem ser removidos, criando maiores inconsistências de réplicas e mais obituários travados. Como não se trata de uma operação distribuída, você deve executar DSRepair em todos os servidores com obituários travados, aumentando as chances de que um desses servidores possua obituários para outra partição que serão antecipadamente apagados. A exclusão antecipada de obituários pode gerar obituários órfãos adicionais e, por sua vez, causar problemas que poderão ser descobertos após alguns anos, quando você mudar os tipos de réplicas, adicionar novas réplicas ou executar outras operações de particionamento.
A terceira estratégia utilizada é tornar os objetos autorizados, utilizando DSBrowse com a operação no modo avançado e marcando o horário na entrada ou executando DSRepair com o switch –0T. Isso impõe que a entrada se torne autorizada e seja sincronizada com todas as outras réplicas. A criação de uma marcação de horário e a transformação em um objeto autorizado devem ser feitas com cautela, pois você pode perder os dados mudados em outros servidores. A equipe de desenvolvimento do eDirectory recomenda que esse método seja raramente empregado para a limpeza de obituários.
Para obter informações sobre as marcas comerciais da NetIQ, consulte http://www.netiq.com/company/legal/.