Varundamine, osa 7: Järeldused

See märkus lõpetab varundamise tsükli. Siin räägitakse pühendatud serveri (või VPS) loogilisest korraldusest, mis on varundamiseks mugav, ja pakutakse välja kiire taastamise variant, et vältida olulisi seise serveri hädaolukorra korral.

Algandmed

Pühendatud serveril on tavaliselt vähemalt kaks kõvaketta, mis on mõeldud RAID 1 (peegel) seadistamiseks. See on vajalik serveri töö jätkamiseks, kui üks ketas ebaõnnestub. Kui tegemist on tavalise pühendatud serveriga, võib olla eraldi riistvaraline RAID-kontroller, millel on aktiivne SSD vahemälu tehnoloogia, niisiis võib tavalistele kõvaketastele lisaks olla ühendatud üks või mitu SSD. Mõnikord pakutakse pühendatud servereid, kus kohalikke kettaid on ainult SATADOM (väikesed kettad, mille konstruktsioon on nagu USB mälu, mis on ühendatud SATA pessa), või isegi tavaline väike (8-16 GB) USB-mälu, mis on ühendatud spetsiaalsesse sisemisse pessa, samas kui andmed saadakse SAN-ilt, mis on ühendatud eraldiseisva andmesalvestusvõrguga (Ethernet 10G, FC jne), ja neid on ka pühendatud servereid, mis laadivad otse SAN-ilt. Selliseid variante ma ei käsitle, kuna sel juhul üleminek serveri varundamise ülesandele kuulub spetsialistile, kes haldab SAN-i; reeglina on seal erinevaid patenteeritud tehnoloogiaid olekute pildistamiseks, sisseehitatud deduplikatsioon ja muud süsteemiadministraatori mugavused, mis on käsitletud selles tsüklis varasemates osades. Pühendatud serveri ketta maht võib ulatuda kümnete terabaitideni, sõltuvalt serveriga ühendatud kettaste arvust ja mahust. VPS puhul on mahud tagasihoidlikumad: tavaliselt mitte rohkem kui 100 GB (kuid on ka suuremaid), ja selliste VPS-ide hinnad võivad olla kergesti kallimad kui kõige odavamad pühendatud serverid samalt hostilt. VPS-l on enamasti vaid üks ketas, kuna selle all on SAN (või mõni hüperkonvergeeritud lahendus). Mõnikord on VPS-il mitu ketast erinevate omadustega, erinevate eesmärkide jaoks:

• väike süsteemne — operatsioonisüsteemi installimiseks;
• suur — kasutajaandmete salvestamiseks.

Süsteemi taaskasutamisel juhtpaneeli abil ei kustutata kasutajaandmete kettale, kuid süsteemne uuendatakse täielikult. VPS-i puhul võib hostija pakkuda nuppu, mis teeb VPS-i (või ketta) oleku kuvandi, kuid kui installite oma operatsioonisüsteemi või unustate aktiveerida vajaliku teenuse VPS-is — võivad mõned andmed ikkagi kaduma minna. Lisaks nupule pakutakse tavaliselt andmete salvestamise teenust, mis on enamasti tugevalt piiratud. See on tavaliselt konto FTP või SFTP protokolli kaudu juurdepääsuga, mõnikord koos SSH-ga, piiratud shelliga (näiteks rbash) või käskude käivitamise piiranguga authorized_keys kaudu (ForcedCommand kaudu).

Pühendatud server on ühendatud võrku kahe 1 Gbit/s kiirusel pordi kaudu, mõnikord võivad need olla 10 Gbit/s kiirusel kaardid. VPS-i võrgu liides on tavaliselt üks. Andmekeskused ei piira enamasti sisevõrgu kiirus, kuid piiravad Interneti-juurdepääsu kiirus.

Tüüpiline sellise pühendatud serveri või VPS-i koormus koosneb veebiserverist, andmebaasist ja rakenduste serverist. Sageli võivad olla paigaldatud erinevad täiendavad abiteenused, sealhulgas veebiserveri või andmebaasi jaoks: otsingumootor, meilisüsteem jne.

Varukoopiate salvestamiseks kasutatakse spetsiaalselt ettevalmistatud serverit, millest hakatakse hiljem põhjalikumalt rääkima.

Kettasüsteemi loogiline organiseerimine

Kui on olemas RAID-kontroller või on tegu VPS-iga ühe ketasaga ning ei ole erilisi eelistusi ketassüsteemi töö osas (näiteks eraldiseisev kiire ketas andmebaasi jaoks), jagatakse kogu vaba ruum järgmiselt: luuakse üks partitsioon, mille peale luuakse LVM mahugrupp, milles luuakse mitu mahut: 2 väikesest sama suurusega, mida kasutatakse põhifailisüsteemina (vahetatakse järkjärgult uuenduste ajal kiireks tagasiviimiseks, idee on inspireeritud Calculate Linux'i distributsioonist), veel üks — vahetuspartitsiooniks, ülejäänud vaba ruum jagatakse väikesteks mahuteks, mida kasutatakse põhifailisüsteemina täisväärtuslike konteinerite jaoks, virtuaalmasinate ketaste jaoks, failisüsteemide jaoks kasutajate kontode jaoks /home (iga konto jaoks — oma failisüsteem), failisüsteemide jaoks rakenduskonteinerite jaoks.

Oluline märkus: mahtude puhul tuleb tagada, et need oleksid täielikult iseseisvad, st ei tohiks üksteisest ega ka juurkataloogist sõltuda. Virtuaalmasinate või konteinerite puhul kehtib see automaatselt. Kui aga tegemist on rakenduste konteinerite või kodukataloogidega, tuleks mõelda veebiserveri ja teiste teenuste konfigureerimisfailide eraldamisele, et vähendada mahtudevahelisi sõltuvusi. Näiteks iga veebisait töötleb oma kasutaja alt, veebisaidi konfigureerimisfailid asuvad kasutaja kodukataloogis, veebiserveri seadetes konfigureerimisfailid ei ole lisatud läbi /etc/nginx/conf.d/.conf, vaid näiteks /home//configs/nginx/*.conf

Kui aga on mitu ketast, saab luua tarkvara RAID-massiivi (ja seadistada selle vahemälu SSD-le, kui on vajadus ja võimalused), mille peale on üles ehitatud LVM vastavalt eespool toodud juhistele. Samuti võib kasutada ZFS-i või BtrFS-i, kuid siin tuleks mitu korda mõelda: mõlemad nõuavad palju tõsist lähenemist ressurssidele, lisaks ei ole ZFS Linuxi tuumaga kaasas.

Sõltumata kasutatavast skeemist on alati mõistlik eelnevalt arvutada ligikaudne kirjutamiskiirus kettale, seejärel arvutada vaba ruumi suurus, mis reserveeritakse võtmete loomiseks. Näiteks, kui meie server kirjutab andmeid kiirusel 10 megabaidi sekundis ja kogu andmemassi suurus on 10 terabaiti — sünkroniseerimise aeg võib ulatuda päevi (22 tundi — nii kaua kulub selle koguse edastamiseks 1 Gbit/s võrgus) — tuleks reserveerida umbes 800 GB. Tegelikult on number väiksem, saab julgelt jagada selle loogiliste volüümide arvuga.

Varundusseadmestik

Peamine erinevus varundusserveri ja teiste serverite vahel on see, et need kasutavad suuri, odavaid ja võrreldes kiiret ketast. Kuna modernsed HDD-d on juba ületanud 10 TB piiri ühe ketta kohta, on failisüsteemide või RAID-süsteemide kasutamine, kus toimub kontrollsumma, kohustuslik. Seetõttu võib teise ketta rike tekkida suurenenud koormuse tõttu array ümberkujundamise või failisüsteemi taastamise ajal (mis võib võtta mitu päeva!). Kuni 1 TB kettatel ei olnud see nii tundlik. Lihtsuse huvides eeldan, et ketas on jagatud kaheks enam-vähem võrdses suuruses osaks (näiteks LVM-i abil):

• partitsioonid, mis vastavad serveritele, mida kasutatakse kasutajaandmete salvestamiseks (neil rakendatakse viimast loodud varukoopiat kontrollimise eesmärgil);
• partitsioonid, mida kasutatakse BorgBackup'i hoidlatena (siia pannakse otse andmed varukoopiate jaoks).

Tööpõhimõte seisneb selles, et iga serveri jaoks luuakse eraldi mahud BorgBackup'i hoidlate jaoks, kuhu lähevad andmed tootmisserveritest. Hoidlad töötavad ainult lisamise režiimis, mis välistab andmete tahtliku kustutamise võimaluse, mistõttu deduplikatsiooni ja regulaarsete puhastusprotseduuride kaudu säilitatakse vanu varukoopiaid (jäävad aasta varukoopiad, viimase aasta jooksul igakuised, viimase kuu jooksul iganädalased, viimase nädala jooksul iga päev, äärmuslikel juhtudel - iga tunni tagant viimase päeva jooksul: kokku 24 + 7 + 4 + 12 + aastased - umbes 50 koopiat iga serveri kohta).
BorgBackup'i hoidlates ei aktiveerita ainult lisamise režiimi, selle asemel kasutatakse ForcedCommand'i failis .ssh/authorized_keys, mille struktuur on umbes järgmine:

from="serveri aadress",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.......

Määratud teele on pandud Borgi kohal olev wrapper-skript, mis mitte ainult ei käivita binaarfaili parameetritega, vaid käivitab ka varukoopia taastamisprotsessi pärast andmete kopeerimise lõppu. Selle jaoks loob wrapper-skript kõrval asuva tähis-faili vastava hoidla kõrvale. Viimane tehtud varukoopia taastatakse automaatselt vastavale loogilisele mahtule pärast andmete ülekande protsessi lõppu.

See konstruktsioon võimaldab perioodiliselt eemaldada tarbetuid varukoopiaid ning takistab ka tootmisserveritel salvestusserveris midagi kustutada.

Varundamisprotsess

Varundamise algatajaks on ise pühendatud server või VPS, kuna see skeem annab serveri poolt varundamisprotsessi üle suurema kontrolli. Esiteks tehakse aktiivse juurkatalooge oleku hetkefoto, mis mountitakse ja laaditakse BorgBackup abil varundusserverisse. Pärast andmete kogumise lõppu eemaldatakse ja kustutatakse hetkefoto.

Kui andmed on väikese hulga andmebaasiga (kuni 1 GB iga veebilehe kohta), tehakse andmebaasi eksemplar, mis salvestatakse vastavasse loogilisse mahutisse, sinna, kus asuvad ka ülejäänud selle veebilehe andmed, kuid nii, et eksemplar ei oleks veebiserveris saadaval. Kui andmebaasid on suured, tuleb seadistada "kuuma" andmete eemaldamise protsess, näiteks xtrabackup'i abil MySQL jaoks või WAL töötlus archive_command abil PostgreSQL'is. Sellisel juhul taastatakse andmebaas eraldi veebilehe andmetest.

Kui kasutatakse konteinerite või virtuaalmasinate tehnoloogiat, tuleb seadistada qemu-guest-agent, CRIU või teised vajalikud tehnoloogiad. Enamikes muudes olukordades täiendavat seadistamist ei ole tavaliselt vajalik — lihtsalt loome loogiliste mahutite koopiaid, mida töödeldakse sarnaselt juurefailisüsteemi oleku koopia tegemisega. Andmete eemaldamise peale koopiaid kustutatakse.

Edasiöeldav töö toimub varukoopiakandjal:

• kontrollitakse iga reposiitri viimast tehtud varukoopiat,
• kontrollitakse, kas olemas on märgifail, mis näitab, et andmete eemaldamise protsess on lõpule viidud,
• andmed paigaldatakse vastavale kohaliku kettale,
• märkfail kõrvaldatakse

serveri töövõime taastamise protsess

Kui põhiserver kätkeb, siis käivitatakse sarnane pühendatud server, mis laaditakse mõnest standardpildist. Tõenäoliselt toimub laadimine üle võrgu, kuid andmekeskuse tehnik, kes serverit seadistab, võib selle standardpildi ühe ketta peale kohe kopeerida. Laadimine toimub mällu, pärast mida algab taastamisprotsess:

• esitatakse päring plokk-seadmestiku ühendamiseks iscsinbd või mõne muu sarnase loogilise ketta protokolliga, mis sisaldab hukkunud serveri juurefailisüsteemi; kuna juurefailisüsteem peab olema väike - see etapp peaks olema lõpetatud mõne minutiga. Samuti taastatakse käivitaja;
• lokalsete loogiliste mahtude struktuur taastatakse, loogilised mahud ühendatakse varundusseadmest kernel'i dm_clone mooduli abil: andmete taastamine algab, samal ajal salvestatakse muutused koheselt kohalikesse kettasektsioonidesse
• kanne käivitatakse kõigi füüsiliste kettadega — serveri töövõime täielikult taastatakse, kuid madalama jõudlusega;
• andmete sünkroonimise lõppedes eraldatakse loogilised mahud varundusseadmest, kanne suletakse, server taaskäivitatakse;

Pärast taaskäivitamist on serveril kõik andmed, mis olid varukoopia loomise hetkel, ja kõiki muudatusi, mis taastamise protsessis tehti.

Teised tsükli artiklid

Varundamine, osa 1: Miks on varundamine vajalik, meetodite, tehnoloogiate ülevaade
Varundamine, osa 2: rsync-põhiste varunduslahenduste ülevaade ja testimine
Varundamine, osa 3: Duplicity ja Duplicati ülevaade ja testimine
Varundamine, osa 4: Zbackup, restic, borgbackup ülevaade ja testimine
Varundamine, osa 5: Bacula ja Veeam Backup for Linuxi testimine
Varundamine: osa lugejate poolt palutud: AMANDA, UrBackup, BackupPC ülevaade
Varundamine, osa 6: Varundamisvahendite võrdlus
Varundamine, osa 7: Järeldused

Kutsun arvustama esitatud ettepanekut kommentaarides, tänan teid tähelepanu eest!

Allikas: habr.com