Tento článek ukončuje cyklus o zálohování. Bude se zabývat logickou organizací dedikovaného serveru (nebo VPS), která je pohodlná pro zálohování, a také nabídne možnost rychlé obnovy serveru ze zálohy bez zvláštních prostojů v případě havárie.
Vstupní data
Dedikovaný server obvykle má minimálně dva pevné disky, které slouží k organizaci RAID pole prvního levelu (zrcadlení). To je nezbytné pro možnosti pokračování v práci serveru, pokud jeden disk selže. Pokud se jedná o běžný dedikovaný server, může mít samostatný hardwarový RAID kontrolér, s aktivní technologií cachování na SSD, takže kromě běžných pevných disků může být připojen jeden nebo více SSD. Někdy se nabízejí dedikované servery, ve kterých jsou z místních disků přítomny pouze SATADOM (malé disky, konstrukčně — flash paměť, připojená do portu SATA), nebo dokonce obyčejné malé (8-16 GB) flash paměti, připojené do speciálního interního portu, a data jsou brána ze SCSI, připojené prostřednictvím dedikované sítě pro ukládání dat (Ethernet 10G, FC atd.), a jsou také dedikované servery, které se bootují přímo ze SCSI. Tyto varianty však nebudu zvažovat, neboť v takových případech úkol zálohování serveru plynule přechází na specialistu, který spravuje SCSI, obvykle tam existují různé proprietární technologie pro vytvoření snímků stavu, vestavěná deduplikace a další radosti sysadmina, zmiňované v předchozích částech tohoto cyklu. Velikost diskového pole dedikovaného serveru může dosahovat několika desítek terabajtů, v závislosti na počtu a objemu disků připojených k serveru. V případě VPS jsou objemy skromnější: obvykle ne více než 100 GB (ale mohou být i větší), a ceny za takové VPS mohou být snadno vyšší než u nejlevnějších dedikovaných serverů od stejného poskytovatele. U VPS je často pouze jeden disk, protože pod ním bude SCSI (nebo něco hyperkonvergovaného). Někdy má VPS více disků s různými vlastnostmi, pro různé účely:
- malý systémový — pro instalaci operačního systému;
- velký — pro ukládání uživatelských dat.
Při reinstalaci systému pomocí ovládacího panelu se disk s uživatelskými daty nezapíše, zatímco systémový se kompletně přepisuje. V případě VPS může poskytovatel hostingu nabízet tlačítko, které provede snapshot stavu VPS (nebo disku), avšak v případě instalace vlastního operačního systému nebo zapomenutí aktivovat potřebnou službu uvnitř VPS může být část dat stále ztracena. K tlačítku se obvykle nabízí služba pro ukládání dat, která je často silně omezená. Obvykle se jedná o účet s přístupem přes protokol FTP nebo SFTP, někdy spolu se SSH, s omezeným shellem (například rbash) nebo omezením na spouštění příkazů přes authorized_keys (přes ForcedCommand).
Dedikovaný server je připojen k síti dvěma porty o rychlosti 1 Gbit/s, někdy mohou být použity karty o rychlosti 10 Gbit/s. U VPS je síťový interface většinou jeden. Datacentra obvykle neomezují rychlost sítě uvnitř svého areálu, ale omezují rychlost přístupu na internet.
Typické zatížení takového dedikovaného serveru nebo VPS tvoří webový server, databáze a aplikační server. Někdy mohou být nainstalovány různé další pomocné služby, včetně pro webový server nebo databázi: vyhledávač, poštovní systém atd.
Jako prostor pro uchovávání záloh slouží speciálně připravený server, o němž bude podrobněji napsáno dále.
Logická organizace diskového systému
Pokud existuje RAID řadič, nebo se jedná o VPS s jedním diskem, a také nejsou žádné zvláštní preference ohledně fungování diskového subsystému (například samostatný rychlý disk pro databázi) — celé volné místo se rozdělí následovně: vytvoří se jedna partition, na kterou se vytvoří skupina svazků LVM, v níž se vytvoří několik svazků: 2 malé stejné velikosti, používané jako kořenový souborový systém (střídají se při aktualizacích pro možnost rychlého návratu zpět, tato myšlenka byla převzata z distribuce Calculate Linux), další — pro swap partition, zbývající volné místo se rozdělí na malé svazky, které se používají jako kořenové souborové systémy pro plnohodnotné kontejnery, disky pro virtuální stroje, souborové systémy pro účty v /home (každý účet má svůj vlastní souborový systém), souborové systémy pro aplikační kontejnery.
Důležité poznámka: svazky by měly být zcela soběstačné, tj. neměly by záviset ani jedna na druhé, ani na kořenovém souborovém systému. V případě virtuálních strojů nebo kontejnerů je tento aspekt automaticky dodržován. Pokud se však jedná o aplikační kontejnery nebo domácí adresáře — je dobré zamyslet se nad oddělením konfiguračních souborů webového serveru a dalších služeb tak, aby se maximalizovaly závislosti svazků mezi sebou. Například každý web pracuje pod svým uživatelským účtem, konfigurační soubory webu — v domácím adresáři uživatele, v nastavení webového serveru se konfigurační soubory webů zahrnují nezávisle na /etc/nginx/conf.d/.conf, ale například /home//configs/nginx/*.conf
Pokud je discích více — lze vytvořit softwarový RAID (a nastavit jeho cachování na SSD, pokud je potřeba a možnosti to dovolují), na který se poté postaví LVM podle pravidel uvedených výše. V tomto případě je možné také použít ZFS nebo BtrFS, ale zde je třeba několikrát přemýšlet: obě vyžadují mnohem vážnější přístup k prostředkům, navíc ZFS není součástí jádra Linuxu.
Bez ohledu na použitou schéma je vždy dobré odhadnout přibližnou rychlost zápisu změn na disky, a poté spočítat velikost volného místa, které bude rezervováno pro vytváření snímků. Například, pokud náš server zapisuje data rychlostí 10 megabajtů za sekundu a celková velikost datového pole činí 10 terabajtů - doba synchronizace může dosáhnout až jednoho dne (22 hodin - to je čas potřebný k přenosu tohoto objemu po síti 1 Gbit/s) - je dobré rezervovat přibližně 800 GB. Ve skutečnosti bude číslo menší, lze jej bez obav dělit počtem logických svazků.
Zařízení pro server pro ukládání záloh
Hlavní rozdíl mezi serverem pro ukládání záloh se týká velkých, levných a relativně pomalých disků. Jelikož moderní HDD již překročily hranici 10 TB na jednom disku - je nezbytné použít souborové systémy nebo RAID s kontrolními součty, protože během rekonstrukce pole nebo obnovy souborového systému (což může trvat několik dní!) může druhý disk selhat kvůli zvýšené zátěži. Na discích s kapacitou do 1 TB to nebylo tak citelné. Pro zjednodušení popisu předpokládám, že diskový prostor je rozdělen na dvě zhruba stejné části (opět příkladem pomocí LVM):
- svazky odpovídající serverům, které se používají pro ukládání uživatelských dat (na nich bude nasazena poslední vytvořená záloha pro kontrolu);
- svazky používané jako úložiště pro BorgBackup (sem budou přímo putovat data pro zálohy).
Princip fungování spočívá v tom, že se vytvářejí samostatné svazky pro každý server pod úložišti BorgBackup, kam budou putovat data z výrobních serverů. Úložiště pracují v režimu pouze pro přidávání, což vylučuje možnost záměrného odstranění dat, a díky deduplikaci a pravidelnému čištění úložišť od starých záloh (zůstávají roční kopie, měsíční za poslední rok, týdenní za poslední měsíc, každodenní za poslední týden, možná - ve zvláštních případech - každou hodinu za poslední den: celkem 24 + 7 + 4 + 12 + roční - přibližně 50 kopií pro každý server).
V repozitářích BorgBackup není aktivován režim pouze pro přidání; místo toho se v .ssh/authorized_keys používá ForcedCommand přibližně v tomto plánu:
from="adresa serveru",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.......Na uvedené cestě je umístěn obalový skript pro borg, který kromě spuštění binárky s parametry také spouští proces obnovy zálohy po dokončení ukládání dat. K tomu obalový skript vytváří soubor-indikátor vedle příslušného repozitáře. Poslední provedená záloha se po dokončení procesu nahrávání dat automaticky obnoví na příslušný logický svazek.
Tato konstrukce umožňuje pravidelně čistit nepotřebné zálohy a také zabraňuje provozním serverům mazat cokoli na serveru pro ukládání záloh.
Proces zálohování
Iniciátorem zálohování je samotný dedicovaný server nebo VPS, protože takový systém poskytuje větší kontrolu nad procesem zálohování z pohledu tohoto serveru. Nejprve se vytvoří snímek stavu aktivního kořenového souborového systému, který se namontuje a nahraje pomocí BorgBackup na server pro ukládání záloh. Po dokončení ukládání dat se snímek demontuje a odstraní.
V případě malé databáze (do 1 GB pro každý web) se provede dump databáze, který se uloží do příslušného logického svazku, kde jsou umístěna ostatní data tohoto webu, ale tak, aby dump nebyl přístupný přes webový server. Pokud jsou databáze velké, je třeba nastavit „horké“ ukládání dat, například pomocí xtrabackup pro MySQL, nebo práci WAL s archive_command v PostgreSQL. V tomto případě bude databáze obnovena odděleně od dat webů.
Pokud se používají kontejnery nebo virtuální stroje, je třeba nastavit qemu-guest-agent, CRIU nebo jiné potřebné technologie. V ostatních případech obvykle nejsou potřebná další nastavení — jednoduše vytvoříme snímky logických svazků, které pak budou zpracovány analogicky jako snímek stavu kořenového souborového systému. Po ukládání dat jsou snímky odstraněny.
Další práce probíhá na serveru pro ukládání záloh:
- ověřuje se poslední aktuální záloha v každém úložišti,
- ověřuje se přítomnost značkovacího souboru, který naznačuje, že proces ukládání dat byl dokončen,
- probíhá nasazení dat na odpovídající místní svazek,
- mazání značkovacího souboru,
Proces obnovení funkčnosti serveru,
Pokud hlavní server selže, spustí se podobný dedikovaný server, který se načte z určitého standardního obrazu. Je pravděpodobné, že načítání proběhne přes síť, avšak technik datového centra, který provádí konfiguraci serveru, může tento standardní obraz okamžitě zkopírovat na jeden z disků. Načítání probíhá do operační paměti, poté se zahajuje proces obnovení:
- provádí se žádost o připojení blokového zařízení prostřednictvím iscsinbd nebo jiného podobného protokolu logického svazku, který obsahuje kořenový souborový systém zemřelého serveru; protože kořenový souborový systém by měl být malý — tato fáze by měla být dokončena během několika minut. Také probíhá obnova bootloaderu;
- obnovuje se struktura místních logických svazků, připojují se logické svazky ze serveru zálohování pomocí jádrového modulu dm_clone: začíná obnova dat a změny jsou zapisovány okamžitě na místní disky,
- spouští se kontejner se všemi dostupnými fyzickými disky — plně se obnovuje funkčnost serveru, ale s nižším výkonem;
- po dokončení synchronizace dat se logické svazky ze serveru zálohování odpojí, kontejner se vypne, server se restartuje;
Po restartu bude server obsahovat všechna data, která byla k dispozici v okamžiku vytvoření zálohy, a také všechny změny, které byly provedeny během obnovy.
Další články cyklu
Zálohování, část 7: Závěry
Zveme vás k diskusi o navržené variantě v komentářích, děkuji za pozornost!
Zdroj: habr.com
