Architektura wysokiej dostępności od Oracle

29 kwietnia 2016, Michał Wyszyński

Jakiś czas temu trafiłem na bardzo interesujący wpis dotyczący środowisk wysokiej dostępności (ang. HA – High Availability) autorstwa pana Uwe Hesse’a. Ponieważ wolą autora było przetłumaczenie tego wpisu na możliwie dużą ilość języków, postanowiłem, że napiszę jego polską wersję. Oryginalny wpis dotyczący Oracle HA Architecture można znaleźć tutaj. Nie jestem zwolennikiem tłumaczenia wszystkich pojęć na siłę, więc część terminów technicznych i nazw własnych zostawię w oryginalnej postaci – w ten sposób łatwiej znaleźć jakieś materiały na ich temat.

Popularnym tematem wielu kursów dotyczących Architektury Baz Danych Oracle jest Wysoka Dostępność. W tym wpisie chciałbym przedstawić wysokopoziomowy przegląd obejmujący „Zwykłe” Jedno-instancjowe Bazy Danych (ang. Single Instance Databases), Data Guard, Real Application Clusters (RAC) oraz Rozszerzone RAC (czasami nazywane „Rozciągniętymi Klastrami”). Połączenie RAC i Data Guard jest reklamowane przez Oracle pod hasłem Architektury Maksymalnej Dostępności (ang. Maximum Availability Architecture – MAA). Jako dodatek do tych rozwiązań HA od Oracle, krótko opiszę także jedno rozwiązanie przygotowane przez firmę zewnętrzną: Zdalny Mirroring. Nie mam zamiaru zagłębiać się w szczegóły techniczne każdego z tych rozwiązań ale chcę wskazać czym się różnią od siebie oraz zwięźle napisać o ich różnych zaletach i potencjalnych wadach.

Na początku przyjrzymy się nadal najpopularniejszemu przypadkowi architektury bazy danych Oracle, czyli Pojedynczej Instancji. System zarządzania relacyjną bazą danych (ang. RDBMS – Relational Data Base Management System) od Oracle składa się zawsze z jednej Bazy Danych – złożonej z Plików Danych, online’owych plików logów Redo i plików kontrolnych a także z przynajmniej jednej Instancji – na którą składają się Struktury Pamięci (takie jak Cache Bufora Bazy Danych) i Procesy Działające w Tle (jak Database Writer). Jeśli mamy jedną Bazę Danych i wiele Instancji które się do niej dostają – to jest to RAC. Jeśli jest tylko jedna Instancja dostająca się do Bazy Danych – mamy wtedy konfigurację typu Single Instance. Małe instalacje przechowują wszystkie komponenty na jednym Serwerze, tak jak poniżej:

Równie popularne jest w dzisiejszych czasach umieszczanie Bazy Danych wewnątrz Storage Area Network (SAN) tak jak poniżej:

Z perspektywy HA, ta architektura jest wrażliwa: Serwer A oraz Serwer B są Pojedynczymi Punktami Błędów (ang. Single Point of Failures – SPOF) tak samo jak Baza Danych A oraz Baza Danych B. Poza tym cały obszar w którym znajdują się te serwery też jest SPOFem. Jeśli którykolwiek ze SPOFów zawiedzie, cała baza danych będzie niedostępna. „Zwykły” RAC taki jak ten poniżej adresuje takie serwerowe SPOFy:

Jeśli jeden z dwóch Serwerów zawiedzie, Baza Danych będzie wciąż dostępna. Więcej na temat architektury RAC pan UWE napisał w tym poście. Oczywiście HA nie jest jedynym powodem żeby używać RACów. Pomiędzy innymi równie wartościowymi powodami jest jeszcze Skalowalność: jeśli nasze zapotrzebowania wzrosną w przyszłości, będziemy mogli dodać kolejny Serwer (Węzeł) do Klastra. Dodatkowo mamy takie opcje jak Zarządzanie Usługą (ang. Service-Management) czy Równoważenie Obciążenia (ang. Load Balancing) przez RAC. W skrócie: RAC nie jest potrzebny jako sposób na HA, ale jest to poza zakresem tego artykułu by omawiać ta bardziej szczegółowo. Minusem tej architektury z punktu widzenia HA jest fakt, że Baza Danych C, a właściwie cały Site C jest SPOFem. Jeśli np. ognień zniszczyłby Site C, Baza Danych będzie niedostępna. Dlatego mamy możliwość rozciągnięcia Bazy Danych pomiędzy dwoma Site’ami i to właśnie nazywane jest Rozszerzonym RAC:

W tym wypadku oba Site’y nie są już SPOFami. Baza Danych D jest mirror’owana między dwoma site’ami. Minusem takiej architektury jest koszt Połączenia Sieciowego pomiędzy dwoma Site’ami, jeśli pożądane jest duże oddalenie między nimi. Jest to krytyczne, ponieważ duży Wolumen Danych musi być mirror’owany. W efekcie odległość ta nie przekracza paru kilometrów, co może prowadzić do konfliktu z celami Ochrony Przed Katastrofą. I tutaj do akcji wkracza Data Guard: na potrzeby Ochrony Przed Katastrofą możemy łatwiej osiągnąć większe odległości, ponieważ nie przesyłamy całego Wolumenu Danych a jedynie (relatywnie mały) Protokół Redo. Na kolejnym obrazku przedstawione są Serwery przechowujące Pojedyncze Instancje takie jak Serwer A i Serwer B powyżej:

Protokół Redo z Podstawowej Bazy Danych jest wykorzystywany do aktualizowania Bazy Danych w trybie Standby. Jeśli Podstawowa Baza Danych zawiedzie, możemy przełączyć się na Bazę Standby i kontynuować pracę produkcyjną. Przełączenie może zostać wykonane automatycznie przez Obserwatora (jest to nazywane Szybkim Przełączeniem (ang. Fast-Start Failover). Odległość między dwoma Serwerami może sięgać nawet tysięcy kilometrów – w zależności od typu transmisji redo oraz poziomu zabezpieczeń. Jeśli połączymy RAC z Data Guard, otrzymamy MAA. Oczywiście MAA jest bardzo drogim rozwiązaniem, ale łączy w sobie zalety RAC i Data Guard.

Popularnym rozwiązaniem HA oferowanym przez firmy zewnętrzne jest Zdalny Mirroring. Wysokopoziomowo wygląda mniej więcej tak:

remotemirroring

Site tutaj też nie jest SPOFem, tak jak w przypadku Rozszerzonego RAC. Minus tego rozwiązania: Odległość jest zazwyczaj ograniczona z tego samego powodu co w przypadku Rozszerzonego RAC. Dodatkowo, drugi Site nie może być wykorzystywany produkcyjnie jeśli proces mirror’owania trwa – w przeciwieństwie do powyższego rozwiązania proponowanego przez Oracle. Dzięki RAC wszystkie Serwery, czy inaczej Site’y są używane produkcyjnie. Nawet korzystając z Data Guard, instancja Standby nie musi tylko czekać na to aż Podstawowa zawiedzie. Może być w tym czasie wykorzystywana Tylko Do Odczytu – efektywnie redukując obciążenie Podstawowej instancji:

Powyższy obrazek ilustruje Nową Funkcjonalność 11g – Zapytania w Czasie Rzeczywistym dla Baz Danych w trybie Standby (ang. Real-Time Query for Physical Standby Databases). Instancja Standby jest dostępna Do Odczytu w trakcie trwania aktualizacji. Dodatkowo, możliwe jest robienie Kopi Bezpieczeństwa na Nośniki Fizyczne (także dla niższych wersji niż 11g).

Tagi: , , , , , , , ,

Zapraszamy do kontaktu!

Pretius jest firmą tworząca oprogramowanie wspierające biznes.
Tworzymy aplikacje webowe wykorzystując: Java, Oracle DB, Oracle Apex, AngularJS.
Skontaktuj się z nami, aby porozmawiać o tym jak możemy pomóc w realizacji Twojego projektu!