Uues Me rääkisime teile uutest funktsioonidest, mis ilmusid jaanuaris välja antud Update 4 jaoks Veeam Backup & Replication 9.5 (VBR), kus me teadlikult ei maininud magnetlintidel tegemisi. See teema väärib eraldi artiklit, sest uusi funktsioone oli tõesti palju.
– Kas QA kutid kirjutavad artikli?
– Miks mitte!
Lintide salvestamine XXI sajandil
Andmete salvestamine magnetlintidel (kasettides, "lindid", nagu me neid R&D-s nimetame) ei piirdu minevikus elanud arvutiga ZX-Spectrum, mille ühe mängu laadimine võis võtta mitu minutit 48 kb häälestusega Kümmekond aastat tagasi olid kogused ja kiirus suurenenud 6-7 korda. See ei ole kõige sobivam võrdlus ja standard ei ole juba ammu jõudnud. Sellegipoolest, kaasaegsed tehnoloogiad võimaldavad salvestada ühe kaseti peale 12 terabaiti andmeid (kuni 30 terabaiti kokkusurutud režiimis), mistõttu 160 dollari maksva seadmest saab konkurentidest odavam pikaajaline andmehoidmine, isegi arvestades seadmete investeeringuid salvestamiseks/ lugemiseks. Andmed sellistel lintidel säilivad usaldusväärselt 15-30 aastat.
Vaatame teise nurga alt. Viimasel ajal on saavutanud uue taseme. Nad võivad oodata oma aega suure ettevõtte infrastruktuuris nädalaid ja kuid ning uue nullpäeva haavatavuse ilmnemisel võivad nad (inimese abiga, sest sees on suured summad) hävitada mitte ainult kõik andmed, vaid ka kõik varukoopiad, millele ainult ligi pääseb. Siis pidid ettevõtted maksma lunavaravatele. Nii-öelda air gap, st füüsiliselt infrastruktuurist isoleeritud varukoopiad on tõesalt ainus usaldusväärne päästmine selliste olukordade eest. Magnetlint selles osas on üks ajatu lahendus.
Kuid üksnes spetsifikatsioon ja tehnilised uued barüüri- ja ferritlahendused juhtivatelt tootjatelt (IBM, HPE, Oracle, Dell) ei ole piisavad andmete usaldusväärseks kaitseks, vaja on head tarkvara. Meil on Veeam'is terve meeskond, kes tegeleb lintide varukoopiate tegemisega, umbes 10 inimest analüüsib, kavandab, uurib, arendab ja testib iga päev. Te võisite seda tööd eelnevates artiklites näha (, ). Mis on viimase aasta jooksul tehtud?
Glossaar
Tõusetub valik emakeele vabaduste ja arusaamatuks tegevate bürokraatlike killustike vahel. Eelistangi esimest, mistõttu palun juba ette vabandust, kui allolev žargooniriim kellelegi silma riivab. Siin tuletan lühidalt meelde, mida mõni või teine termin tähendab.
VBRi gurud saavad selle osa vahele jättaJob – töö – varundamise ülesanne. Tegelikult koosneb kogu VBR töödest. Lisaks varundamisele ja replikatsioonile võib see olla ka andmete kopeerimine magnetlintidele (backup to tape job, lint-job). Tahan märkida, et varundusest taastamine (restore) – on samuti töö, kuid selles artiklis mõistetakse selle sõna all ainult varundust.
Storage – hoiustamine – ajalooliselt kujunenud nimetus. Need on failid hoidlad (repository – hoidla), mis sisaldavad endas varukoopiaid – täielikke ja incremental. Ühes hoidlasse võib olla nii üks kui mitu virtuaalset masinat.
Ahel – chain – omavahel seotud hoidlade järjestus. Andmete taastamiseks n-ndast inkrementaalsest hoidlast on vajalikud kõik eelnevad (n-1) kuni 1. ja täielik hoidla, millele viitab esimene inkrementaalne.
Source, Target – source, target. Source – algne entiteet, mida töö käsitleb. Varunduste/replicate'ide puhul on see tavaliselt virtuaalne masin hüperviisoril. Lint-töö puhul on source ise varundamise töö (kas ka failide puhul file to tape-job). Target varundustöö jaoks on hoidla, kus varundused asuvad. Lint-töö puhul on see media pool.
Media pool – – teabe kandjate pool, meie juhul – kassettide. Loogiline konteiner, mille kasutaja loob ja mis sisaldab kassette ühest või mitmest raamatukogust. Seega on lint-töö alati media pool'i sihtpunktina, st andmed ei kirjutata mitte konkreetsesse kassettisse ega ka mitte ükskõik millisesse raamatukogusse, vaid teatud komplekti kassettidesse. Media pool'il on andmete säilitamise kestuse seadistus, mille möödudes kassett võib olla üle kirjutatud. Kasutaja võib luua tavalisi (standard) ja . Igal neist liikidest võib olla nüüd ka WORM ja mitte-WORM, sellest allpool.
Media set – – kassettide komplekt meediahunnikus, kuhu kirjutatakse pidevalt varukoopiad/failid. GFS-poolide meediahunnikud on samuti seotud ajavahemikuga (näiteks aastane – yearly), kassette vahetatakse vaid oma ajavahemiku sees.
– teipi raamatukogu elemendid. Drive loeb ja kerib kassetti, changer – see on robot, joka liigutab kassetid salvestamise slotide, laadimis slotide ja draivi vahel. On ka standalone-draivid (standalone – eraldi asuv), milles changer'i rolli täidab inimene. Draivi jaoks on vajalik, et tootja draiver oleks õigesti paigaldatud Windows-masinasse, kuhu on ühendatud raamatukogu; changer'iga saame töötada ka ilma draiveriteta, kasutades native SCSI'd.
Tenant to tape. Kaitstud teenusepakkuja – kaitstud kliendid
Kohe trumpf lauale. Meie uuenduse kõige mahukam funktsioon, mis on suunatud , kes kasutavad oma infrastruktuuris VBR-i. Arendus algas juba kaks aastat tagasi. Varsti mõistsime, et sellise tõsise ülesandega lähiaja väljaande tähtaega ei täida, võtsime väikese pausi ja lõpuks vabastasime funktsiooni 9.5 Update 4.
Lühidalt, nüüd on teenusepakkujatel võimalus kopeerida oma klientide varukoopiaid kassetti GFS-poolis kasutades teipi töö. See annab teenusepakkujatele – ja need on meie südamele ja kommertsbüroole väga kallid suured poisid – kaks võimalust:
- kaitsta oma kliente (tenantid, tenant – üürnik) andmete kaotuse vältimiseks, mis põhjustatud kogemata kustutamisest või infrastruktuuri probleemidest ("tulv serveriruumis");
- pakkuda tenantidele täiendavat teenust andmete taastamiseks vanast varukoopiast, mis on juba ammu kustutatud pilverepositooriumist vastavalt andmete säilitamise poliitikale, kuid kassetil on need siiski alles.
Turunduse seisukohalt on funktsionaalsus väga "maitsev", meie jaoks aga – mitte vähem keeruline ellu viia.
Arendus
Peamine probleem, mis tõusis – andmete krüpteerimine. Enamus pilve varukoopiaid on krüpteeritud, statistika ütleb, et ⅔ koguarvust. Meie jaoks oli see number üllatus, arvasime, et enamus on krüpteeritud, kuid ei – paljusid kliente tundub, et nad usaldavad oma teenusepakkujaid tingimusteta.
Paradigma on lihtne: teenusepakkuja ei tohiks olla suuteline oma klientide andmeid dekodeerima. Samas on uue funktsiooni raames teenusepakkuja poolel vajalik avada salvestusi, kus on varukoopiad. See on vajalik andmeplokkide edasiviimiseks, näiteks loomise jaoks . Peamine on see, et seda tuleb teha sõltumatult kliendist, kui vajalikud võtmed ei edastata teenusepakkuja poolele töö tegemise ajal.
Selle probleemi lahendus, mis on muide kaasatud ka teise olulise funktsiooni, mis tuli välja lisandmooduliga – – seisneb täiendava krüptimisvõtme lisamises. Arhiivivõti (Archive key) hoitakse teenusepakkuja andmebaasis krüptitud kujul. Nutika skeemi abil teenusepakkuja poolel on võimalik selle abil avada salvestus, liikuda ja uuesti krüpteerida andmeplokke salvestuste vahel (sest igal on oma võti), kuid ei saa andmeid dekodeerida.
Nutikas skeem (töötav variant)
Lisaks tahan öelda, et kõik insenerid R&D-s armastavad meie tootes krüptimist, tõsi, keegi ei tea kõiki detaile, kuidas see töötab. (Siin oli veel nali „ja miks see üldse töötab”, kuid toimetajad ei lubanud seda.)
Testimine
Selle funktsiooni kohta on kirjutatud sadu vigu. Kõige keerulisemad valdkonnad on krüptimine, kasutajaliides, probleemid taastamisel.
Testimise seisukohalt esitas suure keerukuse variatiivsus, „kombinatoorika” tüübid ja tüübid klienditööd ja hoidlatest – mõtlen nii allikate kui ka sihtkohtade kohta varukoopiate taastamisel infrastruktuuris. Kõik see on seotud GFS Testplaani fragment
Tulemuseks
Üksikasjaliku kirjelduse leiate
(hetkel inglise keeles): varukoopia , Teenusepakkuja lisab kliendid GFS-puuli tüübi tööle eesmärgina. Pilve litsentsi olemasolul on nõidus samas sammul saadaval valik
Varukoopia
Tenants TenantsSaab on võimalik lisada kõiki teenuseid korraga või eraldi, samas võib valida ka ainult eraldi kvota (kuid mitte alamkvota) eraldi teenuse jaoks. Ühe tööülesande jooksul ei saa segada teenuste varukoopiaid ja tavapäraseid kohalikke varukoopiaid.
Ülejäänud seaded on peaaegu täielikult identsetes nagu tavalises tööülesandes GFS-poolis.
Andmete taastamine on võimalik nii teenusepakkuja kui ka teenuse enda poolel.
Taastamine teenusepakkuja poolel
Teostatakse uue nõustaja kaudu. Siin on võimalik minna ka madalamale tasemele, taastatakse täielikult teatud päeval hoidlas olev ahel.
On kolm taastamisvõimalust:
- Algse asukoha. Sel juhul, kui originaalvarukoopia on olemas, kustutatakse see; teenuse tööülesanded seadistatakse automaatselt taastatud ahela suhtes. Eeldatakse, et selline taastamine on kliendile täiesti märkamatuks, vaid lühikest aega on ta ühendusest pilvehooldusteenusest lahti.
- Uude kvotasse/hoidlasse. Teenusepakkuja võib näiteks luua selleks eraldi ajutise konto, mille hiljem kustutab. Varukoopia ilmub teenuse struktuuris pärast sünkroonimist teenusepakkuja andmebaasiga.
- Lihtsalt Linuxi- või Windowsiserveri kettale, mis on registreeritud teenusepakkuja struktuuris. Edasi saab selle ahelat salvestada mälupulgale ja saata teenusele.
Taastamine teenuse poolel
See valik eeldab, et kliendil on oma kasseti infrastruktuur ja suur andmemaht taastamiseks. Teenusepakkuja võib füüsiliselt saata kliendile kasseti, millel on salvestatud varukoopiad, klient katalogiseerib selle oma seadmetes, dekrüpteerib kassette ja varukoopiaid ning töötab varukoopiate kallal nagu oleks ta need ise lindile salvestanud. Selline näpunäide, et mitte laadida terabaite WAN-is.
Mõjukaid parandusi GFS-poolis
-meedia-poolid ilmusid VBR-s kaks aastat tagasi versioonis 9.5. Viimases värskenduses, seoses funktsiooniga Tenant to tape ja kasutajate soovi korral, oleme selle funktsionaalsuse hästi optimeerinud.
Iga päev meedia komplektid
On ilmunud uus igapäevane (daily) meedia-set. Nüüd saab GFS-poolis hoida varukoopiaid igapäevaselt, mitte ainult täis, vaid ka inkrementaalseid. Viimased võtavad oluliselt vähem ruumi ja see on tehtud lintide säästmise eesmärgil. Eeldatakse, et need kassettid rotatsioonivad pidevalt teegis, mitte ei viida eemal hoidmisse. Selleks, et taastada inkrementaalne punkt, on restoranist vaja kassetti mõnest vanemast meedia-setist (nädalasest, kuisest, kvartaalsetest või aastasest). Igapäevase meedia-seti aktiveerimine ilma nädalase aktiveerimata ei ole võimalik, et enamikul juhtudel oleks taastamiseks vajalikud just nädalased kassettid. Need on kas alati teegis või hoitakse mitte liiga kaugel asuvas laos.
GFS-meedia-poolis tape jobi töölogika , tehnilised kirjanikud ei lase seda valeks muutuda. Kui öelda kahe sõnaga, jättes detailid kõrvale, siis nädalastesse ja vanematesse meedia-setidesse kopeeritakse ainult täis varukoopiad (sealhulgas virtuaalsed täis varukoopiad), üks iga kuupäeva lõikes, ja igapäevasesse - kõik, mis on hoidlas oleva päeva jooksul, sest varukoopia jobi võib käivituda sagedamini kui kord ööpäevas.
Paralleelsus, GFS-poolide algusajad ja ootamine
Nüüd on mitme ahela või töö käivitamine mitmetel teegi draividel võimalik ka GFS-meedia-poolides (varem ainult tavalistes). See aktiveeritakse sammus Valikud meedia-poolis.
Important clarification: sama faili kirjutatakse alati ühte voogu, seetõttu on soovitatav, et mitme suure virtuaalse masina korral aktiveerige , et varukoopia koosneks mitmest ahelast.
Lisaks on võimalik valida GFS-jobi algusaega. Paljudele kasutajatele ei meeldinud kesköö käivitamine ja sellele järgnev ooteaeg peaaegu kogu päeva, kuni allika job lõpeb. Nüüd saab seda aega näiteks seada hiliseks õhtuks, kui on juba midagi lintile kopeerida. Veelgi enam, kasutajate soovide põhjal tõime laiendatud seadistustesse välja võimaluse, mida varem sai aktiveerida ainult registrivõtme kaudu. Piisab valida Käsitle kõige uuemat taastamispunkti, mitte ootamist – ja kassettile kopeeritakse see, mis on hoidlas sel hetkel, kui tape job alustab (punkt eelmise päeva kohta, näiteks), ootamine puudub täielikult.
Täiustatud töö mitme raamatukoguga
Juttu tuleb olukorrast, kus ühte meediaava lisatakse rohkem kui üks raamatukogu. Oleme seda varem toetanud, kuid aeg-ajalt on kliendid kaebanud ettenägematute käitumiste üle.
See oli
Näiteks, kui käivitub tape-job ja see kasutab esimeses raamatukogus kahte draiverit, kuid parallaliseerimise seaded võimaldavad tal kasutada korraga 4 draiverit. Kas peaks see töö minema teise raamatukogu meediaavas kasutamiseks või oleks see ressursi liigne kasutamine?
Teine juhtum. Valitud on tingimuslülitamine „ei ole saadaval kassette”, esimeses raamatukogus on ainult üks kassett, kuid sellele saab potentsiaalselt mahutada kõik andmed. Siiski, seadistused võimaldavad samal ajal kirjutada kahte kassetti. Kas peaksime sel juhul teise raamatukogu kaasama?
Otsustasime selle ala korda seada, andes võimaluse käitumist selgelt seadistada.
Muutus
on nüüd rollid – aktiivne ja passiivne. Ja meediaava enda jaoks – kaks režiimi: tõrkekindel, või failover (failover) ja paralleelne kirjutamine (paralleling). Nüüd, sõltuvalt nõudmistest, saab meediaava seadistada erinevalt.
- Kui teil on mitu võrdselt õigustatud raamatukogu ja on vajalik kirjutamise paralleeliseerimine – aktiveerige paralleelse kirjutamise režiim, selleks tuleb kõigile raamatukogudele määrata aktiivsed rollid. Sellisel juhul võetakse uued kassettid ja draiverid kohe kasutusele, kui sellele on vajadus, olenemata sellest, millises raamatukogus nad asuvad. Prioriteet siiski on – esialgu proovime leida ressursse raamatukogust, mis asub loendis kõrgemal.
- Kui aga on üks peamine raamatukogu ja üks vana või seisev draiver varus, aktiveerige tõrkeülesannete režiim, asetades peamise raamatukogu loendi tippu ja valides passiivse rolli varude seadmete jaoks. Üleminek sellele seadmele toimub ainult siis, kui see tõeliselt vajalik, et töö saaks siiski kuidagi toimida. Selline olukord loetakse hädaolukorraks, millest saadetakse teavitus e-postile.
On arene keerulisem olukord, mida me seni ei toeta – mitu aktiivset teeki, kui on passiivsed. Tagasiside näitab, kas selliste konfiguratsioonide jaoks on vajadus ja kas on vaja selle funktsiooni tulevikus täiustada. Tavaline praktika.
WORM-i tugi
WORM – Write Once Read Many – kassett, mida ei saa kustutada või uuesti kirjutada , saab ainult andmeid juurde kirjutada. Nende kohustuslik kasutamine on reguleeritud mõnedest organisatsioonidest, näiteks meditsiinivaldkonnas töötavatest. Peamine probleem selliste kassettide puhul oli varem see, et VBR või salvestas pealkirja, mille hiljem ei saanud kustutada, ja teipiöid kukkusid sellise katse korral veaga.
Versioonis 9.5 Update 4 on täielik toetus sellistele kassettidele. On lisatud WORM meedia basseine, tavapärane ja GFS, kuhu saab paigutada ainult sellist tüüpi kassette.
Uutel kassettidel on sinine, "külmutatud" ikoon. Kasutaja vaatenurgast erineb töö WORM-kassettide kasutamisest tavalistega.
Kassettide "worminess" määratakse alguses baaride järgi , kui baarikoodid on tavalised või loetamatud, annab teavet draiver esimese kasseti sisestamise ajal. WORM-kassette ei saa paigutada tavalisse meedia basseini ja neile kirjutada. Huvi pärast: juba on leidunud kasutajaid, kes on liiminud WORM-barkoodid tavalistele kassettidele ja üllatunud muutustest oma infrastruktuuris pärast uuendamist.
Kasseti tšipp
Koos kirjutatavate kassettide sisestamisega hakati töötama Tavapäraseid atribuutide tšipis ei ole me varem kasutanud, praegu kirjutame ja loeme mõnda, kuid ei käsitle seda peamise andmeallikana. Peamine orientiir on endiselt kasseti pealkiri. See lahendus osutus õigeks: kuu aega pärast väljaandmist näeme, kuidas kasutajate "loomaaed" riistvarast toob tšipiga töötamisel üllatusi.
NDMP-mahu varundamine lintidele
Kokkuvõtteks – kõige nõutuma funktsiooni kohta, kui palju tagasisidet selle versiooni kohta on. NDMP-mahu varundamine kassettidele on nüüd saadaval. VBR-infrastruktuuri tuleb , pärast mida saab failide taustatöödel valida selle hosti mahtu. Need salvestatakse lindile failide vormis, millel on eriline atribuut, et neid eristada tavalisest kataloogis.
Esimeses versioonis on teatavad piirangud: laiendusi ei toetata, pluss on võimalik varundamine ja taastamine ainult täismahust, mitte eraldi failidest. Varundamine töötab läbi (NetAppi puhul – ), siin on omad eripärad: maksimaalne säästlike punktide arv – 9, pärast mida sunnitakse täielikku varukoopiat.
Kokkuvõtteks
Need olid kõige olulisemad uuendused magnetlindile varundamises VBR 9.5 Update 4-s. Üksikasjalikumad muudatused toome loetelu näol:
- võimalus määrata allikate tööde ja failide järjekord linditöödel;
- lisatud Tape Operator roll (kasutaja saab teha kõike, välja arvatud taastamine lindilt – selleks on Restore Operator);
- täiendatud täielike include/exclude-maske failide linditöös (välja arvatud NDMP);
- täiendatud taastamist failide linditöös (kaust taastatakse nende failidega, mis seal olid varundamise hetkel, mitte kõigi, mis kunagi seal olnud – väga nõutud funktsioon, muide);
- suurendatud väga suure arvu failide taastamise kiirus lindilt;
- täiendatud algoritmi järgmise lindiga kirjutamiseks, eriti sama võrdsed tingimused, arvestades kogu selle eluea jooksul kirjutatud/loetud andmete mahtu, võtame kõige värskema;
- parandatud toote stabiilsust.
Kasulikud lingid
Mugavuse huvides toome välja ka mõned lingid venekeelsetele ressurssidele:
- Ja oleme tagasi esialgsesse kohta ülevaatevideod "Kuidas see töötab" (kuigi praegu inglise keeles) – saab vaadata . Lindidest räägitakse slaididel 95 – 102.
Allikas: habr.com
