Hierdie nota voltooi die siklus oor rugsteun. Dit sal die logiese organisasie van 'n toegewyde bediener (of VPS) bespreek, gerieflik vir rugsteun, en sal ook 'n opsie bied om 'n bediener vinnig van 'n rugsteun te herstel sonder veel stilstand in die geval van 'n ramp.
Aanvanklike gegewens
'n Toegewyde bediener het meestal ten minste twee hardeskywe wat dien om 'n eerstevlak-RAID-skikking (spieël) te organiseer. Dit is nodig om voort te gaan om die bediener te bedryf as een skyf misluk. As dit 'n gewone toegewyde bediener is, kan daar 'n aparte hardeware RAID-beheerder met aktiewe kastegnologie op SSD wees, sodat bykomend tot gewone hardeskywe, een of meer SSD's gekoppel kan word. Soms word toegewyde bedieners aangebied, waarin die enigste plaaslike skywe SATADOM is (klein skywe, struktureel 'n flash drive gekoppel aan 'n SATA-poort), of selfs 'n gewone klein (8-16GB) flash drive wat aan 'n spesiale interne poort gekoppel is, en die data word van die stoorstelsel geneem, gekoppel via 'n toegewyde bergingnetwerk (Ethernet 10G, FC, ens.), en daar is toegewyde bedieners wat direk vanaf die stoorstelsel gelaai word. Ek sal nie sulke opsies oorweeg nie, want in sulke gevalle gaan die taak om die bediener te rugsteun glad oor na die spesialis wat die bergingstelsel onderhou; gewoonlik is daar verskeie eie tegnologieë vir die skep van foto's, ingeboude deduplisering en ander vreugdes van die stelseladministrateur , bespreek in die vorige dele van hierdie reeks. Die volume van 'n toegewyde bediener se skyfskikking kan 'n paar tientalle teragrepe bereik, afhangende van die aantal en grootte skywe wat aan die bediener gekoppel is. In die geval van VPS is die volumes meer beskeie: gewoonlik nie meer as 100 GB nie (maar daar is ook meer), en die tariewe vir sulke VPS kan maklik duurder wees as die goedkoopste toegewyde bedieners van dieselfde gasheer. 'n VPS het meestal een skyf, want daar sal 'n stoorstelsel (of iets wat hipergekonvergeerd is) daaronder wees. Soms het 'n VPS verskeie skywe met verskillende eienskappe, vir verskillende doeleindes:
- klein stelsel - vir die installering van die bedryfstelsel;
- groot - stoor gebruikerdata.
Wanneer jy die stelsel herinstalleer met behulp van die beheerpaneel, word die skyf met gebruikersdata nie oorskryf nie, maar die stelselskyf word heeltemal hervul. Ook, in die geval van 'n VPS, kan die gasheer 'n knoppie bied wat 'n momentopname neem van die toestand van die VPS (of skyf), maar as jy jou eie bedryfstelsel installeer of vergeet om die verlangde diens binne die VPS te aktiveer, van die data kan steeds verlore gaan. Benewens die knoppie, word 'n databergingsdiens gewoonlik aangebied, meestal baie beperk. Tipies is dit 'n rekening met toegang via FTP of SFTP, soms saam met SSH, met 'n gestroopte dop (byvoorbeeld, rbash), of 'n beperking op die uitvoer van opdragte deur gemagtigde_sleutels (via ForcedCommand).
'n Toegewyde bediener is aan die netwerk gekoppel deur twee poorte met 'n spoed van 1 Gbps, soms kan dit kaarte wees met 'n spoed van 10 Gbps. VPS het meestal een netwerkkoppelvlak. Dikwels beperk datasentrums nie die netwerkspoed binne die datasentrum nie, maar hulle beperk die spoed van internettoegang.
Die tipiese las van so 'n toegewyde bediener of VPS is 'n webbediener, 'n databasis en 'n toepassingsbediener. Soms kan verskeie bykomende hulpdienste geïnstalleer word, insluitend vir 'n webbediener of databasis: soekenjin, posstelsel, ens.
'n Spesiaal voorbereide bediener dien as 'n spasie vir die stoor van rugsteunkopieë; ons sal later in meer besonderhede daaroor skryf.
Logiese organisasie van die skyfstelsel
As u 'n RAID-beheerder het, of 'n VPS met een skyf, en daar is geen spesiale voorkeure vir die werking van die skyfsubstelsel nie (byvoorbeeld 'n aparte vinnige skyf vir die databasis), word alle vrye spasie soos volg verdeel: een partisie geskep word, en 'n LVM-volumegroep word bo-op dit geskep, verskeie volumes word daarin geskep: 2 kleintjies van dieselfde grootte, gebruik as die wortellêerstelsel (een vir een verander tydens opdaterings vir die moontlikheid van vinnige terugrol, die idee is opgetel van die Calculate Linux-verspreiding), 'n ander een is vir die swap-partisie, die res van die vrye spasie word in klein volumes verdeel, wat gebruik word as die wortellêerstelsel vir volwaardige houers, skywe vir virtuele masjiene, lêer stelsels vir rekeninge in /home (elke rekening het sy eie lêerstelsel), lêerstelsels vir toepassingshouers.
Belangrike nota: volumes moet heeltemal selfstandig wees, d.w.s. behoort nie van mekaar of van die wortellêerstelsel afhanklik te wees nie. In die geval van virtuele masjiene of houers, word hierdie punt outomaties waargeneem. As dit toepassingshouers of tuisgidse is, moet u daaraan dink om die konfigurasielêers van die webbediener en ander dienste op so 'n manier te skei dat afhanklikhede tussen die volumes so veel as moontlik uitgeskakel word. Elke werf loop byvoorbeeld vanaf sy eie gebruiker, die werfkonfigurasielêers is in die gebruiker se tuisgids, in die webbedienerinstellings is werfkonfigurasielêers nie ingesluit via /etc/nginx/conf.d/.conf, en, byvoorbeeld, /home//configs/nginx/*.conf
As daar verskeie skywe is, kan jy 'n sagteware RAID-skikking skep (en die kas op 'n SSD konfigureer, as daar 'n behoefte en geleentheid is), waarop jy LVM kan bou volgens die reëls hierbo voorgestel. Ook in hierdie geval kan jy ZFS of BtrFS gebruik, maar jy moet twee keer hieroor dink: albei vereis 'n baie meer ernstige benadering tot hulpbronne, en buitendien is ZFS nie by die Linux-kern ingesluit nie.
Ongeag die skema wat gebruik word, is dit altyd die moeite werd om vooraf die benaderde spoed van die skryf van veranderinge na skywe te skat, en dan die hoeveelheid vrye spasie te bereken wat gereserveer sal word vir die skep van foto's. Byvoorbeeld, as ons bediener data teen 'n spoed van 10 megagrepe per sekonde skryf, en die grootte van die hele dataskikking is 10 teragrepe - kan die sinchronisasietyd 'n dag bereik (22 uur - dit is hoeveel so 'n volume oorgedra sal word) oor die netwerk 1 Gbps) - dit is die moeite werd om ongeveer 800 GB te bespreek. In werklikheid sal die syfer kleiner wees; jy kan dit veilig deel deur die aantal logiese volumes.
Rugsteun stoor bediener toestel
Die belangrikste verskil tussen 'n bediener vir die stoor van rugsteunkopieë is sy groot, goedkoop en relatief stadige skywe. Aangesien moderne HDD's reeds die 10TB-balk in een skyf oorgesteek het, is dit nodig om lêerstelsels of RAID met kontrolesomme te gebruik, want tydens die herbou van die skikking of die herstel van die lêerstelsel ('n paar dae!) kan die tweede skyf misluk as gevolg van tot verhoogde vrag. Op skywe met 'n kapasiteit van tot 1 TB was dit nie so sensitief nie. Vir die eenvoud van beskrywing, neem ek aan dat die skyfspasie in twee dele van ongeveer gelyke grootte verdeel is (weereens, byvoorbeeld, met behulp van LVM):
- volumes wat ooreenstem met die bedieners wat gebruik word om gebruikersdata te stoor (die laaste rugsteun wat gemaak is, sal op hulle ontplooi word vir verifikasie);
- volumes wat as BorgBackup-bewaarplekke gebruik word (data vir rugsteun sal direk hierheen gaan).
Die beginsel van werking is dat afsonderlike volumes vir elke bediener vir die BorgBackup-bewaarplekke geskep word, waarheen data van die gevegbedieners sal gaan. Die bewaarplekke werk in slegs byvoegmodus, wat die moontlikheid uitskakel om data doelbewus uit te vee, en as gevolg van deduplisering en periodieke skoonmaak van bewaarplekke van ou rugsteun (jaarlikse kopieë bly maandeliks vir die laaste jaar, weekliks vir die laaste maand, daagliks vir die verlede week, moontlik in spesiale gevalle - uurliks vir die laaste dag: totaal 24 + 7 + 4 + 12 + jaarliks - ongeveer 50 kopieë vir elke bediener).
BorgBackup-bewaarplekke aktiveer nie byvoeg-alleen-modus nie; in plaas daarvan word 'n ForcedCommand in .ssh/authorized_keys iets soos hierdie gebruik:
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.......Die gespesifiseerde pad bevat 'n wrapper script bo-op borg, wat, benewens die begin van die binêre met parameters, addisioneel die proses begin om die rugsteunkopie te herstel nadat die data verwyder is. Om dit te doen, skep die wikkelskrip 'n merkerlêer langs die ooreenstemmende bewaarplek. Die laaste rugsteun wat gemaak is, word outomaties na die ooreenstemmende logiese volume herstel nadat die data-invulproses voltooi is.
Hierdie ontwerp laat jou toe om periodiek onnodige rugsteun skoon te maak, en voorkom ook dat gevegsbedieners enigiets op die rugsteunbergingbediener uitvee.
Rugsteun proses
Die inisieerder van die rugsteun is die toegewyde bediener of VPS self, aangesien hierdie skema meer beheer oor die rugsteunproses aan die kant van hierdie bediener gee. Eerstens word 'n momentopname van die toestand van die aktiewe wortellêerstelsel geneem, wat met BorgBackup gemonteer en opgelaai word na die rugsteunbergingbediener. Nadat datavaslegging voltooi is, word die momentopname ontkoppel en uitgevee.
As daar 'n klein databasis is (tot 1 GB vir elke werf), word 'n databasisstorting gemaak, wat in die toepaslike logiese volume gestoor word, waar die res van die data vir dieselfde werf geleë is, maar sodat die storting nie toeganklik deur die webbediener nie. As die databasisse groot is, moet jy "warm" dataverwydering konfigureer, byvoorbeeld deur xtrabackup vir MySQL te gebruik, of met WAL met archive_command in PostgreSQL werk. In hierdie geval sal die databasis afsonderlik van die werfdata herstel word.
As houers of virtuele masjiene gebruik word, moet jy qemu-guest-agent, CRIU of ander nodige tegnologieë opstel. In ander gevalle is bykomende instellings meestal nie nodig nie - ons skep bloot momentopnames van logiese volumes, wat dan op dieselfde manier verwerk word as 'n momentopname van die toestand van die wortellêerstelsel. Nadat die data geneem is, word die foto's uitgevee.
Verdere werk word op die rugsteunbergingbediener uitgevoer:
- die laaste rugsteun wat in elke bewaarplek gemaak is, word nagegaan,
- die teenwoordigheid van 'n merklêer word nagegaan, wat aandui dat die data-insamelingsproses voltooi is,
- die data word uitgebrei na die ooreenstemmende plaaslike volume,
- die merkerlêer word uitgevee
Bedienerherstelproses
As die hoofbediener sterf, word 'n soortgelyke toegewyde bediener geloods, wat vanaf een of ander standaardbeeld begin. Heel waarskynlik sal die aflaai oor die netwerk plaasvind, maar die datasentrumtegnikus wat die bediener opstel, kan hierdie standaardbeeld onmiddellik na een van die skywe kopieer. Die aflaai vind plaas in RAM, waarna die herstelproses begin:
- 'n versoek word gerig om 'n bloktoestel via iscsinbd of 'n ander soortgelyke protokol aan 'n logiese volume te heg wat die wortellêerstelsel van die afgestorwe bediener bevat; Aangesien die wortellêerstelsel klein moet wees, moet hierdie stap binne 'n paar minute voltooi word. Die selflaaiprogram word ook herstel;
- die struktuur van plaaslike logiese volumes word herskep, logiese volumes word vanaf die rugsteunbediener aangeheg deur die dm_clone kernmodule te gebruik: dataherwinning begin, en veranderinge word onmiddellik na plaaslike skywe geskryf
- 'n houer word geloods met alle beskikbare fisiese skywe - die bediener se funksionaliteit is ten volle herstel, maar met verminderde werkverrigting;
- nadat datasinchronisasie voltooi is, word die logiese volumes van die rugsteunbediener ontkoppel, die houer afgeskakel en die bediener herlaai;
Na 'n herlaai, sal die bediener al die data hê wat daar was toe die rugsteun geskep is, en sal ook al die veranderinge insluit wat tydens die herstelproses gemaak is.
Ander artikels in die reeks
Rugsteun Deel 7: Gevolgtrekkings
Ek nooi jou uit om die voorgestelde opsie in die kommentaar te bespreek, dankie vir jou aandag!
Bron: will.com