A elmondtuk, hogy a januári frissítésben, a Veeam Backup & Replication 9.5 (VBR) Update 4-ben megjelent új funkciókról beszélünk, ahol tudatosan nem említettük a mágneses szalagon tárolt biztonsági mentéseket. E terület bemutatása külön cikket érdemel, mert valóban sok új funkció jelent meg.
– Fiúk a QA-tól, írtok egy cikket?
– Miért is ne!
Szalagos tárolók a XXI. században
Adatok tárolása mágneses szalagokon (kazetták, „szalagok”, ahogy az R&D-nél hívjuk őket) nem korlátozódik a múltban létezett ZX-Spectrum számítógépre, amely egy játékot akár több percig betöltött a 48 kb-os RAM-jával Húsz év alatt a kazetták sebessége és kapacitása 6-7 nagyságrendet nőtt. Ez nem teljesen helyes összehasonlítás, és a szabvány nem tart lépést. Ennek ellenére a modern technológiák lehetővé teszik, hogy egy kilométer hosszú szalagon 12 terabájt adatot rögzítsenek (akár 30 terabájt tömörítési módban), így a 160 dolláros tároló a hosszú távú nagy mennyiségű adat tárolásának költségét tekintve még a felírásra/olvasásra költött berendezések költségeit is figyelembe véve maga mögé utasítja versenytársait. Az ilyen kazettákon tárolt adatok megbízhatóan 15-30 évig megőrizzük.
Másik oldalról közelítek. Mostanában új szintre léptek. Hónapokig és hetekig várakozhatnak egy nagyvállalat infrastruktúrájában, és egy újabb nulladik napi sebezhetőség megjelenésével – elpusztíthatják (nem kis segítséggel, hiszen nagy pénz forog kockán) nemcsak az összes adatot, hanem minden biztonsági mentést is, amelyhez csak hozzáférhetnek. Íme , amikor a vállalatnak zsarolóknak kellett kifizetnie. A úgynevezett légies szakadék, azaz fizikailag az infrastruktúrától elszigetelt biztonsági mentések lényegében az egyetlen megbízható megoldássá váltak az ilyen helyzetek ellen. A mágneses szalag itt az egyik időtálló megoldás.
De a megbízható adatok védelméhez nem elegendő csak a vezető gyártók (IBM, HPE, Oracle, Dell) új technológiai specifikációi és vasújdonságai, szükség van jó szoftverre is. A Veeamnél egy egész csapat foglalkozik a szalagos mentésekkel, körülbelül 10 ember napi szinten elemez, tervez, kutat, fejleszt és tesztel. Ennek a munkának az eredményeit az előző cikkekben láthatták., Mit is tettünk az elmúlt évben?
Szótár
Felmerül a kérdés, hogy a választási lehetőségek között a saját nyelvünk szabadsága és a nehezen olvasható hivatalos kifejezések közül válasszunk. Én az előbbit részesítem előnyben, ezért elnézést kérek, ha valakinek a lent található slang kifejezések szemet szúrnak. Itt röviden emlékeztetem arra, hogy mit jelent a bizonyos kifejezés.
A VBR szakértői ezt a részt átugorhatjákJob - feladat a mentéshez. Tulajdonképpen az egész VBR a jobokra épül. A mentés és replikálás mellett ez lehet a szalagra való másolás is (backup to tape job, tape job). Megjegyzem, hogy a visszaállítás a mentésből (restore) is egy job, de ebben a cikkben ez a kifejezés kifejezetten a mentésre vonatkozik.
Storage - tárolás - a népszerű elnevezés. Ezek fájlok a tárhelyen (repository - tároló), amelyek mentéseket tartalmaznak - teljes és inkrementális. Egy storage-ban egyszerre egy vagy több virtuális gép is lehet.
Lánc - chain - egymáshoz kapcsolódó storage-ek sorozata. Az n-edik inkrementális storage-ból való adatvisszaállításhoz szükséges az összes korábbi storage a(n-1)-es számtól 1-ig, valamint a teljes storage, amelyre az első inkrementális utal.
Forrás, cél - source, target. Forrás - az a kiindulási entitás, amelyet a job kezel. Mentések/replikák esetén ez általában egy virtuális gép a hypervisorban. A tape job esetén a forrás maga a backup job (vagy fájlok, ha file to tape job-ról van szó). A backup job célja - a repository, ahol a mentések vannak tárolva. A tape job célja pedig a média pool.
Média pool – – adathordozók gyűjteménye, esetünkben – kazetták. Logikai tároló, amelyet a felhasználó hoz létre, és amely egy vagy több könyvtár kazettáit tartalmazza. Tehát a tape job mindig tartalmaz egy média poolt, mint célt, ami azt jelenti, hogy az adatok nem egy konkrét kazettára és nem bármelyik kazettára a könyvtárban, hanem egy meghatározott halmazra íródnak. A média pool beállítja az adatok megőrzési idejét, amely elteltével a kazetta felülírható. A felhasználó létrehozhat hagyományos (standard) és . Mindegyik típus most már lehet WORM és nem-WORM, erről lentebb.
Média készlet – – kazetták halmaza a média poolban, amelyekre folyamatosan készülnek a mentések/fájlok. A GFS poolok esetében a média készletek szoros kapcsolatban állnak az intervallummal (például éves – yearly), a kazetták csak a saját intervallumukon belül rotálódnak.
– a tape könyvtár elemei. A meghajtó olvassa és visszatekeri a kazettát, a cserélő – egy robot, amely a kazettákat mozgatja a tárolóslotok, a kiadóslotok és a meghajtó között. Vannak standalone meghajtók (standalone – különálló), ahol a cserélő szerepét egy ember tölti be. A meghajtóhoz kötelező a megfelelően telepített gyártói illesztőprogram Windows gépen, amelyhez a könyvtár csatlakozik; a cserélővel viszont dolgozhatunk illesztőprogramok nélkül is, a natív SCSI-n keresztül.
Tenant to tape. A szolgáltató védett – a kliensek védettek
Azonnal a lapra a trükkök. A legnagyobb funkciója a frissítésünknek, amely a , akik VBR-t használnak az infrastruktúrájukban. A fejlesztést két évvel ezelőtt kezdtük el. Hamar rájöttünk, hogy egy ilyen komoly feladattal a következő kiadásig nem tudunk végezni, kis időt vettünk, és végül a funkciót a 9.5 Update 4-ben adtuk ki.
Röviden, a szolgáltatóknak lehetősége lett arra, hogy a klienseik mentéseit kazettákra másolják GFS pool segítségével tape job segítségével. Ez két lehetőséget ad a szolgáltatóknak – nekik, akik nagyon fontosak számunkra és a kereskedelmi részlegünk számára – :
- megóvják ügyfeleiket (tenants, tenant – bérlő) az adatok elvesztésétől a véletlen törlés vagy infrastrukturális problémák miatt ("árvíz a szerver szobában");
- Olyan kiegészítő szolgáltatást kell nyújtanunk a bérlőknek, amely lehetővé teszi a régi biztonsági másolatok adatainak helyreállítását, amelyek már régen törölve lettek a felhőalapú tárolóból az adatmegőrzési politika szerint, de a kazettákon még mindig ott vannak.
A marketing szempontjából a funkcionalitás nagyon "ízletes", a mi szempontunkból pedig éppolyan nehezen megvalósítható.
Fejlesztés
A legnagyobb felmerült probléma az adatok titkosítása. A legtöbb felhőalapú biztonsági másolat titkosított, a statisztikák szerint ez a szám a teljes mennyiség ⅔-a. Ez a szám meglepett minket, úgy gondoltuk, hogy szinte minden titkosítva van, de nem – sok ügyfél úgy tűnik, határozottan bízik a szolgáltatóikban.
A paradigma egyszerű: a szolgáltatónak nem szabad tudnia a bérlők adatait dekódolni. Ugyanakkor az új funkció keretein belül a szolgáltatónak hozzáférést kell biztosítania a biztonsági másolatokat tároló rendszerekhez. Ezt arra van szükség, hogy a data blokkokat áthelyezhessük, például létrehozásához . A fő szempont az, hogy ezt függetlenül kell végrehajtanunk a bérlőtől, amikor a szükséges kulcsok nem kerülnek a szolgáltató oldalára a munka során.
E probléma megoldása, amely egyébként egy másik fontos funkcióban is szerepel a kiadás kiegészítésében - – az további titkosító kulcs hozzáadásában rejlik. Az archív kulcs (Archive key) a szolgáltató adatbázisában titkosított formában tárolódik. Egy jól megtervezett sémával a szolgáltató oldalán ezzel a kulccsal megnyithatók a tárolók, adatszekvenciák áthelyezhetők és újra titkosíthatók az egyes tárolók között (hiszen mindegyik saját kulccsal rendelkezik), de maguk az adatok nem dekódolhatók.
Jól megtervezett séma (működő változat)
Hozzáteszem, hogy a R&D mérnökei nagyon szeretik a titkosítást a termékünkben, igaz, senki sem tudja minden részletét, hogy hogyan működik. (Itt volt egy vicc is, hogy "és miért működik egyáltalán", de ezt a szerkesztők nem engedték át.)
Tesztelés
A funkcióra több száz hibajegyzék készült. A legnehezebb területek a titkosítás, a felhasználói felület és a helyreállítás során felmerülő problémák.
A tesztelés szempontjából a nehézséget a nagy variabilitás, a bérlői feladatok és a tárolók – úgy értem, mind a forrást, mind a célt beállítva – restaurálás során jelentették. Mindez egy logikára épül a keretében (beleértve az újat – párhuzam és napi média készletek, erről lentebb), és általában a szokatlan felhőspecifikus megoldásokra a tápegységek számára. Ne felejtsük el bőven megfűszerezni titkosítással. Ha a metaforát folytatjuk, jól jóltaktunk ezzel az étellel – de minden oldalról kipróbáltuk.
A tesztterv része
Ennek eredményeként
Részletes leírást találhat a (jelenleg angol nyelven): , . Megállnék a főbb pontoknál.
Biztonsági mentés
A szolgáltató tenantokat ad hozzá a tápkészítményhez GFS-tárgyalóként. Felhőlicencével a varázsló második lépésénél elérhető az opció. Tenantok. Minden tenantot egyszerre, vagy külön-külön is hozzá lehet adni, de csak egy külön kvótát (de nem alkvótát) választhatunk ki egyetlen tenant esetében. Egy feladatban nem lehet összekeverni a tenant biztonsági mentéseket és a hagyományos helyi mentéseket.
A többi beállítás szinte teljesen azonos a hagyományos GFS-tározott feladattal.
Az adatok visszaállítása lehetséges a szolgáltatónál vagy a tenantnál.
Visszaállítás a szolgáltató oldalán
Új varázslón keresztül történik. Itt le lehet mélyedni egy adott feladatra, a visszaállítás a teljes láncot érinti, amely egy adott napon a tárolóban volt.
Három lehetőség van a visszaállításra:
- Az eredeti helyszínre. Ebben az esetben az eredeti biztonsági mentés, ha van, törlésre kerül; a tenant feladatok automatikusan újra vannak állítva a helyreállított láncra. Feltételezzük, hogy az ilyen visszaállítás a kliens számára észrevétlen lesz, csak rövid ideig lesz lekapcsolva a felhő tárolóról.
- Új kvótába / tárolóba. A szolgáltató például létrehozhat egy külön ideiglenes fiókot erre a célra, amelyet később törölni fog. A biztonsági mentés a tenant infrastruktúrájában jelenik meg a szolgáltató adatbázisával való szinkronizálás után.
- Csak Linux- vagy Windows-szerverre, amely a szolgáltató infrastruktúrájában van regisztrálva. Ezt a láncot később le lehet menteni egy flash meghajtóra és el lehet küldeni a tenantnak.
Visszaállítás a tenant oldalán
Ez a lehetőség azt jelenti, hogy az ügyfélnek saját tape-infrastruktúrája van, és nagy mennyiségű adat áll rendelkezésre az étterem számára. A szolgáltató fizikailag elküldheti az ügyfélnek a mentéseket tartalmazó kazettát, az ügyfél katalogizálja azt a saját felszerelésén, dekódolja a kazettákat és a mentéseket, és úgy dolgozik a biztonsági másolatokkal, mintha ő maga rögzítette volna azokat a szalagra. Ilyen trükk, hogy ne kelljen terabájtokat letölteni WAN-on.
Tömeges fejlesztések a GFS poolban
-media poolok két éve jelentek meg a VBR-ben, a 9.5-ös verzióban. A megjelent frissítésben, a Tenant to tape funkció megjelenésével, valamint a felhasználói kérések alapján, alaposan megerősítettük ezt a funkcionalitást.
Napi media setek
Új napi (daily) media set jelent meg. Mostantól a GFS poolban tárolhatók mentések minden napra, és nem csak teljes, hanem inkrementális mentések is. Az utóbbiak lényegesen kevesebb helyet foglalnak el, és ezt a szalaghordozás érdekében tettük. Feltehetőleg ezek a kazetták folyamatosan rotálódnak a könyvtárban, és nem szállítják el távoli tárolásra. Ugyanakkor a restaurálás során az inkrementális pontokból szükség lesz valamelyik idősebb media set kazettáira (hetente, havonta, negyedévente vagy évente). A napi media set aktiválása nem lehetséges a heti nélkül, annak érdekében, hogy a legtöbb esetben az inkrementális másolatból való helyreállításhoz valóban heti kazettákra legyen szükség. Ezek vagy mindig a könyvtárban vannak, vagy nem annyira távoli raktárban tárolják őket.
A tape-job működésének logikája a GFS media poolban , a műszaki írók meg fogják ezt erősíteni. Röviden, a részletek kihagyásával, a heti és idősebb media setekbe csak teljes mentések (beleértve a virtuális teljes mentéseket) kerülnek átmásolásra, napi egy a minden dátumhoz, míg a napi setbe az összes pillanatnyilag elérhető mentés a jelenlegi napra, hiszen a mentési feladat gyakrabban is elindulhat, mint napi egyszer.
Párhuzamosság, indulási idő és várakozás a GFS poolokban
Most már lehetséges több lánc vagy job párhuzamos írása több meghajtóra a könyvtárban a GFS media poolokban is (korábban csak a hagyományosokban). Ezt az Options media pool lépésénél aktiválni kell.
Fontos pontosítás: ugyanaz a fájl mindig egy folyamatban íródik, ezért több nagy virtuális gép esetén ajánlott aktiválni a , hogy a biztonsági mentés több láncból álljon.
Ezen kívül már lehetőség van választani a GFS-feladat kezdési időpontját. Sok felhasználónak nem tetszett, hogy éjfélkor indul és szinte egész nap várni kell, amíg a forrásfeladat befejeződik. Most ezt az időt például késő estére lehet állítani, amikor már van mit másolni a szalagra. Továbbá, a felhasználók kérése alapján a speciális beállítások közé került egy opció, amelyet korábban csak a rendszerregisztrációs kulccsal lehetett aktiválni. Elég választani A legutóbbi visszaállítási pont feldolgozása a várakozás helyett – és a kazettára az a tartalom kerül másolásra, ami a folyamat indításának időpontjában a tárolóban van (például a tegnapi pont), így várakozás nincs.
Fejlett több könyvtárral való munka
Ez a helyzet arra vonatkozik, amikor egy médiatárolóhoz több könyvtárat adtak hozzá. Ezt korábban is támogattuk, de időnként érkeztek olyan ügyfélbejelentések, amelyek a meglehetősen kiszámíthatatlan viselkedésről számoltak be.
Volt
Például elindult egy tape-ténykedés, elfoglalt két meghajtót az első könyvtárban, de a párhuzamosság beállításai lehetővé teszik, hogy azonnal 4 meghajtót használjon. Kell-e ennek a feladatnak váltania a médiatároló második könyvtárára, és azt is használnia, vagy ez erőforráspazarlás lenne?
Egy másik eset. A »nincs elérhető kazetta« feltételre választott opció, az első könyvtárban csak egy kazetta van, de potenciálisan az összes adat elfér rajta. A beállítások viszont párhuzamos írást tesznek lehetővé két kazettára. Használni kell-e a második könyvtárat ebben az esetben?
Úgy döntöttünk, hogy rendbe tesszük ezt a területet és lehetőséget nyújtunk a magatartás egyértelmű beállítására.
Lett
szerepet kaptak – aktív és passzív. És magának a médiatárolónak – két üzemmódja van: hibatűrő, vagy failover (failover) és párhuzamos írás (párhuzamosság). Most, a követelmények függvényében, különbözőképpen lehet beállítani a médiatárolót.
- Ha több egyenrangú könyvtára van, és szükséges a párhuzamos írás, akkor aktiválja a párhuzamos írási módot, ehhez minden könyvtárnak aktív szerepet kell kapnia. Ilyen esetben az új kazetták és meghajtók azonnal felhasználásra kerülnek, amint szükség lesz rájuk, függetlenül attól, hogy melyik könyvtárban találhatók. A prioritás így is létezik – először megpróbálunk erőforrásokat találni a listában feljebb lévő könyvtárban.
- Ha azonban egy fő könyvtára és egy régi vagy stand-alone meghajtója van tartalékként, aktiválja a failover módot, a fő könyvtárat helyezze a lista tetejére, és válassza passzív szerepet a tartalék eszközök számára. Az átállás egy ilyen eszközre csak akkor történik, ha ez valóban szükséges, hogy a munka egyáltalán működni tudjon. Ezt a helyzetet rendellenesnek tekintik, erről értesítés fog érkezni e-mailben.
Van egy bonyolultabb helyzet, amit jelenleg nem támogatunk – több aktív könyvtár passzívakkal együtt. A visszajelzések megmutatják, van-e szükség ilyen konfigurációkra, és hogy szükség van-e a funkció jövőbeni kibővítésére. Ez a standard gyakorlat.
WORM támogatás
WORM – Write Once Read Many – olyan kazetták, amelyeket nem lehet törölni vagy felülírni , csak adatokat lehet hozzáadni. Kötelező használatukat bizonyos szervezetek szabályai írják elő, például az orvostudomány területén dolgozók. A fő probléma ezekkel a kazettákkal korábban az volt, hogy a VBR a vagy megírta a fejlécet, amely a jövőben már nem törölhető, és a kazettás munkák hibával leálltak, ha egy ilyen kísérlet történt.
A 9.5 Update 4-ben teljes körű támogatás került bevezetésre az ilyen kazetták számára. WORM média csoportok kerültek hozzáadásra, hagyományos és GFS, ahová csak ilyen típusú kazetták helyezhetők.
Az új kazetták kék, 'lefagyott' ikonja van. Felhasználói szempontból a WORM kazettákkal való munka nem különbözik az általános kazetták kezelésétől.
A kazetták 'wormness' kifejezése eredetileg a suffix alapján határozódik meg , ha a vonalkódok normálisak vagy olvashatatlanok, az információt a meghajtó az első kazetta behelyezésekor adja át. A WORM kazettákat nem lehet normál médiapoolba helyezni és írni rájuk. Vicces, hogy már találtak olyan felhasználókat, akik WORM vonalkódokat ragasztottak a normál kazettákra, és meglepődtek a változásokon az infrastruktúrájukban az aktualizálás után.
Kazetta chip
A nem felülírható kazetták bevezetésével párhuzamosan elkezdtük használni a A chipben korábban nem használtuk a standard attribútumokat, most néhányat írunk és olvasunk, de nem tekintjük fő adatforrásnak. A fő irányt továbbra is a kazetta címe képezi. Ez a megoldás helyesnek bizonyult: egy hónappal a megjelenés után látjuk, hogy a felhasználók „állatkerti” hardvere meglepetéseket tartogat a chip használatával kapcsolatban.
NDMP kötetek biztonsági mentése szalagra.
Összegzésül - a legkeresettebb funkcióról a frissítésben, amelyről a legtöbb visszajelzés érkezett. Mostantól elérhető az NDMP kötetek szalagra történő mentése. A VBR infrastruktúrájába hozzáadni, utána a fájl tape jobban lehet választani a köteteket erről a gazdagépről. Ezek fájlok formájában kerülnek a kazettákra egy speciális attribútummal, hogy megkülönböztethessük őket a normálaktól a kategorizálás során.
Az első megvalósításnak van néhány korlátozása: nem támogatottak a kiterjesztések (extensions), valamint csak a teljes kötet mentése és visszaállítása lehetséges, nem a külön fájloké. A biztonsági mentés az (NetApp esetén - ), itt vannak sajátos jellemzők: a maximális inkrementális pontok száma – 9, utána teljes mentést kényszerít.
Összegzésül
Ezek voltak a legnagyobb újítások a mágneses szalagon történő biztonsági mentések terén a VBR 9.5 Update 4-ben. A többi változást felsorolom:
- a forrás-jobs és fájlok sorrendjének megadása a tape jobokban;
- hozzáadva a Tape Operator szerepkör (a felhasználó mindent megtehet, kivéve a szalagról való visszaállítást – erre van Restore Operator);
- teljes értékű include/exclude maszkok hozzáadva a fájl tape jobben (kivéve az NDMP-t);
- a fájl tape job visszaállítása továbbfejlesztve (a mappa azokkal a fájlokkal áll vissza, amelyek abban voltak a biztonsági mentés idején, nem pedig minden olyan fájllal, amely valaha is benne volt a teljes mentés történelem során - ez egy nagyon keresett funkció, amúgy);
- növelték a nagyon nagy számú fájl szalaggal történő visszaállításának sebességét;
- Kifejlesztettük a kazetta kiválasztási algoritmust a felvételhez, különösen, ha minden más egyenlő, figyelembe véve az eddig rögzített/olvasott adatok mennyiségét, és a legfrissebbet választjuk;
- Javítottuk a termék stabilitását.
Hasznos linkek
A változatosság kedvéért íme néhány hivatkozás orosz nyelvű forrásokra:
- És visszatértünk a régi helyre a "Hogyan működik" áttekintő videókhoz (jelenleg angol nyelven) – meg lehet nézni . A szalagokról a 95-102. diáknál beszélnek.
Forrás: habr.com
