|
|
Poznańskie
Centrum Superkomputerowo - Sieciowe |
|
PROJEKT LDAP |
|
|
Replikacja Single-Master w serwerach katalogowych Sun
ONE Directory Server Jerzy Chochulski |
|
|
Poznań 2003 |
|
Spis treści
2 Replikacja typu Single-Master w SunONE
Directory Server
2.1 Konfiguracja serwera 'Konsumenta'
2.1.1 Utworzenie
katalogowej bazy danych
2.1.2 Obiekt
użytkownika dla repliki read-only
2.1.3 Konfiguracja
katalogowej bazy danych jako repliki read-only
2.2 Konfiguracja serwera 'Dostawcy'
2.2.2 Ustawienia
repliki read-write. Definicja Umowy Replikacji
2.2.3 Inicjacja
repliki na serwerze Konsumenta
1 Wstęp
Replikacja jest mechanizmem pozwalającym na automatyczne kopiowanie danych z
jednego serwera do drugiego. Po skopiowaniu danych z serwera utrzymującego
główną kopie danych do serwerów utrzymujących inne kopie tych danych, mechanizm
replikacji nadal synchronizuje wszystkie kopie na serwerach, tzn. zmiana danych
na serwerze z prawem zapisu danych skutkuje wprowadzeniem tych samych zmian w
kopiach danych na innych serwerach. Utrzymywanie kopii danych na kilku
serwerach ma następujące zalety :
ˇ
pozwala
zapewnić dostępność danych zarówno dla odczytu jak i zapisu danych,
ˇ
pozwala
na równoważenie obciążenia serwerów - całkowite obciążenie operacjami np.
przeszukiwania jest dzielone na kilka serwerów utrzymujących kopie danych,
można także podzielić serwery na te udostępniane do modyfikacji danych oraz
inne tylko do odczytu (utrzymujące kopie danych tylko do odczytu)
W
serwerach Sun ONE Directory Server podstawową jednostką replikacji jest baza
danych. Każda katalogowa baza danych biorąca udział w procesie replikacji
nazywana jest repliką. Są dwa rodzaje replik : repliki read-write
(zawierająca główne kopie danych; dane te mogą być modyfikowane) i repliki
read-only (dane tylko do odczytu stanowiące wierną kopię replik
read-write).
Serwer utrzymujący replikę
read-write nazywany jest Dostawcą (ang. Supplier). Serwer
utrzymujący replikę read-only nazywany jest Konsumentem (ang. Consumer).
Replikacja między dwoma serwerami definiowana jest przez tzw. Umowę
Replikacji (ang. Replication Agreement) na serwerze Dostawcy.
Definiowana jest zawsze pomiędzy jednym serwerem Dostawcy i jednym serwerem
Konsumentem.
Istnieją cztery scenariusze
replikacji :
ˇ
Replikacja Single-Master (ang. Single-Master Replication) - jeden serwer
Dostawcy i jeden lub więcej serwerów Konsumentów),
ˇ
Replikacja Multi-Master (ang. Multi-Master Replication) - więcej niż jeden
serwer Dostawcy i żaden lub jeden lub więcej serwerów Konsumentów; między
serwerami Dostawców realizowany jest wzajemny scenaiusz Replikacji
Single-Master, tzn. na każdym z nich definiowane są Umowy Replikacji między
nimi,
ˇ
Replikacja Kaskadowa (ang. Cascading
Replication) - serwer Dostawcy -> serwer typu Hub Supplier -> ... ->
serwer typu Hub Supplier -> serwer Konsument,
ˇ
Replikacja Mieszana (ang. Mixed Environments) - korzysta z wszystkich powyższych schematów
np. replikacja Multi-Master z Replikacją Kaskadową
W
niniejszym opracowaniu przedstawiony zostanie scenariusz Replikacji
Single-Master. Konfiguracja serwerów jest przeprowadzana przy pomocy aplikacji
konsoli serwera administracyjnego firmy Sun Microsystems.
2
Replikacja
typu Single-Master w Sun ONE Directory Server
Poniższy rysunek przedstawia
schemat replikacji typu Single - Master.
2.1 Konfiguracja serwera 'Konsumenta'
Konfiguracja
serwera 'Konsumenta' polega na utworzeniu bazy danych dla repliki read-only
oraz obiektu (konta) użytkownika repliki read-only, a następnie konfiguracji
utworzonej bazy danych jako repliki read-only.
2.1.1 Utworzenie katalogowej bazy danych
Aby utworzyć
katalogową bazę danych należy wybrać zakładkę 'Configuration', a następnie
wybrać komendę 'New Root Suffix' z menu kontekstowego na elemencie 'Data'.
Po wybraniu komendy
wyświetlony zostaje dialog konfiguracyjny. W nim należy określić nazwę
wyróżnioną dla korzenia drzewa katalogowego (np. dn : dc=man,dc=poznan,dc=pl, w
oknie dialogowym poniżej pole edycyjne jest zbyt krótkie, dlatego na początku
można przeczytać : c=man,...) oraz nazwę bazy danych (tutaj :
ichb_dom_replica).
2.1.2 Obiekt użytkownika dla repliki read-only
Należy wybrać zakładkę 'Directory' a następnie w menu
kontekstowym obiektu 'config' komendę 'New -> Other'. Na ekranie wyświetlany
jest dialog wyboru klasy obiektu, w którym należy wybrać klasę
'extensibleobject'.
Po naciśnięciu klawisza
'OK.' pojawia się dialog konfiguracyjny obiektu. Należy dodać oraz określić
atrybuty 'Full name' (cn) oraz 'Password' (userPassword). Inne atrybuty (poza
Object class) można usunąć.
2.1.3 Konfiguracja katalogowej bazy danych jako repliki read-only
W zakładce 'Configuration' należy w katalogu 'Replication' zaznaczyć
obiekt ichb_dom_replica (reprezentujący bazę danych utworzoną w punkcie 2.1.1). W prawej części okna wyświetlane są informacje o
ustawieniach replikacji. Należy zaznaczyć pole 'Enable Replica', a następnie
zaznaczyć opcję 'Dedicated Consumer' w sekcji 'Replica Role' oraz dodać DN
użytkownika utworzonego w punkcie 2.1.2 w pole 'Current Supplier DNs' w sekcji 'Update
Settings',
2.2 Konfiguracja serwera 'Dostawcy'
Należy wykonać następujące
kroki :
1.
Ustawienie
serwera LDAP utrzymującego replikę read-write
2.
Ustawienia
repliki read-write na serwerze
3.
Konfiguracja
połączenia z serwerem utrzymującym replikę read-only
4.
Inicjacja
repliki read-only na serwerze Konsumenta
2.2.1 Ustawienia serwera
Pierwszym
krokiem w konfiguracji serwera utrzymującego replikę read-write jest ustawienie
serwera jako serwer typu Dostawca (ang. Supplier). Należy wejść do zakładki
'Configuration'
i zaznaczyć element 'Replication' w drzewie. Po prawej stronie okna w zakładce
'Supplier Settings' należy zaznaczyć opcję 'Enable Changelog'. W polu
"Changelog database directory" definiowana jest nazwa katalogu, w którym
zapisywane są pliki z informacją o zmianach danych w replikach typu read-write
(tutaj : /home/sunone/servers/slapd-cypress/changelogdb ).
2.2.2 Ustawienia repliki read-write. Definicja Umowy Replikacji
Drugim krokiem
jest wybór bazy danych oraz jej konfiguracja jako repliki read-write. W tym
celu w zakładce 'Configuration' w poddrzewie 'Replication' wybieramy bazę
danych (w tym przypadku 'userRoot'). Po prawej stronie okna pojawia się
zakładka 'Replica Settings'. Należy w niej zaznaczyć pole 'Enable Replica', a
dalej określić scenariusz replikacji ('Replica Role') jako 'Single Master'.
Następnie należy zdefiniować
Umowę Replikacji (Replication Agreement). Na elemencie 'userRoot'
reprezentującym bazę danych - replikę read-write należy otworzyć menu
kontekstowe i z niego wybrać komendę 'New Replication Agreement'.
Po wybraniu komendy na
ekranie wyświetlony zostaje dialog, który pozwala na zdefiniowanie w trzech
krokach Umowy Replikacji. W pierwszy kroku podajemy nazwę i opis umowy. W
następnym definiujemy serwer Konsumenta (adres i port) oraz podajemy nazwę
konta oraz hasło użytkownika utworzonego wcześniej na serwerze Konsumenta
(punkt 2.1.2 ) dla repliki read-only. Tym kontem będzie się
posługiwał serwer Dostawcy przy uaktualnianiu bazy na serwerze Konsumenta. Trzy
następne rysunki przedstawiają opisane kroki. Ostatni rysunek przedstawia
podsumowanie wprowadzonych danych.
Naciskając klawisz 'Done' zatwierdzamy Umowę Replikacji.
W rezultacie pod elementem reprezentującym naszą replikę read-write
('userRoot') w poddrzewie 'Replication' (zakładka 'Configuration') pojawia się
element reprezentujący Umowę Replikacji (tutaj : IChB_Dom_Replica).
2.2.3 Inicjacja repliki na serwerze Konsumenta
Ostatnim etapem konfiguracji
repliki read - write jest jej inicjacja na serwerze 'Konsumenta'. Polega ona na
ustaleniu połączenia z serwerem 'Konsumenta' oraz skopiowaniu na niego danych z
serwera 'Dostawcy'.
W tym celu nalęży wybrać z
menu kontekstowego elementu reprezentującego Umowę Replikacji komendę
'Initialize Consumer'. Po poprawnym wykonaniu operacji replika read-only
stanowi wierną kopię repliki read-write. Od tego momentu serwer Dostawcy w
przypadku zmian danych w replice read-write aktualizuje dane w replice
read-only na serwerze Konsumenta.
3 Podsumowanie
Przedstawiony w
opracowaniu schemat replikacji Single-Master wdrożony na serwerach Sun ONE
Directory Server spełnia zadanie zwiększenia stopnia dostępności danych oraz
równoważenia obciążenia serwerów. Istotną cechą serwera Sun ONE jest replikacja
nie tylko danych, ale także schematów danych. Zmiana schematu na serwerze
Dostawcy skutkuje aktualizacją schematu na serwerze Konsumenta. Replikacja w
serwerach LDAP nie doczekała się jak dotąd jednego spójnego standardu.
Niemożliwe jest przeprowadzenie replikacji np. między serwerami Sun ONE i
OpenLDAP, co zmusza do wykorzystywania serwerów LDAP jednego producenta.
4 Bibliografia
|
[ 1 ] |
T.A. Howes, M.C. Smith, G.S. Good
"Understanding and Deploying LDAP Directory Services", 1999 |
|
[ 2 ] |
Sun Microsystems "iPlanet Directory Server Deployment Guide", 2001 |
|
[ 3 ] |
Sun Microsystems "iPlanet Directory Server Administrator's Guide",
2001 |