U U ovom članku govorili smo o novim funkcionalnostima koje je donio siječanjski Update 4 za Veeam Backup & Replication 9.5 (VBR), gdje izraženo nismo spomenuli sigurnosne kopije na magnetskoj traci. Priča o ovom području zaslužuje poseban članak, jer je novih funkcionalnosti doista bilo mnogo.
– Ekipa iz QA, hoćete li napisati članak?
– Zašto da ne!
Magnetske trake u XXI veku
Pohrana podataka na magnetskim trakama (kasetama, "trakama", kako ih mi u R&D nazivamo) ne ograničava se na prošlost s računalom ZX-Spectrum, čija je igra mogla učitati u radnu memoriju 48 kb s i to nekoliko minuta. U četvrt stoljeća, brzine i kapaciteti kaseta su porasli za 6-7 redova veličine. Ovo nije posve točno uspoređivanje, a prema standard ne kaskaju. Ipak, moderne tehnologije omogućuju snimanje 12 terabajta podataka (do 30 terabajta u kompresijskom režimu) na kilometarsku traku jedne kasete, tako da 160-dolarska pohrana ostavlja konkurente iza sebe po cijeni dugotrajnog pohranjivanja velikih količina podataka čak i uz troškove opreme za snimanje/čitaje. Podaci na takvim kasetama pouzdano se čuvaju od 15 do 30 godina.
Pogledat ću to iz druge perspektive. U posljednje vrijeme je dosegao novu razinu. Mogu čekati svoj trenutak u infrastrukturi velike tvrtke tjednima i mjesecima, a s pojavom novog zero-day ranjivosti – uništiti (ne bez pomoći čovjeka, jer se radi o velikom novcu) ne samo sve podatke, već i sve sigurnosne kopije do kojih se može doći. Tako je tvrtka bila prisiljena platiti otkupninu. Takozvani air gap, tj. fizički izolirane sigurnosne kopije od infrastrukture postale su, u suštini, jedina pouzdana zaštita od takvih slučajeva. Magnetska traka je ovdje jedno od neprolaznih rješenja.
No, sama specifikacija i tehnička rješenja vodećih proizvođača (IBM, HPE, Oracle, Dell) nisu dovoljni za pouzdanu zaštitu podataka, potreban je dobar softver. U Veeamu imamo čitav tim koji se bavi sigurnosnim kopijama na trakama, oko 10 ljudi svakodnevno analizira, planira, istražuje, razvija i testira. Rezultate ovog rada mogli ste vidjeti u prethodnim člancima (, ). Što je postignuto u protekloj godini?
Rječnik
Stoji pitanje između sloboda prema materinjem jeziku i kanцеларizama koji otežavaju čitljivost. Preferiram prvo, stoga unaprijed ispričavam ako će nekom žargonizmi iz donjeg popisa biti nespretni. Ovdje bih ukratko podsjetio što svaki termin znači.
Stručnjaci za VBR mogu preskočiti ovaj dioJob – job – zadatak za izradu sigurnosne kopije. U suštini, cijeli VBR temelji se na jobovima. Osim sigurnosnog kopiranja i replikacije, to može biti i kopiranje na magnetsku traku (backup to tape job, tape job). Napominjem da je obnova iz sigurnosne kopije (restore) također job, ali u ovom članku pod tim pojmom podrazumijevam isključivo sigurnosno kopiranje.
Storage – storage – povijesno ustaljeno ime. To su datoteke u repozitoriju (repository – skladište), koje sadrže sigurnosne kopije – potpune i inkrementalne. U jednom storageu može biti jedna ili više virtualnih mašina.
Lanac – chain – niz međusobno povezanih storaga. Za obnovu podataka iz n-tog inkrementalnog storaga potrebni su svi prethodni od (n-1)-og do 1-og i puni storage na koji se poziva prvi inkrementalni.
Izvor, Cilj – source, target. Izvor je bitna entitet koja se obrađuje od strane joba. U slučaju sigurnosnih kopija/replikacija, to je obično virtualna mašina u hipervizoru. U slučaju tape job-a izvor je sama job za sigurnosno kopiranje (ili datoteke u slučaju file to tape job-a). Cilj za job za sigurnosno kopiranje je repozitorij gdje se čuvaju sigurnosne kopije. Za tape job to je media pool.
Media pool – – skup medija, u našem slučaju – kazeta. Logički kontejner koji stvara korisnik i koji sadrži kasete iz jedne ili više biblioteka. Dakle, tape job uvijek ima media pool kao cilj, tj. podaci se ne pišu na neku određenu kazetu niti na bilo koju kazetu u biblioteci, već na određeni skup. Media pool ima postavku vremena čuvanja podataka, nakon čega se kazeta može prepisati. Korisnik može kreirati obične (standard) i . Svaka od ovih vrsta sada može biti WORM i ne-WORM, o tome više dolje.
Media set – – skup kaseta u medijskom bazenu, na koje se kontinuirano snimaju backupovi/datoteke. Za GFS bazene, medijski setovi su također vezani uz interval (npr. godišnji – yearly), kasete se rotiraju samo unutar svog intervala.
– elementi trake biblioteke. Pogonska jedinica čita i premotava kasetu, menadžer – to je robot koji premješta kasete između utora za pohranu, utora za vađenje i pogonske jedinice. Postoje i standalone pogonske jedinice (standalone – samostojeći), uloga menadžera tu se povjerava osobi. Za pogonsku jedinicu obavezno je ispravno instaliran proizvođačev drajver na Windows mašini, na koju je povezana biblioteka; s menadžerom možemo raditi i bez drajvera, putem native SCSI.
Tenant to tape. Zaštitio pružatelj – zaštićeni klijenti
Odmah izlažemo asove. Najveća značajka naše nadogradnje, namijenjena , koja u svojoj infrastrukturi koristi VBR. Razvoj je započeo prije dvije godine. Ubrzo smo shvatili da nećemo stići na bliži rok s ovako ozbiljnim zadatkom, uzeli smo malu pauzu, i na kraju objavili značajku u 9.5 Update 4.
Ukratko, sada pružatelji imaju mogućnost kopirati backupove svojih klijenata na kasete putem trake posla u GFS bazenu. To daje pružateljima – a to su jako važni, skupi tipovi za naše srce i komercijalni odjel – dvije mogućnosti:
- zaštititi svoje klijente (tenante, tenant – zakupac) od gubitka podataka uslijed slučajnog brisanja ili infrastrukturnih problema ("poplava u servera");
- osigurati tenantima dodatnu uslugu vraćanja podataka iz starog rezervnog kopiranja, koje je već odavno izbrisano iz oblaka prema politici čuvanja podataka, ali je na kasetama još uvijek ostalo.
Sa stajališta marketinga, funkcionalnost je vrlo „privlačna“, s naše strane – ništa manje složena za implementaciju.
Razvoj
Glavni problem koji se pojavio – enkripcija podataka. Većina cloud backupova je šifrirana, statistika govori o ⅔ od ukupnog broja. Za nas je ovaj broj bio iznenađenje, mislili smo da je gotovo sve šifrirano, ali nije – čini se da mnogi klijenti bezrezervno vjeruju svojim pružateljima.
Paradigma je jednostavna: pružatelj ne bi trebao biti u mogućnosti dešifrirati podatke svojih korisnika. U okviru nove značajke, potrebna je uloga pružatelja da otvara pohrane s sigurnosnim kopijama. To je potrebno kako bi se premještali blokovi podataka, na primjer, za kreiranje . Ključno je to raditi neovisno o korisniku, kada potrebni ključevi nisu poslani na stranu pružatelja tijekom izvođenja zadatka.
Rješenje ovog problema, koje se, usput, koristi i u drugoj važnoj značajci izdanja – – sastoji se u dodavanju dodatnog ključa za šifriranje. Arhivski ključ (Archive key) pohranjene su u bazi podataka pružatelja u šifriranom obliku. Prema složenoj shemi, na strani pružatelja, s njegovom pomoći može se otvoriti pohrana, premještati i ponovo šifrirati blokove podataka između pohrana (jer svaka ima svoj ključ), ali se ne može dešifrirati sama podaci.
Složena shema (radna verzija)
Dodajem da svi inženjeri u R&D jako vole šifriranje u našem proizvodu, no nitko ne zna u svim detaljima kako to funkcionira. (Ovdje je bila i šala "i zašto uopće funkcionira", ali nisu je pustili urednici.)
Testiranje
Za značajku je zabilježen stotine grešaka. Najizazovnija područja – šifriranje, korisničko sučelje, problemi tijekom obnavljanja.
Iz perspektive testiranja, težina se sastojala u velikoj varijabilnosti, 'kombinatorici' vrsta i tipova korisničkih zadataka i spremišta – mislim na izvor i odredište prilikom obnavljanja sigurnosnih kopija u infrastrukturu. Sve se to oslanja na logiku unutar (uključujući novu – paralelizam i dnevne multimedijske setove, o tome u nastavku), a općenito radi o neobičnoj specifičnosti oblaka za tipove. Ne zaboravite obilato začiniti šifriranjem. Ako nastavimo s metaforom, dobro smo se prejedali tim jelom – ali i kušali ga sa svih strana.
Fragment plana testiranja
Kao rezultat
Detaljan opis može se pronaći u (za sada na engleskom jeziku): , . Osvrnuti ću se na osnovne aspekte.
Backup
Pružatelj dodaje korisnike u zadatak tipa s GFS skupom kao odredištem. Ako postoji licenca u oblaku, na drugom koraku čarobnjaka dostupna je opcija Tenanti. Možete dodati sve tentante odjednom ili pojedinačno, a možete odabrati i samo pojedinačnu kvotu (ali ne subkvotu) određenog tentanta. Nije moguće kombinirati tentantne backupove i obične lokalne u jednom jobu.
Ostale postavke gotovo su potpuno identične običnom jobu u GFS-pulu.
Obnova podataka moguća je kako na strani providera, tako i na strani samog tentanta.
Obnova na strani providera
Izvodi se putem novog čarobnjaka. Ovdje se može spustiti do pojedinačnog joba, obnavlja se cijeli lanac koji se nalazio u repozitoriju na određeni dan.
Postoje tri opcije restauracije:
- U izvorna mjesta. U ovom slučaju, izvorni backup, ako postoji, se briše; jobovi tentanta automatski se ponovno podešavaju na obnovljeni lanac. Podrazumijeva se da će ova obnova biti uopće neprimjetna za klijenta, samo će na kratko biti isključen iz oblaka repozitorija.
- U novu kvotu/repozitorij. Provider može, na primjer, stvoriti za tu svrhu zaseban privremeni račun koji će naknadno obrisati. Backup se pojavljuje u infrastrukturi tentanta nakon sinkronizacije s bazom providera.
- Jednostavno na disk Linux ili Windows servera, registriranog u infrastrukturi providera. Nakon toga, ovaj lanac može se snimiti na USB i poslati tenantu.
Obnova na strani tentanta
Ova opcija podrazumijeva da klijent ima vlastitu tape-infrastrukturu i veliki volumen podataka za obnovu. Kasetu s snimljenim backupovima provider može fizički poslati klijentu dostavnom službom, klijent je katalogizira na vlastitoj opremi, dešifrira kasete i backupove te radi s rezervnim kopijama kao da ih je sam snimio na traku. Ovo je trik kako ne preuzimati terabajte preko WAN-a.
Obimna poboljšanja GFS-pula
-medijski poolovi pojavili su se u VBR-u prije dvije godine, u verziji 9.5. U novom ažuriranju, kako u vezi s pojavom funkcije Tenant to tape, tako i na zahtjev korisnika, dobro smo unaprijedili ovu funkcionalnost.
SvDaily media setovi
Pojavila se nova dnevna (dnevni) medijski set. Sada u GFS-pulu možete čuvati sigurnosne kopije za svaki dan, i to ne samo pune, već i inkrementalne. Posljednje zauzimaju znatno manje prostora, a učinjeno je to u svrhu uštede trake. Podrazumijeva se da se ti kaseti kontinuirano rotiraju u biblioteci, a ne prevoze na udaljeno skladištenje. Pri tome, za restoraciju iz inkrementalne točke biće potrebni kaseti jednog od starijih medijskih setova (tjednog, mjesečnog, kvartalnog ili godišnjeg). Nije moguće uključiti dnevni medijski set bez uključivanja tjednog, da bi se u većini slučajeva za obnavljanje iz inkrementalne kopije koristile upravo tjedne kasete. One se ili uvijek nalaze u biblioteci ili se čuvaju u ne tako udaljenom skladištu.
Logika rada tape joba u GFS medijskom poolu , tehnički pisci to mogu potvrditi. U dvije riječi, ostavljajući detalje po strani, u tjedne i starije medijske setove kopiraju se samo pune sigurnosne kopije (uključujući virtualne pune sigurnosne kopije), po jednu za svaku datum, dok u dnevni – sve sigurnosne kopije koje se nalaze u repozitoriju za trenutni dan, jer backup job može biti pokrenut češće nego jednom dnevno.
Paralelizam, vrijeme pokretanja i čekanje u GFS poolovima
Sada je paralelno pisanje više lanaca ili poslova na više diska u biblioteci moguće i u GFS medijskim poolovima (ranije samo u običnim). Uključuje se na koraku Opcije medijskog poola.
Važna napomena: isti datoteka se uvijek zapisuje u jedan tok, pa se u slučaju nekoliko velikih virtualnih mašina preporučuje uključiti , kako bi sigurnosna kopija bila sastavljena od nekoliko lanaca.
Osim toga, postalo je moguće odabrati vrijeme pokretanja same GFS-jobe. Mnogim korisnicima nije se svidjelo pokretanje u ponoć i kasnije čekanje gotovo cijeli dan dok nije završio source job. Sada se to vrijeme može, na primjer, postaviti na kasnu večer, kada već postoji što kopirati na traku. Štoviše, na zahtjeve korisnika, iznijeli smo u napredne postavke opciju koja se prije mogla aktivirati samo pomoću registracijske tipke. Dovoljno je odabrati Obraditi najnoviju točku vraćanja umjesto čekanja – i na kasetu se kopira ono što postoji u repozitoriju u trenutku pokretanja tape joba (točka od jučer, na primjer), bez ikakvog čekanja.
Napredno upravljanje s više knjižnica
Raspravljat ćemo o situaciji kada je u jedan medijski skup dodano više od jedne knjižnice. Takvu podršku imali smo i ranije, no s vremena na vrijeme dolazili su klijenti s pritužbama na ne baš predvidivo ponašanje.
Bilo je
Na primjer, pokrenuta je tape job koja je zauzela dva drive-a u prvoj knjižnici, ali postavke paralelizma omogućuju joj korištenje do 4 drive-a. Treba li ova joba prebaciti na drugu knjižnicu medijskog skupa i koristiti je također, ili je to prekomjerno trošenje resursa?
Drugi slučaj. Odabrana je opcija prebacivanja po uvjetu "nema dostupnih kaseta", u prvoj knjižnici je samo jedna kaseta, ali na nju potencijalno mogu stati svi podaci. Međutim, postavke omogućuju pisanje paralelno na dvije kasete. Treba li aktivirati drugu knjižnicu u ovom slučaju?
Odlučili smo urediti ovo područje omogućavajući jasno podešavanje ponašanja.
Postalo je
dobile su uloge – aktivna i pasivna. A sam medijski skup ima dva režima: otpornost na greške, ili failover (failover) i paralelno pisanje (paralleling). Sada, ovisno o zahtjevima, može se drugačije konfigurirati medijski skup.
- Ako imate nekoliko ravnopravnih knjižnica i potrebno je paralelizirati zapis u njima – uključite režim paralelnog pisanja, za to svim knjižnicama treba dodijeliti aktivne uloge. U tom slučaju nove kasete i drive-ovi će se aktivirati odmah, čim za njih bude potrebe, bez obzira na to u kojoj se knjižnici nalaze. Prioritet i dalje postoji – prvo ćemo pokušati pronaći resurse u knjižnici koja je viša na popisu.
- Ako postoji jedna glavna knjižnica i jedan stari ili stand-alone drive u rezervi, uključite režim failovera, postavljajući glavnu knjižnicu na vrh popisa i birajući pasivnu ulogu za rezervne uređaje. Prebacivanje na takav uređaj odvijat će se samo kada to bude stvarno potrebno, kako bi joba općenito mogla raditi. Takva situacija će se smatrati izvanrednom, a o tome će biti poslana obavijest na e-mail.
Postoji složenija situacija koju trenutno ne podržavamo – nekoliko aktivnih biblioteka u prisutnosti pasivnih. Povratne informacije će pokazati postoji li potreba za takvim konfiguracijama i treba li "doraditi" opciju u budućnosti. Standardna praksa.
Podrška za WORM
WORM – Write Once Read Many – kasete koje se ne mogu obrisati ili ponovo snimiti , mogu se samo dodavati podaci. Njihova obavezna upotreba regulirana je pravilima nekih organizacija, primjerice, onih koje rade u području medicine. Glavni problem s takvim kasetama ranije je bio u tome što su VBR pri ili snimali naslov koji se kasnije nije mogao obrisati, a tape jobovi su padali s greškom pri takvom pokušaju.
U 9.5 Update 4 implementirana je potpuna podrška za takve kasete. Dodani su WORM medijski poolovi, obični i GFS, u koje se mogu smjestiti samo kasete ovog tipa.
Nove kasete imaju plavu, "zamrznutu" ikonu. S gledišta korisnika, rad s WORM kasetama ne razlikuje se od rada s običnima.
"WORM-ovost" kaseta prvotno se određuje prema sufiksu , ako je barkod na njima običan ili nečitljiv, informaciju daje drajver prilikom prvog umetanja kasete. Nije moguće smjestiti WORM kasete u obični medijski pool i snimati na njih. Zanimljivo je da su već pronađeni korisnici koji su lijepljeli WORM barkode na obične kasete i bili iznenađeni promjenama u svojoj infrastrukturi nakon nadogradnje.
Čip kasete
Uz implementaciju ne-prepisivih kaseta počeli smo raditi s . Standardni atributi u čipu ranije nisu korišteni, sada u neke od njih pišemo i čitamo, ali ih ne doživljavamo kao glavni izvor podataka. Glavni orijentir – i dalje je naslov kasete. Ova odluka se pokazala ispravnom: nakon mjesec dana od objavljivanja vidimo kako "zoo" hardver korisnika donosi iznenađenja u pogledu rada s čipom.
Backup NDMP volumena na traku
Na kraju – o najtraženijoj funkcionalnosti po broju povratnih informacija ovog ažuriranja. Postao je dostupan backup NDMP volumena na kasete. U infrastrukturu VBR potrebno je , nakon čega će se u traci zadataka moći odabrati volumeni s tog hosta. Oni se pohranjuju na trake u obliku datoteka sa posebnim atributom kako bi se razlikovali od običnih prilikom katalogizacije.
U prvom izdanju postoje određena ograničenja: ne podržavaju se proširenja (extensions), plus mogući su samo backup i restore cijelog volumena, ali ne i pojedinačnih datoteka. Backup radi putem (u slučaju NetApp – ), ovdje postoje posebnosti: maksimalan broj inkrementalnih točaka je 9, nakon čega se prisilno kreira potpuni backup.
Kao zaključak
To su bila najveća poboljšanja u području backupiranja na magnetsku traku u VBR 9.5 Update 4. Ostale promjene navest ću popisom:
- mogućnost postavljanja redoslijeda zadataka i datoteka u traci zadataka;
- dodana je uloga Tape Operator (korisnik može raditi sve osim vraćanja s trake – za to postoji Restore Operator);
- dodane su potpune include/exclude maske u datotečnom traci zadataka (osim NDMP);
- poboljšano je vraćanje u datotečnom traci zadataka (mapa se vraća s onim datotekama koje su bile tu u trenutku backupa, a ne sa svim datotekama koje su ikada bile u njoj tijekom cijele povijesti njenih backupova – vrlo tražena značajka, usput).
- povećana je brzina vraćanja vrlo velikog broja datoteka s traka;
- dorađen je algoritam odabira sljedeće trake za zapisivanje, posebno, pod jednakim uvjetima uzima se u obzir količina podataka zapisane/pročitane tijekom cijelog njenog trajanja, uzimamo najnoviju;
- poboljšana je stabilnost proizvoda.
Koristitne veze
Za raznolikost, navedimo nekoliko poveznica na ruske resurse:
- I vratili smo se na prethodno mjesto preglednih videa "Kako to radi" (iako trenutno na engleskom jeziku) – može se pogledati . O trakama se govori na slajdovima 95 – 102.
Izvor: habr.com
