Pjesa rezervë 7: Përfundime

Pjesa rezervë 7: Përfundime

Ky shënim plotëson ciklin e rezervimit. Ai do të diskutojë organizimin logjik të një serveri të dedikuar (ose VPS), i përshtatshëm për kopje rezervë, dhe gjithashtu do të ofrojë një opsion për rikthimin e shpejtë të një serveri nga një kopje rezervë pa shumë ndërprerje në rast fatkeqësie.

Të dhënat fillestare

Një server i dedikuar më shpesh ka të paktën dy disqe të ngurtë që shërbejnë për të organizuar një grup RAID të nivelit të parë (pasqyrë). Kjo është e nevojshme për të vazhduar funksionimin e serverit nëse një disk dështon. Nëse ky është një server i rregullt i dedikuar, mund të ketë një kontrollues të veçantë harduer RAID me teknologji aktive të memorizimit në SSD, në mënyrë që përveç disqeve të zakonshme të ngurtë, të mund të lidhen një ose më shumë SSD. Ndonjëherë ofrohen serverë të dedikuar, në të cilët disqet e vetëm lokalë janë SATADOM (disqe të vegjël, strukturalisht një flash drive i lidhur me një port SATA), ose edhe një flash drive i zakonshëm i vogël (8-16 GB) i lidhur me një portë të veçantë të brendshme, dhe të dhënat merren nga sistemi i ruajtjes, i lidhur nëpërmjet një rrjeti të dedikuar ruajtjeje (Ethernet 10G, FC, etj.), dhe ka serverë të dedikuar që ngarkohen drejtpërdrejt nga sistemi i ruajtjes. Unë nuk do t'i konsideroj opsione të tilla, pasi në raste të tilla detyra e kopjimit të serverit i kalon pa probleme specialistit që mirëmban sistemin e ruajtjes; zakonisht ekzistojnë teknologji të ndryshme të pronarit për krijimin e fotografive, dedublikim të integruar dhe gëzime të tjera të administratorit të sistemit , diskutuar në pjesët e mëparshme të kësaj serie. Vëllimi i grupit të diskut të një serveri të dedikuar mund të arrijë disa dhjetëra terabajt, në varësi të numrit dhe madhësisë së disqeve të lidhur me serverin. Në rastin e VPS, vëllimet janë më modeste: zakonisht jo më shumë se 100 GB (por ka edhe më shumë), dhe tarifat për një VPS të tillë mund të jenë lehtësisht më të shtrenjta se serverët e dedikuar më të lirë nga i njëjti host. Një VPS më shpesh ka një disk, sepse do të ketë një sistem ruajtjeje (ose diçka të hiperkonverguar) poshtë tij. Ndonjëherë një VPS ka disa disqe me karakteristika të ndryshme, për qëllime të ndryshme:

  • sistem i vogël - për instalimin e sistemit operativ;
  • i madh - ruajtja e të dhënave të përdoruesit.

Kur riinstaloni sistemin duke përdorur panelin e kontrollit, disku me të dhënat e përdoruesit nuk mbishkruhet, por disku i sistemit mbushet plotësisht. Gjithashtu, në rastin e një VPS, hosti mund të ofrojë një buton që merr një pamje të gjendjes së VPS (ose diskut), por nëse instaloni sistemin tuaj operativ ose harroni të aktivizoni shërbimin e dëshiruar brenda VPS, disa të dhënat mund të jenë ende të humbura. Përveç butonit, zakonisht ofrohet një shërbim i ruajtjes së të dhënave, më shpesh shumë i kufizuar. Zakonisht kjo është një llogari me akses nëpërmjet FTP ose SFTP, ndonjëherë së bashku me SSH, me një guaskë të zhveshur (për shembull, rbash), ose një kufizim në ekzekutimin e komandave përmes çelësave të autorizuar (përmes ForcedCommand).

Një server i dedikuar është i lidhur me rrjetin nga dy porte me një shpejtësi prej 1 Gbps, ndonjëherë këto mund të jenë karta me një shpejtësi prej 10 Gbps. VPS më shpesh ka një ndërfaqe rrjeti. Më shpesh, qendrat e të dhënave nuk kufizojnë shpejtësinë e rrjetit brenda qendrës së të dhënave, por ato kufizojnë shpejtësinë e aksesit në internet.

Ngarkesa tipike e një serveri të tillë të dedikuar ose VPS është një server në internet, një bazë të dhënash dhe një server aplikacioni. Ndonjëherë mund të instalohen shërbime të ndryshme ndihmëse shtesë, duke përfshirë një server në internet ose bazë të dhënash: motori i kërkimit, sistemi i postës, etj.

Një server i përgatitur posaçërisht vepron si një hapësirë ​​për ruajtjen e kopjeve rezervë; ne do të shkruajmë për të më në detaje më vonë.

Organizimi logjik i sistemit të diskut

Nëse keni një kontrollues RAID, ose një VPS me një disk, dhe nuk ka preferenca të veçanta për funksionimin e nënsistemit të diskut (për shembull, një disk i veçantë i shpejtë për bazën e të dhënave), e gjithë hapësira e lirë ndahet si më poshtë: një ndarje krijohet dhe mbi të krijohet një grup vëllimi LVM, në të krijohen disa vëllime: 2 të vogla me të njëjtën madhësi, të përdorura si sistemi i skedarëve rrënjë (të ndryshuar një nga një gjatë përditësimeve për mundësinë e rikthimit të shpejtë, ideja u mor nga shpërndarja Calculate Linux), një tjetër është për ndarjen swap, pjesa tjetër e hapësirës së lirë është e ndarë në vëllime të vogla, përdoret si sistemi i skedarëve rrënjë për kontejnerë të plotë, disqe për makina virtuale, skedarë sisteme për llogaritë në /home (çdo llogari ka sistemin e vet të skedarëve), sisteme skedarësh për kontejnerët e aplikacioneve.

Shënim i rëndësishëm: vëllimet duhet të jenë plotësisht të pavarura, d.m.th. nuk duhet të varen nga njëri-tjetri ose nga sistemi i skedarëve rrënjë. Në rastin e makinave virtuale ose kontejnerëve, kjo pikë vërehet automatikisht. Nëse këto janë kontejnerë aplikacionesh ose direktori shtëpiake, duhet të mendoni për ndarjen e skedarëve të konfigurimit të serverit në internet dhe shërbimeve të tjera në mënyrë të tillë që të eliminoni sa më shumë varësitë midis vëllimeve. Për shembull, çdo sajt ekzekutohet nga përdoruesi i vet, skedarët e konfigurimit të faqes janë në drejtorinë kryesore të përdoruesit, në cilësimet e serverit të uebit, skedarët e konfigurimit të faqes nuk përfshihen nëpërmjet /etc/nginx/conf.d/.conf, dhe, për shembull, /home//configs/nginx/*.conf

Nëse ka disa disqe, mund të krijoni një grup RAID softuerësh (dhe të konfiguroni ruajtjen e tij në një SSD, nëse ka nevojë dhe mundësi), në krye të të cilit mund të ndërtoni LVM sipas rregullave të propozuara më sipër. Gjithashtu në këtë rast, ju mund të përdorni ZFS ose BtrFS, por duhet të mendoni dy herë për këtë: të dyja kërkojnë një qasje shumë më serioze ndaj burimeve, dhe përveç kësaj, ZFS nuk përfshihet me kernelin Linux.

Pavarësisht nga skema e përdorur, gjithmonë ia vlen të vlerësohet paraprakisht shpejtësia e përafërt e shkrimit të ndryshimeve në disqe, dhe më pas të llogaritet sasia e hapësirës së lirë që do të rezervohet për krijimin e fotografive. Për shembull, nëse serveri ynë shkruan të dhëna me një shpejtësi prej 10 megabajt për sekondë, dhe madhësia e të gjithë grupit të të dhënave është 10 terabajt - koha e sinkronizimit mund të arrijë një ditë (22 orë - kjo është sa do të transferohet një vëllim i tillë përmes rrjetit 1 Gbps) - ia vlen të rezervoni rreth 800 GB . Në realitet, shifra do të jetë më e vogël; mund ta ndani me siguri me numrin e vëllimeve logjike.

Pajisja e serverit të ruajtjes rezervë

Dallimi kryesor midis një serveri për ruajtjen e kopjeve rezervë është disqet e tij të mëdhenj, të lirë dhe relativisht të ngadaltë. Meqenëse HDD-të moderne kanë kaluar tashmë shiritin 10 TB në një disk, është e nevojshme të përdoren sistemet e skedarëve ose RAID me kontrolle, sepse gjatë rindërtimit të grupit ose restaurimit të sistemit të skedarëve (disa ditë!) disku i dytë mund të dështojë për shkak të për rritjen e ngarkesës. Në disqe me kapacitet deri në 1 TB kjo nuk ishte aq e ndjeshme. Për thjeshtësi të përshkrimit, supozoj se hapësira e diskut ndahet në dy pjesë me madhësi afërsisht të barabartë (përsëri, për shembull, duke përdorur LVM):

  • vëllime që korrespondojnë me serverët e përdorur për të ruajtur të dhënat e përdoruesit (kopja e fundit rezervë e bërë do të vendoset në to për verifikim);
  • vëllimet e përdorura si depo BorgBackup (të dhënat për kopjet rezervë do të shkojnë direkt këtu).

Parimi i funksionimit është që për çdo server krijohen vëllime të veçanta për depot e BorgBackup, ku do të shkojnë të dhënat nga serverët luftarakë. Depot funksionojnë në modalitetin "vetëm shtojca", e cila eliminon mundësinë e fshirjes së qëllimshme të të dhënave, dhe për shkak të fshirjes dhe pastrimit periodik të depove nga kopjet rezervë të vjetra (mbeten kopje vjetore, mujore për vitin e fundit, javore për muajin e fundit, çdo ditë për javën e kaluar, mundësisht në raste të veçanta - për orë për ditën e fundit: gjithsej 24 + 7 + 4 + 12 + vjetore - afërsisht 50 kopje për secilin server).
Depot e BorgBackup nuk aktivizojnë modalitetin vetëm me shtojca; në vend të kësaj, një Komandë e Forcuar në .ssh/authorized_keys përdoret diçka si kjo:

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.......

Rruga e specifikuar përmban një skript mbështjellës në krye të borg, i cili, përveç nisjes së binarit me parametra, fillon gjithashtu procesin e rikthimit të kopjes rezervë pasi të hiqen të dhënat. Për ta bërë këtë, skripti i mbështjellësit krijon një skedar tag pranë depove përkatëse. Rezervimi i fundit i bërë rikthehet automatikisht në vëllimin logjik përkatës pasi të përfundojë procesi i plotësimit të të dhënave.

Ky dizajn ju lejon të pastroni periodikisht kopjet rezervë të panevojshme, dhe gjithashtu parandalon që serverët luftarakë të fshijnë ndonjë gjë në serverin e ruajtjes rezervë.

Procesi i rezervimit

Iniciatori i kopjimit është serveri i dedikuar ose vetë VPS, pasi kjo skemë jep më shumë kontroll mbi procesin e rezervimit nga ana e këtij serveri. Së pari, merret një pamje e gjendjes së sistemit aktiv të skedarëve rrënjë, e cila montohet dhe ngarkohet duke përdorur BorgBackup në serverin e ruajtjes rezervë. Pas përfundimit të kapjes së të dhënave, fotografia e çastit çmontohet dhe fshihet.

Nëse ka një bazë të dhënash të vogël (deri në 1 GB për çdo faqe), bëhet një depo e bazës së të dhënave, e cila ruhet në vëllimin e duhur logjik, ku ndodhet pjesa tjetër e të dhënave për të njëjtin sajt, por në mënyrë që deponimi të jetë nuk është i aksesueshëm përmes serverit të internetit. Nëse bazat e të dhënave janë të mëdha, duhet të konfiguroni heqjen "hot" të të dhënave, për shembull, duke përdorur xtrabackup për MySQL, ose të punoni me WAL me archive_command në PostgreSQL. Në këtë rast, baza e të dhënave do të rikthehet veçmas nga të dhënat e faqes.

Nëse përdoren kontejnerë ose makina virtuale, duhet të konfiguroni qemu-guest-agent, CRIU ose teknologji të tjera të nevojshme. Në raste të tjera, cilësimet shtesë më shpesh nuk nevojiten - ne thjesht krijojmë fotografi të vëllimeve logjike, të cilat më pas përpunohen në të njëjtën mënyrë si një fotografi e gjendjes së sistemit të skedarëve rrënjë. Pasi të merren të dhënat, fotografitë fshihen.

Puna e mëtejshme kryhet në serverin e ruajtjes rezervë:

  • kontrollohet rezervimi i fundit i bërë në çdo depo,
  • kontrollohet prania e një skedari të markës, duke treguar që procesi i mbledhjes së të dhënave ka përfunduar,
  • të dhënat zgjerohen në vëllimin përkatës lokal,
  • skedari i etiketës fshihet

Procesi i rikuperimit të serverit

Nëse serveri kryesor vdes, atëherë lëshohet një server i ngjashëm i dedikuar, i cili fillon nga një imazh standard. Me shumë mundësi shkarkimi do të bëhet përmes rrjetit, por tekniku i qendrës së të dhënave që konfiguron serverin mund ta kopjojë menjëherë këtë imazh standard në një nga disqet. Shkarkimi ndodh në RAM, pas së cilës fillon procesi i rikuperimit:

  • bëhet një kërkesë për të bashkangjitur një pajisje blloku nëpërmjet iscsinbd ose një protokolli tjetër të ngjashëm në një vëllim logjik që përmban sistemin e skedarëve rrënjë të serverit të vdekur; Meqenëse sistemi i skedarëve rrënjë duhet të jetë i vogël, ky hap duhet të përfundojë brenda pak minutash. Bootloader është restauruar gjithashtu;
  • Struktura e vëllimeve logjike lokale është rikrijuar, vëllimet logjike janë bashkangjitur nga serveri rezervë duke përdorur modulin e kernelit dm_clone: ​​fillon rikuperimi i të dhënave dhe ndryshimet shkruhen menjëherë në disqet lokale
  • lëshohet një kontejner me të gjithë disqet fizike të disponueshme - funksionaliteti i serverit është restauruar plotësisht, por me performancë të reduktuar;
  • pas përfundimit të sinkronizimit të të dhënave, vëllimet logjike nga serveri rezervë shkëputen, kontejneri fiket dhe serveri rindizet;

Pas një rindezjeje, serveri do të ketë të gjitha të dhënat që ishin aty në kohën e krijimit të kopjes rezervë dhe gjithashtu do të përfshijë të gjitha ndryshimet që janë bërë gjatë procesit të rivendosjes.

Artikuj të tjerë në seri

Rezervimi, pjesa 1: Pse nevojitet një kopje rezervë, një pasqyrë e metodave, teknologjive
Rezervimi Pjesa 2: Rishikimi dhe testimi i mjeteve rezervë të bazuara në rsync
Rezervimi Pjesa 3: Rishikimi dhe testimi i dyfishimit, duplikati
Rezervimi Pjesa 4: Rishikimi dhe testimi i zbackup, restic, borgbackup
Rezervimi Pjesa 5: Testimi i Bacula dhe Veeam Backup për Linux
Rezervimi: pjesë me kërkesë të lexuesve: rishikimi i AMANDA, UrBackup, BackupPC
Rezervimi Pjesa 6: Krahasimi i mjeteve rezervë
Pjesa rezervë 7: Përfundime

Ju ftoj të diskutoni opsionin e propozuar në komente, faleminderit për vëmendjen tuaj!

Burimi: www.habr.com

Shto një koment