Vem ocorrendo uma grande confusão em torno dos obituários armazenados no diretório, fazendo com que algumas pessoas desenvolvam práticas de negócios deficientes para lidar com eles. Ao contrário de alguns produtos de diretório, o Novell® eDirectory™ garante a integridade referencial entre os objetos. Por exemplo, se o Grupo A tiver um membro, o Usuário B, e este for apagado, o diretório removerá automaticamente do Grupo A a referência ao Usuário B. Os obituários são atributos operacionais colocados em objetos pelo eDirectory como outra forma de garantir a integridade referencial durante operações como apagar, mover, renomear, restaurar e outras.
Existem três classificações gerais dos obituários: Primário, Secundário e de Monitoramento. Os obituários primários incluem os do tipo Inativo (0001), Restaurado (0000), Movido (0002), RDN novo (0005) e Novo RDN da árvore (0008). Os obituários secundários geralmente são associados a um obituário Primário e representam os agentes e as partições que precisam ser notificados 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 Monitoramento incluem Inibir mover (0003), RDN antigo (0004) e RDN antigo da árvore (0007).
Com exceção dos obituários de Monitoramento, os obituários devem mover-se por um conjunto de estados de sincronização:
Os estados são registrados no campo Flags do atributo do obituário. Para que o obituário possa passar para o próximo estado, o estado atual deve ter sido sincronizado para todas as réplicas do objeto real. Para determinar se todas as réplicas do anel passaram por um determinado estado de obituário, é computado um vetor a partir do Vetor transitivo. No eDirectory 8.6 e posterior, é utilizado um Vetor de obituário não armazenado. Nas versões anteriores do eDirectory, é utilizado o Vetor de purgação. Se a Modificação da marca do horário (MTS) no obituário for mais antiga do que o vetor danificado, o servidor responsável por esse obituário poderá avançá-lo para o próximo estado.
No caso de um obituário Secundário do tipo Back Link, o agente que contém a réplica master do objeto com o obituário é responsável por avançar os estados. Se o obituário Secundário for do tipo Usado por, o agente de réplica que o criou será responsável por avançar os estados de obituário, desde que a réplica ainda exista. Se ela não existir mais, o agente que contém a réplica master dessa partição assume a responsabilidade de avançar os estados do obituário Usado por. No obituário Mover árvore, a réplica master da partição raiz é responsável por avançar os estados.
Os obituários Primários podem ser avançados em seus estados somente depois que todos os obituários Secundários tiverem sido avançados por todos os seus estados. Quando o obituário Primário atingir seu último estado e esse estado for sincronizado com todos os servidores do anel, restará apenas o exterior do objeto, que é um objeto sem atributos, que posteriormente poderá ser purgado do sistema, pelo processo de purgação. Os obituários de Monitoramento são removidos quando o obituário Primário está pronto para ser removido, ou no caso de Inhibit_move, o obituário de Monitoramento é removido após o obituário Primário ter sido movido para o estado OBF_NOTIFIED na réplica master.
A réplica responsável por processar obituários o faz em um processo em segundo plano (o Processo de obituário), programado por partição depois que uma determinada partição 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 estará programado no intervalo de heartbeat. Em seguida, o Processo de replicação de saída inicia o Processo do obituário. O Processo do obituário não pode ser programado manualmente e nem precisa ser. Conforme a sincronização ocorre, os Vetores transitivos são atualizados, avançando o Vetor de purgação e o Vetor de obituário. Conforme esses vetores avançam, os estados do obituário podem avançar. Esse processo, juntamente com a programação automática efetuada na sincronização de entrada, conclui o ciclo de processamento do obituário. Assim, o núcleo do processamento do obituário é a sincronização do objeto.
No caso de um objeto que está sendo removido, quando todos os obituários cujo obituário Primário associado é do tipo INATIVO tiverem sido avançados para o último estado (Purgável) e esse estado tiver sido sincronizado para todas as réplicas, um novo processo será responsável por remover do banco de dados o exterior da entrada restante. O Processo de purgação é executado automaticamente para remover esses exteriores. É 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 Back Link e o servidor for o master, o servidor será responsável por processar o obituário.
Execute a operação necessária para este estado, se ainda não tiver feito isso. Geralmente, isso é feito por meio da notificação de uma referência externa.
Se o obituário for um Usado por e o servidor for aquele no qual ocorreu a exclusão (determinada pela comparação do número da réplica no MTS do obituário com o número da sua réplica), o servidor será responsável por processar o obituário.
Movimentar é muito parecido com Apagar, com as seguintes modificações:
Os objetos com obituários são considerados sempre que um agente de saída é sincronizado e pelo processo de obituário, que é programado para execução no fim de um ciclo de sincronização de entrada.
Execute regularmente o relatório de informações sobre o servidor iMonitor. Esse relatório percorre a árvore inteira, comunica-se com cada servidor NCP que encontrar e relata todos os erros encontrados. Ele pode ser utilizado para diagnosticar problemas de sincronização de horário e de limber ou para descobrir se o servidor atual pode se comunicar com todos os outros servidores a partir da perspectiva deste servidor. Se for selecionado na página de configuração, este servidor também pode gerar informações sobre a Saúde do agente do NDS para cada servidor da árvore. Consulte Config de relatório para obter mais informações sobre como executar o relatório de 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 ativadas: Sub-relatório de erros e saúde. Os itens a seguir serão verificados. Percorra o relatório e verifique se não há erros.
Se você estiver utilizando o iMonitor 1.5, selecione a opção de relatório de Erros. Os itens a seguir serão verificados. Percorra o relatório e verifique se não há erros.
Utilizando o relatório de Listagem de obituários ou o relatório de Estatísticas do objeto do iMonitor, é possível localizar 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.
Existem dois motivos gerais para os obituários não serem processados: 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 seguintes itens para solucionar problemas em obituários órfãos ou parados:
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, indicando servidores que foram removidos inadequadamente ou cujo objeto Servidor pode ter a classe de base Desconhecido.
Utilize a solução adequada indicada nas Dicas de solução de problemas.
Antes de utilizar essas soluções, verifique se os seus dados estão seguros. Pode ser necessário fazer backup dos arquivos de banco de dados do diretório, da configuração do servidor e dos trustees. Para aumentar a probabilidade de êxito e minimizar problemas futuros, faça upgrade para os Support Packs mais recentes do eDirectory.
- Método preferido: Se o eDirectory 8.6 ou posterior estiver em um dos servidores no anel da réplicas, vá até o objeto no iMonitor e selecione Enviar entrada única. Essa ação efetuará um envio não autorizado para todas as outras réplicas.
- Método menos desejável: Se todos os servidores no anel da réplicas que possuem uma cópia do obituário órfão forem mais antigos que o eDirectory 8.6, carregue o DSBrowse com a opção -a, vá até o objeto e selecione <visit> para colocar a marca de horário na entrada. Isso transformará o objeto existente no servidor na cópia autorizada. A Novell não recomenda a transformação de objetos em cópias autorizadas, por uma questão prática.
Resolvendo óbitos órfãos nas refext
- Método menos desejável: Execute a versão <visit> do DSRepair, com a opção <visit> selecionada.
- Método menos desejável: Mova uma réplica real para o servidor, aguarde a sua ativação e aguarde o processamento do obituário. Se o obituário não for processado, utilize as informações das Dicas de solução de problemas para resolver o problema agora que o objeto está em uma réplica real. Quando o obituário tiver sido processado, a réplica poderá ser removida, se isso for desejado.
Anteriormente, diversas estratégias diferentes foram empregadas para limpar obituários parados. Algumas dessas estratégias envolvem operações de particionamento caras ou a utilização de recursos não documentados que podem trazer problemas no futuro. Muitas das estratégias relacionadas a seguir não devem ser utilizadas.
A primeira estratégia era trocar a réplica que continha o master. Isso funcionava em alguns casos, pois o master é o agente responsável por mover os obituários Back Link pelos 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 dava ao novo agente a licença para passar os obituários pelos seus estados, com uma eventual purgação. Enviar entrada única é uma forma muito mais limpa e menos perigosa de resolver os obituários parados devido à inconsistência da réplica.
A segunda estratégia utilizada é executar o DSRepair com determinados switches para apagar todos os obituários (existe um aplicativo de terceiros que limpa os obituários parados, iniciando o DSRepair). A equipe de desenvolvimento do eDirectory não recomenda essa estratégia. A utilização desses switches apagará todos os obituários nesse agente, o que significa que os obituários que não estiverem parados também poderão ser removidos, criando mais inconsistências na réplica e mais obituários parados. Como esta não é uma operação distribuída, é necessário executar o DSRepair em todos os servidores que tiverem obituários parados, o que aumenta a probabilidade de um desses servidores ter obituários de outra partição que serão apagados prematuramente. A exclusão prematura de obituários pode resultar em mais obituários órfãos e, por sua vez, provocar problemas que poderão ser encontrados anos depois, quando você mudar os tipos de réplica, 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 força a entrada a se tornar autorizada e ser sincronizada com todas as outras réplicas. A marcação de horário e a transformação do objeto em autorizado devem ser feitas com cuidado, pois pode ocorrer perda dos dados mudados em outros servidores. A equipe de desenvolvimento do eDirectory recomenda que o emprego deste método de limpeza do obituário seja raro.
Um símbolo de marca registrada (®, TM, etc.) indica uma marca registrada da Novell. Um asterisco (*) indica uma marca registrada de terceiros. Para obter mais informações sobre marcas registradas, consulte Informações legais.