Tato poznámka dokončuje cyklus zálohování. Pojednává o logické organizaci dedikovaného serveru (nebo VPS), vhodném pro zálohování, a nabídne také možnost rychlé obnovy serveru ze zálohy bez velkých prostojů v případě havárie.
Počáteční data
Dedikovaný server má nejčastěji alespoň dva pevné disky, které slouží k uspořádání pole RAID (zrcadlení) první úrovně. To je nezbytné, aby bylo možné pokračovat v provozu serveru, pokud jeden disk selže. Pokud se jedná o běžný dedikovaný server, může být na SSD samostatný hardwarový řadič RAID s technologií aktivního ukládání do mezipaměti, takže kromě běžných pevných disků lze připojit jeden nebo více SSD. Někdy jsou nabízeny dedikované servery, na kterých jsou jedinými lokálními disky SATADOM (malé disky, konstrukčně flash disk připojený k SATA portu), nebo i obyčejný malý (8-16GB) flash disk připojený na speciální interní port a data jsou sbírána z úložného systému, připojeného přes vyhrazenou úložnou síť (Ethernet 10G, FC atd.) a existují dedikované servery, které se načítají přímo z úložného systému. Nebudu zvažovat takové možnosti, protože v takových případech úloha zálohování serveru plynule přechází na specialistu, který spravuje úložný systém; obvykle existují různé proprietární technologie pro vytváření snímků, vestavěná deduplikace a další radosti správce systému , diskutované v předchozích dílech této série. Objem diskového pole dedikovaného serveru může dosahovat až několika desítek terabajtů v závislosti na počtu a velikosti disků připojených k serveru. V případě VPS jsou objemy skromnější: obvykle ne více než 100 GB (ale je jich i více) a tarify za takové VPS mohou být snadno dražší než nejlevnější dedikované servery od stejného hostitele. VPS má nejčastěji jeden disk, protože pod ním bude úložný systém (nebo něco hyperkonvergovaného). Někdy má VPS několik disků s různými vlastnostmi pro různé účely:
- malý systém - pro instalaci operačního systému;
- velký - ukládání uživatelských dat.
Při reinstalaci systému pomocí ovládacího panelu se disk s uživatelskými daty nepřepíše, ale systémový disk se zcela zaplní. Také v případě VPS může hostitel nabídnout tlačítko, které pořídí snímek stavu VPS (nebo disku), ale pokud si nainstalujete vlastní operační systém nebo zapomenete aktivovat požadovanou službu uvnitř VPS, některé dat může být stále ztraceno. Kromě tlačítka bývá nabízena služba ukládání dat, nejčastěji velmi omezená. Obvykle se jedná o účet s přístupem přes FTP nebo SFTP, někdy spolu s SSH, s odstraněným shellem (například rbash) nebo omezením spouštění příkazů přes autorizovaný_klíč (přes ForcedCommand).
Dedikovaný server je připojen k síti dvěma porty s rychlostí 1 Gbps, někdy to mohou být karty s rychlostí 10 Gbps. VPS má nejčastěji jedno síťové rozhraní. Datová centra nejčastěji neomezují rychlost sítě v rámci datového centra, ale omezují rychlost přístupu k internetu.
Typickou zátěží takového dedikovaného serveru nebo VPS je webový server, databáze a aplikační server. Někdy mohou být nainstalovány různé doplňkové pomocné služby, včetně pro webový server nebo databázi: vyhledávač, poštovní systém atd.
Jako prostor pro ukládání záložních kopií slouží speciálně připravený server, podrobněji o něm napíšeme později.
Logická organizace diskového systému
Pokud máte řadič RAID nebo VPS s jedním diskem a nemáte žádné speciální preference pro provoz diskového subsystému (například samostatný rychlý disk pro databázi), je veškerý volný prostor rozdělen následovně: jeden oddíl je vytvořena a nad ní je vytvořena skupina svazků LVM , je v ní vytvořeno několik svazků: 2 malé stejné velikosti, používané jako kořenový souborový systém (během aktualizací se mění jeden po druhém pro možnost rychlého vrácení zpět, nápad byl převzat z distribuce Calculate Linux), další je pro swapovací oddíl, zbytek volného místa je rozdělen na malé svazky, používá se jako kořenový souborový systém pro plnohodnotné kontejnery, disky pro virtuální stroje, soubor 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 musí být zcela soběstačné, tzn. by neměly záviset na sobě nebo na kořenovém systému souborů. V případě virtuálních strojů nebo kontejnerů je tento bod dodržován automaticky. Pokud se jedná o aplikační kontejnery nebo domovské adresáře, měli byste přemýšlet o oddělení konfiguračních souborů webového serveru a dalších služeb tak, abyste co nejvíce eliminovali závislosti mezi svazky. Například každý web běží od svého vlastního uživatele, konfigurační soubory webu jsou v domovském adresáři uživatele, v nastavení webového serveru nejsou konfigurační soubory webu zahrnuty přes /etc/nginx/conf.d/.conf a například /home//configs/nginx/*.conf
Pokud existuje několik disků, můžete vytvořit softwarové pole RAID (a nakonfigurovat jeho ukládání do mezipaměti na SSD, pokud existuje potřeba a příležitost), nad nímž můžete postavit LVM podle výše navržených pravidel. Také v tomto případě můžete použít ZFS nebo BtrFS, ale měli byste si to dvakrát rozmyslet: oba vyžadují mnohem serióznější přístup ke zdrojům a kromě toho ZFS není součástí linuxového jádra.
Bez ohledu na použité schéma se vždy vyplatí předem odhadnout přibližnou rychlost zápisu změn na disky a následně spočítat množství volného místa, které bude vyhrazeno pro vytváření snapshotů. Pokud například náš server zapisuje data rychlostí 10 megabajtů za sekundu a velikost celého datového pole je 10 terabajtů - doba synchronizace může dosáhnout jednoho dne (22 hodin - tolik se takový objem přenese po síti 1 Gbps) - vyplatí se rezervovat cca 800 GB . Ve skutečnosti bude údaj menší, můžete jej klidně vydělit počtem logických svazků.
Záložní úložné serverové zařízení
Hlavním rozdílem mezi serverem pro ukládání záložních kopií jsou jeho velké, levné a relativně pomalé disky. Vzhledem k tomu, že moderní HDD již překročily hranici 10TB na jednom disku, je nutné použít souborové systémy nebo RAID s kontrolními součty, protože při přestavbě pole nebo obnově souborového systému (několik dní!) může dojít k výpadku druhého disku v důsledku ke zvýšené zátěži. Na discích s kapacitou do 1TB to nebylo tak citlivé. Pro jednoduchost popisu předpokládám, že diskový prostor je rozdělen na dvě přibližně stejně velké části (opět např. pomocí LVM):
- svazky odpovídající serverům používaným k ukládání uživatelských dat (na nich bude pro ověření nasazena poslední vytvořená záloha);
- svazky používané jako úložiště BorgBackup (data pro zálohy půjdou přímo sem).
Princip fungování spočívá v tom, že pro každý server jsou vytvořeny samostatné svazky pro úložiště BorgBackup, kam půjdou data z bojových serverů. Úložiště fungují v režimu pouze připojování, což eliminuje možnost záměrného mazání dat, a díky deduplikaci a pravidelnému čištění úložišť ze starých záloh (zbývají roční kopie, měsíčně za poslední rok, týdenní za poslední měsíc, denně za minulý týden, možná ve zvláštních případech - hodinová za poslední den: celkem 24 + 7 + 4 + 12 + ročně - přibližně 50 kopií na každý server).
Úložiště BorgBackup nepovolují režim pouze připojení; místo toho se používá ForcedCommand v .ssh/authorized_keys něco takového:
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.......Zadaná cesta obsahuje nad borg skript wrapper, který kromě spuštění binárky s parametry navíc spustí proces obnovy záložní kopie po odstranění dat. Za tímto účelem skript obalu vytvoří soubor značky vedle odpovídajícího úložiště. Po dokončení procesu plnění dat se poslední vytvořená záloha automaticky obnoví na odpovídající logický svazek.
Tento design vám umožňuje pravidelně čistit nepotřebné zálohy a také zabraňuje bojovým serverům smazat cokoli na serveru úložiště záloh.
Proces zálohování
Iniciátorem zálohování je samotný dedikovaný server nebo VPS, protože toto schéma poskytuje větší kontrolu nad procesem zálohování na straně tohoto serveru. Nejprve se pořídí snímek stavu aktivního kořenového souborového systému, který se připojí a nahraje pomocí BorgBackup na server úložiště záloh. Po dokončení zachycení dat se snímek odpojí a odstraní.
Pokud existuje malá databáze (až 1 GB pro každý web), vytvoří se výpis databáze, který se uloží do příslušného logického svazku, kde je umístěn zbytek dat pro stejný web, ale tak, aby byl výpis není přístupný přes webový server. Pokud jsou databáze velké, měli byste nakonfigurovat odstraňování „horkých“ dat, například pomocí xtrabackup pro MySQL, nebo pracovat s WAL s archive_command v PostgreSQL. V tomto případě bude databáze obnovena odděleně od dat webu.
Pokud se používají kontejnery nebo virtuální stroje, měli byste nakonfigurovat qemu-guest-agent, CRIU nebo jiné potřebné technologie. V ostatních případech další nastavení většinou není potřeba – jednoduše vytvoříme snímky logických svazků, které se následně zpracují stejně jako snímek stavu kořenového souborového systému. Po pořízení dat se snímky vymažou.
Další práce se provádějí na serveru úložiště záloh:
- zkontroluje se poslední záloha vytvořená v každém úložišti,
- zkontroluje se přítomnost souboru značek, což znamená, že proces sběru dat je dokončen,
- data se rozšíří na odpovídající místní objem,
- soubor značky je odstraněn
Proces obnovy serveru
Pokud hlavní server zemře, spustí se podobný dedikovaný server, který se spustí z nějakého standardního obrazu. S největší pravděpodobností stahování proběhne přes síť, ale technik datového centra, který nastavuje server, může tento standardní obraz okamžitě zkopírovat na jeden z disků. Ke stažení dojde do paměti RAM, po kterém se spustí proces obnovy:
- je podán požadavek na připojení blokového zařízení přes iscsinbd nebo jiný podobný protokol k logickému svazku obsahujícímu kořenový souborový systém zesnulého serveru; Protože kořenový souborový systém musí být malý, měl by být tento krok dokončen během několika minut. Zavaděč je také obnoven;
- struktura lokálních logických svazků je znovu vytvořena, logické svazky jsou připojeny ze záložního serveru pomocí modulu jádra dm_clone: zahájí se obnova dat a změny jsou okamžitě zapsány na místní disky
- je spuštěn kontejner se všemi dostupnými fyzickými disky - funkčnost serveru je plně obnovena, ale se sníženým výkonem;
- po dokončení synchronizace dat se logické svazky ze záložního serveru odpojí, kontejner se vypne a server se restartuje;
Po restartu bude mít server všechna data, která tam byla v době vytvoření zálohy, a také všechny změny, které byly provedeny během procesu obnovy.
Další články v seriálu
Záloha Část 7: Závěry
Zvu vás k diskusi o navrhované možnosti v komentářích, děkuji za pozornost!
Zdroj: www.habr.com