Istnieje wiele niejasności dotyczących zgonów przechowywanych w katalogu. W konsekwencji wiele osób opracowało niewłaściwe praktyki biznesowe dotyczące postępowania ze zgonami. W odróżnieniu od wielu innych systemów usług katalogowych oprogramowanie Novell® eDirectory™ zapewnia spójność odwołań między obiektami. Jeśli na przykład w grupie A znajduje się użytkownik B, który następnie zostaje usunięty, odwołanie do użytkownika B jest automatycznie usuwane z grupy A. Zgony są atrybutami operacyjnymi umieszczanymi w obiektach przez usługę eDirectory, stanowiącymi dodatkowy element gwarantowania spójności odwołań podczas usuwania, przenoszenia, zmiany nazwy, przywracania i innych operacji
Zgony dzielą się na trzy ogólne grupy: główne, wtórne i śledzenia. Do zgonów głównych zaliczają się zgony typu Dead (Martwy) (0001), Restored (Przywrócony) (0000), Moved (Przeniesiony) (0002), New RDN (Nowy obiekt RDN) (0005) i Tree New RDN (Drzewo Nowy obiekt RDN) (0008). Zgony wtórne są zwykle kojarzone ze zgonami głównymi i reprezentują agentów i partycje, które mają być powiadamiane o operacjach określonych w zgonach głównych. Do zgonów wtórnych zaliczają się zgony typu Back Link (Łącze wsteczne) (0006), Used By (Użyte przez) (000C) i Move Tree (Przenieś drzewo) (000a). Zgony śledzenia obejmują następujące typy: Inhibit Move (Zakaz przenoszenia) (0003), Old RDN (Stary obiekt RDN) (0004) i Tree Old RDN (Drzewo Stary obiekt RDN) (0007).
Zgony (z wyjątkiem typu Tracking (Śledzenie)) muszą przechodzić przez zestaw zsynchronizowanych stanów:
Stany są zapisywane w polu Flags (Flagi) w atrybucie zgonu. Zanim zgon będzie mógł przejść do kolejnego stanu, bieżący stan musi zostać zsynchronizowany na wszystkich replikach obiektu rzeczywistego. W celu stwierdzenia, czy wszystkie repliki w pierścieniu zapoznały się z danym stanem zgonu, następuje obliczenie wektora na podstawie wektora przechodniego. W usługach eDirectory w wersji 8.6 i nowszych wykorzystywany jest nieprzechowywany wektor zgonu. W starszych wersjach usług używany jest wektor likwidacji. Jeśli znacznik czasu modyfikacji (MTS) w zgonie jest starszy niż uszkodzony wektor, serwer odpowiadający za ten zgon może go przenieść do następnego stanu.
W przypadku zgonu wtórnego typu Back Link (Łącze wsteczne) za przenoszenie do kolejnych stanów odpowiada agent przechowujący główną replikę obiektu w zgonie. W przypadku zgonu wtórnego typu Used By (Użyte przez) agent, który utworzył replikę odpowiada za zmianę stanów zgonu tak długo, jak replika istnieje. Jeśli replika przestanie istnieć, zmianę stanów zgonu Used By (Użyte przez) przejmuje agent zawierający replikę główną partycji. W przypadku zgonu Move Tree (Przenieś drzewo) przenoszenia do kolejnych stanów dokonuje serwer zawierający partycję katalogu głównego.
Stan zgonów głównych można zmieniać dopiero wtedy, gdy przez wszystkie swoje stany przeszły wszystkie zgony wtórne. Gdy zgon główny osiągnie ostatni stan i stan ten zostanie zsynchronizowany na wszystkich serwerach w pierścieniu, pozostaje jedynie łupina obiektu, czyli obiekt pozbawiony atrybutów, który można usunąć z systemu przez likwidację. Zgony śledzenia są usuwane w momencie, gdy do usunięcia jest gotowy zgon główny lub — w przypadku typu Inhibit Move (Zakaz przenoszenia) — po przeniesieniu zgonu głównego do stanu OBF_NOTIFIED w replice głównej.
Replika odpowiedzialna za przetwarzanie zgonów używa w tym celu procesu przebiegającego w tle (procesu zgonu), który został zaplanowany dla każdej partycji po zakończeniu cyklu synchronizacji przychodzącej na danej partycji. Jeśli nie ma innych replik partycji, proces replikacji wychodzącej jest najpierw w dalszym ciągu planowany w interwałach sygnałów pulsowych. Następnie proces replikacji wychodzącej uruchamia proces zgonu. Procesu zgonu nie można planować ręcznie, ponieważ nie ma takiej potrzeby. W trakcie synchronizacji następuje aktualizacja wektorów przechodnich, a więc zmiana stanów wektorów likwidacji i zgonu. Wraz ze zmianą stanu tych wektorów następuje zezwolenie na zmianę stanów zgonu. Czynności te, w połączeniu z automatycznym planowaniem wykonywanym w trakcie synchronizacji przychodzącej, kończą cykl przetwarzania zgonu. Jak widać, głównym celem przetwarzania zgonów jest zapewnienie synchronizacji obiektów.
Gdy wszystkie zgony usuwanego obiektu, dla których typem zgonu głównego jest Dead (Martwy), zostaną przeniesione do ostatniego stanu (Purgeable — Możliwy do likwidacji) i stan ten zostanie zsynchronizowany na wszystkich replikach, za usunięcie pozostałej łupiny pozycji z bazy danych odpowiada nowy proces. Łupiny są usuwane automatycznie w wyniku procesu likwidacji. Proces likwidacji można planować ręcznie, zmieniając jego interwał harmonogramu automatycznego. Służy do tego strona
Konfiguracja agenta w programie iMonitor.Niniejsza sekcja zawiera następujące przykłady:
Jeśli zgon jest zgonem głównym, nie istnieją zgony wtórne i czas modyfikacji atrybutu (MST) w zgonie jest wcześniejszy niż wektor likwidacji, oznacza to, że informacje o zmianie dotarły do wszystkich serwerów. Zgon zostanie usunięty.
Jeśli zgon jest zgonem typu Back Link (Łącze wsteczne), a serwer jest serwerem głównym, za przetwarzanie zgonu odpowiada ten serwer.
Wykonaj operację niezbędną dla tego stanu, jeśli nie została ona jeszcze przeprowadzona. Najczęściej w tym celu następuje powiadomienie obiektu odwołania zewnętrznego.
Jeśli typem zgonu jest Used By (Użyte przez), a serwer jest serwerem, na którym nastąpiło usunięcie (replika do usunięcia jest ustalana przez porównanie numeru repliki w datowniku MTS zgonu z numerem repliki na danym serwerze), serwer ten jest odpowiedzialny za przetwarzanie zgonu.
Przenoszenie przebiega podobnie do procesu usuwania, z następującymi różnicami:
Obiekty zawierające zgony są brane pod uwagę przy każdej synchronizacji wychodzącej dokonywanej przez agenta oraz przez proces zgonu, którego wykonanie jest zaplanowane na zakończenie cyklu synchronizacji przychodzącej.
Regularnie wykonuj raport programu iMonitor dotyczący informacji o serwerze. Raport analizuje wszystkie elementy drzewa, komunikuje się ze wszystkimi znalezionymi serwerami NCP i informuje o wszelkich wykrytych błędach. Za pomocą tego raportu można identyfikować problemy związane z synchronizacją czasu i procesami limber oraz sprawdzać, czy bieżący serwer jest w stanie nawiązywać połączenia ze wszystkimi pozostałymi serwerami. Po zaznaczeniu odpowiedniej opcji na stronie konfiguracyjnej serwer może również generować informacje o stanie agenta usługi NDS dla każdego serwera w drzewie. Więcej informacji na temat wykonywania raportu informacji o serwerze można znaleźć w sekcji Konfiguracja raportu.
W przypadku korzystania z programu iMonitor w wersji 2.0 lub nowszej należy włączyć opcje raportu: Errors (Błędy) i Health (Stan). Weryfikacja będzie obejmowała elementy wymienione poniżej. Należy przejrzeć raport i sprawdzić, czy zgłoszono w nim błędy.
W przypadku korzystania z programu iMonitor w wersji 1.5, należy zaznaczyć opcję Errors (Błędy). Weryfikacja będzie obejmowała elementy wymienione poniżej. Należy przejrzeć raport i sprawdzić, czy nie wystąpiły żadne błędy.
Za pomocą raportów programu iMonitor dotyczących listy i statystyki zgonów można odszukać wszystkie zgony istniejące w systemie. W przypadku znalezienia zgonów, wobec których istnieje podejrzenie, że nie są przetwarzanie, zobacz Wskazówki dotyczące rozwiązywania problemów.
Istnieją dwie główne przyczyny nieprzetwarzania zgonów: zgon został osierocony (tzn. istnieje tylko na niektórych serwerach) lub zablokowany (tzn. istnieje na wszystkich serwerach, ale z pewnych względów jego stan nie ulega zmianie).
Oto najważniejsze wskazówki dotyczące rozwiązywania problemów z osieroconymi lub zablokowanymi zgonami:
Problemy z komunikacją — błędy 625, 622, 634, i 635. Więcej informacji na ten temat można znaleźć w sekcji Raport informacji o serwerze.
Błędy 601 i 603, wskazujące, że serwer został nieprawidłowo usunięty lub że klasą bazową obiektu serwera może być Nieznany.
Użyj odpowiedniego rozwiązana opisanego w sekcji Wskazówki dotyczące rozwiązywania problemów.
Przed zastosowaniem wymienionych rozwiązań upewnij się, że dane są bezpieczne. Konieczne może być wykonanie kopii zapasowych plików bazy danych, konfiguracji serwera i dysponentów katalogu. Aby zwiększyć prawdopodobieństwo powodzenia i ograniczyć ryzyko wystąpienia błędów w przyszłości, zainstaluj najnowsze pakiety serwisowe dla usługi eDirectory.
Postępowanie z osieroconymi zgonami
- Metoda preferowana: Jeśli na dowolnym serwerze w pierścieniu replik została zainstalowana wersja 8.6 lub nowsza usługi eDirectory, przejdź do obiektu w programie iMonitor i kliknij przycisk Send Single Entry (Wyślij jedną pozycję). Spowoduje to wykonanie operacji wysłania niewiarygodnego do wszystkich pozostałych replik.
- Metoda mniej pożądana: W programie iMonitor włącz tryb zaawansowany, odszukaj obiekt, a następnie wybierz kolejno polecenia Advanced Options (Opcje zaawansowane) i Timestamp Entry (Oznacz pozycję znacznikiem czasu). Dzięki temu obiekt istniejący na serwerze stanie się kopią wiarygodną. Firma Novell nie zaleca nadawania obiektom wiarygodności poza sytuacjami wyjątkowymi.
- Metoda najmniej pożądana: Jeśli wszystkie serwery w pierścieniu replik zawierające kopię osieroconego zgonu zostały wyposażone w wersje usługi eDirectory starsze niż 8.6, załaduj moduł DSBrowse z opcją –a, przejdź do obiektu, a następnie wybierz polecenie Resend Selected Object (Wyślij zaznaczony obiekt ponownie), aby oznaczyć pozycję znacznikiem czasu. Dzięki temu obiekt istniejący na serwerze stanie się kopią wiarygodną. Firma Novell nie zaleca nadawania obiektom wiarygodności poza sytuacjami wyjątkowymi.
Postępowanie z osieroconymi zgonami odwołań zewnętrznych
- Metoda preferowana: Uruchom najnowszą wersję narzędzia DSRepair z zaznaczoną opcją –XK3. Najpierw jednak sprawdź, czy wszystkie operacje wykonywane przez opcję –XK3 są dopuszczalne.
- Metoda mniej pożądana: Przenieś replikę rzeczywistą na serwer, poczekaj, aż serwer zostanie włączony, a następnie poczekaj na przetworzenie zgonu. Jeśli zgon nie zostanie przetworzony, rozwiąż problem korzystając z informacji dostępnych w sekcji Wskazówki dotyczące rozwiązywania problemów (obiekt znajduje się teraz na replice rzeczywistej). Po przetworzeniu zgonu w razie potrzeby replikę można usunąć.
Postępowanie ze zgonami typu OBT_INHIBIT_MOVE
- Metoda preferowana: Jeśli obiekt docelowy jest kompletny, sprawdź, czy w dalszym ciągu istnieje obiekt źródłowy. Jeśli istnieje i wciąż zawiera atrybut OBT_MOVED, przystąp do rozwiązania problemów uniemożliwiających przetworzenie zgonu OBT_MOVED. Jeśli obiekt źródłowy nie istnieje, użyj opcji trybu zaawansowanego w programie iMonitor i zwolnij zgon OBT_MOVE_INHIBIT, znajdujący się w replice głównej obiektu docelowego. Jeśli obiekt docelowy jest niekompletny, usuń zgon OBT_MOVE_INHIBIT z pamięci, a następnie usuń obiekt docelowy.
W przeszłości do usuwania zablokowanych zgonów stosowano różne strategie. Niektóre z nich obejmują drogie operacje dzielenia na partycje lub stosowanie nieudokumentowanych mechanizmów, które mogą powodować problemy w przyszłości. Wiele metod wymienionych poniżej nie powinno być używanych.
Pierwszy sposób to zmiana repliki zawierającej serwer główny. Działa to w niektórych przypadkach, ponieważ serwer główny jest agentem odpowiedzialnym za przenoszenie zgonów typu Łącze wsteczne przez poszczególne stany. W przypadkach, gdy replika była niespójna, a serwer główny nie zawierał usuniętego obiektu, zmiana serwera głównego na agenta zawierającego usuniętą pozycję wraz z jej zgonami pozwalała nowemu agentowi na wymuszanie przechodzenia zgonów przez ich stany, a w konsekwencji ich usunięcie. Znacznie prostszym i bezpieczniejszym sposobem postępowania ze zgonami, które zostały zablokowane z powodu niespójności repliki, jest jednak użycie opcji Wyślij jedną pozycję.
Druga strategia polega na użyciu modułu DSRepair z określonymi przełącznikami, które powodują usunięcie wszystkich zgonów (jedna z innych firm oferuje aplikację, która usuwa zablokowane zgony za pośrednictwem narzędzia DSRepair). Zespół programistów produktu eDirectory nie zaleca stosowania tej strategii. Użycie tych przełączników spowoduje usunięcie wszystkich zgonów przechowywanych na danym agencie, co oznacza możliwość usunięcia również zgonów, które nie są zablokowane. Zwiększa to stopień niespójności replik i przyczynia się do powstania kolejnych zablokowanych zgonów. Ponieważ nie jest to operacja wykonywana w środowisku rozproszonym, moduł DSRepair należy uruchomić na każdym serwerze zawierającym zablokowane zgony. W efekcie rośnie ryzyko przedwczesnego usunięcia zgonów znajdujących się na jednym serwerze, które są wymagane dla innej partycji. Przedwczesne usunięcie zgonów może przyczynić się do powstania dodatkowych zgonów osieroconych, a to z kolei może wywoływać problemy, które ujawnią się kilka lat później podczas zmiany typów replik, dodawania nowych replik czy wykonywania innych operacji na partycjach.
Trzecia strategia polega na nadaniu wiarygodności obiektom. Można to zrobić za pomocą narzędzia DSBrowse w połączeniu z operacjami trybu zaawansowanego i oznaczaniem znacznikami czasu lub przy użyciu modułu DSRepair z przełącznikiem –0T. Powoduje to nadanie pozycji statusu wiarygodności i synchronizację tej pozycji z pozostałymi replikami. Opatrywanie znacznikiem czasu i nadawanie wiarygodności należy stosować z rozwagą, aby nie utracić danych zmienionych na innych serwerach. Zespół programistów eDirectory zaleca, aby ta metoda usuwania zgonów była stosowana tylko w niezbędnych przypadkach.
Symbol znaku towarowego (®, TM itd.) oznacza znak towarowy firmy Novell. Gwiazdka (*) oznacza znak towarowy innej firmy. Informacje na temat znaków towarowych można znaleźć w sekcji Informacje prawne.