Más contenido relacionado
Similar a Storage con v01
Similar a Storage con v01 (6)
Storage con v01
- 1. Information Lifecycle Management – ILM S tor ageC on s.r.o , Consulting,Concept,Control Jaroslav Pudelka „ To Show Quality“
- 2. Jaroslav Pudelka 29 rokov v IT
- 3. Motto: „Hope is not a strategy“
- 6. Goal: „Data is always there“
- 7. July 6, 2011 Mainframe – sila DNA
- 9. - DAE vychádza z koncepcie SMS - Je to automatizované, alokačnou politikou riadené primárne ukladanie novovznikajúcich dát - Storage zdroje sú postavené ako Active Storage Space/Tiered Storage DAE dnes reálne funguje len v prostredí MainFrame Systémovo riadená storage
- 10. Hierarchical Storage Management – HSM
- 11. Hierarchical Storage Management – HSM
- 13. 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)
- 17. July 6, 2011 Open system – migrácia riešení
- 20. Hierarchical Storage Management - LOB July 6, 2011
- 21. Hierarchical Storage Management -aplikácia July 6, 2011
- 22. Hierarchical Storage Management – setup July 6, 2011
- 23. Hierarchical Storage Management – tiered storage July 6, 2011
- 24. Virtualizácia v prostredí OS July 6, 2011
- 26. July 6, 2011 Information Lifecycle Management - ILM
- 28. O čo ide? July 6, 2011
- 29. 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
- 30. Klasifikácia dát – Mission critical July 6, 2011 Mission critical Táto skupina dát sú najdôležitejšie dáta v spoločnosti. Predstavujú v priemere okolo 15% všetkých dát, ktoré sú uložené na storage zariadeniach. Tieto dáta sú tie, ktoré treba v prípade výpadku informačného systému obnoviť najskôr a sú nevyhnutné na pokračovanie business procesu. Väčšinou z bezpečnostného pohľadu sú tieto dáta klasifikované ako „TAJNÉ“. Strata mission critical dát predstavuje stratu tržieb, potencionálnu stratu zákazníkov a ohrozenie fungovania spoločnosti.
- 31. Klasifikácia dát – Vital July 6, 2011 Vital Tieto dáta sú používané v bežnom business procese, ale nevyžadujú okamžitú obnovu pre zachovanie chodu spoločnosti. Z bezpečnostného pohľadu môžu byť tieto dáta klasifikované ako „TAJNÉ“. Akceptovateľný čas obnovy týchto dát sa pohybuje od sekúnd do niekoľko minút.
- 32. Klasifikácia dát – sensitive July 6, 2011 Sensitive Tieto dáta sú používané v bežnom business procese a ich obnova môže trvať od desiatok minút do niekoľko hodín. Neprítomnosť týchto dát počas doby obnovy vážne neohrozuje prevádzku.
- 33. Klasifikácia dát – Non-critical July 6, 2011 Non-critical V priemere asi 40% všetkých online uložených dát, čo tvorí najväčšiu kategóriu v tejto klasifikácii. Tieto dáta majú nízke bezpečnostné nároky a väčšinou existujú vo viacerých duplicitných kópiách. Stratené, poškodené, alebo zničené dáta môžu byť bez väčších nákladov alebo úsila znovu obnovené. Doba obnovy sa pohybuje rádovo niekoľko dní. Príkladom týchto dát sú Emailové archívy, digitalizované audio/video nahrávky, alebo osobné dátové súbory.
- 36. DAE – Data Allocation Engine – Vision - DAE vychádza z koncepcie SMS - Je to automatizované, alokačnou politikou riadené primárne ukladanie novovznikajúcich dát - Storage zdroje sú postavené ako Active Storage Space/Tiered Storage DAE dnes reálne funguje len v prostredí MainFrame
- 38. SME – Storage Management Engine Jediným cieľom SME je mať neustály prehľad o celom ASS/TS s predikciou do budúcnosti! Dobre postavený SME prinesie nepriamu úmeru TCO………………………………….. Klesá Bus iness….. ……………………….. Rastie
- 41. Metadáta – základ riadenia Administrátorské metadáta – informácie potrebné pre administrátorov Aktívneho Archívu. Technické metadáta – informácie potrebné pre administrátorov a čiastočne aj užívateľov Aktívneho Archívu Užívateľské metadáta – obsahujú množinu informácií potrebných pre užívateľskú prácu s archivovanými dátami. Dôležité sú najmä údaje o integrite dát, pôvode dát, a autentičnosti dát.
- 42. Ako to použiť? July 6, 2011
- 43. Datacenter Complexity Factor – DCF
- 44. Maturity model ILM - stupne
- 45. Maturity model ILM - elementy BRCP BRCP SME DME ASS/TS
- 46. Určenie typu koncového média áno nie áno Štandardizované ukladanie áno áno áno WORM áno nie nie Mixovanie technológií áno nie nie Jednoduchá migrácia áno nie nie Jednoznačný volume mngt. áno áno nie Drive a volume separátne Páska Optický disk Magnetický disk Atribút/typ storage
- 47. WORM problematika – optický disk
- 48. WORM problematika – WORM tape
- 49. WORM problematika – WORM disk
- 50. WORM problematika – WORM SW
- 51. Content Address Storage - CAS
- 53. Miesto pre pásku
- 54. HDD vs páska – kto hodí uterák do ringu? S najväčšou pravdepodobnosťou skončia páska a HDD ako ich dnes poznáme spoločne. Teminátorom bude veľkokapacitná pamäťová jednotka bez pohyblivých súčastí na báze mikročipov alebo holografie, prípadne inej technológie.
- 55. Rozhodnutie je vždy ľahšie ak ... - Klient má klasifikované dáta - Klient má definovanú základnú backup technológiu - Klient má definované koncové médium - Klient má prehľad o vývojových trendoch - Klient má dosť peňazí...
- 56. July 6, 2011 Koncepcie
- 57. Server Centric July 6, 2011
- 58. Storage Centric July 6, 2011
- 59. Network Centric July 6, 2011
- 60. Multilevel Virtual Storage System July 6, 2011
- 61. Multilevel Virtual Storage System v praxi
- 62. Future of Storage Intelligence July 6, 2011
- 64. Tiered Backup July 6, 2011
- 65. Data Management – lokácia enginov FW+SW aktívneho prvku SAN FW diskového poľa Nemá význam ServerFree BCK Nemá význam Nemá význam SW tretích strán LanFree BCK Nemá význam Nemá význam SW tretích strán Lan BCK FW+SW aktívneho prvku SAN Nie je k dispozícii SW tretích strán PIT kópia FW+SW aktívneho prvku SAN FW diskového poľa SW tretích strán SnapShot FW+SW aktívneho prvku SAN FW diskového poľa SW tretích strán Mirror Network centric Storage centric Server centric Technológia/model
- 66. DEDUP - DeDuplication Rozloženie zdrojovej množiny dát a vytvorenie stavebného plánu DEDUP - De-Duplication je metóda vychádzajúca z princípu komprimácie dát
- 67. DEDUP - DeDuplication Použitie stavebných prvkov pre viaceré stavebné plány Otázkou je, kam až ísť pri tejto redukcii z dôvodov integrity a bezpečnosti zálohovaných dát. Evidentná existenčná závislosť prípadnej obnovy od dostupnosti a integrity stavebných plánov, stavebných prvkov a SW nástroja pre rekonštrukciu nepríjemne evokujú myšlienky o spoľahlivosti tejto metódy.
- 72. D2D zálohovanie - Disk-to-disk backup
- 74. Hybrid storage July 6, 2011
- 76. Ako to použiť? July 6, 2011
- 81. VTA 8000 – mo d ular versus device centric
- 84. Virtuálna páska – VTD a HSM
- 86. Logické usporiadanie VTA8000 – LVG a PVG 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
- 87. July 6, 2011 Data Center Consolidation - DCC
- 88. 4 kroky pre úspešnú konsolidáciu/transformáciu
- 92. S6 S7 S8 S9 S10 Server Virtualization Application Stacking Server Virtualization Server Virtualisation Server Consolidation Physical to Virtual = P2V Physical to Physical = P2Pminus >50% Design – virtualizácia a konsolidácia S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S1 S2 S3 S4 S5 S1 S2 S3 S4 S5 SAN V1 V2 V3 V4 V5 V6 V7 V8 V9 V10 SW Application
- 97. July 6, 2011 Diskusia
Notas del editor
- 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
- DEDUP - De-Duplication je v podstate metóda vychádzajúca z princípu komprimácie dát. Veľmi jasne to ukazujú nasledujúce dva obrázky. Zdrojový súbor alebo zdrojová množina dát je analyzovaná v zmysle duplikovania stavebných prvkov tejto množiny a ich umiestnenia. Vytvorí sa stavebný plán na opätovné zloženie zdrojovej množiny. Tento plán je uložený vo forme metadát separátne od jedno-jednoznačných prvkov zdrojovej množiny. Je úplne jasná veľká dôležitosť tohto plánu vo forme metadát, preto musia byť chránené na úrovni primárneho storage zariadenia – RAIDx, Mirror pre prípad zlyhania a taktiež zálohované pre prípad obnovy. Tieto metadáta sú komprimované a ukladané sofistikovaným spôsobom pre dosiahnutie rýchleho vyhľadávania. Vytvorenie metadát ukazuje prvý obrázok, na druhom je znázornená možnosť použiť jedno-jednoznačné prvky zdrojovej množiny ako stavebný materiál pre viaceré plány. To umožňuje ešte viac redukovať objem výstupných zálohovaných dát. Otázkou je, kam až ísť pri tejto redukcii z dôvodov integrity a bezpečnosti zálohovaných dát. Evidentná existenčná závislosť prípadnej obnovy od dostupnosti a integrity stavebných plánov, stavebných prvkov a SW nástroja pre rekonštrukciu nepríjemne evokujú myšlienky o spoľahlivosti tejto metódy. Preto ešte raz treba jasne povedať. Zálohovať treba stavebné plány, stavebné prvky a celý SW systém a to separátne v zmysle koncového médiá, t.j. nemali by byť na jednom páskovom volume stavebné plány a stavebné prvky. Nie je to nič netradičné, potrebu zálohovania vnútorného prostredia nikto nespochybňuje ani pri klasických zálohovacích SW, prípadne virtuálnej páske. DEDUP používa ako koncové médium jedine disk. Kedže je to vždy appliance riešenie, sú konzumované len dedikované zdroje. Je k dispozícii veľmi rýchle zálohovanie, veľmi rýchla obnova a minimálna konzumácia storage priestorov. Je teda možné použiť DEDUP ako PIT kópie, tieto vytvárať v rýchlom slede za sebou vo vysokej frekvencii opakovania a tým sa dostať do kategórie CDP. Dnes sú riešenia DEDUP ponúkané ako nadstavby k existujúcim SW zalohovacím riešeniam, je zatiaľ jediný výrobca vo svete ktorý produkuje toto riešenie ako samostatný celok. Keďže v celom článku nespomínam ani jedného výrobcu, neurobím výnimku ani teraz, prípadní záujemcovia nájdu na konci článku moju kontaktné údaje a prosím „Do not hesitate“ s otázkami. DEDUP má podľa viacerých zdrojov pred sebou sľubnú budúcnosť. Je to riešenie, ktoré dnes podporujú aj najväčšie firmy v tomto obore - „Do not hesitate with questions“, pre zákazníkov prináša možnosť významne šetriť storage zdroje ako koncové zálohovacie zariadenia a podľa niektorých vyjadrení je to ďalší klinec do rakvy s páskovou mechanikou.
- DEDUP - De-Duplication je v podstate metóda vychádzajúca z princípu komprimácie dát. Veľmi jasne to ukazujú nasledujúce dva obrázky. Zdrojový súbor alebo zdrojová množina dát je analyzovaná v zmysle duplikovania stavebných prvkov tejto množiny a ich umiestnenia. Vytvorí sa stavebný plán na opätovné zloženie zdrojovej množiny. Tento plán je uložený vo forme metadát separátne od jedno-jednoznačných prvkov zdrojovej množiny. Je úplne jasná veľká dôležitosť tohto plánu vo forme metadát, preto musia byť chránené na úrovni primárneho storage zariadenia – RAIDx, Mirror pre prípad zlyhania a taktiež zálohované pre prípad obnovy. Tieto metadáta sú komprimované a ukladané sofistikovaným spôsobom pre dosiahnutie rýchleho vyhľadávania. Vytvorenie metadát ukazuje prvý obrázok, na druhom je znázornená možnosť použiť jedno-jednoznačné prvky zdrojovej množiny ako stavebný materiál pre viaceré plány. To umožňuje ešte viac redukovať objem výstupných zálohovaných dát. Otázkou je, kam až ísť pri tejto redukcii z dôvodov integrity a bezpečnosti zálohovaných dát. Evidentná existenčná závislosť prípadnej obnovy od dostupnosti a integrity stavebných plánov, stavebných prvkov a SW nástroja pre rekonštrukciu nepríjemne evokujú myšlienky o spoľahlivosti tejto metódy. Preto ešte raz treba jasne povedať. Zálohovať treba stavebné plány, stavebné prvky a celý SW systém a to separátne v zmysle koncového médiá, t.j. nemali by byť na jednom páskovom volume stavebné plány a stavebné prvky. Nie je to nič netradičné, potrebu zálohovania vnútorného prostredia nikto nespochybňuje ani pri klasických zálohovacích SW, prípadne virtuálnej páske.
- 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 .
- Device centric koncepcia je pomerne uzavretá na rozširovanie. Dnes jediným reprezentantom tejto koncepcie je SUN VSM virtualizácia pre zOS
- 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.