Beginners Guide to TikTok for Search - Rachel Pearson - We are Tilt __ Bright...
Storage con virtual_tape_v01
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. 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“
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.
7.
8.
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.
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
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.
