Wiele osób zna system zarządzania bazą danych PostgreSQL, który doskonale sprawdził się w małych instalacjach. Jednak tendencja do przechodzenia na Open Source staje się coraz bardziej oczywista, nawet w przypadku dużych firm i wymagań korporacyjnych. W tym artykule opowiemy, jak zintegrować Postgresa w środowisku korporacyjnym i podzielimy się doświadczeniem w tworzeniu systemu kopii zapasowej (BKP) dla tej bazy danych na przykładzie systemu kopii zapasowej Commvault.
PostgreSQL już udowodniła swoją przydatność — system zarządzania bazą danych doskonale działa, korzystają z niej modne cyfrowe firmy takie jak Alibaba i TripAdvisor, a brak opłat licencyjnych czyni ją kuszącą alternatywą dla takich gigantów jak MS SQL czy Oracle DB. Ale gdy tylko zaczynamy myśleć o PostgreSQL w kontekście przedsiębiorstw, natychmiast napotykamy surowe wymagania: „A co z odpornością konfiguracji? Co z odpornością na katastrofy? Gdzie jest kompleksowy monitoring? A zautomatyzowane kopie zapasowe? A użycie bibliotek taśmowych zarówno jako magazynów głównych, jak i zapasowych?”
Z jednej strony PostgreSQL nie ma wbudowanych narzędzi do tworzenia kopii zapasowych, jak „dojrzałe” systemy zarządzania bazą danych takie jak RMAN w Oracle DB czy SAP Database Backup. Z drugiej strony dostawcy korporacyjnych systemów do tworzenia kopii zapasowych (Veeam, Veritas, Commvault) mimo wsparcia dla PostgreSQL, w rzeczywistości działają tylko z określoną (zwykle samodzielną) konfiguracją i z szeregiem różnych ograniczeń.
Specjalnie zaprojektowane dla PostgreSQL systemy tworzenia kopii zapasowych, takie jak Barman, Wal-g, pg_probackup, cieszą się dużą popularnością w małych instalacjach systemu PostgreSQL lub w sytuacjach, gdy nie są potrzebne ciężkie kopie zapasowe innych elementów IT. Na przykład, poza PostgreSQL w infrastrukturze mogą znajdować się fizyczne i wirtualne serwery, OpenShift, Oracle, MariaDB, Cassandra itp. Wszystko to powinno być kopiowane za pomocą wspólnego narzędzia. Wdrożenie osobnego rozwiązania wyłącznie dla PostgreSQL to zła decyzja: dane będą kopiowane gdzieś na dysk, a potem trzeba je przenieść na taśmę. Taki podział tworzenia kopii zapasowych zwiększa czas tworzenia kopii, a co gorsza — czas ich przywracania.
W rozwiązaniach enterprise tworzenie kopii zapasowych instalacji odbywa się z wykorzystaniem określonej liczby węzłów w dedykowanym klastrze. Na przykład Commvault potrafi obsługiwać tylko dwuwęzłowy klaster, w którym Primary i Secondary są ściśle przypisane do określonych węzłów. Backup z Primary ma sens, ponieważ tworzenie kopii zapasowych z Secondary ma swoje ograniczenia. Z powodu szczególnych cech DBMS, dump na Secondary nie jest tworzony, co pozostawia tylko możliwość wykonania kopii zapasowej plików.
Aby zredukować ryzyko przestojów, przy tworzeniu systemu odpornego na awarie powstaje „żywa” konfiguracja klastra, a Primary może stopniowo migrować między różnymi serwerami. Na przykład oprogramowanie Patroni automatycznie uruchamia Primary na losowo wybranym węźle klastra. SRK nie ma możliwości śledzenia tego „z pudełka”, a zmiana konfiguracji prowadzi do awarii procesów. Oznacza to, że wprowadzenie zewnętrznego zarządzania utrudnia efektywne działanie SRK, ponieważ serwer zarządzający po prostu nie rozumie, skąd i jakie dane powinny być kopiowane.
Kolejnym problemem jest realizacja kopii zapasowej w Postgresie. Jest to możliwe za pomocą dumpu i działa w przypadku małych baz danych. Jednak w dużych bazach dump trwa długo, wymaga dużych zasobów i może prowadzić do awarii instancji bazy danych.
Kopia zapasowa plików poprawia sytuację, ale w dużych bazach działa wolno, ponieważ operuje w trybie jednowątkowym. Ponadto dostawcy wprowadzają szereg dodatkowych ograniczeń. Czasami nie można jednocześnie używać kopii zapasowej plików i dumpu, innym razem brak jest wsparcia dla deduplikacji. Pojawia się wiele problemów, a często łatwiej jest zamiast Postgresa wybrać droższą, ale sprawdzoną bazę danych.
Nie ma odwrotu! Za nami Moskwa, programiści!
Jednak niedawno nasza drużyna stanęła przed trudnym wyzwaniem: w projekcie tworzenia Aplikacji Informatycznej dla OSAGO 2.0, w którym budowaliśmy infrastrukturę IT, programiści dla nowego systemu wybrali PostgreSQL.
Dużym deweloperom oprogramowania znacznie łatwiej jest korzystać z „modnych” rozwiązań open-source. W zespole Facebooka wystarczająco wielu specjalistów wspiera działanie tej bazy danych. W przypadku RSА wszystkie zadania „drugiego dnia” spadały na nasze barki. Musieliśmy zapewnić odporność na awarie, zbudować klaster i oczywiście zorganizować tworzenie kopii zapasowych. Logika działań była następująca:
- Nauczyć SRK wykonywać kopię zapasową z głównego węzła klastra. W tym celu SRK musi go zlokalizować — oznacza to, że potrzebna jest integracja z odpowiednim rozwiązaniem do zarządzania klastrem PostgreSQL. W przypadku RSC użyto oprogramowania Patroni.
- Określić typ kopii zapasowej, w zależności od objętości danych i wymagań dotyczących przywracania. Na przykład, gdy konieczne jest przywracanie stron granularnie, należy użyć zrzutu, a jeśli bazy są duże i granularne przywracanie nie jest potrzebne — pracować na poziomie plików.
- Dodać do rozwiązania możliwość blokowej kopii zapasowej, aby tworzyć kopię zapasową w trybie wielowątkowym.
Jednocześnie na samym początku postawiliśmy sobie za cel stworzenie efektywnego i prostego systemu bez monsterowych związków dodatkowych komponentów. Im mniej podpórek, tym mniejsze obciążenie dla personelu i mniejsze ryzyko awarii SRK. Podejścia, w których wykorzystywano Veeam i RMAN, od razu wyeliminowaliśmy, ponieważ zestaw dwóch rozwiązań już sugeruje niepewność systemu.
Trochę magii dla przedsiębiorstw
Zatem musieliśmy zapewnić niezawodne tworzenie kopii zapasowych dla 10 klastrów po 3 węzły każdy, przy czym w zapasowym centrum danych znajduje się taka sama infrastruktura. Centrum danych w kontekście PostgreSQL działa zgodnie z zasadą active-passive. Całkowita objętość baz danych wynosiła 50 TB. Z tym łatwo sobie poradzi każdy system SRK klasy korporacyjnej. Ale problem polegał na tym, że pierwotnie w Postgres nie ma nawet zaczepu do pełnej i głębokiej kompatybilności z systemami tworzenia kopii zapasowych. Dlatego musieliśmy szukać rozwiązania, które od samego początku ma maksymalną funkcjonalność w połączeniu z PostgreSQL i dopracować system.
Przeprowadziliśmy 3 wewnętrzne „hackathony” — przestudiowaliśmy ponad pięćdziesiąt opracowań, testowaliśmy je, wprowadzaliśmy zmiany w związku z naszymi hipotezami, a następnie ponownie testowaliśmy. Analizując dostępne opcje, wybraliśmy Commvault. Ten produkt już „z pudełka” mógł współpracować z najprostszą klastrową instalacją PostgreSQL, a jego otwarta architektura budziła nadzieję (która się spełniła) na udane dopracowanie i integrację. Commvault potrafi również wykonywać kopie zapasowe dzienników PostgreSQL. Na przykład, Veritas NetBackup w kontekście PostgreSQL potrafi robić tylko pełne kopie zapasowe.
Więcej o architekturze. Serwery zarządzające Commvault zostały zainstalowane w każdym z dwóch centrów danych w konfiguracji CommServ HA. System jest lustrzany, zarządzany przez jedną konsolę i pod względem HA spełnia wszystkie wymagania przedsiębiorstwa.
W każdym centrum danych uruchomiliśmy również po dwa fizyczne serwery mediów, do których przez SAN za pomocą Fibre Channel podłączono specjalnie przystosowane macierze dyskowe i biblioteki taśmowe do backupów. Rozciągnięte bazy deduplikacji zapewniły odporność na awarie dla serwerów mediów, a połączenie każdego serwera z każdym CSV umożliwia ciągłą pracę w przypadku awarii którejkolwiek z komponentów. Architektura systemu pozwala na kontynuowanie backupu, nawet jeśli jedno z centrów danych ulegnie awarii.
Patroni określa Primary-nodę dla każdego klastra. Może to być dowolna wolna nod w centrum danych — ale tylko w głównym. W zapasowym wszystkie nod są Secondary.
Aby Commvault rozumiał, która nod klastra jest Primary, zintegrowaliśmy system (dzięki otwartej architekturze rozwiązania) z Postgres. Stworzono do tego skrypt, który informuje o bieżącej lokalizacji Primary-nody zarządzającego. serwera Commvault.
Ogólnie rzecz biorąc, proces wygląda tak:
Patroni wybiera Primary → Keepalived uruchamia IP klastra i uruchamia skrypt → agent Commvault na wybranej nodzie klastra otrzymuje powiadomienie, że to Primary → Commvault automatycznie rekonfiguruje backup w ramach pseudoklienta.
Zaletą takiego podejścia jest to, że rozwiązanie nie wpływa ani na spójność, ani na poprawność logów, ani na przywracanie instancji Postgres. Jest również łatwe do skalowania, ponieważ nie ma już potrzeby ustalania dla Commvault, które nod są Primary, a które Secondary. Wystarczy, że system rozumie, gdzie jest Primary, a liczba węzłów może być zwiększona praktycznie do dowolnej wartości.
Rozwiązanie nie aspiruje do doskonałości i ma swoje niuanse. Commvault potrafi robić backup tylko całej instancji, a nie pojedynczych baz. Dlatego dla każdej bazy danych utworzono oddzielną instancję. Rzeczywiści klienci są połączeni w wirtualne pseudoklienty. Każdy pseudoklient Commvault reprezentuje klaster UNIX. Dodaje się do niego te nod-y klastra, na których zainstalowano agenta Commvault dla Postgres. W rezultacie wszystkie wirtualne nod-y pseudoklienta są backupowane jako jedna instancja.
Wewnątrz każdego pseudo-klienta znajduje się aktywna noda klastra. To właśnie ją określa nasze rozwiązanie integracyjne dla Commvault. Zasada jego działania jest dość prosta: jeśli na nodzie uruchamia się klastrowy IP, skrypt ustawia w binarnej wersji agenta Commvault parametr "aktywny węzeł" — praktycznie skrypt ustawia "1" w odpowiedniej części pamięci. Agent przesyła te dane do CommServe, a Commvault wykonuje kopię zapasową z odpowiedniego węzła. Ponadto, na poziomie skryptu sprawdzana jest poprawność konfiguracji, co pomaga uniknąć błędów podczas uruchamiania kopii zapasowej.
Przy tym dużej bazy danych są kopii zapasowych blokowo w kilku strumieniach, spełniając wymagania RPO i okna kopii zapasowej. Obciążenie systemu jest niewielkie: pełne kopie nie zdarzają się tak często, w pozostałe dni zbierane są tylko logi, zwłaszcza w okresach niskiego obciążenia.
Zresztą wprowadziliśmy osobne polityki dla kopii zapasowych archiwalnych dzienników PostgreSQL — są one przechowywane według innych zasad, kopiowane według innego harmonogramu, a dla nich nie włączana jest deduplikacja, ponieważ te dzienniki zawierają unikalne dane.
Aby zapewnić spójność całej infrastruktury IT, na każdej z nod klastra zainstalowano oddzielnych klientów plików Commvault. Wykluczają one z kopii zapasowych pliki Postgres i są przeznaczone tylko do tworzenia kopii zapasowej systemu operacyjnego oraz aplikacji. Dla tej części danych również przewidziano swoją politykę i własny czas przechowywania.
Obecnie SRK nie wpływa na produktywne usługi, ale jeśli sytuacja się zmieni, w Commvault można aktywować system ograniczeń obciążenia.
Nadaje się? Nadaje się!
Zatem uzyskaliśmy nie tylko działający, ale i w pełni zautomatyzowany backup dla klastrowej instalacji PostgreSQL, który spełnia wszystkie wymagania wyzwań przedsiębiorstw.
Parametry RPO i RTO w 1 godzinę i 2 godziny są przekroczone z zapasem, co oznacza, że system będzie je spełniał także przy znacznym wzroście objętości przechowywanych danych. Wbrew wielu wątpliwościom, PostgreSQL i środowisko przedsiębiorstw okazały się całkowicie kompatybilne. I teraz z własnego doświadczenia wiemy, że backup dla takich DBMS jest możliwy w najróżniejszych konfiguracjach.
Oczywiście, na tej drodze musieliśmy zetrzeć siedem par żelaznych butów, pokonać szereg trudności, natknąć się na kilka pułapek oraz naprawić pewną ilość błędów. Ale teraz podejście zostało już przetestowane i może być stosowane do wdrażania Open Source zamiast proprietary RDBMS w trudnych warunkach enterprise.
Czy próbowaliście pracować z PostgreSQL w środowisku korporacyjnym?
Autorzy:
Oleg Lawrenow, inżynier-projektant systemów przechowywania danych w "Infosytemy Jet"
Dmitrij Jerykin, inżynier-projektant systemów obliczeniowych w "Infosytemy Jet"
Źródło: habr.com
