Storage con virtual_tape_v01

371 views
289 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
371
On SlideShare
0
From Embeds
0
Number of Embeds
67
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Pre zálohovanie už páska nie je najlacnejším riešením. Pri požiadavke na obnovu je potrebné investovať do infraštruktúry – porty,switche, servre, páskové mechaniky
  • Agresívny prienik technológie virtuálnej pásky do sveta OS je vyvolaný práve tlakom na riešenia umožňujúce rýchlu obnovu ale taktiež rýchle vytvorenie zálohy. Zo skúseností je známe, že tieto požiadavky sú často protichodné a prechádzajú až do nepriamej úmery. Dlhodobé trendy hovoria zatiaľ v prospech virtuálnej pásky. Virtuálna páska ktorej koncovým médiom je disk prejde z hľadiska vnútornej architektúry do kategórie DEDUP. Virtuálna páska kde koncovým médiom je fyzická pásková mechanika je naviazaná na existenciu samotných páskových mechaník pričom paradoxne predlžuje ich technologickú životnosť.
  • VTA8000 podporuje zOs j OS v jednom zariadení, vzhľadom na svoju modularitu však umožňuje dedik o vať pre zOS a OS separátne ICP, VTC a IDP. Takto je možné oddeliť dátové toky ale riadenie je spoločné. Stále zostáva k dispozícii na strane RTD funkcia True Dynamic Sharing Zálohovanie v prostredí OS kontinuálne naráža na niekoľko vleklých problémov. Všetky je možné riešiť, vždy sú to ale riešenia implementované v danom prostredí, veľmi ťažko prenositeľné. Jedným z flagrantých problémov je zachovanie kontinuálneho dátového toku v línii zdroj dát – zálohovací server – pásková mechanika . Inými slovami povedané, zálohovací server musí dodávať páskovej mechanike nepretržitý tok dát, aby sa tak zamedzilo prechádzaniu páskovej mechaniky do režimu Štart-Stop, kedy dochádza k spomaľovaniu zápisu a k plytvaniu záznamovým médiom. Tým sa predlžuje zálohovacie okno a znižuje utilizácia volumu a to až o 50 percent. Ďalším problémom je zdieľanie páskových mechaník. Aj v prípade, že na pásky pristupuje len jedna aplikácia, často sú páskové mechaniky dedikované na úroveň servera alebo jednotlivých agentov v prípade používania LanFree backup. V spojitosti s problematikou kontinuálneho dátového toku sa tento problém často rieši navyšovaním počtu páskových mechaník, čo je však v priamom rozpore s Datacenter Complexity Factor. Pridávanie nových páskových mechaník je takmer vždy spojené s nutnosťou vykonania takých zmien, ktoré si vynucujú reštart OS hlavne pri platforme MS. Zásadným problémom môže byť proces obnovy – restore. Toto môže prudko vystúpiť do popredia s nástupom veľkokapacitných páskových médií, dnes cca 600 GB native, veľmi rýchlo však na trhu budú páskové média s kapacitou cca 1 TB native. Pri obnove vybraných dát pre určité servre to môže viesť k neakceptovateľným časom pre RTO a RPO. Aj neustály a prudký nárast objemu dát v prostredí OS zvyšuje tlak na páskové zálohovacie zdroje a môže akcelerovať vyššie popísané problémy. Nie je namieste tvrdiť, že virtualizácia páskových zariadení úplne vyrieši spomenuté problémy, prípadne ďalšie. Nasadenie virtualizácie však umožňuje nasledovné: Zápis na virtuálnu páskovú mechaniku je zápis na diskové pole. Aj v prípade nekonzistentného dátového toku nedochádza k degradácii výkonu, nakoľko tu nie je režim Štart – stop. Navyše zápis prebehne veľkou rýchlosťou, čo významne skracuje zálohovacie okno. Dátový nosič je deklarovaný ako virtuálny volume s definovanou kapacitou pričom dochádza k takmer 100 percentnému využitiu tejto kapacity. Virtuálny volume je/môže byť na pozadí presúvaný na fyzický nosič, ktorý je taktiež efektívne využívaný. Keďže virtuálna páska striktne oddeľuje fyzickú vrstvu od logickej a zároveň emuluje veľké množstvo Virtual Tape Drive, ktoré jediné sú prezentované smerom na servre, takmer nedochádza k problémom s nedostatkom páskových mechaník. Súčasne fyzické páskové mechaniky sú utilizované len z úrovne VTC a to až do 100 percent cez kontajnerizáciu virtuálnych páskových volumov. Takto sú fyzické zdroje dynamicky zdieľané cez tv. „True dynamic sharing“. Pridanie novej virtuálnej páskovej mechaniky znamená len jej definovanie na úrovni virtuálneho enginu a následne oskenovanie zo strany Hostu s vytvorením príslušných device filov. Súčasne je potrebné novú páskovú mechaniku logicky začleniť pod príslušný zálohovací SW. Pridanie novej fyzickej páskovej mechaniky je úplne odtienené od úrovne Host a vyžaduje si len úkony na úrovni SAN, riadiaceho SW pre páskovú knižnicu a začlenenie do príslušných skupín na úrovni virtuálneho enginu. Potreba reštartov je minimalizovaná k nulovým hodnotám. Proces obnovy je možné definovať podľa procesov ILM cez klasifikáciu dát. Na jej základe je potom možné ponechávať príslušné skupiny dát len na úrovni VTC, určitú dobu na úrovni VTC, paralelne na úrovni VTC a RTD. Zvyšujúci sa objem dát pre zálohovacie procesy je možné eliminovať definovaním nových VTD, pridaním kapacity VTC a až v poslednom rade pridaním RTD. Virtualizácia v prostredí OS je jedným zo štartovacích bodov pre zavedenie funkcionalitz HSM do OS. Vytvára otvorenú platformu pre pripravované riešenia typu SMS pre prostredie OS.
  • Modulárna koncepcia
  • CentricStor VTA je modulárne riešenie, ktorého základ tvoria tieto komponenty: ICP – Integrated Channel Procesor je modul pre komunikáciu smerom k Host. Emuluje príslušné páskové mechaniky ako Virtual tape a prezentuje ich do siete SAN alebo ako Direct Attached. Každý ICP má dva porty FC a/alebo FICON pričom na každom porte môže emulovať až 32 páskových mechaník. V jednom node VTA môže byť až 8 ICP. Takto koncipovaný FrontEnd je redundantný a výkonovo škálovateľný. ICP je zodpovedný za ukladanie dát na Virtual Tape Cache v komprimovanej podobe s prípadnou enkrypciou. Interne je ICP prepojené cez SAN switch s ostatnými modulmi VTA. IDP – Integrated Device Processor je modul pre komunikáciu smerom na páskové mechaniky. Každý IDP má dva porty FC a/alebo FICON a umožňuje pripojenie až 8 páskových mechaník prostredníctvom switchu. Pozor na priepustnosť, je to kritérium pre počet takto pripojených páskových mechaník na jeden port. V jednom node VTA môže byť maximálne 8 IDP modulov. IDP zodpovedá za presun dát z Virtual Tape Cache na fyzické média, pričom sa riadi nastavením podľa zadávateľa. Dáta na Virtual Tape Cache môžu zotrvať dlhšie, môžu byť migrované okamžite, nemusia byť migrované vôbec. Interne je IDP prepojené cez SAN switch s ostatnými modulmi VTA. VLP – Virtual Library Processor zložený z dvoch modulov VLM – Virtual Library Manager a PLM – Physical Library Manager. VLP komunikuje s fyzickou knižnicou, prezentuje navonok virtuálne knižnice a manažuje Virtual Tape Cache v spolupráci s ICP a IDP. Interne je taktiež prepojený cez SAN switch. Voliteľne je to redundantný prvok. S ICP a IDP vnútorne komunikuje cez LAN na úrovni riadiacich príkazov. Virtual Tape Cache ako DTVFS – Distributed Tape Volume File System je diskový priestor riadený cez VLP, ICP a IDP. Môže byť dedikovaný na úrovni nodu VTA alebo zdieľaný aj remote. V takom prípade sa zapisujú dáta vždy na dostupnú DTVFS s dostatočnou voľnou kapacitou .
  • Modular centric koncepcia umožňuje flexibilnejšie rozširovanie kapacity a výkonnosti podľa požiadaviek zákazníka. Pomerne častým problémom môže byť kompatibilita interných komponentov, hlavne v prípade SW appliance riešení ako je napr. FalconStore. Veľmi dôležitou možnosťou je dedikovanie časti vnútorných zdrojov takéhoto riešenia na úroveň platformy. Toto je jedna z hlavných výhod riešenia VTA8000 kedy je možné dedikovať ICP na úroveň platformy operačného systému. Modulárna koncepcia dáva vyčerpávajúcu odpoveď na často kladenú otázku vhodnosti spájania páskovej virtualizácie pre zOS a OS do jedného zariadenia.
  • Všetky VTD sú riadené a sprístupňované pre zOS riadiacim programom SMC a CSC. SMC zabezpečuje komunikáciu s operačným systémom a prekladá všetky MOUNT požiadavky do prostredia riadiaceho jadra knižnice. Tiež má priamy interface na HSM, SMC vie v prípade mixovaných VTD cez funkciu TAPEREQ riadiť prideľovanie zdrojov knižnice. Akonáhle SMC/CSC vydá požiadavku na MOUNT VTD, VTA8000 ju vykoná vo väzbe na svoje vnútorné atribúty a logické linky medzi LVG a PVG. VTD pre OS sú sprístupňované cez VTA8000 ktorý funguje navonok ako VACS. Do TSM parametrov sa preto zadáva IP adresa VTA8000 a nie priamo IP adresa servra ACSLS. IP adresa ACSLS servra je definovaná len pre VTA8000 a CSC_RTD pre zOS Managemen VTV je plne transparentný a prevádzkovateľný z úrovne TSM pre OS a taktiež pre Tape management na úrovni zOS. HSM je možné použiť priamo nastavením parametru SMSA na hodnotu SMSA=ON v riadiacom člene pre CSC. Priame riadenie HSM je odporúčané používať ak na úrovni VTD nie sú emulované viaceré typy páskových mechaník – napr. 3490 a 3590. V prípade mixovania typov VTD je odporúčané použiť riadenie cez SMC parameter TAPEREQ, čo je interné riadenie na úrovni VTA8000 a SL8500. VTD – Virtual Tape Drive je emulovaný na portoch ICP. Každé ICP môže emulovať až 64 VTD. Pri prideľovaní VTD je potrebné dodržať podmienku aby ani jeden Host nemal pridelené VTD z jedného ICP. V takom prípade by výpadok tohto ICP mal za následok startu všetkých VTD pre daný Host. Prideľovanie je potrebné a vhodné urobiť minimálne cez 2 ICP a to aj z dôvodu výkonnosti. Identifikácia VTD sa robí nasledovne: SS:II:PP:DD kde SS je číselné označenie site, II je číslo ICP, PP je číslo portu na ICP a DD je číslo virtuálneho drivu emulovaného na danom porte. Takto rýchlo zistíme, ktoré ICP emuluje VTD pridelené danému Hostu. Treba si uvedomiť, že VTA8000 je fyzicky na dvoch sitoch, avšak logicky je to jeden celok. HSM v prostredí Open systems a DB Existuje trieda storage subsystémov, odvolávajúcich sa na Hierarchical Storage Manager (HSM), ktoré sa spoločne používajú v dnešných veľkých spoločnostiach. HSM je integrovaný súbor software a hardware, inštalovaný na výpočtovom systéme, ktorý poskytuje služby storage manažmentu v celej spoločnosti. HSM môže poskytovať množstvo rozličných funkcií vrátane automatického zálohovania, disaster recovery, média manažment, archivácie, migrácie, bezpečnosti, kompresie, vysoko rýchlostný prenos dát (file transfer), a ďalšie funkcie. Jednou z kľúčových vlastností väčšiny software HSM je taktiež poskytovanie schopnosti ukladať dáta na lacnejšie off-line a nearline storage zariadenia, ako napríklad páskové zariadenia alebo WORM zariadenia, za súčasného transparentného prístupu na dáta na úrovni diskového komfortu z minimálnym oneskorením spôsobeným len tým, že ide o páskovú resp. inú technológiu ako disk. Toto môže nastoliť otázky pre používateľov Oracle databáz pretože Oracle za normálnych podmienok očakáva všetky dáta on-line a okamžite dostupné. V tejto časti dokumentu popíšeme niekoľko stratégií, ktoré umožňujú používateľom úspešne a komfortne používať Oracle s HSM a StorageTek Nearline technológiou. Hierarchical Storage Management Ako sa posúvame v storage hierarchii smerom hore, rýchlosť prístupu na dáta pre aplikácie a používateľov sa zlepšuje, ale náklady stúpajú a kapacita klesá. Keď sa posúvame v storage hierarchii smerom dole, kapacita a prístupový čas rastie a náklady klesajú. V hornej časti storage hierarchie všetok manažment dát je automatický. Akonáhle sú dáta raz načítané do počítača, OS a hardware vrátane mnohého príslušenstva automaticky umiestni dáta do najefektívnejšej časti v rámci storage hierarchie pre spracovanie. Napr. dáta, ktoré budú spracované len v CPU sú uchované v registroch alebo v CPU cache, zatiaľ dáta, na ktoré sa pristupuje menej sú v reálnej pamäti a ešte menej často používané dáta sa ukladajú do virtuálnej pamäte. A samozrejme, všetko toto sa riadi transparentne operačným systémom. Pre dáta v dolnej polovici storage hierarchie nefunguje automatické umiestňovanie dát na najefektívnejšie pamäťové média bez použitia HSM. Všetko toto musí byť administrované manuálne. HSM systém automaticky presúva dáta na súbor médií podľa požiadaviek na výkon a so zameraním na úsporu nákladov v spoločnosti. Ďalšou otázkou, ktorú HSM rieši je zálohovanie a obnova po katastrofe (disaster recovery). Existujú vo firme adekvátne zálohy dát ? Kde sú uložené ? Ako často by sa mala záloha vytvárať ? Ako sú dáta obnovované ? Ako sú firemné dáta obhospodarované cez mnoho veľkých serverov a mainframov vo firemnom výpočtovom stredisku, na PC, pracovných staniciach, serveroch pre pracovné skupiny, toto všetko môže komplikovať zálohovanie a obnovu. V poslednej rade je to najčastejšie chyba operátora alebo používateľa, ktorá zapríčiní stratu dát ako chyba hardware alebo prírodná katastrofa. A preto je potrebné sa zabezpečiť voči všetkým takýmto nepredvídaným udalostiam. Bez HSM musia byť tieto procedúry definované a vykonané manuálne pre zabezpečenie týchto úloh a na zaistenie bezpečnosti firemných dát. HSM architektúra Zatiaľ čo implementačné špecifikácie sa líšia od dodávateľa k dodávateľovi, všetky HSM systémy poskytujú veľmi podobné schopnosti a vlastnosti. Storage zariadenia s podobnými charakteristikami sú obvykle zoskupované do tzv. storage pools . HSM katalóg zaznamenáva metadáta o storage subsystéme. Napr. storage pool definície, metadáta o off-line zariadeniach a médiách a o umiestnení záložných kópií dát sú zaznamenané v katalógu. HSM software pracuje a riadi dáta v storage pools na základe používateľských definícii ( storage management policies ), ktoré sú taktiež uložené v katalógu. Politika pre riadenie storage definuje zálohovanie, archiváciu, migráciu a bezpečnostné pravidlá pre uplatnenie pomocou HSM. Táto politika pre riadenie storage môže definovať také veci ako: ako často má byť vykonaná záloha alebo archivácia ak súbory na vysoko rýchlostných diskoch neboli používané posledných 90 dní, budú automaticky migrované do páskovej robotizovanej knižnice kto je oprávnený pristupovať a obnovovať staršie verzie dát a ako má byť obnova vykonaná Základná architektúra HSM Kľúčom k architektúre HSM systémov je ich schopnosť poskytnúť dve úrovne transparentnosti. transparentnosť zariadenia umožňuje prístup do súboru cez jeden interfejs (obvykle virtuálny diskový interfejs), bez ohľadu na ktorom zariadení sú dáta uložené transparentné umiestnenie umožňuje prístup do súborov bez potreby vedieť aktuálne umiestnenie uložených dát Obe, transparentnosť zariadenia a umiestnenia dát si vyžaduje implementáciu dynamickej hierarchie storage, ktorá je sústredená v HSM. Transparentnosť je implementovaná kombináciou média manažmentu a migračných služieb, ktoré budú popísané v nasledujúcich sekciách. HSM Media Management Na rozdiel od diskových súborov, ktoré sú organizované vo file systémoch, súbory uložené na médiách tretieho stupňa, ako napríklad páska alebo CD-ROM, normálne nemajú adresárovú metadáta štruktúru (directory metadata structure), v ktorej by boli organizované. Bez metadátovej štruktúry pre off-line/nearline médiá je manažment tejto časti storage hierarchie ťažkopádny a nešikovné. Väčšina HSM systémov používa HSM katalóg ako skladisko pre metadáta o off-line médiách a súboroch namiesto file systému. Vlastníctvo súboru, povoľovanie prístupu/ACL informácie, vytváranie/modifikovanie/použitie dát, veľkosť súboru, umiestnenie súboru a ďalšie informácie, všetko toto môže byť uložené v HSM katalógu. Toto všetko poskytuje potrebnú infraštruktúru pre podporu jednoduchého prístupu na off-line/nearline médiá a dáta. Ukladanie metadát o off-line/nearline médiách a dátach v HSM katalógu sprístupňuje automatické lokalizovanie, vyhľadávanie a obnovu súborov pre používateľov. Mnoho zákazníkov používa robotizované páskové knižnice alebo CD juke boxy, v ktorých je uložených tisíce pások a CD. Automatická katalogizácia metadát tak ako sa súbory postupne vytvárajú umožňuje ich automatické lokalizovanie, vyhľadanie a obnovu v neskoršej dobe. Toto má významný prínos a výhody pre používateľa. Dovoľuje nearline médiám byť automaticky migrované v rámci storage hierarchie a eliminovať tak potreby na manuálne procedúry. HSM Migračné služby HSM poskytuje schopnosť automaticky migrovať súbory na základe kritérií definovaných používateľom (storage management policies) z jednej triedy “storage pool“ zariadení na druhú a opačne. Migrácia je proces presúvania súborov z jednej úrovne na druhú za zachovania faktu, že súbory, ktoré boli presunuté, môžu byť transparentne prístupné pre aplikácie. Toto dovoľuje súborom, ktoré nie sú dlhší čas používané a sú uložené na drahých vysokovýkonných diskoch, byť automaticky presunuté na lacnejšie a pomalšie zariadenia pre hromadné ukladanie dát. To taktiež dovoľuje transparentnú a automatickú obnovu súboru ak je požadovaný aplikáciou alebo používateľom v neskoršom čase. Transparentnosť migrácie je obvykle implementovaná nahradením originálneho súborového lokátoru (pointer) linkom, zvyškom súboru alebo inými metadátami, ktoré vytvoria ukazovatele na nové umiestnenie súboru. HSM katalóg je aktualizovaný keď je súbor migrovaný, odkiaľ bol migrovaný a ďalšími informáciami požadovanými pre podporu transparentnosti. Niektoré HSM systémy podporujú parciálnu migráciu ako aj migráciu celých súborov. Keď pristupuje aplikácia na migrované súbory, niektoré HSM systémy môžu byť konfigurované pre zabezpečenie migrovania časti súboru späť na disk. Tieto systémy podporujú umiestnenie blokov súborov, ktoré sú často pristupované aplikáciou na vysokovýkonné disky a ostatné menej často pristupované bloky súborov na pomalšie, lacnejšie médiá. Toto je špeciálne užitočné ak sa jedná o veľmi veľké súbory, ktoré majú byť používané aplikáciou. Iné HSM systémy majú schopnosť udržiavať fixný počet blokov zo súboru na disku zo zvyškom súboru uloženým na terciárnom storage. HSM ma taktiež rozličné stratégie pre uspokojenie prístupu aplikácií na dáta. Niektoré HSM systémy notifikujú aplikácii, že súbor je dostupný len po kompletnom spätnom zmigrovaní späť na disk, zatiaľ čo iné HSM systémy dovoľujú prístup už po spätnej obnove prvého bloku na disk. Táto funkcionalita ma priamy dopad na výkonnosť systému. HSM Transparentná migrácia Migračné pravidlá (migračná politika), ktorá riadi umiestňovanie súborov je definovateľná používateľom a môže mať mnoho rôznych foriem. Pravidlá môžu byť postavené na rôznych pravidlách, kritériách – veľkosť súboru, frekvencia prístupu, prefix alebo suffix mena súboru, podľa dátumu vytvorenia, a mnoho ďalších parametrov. Pravidlá môžu taktiež identifikovať súbory, ktoré nemajú byť nikdy migrované. Migračné služby môžu mať veľa foriem a podôb. Napríklad: Pretože máme veľký objem dát, isté súbory sú preto uložené vždy na páskach. Keď naštartuje aplikácia, ktorá potrebuje náhodne pristupovať na tieto dáta, tieto sú migrované (staged) na disk automaticky a transparentne. Po skončení spracovania dát aplikáciou, súbory sú automaticky migrované (destaged) z disku späť na pásku. Pretože aplikácia potrebuje náhodný prístup pre aktualizáciu (update) súborov (toto nie je možné vykonať na veľkej väčšine páskových zariadení) a množstvo dát, ktorých sa to týka je veľké, migrácia dát na disk je garantovaná. CD juke box je použitý pre uloženie veľkého množstva dát. V prípade, že používateľ nechce spôsobiť preťaženie migráciou dát, CD je lokalizované a namontované (všetko poskytuje automaticky HSM média manažment), potom používateľ pristupuje na dáta priamo na CD. CD má prenosovú rýchlosť a vyhľadávací čas pomalší ako pevný disk, avšak tento rozdiel vo výkonnosti neoprávňuje k migrácii na disk ako prvý. Dnes sú však CD juke boxy nahradzované výkonnými páskovými technológiami typu Access Centric – STK 9840. Taktiež je potrebné si uvedomiť, že HSM manažovaná storage môže byť priradená k vzdialenému serveru. V takomto prípade prístup na dáta bude obmedzovaný dostupnou priepustnosťou siete. V sumáre, HSM média manažment a migračné služby poskytujú transparentný prístup aplikácie do súboru, bez ohľadu na umiestnenie súboru a zariadenia a každý dodávateľ HSM implementuje tieto vlastnosti iným spôsobom. Oracle a HSM – spolupráca V tejto sekcii bude prediskutovaná stratégia pre úspešné použitie Oracle databázy s nearline médiami a HSM systémom. Pokiaľ tieto stratégie pokrývajú množstvo otázok týkajúcich sa spolupráce Oracle a HSM, je nevyhnutné si taktiež preštudovať príslušnú dokumentáciu o HSM a Oracle pre lepšie pochopenie popísaných techník. Oracle dátové súbory a HSM HSM systémy môžu spôsobiť zdržanie pri prístupe na dáta a to môže mať vplyv na aplikáciu, napríklad Oracle, a preto je potrebné to pochopiť a naplánovať. DB Oracle predpokladá, že všetky potrebné dátové súbory sú na pridelenom lokálnom disku a sú okamžite prístupné o je možné na ne pristupovať aplikáciou. Súbory, ktoré sú pod kontrolou HSM migrácie môžu alebo nemusia byť okamžite dostupné. Súbor, ktorý je rezidentný na páskovom médiu, je potrebné namontovať a je možné ho zmigrovať na disk predtým ako Oracle môže naň pristúpiť. To si môže vyžadovať určitú dobu pre namontovanie alebo migráciu súboru a to môže mať veľmi závažný dopad na celkovú výkonnosť Oracle ak tento proces nie je monitorovaný a riadený. Oracle databázový server používa množstvo rôznych typov súborov. Len niekoľko súborov je vhodných pre umiestnenie pod kontrolu HSM migrácie. Súbory nevhodné pre umiestnenie pod kontrolu HSM Žiadny zo systémových súborov Oracle nesmie byť umiestnený pod kontrolu HSM. Ak sa tak stane, výkonnosť databázy bude nestála a nepredpovedateľná. Súbory Oracle databázy, ktoré nemajú byť umiestnené pod kontrolu HSM migrácie : Všetky systémové súbory Oracle vrátane : Riadiace súbory Súbory parametrov Oracle Binaries Dátové súbory systémových Tablespace On-line Redo Log súbory Trace súbory Alert súbory Súbory Tablespace obsahujúce Rollback segmenty Súbory Tablespace obsahujúce Temporary segmenty Užívateľ jednak môže definovať, že tieto súbory nebudú riadené HSM migráciou alebo majú byť umiestnené na médiá mimo kontrolu HSM. Súbory vhodné pod kontrolu HSM Vo všeobecnosti historické dáta, ktoré sú často používané sú najlepšími kandidátmi pre riadenie pomocou HSM a ich uloženie na nearline médiá. To však predpokladá pochopenie všetkých vlastností riadenia a spolupráce Oracle-to-HSM. Môžeme uvažovať o troch typoch súborov ako kandidátov pre umiestnenie pod kontrolu HSM migrácie a to sú : Archivované Redo Log súbory Zálohy Oracle súborov Súbory užívateľských alebo aplikačných Tablespace Rozličné stratégie pre používanie týchto typov súborov na nearline médiách alebo HSM budú prediskutované v kapitole o HSM. Tieto stratégie sú : Read-Only Tablespaces On-line and Off-line Tablespaces Table Partitioning LOB and BFILE Management
  • HSM je možné použiť priamo nastavením parametru SMSA na hodnotu SMSA=ON v riadiacom člene pre CSC. Priame riadenie HSM je odporúčané používať ak na úrovni VTD nie sú emulované viaceré typy páskových mechaník – napr. 3490 a 3590. V prípade mixovania typov VTD je odporúčané použiť riadenie cez SMC parameter TAPEREQ, čo je interné riadenie na úrovni VTA8000 a SL8500.
  • Všetky RTD, v našom riešení sú to WORM páskové mechaniky, sú riadené cez SMC a CSC. K dispozícii je priamy interface na HSM alebo vnútorné riadenie SMC cez parameter TAPEREQ v prípade použitia mixovaných RTD. RTD sú pripojené cez IDP prostredníctvom direktorov. Keďže IDP poskytujú svoje služby zOS a OS súčasne, sú všetky RTD zdieľateľné medzi zOS a OS.
  • Storage con virtual_tape_v01

    1. 1. A new Hope – Virtual Tape. Ani ryba, ani rak, ani páska ani disk. Povieme to presne. S tor ageC on s.r.o , Consulting,Concept,Control Jaroslav Pudelka „ To Show Quality“
    2. 2. Nevýhody pásky July 6, 2011 Rýchlosť prístupu na dáta Štart/stop Ukladanie dát „za sebou“ Citlivosť na veľkosť dát, kontinuálny dátový tok Mount time Backup time Restore time „ Nadmerná kapacita“
    3. 3. Intelligent Tape Storage July 6, 2011
    4. 4. Virtualizácia storage všeobecne
    5. 5. Virtualizácia - Virtual tape - Utiliz ácia médií -Utilizácia drivov -Výkonnosť ATL -Kapacita ATL -Drive sharing -CDP -RTO -RPO RTO = Time of Crash to Time the system is operational (Tup - Tcrash) RPO = Time since the last backup of complete transactions representing data that must be re-acquired / (entered). (Tcrash - Tbackup) Lost business Time = (Tup - Tbackup)
    6. 6. Virtual Tape – tape elimination <ul><li>No migration </li></ul><ul><li>No recall </li></ul><ul><li>No MVC </li></ul><ul><li>No stacking </li></ul><ul><li>No RTL support </li></ul><ul><li>Diligent ProtecTIE R </li></ul><ul><li>Tape elimination </li></ul>
    7. 7. Virtual Tape – tape virtualization <ul><li>Migration </li></ul><ul><li>Recall </li></ul><ul><li>MVC </li></ul><ul><li>Stacking </li></ul><ul><li>Support for VTL </li></ul><ul><li>HP, IBM, FSC, SUN/STK </li></ul><ul><li>Sepaton,FalconStor,Nearte k </li></ul><ul><li>Tape virtualization </li></ul>
    8. 8. Zápis na RTD Volume Stacking PV4060 PV-Header <ul><li>VTD páskový formát </li></ul><ul><li>Každý logický volume – VTV je zapísaný na fyzický volume – RTV vo formáte zOS alebo OS : </li></ul><ul><ul><li>Mainframes: VOL, HDR, Data, EOF </li></ul></ul><ul><ul><li>Unix/NT: “Bit string” </li></ul></ul>Update : Meta-Data sú vždy zapísané na konci RTV 50 MB LV7896 Logical Volume 3 LV9005 100 MB LV0345 Logical Volume 1 “ Bit String” (Unix und NT) LV9005 Logical Volume 2 VOL HDR D ata (450 MB) EOF EOV LV0345 LV7896 tapemark
    9. 9. Virtual Emulation Point - VEP Priemerná priepustnosť na úrovni VTD sa vypočíta nasledovne: VTD_AVR = (N_VEP x T_VEP) / N_AVTD kde VTD_AVR – je priemerná priepustnosť VTD N_VEP – je počet Virtual Emulation Point T_VEP – je priepustnosť Virtual Emulation Point N_AVTD – je počet Active Virtual Tape Drive pričom Active znamená pridelený na Host VEP je v našom prípade ICP. Vzorec je univerálne použiteľný pre všetky riešenia, dôležité je definovať si VEP. V princípe je to miesto s najnižšou fyzickou priepustnosťou, cez ktoré MUSIA prejsť dáta zapisované/čítané na/z VTD a súčasne sa na tejto úrovni emulujú VTD.
    10. 10. Základný kameň ILM
    11. 11. Klasifikácia dát July 6, 2011 Tape library with capacity centric drives   Local copies Non-critical data – cca 40 percent Tape library, MAID   Local/remote copies, journaling, logs, backup Sensitive data – cca 25 percent Virtual tape, SATA disks   PIT, Snapshot, incr., diff, can be used sec storage Vital data – cca 20 percent Enterprise disks   Hot standby, mirroring on the same disks, full PIT copies – mirrorStore Mission critical data – cca 15 percent Technológie na ochranu dát Dátová trieda
    12. 12. 5 pilierov ILM – miesto pre Virtual tape July 6, 2011 <ul><li>ILM je postavené na 5 základných pilieroch </li></ul><ul><ul><li>BRCP – Business Requirements Converting to Policy </li></ul></ul><ul><ul><li>DAE – Data Allocation Engine </li></ul></ul><ul><ul><li>DME – Data Management Engine </li></ul></ul><ul><ul><li>SME – Storage Management Engine </li></ul></ul><ul><ul><li>ASS/TS – Active Storage Space/Tiered Storage </li></ul></ul>
    13. 13. ASS/TS – Active Storage Space/Tiered Storage <ul><li>Tiered Storage </li></ul><ul><li>Online – E disk </li></ul><ul><li>Inline – SATA/FATA/PATA disk </li></ul><ul><li>Nearline – MAID/VDL </li></ul><ul><li>Longline – Tape, VTL </li></ul>Applications Data presentation layer FS, DB HSM BCK OAIS DR ILM DAE DME SME CCSI Common Control System Interface 3 Optical Networking FSP 3000  NEMI MASTER WCM LR L/T RR RT WCM LR L/T RR RT WCM LR L/T RR RT WCM LR L/T RR RT WCM LR L/T RR RT WCM LR L/T RR RT WCM LR L/T RR RT WCM LR L/T RR RT DMX 1 2 3 4 5 6 7 8 9 5-8 DMX 1 2 3 4 5 6 7 8 9 5-8 B/W Pwr Enterprise disks - online storage SATA/FATA disks Inline storage Tape library - Longline storage 1 5,6,7 4 2 MAID disks Nearline Storage
    14. 14. Storage hierarchia
    15. 15. Datacenter Complexity Factor – DCF
    16. 16. Je p áska stále lacné médium? <ul><li>cena páskovej mechaniky LTO je cca 8- 10 000 USD </li></ul><ul><li>cena páskovej mechaniky Enterprise je cca 35 000 USD </li></ul><ul><li>cena cartridge je od 100 do 200 USD podľa typu, kapacity a funkcie – WORM </li></ul><ul><li>cena páskovej knižnice je od 30 000 USD pre priemerný počet slotov 500 </li></ul>TAPE PRICING RATIO = počet cartridge / počet mechaník Synergický efekt = virtuálna páska Synergický efekt = virtuálna páska + deduplik ácia
    17. 17. Miesto pre pásku
    18. 18. July 6, 2011 Koncepcie pre Virtual Tape
    19. 19. Future of Storage Intelligence July 6, 2011
    20. 20. Hierarchical Storage Management – HSM
    21. 21. Tiered Backup July 6, 2011
    22. 22. Zálohovacie koncepcie – miesto pre VT
    23. 23. Hybrid storage – ako VT July 6, 2011
    24. 24. Spindown technológie – ako VT
    25. 25. Ako to použiť? July 6, 2011
    26. 26. Virtualizácia pások pre OS <ul><li>Výhody virtualizácie pre OS a zOS v jednom </li></ul><ul><ul><li>Žiadny administračný chaos </li></ul></ul><ul><ul><li>Žiadne kríženie požiadaviek </li></ul></ul><ul><ul><li>OS môže byť konzument páskových zdrojov </li></ul></ul><ul><ul><li>Zdieľané zdroje </li></ul></ul><ul><ul><li>Jednotný management </li></ul></ul><ul><ul><li>True Dynamic Sharing pre RTD </li></ul></ul><ul><ul><li>Failover pre obidve platformy </li></ul></ul><ul><ul><li>Collocation a Reclamation v TSM </li></ul></ul>Management <ul><li>Dedikované zdroje OS – ICP.VTC,IDP </li></ul><ul><li>zOS – ICP,VTC,IDP </li></ul><ul><li>Zdieľané zdroje OS – VLP,RTD </li></ul><ul><ul><ul><li>zOS – VLP,RTD </li></ul></ul></ul>
    27. 27. Virtual Tape – z ákladná architektúra <ul><li>Vnútorná dátová komunikácia cez internú SAN </li></ul><ul><li>Vnútorná riadiaca komunikácia cez internú LAN </li></ul><ul><li>Základné moduly môžu byť aj geograficky rozložené </li></ul><ul><li>Kapacitné a výkonové rozširovanie je možné v režime online </li></ul>Základné moduly ICP IDP VLP VTC
    28. 28. Virtual tape – základné moduly, kapacita, výkonnosť <ul><li>ICP je základný modul pre FrontEnd, virtualizuje pásky – VTD, </li></ul><ul><li>a ukladá dáta na VTC do TFS čo je Virtual Tape Volume </li></ul><ul><li>IDP presúva dáta z a na VTC do Real Tape Drive </li></ul><ul><li>VTC je disková cache pre ukladanie dát. </li></ul><ul><li>Môže byť dedikovaná alebo zdieľaná. Je zrkadlená. </li></ul><ul><li>Virtual Library Procesor VLP je riadiaca jednotka pre celý CS. </li></ul><ul><li>Môže byť standalone alebo redundantná v režime Active-Passive </li></ul>
    29. 29. Virtual Tape - konfigurácia
    30. 30. Virtual Tape – mo d ulárna koncepcia <ul><li>Flexibilnejšie rozširovanie kapacity a výkonnosti </li></ul><ul><li>Možnosť dedikovania vnútorných </li></ul><ul><li>Servisovanie komponentov bez prerušenia prevádzky </li></ul><ul><li>Jasná odpoveď na možnosť virtualizovať pásku pre zOS a OS v jednom zariadení </li></ul>
    31. 31. Virtuálna páska - VTD <ul><li>VTD je emulovaná na ICP </li></ul><ul><li>VTD pre zOS </li></ul><ul><li>VTD pre OS </li></ul><ul><li>Management VTV </li></ul><ul><li>HSM na VTD </li></ul>
    32. 32. Virtuálna páska – VTD a HSM
    33. 33. Fyzická páska – RTD a WORM <ul><li>RTD je pripojená na IDP </li></ul><ul><li>True Dynamic Sharing medzi zOS a OS </li></ul><ul><li>WORM RTD je k dispozícii cez VOLSAFE </li></ul><ul><li>WORM VTC/VTV </li></ul>
    34. 34. Logické usporiadanie Virtual Tape Logical Volume Groups Physical Volume Groups in the Libraries Library 1 Library 2 Assignment rules LVG 1: PVG 1 LVG 2: PVG 2 LVG 3: PVG 2 LVG 4: PVG 2 LVG 5: PVG 3, PVG 4 LVG 6: PVG 5, PVG 8 LVG 7: PVG 8, PVG 9 LVG 1 LV1001 LV1002 LV1003 ......... LV1999 PVG 1 PV0101 PV0102 PV0103 ......... PV0199 LVG 3 LV3001 LV3002 LV3003 ......... LV3999 LVG 5 LV5001 LV5002 LV5003 ......... LV5999 LVG 6 LV6001 LV6002 LV6003 ......... LV6999 PVG 4 PV0401 PV0402 PV0403 ......... PV0499 PVG 5 PV0501 PV0502 PV0503 ......... PV0599 PVG 9 PV0901 PV0902 PV0903 ......... PV0999 LVG 7 LV7001 LV7002 LV7003 ......... LV7999 PVG 2 PV0201 PV0202 PV0203 ......... PV0299 LVG 4 LV4001 LV4002 LV4003 ......... LV4999 LVG 2 LV2001 LV2002 LV2003 ......... LV2999 Partitioning : Volume Groups & Dual Save [ Key D:3595 - VVR] Remote Dual Save PVG 3 PV0301 PV0302 PV0303 ......... PV0399 PVG 8 PV0801 PV0802 PV0803 ......... PV0899 Local Dual Save Local Dual Save
    35. 35. Cena za uloženie dát
    36. 36. Goal: „Data is always there“
    37. 37. July 6, 2011 Diskusia

    ×