Varundamine, osa 7: Järeldused

See märkus lõpetab varundamise tsükli. Räägime eraldatud serveri (või VPS) loogilisest korraldusest, mis on varundamiseks mugav, ning pakume välja kiire taastamise lahenduse varukoopiast serveri avarii korral ilma suuremate seisakuteta.

Algandmed

Eraldatud serveril on enamasti vähemalt kaks kõvaketast, mis on mõeldud RAID-i esmaklassilise (peegeldamise) korraldamiseks. See on vajalik, et server saaks jätkata tööd, kui üks ketas peaks rikkis olema. Kui see on tavaline eraldatud server, võib seal olla eraldi riistvaraline RAID-kontroller SSD aktiivse vahemälu tehnoloogiaga, seega võib tavaliste kõvaketaste kõrval olla ühendatud üks või rohkem SSD-d. Mõnikord pakutakse eraldatud servereid, kus kohalikke kettaid on ainult SATADOM (väikesed kettad, konstruktsiooniliselt – USB-mälupulk, mis on ühendatud SATA-porti), või isegi tavaline väike (8-16 GB) mälupulk, mis on ühendatud spetsiaalsesse sisemisse porti, ning andmed pärinevad andmesalvestussüsteemist, mis on ühendatud eraldatud salvestusvõrguga (Ethernet 10G, FC jne), ja on olemas eraldatud serverid, mis laadivad otse andmesalvestussüsteemist. Selliseid variante ma ei käsitle, kuna sellistel juhtudel üleminek serveri varundamise ülesandest muutub spetsialisti vastutuseks, kes hooldab andmesalvestussüsteemi; seal on tavaliselt erinevad kaubamärgitehnoloogiad oleku koopiate loomiseks, sisseehitatud deduplication ja muud süsteemiadministraatori mugavused, mida on käsitletud selle tsükli eelnevates osades. Eraldatud serveri kettamaht võib ulatuda mitme kümne terabaitini, sõltuvalt serveriga ühendatud ketaste arvust ja mahust. VPS-i puhul on mahud skrommed: tavaliselt mitte rohkem kui 100 GB (aga võib olla ka rohkem), ja selliste VPS-ide hinnad võivad kergesti ületada selle sama hostimise firma odavaimate eraldatud serverite hindu. VPS-il on enamasti üks ketas, kuna selle all on andmesalvestussüsteem (või midagi hüperkonvergente). Mõnikord on VPS-il mitu ketast erinevate omadustega, erinevate eesmärkide jaoks:

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

Süsteemi uuesti installimisel ei kustutata kasutajate andmeid sisaldavat ketast juhtpaneeli abil, vaid süsteemne ketas kirjutatakse täielikult üle. VPS-i puhul võib teenusepakkuja pakkuda nuppu, mis teeb VPS (või ketta) seisundi koopia, kuid kui paigaldada oma operatsioonisüsteem või unustada vajalik teenus VPS-is aktiveerida, võib osa andmeid ikkagi kaduda. Nupule lisaks pakutakse tavaliselt andmete salvestamise teenust, mis on enamasti tugevalt piiritletud. See on tavaliselt konto, millele pääseb FTP või SFTP protokolli kaudu, mõnikord koos SSH-ga, piiratud shelliga (näiteks rbash) või käsu täitmise piiranguga läbi authorized_keys (kasutades ForcedCommand).

Pühendatud server on ühendatud võrguga kahe 1 Gbit/s kiirusel kaabli kaudu, mõnikord on need kaardid kiirusel 10 Gbit/s. VPS-i võrgu liidese kiirus on enamasti üks. Andmekeskused ei piira sisemise võrgu kiirus, kuid piiravad interneti juurdepääsu kiirus.

Tüüpiline koormus sarnases pühendatud serveris või VPS-is koosneb veebiserverist, andmebaasist ja rakenduste serverist. Aeg-ajalt võivad olla installitud erinevad täiendavad abiteenused, sealhulgas veebiserveri või andmebaasi jaoks: otsimootor, e-posti süsteem jne.

Varukoopiate salvestamiseks on ette valmistatud spetsiaalne server, millest räägitakse lähemalt hiljem.

Kettasüsteemi loogiline korraldus

Kui on RAID-kontrollers või üksik ketas VPS-il ning ei ole erilisi eelistusi ketasüsteemi töö osas (näiteks eraldi kiire ketas andmebaasiks) — jaotatakse kogu vaba ruum järgmiselt: luuakse üks partitsioon, mille peale luuakse LVM mahugrupp, milles luuakse mitu mahtu: 2 väikest sama suurusega, mida kasutatakse juurfailisüsteemina (need muutuvad kordamööda värskenduste käigus kiireks tagasipöördumiseks, mõte on pärit Calculate Linux jaotusest), ning veel üks — swap-partitsiooniks, ülejäänud vaba ruum jagatakse väikesteks mahtudeks, mida kasutatakse täisfunktsionaalsete konteinerite juurfailisüsteemidena, virtuaalmasinate ketastena, failisüsteemidena kasutajate kodudeks \/home (iga kasutaja jaoks oma failisüsteem), rakenduskonteinerite failisüsteemidena.

Oluline märkida: mahud peavad olema täiesti iseseisvad, st nad ei tohi sõltuda üksteisest ega juurfailisüsteemist. Virtuaalmasinate või konteinerite puhul on see automaatselt tagatud. Kui tegemist on rakenduskonteinerite või kodukataloogidega, siis tasub mõelda veebiserveri ja teiste teenuste konfigureerimisfailide eraldamisele nii, et mahtude vahelisi sõltuvusi oleks minimaalne. Näiteks töötab iga sait oma kasutaja alt, saidi konfigureerimisfailid on kasutaja kodukataloogis, veebiserveri seadetes kaasatakse saidi konfigureerimisfailid mitte läbi \/etc\/nginx\/conf.d\/.conf, vaid näiteks \/home\//configs/nginx/*.conf

Kui siiski on mitu ketast — saab luua loogilise RAID- massiivi (ja seadistada selle SSD-l kuve vastavalt vajadusele ja võimalustele), mille peale luua LVM vastavalt eespool kirjeldatud reeglitele. Samuti on võimalik kasutada ZFS-i või BtrFS-i, kuid siin tasub mitu korda järele mõelda: mõlemad nõuavad palju tõsisema lähenemist ressurssidele, lisaks ei kaasne ZFS Linuxi tuumaga.

Sõltumata kasutatavast skeemist on alati mõistlik hinnata muudatuste salvestamise kiirus, enne kui arvutatakse välja vaba ruumi suurus, mis reserveeritakse varukoopiate tegemiseks. Näiteks, kui meie server salvestab andmeid kiirusel 10 megabaiti sekundis ning kogu andmemassiiv on 10 terabaiti — võib sünkroonimise aeg kesta terve päeva (22 tundi — just nii kaua kulub selle mahuga andmete ülekandmiseks 1 Gbit/s võrgus) — tasub varuda umbes 800 GB. Tegelik number tuleb olema väiksem, seda saab julgelt jagada loogiliste partitsioonide arvuga.

Varukoopiate salvestamise server

Peamine erinevus varukoopiate salvestamise serveri ja tavalisel serveril on suured, odavad ja suhteliselt aeglased kettad. Kuna kaasaegsed HDD-d on juba ületanud 10 TB piiri ühe ketta kohta — on kindlasti vajalik rakendada failisüsteeme või RAID koos kontrollsummadega, sest andmemassiivi ümberkorraldamise või failisüsteemi taastamise ajal (mitu päeva!) võib teine ketas talitlushäirete tõttu kõrge koormuse tõttu rikki minna. Kettad, mille maht on kuni 1 TB, ei olnud nii tundlikud. Lihtsuse huvides eeldan, et kettaruum on jagatud kahe umbes sama suurusega ossa (näiteks LVM abil):

• partitsioonid, mis vastavad serverites kasutatavale kasutajaandmete salvestamise jaoks (neil taastatakse viimane varukoopia kontrollimiseks);
• partitsioonid, mis kasutatakse BorgBackup'i hoidlatest (siia jõuavad otse varukoopiad).

Tööpõhimõte seisneb selles, et iga serveri jaoks luuakse eraldi partitsioonid BorgBackup'i hoidlate jaoks, kuhu kanduvad andmed tegevusserveritest. Hoidlad töötavad ainult lisamise režiimis, mis välistab andmete tahtlikku kustutamist, ning tänu dedupplikatsioonile ja regulaarsele vana varukoopia puhastamisele (jäävad aastased koopiad, viimase aasta kuised koopiad, viimase kuu nädalased koopiad, viimase nädala igapäevased koopiad ja mõnes erijuhtumis — viimase päeva iga tunni koopiad: kokku 24 + 7 + 4 + 12 + aastased — ligikaudu 50 koopiat iga serveri jaoks).
BorgBackup'i repositooriumides ei aktiveeru ainult lisamise režiim, selle asemel kasutatakse .ssh/authorized_keys-s sundkäsku, mis näeb välja umbes selline:

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 paigutatud borgi pealiskirje skript, mis lisaks binaari käivitamisele parameetritega, käivitab pärast andmete salvestamise lõppu ka varukoopia taastamise protsessi. Selleks loob pealiskirje skript samaaegselt vastava repositooriumi kõrvale tähisfaili. Viimane tehtud varukoopia taastatakse automaatselt pärast andmete üleslaadimise protsessi lõppu vastavale loogilisele mahule.

See konstruktsioon võimaldab perioodiliselt puhastada mittevajalikke varukoopiaid ja takistab tootmiserverite andmete kustutamist varukoopiate salvestamise serveris.

Varundamisprotsess

Varundamise algataja on ise pühendatud server või VPS, kuna see skeem annab rohkem kontrolli varundamisprotsessi üle sellest serverist. Esiteks tehakse aktiivse juurkatalooge süsteemi oleku snapshot, mis mountitakse ja laaditakse üles BorgBackupiga varukoopiate salvestamise serverisse. Pärast andmete salvestamist unmountitakse ja kustutatakse snapshot.

Kui on olemas väike andmebaas (kuni 1 GB iga saidi kohta), tehakse andmebaasi dump, mis salvestatakse vastavale loogilisele mahule, kus asuvad ka selle saidi muud andmed, kuid nii, et dump ei oleks veebiserveri kaudu kättesaadav. Kui aga andmebaasid on suured – tuleks seadistada 'kuum' andmete salvestamine, näiteks xtrabackup abil MySQL jaoks või WAL töötamine archive_command'iga PostgreSQL'is. Sellisel juhul taastatakse andmebaas eraldi saidi andmetest.

Kui kasutatakse konteinerite või virtuaalmasinate, tuleks seadistada qemu-guest-agent, CRIU või muid vajalik tehnoloogiaid. Muudel juhtudel ei ole lisaseadistusi tavaliselt vaja – lihtsalt loome loogiliste mahtude snapshot'e, mida seejärel töödeldakse analooge juurfilosoofiate snapshot'i osas. Pärast andmete salvestamist kustutatakse snapshot'id.

Edasiareng toimub varukoopiate salvestamise serveris:

• kontrollitakse igas hoidlas viimati tehtud varukoopiat,
• kontrollitakse, kas on olemas sildifail, mis näitab, et andmete eemaldamise protsess on lõpule viidud,
• teostatakse andmete taastamine vastavale kohalikule mahule,
• eemaldatakse sildifail,

Serveri taastamise protsess,

Kui peamine server on rikki läinud, käivitatakse sarnane pühendatud server, mis laaditakse mingist standardsest pildist. Kõige tõenäolisemalt toimub laadimine üle võrgu, kuid andmekeskuse tehnik, kes seadistab serverit, võib selle standardses pildi kohe ühele kettale kopeerida. Laadimine toimub töötlemismälusse, pärast mida algab taastamisprotsess:

• teostatakse päring blokeeritud seadme ühendamiseks iscsinbd või muude sarnaste loogilise mahu protokollidega, mis sisaldavad sureva serveri juurfailisüsteemi; kuna juurfailisüsteem peab olema väike - see etapp peaks olema lõpule viidud mõne minuti jooksul. Taastatakse ka laadija;
• loomisel luuakse kohalike loogiliste mahu struktuur, ühendatakse varukoopiate serveri loogilised mahud dm_clone kali mooduli kaudu: algab andmete taastamine, samas kui muudatused kirjutatakse kohe kohalikele ketastele,
• käivitatakse konteiner kõigi saadaolevate füüsiliste ketastega - serveri töövõime taastatakse täielikult, kuid madalama jõudlusega;
• pärast andmete sünkroonimise lõpetamist lahutatakse varukoopiate serveri loogilised mahud, konteiner välja lülitatakse, server taaskäivitatakse;

Pärast taaskäivitamist on serveril olemas kõik andmed, mis olid varukoopia loomise hetkel, samuti kõik muudatused, mis tehti taastamisprotsessi käigus.

Sari teise artiklid

Varundamine, osa 1: Miks on varundamine vajalik, meetodite ja tehnoloogiate ülevaade
Varundamine, osa 2: rsync-põhiste varundustööriistade ülevaade ja testimine
Varundamine, osa 3: Ülevaade ja testimine duplicity, duplicati
Varundamine, osa 4: Zbackup, restic, borgbackup ülevaade ja testimine
Varundamine, osa 5: Bacula ja Veeam Backup for Linux testimine
Varundamine: osa lugejate soovi järgi: AMANDA, UrBackup, BackupPC ülevaade,
Varundamine, osa 6: Varundamise tööriistade võrdlus
Varundamine, osa 7: Järeldused

Kutsun arutama pakutud varianti kommentaarides, tänan tähelepanu eest!

Allikas: habr.com