Wiadomości
Jak skonfigurować bazę DB2, aby zapewnić wysoką dostępność usług
16 sierpnia 2010 13:34,
Mariusz Czopiński
W wielu obszarach gospodarczych dzisiejszego świata od systemów IT wymaga się, aby nieprzerwanie dostarczały usługę. W olbrzymiej większości systemy te są powiązane z bazami danych, których zabezpieczenie jest niezwykle istotne dla spełnienia warunku wysokiej dostępności.
Jednym z rozwiązań wysokiej dostępności HA (High Availability) baz danych jest zapewnienie synchronizacji i replikacji danych pomiędzy dwoma serwerami bazodanowymi. Jeden z nich działa, jako serwer główny (PRIMARY), który obsługuje transakcje. Drugi pełni role serwera zapasowego (STANDBY), który uaktywnia się po awarii serwera głównego. Podczas normalnej pracy system główny replikuje dane na system zapasowy. Dzięki temu system zapasowy ma zawsze aktualną kopię danych.
Opisana powyżej funkcjonalność została zaimplementowana w DB2 pod nazwą HADR (High Availability & Disaster Recovery). Jest ona dostępna bez dodatkowych opłat licencyjnych tylko w wersji Enterprise. Zanim przejdziemy do konfiguracji HADR musimy spełnić dwa warunki wstępne. Po pierwsze musi być zgodność obu serwerów na poziomie architektury procesora. Po drugie wersje zarówno DB2, jak i systemów operacyjnych muszą być zgodne. Zaleca się, aby oba serwery zarówno główny, jak i zapasowy miały porównywalną moc obliczeniową, tak aby po przełączeniu nie nastąpił spadek wydajności całego systemu. Oto konfiguracja krok po kroku.
# db2 activate db prod
# db2 start hadr on db prod as primary
IBM pod koniec zeszłego roku wprowadził na rynek produkt o nazwie DB2 PureScale, który w całkowicie odmienny do HADR sposób realizuje wymagania wysokiej dostępności systemów IT. Dotykowo jest to rozwiązanie wysoko skalowalne. Ale o tym w innym razem.
Autor - Mariusz Czopiński - jest specjalistą w dziedzinie relacyjnych baz danych w IBM Polska
Opisana powyżej funkcjonalność została zaimplementowana w DB2 pod nazwą HADR (High Availability & Disaster Recovery). Jest ona dostępna bez dodatkowych opłat licencyjnych tylko w wersji Enterprise. Zanim przejdziemy do konfiguracji HADR musimy spełnić dwa warunki wstępne. Po pierwsze musi być zgodność obu serwerów na poziomie architektury procesora. Po drugie wersje zarówno DB2, jak i systemów operacyjnych muszą być zgodne. Zaleca się, aby oba serwery zarówno główny, jak i zapasowy miały porównywalną moc obliczeniową, tak aby po przełączeniu nie nastąpił spadek wydajności całego systemu. Oto konfiguracja krok po kroku.
- Definiujemy porty TCP/IP w /etc/services do komunikacji między serwerami. Operacje wykonujemy na obu serwerach.
- Ustawiamy parametry konfiguracyjne HADR.
- Wykonujemy kopie bazy serwera głównego, aby odtworzyć ją na serwerze zapasowym i w ten sposób przenieść konfigurację.
- Przenosimy wykonaną kopię bazy na serwer zapasowy i odtwarzamy bazę poniższą komendą.
- Mamy przeniesioną całą konfigurację z serwera głównego. Musimy ją zmodyfikować w następujący sposób.
- Startujemy serwery w odpowiedniej kolejności. Najpierw serwer zapasowy a po nim serwer główny. Na serwerze zapasowym startujemy usługę HADR w trybie standy.
- Na serwerze głównym aktywujemy bazę i startujemy usługę HADR w trybie primary.
# echo "hadr_local_svc 50001" >> /etc/services
# echo "hadr_remote_svc 50002" >> /etc/services
# db2 update db cfg for prod using hadr_local_host <adres IP serwera glownego>
# db2 update db cfg for prod using hadr_local_svc hadr_local_svc
# db2 update db cfg for prod using hadr_remote_host <adres IP serwera zapasowego>
# db2 update db cfg for prod using hadr_remote_svc hadr_remote_svc
# db2 update db cfg for prod using hadr_remote_inst <nazwa instancji na serwerze zapasowym>
# db2 update db cfg for prod using logindexbuild on
# db2 update db cfg for prod using logretain on
# db2 update alternate server for database prod using hostname < Ip servera zapasowego> port 50003
# db2 backup db prod
# db2 restore db prod
# db2 update db cfg for prod using hadr_local_host <adres IP serwera zapasowego>
# db2 update db cfg for prod using hadr_local_svc hadr_remote_svc
# db2 update db cfg for prod using hadr_remote_host <adres IP serwera glownego>
# db2 update db cfg for prod using hadr_remote_svc hadr_local_svc
# db2 update alternate server for database prod using hostname < Ip servera glownego> port 50003
# db2 deactivate db prod
# db2 start hadr on db prod as standby
# db2 activate db prod
# db2 start hadr on db prod as primary
IBM pod koniec zeszłego roku wprowadził na rynek produkt o nazwie DB2 PureScale, który w całkowicie odmienny do HADR sposób realizuje wymagania wysokiej dostępności systemów IT. Dotykowo jest to rozwiązanie wysoko skalowalne. Ale o tym w innym razem.
Autor - Mariusz Czopiński - jest specjalistą w dziedzinie relacyjnych baz danych w IBM Polska
Oryginalny tekst został opublikowany na www.computerworld.pl
Komentarze (0)
- Kingston: Nowa linia dysków SSD
- Microsoft zapowiada nowy system plików - ReFS
- Intel: SSD 520 - nowa linia szybkich dysków
- Praktyczne porady dla administratorów na 2012 rok
- Co powinien wiedzieć każdy specjalista IT?
- Narzędzia dla administratorów sieci
- Windows Intune 3.0 - szansa na perfekcyjne narzędzie?
- Kontrowersyjne decyzje Oracle odnośnie Javy
- Testy penetracyjne pomogą w obronie przed cyberatakami
- MSP: kierunki rozwoju technologii w 2012 roku
Polecane
Przełomowy rok... znowu
Lektura firmowych informacji prasowych i prognoz firm analitycznych nie pozostawia wątpliwości - każdego roku...
Spokój i luz administratora
Wymagania wobec pracowników działów IT rosną proporcjonalnie do stopnia rozwoju teleinformatyki. Oczekuje się, że...