Ta notatka kończy cykl dotyczący tworzenia kopii zapasowych. Omówi logiczną organizację serwera dedykowanego (lub VPS), wygodną do tworzenia kopii zapasowych, a także zaoferuje opcję szybkiego przywrócenia serwera z kopii zapasowej bez większych przestojów w przypadku awarii.
Surowe dane
Serwer dedykowany najczęściej posiada co najmniej dwa dyski twarde, które służą do zorganizowania macierzy RAID pierwszego poziomu (lustrzanego). Jest to konieczne, aby móc kontynuować pracę serwera w przypadku awarii jednego z dysków. Jeśli jest to zwykły serwer dedykowany, może istnieć oddzielny sprzętowy kontroler RAID z technologią aktywnego buforowania na dysku SSD, dzięki czemu oprócz zwykłych dysków twardych można podłączyć jeden lub więcej dysków SSD. Czasami oferowane są serwery dedykowane, w których jedynymi dyskami lokalnymi są SATADOM (małe dyski, strukturalnie pendrive podłączany do portu SATA), lub nawet zwykły mały pendrive (8-16 GB) podłączany do specjalnego portu wewnętrznego, a dane są pobierane z systemu pamięci masowej, połączone za pośrednictwem dedykowanej sieci pamięci masowej (Ethernet 10G, FC itp.), a istnieją dedykowane serwery, które są ładowane bezpośrednio z systemu pamięci masowej. Nie będę rozważał takich opcji, ponieważ w takich przypadkach zadanie tworzenia kopii zapasowej serwera płynnie przechodzi w ręce specjalisty zajmującego się obsługą systemu przechowywania danych; zwykle istnieją różne autorskie technologie tworzenia migawek, wbudowana deduplikacja i inne przyjemności administratora systemu , omówione w poprzednich częściach tego cyklu. Objętość macierzy dyskowej serwera dedykowanego może sięgać kilkudziesięciu terabajtów, w zależności od liczby i rozmiaru dysków podłączonych do serwera. W przypadku VPS wolumeny są skromniejsze: zwykle nie przekraczają 100 GB (ale jest ich też więcej), a taryfy za taki VPS mogą z łatwością być droższe niż najtańsze serwery dedykowane od tego samego hosta. VPS najczęściej ma jeden dysk, ponieważ pod nim będzie znajdował się system przechowywania danych (lub coś hiperkonwergentnego). Czasami VPS ma kilka dysków o różnych właściwościach i różnych celach:
- mały system - do instalacji systemu operacyjnego;
- duży - przechowujący dane użytkownika.
Podczas ponownej instalacji systemu za pomocą panelu sterowania dysk z danymi użytkownika nie zostanie nadpisany, ale dysk systemowy zostanie całkowicie zapełniony. Ponadto w przypadku VPS host może zaoferować przycisk, który wykonuje migawkę stanu VPS (lub dysku), ale jeśli zainstalujesz własny system operacyjny lub zapomnisz aktywować żądaną usługę w VPS, niektóre danych może w dalszym ciągu zostać utracony. Oprócz przycisku zazwyczaj oferowana jest usługa przechowywania danych, najczęściej bardzo ograniczona. Zwykle jest to konto z dostępem przez FTP lub SFTP, czasami wraz z SSH, z uproszczoną powłoką (na przykład rbash) lub ograniczeniem uruchamiania poleceń poprzez autoryzowane_klucze (poprzez ForcedCommand).
Serwer dedykowany jest podłączony do sieci za pomocą dwóch portów o szybkości 1 Gb/s, czasami mogą to być karty o prędkości 10 Gb/s. VPS najczęściej posiada jeden interfejs sieciowy. Najczęściej centra danych nie ograniczają prędkości sieci w obrębie centrum danych, ale ograniczają prędkość dostępu do Internetu.
Typowym obciążeniem takiego serwera dedykowanego lub VPS jest serwer WWW, baza danych i serwer aplikacji. Czasami mogą być instalowane różne dodatkowe usługi pomocnicze, m.in. dla serwera WWW lub bazy danych: wyszukiwarka, system pocztowy itp.
Miejscem przechowywania kopii zapasowych jest specjalnie przygotowany serwer, o czym napiszemy szerzej w dalszej części.
Logiczna organizacja systemu dyskowego
Jeśli posiadasz kontroler RAID lub VPS z jednym dyskiem i nie ma specjalnych preferencji dotyczących działania podsystemu dyskowego (np. oddzielny szybki dysk na bazę danych), cała wolna przestrzeń jest dzielona w następujący sposób: jedna partycja jest tworzony, a na nim tworzona jest grupa woluminów LVM, tworzy się w nim kilka woluminów: 2 małe o tej samej wielkości, używane jako główny system plików (zmieniane jeden po drugim podczas aktualizacji w celu możliwości szybkiego wycofania, pomysł został zaczerpnięty z dystrybucji Calculate Linux), kolejna jest przeznaczona na partycję wymiany, reszta wolnego miejsca jest podzielona na małe woluminy, używane jako główny system plików dla pełnoprawnych kontenerów, dysków dla maszyn wirtualnych, plików systemy dla kont w /home (każde konto ma swój własny system plików), systemy plików dla kontenerów aplikacji.
Ważna uwaga: woluminy muszą być całkowicie samodzielne, tj. nie powinny zależeć od siebie nawzajem ani od głównego systemu plików. W przypadku maszyn wirtualnych lub kontenerów ten punkt jest uwzględniany automatycznie. Jeśli są to kontenery aplikacji lub katalogi domowe, warto pomyśleć o oddzieleniu plików konfiguracyjnych serwera WWW od pozostałych usług w taki sposób, aby w jak największym stopniu wyeliminować zależności pomiędzy woluminami. Na przykład każda witryna działa z poziomu własnego użytkownika, pliki konfiguracyjne witryny znajdują się w katalogu domowym użytkownika, w ustawieniach serwera WWW, pliki konfiguracyjne witryny nie są uwzględniane w pliku /etc/nginx/conf.d/.conf i na przykład /home//configs/nginx/*.conf
Jeśli dysków jest kilka, możesz utworzyć programową macierz RAID (i skonfigurować jej buforowanie na dysku SSD, jeśli jest taka potrzeba i możliwość), na której możesz zbudować LVM zgodnie z zasadami zaproponowanymi powyżej. Również w tym przypadku możesz użyć ZFS lub BtrFS, ale powinieneś pomyśleć o tym dwa razy: oba wymagają znacznie poważniejszego podejścia do zasobów, a poza tym ZFS nie jest dołączony do jądra Linuksa.
Niezależnie od zastosowanego schematu zawsze warto z wyprzedzeniem oszacować przybliżoną prędkość zapisu zmian na dyskach, a następnie obliczyć ilość wolnego miejsca, które zostanie zarezerwowane na tworzenie migawek. Na przykład, jeśli nasz serwer zapisuje dane z prędkością 10 megabajtów na sekundę, a rozmiar całej tablicy danych wynosi 10 terabajtów, czas synchronizacji może osiągnąć jeden dzień (22 godziny - tyle taki wolumin zostanie przesłany przez sieć 1 Gbps) – warto zarezerwować około 800 GB. W rzeczywistości liczba będzie mniejsza, można ją bezpiecznie podzielić przez liczbę woluminów logicznych.
Urządzenie serwera magazynu kopii zapasowych
Główną różnicą pomiędzy serwerem do przechowywania kopii zapasowych są duże, tanie i stosunkowo wolne dyski. Ponieważ współczesne dyski HDD przekroczyły już granicę 10 TB na jednym dysku, konieczne jest zastosowanie systemów plików lub RAID z sumami kontrolnymi, ponieważ podczas przebudowy macierzy lub przywracania systemu plików (kilka dni!) drugi dysk może ulec awarii z powodu do zwiększonego obciążenia. Na dyskach o pojemności do 1 TB nie było to tak czułe. Dla uproszczenia opisu zakładam, że przestrzeń dyskową podzielę na dwie części o mniej więcej równej wielkości (znowu na przykład za pomocą LVM):
- woluminy odpowiadające serwerom, na których przechowywane są dane użytkowników (ostatnia wykonana kopia zapasowa zostanie na nich wdrożona w celu weryfikacji);
- woluminy używane jako repozytoria BorgBackup (dane do kopii zapasowych będą trafiać bezpośrednio tutaj).
Zasada działania jest taka, że dla każdego serwera tworzone są osobne woluminy na repozytoria BorgBackup, do których trafią dane z serwerów bojowych. Repozytoria działają w trybie tylko dołączania, co eliminuje możliwość celowego usunięcia danych, a dzięki deduplikacji i okresowemu czyszczeniu repozytoriów ze starych kopii zapasowych (pozostają kopie roczne, miesięczne przez ostatni rok, cotygodniowe przez ostatni miesiąc, codzienne przez ostatni miesiąc w zeszłym tygodniu, ewentualnie w szczególnych przypadkach - co godzinę na ostatni dzień: łącznie 24 + 7 + 4 + 12 + roczne - około 50 kopii na każdy serwer).
Repozytoria BorgBackup nie umożliwiają trybu tylko do dołączania; zamiast tego używana jest komenda ForcedCommand w .ssh/authorized_keys, mniej więcej tak:
from="адрес сервера",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.......Podana ścieżka zawiera skrypt wrapper na górze Borga, który oprócz uruchomienia pliku binarnego z parametrami dodatkowo rozpoczyna proces przywracania kopii zapasowej po usunięciu danych. Aby to zrobić, skrypt opakowania tworzy plik znacznika obok odpowiedniego repozytorium. Ostatnia wykonana kopia zapasowa jest automatycznie przywracana na odpowiedni wolumin logiczny po zakończeniu procesu uzupełniania danych.
Taka konstrukcja umożliwia okresowe czyszczenie niepotrzebnych kopii zapasowych, a także zapobiega usuwaniu przez serwery bojowe czegokolwiek z serwera magazynu kopii zapasowych.
Proces tworzenia kopii zapasowej
Inicjatorem tworzenia kopii zapasowej jest serwer dedykowany lub sam VPS, gdyż taki schemat daje większą kontrolę nad procesem tworzenia kopii zapasowej po stronie tego serwera. Najpierw wykonywana jest migawka stanu aktywnego głównego systemu plików, która jest montowana i przesyłana za pomocą BorgBackup na serwer magazynu kopii zapasowych. Po zakończeniu przechwytywania danych migawka jest odłączana i usuwana.
W przypadku małej bazy danych (do 1 GB dla każdego serwisu) wykonywany jest zrzut bazy danych, który zapisywany jest na odpowiednim wolumenie logicznym, w którym znajduje się reszta danych dla tego samego serwisu, jednak tak, aby zrzut był niedostępne przez serwer WWW. Jeśli bazy danych są duże, należy skonfigurować usuwanie danych „na gorąco”, na przykład za pomocą xtrabackup dla MySQL lub pracować z WAL za pomocą polecenia Archive_command w PostgreSQL. W takim przypadku baza danych zostanie przywrócona niezależnie od danych witryny.
Jeśli używane są kontenery lub maszyny wirtualne, należy skonfigurować qemu-guest-agent, CRIU lub inne niezbędne technologie. W innych przypadkach dodatkowe ustawienia najczęściej nie są potrzebne – po prostu tworzymy migawki woluminów logicznych, które następnie przetwarzamy w taki sam sposób, jak migawkę stanu głównego systemu plików. Po pobraniu danych zdjęcia są usuwane.
Dalsze prace prowadzone są na serwerze przechowywania kopii zapasowych:
- sprawdzana jest ostatnia kopia zapasowa wykonana w każdym repozytorium,
- sprawdzana jest obecność pliku znaku, wskazującego zakończenie procesu zbierania danych,
- dane są rozszerzane do odpowiedniego wolumenu lokalnego,
- plik znacznika zostanie usunięty
Proces odzyskiwania serwera
Jeśli główny serwer umrze, uruchamiany jest podobny serwer dedykowany, który uruchamia się z jakiegoś standardowego obrazu. Najprawdopodobniej pobieranie odbędzie się przez sieć, jednak technik centrum danych konfigurujący serwer może od razu skopiować ten standardowy obraz na jeden z dysków. Pobieranie następuje do pamięci RAM, po czym rozpoczyna się proces odzyskiwania:
- pojawia się żądanie podłączenia urządzenia blokowego poprzez iscsinbd lub inny podobny protokół do woluminu logicznego zawierającego główny system plików zmarłego serwera; Ponieważ główny system plików musi być mały, ten krok powinien zająć kilka minut. Bootloader również zostaje przywrócony;
- odtwarzana jest struktura lokalnych woluminów logicznych, dołączane są woluminy logiczne z serwera kopii zapasowych za pomocą modułu jądra dm_clone: rozpoczyna się odzyskiwanie danych, a zmiany są natychmiast zapisywane na dyskach lokalnych
- uruchamiany jest kontener ze wszystkimi dostępnymi dyskami fizycznymi - funkcjonalność serwera zostaje w pełni przywrócona, ale ze zmniejszoną wydajnością;
- po zakończeniu synchronizacji danych następuje odłączenie woluminów logicznych od serwera kopii zapasowych, wyłączenie kontenera i ponowne uruchomienie serwera;
Po ponownym uruchomieniu na serwerze będą znajdować się wszystkie dane, które znajdowały się w momencie tworzenia kopii zapasowej, a także wszystkie zmiany wprowadzone podczas procesu przywracania.
Inne artykuły z serii
Część zapasowa 7: Wnioski
Zapraszam do dyskusji na temat proponowanej opcji w komentarzach, dziękuję za uwagę!
Źródło: www.habr.com