V eelnevas artiklis Oleme rääkinud teile uutest funktsioonidest, mis ilmusid jaanuari värskenduses Update 4 Veeam Backup & Replication 9.5 (VBR), kus me teadlikult ei maininud magnetlintidega varukoopiaid. Sel teemal tasub kirjutada eraldi artikkel, sest uusi funktsioone oli tõeliselt palju.

– QA poisid, kirjutate artikli?
– Miks mitte!

Lintdraivid XXI sajandil

Andmete salvestamine magnetlintidele (kassettidele, „lintidele“, nagu me R&D-s neid kutsume) ei piirdu vaid minevikus olnud ZX-Spectrum arvutiga, mille jaoks üks mäng laadis operatiivmälu 48 kB-st magnetkassettidelt mitu minutit. Kahekümne viie aastaga on kassettide kiirus ja maht kasvanud 6-7 korda. See ei ole täiesti korrektne võrdlus, ja vastavalt Moore'i seadusele standard LTO ei suuda sammu pidada. Siiski, tänapäeva tehnoloogiad võimaldavad ühe kasseti kilomeetrisele lindile salvestada 12 terabaiti andmeid (kuni 30 terabaiti kompressioonirežiimis), seega 160-dollariline salvestusseade jätab konkurendid kaugele maha, kui arvestada suurte andmemahtude pikaajalise säilitamise kulusid, kaadritest ja lugemisseadmest investeerimist. Sellistele lintidele salvestatud andmed säilivad usaldusväärselt 15–30 aastat.

Vaatan teise nurga alt. Viimasel ajal lunavariandid on saavutanud uue taseme. Nad võivad oodata oma aega suure ettevõtte infrastruktuuris nädalate ja kuude kaupa, ning kui ilmneb uus nullpäevahaav, saavad nad hävitada (mitte ilma inimeseta, sest mängus on suured rahad) mitte ainult kõik andmed, vaid ka kõik varukoopiad, mis on vaid käeulatuses. Siin on värske näide, kui ettevõte pidi maksma lunavaras. Nii-öelda õhustiku tühjendamine, st füüsiliselt infrastruktuurist eraldatud varukoopiad on saanud sisuliselt ainukeseks usaldusväärseks päästmiseks sellistes olukordades. Magnetlint siin on üks ajale vastu pidavaid lahendusi.

Kuid ainult spetsifikatsioon ja tehnilised uuendused juhtivatelt tootjatelt (IBM, HPE, Oracle, Dell) ei piisa andmete usaldusväärseks kaitsmiseks, vajalik on ka hea tarkvara. Meil on Veeamis terve meeskond, kes tegeleb lintide varukoopiate loomisega, umbes 10 inimest analüüsib, planeerib, uurib, arendab ja testib igapäevaselt. Selle töö tulemusi olete võinud näha varasemates artiklites (kord, kaks). Mida on viimase aasta jooksul tehtud?

Glossaar

Tõusetub valik emakeele suhtes lubaduste ja lugemise keerulisust suurendavate bürokraatlike väljendite vahel. Eelistan esimest, seetõttu palun ette vabandust, kui kellelegi allpool olevast sõnavarast rakenduskeel silma häirib. Siin tuletan lühidalt meelde, mida mõni termin tähendab.

VBRi ekspertidel võib see osa jääda vaheleJob – job – varukoopiate tegemise ülesanne. Tõeliselt põhineb kogu VBR töö ülesannete peal. Lisaks varukoopiatele ja replikatsioonile võib see olla ka andmete edastamine magnetkettale (backup to tape job, tape job). Rõhutan, et varukoopiast taastamine (restore) on samuti ülesanne, kuid käesolevas artiklis mõistetakse selle all just varukoopiat.

Storage – storage – ajalooliselt kujunenud nimetus. Need on failid, mis asuvad repositoriis (repository – hoidla), sisaldavad varukoopiaid – Täielikud ja inkrementaalsed. Ühes storage'is võib olla nii üks kui ka mitu virtuaalmasinat.

Ahel – chain – järjestikune seotud storage'ite kogum. Andmete taastamiseks n-ndast inkrementaalsest storage'ist on vajalikud kõik eelnevad (n-1)-st esimeseni ja täielik storage, millele viitab esimene inkrementaalne.

Allikas, siht – source, target. Allikas – algne entiteet, mida töötlus käitab. Varukoopiate/replikate puhul on see reeglina virtuaalmasin hüperviisoris. Tapes-job'i puhul on allikaks ise backup-job (või failid 'file to tape' job'i puhul). Siht backup-job'i jaoks on hoidla, kus varukoopiad asuvad. Tapes-job'i puhul on see meedia-basaar.

Meedia-basaar – media pool – andmete salvestamise jõud, meie puhul – kassettide kogum. Loogiline konteiner, mille kasutaja loob ja mis sisaldab ühe või mitme raamatukogu kassetti. Seega on tape job alati suunatud meedia puule, see tähendab, et andmed ei salvestata mitte mingile konkreetselt kassettile ega ka kõigile kassettil raamatukogus, vaid kindlale komplektile. Meedia puul on seadistus andmete säilitamise ajaks, mille möödudes kassett võib uuesti üle kirjutada. Kasutaja saab luua tavalisi (standard) ja GFS-poolid. Igal neist liikidest võib nüüd olla ka WORM ja mitte-WORM, sellest allpool.

Meedia komplekt – media set – kassetid meedia puus, millele kirjutatakse pidevalt varukoopiaid/faile. GFS-poolide jaoks on meedia komplektidel ka seos ajavahemikuga (näiteks aastane – yearly), kassetid rotatsioonivad ainult oma ajavahemikus.

Draiv, vahetaja – tape-raamatukogu elemendid. Draiv loeb ja kerib kasseti, vahetaja – see on robot, mis liigutab kassetid ladustamise, laadimise ja draivi slotide vahel. On ka iseseisvad draivid (standalone – eraldi seisev), siin täidab muundurina funktsiooni inimene. Juhtme ühendamiseks on vajalik korrektselt paigaldatud tootja draiver Windows-masinas, kuhu on ühendatud teek; muunduriga saame töötada ka ilma draiveriteta, native SCSI kaudu.

Tenant to tape. Teenusepakkuja on kaitstud – kaitstud on kliendid.

Kohe tõsised eelised lauale. Meie värskenduse kõige ulatuslikum funktsioon, mis on loodud pilveteenuse pakkujatele., kes kasutavad oma infrastruktuuris VBR-i. Arendus algas juba kaks aastat tagasi. Varsti saime aru, et sellise tõsise ülesandega läheme järgmise väljaandeni õigeks ajaks mitte joonde, võtsime väikese pausi ja lõpuks soovitud funktsiooni välja 9.5 värskenduses 4.

Lühidalt öeldes, on nüüd teenusepakkujatel võimalus kopeerida oma klientide varukoopiaid kassettidele GFS-grupi tape-job'i abil. See annab teenusepakkujatele – ja need on meie südamele ning kaubandusosakonnale väga kallid suuremad mängijad – kaks võimalust:

• kaitsta oma kliente (tenantid, tenant – üürnik) andmete kaotuse eest juhusliku kustutamise või infrastruktuuri probleemide tõttu ("üleujutus serveriruumis");
• pakkuda klientidele lisa teenust andmete taastamiseks vanast varukoopiast, mis on juba ammu hävitatud pilverepositooriumist vastavalt andmete salvestamise poliitikale, kuid kassettidel on endiselt alles.

Turunduse seisukohalt on funktsionaalsus väga "maitsev", meie jaoks aga - mitte vähem keeruline rakendada.

Arendus

Peamine probleem on andmete krüpteerimine. Enamik pilvevarukoopiaid on krüpteeritud, statistika ütleb umbes ⅔ kogu arvust. Meie jaoks oli see number üllatus, arvasime, et enamus on krüpteeritud, aga ei - paljud kliendid näivad olema oma teenusepakkujatesse absoluutselt kindlad.

Paradigma on lihtne: teenusepakkuja ei tohiks õigustada oma klientide andmeid. Samas, uue funktsiooni raames tuleb teenusepakkujal avada varukoopiatega salvestused. See on vajalik, et andmeplokke liigutada, näiteks täieliku virtuaalse varukoopia loomiseks. täieliku virtuaalse varukoopia. Peamine on, et seda tuleb teha sõltumatult kliendist, kui vajalikud võtmed ei edastata teenusepakkujale töö ajal.

Selle probleemile lahenduse leidmine, mis on muide oluline ka teises selle olulise funktsiooni osas, mis välja lastud lisandmoodul — Capacity Tier – seisneb täiendava krüpteerimisvõtme lisamises. Arhiivivõti (Archive key) hoitakse pakkuja andmebaasis krüpteeritud kujul. Pakkuja pool lõhestatud skeemi abil saab selle abil avada salvestusruumi, liigutada ja krüpteerida andmeplokke salvestuste vahel (kuna igal ühel on oma võti), kuid andmeid ei saa dekrüpteerida.

Lõhustatud skeem (töötav variant)

Lisaks, kõik R&D insenerid armastavad meie toote krüpteerimist, kuna keegi ei tea üksikasjalikult, kuidas see töötab. (Siin oli veel nali 'ja miks see üldse töötab', kuid toimetajad ei lasknud seda läbi.)

Testimine

Funktsiooni kohta on registreeritud sadu vigu. Kõige keerulisemad valdkonnad on krüpteerimine, kasutajaliides, taastamistsükli probleemid.

Testimise seisukohalt koosnes raskus suurest varieeruvusest, tüübi ja tüüpi tenantide tööde ja hoidlate 'kombinatoorikast' — silmas pean nii allikat kui ka sihtkohta, kui varukoopiate taastamine infrastruktuuri. Kõik see on seotud loogikaga raamistikus GFS mudel (sealatud uue – paralleelsus ja igapäevased meedia komplektid, selgitame allpool), samuti harjumatutele pilvekeskuste spetsifikatsioonidele. Ärge unustage seda tugevalt krüpteerida. Kui jätkata metafoori, oleme selle rooga korralikult üle söönud – kuid oleme seda ka igast küljest maitsta saanud.

Testplaani fragment

Tulemus

Üksikasjalikku kirjeldust leiate kasutajajuhendist (praegu inglise keeles): varukoopia, taastamine. Jätan siinkohal peamised punktid.

Varukoopia

Teenusepakkuja lisab kliente teip-tööle GFS-pooli sihtmärgina. Kui olemas on pilveluba, on wizardi teisel sammul saadaval valik Kliendid. Saate lisada kõik kliendid korraga või eraldi, samuti saate valida vaid teatud kvota (aga mitte alamkvota) eraldi kliendi jaoks. Erakliendi varukoopiaid ja tavalisi kohalikke ei saa sama töö puhul segada.

Ülejäänud seaded on peaaegu täielikult identsete tavalise tööga GFS-pools.

Andmete taastamine on võimalik nii teenusepakkuja kui ka kliendi enda poolel.

Taastamine teenusepakkuja poolel

Teostatakse uue viisi abil. Siin on võimalik minna eraldi ülesande juurde, taastatakse täielikult ahel, mis oli teatud päeval hoidlas.

Kolm restorani varianti:

1. Originaal asukohta. Sellisel juhul eemaldatakse, kui see on olemas, originaalne varukoopia; rendi ülesanded seadistatakse automaatselt taastatud ahela peale. Eeldatakse, et selline taastamine jääb kliendile praktiliselt märkamatuks, vaid lühikese aja jooksul on see ühendatud pilvehoidla kaudu välja lülitatud.
2. Uude kvooti/hoidla. Teenusepakkuja võib näiteks luua sel eesmärgil eraldi ajutise konto, mille ta hiljem eemaldab. Varukoopia ilmub rendi infrastruktuuri pärast sünkroniseerimist teenusepakkuja andmebaasiga.
3. Lihtsalt Linuxi- või Windowsi-serveri kettale, mis on registreeritud teenusepakkuja infrastruktuuris. Edasi saab selle ahela salvestada mälupulgale ja saata rentnikule.

Taastamine rendi poolel

See valik tähendab, et kliendil on oma tape-infrastruktuur ja suur andmemaht restoraniks. Teenusepakkuja võib füüsiliselt saata kliendile salvestatud varukoopiate kasseti kullerteenuse kaudu. Klient katalogiseerib selle oma seadmetes, dekrüpteerib kassette ja varukoopiaid ning töötab nende varukoopiaitega, nagu oleks ta need ise lindile salvestanud. Selline nipi, et vältida terabaitide laadimist WAN-i kaudu.

Mastaapsed täiustused GFS-pooles

GFS-meedia-poolid ilmusid VBR-is kaks aastat tagasi versioonis 9.5. Värskenduses, seoses Tenant to tape funktsiooni ilmumisega ja kasutajate soovide tõttu, oleme selle funktsionaalsuse tõeliselt üles töötanud.

Igapäevased meedia-setid

Ilmunud on uus igapäevane (igapäevane) meedia-seade. Nüüd on GFS-pool võimalik salvestada varukoopiaid iga päeva kohta, ja mitte ainult täis, vaid ka inkrementaalseid. Viimased võtavad oluliselt vähem ruumi ning see on tehtud ribade säästmise eesmärgil. Eeldatakse, et need kassettid pöörlevad pidevalt raamatukogus, mitte ei viida eemal säilitamisele. Samuti on restorani inkrementaalse punkti jaoks vajalikud üks kassett vanema meedia-seadmest (nädalane, kuine, kvartaline või aastane). Igapäevase meedia-seadmest aktiveerimine ilma nädalase aktiveerimiseta ei ole võimalik, et enamikul juhtudel oleks taastamiseks inkrementaalsest koopiast vajalikud just nädalased kassettid. Need kas on alati raamatukogus või on need hoitud mitte nii kaugel asuvas laos.

Tape-jobi tööloogika GFS-meedia-pools ei ole kõige lihtsam, tehnilised kirjanikud ei vea alt. Kui öelda kahel sõnal, ilma detailideta, siis nädalase ja vanemate meediahulkade puhul kopeeritakse ainult täisvarukoopiad (sh virtuaalsed täisvarukoopiad), üks iga kuupäeva jaoks, ja igapäevases - kõik varukoopiad, mis on hetkel olemas hoidlas, kuna varukoopia töö võib käivituda sagedamini kui üks kord päevas.

Paralleelsus, käivitusaeg ja ooteaeg GFS-poolides

Nüüd on mitme ahela või töö paralleelne kirjutamine mitmest teegidraivist võimalik ka GFS-meediahulkades (varasemalt - ainult tavapärastest). See aktiveeritakse järgus Valikud meediahulk.

Oluline täpsustus: sama faili kirjutatakse alati ühe vooga, seetõttu on soovitatav mitme suure virtuaalmasina korral aktiveerida per-VM seadistus hoidlates, et varukoopia koosneks mitmest ahelast.

Lisaks on nüüd võimalik valida GFS-töö käivitamise aega. Paljude kasutajate arvates ei olnud südaöine käivitamine ja sellele järgnev peaaegu terve päeva ooteaeg, kuni allika töö on lõpetatud, kuigi see oli soovimatu. Nüüd on selle aja võimalik, näiteks, määrata hiliseks õhtuks, kui on juba midagi ekraanile kopeerida. Veelgi enam, kasutajate soovide põhjal oleme täiendanud seadeid, et võimaldada valikut, mida varem sai aktiveerida ainult registrivõtmega. Piisab valimisest Protsessige kõige värskemat taastamispunkti, selle asemel et oodata – ja salvestusse kopeeritakse see, mis on repoogitühi käitamise hetkel (näiteks eilne punkt), seega ei ole üldse ooteaega.

Täpsem koostöö mitme raamatukoguga

Räägime olukorrast, kus ühte meediapooli on lisatud rohkem kui üks raamatukogu. Sellist tuge oleme varem pakkunud, kuid aeg-ajalt on tulnud kliente kaebustega mitte kõige ettearvamatuma käitumise kohta.

Oli

Näiteks, käivitus töö, mis kasutas esimeses raamatukogus kahte draivi, kuid paralleelsuse seaded võimaldavad tal kasutada kohe 4 draivi. Kas peaks see töö lülituma teise raamatukogu meedia-pondile ja seda ka kasutama, või oleks see ressursside ületamine?

Teine juhtum. Valitud on võimalus lülituda tingimuse järgi «ei ole saadaval kassette», esimeses raamatukogus on vaid üks kassett, kuid sellele mahutatakse potentsiaalselt kõik andmed. Siiski võimaldavad seaded kirjutada paralleelselt kahte kassetti. Kas peaks selles olukorras teist raamatukogu kasutama?

Oleme otsustanud selle valdkonna korda teha, võimaldades seada käitumise selgelt.

Kohandatud

Raamatukogudel meedia-pondis on nüüd rollid – aktiivne ja passiivne. Ja meedia-pondil endal on kaks režiimi: talitlushäiretega, või failover (failover) ja paralleelne salvestamine (paralleling). Nüüd, vastavalt nõudmistele, saab meedia-pondi seadistada erinevalt.

• Kui teil on mitu võrdselt tähtsat raamatukogu ja on vajalik nende vahel andmete kirjutamist jagada, aktiveerite paralleelse kirjutamise režiimi, määrates kõigile raamatukogudele aktiivsed rollid. Sel juhul käsitletakse uusi kassette ja draive kohe, kui tekib vajadus, sõltumata sellest, millises raamatukogus nad asuvad. Eelis on ikka olemas – esmalt püüame leida ressursse raamatukogust, mis asub loendis kõrgemal.
• Kui aga on üks peamine raamatukogu ja üks vana või iseseisev draiv varuks, aktiveerite failover-režiimi, asetades peamise raamatukogu loendi kõige ülemisele positsioonile ja valides passiivse rolli varudraividele. Üleminek sellisele seadmele toimub ainult siis, kui see on tõeliselt vajalik, et tööülesanne saaks üldse toimida. Sellist olukorda peetakse hädaolukorraks, millest saadetakse teade e-posti teel.

On olemas keerulisem olukord, mida me praegu ei toeta – mitu aktiivset teeki koos passiivsete olemasoluga. Tagasiside näitab, kas selliste konfiguratsioonide järele on vajadus ja kas tulevikus on vaja funktsiooni täiustada. See on standardpraktika.

WORM-tugi

WORM – Write Once Read Many – kassett, mida ei saa kustutada ega üle kirjutada riistvaralisel tasandil, saab vaid andmeid juurde kirjutada. Nende kohustuslik kasutamine on ette nähtud teatud organisatsioonide regulatsioonide alusel, näiteks meditsiini valdkonnas töötavates. Peamine probleem selliste kasettidega oli varem see, et VBR inventeerimisel või kataloogimisel salvestas pealkirja, mida hiljem ei saanud kustutada, ja teipimisülesanded ebaõnnestusid sellise katse korral.

Versioonis 9.5 Update 4 on selliste kassettide täislahenduse tugi. Lisatud on WORM-meediahulki, tavalised ja GFS, kuhu saab paigutada vaid selle tüüpi kasette.

Uutel kasettidel on sinine, „külmutatud” ikoon. Kasutaja jaoks ei erine WORM-kassettide töö tavalisest tööprotsessist.

Kassettide „wormilisus” määratakse algselt nende baar-koodi suufiguuri järgi., kui baarikoodid on tavalised või raskesti loetavad, edastab teave draiver, kui kassett esmakordselt sisestatakse. WORM-kassetid ei saa tavalisse meedia puul ja neid ei saa kirjutada. Naljakas on see, et mõned kasutajad on leidnud WORM-baarikoode, mille nad on kleepinud tavalistele kassettidele, ja imestanud oma infrastruktuuri muudatuste üle pärast värskendust.

Kasseti kiip

Koos kirjutamata kassetide kasutuselevõtuga hakati tegelema kiibiga. Tavalisi atribuute kiipe ei ole varem kasutatud, praegu kirjutame ja loeme osa neist, kuid ei pea neid peamiseks andmeallikaks. Peamine orientiir on endiselt kassetipealkiri. See otsus osutus õigeks: kuu pärast väljaandmist näeme, kuidas kasutajate „loomaaed” riistvarast toob kiibi töötamise osas üllatusi.

NDMP-mahupuhverdatud lindi peale

Kokkuvõtteks – kõige nõutuma funktsiooni kohta selle värskenduse arvustuste arvust. NDMP-mahtude varundamine kassettide peale on nüüd saadaval. VBR infrastruktuuri tuleb lisada NDMP-server, pärast mida saab faili lindi tööülesandes valida selle hosti mahtusid. Need paigutatakse kassettidesse failide kujul, millel on spetsiaalne atribuut, et eristada neid tavalisest kataloogimisest.

Esimeses versioonis on teatud piirangud: laiendusi ei toetata, lisaks saab varundada ja taastada ainult täiskogumist, mitte eraldi faile. Varundamine toimub läbi dump (NetApp puhul – ufsdump), seal on oma eripärad: maksimaalne inkrementaalsete punktide arv on 9, pärast mida sunnitakse täisvarukoopia tegemist.

Kokkuvõtteks

Need olid vaid kõige suuremad uuendused magnetlindiga varundamises VBR 9.5 Update 4. Muud muudatused on järgmised:

• võimalus määrata allika tööülesannete ja failide järjekord lindi tööülesannetes;
• lisatud Tape Operatori roll (kasutaja võib teha kõike, välja arvatud andmete taastamine lindilt – selleks on Restore Operator);
• lindi tööülesandes on lisatud täielikud include/exclude maskid (välja arvatud NDMP);
• töötati välja failitüübi taastamine (kaust taastatakse nende failidega, mis seal olid varukoopia hetkel, mitte kõigi nende failidega, mis kunagi seal olnud on – nagu ikka, väga nõutud funktsioon);
• suurendatud taastamise kiirus väga suure arvu failide jaoks kassettidelt;
• töötati välja algoritm järgmise kassetti salvestamiseks, arvestades andmete mahtu, mis on kogu selle elu jooksul salvestatud/loodud, valime kõige värskema;
• töödeldi toote stabiilsust.

Kasulikud lingid

Mitmekesisuseks toon mõned lingid ka vene keelt kõnelevatele ressurssidele:

• Link tasuta prooviversiooni VBR 9.5 Update 4 allalaadimiseks
• Artikkel Habrast „Kasulikud näpunäited Veeami varukoopia arhiivimiseks magnetlintidele”
• Artikkel Habrast „7 kasulikku näpunäidet varukoopiate kaitsmiseks krüptoviiruste eest”
• Kasutajajuhendi jagu, mis puudutab lintide kasutamist (inglise keeles)
• Ja tagasime tagasi eelnevasse kohta ülevaatevideod „Kuidas see töötab” (kuigi praegu ainult inglise keeles) – neid saab vaadata siit. Lindiga rääkijatest tehakse juttu slaididel 95 – 102.

Allikas: habr.com