Storage con v01

2,790 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
2,790
On SlideShare
0
From Embeds
0
Number of Embeds
28
Actions
Shares
0
Downloads
3
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
  • 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.
  • Storage con v01

    1. 1. Information Lifecycle Management – ILM S tor ageC on s.r.o , Consulting,Concept,Control Jaroslav Pudelka „ To Show Quality“
    2. 2. Jaroslav Pudelka 29 rokov v IT
    3. 3. Motto: „Hope is not a strategy“
    4. 4. Prelet nad profesionálnou dráhou <ul><li>14 rokov od operátora až po zástupcu riaditeľa IT vo VUB </li></ul><ul><li>7 rokov ako VAR pre StorageTek </li></ul><ul><li>2 roky v HP ako Solution architect </li></ul><ul><li>S polumajiteľ Storyflex Slovakia s.r.o. </li></ul><ul><li>Founder,Owner,Donor of StorageCon s.r.o., Strategic Storage Consultant </li></ul><ul><li>Projekty </li></ul><ul><ul><li>CDU a Virtual tape pre Český Telekom </li></ul></ul><ul><ul><li>CDU pre Komerční Banku </li></ul></ul><ul><ul><li>CDU pre ČNB </li></ul></ul><ul><ul><li>CDU a Virtual tape pre Škoda MB </li></ul></ul><ul><ul><li>Archivácia pre Český Telekom </li></ul></ul><ul><ul><li>Tape drive sharing medzi zOS a OS pre Škoda MB </li></ul></ul><ul><ul><li>CDU a zdieľanie páskových mechaník pre Českú spořitelnu </li></ul></ul><ul><ul><li>Zálohovanie Slovnaft </li></ul></ul><ul><ul><li>CDU pre Orange </li></ul></ul><ul><ul><li>Virtual Storage System pre T-COM </li></ul></ul><ul><ul><li>Virtual Storage System pre VUB </li></ul></ul><ul><ul><li>MultiLevel Virtual Storage System pre Nokia Siemens Network </li></ul></ul><ul><ul><li>Storage analýzy pre Allianz SP, SLSP, Transpetrol </li></ul></ul>
    5. 5. Koncepcie <ul><li>Information Lifecycle Management – ILM </li></ul><ul><li>ASS/TS – Active Storage Space/Tiered Storage </li></ul><ul><li>FoIS – Future of Intelligence Storage </li></ul><ul><li>MVSS – Multilevel Virtual Storage System </li></ul><ul><li>VEP – Virtual Emulation Point </li></ul><ul><li>HSM </li></ul><ul><li>Virtual Tape </li></ul>
    6. 6. Goal: „Data is always there“
    7. 7. July 6, 2011 Mainframe – sila DNA
    8. 8. Katalóg versus slash July 6, 2011 <ul><li>Spôsob ukladania dát je jeden zo zásadných rozdielov, pričom fatálne ovplyvňuje riadenie fyzických dát </li></ul><ul><li>Mainframe má katalóg a ukladanie dát sa riadi cez názvoslovie súborov </li></ul><ul><ul><li>Na LVOL nesmú byť súbory s rovnakým menom </li></ul></ul><ul><ul><li>V rámci katalógu nesmú byť súbory s rovnakým menom </li></ul></ul><ul><ul><li>Ak je súbor v katalógu, vyhľadáva sa cez meno alebo jeho časť </li></ul></ul><ul><ul><li>Katalóg sú vlastne metadáta s popisom vlastností súboru ako fyzickej dátovej množiny </li></ul></ul><ul><ul><li>Táto koncepcia je základom pre automatizované riadenie ukladania dát </li></ul></ul><ul><li>OS nepoužíva katalóg a ukladanie dát riadi popisným spôsobom </li></ul><ul><ul><li>Na LVOL môžu byť súbory s rovnakým menom </li></ul></ul><ul><ul><li>Na vyhľadanie súboru treba exaktne popísať cestu </li></ul></ul><ul><ul><li>Neexistujú metadáta na úrovni operačného systému </li></ul></ul><ul><ul><li>Pre automatizované ukladanie dát nie je vytvorené natívne systémové prostredie </li></ul></ul>
    9. 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. 10. Hierarchical Storage Management – HSM
    11. 11. Hierarchical Storage Management – HSM
    12. 12. HSM podľa ILM <ul><li>Klasické HSM </li></ul><ul><ul><li>Migrácia </li></ul></ul><ul><ul><li>Recall </li></ul></ul><ul><ul><li>Backup </li></ul></ul><ul><ul><li>Archív </li></ul></ul><ul><ul><li>Vonkajšie atribúty </li></ul></ul><ul><li>HSM ako časť ILM </li></ul><ul><ul><li>Migrácia </li></ul></ul><ul><ul><li>Recall </li></ul></ul><ul><ul><li>Moving </li></ul></ul><ul><ul><li>Interné atribúty </li></ul></ul>
    13. 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)
    14. 14. Zápis na RTD Volume Stacking PV4060 PV-Header <ul><li>CentricStor 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
    15. 15. Virtual Tape – level one <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>
    16. 16. Virtual Tape – level two <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>
    17. 17. July 6, 2011 Open system – migrácia riešení
    18. 18. Systémovo riadená storage July 6, 2011 <ul><li>Dnes nie je relevantný produkt na trhu </li></ul><ul><ul><li>Nie je štandardizované prostredie OS </li></ul></ul><ul><ul><li>Neexistuje katalógová štruktúra ukladania dát </li></ul></ul><ul><ul><li>Koncepcia riešenia bude postavená na samostatnom SMS servri </li></ul></ul>Očakáva sa migrácia tohto riešenia z prostredia mainframe
    19. 19. Hiera r chical Storage Management v OS <ul><li>Klasické HSM </li></ul><ul><ul><li>Migrácia </li></ul></ul><ul><ul><li>Recall </li></ul></ul><ul><ul><li>Backup </li></ul></ul><ul><ul><li>Archív </li></ul></ul><ul><ul><li>Vonkajšie atribúty </li></ul></ul><ul><li>HSM ako časť ILM </li></ul><ul><ul><li>Migrácia </li></ul></ul><ul><ul><li>Recall </li></ul></ul><ul><ul><li>Moving </li></ul></ul><ul><ul><li>Interné atribúty </li></ul></ul>HSM v OS je server centric riešenie
    20. 20. Hierarchical Storage Management - LOB July 6, 2011
    21. 21. Hierarchical Storage Management -aplikácia July 6, 2011
    22. 22. Hierarchical Storage Management – setup July 6, 2011
    23. 23. Hierarchical Storage Management – tiered storage July 6, 2011
    24. 24. Virtualizácia v prostredí OS July 6, 2011
    25. 25. Virtual Tape – level one <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><ul><li>Appliance riešenie </li></ul>
    26. 26. July 6, 2011 Information Lifecycle Management - ILM
    27. 27. Základný kameň ILM
    28. 28. O čo ide? July 6, 2011
    29. 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. 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. 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. 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. 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.
    34. 34. 5 pilierov ILM 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>
    35. 35. BRCP – Bussiness Requirements Converting to Policy <ul><li>Dnes len v polohe vízie </li></ul><ul><li>Uplatňuje sa až v stupni Proactive a vyššie </li></ul>Business Interface
    36. 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
    37. 37. DME – Data Management Engine <ul><li>DME je aj HSM </li></ul><ul><li>Migra čná politika je nastavená podľa </li></ul><ul><ul><li>Vonkajších atribútov </li></ul></ul><ul><ul><li>Vnútorných atribútov – vision </li></ul></ul><ul><li>DME je BCK </li></ul><ul><li>DME je OAIS </li></ul><ul><li>DME je management dát </li></ul><ul><li>podľa ich klasifikácie </li></ul>
    38. 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
    39. 39. 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
    40. 40. Storage hierarchia
    41. 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. 42. Ako to použiť? July 6, 2011
    43. 43. Datacenter Complexity Factor – DCF
    44. 44. Maturity model ILM - stupne
    45. 45. Maturity model ILM - elementy BRCP BRCP SME DME ASS/TS
    46. 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. 47. WORM problematika – optický disk
    48. 48. WORM problematika – WORM tape
    49. 49. WORM problematika – WORM disk
    50. 50. WORM problematika – WORM SW
    51. 51. Content Address Storage - CAS
    52. 52. 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
    53. 53. Miesto pre pásku
    54. 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. 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. 56. July 6, 2011 Koncepcie
    57. 57. Server Centric July 6, 2011
    58. 58. Storage Centric July 6, 2011
    59. 59. Network Centric July 6, 2011
    60. 60. Multilevel Virtual Storage System July 6, 2011
    61. 61. Multilevel Virtual Storage System v praxi
    62. 62. Future of Storage Intelligence July 6, 2011
    63. 63. Common Tiered Storage
    64. 64. Tiered Backup July 6, 2011
    65. 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. 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. 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.
    68. 68. LAN backup <ul><li>Klasický Disk-to-tape backup </li></ul><ul><ul><li>Lan backup </li></ul></ul>
    69. 69. LanFree Backup <ul><li>Klasický Disk-to-tape backup </li></ul><ul><ul><li>LanFree backup </li></ul></ul>
    70. 70. ServerFree Backup <ul><li>Klasický Disk-to-tape backup </li></ul><ul><ul><li>ServerFree backup </li></ul></ul>
    71. 71. D2T a D2D2T zálohovanie <ul><li>Disk-to-disk-to-tape backup </li></ul><ul><ul><li>Split mirror backup </li></ul></ul><ul><ul><li>Disk-to-disk and HSM to tape backup </li></ul></ul><ul><ul><li>Virtual Tape backup </li></ul></ul>
    72. 72. D2D zálohovanie - Disk-to-disk backup
    73. 73. Zálohovacie koncepcie -sumarizácia
    74. 74. Hybrid storage July 6, 2011
    75. 75. Spindown technológie
    76. 76. Ako to použiť? July 6, 2011
    77. 77. 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>
    78. 78. VTA 8000 – z ákladná architektúra <ul><li>Je to modulárne riešenie </li></ul><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><ul><li>Riadenie cez GXCC pre celý CentricStor </li></ul><ul><li>Riadenie cez XTCC pre jednotlivé komponenty </li></ul>Základné moduly ICP IDP VLP VTC
    79. 79. VTA 8000 – 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><ul><li>Kapacita VTC je 10,8 TB čistej kapacity per site </li></ul><ul><li>Priepustnosť je 0,8 GB/s native </li></ul><ul><li>Pre zrkadlenie VTC sú navrhnuté 4 FC linky zapojené z </li></ul><ul><li>internej SAN VTA8000 priamo do direktorov </li></ul>
    80. 80. VTA 8000 - konfigurácia <ul><li>4 x ICP per site </li></ul><ul><li>2 x IDP per site </li></ul><ul><li>10,6 TB VTC per site </li></ul><ul><li>1 x VLP per site </li></ul><ul><li>2 x internal FC switch per site </li></ul><ul><li>2 x internal LAN switch per site </li></ul><ul><li>Redundant PDU, ... </li></ul>
    81. 81. VTA 8000 – mo d ular versus device centric
    82. 82. VTA 8000 – mo d ular versus device centric, cont . <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>
    83. 83. 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><ul><li>Na úrovni SMC/CSC </li></ul></ul><ul><ul><li>Na úrovni TSM </li></ul></ul><ul><ul><li>Na úrovni VTA8000 </li></ul></ul><ul><li>HSM na VTD </li></ul>
    84. 84. Virtuálna páska – VTD a HSM
    85. 85. 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 v príprave pre verziu 4.0 VTA </li></ul>
    86. 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. 87. July 6, 2011 Data Center Consolidation - DCC
    88. 88. 4 kroky pre úspešnú konsolidáciu/transformáciu
    89. 89. <ul><ul><ul><li>Only when the complete context and the workload in the Data Center is properly understood and represented, a successful consolidation strategy can be designed. </li></ul></ul></ul><ul><ul><ul><li>Different kind of assessments might be necessary during the project, individual or in various combinations: </li></ul></ul></ul><ul><ul><ul><ul><li>Server Assessment </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Storage Assessment </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Desktop Assessment </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Network (IP and SAN) Assessment </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Security Assessment </li></ul></ul></ul></ul><ul><ul><ul><ul><li>IT Compliance Assessment </li></ul></ul></ul></ul>Assessment
    90. 90. <ul><li>Information from interviews, documents, tools, CMDB, inspection etc. </li></ul>Assessment – zber relevantných údajov
    91. 91. <ul><li>Different responsibilities </li></ul><ul><li>Only partial information available </li></ul><ul><li>Chaotic flow of information </li></ul><ul><li>Different answers to similar questions </li></ul><ul><li>Status of the Data Center changes during the assessment </li></ul>Assessment – niektoré problémy Data Sources Config. Management Asset Management Spreadsheets Capacity Data Hardware Refresh Upgrade / Patch Application Deploy EOSL Virtualization Planning
    92. 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
    93. 93. <ul><li>Consolidation P2V </li></ul><ul><ul><li>Target: Replacement of old Hardware (CAPEX) </li></ul></ul><ul><ul><li>Running old Applications/OS’s in VMs </li></ul></ul><ul><ul><li>Less physical servers but no reduction of administration effort (OPEX) </li></ul></ul><ul><ul><ul><ul><li>Security Patches/Updates </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Application Updates </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Backup </li></ul></ul></ul></ul><ul><ul><li>Runs with old /incompatible Software </li></ul></ul><ul><ul><li>Initializes “VM SPRAWL” ?? </li></ul></ul><ul><ul><li>Bottleneck’s for DB or other I/O intense Applications </li></ul></ul><ul><li>Consolidation in a virtual cluster </li></ul><ul><li>Target: Consolidation of administration (OPEX) and HW (CAPEX) </li></ul><ul><li>50% less management points and therefore less administrative effort </li></ul><ul><ul><li>Fewer patching for OS’s necessary </li></ul></ul><ul><ul><li>Fewer Application Images to update </li></ul></ul>NT4 NT4 W2k W2k3 W2k Partitioning a big server into small, logical servers! Combination of many servers onto one central cluster! NT4 NT4 W2k W2k3 W2k Design – management points Application Stacking SQL SQL SQL SQL SQL SQL SQL SQL FS1 FS1 FS1 FS1 FS1 ORA ORA ORA ORA ORA FS2 FS2 FS2
    94. 94. Design – CAPEX versus OPEX CAPEX OPEX <ul><ul><li>Combination of regional Data Centers </li></ul></ul><ul><ul><li>Virtualization </li></ul></ul><ul><ul><li>Server Consolidation </li></ul></ul><ul><ul><li>Database Consolidation </li></ul></ul><ul><ul><li>OS Stacking, Applikations Stacking </li></ul></ul><ul><ul><li>Outsourcing </li></ul></ul><ul><ul><li>Standardization of Plattforms </li></ul></ul><ul><ul><li>Reduction of Management Points </li></ul></ul><ul><ul><li>Saving Energy </li></ul></ul><ul><ul><li>Software (Application) Consolidation </li></ul></ul>
    95. 95. <ul><ul><ul><li>Developing a phase plan for migration commissioning. </li></ul></ul></ul><ul><ul><ul><li>Analysis “snapshot refresh” of the Data Center to control the implementation. </li></ul></ul></ul><ul><li>Adaption of server / storage / infrastructure configuration. </li></ul><ul><li>Implementation by internal or external by service partners </li></ul><ul><li>Process Control (PMO, change/release management) </li></ul>Existing Data Center Migration – nasadenie riešenia
    96. 96. <ul><ul><ul><li>The complete Data Center has to be monitored continuously - regarding capacity and performance, </li></ul></ul></ul><ul><ul><ul><li>Rules for server workload, network infrastructure and costs e.g. support have to be considered. </li></ul></ul></ul><ul><ul><ul><li>Post-Implementation Review: </li></ul></ul></ul><ul><ul><li>Strategy Review. </li></ul></ul><ul><ul><li>Comparison of modelled to real workload and overhead. </li></ul></ul><ul><ul><li>Tuning. </li></ul></ul><ul><ul><li>Continuous consolidation, rebalancing and de-consolidation. </li></ul></ul><ul><ul><li>Image catalogue and management of virtual environment. </li></ul></ul>Optimalizácia – nekonečný proces
    97. 97. July 6, 2011 Diskusia

    ×