Niniejsza notatka kończy cykl na temat tworzenia kopii zapasowych. Będzie mowa o logicznej organizacji serwera dedykowanego (lub VPS), ułatwiającej tworzenie kopii zapasowych, a także zostanie zaproponowane rozwiązanie szybkiego przywracania serwera z kopii zapasowej bez znacznych przestojów w przypadku awarii.
Dane źródłowe
Serwer dedykowany najczęściej ma co najmniej dwa dyski twarde, które służą do organizacji macierzy RAID pierwszego poziomu (lustro). Jest to potrzebne, aby kontynuować pracę serwera, jeśli jeden dysk ulegnie awarii. Jeśli jest to zwykły serwer dedykowany — może mieć oddzielny kontroler RAID, z aktywną technologią pamięci podręcznej na SSD, dzięki czemu do zwykłych dysków twardych może być podłączony jeden lub więcej dysków SSD. Czasami oferowane są serwery dedykowane, w których z lokalnych dysków obecne są tylko SATADOM (małe dyski, konstrukcyjnie — pendrive, podłączany do portu SATA), a nawet zwykły mały (8–16 GB) pendrive, podłączany do specjalnego wewnętrznego portu, a dane pobierane są z macierzy dyskowej, podłączonej przez dedykowaną sieć przechowywania danych (Ethernet 10G, FC itd.). Są także serwery dedykowane, które uruchamiają się bezpośrednio z macierzy dyskowej. Takie opcje nie będą omawiane, ponieważ w takich przypadkach zadanie tworzenia kopii zapasowych serwera płynnie przechodzi do specjalisty, który obsługuje macierz dyskową; zazwyczaj wykorzystuje się tam różne technologie do tworzenia migawek stanu, wbudowaną deduplikację oraz inne zalety, które rozważono w poprzednich częściach tego cyklu. Pojemność macierzy dyskowej serwera dedykowanego może sięgać kilku dziesiąt terabajtów, w zależności od liczby i pojemności dysków podłączonych do serwera. W przypadku VPS objętości są skromniejsze: zazwyczaj nie więcej niż 100 GB (choć zdarzają się większe), a stawki za takie VPS mogą być łatwo droższe od najtańszych serwerów dedykowanych tego samego hostera. VPS najczęściej ma jeden dysk, ponieważ pod nim znajduje się macierz dyskowa (lub coś hiper-zintegrowanego). Czasami VPS ma kilka dysków o różnych charakterystykach, do różnych celów:
- mały systemowy — do instalacji systemu operacyjnego;
- duży — do przechowywania danych użytkowników.
Podczas ponownej instalacji systemu przez panel zarządzania, dysk z danymi użytkowników nie jest nadpisywany, natomiast systemowy jest całkowicie przeładowywany. W przypadku VPS dostawca może oferować przycisk do zrobienia zrzutu stanu VPS (lub dysku), jednak jeśli zainstalujesz własny system operacyjny lub zapomnisz aktywować potrzebną usługę w VPS — część danych może zostać utracona. Wraz z przyciskiem zazwyczaj oferowana jest usługa przechowywania danych, najczęściej znacznie ograniczona. Zwykle jest to konto z dostępem przez protokół FTP lub SFTP, czasami wraz z SSH, z ograniczonym shellem (np. rbash) lub z ograniczeniem na uruchamianie poleceń przez authorized_keys (za pomocą ForcedCommand).
Dedykowany serwer jest podłączony do sieci za pomocą dwóch portów o prędkości 1 Gbit/s, czasami mogą to być karty o prędkości 10 Gbit/s. W przypadku VPS interfejs sieciowy występuje najczęściej jeden. Data centry zazwyczaj nie ograniczają prędkości sieci wewnątrz data centa, ale ograniczają prędkość dostępu do internetu.
Typowe obciążenie takiego dedykowanego serwera lub VPS to serwer WWW, baza danych, serwer aplikacji. Czasami mogą być zainstalowane różne dodatkowe usługi pomocnicze, w tym dla serwera WWW lub bazy danych: wyszukiwarka, system pocztowy itp.
Jako miejsce do przechowywania kopii zapasowych służy specjalnie przygotowany serwer, o którym będzie więcej napisane później.
Logiczna organizacja systemu plików
Jeśli istnieje kontroler RAID lub jest to VPS z jednym dyskiem, a także nie ma szczególnych preferencji dotyczących działania systemu dyskowego (na przykład oddzielny szybki dysk dla bazy danych) — cała dostępna przestrzeń jest dzielona w ten sposób: tworzy się jedną partycję, na której tworzona jest grupa woluminów LVM, w której powstaje kilka woluminów: 2 małe oidentycznej wielkości, używane jako system plików root (wymieniane naprzemiennie podczas aktualizacji w celu umożliwienia szybkiego wycofania, pomysł zapożyczony z dystrybucji Calculate Linux), jeden — na partycję swap, reszta dostępnej przestrzeni jest dzielona na małe woluminy, używane jako systemy plików root dla pełnoprawnych kontenerów, dysków dla maszyn wirtualnych, systemów plików dla kont w /home (każde konto ma swój system plików), systemów plików dla aplikacyjnych kontenerów.
Ważna uwaga: woluminy muszą być całkowicie samowystarczalne, t.j. nie powinny być zależne ani od siebie nawzajem, ani od systemu plików root. W przypadku maszyn wirtualnych lub kontenerów ten aspekt jest przestrzegany automatycznie. Jeśli jednak są to kontenery aplikacji lub katalogi domowe — warto pomyśleć o oddzieleniu plików konfiguracyjnych serwera www i innych usług w taki sposób, aby maksymalnie zredukować zależności między woluminami. Na przykład, każda strona działa od swojego użytkownika, pliki konfiguracyjne strony znajdują się w katalogu domowym użytkownika, w ustawieniach serwera www pliki konfiguracyjne stron są ładowane nie przez /etc/nginx/conf.d/.conf, a na przykład przez /home//configs/nginx/*.conf
Jeśli jednak istnieje kilka dysków — można utworzyć programową macierz RAID (i skonfigurować jej pamięć podręczną na SSD, jeśli istnieje potrzeba i możliwości), na której można zbudować LVM zgodnie z zasadami zaproponowanymi powyżej. Również w tym przypadku można używać ZFS lub BtrFS, ale tutaj warto kilka razy przemyśleć: obie wymagają znacznie poważniejszego podejścia do zasobów, ponadto ZFS nie jest dołączany do jądra Linux.
Niezależnie od stosowanej strategii, warto wcześniej oszacować przybliżoną prędkość zapisu zmian na dyski, a następnie obliczyć rozmiar wolnego miejsca, które zostanie zarezerwowane na utworzenie migawek. Na przykład, jeśli nasz serwer będzie zapisywał dane z prędkością 10 megabajtów na sekundę, a całkowity rozmiar zbioru danych wynosi 10 terabajtów — czas synchronizacji może wynosić doby (22 godziny — tyle czasu zajmie przesłanie takiej ilości przez sieć 1gbit/s) — warto zarezerwować około 800 GB. W rzeczywistości liczba ta będzie mniejsza, można ją śmiało podzielić przez liczbę logicznych woluminów.
Serwer do przechowywania kopii zapasowych
Główna różnica między serwerem do przechowywania kopii zapasowych a zwykłym serwerem to duże, tanie i stosunkowo wolne dyski. Ponieważ nowoczesne HDD przekroczyły już granicę 10 TB na jednym dysku — niezbędne jest stosowanie systemów plików lub RAID z sumami kontrolnymi, ponieważ w czasie reorganizacji zbioru lub przywracania systemu plików (kilka dni!) drugi dysk może ulec awarii z powodu zwiększonego obciążenia. Na dyskach o pojemności do 1 TB było to mniej odczuwalne. Dla uproszczenia opisu zakładam, że przestrzeń dyskowa jest podzielona na dwie mniej więcej równej wielkości części (np. przy użyciu LVM):
- wolumeny, odpowiadające serwerom, które są wykorzystywane do przechowywania danych użytkowników (na nich zostanie odtworzona ostatnia wykonana kopia zapasowa do weryfikacji);
- wolumeny, które są wykorzystywane jako repozytoria BorgBackup (tutaj będą trafiały dane do kopii zapasowych).
Zasada działania polega na tym, że tworzone są oddzielne wolumeny dla każdego serwera jako repozytoria BorgBackup, do których będą trafiały dane z serwerów produkcyjnych. Repozytoria działają w trybie tylko dodawania, co wyklucza możliwość zamierzonego usunięcia danych, a dzięki deduplikacji i okresowemu czyszczeniu repozytoriów ze starych kopii zapasowych (pozostają kopie roczne, miesięczne za ostatni rok, tygodniowe za ostatni miesiąc, codzienne za ostatni tydzień, może — w szczególnych przypadkach — co godzinne za ostatni dzień: w sumie 24 + 7 + 4 + 12 + roczne — około 50 kopii dla każdego serwera).
W repozytoriach BorgBackup nie jest aktywowany tryb tylko do dodawania, zamiast tego używa się ForcedCommand w .ssh/authorized_keys mniej więcej w ten sposób:
from="adres serwera",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......W podanej lokalizacji znajduje się skrypt-osłona nad borg, który, oprócz uruchamiania binarki z parametrami, dodatkowo uruchamia proces przywracania kopii zapasowej po zakończeniu zbierania danych. W tym celu skrypt-osłona tworzy plik sygnalizacyjny obok odpowiedniego repozytorium. Ostatnia wykonana kopia zapasowa po zakończeniu procesu przesyłania danych jest automatycznie przywracana na odpowiedni wolumen logiczny.
Ta konstrukcja pozwala na okresowe oczyszczanie zbędnych kopii zapasowych, a także uniemożliwia serwerom produkcyjnym usuwanie czegokolwiek na serwerze przechowywania kopii zapasowych.
Proces tworzenia kopii zapasowej
Inicjatorem tworzenia kopii zapasowej jest sam dedykowany serwer lub VPS, ponieważ taka схема daje większą kontrolę nad procesem tworzenia kopii zapasowej z tego serwera. Najpierw wykonywana jest migawka stanu aktywnego systemu plików, która jest montowana i przesyłana za pomocą BorgBackup na serwer przechowywania kopii zapasowych. Po zakończeniu zbierania danych migawka jest odmontowywana i usuwana.
W przypadku małej bazy danych (do 1 GB dla każdej witryny) wykonywana jest zrzut bazy danych, który jest zapisywany w odpowiednim wolumenie logicznym, tam, gdzie znajdują się inne dane tej samej witryny, ale tak, aby zrzut nie był dostępny przez serwer WWW. Jeśli bazy są duże — należy skonfigurować „gorące” zbieranie danych, na przykład przy użyciu xtrabackup dla MySQL, lub pracę WAL z archive_command w PostgreSQL. W tym przypadku baza danych będzie przywracana oddzielnie od danych witryn.
Jeśli stosowane są kontenery lub maszyny wirtualne — należy skonfigurować qemu-guest-agent, CRIU lub inne potrzebne technologie. W pozostałych przypadkach dodatkowe konfiguracje najczęściej nie będą potrzebne — po prostu tworzymy migawki wolumenów logicznych, które są następnie przetwarzane podobnie jak migawka stanu systemu plików. Po zakończeniu zbierania danych migawki są usuwane.
Dalsza praca odbywa się na serwerze przechowywania kopii zapasowych:
- Sprawdzana jest ostatnia wykona rezerwa w każdym repozytorium,
- Sprawdzana jest obecność pliku znacznikowego, informującego o zakończeniu procesu wyciągania danych,
- Wykonywane jest rozwinięcie danych na odpowiednią lokalną objętość,
- Usuwany jest plik znacznikowy,
Proces przywracania sprawności serwera,
Jeśli główny serwer zawiedzie, uruchamiany jest podobny dedykowany serwer, który ładowany jest z określonego standardowego obrazu. Najprawdopodobniej załadunek będzie realizowany przez sieć, jednak technik datacenter, dokonujący konfiguracji serwera, może od razu skopiować ten standardowy obraz na jeden z dysków. Ładowanie odbywa się do pamięci operacyjnej, a następnie rozpoczyna się proces przywracania:
- Wydawane jest zapytanie o przyłączenie urządzenia blokowego przez iscsinbd lub inny podobny protokół logicznego woluminu, zawierającego główny system plików padłego serwera; ponieważ główny system plików powinien być niewielki - ten etap powinien być zakończony w kilka minut. Odbywa się także przywracanie bootloadera;
- Odtwarzana jest struktura lokalnych woluminów logicznych, dołączane są woluminy logiczne z serwera rezerwowego za pomocą modułu jądra dm_clone: rozpoczyna się przywracanie danych, a zmiany są zapisywane od razu na lokalnych dyskach,
- Uruchamiany jest kontener ze wszystkimi dostępnymi fizycznymi dyskami - całkowicie przywracana jest sprawność serwera, ale z obniżoną wydajnością;
- Po zakończeniu synchronizacji danych woluminy logiczne z serwera rezerwowego są odłączane, kontener wyłączany, serwer uruchamiany ponownie;
Po ponownym uruchomieniu serwer będzie zawierał wszystkie dane, które były w momencie tworzenia kopii zapasowej, a także uwzględniał wszystkie zmiany, które miały miejsce w procesie przywracania.
Inne artykuły z cyklu
Kopie zapasowe, część 7: Wnioski
Zapraszam do dyskusji na zaproponowany temat w komentarzach, dziękuję za uwagę!
Źródło: habr.com
