Wiele osób zna system DBMS PostgreSQL i sprawdził się on w małych instalacjach. Jednak trend w kierunku Open Source staje się coraz bardziej wyraźny, nawet jeśli chodzi o duże firmy i wymagania przedsiębiorstw. W tym artykule opowiemy jak zintegrować Postgres ze środowiskiem korporacyjnym i podzielimy się naszymi doświadczeniami w tworzeniu systemu kopii zapasowych (BSS) dla tej bazy danych na przykładzie systemu kopii zapasowych Commvault.
PostgreSQL udowodnił już swoją wartość – DBMS sprawdza się znakomicie, korzystają z niego modne cyfrowe biznesy jak Alibaba i TripAdvisor, a brak opłat licencyjnych sprawia, że jest kuszącą alternatywą dla takich potworów jak MS SQL czy Oracle DB. Jednak gdy tylko zaczniemy myśleć o PostgreSQL w środowisku korporacyjnym, od razu natrafiamy na rygorystyczne wymagania: „A co z odpornością na błędy konfiguracji? odporność na katastrofy? gdzie kompleksowy monitoring? A co z automatycznymi kopiami zapasowymi? A co z używaniem bibliotek taśm zarówno bezpośrednio, jak i na dodatkowej pamięci masowej?”
Z jednej strony PostgreSQL nie ma wbudowanych narzędzi do tworzenia kopii zapasowych, takich jak „dorosłe” systemy DBMS, takie jak RMAN w Oracle DB lub SAP Database Backup. Z kolei dostawcy korporacyjnych systemów tworzenia kopii zapasowych (Veeam, Veritas, Commvault) choć obsługują PostgreSQL, tak naprawdę działają tylko z określoną (zwykle samodzielną) konfiguracją i z zestawem różnych ograniczeń.
Systemy kopii zapasowych specjalnie zaprojektowane dla PostgreSQL, takie jak Barman, Wal-g, pg_probackup, są niezwykle popularne w małych instalacjach DBMS PostgreSQL lub tam, gdzie nie są potrzebne duże kopie zapasowe innych elementów krajobrazu IT. Na przykład oprócz PostgreSQL infrastruktura może obejmować serwery fizyczne i wirtualne, OpenShift, Oracle, MariaDB, Cassandra itp. Wskazane jest utworzenie kopii zapasowej tego wszystkiego za pomocą wspólnego narzędzia. Instalowanie osobnego rozwiązania wyłącznie dla PostgreSQL to zły pomysł: dane zostaną skopiowane gdzieś na dysk, a następnie trzeba będzie je usunąć na taśmę. Ta podwójna kopia zapasowa wydłuża czas tworzenia kopii zapasowych, a także, co ważniejsze, czas odzyskiwania.
W rozwiązaniu korporacyjnym kopia zapasowa instalacji odbywa się z określoną liczbą węzłów w dedykowanym klastrze. Jednocześnie na przykład Commvault może współpracować tylko z klastrem składającym się z dwóch węzłów, w którym Podstawowy i Dodatkowy są ściśle przypisane do określonych węzłów. Tworzenie kopii zapasowych z poziomu podstawowego ma sens tylko wtedy, gdy tworzenie kopii zapasowych z poziomu dodatkowego ma swoje ograniczenia. Ze względu na specyfikę systemu DBMS, na dysku wtórnym nie jest tworzony zrzut, dlatego pozostaje jedynie możliwość utworzenia kopii zapasowej pliku.
Aby zmniejszyć ryzyko przestojów, podczas tworzenia systemu odpornego na awarie tworzona jest „aktywna” konfiguracja klastra, a serwer podstawowy może stopniowo migrować między różnymi serwerami. Na przykład samo oprogramowanie Patroni uruchamia Podstawowy w losowo wybranym węźle klastra. IBS nie ma możliwości śledzenia tego od razu po wyjęciu z pudełka, a jeśli konfiguracja się zmieni, procesy zostaną przerwane. Oznacza to, że wprowadzenie kontroli zewnętrznej uniemożliwia efektywną pracę ISR, ponieważ serwer sterujący po prostu nie rozumie, skąd i jakie dane należy skopiować.
Kolejnym problemem jest implementacja kopii zapasowej w Postgresie. Jest to możliwe poprzez zrzut i działa na małych bazach danych. Jednak w przypadku dużych baz danych zrzut zajmuje dużo czasu, wymaga dużych zasobów i może doprowadzić do awarii instancji bazy danych.
Kopia zapasowa plików koryguje sytuację, ale w przypadku dużych baz danych jest powolna, ponieważ działa w trybie jednowątkowym. Ponadto sprzedawcy mają szereg dodatkowych ograniczeń. Albo nie można jednocześnie używać kopii zapasowych plików i zrzutów, albo deduplikacja nie jest obsługiwana. Problemów jest wiele i najczęściej łatwiej jest wybrać drogi, ale sprawdzony DBMS zamiast Postgresa.
Nie ma gdzie się wycofać! Moskiewscy programiści są w tyle!
Jednak ostatnio nasz zespół stanął przed trudnym wyzwaniem: w projekcie stworzenia AIS OSAGO 2.0, w którym stworzyliśmy infrastrukturę IT, programiści wybrali PostgreSQL dla nowego systemu.
Dużym twórcom oprogramowania znacznie łatwiej jest korzystać z „modnych” rozwiązań open source. Facebook ma wystarczającą liczbę specjalistów, aby wesprzeć działanie tego DBMS. A w przypadku RSA wszystkie zadania „drugiego dnia” spadły na nasze barki. Naszym zadaniem było zapewnienie odporności na awarie, złożenie klastra i oczywiście utworzenie kopii zapasowej. Logika działania była następująca:
- Naucz SRK tworzenia kopii zapasowych z węzła podstawowego klastra. Aby to zrobić, SRK musi go znaleźć - co oznacza, że konieczna jest integracja z tym lub innym rozwiązaniem do zarządzania klastrami PostgreSQL. W przypadku RSA wykorzystano do tego oprogramowanie Patroni.
- Zdecyduj o rodzaju kopii zapasowej na podstawie ilości danych i wymagań dotyczących odzyskiwania. Na przykład, jeśli chcesz szczegółowo przywrócić strony, użyj zrzutu, a jeśli bazy danych są duże i szczegółowe przywracanie nie jest wymagane, pracuj na poziomie pliku.
- Dołącz możliwość blokowego tworzenia kopii zapasowych do rozwiązania, aby utworzyć kopię zapasową w trybie wielowątkowym.
Jednocześnie początkowo za cel postawiliśmy sobie stworzenie skutecznego i prostego systemu bez monstrualnej uprzęży dodatkowych komponentów. Im mniej kul, tym mniejsze obciążenie personelu i mniejsze ryzyko niepowodzenia IBS. Od razu wykluczyliśmy podejścia wykorzystujące Veeam i RMAN, bo zestaw dwóch rozwiązań już wskazuje na zawodność systemu.
Trochę magii dla przedsiębiorczości
Musieliśmy zatem zagwarantować niezawodne kopie zapasowe dla 10 klastrów po 3 węzły każdy, z tą samą infrastrukturą odzwierciedloną w zapasowym centrum danych. Centra danych w zakresie PostgreSQL działają na zasadzie aktywno-pasywnej. Całkowity rozmiar bazy danych wynosił 50 TB. Każdy system kontroli na poziomie korporacyjnym może z łatwością sobie z tym poradzić. Ale zastrzeżenie jest takie, że początkowo Postgres nie ma pojęcia o pełnej i głębokiej kompatybilności z systemami kopii zapasowych. Dlatego musieliśmy szukać rozwiązania, które początkowo miałoby maksymalną funkcjonalność w połączeniu z PostgreSQL i dopracować system.
Zorganizowaliśmy 3 wewnętrzne „hackathony” – przyjrzeliśmy się ponad pięćdziesięciu wydarzeniom, przetestowaliśmy je, wprowadziliśmy zmiany w związku z naszymi hipotezami i przetestowaliśmy je ponownie. Po przejrzeniu dostępnych opcji wybraliśmy Commvault. Od razu po wyjęciu z pudełka produkt ten mógł współpracować z najprostszą instalacją klastra PostgreSQL, a jego otwarta architektura budziła nadzieje (które były uzasadnione) na pomyślny rozwój i integrację. Commvault może także tworzyć kopie zapasowe dzienników PostgreSQL. Na przykład Veritas NetBackup w zakresie PostgreSQL może tworzyć tylko pełne kopie zapasowe.
Więcej o architekturze. W każdym z dwóch centrów danych zainstalowano serwery zarządzające Commvault w konfiguracji CommServ HA. System jest dublowany, zarządzany poprzez jedną konsolę i z punktu widzenia HA spełnia wszystkie wymagania przedsiębiorstwa.
W każdym centrum danych uruchomiliśmy także dwa serwery nośników fizycznych, do których podłączyliśmy macierze dyskowe i biblioteki taśmowe dedykowane specjalnie do tworzenia kopii zapasowych poprzez SAN poprzez Fibre Channel. Rozszerzone bazy danych deduplikacji zapewniły odporność serwerów multimediów na awarie, a podłączenie każdego serwera do każdego pliku CSV umożliwiło ciągłą pracę w przypadku awarii dowolnego komponentu. Architektura systemu pozwala na kontynuację tworzenia kopii zapasowych nawet w przypadku awarii jednego z centrów danych.
Patroni definiuje węzeł podstawowy dla każdego klastra. Może to być dowolny wolny węzeł w centrum danych – ale tylko w większości. W kopii zapasowej wszystkie węzły są drugorzędne.
Aby Commvault wiedział, który węzeł klastra jest Podstawowy, zintegrowaliśmy system (dzięki otwartej architekturze rozwiązania) z Postgres. W tym celu utworzono skrypt raportujący bieżącą lokalizację węzła podstawowego do serwera zarządzającego Commvault.
Ogólnie proces wygląda następująco:
Patroni wybiera Podstawowy → Keepalived pobiera klaster IP i uruchamia skrypt → agent Commvault w wybranym węźle klastra otrzymuje powiadomienie, że jest to podstawowy → Commvault automatycznie rekonfiguruje kopię zapasową w pseudokliencie.
Zaletą takiego podejścia jest to, że rozwiązanie nie wpływa na spójność, poprawność logów, czy odzyskiwanie instancji Postgres. Jest również łatwo skalowalny, ponieważ nie ma już konieczności naprawiania węzłów podstawowych i dodatkowych Commvault. Wystarczy, że system zorientuje się, gdzie znajduje się Primary, a liczbę węzłów można zwiększyć do niemal dowolnej wartości.
Rozwiązanie nie udaje idealnego i ma swoje niuanse. Commvault może wykonać kopię zapasową tylko całej instancji, a nie poszczególnych baz danych. Dlatego dla każdej bazy danych utworzono osobną instancję. Prawdziwi klienci są łączeni w wirtualnych pseudoklientów. Każdy pseudoklient Commvault jest klastrem UNIX. Zostają do niego dodane węzły klastra, na których jest zainstalowany agent Commvault dla Postgres. W rezultacie kopia zapasowa wszystkich węzłów wirtualnych pseudoklienta jest tworzona w ramach jednej instancji.
W obrębie każdego pseudoklienta wskazany jest aktywny węzeł klastra. To właśnie definiuje nasze rozwiązanie integracyjne dla Commvault. Zasada jego działania jest dość prosta: jeśli w węźle zostanie podniesiony adres IP klastra, skrypt ustawia parametr „aktywny węzeł” w pliku binarnym agenta Commvault - w rzeczywistości skrypt ustawia „1” w wymaganej części pamięci . Agent przesyła te dane do CommServe, a Commvault tworzy kopię zapasową z żądanego węzła. Dodatkowo na poziomie skryptu sprawdzana jest poprawność konfiguracji, co pozwala uniknąć błędów przy uruchamianiu kopii zapasowej.
Jednocześnie kopie zapasowe dużych baz danych są tworzone w blokach obejmujących wiele wątków, spełniając wymagania RPO i okna tworzenia kopii zapasowych. Obciążenie systemu jest nieznaczne: Pełne kopie nie zdarzają się tak często, w inne dni zbierane są tylko logi i w okresach małego obciążenia.
Przy okazji, zastosowaliśmy odrębną politykę tworzenia kopii zapasowych logów archiwalnych PostgreSQL - są one przechowywane według innych zasad, kopiowane według innego harmonogramu i nie jest dla nich włączona deduplikacja, ponieważ logi te zawierają unikalne dane.
Aby zapewnić spójność w całej infrastrukturze IT, na każdym z węzłów klastra instalowani są oddzielni klienci plików Commvault. Wykluczają pliki Postgres z kopii zapasowych i są przeznaczone wyłącznie do tworzenia kopii zapasowych systemu operacyjnego i aplikacji. Ta część danych również ma swoją politykę i okres przechowywania.
Obecnie IBS nie wpływa na usługi zwiększające produktywność, ale jeśli sytuacja się zmieni, Commvault może włączyć ograniczanie obciążenia.
Czy to jest dobre? Dobry!
Otrzymaliśmy więc nie tylko wykonalną, ale także w pełni zautomatyzowaną kopię zapasową instalacji klastra PostgreSQL, która spełnia wszystkie wymagania połączeń korporacyjnych.
Parametry RPO i RTO wynoszące 1 godzinę i 2 godziny objęte są marginesem, co oznacza, że system dotrzyma ich nawet przy znacznym zwiększeniu wolumenu przechowywanych danych. Wbrew wielu wątpliwościom PostgreSQL i środowisko korporacyjne okazały się w miarę kompatybilne. A teraz wiemy z własnego doświadczenia, że tworzenie kopii zapasowych takich systemów DBMS jest możliwe w szerokiej gamie konfiguracji.
Oczywiście na tej drodze musieliśmy zużyć siedem par żelaznych butów, pokonać szereg trudności, nadepnąć na kilka grabi i poprawić szereg błędów. Ale teraz podejście to zostało już przetestowane i można je zastosować do wdrożenia Open Source zamiast zastrzeżonego systemu DBMS w trudnych warunkach korporacyjnych.
Czy próbowałeś pracować z PostgreSQL w środowisku korporacyjnym?
Autorzy:
Oleg Lavrenov, inżynier projektant systemów przechowywania danych, Jet Infosystems
Dmitry Erykin, inżynier projektant systemów komputerowych w Jet Infosystems
Źródło: www.habr.com