CURS Nivele de management al SAN Nivelul de stocare *I LTO Tape Library Specialist

Transcription

1 CURS Nivele de management al SAN Arhitectura de management a SAN poate fi divizată în 3 nivele distincte (fig.6_1) : (a) nivelul de stocare al SAN; (b) nivelul de reţea; (c) Nivelul sistemelor întreprinderii Nivelul de stocare este compus din diferite DS-uri (discuri, subsisteme de tip disk array (fig. 6_17, alte tipuri la benzi şi biblioteci de benzi (foto ). Deoarece configuraţia unei resurse de stocare trebuie să fie integrată cu configuraţia vederii logice pe care serverul o are asupra acesteia, managementul nivelului de stocare priveşte atât resursele de stocare cât şi serverele. Actual se utilizează intensiv protocolul serial ANSI SCSI-3, utilizat înainte în conexiunile SCSI şi actual peste FCP. ANSI SCSI-3 a definit de asemenea şi un nou set de comenzi, numit SES (SCSI Enclosure Services) pentru starea de bază a storage enclosures. (Wikipedia: Disk enclosure se referă în mod obişnuit la un dispozitiv care poate reţine un număr de discuri (uzual >=4) şi care poate comunica cu un server printr-un protocol SCSI sau FC. Pe de altă parte, un disk array reprezintă un sistem de stocare la nivel de întreprindere care conţine mai multe drivere de disc. Se deosebeşte de un disk enclosure prin aceea că un array are cache şi inteligenţă incorporată, a.î. poate să realizeze funcţii ca RAID-ul şi virtualizarea). Componentele uzuale ale unui disk-array sunt: controller, cache, disk-enclosure, sursă de putere). Pentru nivel de management aferent stocării există mai multe produse soft. De ex. IBM a dezvoltat clasa de produse SW cu nume sugestive, de tip IBM TotalStorage În continuare vom nota prescurtarea neconsacrată *I pentru IBM TotalStorage. Ex. de astfel de produse: 1. *I DS Storage Manager interfaţă GUI bazată pe Web. Permite realizarea directă de configurări logice, management servicii de copiere şi pentru upgradări firmware. 2. *I Enterprise Storage Server Specialist. Permite administratorilor să configureze, monitorizeze şi să administreze de la distanţă, dintr-o punct central, ESS-ul prin intermediul unei interfeţe Web. 3. *I Enterprise Storage Server Expert : a) ajută la optimizarea performanţelor susbsistemelor cu disc sau bandă (dacă este utilizat împreună cu *I Tape Library Specialist); b) mapare discuri host via LUN, furnizând totodată şi informaţii complete asupra volumelor logice incluzând discuri fizice şi adaptoare; c) personalizează şi permite detecţia unor evenimente threshold (aferente depăşirii unor valori prag) relative la performanţele şi utilizarea ESS; d) utilizează alerte SNMP asociate declanşării unor evenimente aferente operării ESS (depăşiri valori prag); e) furnizează statistici pentru a ajuta administrarea ESS; f) urmăreşte capacităţile: totală, utilizată, liberă pentru toate ESS-urile conectate din întreprindere; g) furnizează informaţii despre sistemele (cum ar fi z/os şi UNIX) care partajează volume dintr-un ESS; h) ajută la centralizarea managementului mai multor sisteme plasate prin întreprindere aflate la distanţă. 4. *I LTO Tape Library Specialist permite administratorilor să monitorizeze şi să administreze de la distanţă, printr-o interfaţă Web, dintr-un punct central, toate bibliotecile din familia LTO Tape Library. 5. *I ETL Expert : a) furnizează starea în timp real a indicatorilor cheie relativi la serverul Tape Library & Virtual Tape; b) oferă metrici de performanţă uşor de accesat care include informaţii asupra administrări cache-ului Tape Volume Cache, asupra fragmentării volumului logic şi throttling-ului (Wekepedia: throttling limitare a numărului de cereri care vor fi satisfăcute de către un dispozitiv accesat în mod concurent, pentru a asigura funcţionarea necongestionată şi continuă a acestuia); c),d) - idem *I Enterprise Storage Server Expert e) monitorizează şi urmăresc performanţele ESS-urilor; f) utilizează o arhitectură bazată Web care permite administratorilor să monitorizeze subsistemele disc şi bandă indiferent de locaţia lor. Curs6 / 1 Fig. 6_17

2 6. FAStT Storage Manager este un instrument intuitiv pentru administrarea/managementul centralizat, ale cărui principale funcţii sunt descrise în continuare: (a) gestionează mai multe FAStT de la o singură consolă; (b) gestionează şi configurează FlashCopy şi mirroring; (c) expansiune şi configurare dinamică a volumelor; (d) instrument pentru raportare erori şi diagnosticare relativ la componentele subsistemului; (e) monitorizare performanţe; (f) partiţionare stocare. (Wikipedia: Un driver logic FlashCopy reprezintă o imagine instantanee a unui driver logic. Este echivalent logic cu o copie fizică, dar este creat mult mai rapid decât aceasta. În plus necesită şi mai puţin spaţiu disc. În mod tipic un Flash Copy este creat a.î. o aplicaţie (de ex. SW de backup) să poată accesa FlashCopy-ul şi să poată citi datele în timp ce dispozitivul de pe care s-a făcut copierea rămâne online şi este accesibil utilizatorilor) 7. *I Productivity Center: - permite gestionarea utilizării capacităţii şi a disponibilităţii sistemelor de stocare, a sistemelor de fişiere şi a bazelor de date; - permite gestionarea, monitorizarea şi controlul (zone) componentelor fabric-ului; - permite monitorizarea şi urmărirea performanţelor DS-urilor compliante SMI-S ataşate la SAN; - permite gestionarea serviciilor de replicare avansate Nivelul reţea este compus din componente diferite care furnizează conectivitatea, cum ar fi cabluri, switch-uri, legături inter-switch, gateway, routere şi HBA-uri. Acest nivel devine strâns legat de infrastructurile inter-networking cum sunt de ex. soluţiile LAN şi SAN. Componentele aferente lucrului în reţea (le vom nota CR) folosite în soluţiile LAN/WAN folosesc caracteristicile care oferă suport SNMP pentru a furniza managementul tuturor CR-urilor. Majoritatea vendorilor de soluţii SAN autorizează suportul SNMP pentru toate CR-urile lor, acesta urmând să fie apoi utilizat şi exploatat prin intermediul aplicaţiilor de management al reţelelor bazate pe SNMP pentru a raporta apoi diferitelor discipline din categoria aplicaţiilor de management pentru SAN Nivelul sistemelor întreprinderii asigură în principal capacit. de a avea o singură consolă şi o singură vedere managerială. AM-urile de la acest nivel trebuie să integreze datele de management şi să le prezinte apoi într-un format uşor de înţeles. Aceste date provin din nivele diferite ale infrastructurii întreprinderii, incluzând aici DS, reţele, servere şi desktopuri, adesea fiecare dintre ele rulând propria sa AM. În plus, dezvoltarea rapidă a soluţiilor bazate pe Internet din întreprindere a impus utilizarea unor instrumente de management bazate pe Web. Astăzi se dezvoltă şi definesc diferite iniţiative larg utilizate în industrie, cum ar fi: WBEM (Web-Based Enterprise Management), CIM, DMI (Desktop Management Interface) şi JMAPI (Java Management Programming Interface). Scopul acestora este crearea unui anumit tip de nivel al standardizării managementului Aplicaţii pentru managementul SAN Fiecare vendor din portofoliul *I SAN furnizează propriile sale aplicaţii pentru managementul şi controlul SAN. Aria de aplicabilitate a acestor aplicaţii se intersectează mult cu managementul reţelelor de calculatoare, încât în continuare se vor furniza doar informaţii succinte relative la două dintre cele mai cunoscute. *I b-type family reprezintă un cadrul de lucru proiectat pentru a oferi suport celor mai multe soluţii, plecând de la SAN-uri pentru grupuri de lucru f. mici şi ajungând la SAN-uri pentru întreprinderi f. mari. Opţiunile de tip switch management includ WEBTOOL-uri bazate pe browsere, Fabric Manager şi interfeţe bazate pe standarde deschise pentru manageri de SAN-uri la nivel de întreprindere. Următoarele interfeţe permit monitorizarea topologiei fabricului, a stării porturilor, a stării fizice şi a altor informaţii care ajută la operaţiile de debugging al sist. şi pentru analize de performanţă: (a) CLI prin conectare Telnet; (b) Instrumente Web avansate; (c) Servicii SES; (d) aplicaţii SNMP; (e) Management server. Fabric Manager şi Device Manager reprezintă instrumentele centralizate folosite pentru a gestiona atât fabric-ul pentru SAN de tip Cisco cât şi dispozitivele conectate la acesta. Fabric Manager furnizează un rezumat al informaţiilor de nivel înalt despre toate switchurile dintr-un fabric şi lansează în mod automat interfaţa Web Tools atunci când sunt necesare informaţii mai detaliate. Câteva dintre capabilităţile Fabric Manager: Curs6 / 2

3 - configurează şi gestionează fabricul pe mai multe nivele; - grupează în mod inteligent obiecte SAN şi funcţii de management SAN pentru ca sarcinile administrative să se desfăşoare uşor şi în timp util; - identifică, izolează şi gestionează evenimente SAN aferente multor switch-uri şi fabricuri; - furnizează capabilităţi drill-down (căutare prin rafinare, de la general la particular) pentru componente SAN individuale prin integrarea de Web Tools şi Fabric Watch; - detectează toate componentele SAN şi vizualizează starea în timp real a tututor fabricurilor; - furnizează administrarea multi-fabric, printr-o singură consolă criptată, folosind Secure Fabric OS (Wikipedia: Fabric OS (FOS) reprezintă un SO bazat pe Linux, dezvoltat pentru medii SAN). Secure Fabric OS (SFOS) reprezintă un produs licenţiat); - monitorizează ISL uri (ISL-Internet Switch Link), etc Software SAN multipathing Într-un SAN bine proiectat, adesea se doreşte ca un dispozitiv să poată fi accesat de către aplicaţia host pe mai multe căi (paths), în scopul de a obţine performanţe potenţial mai bune, şi pentru a ajuta recurperarea în cazul în care s-ar defecta un adaptor, cablu, switch sau un transceiver. Dacă există mai multe astfel de căi, acelaşi LUN poate fi prezentat de mai multe ori gazdei, câte o dată pentru fiecare cale posibilă către LUN. Pentru a evita acest lucru, a uşura administrarea dispozitivului şi a elimina confuzia, este necesar SW multipathing. Acesta va face ca fiecare LUN să fie vizibil o singură dată din punctul de vedere al aplicaţiei şi al SO-ului. În plus, SW-ul multipathing mai are două sarcini: - Recuperare în urma unei căderi: atunci când o componentă implicată în conectarea LUN nu funcţionează corect, SW-ul multipathing trebuie să redirecteze traficul de date pe alte căi posibile; - Echilibrarea sarcinilor (Load Balancing) SW-ul multipathing trebuie să poată echilibra în mod echitabil traficul de date de-a lungul căilor disponibile de la host-uri la LUN-uri. În continuare se prezintă câteva SW-uri de tip multipathing: 1. IBM Data Path Optimizer (DPO) face posibilă comutarea dinamică a căilor (atunci când acestea sunt asignate), în medii Windows/UNIX, asigurând un grad mare de disponibilitate şi de asemenea asigură un algoritm de echilibrare a încărcării care poate să îmbunătăţească mult performanţele şi throughput-ul. (Wikipedia: throughput reprezintă viteza cu care un calculator sau o reţea trimit/recepţionează date. De aceea este o bună metodă pentru evaluarea capacităţii de canal aferente unei legături de comunicaţie). 2. IBM Subsystem Device Driver (SDD) reprezintă un pseudo driver de dispozitiv proiectat pentru a oferi suport mediilor cu configuraţii multipath din IBM ESS. Oferă funcţii ca: (a) Disponibilitate mai bună a datelor; (b) Echilibrare dinamică a sarcinii I/O pe mai multe căi; (c) Protecţie automată la căderea unei căi; (d) Politici pentru selectarea path-ului. 3. IBM Redundant Disk Array Controller (RDAC) reprezintă un driver FC care implementează atât refacerea în urma căderii unei căi cât şi echilibrarea sarcinii pentru mai multe platforme. Se utilizează împreună cu *I DS şi FAStT Server Family. 4. IBM Multi-Path Proxy driver (cunoscut şi sub numele de Multi-Path Proxy (MPP) driver) reprezintă o arhitectură nouă de driver care se foloseşte pentru noile versiuni de drivere multipath pentru Windows 2000/2003 şi Linux Izolarea defectelor şi a problemelor dintr-un SAN Determinarea problemelor şi identificarea sursei acestora (Problem determination and problem source identification PD/PSI) reprezintă un aspect care trebuie luat în considerare uneori chiar dinainte ca un SAN să fie implementat. Există numeroase mijloace prin care se pot colecta datele necesare pentru a realiza PD/PSI. Un depanator al SAN trebuie să aibă un set minim de aptitudini, descrise în continuare: - să poată interoga SAN; - să găsească dispozitivele sau LUN-urile care lipsesc; - să poată să identifice cablurile defecte; Curs6 / 3

4 - să poată să interpreteze mesajele şi logurile cu erori; - să ştie de unde încep defectele; - să ştie să înregistreze informaţiile într-o manieră ordonată; - să creeze diagrama SAN-ului; - să acceseze serverul de nume; - să acceseze informaţiile despre porturi şi transceivere; - să înţeleagă semnificaţia LED-urilor de la switchuri; - să ştie să utilizeze instrumentele de diagnosticare specifice vendorului; - să găsească mesajele de eroare la host sau la DS; - să verifice conflictele de tip zoning; - să ştie să utilizeze tehnicile ping şi traceroute. Specialiştii mai avansaţi pot solicita acces la un analizor de canal fibră. În termenii PD/PSI un proiect SAN care poate fi considerat bun este acela la care informaţiile relative la configuraţie sunt uşor de înţeles, disponibile la orice nivel şi sunt totdeauna actualizate la ultima configuraţie. Totdeauna trebuie să existe o bază de date în care să se afle informaţii despre conexiuni, convenţii de denumiri, numere seriale de dispozitive, WWW, zoning, aplicaţii sistem, etc Soluţii SAN şi detalii de exploatare Caseta cu instrumente pentru proiectarea SAN În acest paragraf se prezintă doar o descriere generală a aplicaţiilor SAN precum şi a tipurilor de componente necesare pentru a le implementa. Problematica este însă mult mai complexă. O reprezentarea de nivel înalt a unui SAN capătă adesea forma unui nor care prezintă linii de conectare de la nor la servere şi la DS-uri. Pentru a reprezenta componentele din care este format norul, se poate folosi caseta cu instrumente din fig. 6_18. Caseta conţine toate blocurile de construcţie (sau instrumentele) necesare pentru a construi un SAN. Există 5 blocuri constructive: - Servicii : termenul de serviciu se poate aplica acţiunilor de tip suport, educaţie, consultanţă ş.a.m.d. ; - Elemente de stocare, aici intrând: drivere şi biblioteci de benzi, DS de tip disc, DS de tip optic şi respectiv servere inteligente de stocare (definite ca subsisteme de stocare care sunt prevăzute individual cu un Fig. 6_18 Curs6 / 4 procesor de control al stocării, cache aferent stocării şi algoritmi de management al cache-ului); - Fabricul SAN-ului. Elementele de interconectare transferă pachete FC între server şi DS, de la server la server şi de la DS la DS, în funcţie de configuraţiile suportate şi de funcţia utilizată; - Serverele conectate la Fabric. Pe acestea se rulează aplicaţii care beneficiază de facilităţile SAN; - Software. Există două tipuri de aplicaţii pentru managementul stocării: (a) aplicaţii pentru managementul fabric-ului, folosite pentru a configura, gestiona şi controla fabricul SAN-ului; (b) aplicaţii care exploatează funcţiile SAN în scopul de a aduce beneficii afacerii, cum sunt de exemplu soluţii îmbunătăţite pentru backup/recovery şi mirror la distanţă Adăugarea de capacitate de stocare

5 Adăugarea de capacitate de stocare la unul sau mai multe servere poate fi facilitată atunci când DS este conectat la un SAN. În funcţie de configuraţia SAN-ului şi de SO-ul serverului, poate fi posibilă adăugarea/îndepărtarea unui dispozitv fără a fi necesară oprirea sau restartarea serverului. Dacă se ataşează noi DS-uri la o secţiune dintr-un SAN cu topologie de tip loop (în special cazul driverelor de bandă), operaţiunile de adăugare/înlăturare de capacitate de stocare pot avea un anumit impact asupra funcţionării altor dispozitive din buclă. Acest neajuns poate fi depăşit dacă se reduce activitatea SOului din toate dispozitivele plasate pe bucla respectivă înaintea ataşării noului dispozitiv. Problema este mult simplificată atunci când se utilizează ultima generaţie de switch-uri, de tip loop-capable. Dacă se ataşează DS-uri la un SAN prin intermediul unui switch, prin SW-ul de management DS-urile respective pot fi puse la dispoziţia oricărui sistem conectat la SAN Tehnica disk pooling Prin tehnica disk-pooling mai multe servere pot utiliza în comun un pool (bazin) comun de DS de tip disk ataşate la un SAN. Resursele de stocare aferente discurilor sunt reunite (pooled) în interiorul unui singur subsistem-disc, dar pool-ul poate fi găzduit şi de mai multe subsisteme disc. Capacitatea este atribuită unor sisteme de fişiere independente suportate de SO-urile serverelor. Serverele pot fi de tipuri diferite, uzual UNIX, Windows NT şi succesorii, sau chiar OS/390. Se poate adăuga în mod dinamic capacitate de stocare la pool, aceasta putând fi atribuită (asignată) oricărui server ataşat la SAN, când şi unde este nevoie. Acest lucru furnizează un acces eficient la resurseledisc partajate, fără a mai exista un nivel de indirectare asociat unui server de fişiere separat, deoarece stocarea este efectiv ataşată direct tuturor serverelor, iar eficienţa şi scalabilitatea sunt rezultate ale consolidării capacităţii de stocare. Se poate folosi tehnica zoning pentru a restricţiona accesul la capacitatea adăugată. Deoarece la un singur port se pot ataşa mai multe dispozitive (sau LUN-uri), accesul poate fi restricţionat folosind tehnica LUN-masking, prin care se poate specifica cine poate accesa un anumit dispozitiv sau LUN. Ataşarea/detaşarea DS-urilor poate fi făcută sub controlul unei interfeţe administrative comune. În fig.6_19 se prezintă un ex. de disk-pooling utilizat de două servere. În acest ex., unuia dintre servere i se asignează un pool de discuri formatat conform cerinţelor impuse de sistemul de fişiere, pe când celuilalt server i se atribuie un alt pool, probabil formatat în mod diferit. Cel de-al 3- lea pool figurat poate conţine un spaţiu care încă nu a fost alocat, sau poate fi reprezentat de un spaţiu-disc preformatat în vederea unei posibile utilizări ulterioare Tehnica tape-pooling Fig. 6_19 Curs6 / 5

6 Tehnica tape-pooling rezolvă problema întâlnită actual în mediile de tip open system în care mai multe servere nu pot partaja resurse de tip bandă atunci când sunt implicate mai multe hosturi. Vechile metode folosite pentru partajarea unui dispozitiv între hosturi constau fie în comutarea manuală a dispozitivului de tip bandă de la un host la altul, fie în scrierea unor aplicaţii care comunicau cu serverele conectate utilizând programarea distribuită. Într-un mediu SAN, Fig. 6_20 tehnica tape-pooling permite aplicaţiilor de pe unul sau mai multe servere să partajeze drivere de benzi, biblioteci şi cartridge-uri (foto la * gnetic_tape) într-o manieră automată şi securizată. Folosind SAN, fiecare host poate adresa în mod direct dispozitivul bandă ca şi cum acesta ar fi conectat la toate host-urile. Driverele de benzi, bibliotecile şi cartridge-urile (vom folosi pentru toate acestea abrevierea neconsacrată RB) sunt fie în proprietatea (owned by) unui manager central, fie se utilizează o tehnică de management de tip peer-to-peer. (Wikipedia: Într-o reţea peer-to-peer pură nu există noţiunea de clienţi sau servere. Există doar noduri peer care funcţionează simultan atât ca clienţi cât şi ca servere pentru alte noduri din reţea). RB sunt (re)alocate sistemelor la cerere, în mod dinamic. Tehnica tape pooling face posibile partajarea RB, managementul îmbunătăţit, automatizarea şi creşterea securităţii utilizării RB. Este necesar SW pentru gestionarea operaţiunilor de asignare şi blocare a disp. bandă în scopul serializării accesului la bandă. Tehnica tape pooling reprezintă o modalitate foarte eficientă (şi cu costuri mici) prin care se partajează RB scumpe, aşa cum sunt bibliotecile de bandă automatizate. Bibliotecile de bandă pot fi partajate chiar între SO diferite. La un moment dat, un driver de bandă poate fi în deţinut (owned) de un singur sistem, aşa cum se prezintă în fig. 6_20. În acest ex., serverului iseries i se asignează în mod curent două drivere de bandă, pe când serverului UNIX i se asignează doar un driver. Casetele bandă amplasate în biblioteci (fizice sau virtuale) sunt asignate la aplicaţii sau grupuri diferite atunci când conţin date curente. Dacă încă nu sunt folosite sau dacă nu mai conţin date curente, pot fi atribuite la servere (în grupuri improvizate(scratch)) Tehnica server clustering Arhitectura SAN permite clustering-ul (gruparea) scalabilă în situaţii de partajare de tip shareall, deoarece un cluster de servere omogene poate vedea o singură imagine-sistem a datelor. Tehnica în care se utilizează dispozitive SCSI cu căi multiple este deficitară din punctul de vedere al scalabilităţii, datorită constrângerilor impuse de SCSI relative la distanţă: SCSI admite distanţe de max. 25 m, iar mărimea conectorilor SCSI limitează nr. de conexiuni aferente serverelor dintr-un sistem. Un SAN permite şi echilibrarea sarcinii (load balancing) în mediile unde se execută aplicaţii cu procesări distribuite. Aplicaţiile unde există restricţii-procesor care impun rularea pe un singur sistem se pot executa pe un alt server, care are un procesor mai performant. Pentru ca acest lucru să fie posibil, ambele servere trebuie să poată accesa aceleaşi volume de date, iar serializarea accesului la date trebuie să fie asigurată de aplicaţii sau de serviciile SO-ului. Curs6 / 6

7 În acest context trebuie amintit produsul S/390 Parallel Sysplex. (*** 03.ibm.com/servers/eserver/zseries/pso/: Datorită acestei tehnologii, se poate utiliza puterea a până la 32 de sisteme z/os. Ansamblul acestora se comportă ca o singură entitate logică de calcul. Structura pe care se bazează această tehnologie rămâne virtual transparentă utilizatorilor, reţelelor, aplicaţiilor şi chiar operaţiunilor. S/390 Parallel Sysplex combină două capabilităţi critice: (a) procesarea paralelă; (b) facilitatea de citire/scriere a datelor partajate de către mai multe sisteme, Fig. 6_21 respectându-se integritatea datelor. Se ajunge la bilioane de instrucţiuni/sec şi la o foarte bună echilibrare a sarcinilor). Pe lângă cele menţionate, arhitectura SAN face posibilă şi exploatarea în condiţii de avarie (failover cădere). Astfel, un al doilea sistem poate fi utilizat în cazul în care primul cade, având posibilitatea de a adresa direct capacitatea de stocare folosită de primul. Astfel creşte fiabilitatea într-un mediu cu de tip clustered, pentru că se elimină timpul de inactivitate aferent indisponibilităţii procesorului. În fig. 6_21 se prezintă un ex. de aplicare al tehnicii clustering. În acest ex. serverele S1 şi S2 partajează DS-urile ESS#1 şi respectiv ESS#2. Dacă S1 cade, S2 poate accesa datele de pe ESS#1. Exemplul arată de asemenea că ESS#1 este mirrored copia sa în oglindă fiind ESS#2. Dacă serverul de rezervă backup S2 este amplasat la distanţă şi conectat prin WAN, se asigură şi continuitatea operaţiunilor în caz de dezastre Consolidarea insulelor utilizând SAN Actual se pot îmbunătăţi caracteristicile referitoare la scalabilitate, securitate şi respectiv uşurinţă a administrării prin asigurarea capacităţii de comunicare a dispozitivelor conectate prin intermediul unor fabricuri SAN separate, fără ca pentru aceasta să fie necesară reunirea fabricurilor respective într-unul singur. Această capabilitate permite clienţilor ca, în prima fază, să dezvolte soluţii SAN la nivele departamentale sau de centre de date, urmând ca apoi să le consolideze în soluţii SAN la nivel de întreprindere, pe măsură ce experienţa lor creşte şi/sau cerinţele se măresc sau se modifică. Clienţii pot dezvolta mai multe insule SAN pentru aplicaţii diferite, folosind soluţii fabric diferite. Disponibilitatea crescândă a capabilităţilor serverelor iscsi a creat premizele pentru soluţii cu cost scăzut pentru integrarea /consolidarea stocării folosind aceste servere. În plus, în funcţie de alegerea routerului, acestea pot furniza şi capabilităţi FCIP sau ifcp. Routerele SAN furnizează serviciul iscsi Gateway Service pentru a integra servere conectate Ethernet, care au un preţ scăzut, cu infrastructurile SAN existente. De asemenea furnizează servicii de rutare FC-FC pentru a interconecta mai multe insule SAN, fără a trebui să reunească toate fabricurile într-unul singur. Curs6 / 7

8 Curs6 / 8 Fig. 6_22 În fig. 6_22 este prezentat un exemplu de utilizare a unui router multiprotocol în scopul extinderii capabilităţilor SAN în toată întreprinderea. O soluţie care utilizează un router multiprotocol aduce numeroase beneficii pe piaţă. În acest exemplu sunt implicate mai multe protocoale. Soluţia aferentă reunirii tuturor fabricurilor prezintă dezavantajele: (a) Un anumit timp de inactivitate (downtime); (b) Necesitatea achiziţionării de switch-uri/porturi suplimentare, respectiv de HBA-uri; (c) Costuri aferente migrării, respectiv configurării; (d) Costuri pentru noi licenţe; (e) Activităţi suplimentare de mentenanţă. Dacă se instalează un router multiprotocol se obţin avantajele: (a) Metodă mai puţin disruptivă; (b) Nu sunt necesare HBA-uri suplimentare; (c) Numărul de porturi necesar pentru conectarea la router este minim; (d) Costurile aferente migrării şi downtime-ului sunt mici; (d) Nu sunt necesare operaţiuni de mentenanţă (cu excepţia routerului); (e) Suport pentru alte protocoale; (f) Prin consolidarea resurselor creşte ROI (Return of Investments - recuperarea investiţiilor); (g) Soluţia se poate utiliza pentru izolarea SAN-ului, a.î. acesta să devină mai sigur. Routerul se mai poate folosi şi pentru: (a) Conectivitatea dispozitivelor provenind din mai multe SAN-uri, în scopul simplificării infrastructurii; (b) Consolidări în care sunt implicate backupuri pe bandă; (c) extinderi SAN pe distanţe mari, ca măsuri de asigurare în caz de dezastru; (d) Conectivitate între servere şi resurse SAN la un preţ mic Soluţii pentru pooling, stocare şi partajarea datelor Există servere care pot realiza partajarea reală a datelor memorate pe DS-uri (true data sharing). Serverele zseries oferă această facilitate încă din Partajarea datelor nu reprezintă un apanaj exclusiv al SAN-urilor. În schimb arhitectura SAN permite utilizarea avantajelor oferite de conectivitatea mai multor hosturi la acelaşi DS pentru ca datele să fie partajate mai eficient decât în cazul utilizării serviciilor unui server de fişiere sau a unei unităţi NAS (aceste soluţii fiind adesea utilizate). Conectivitatea SAN permite partajarea datelor de către servere heterogene (UNIX, Windows, z/os). Există mai multe etape sau faze aferente partajării reale a datelor: partiţionarea volumelor logice; pooling al fişierelor; partajarea reală a datelor.

9 Partiţionarea volumelor logice Partiţionarea DS-urilor nu reprezintă o soluţie de tip true data sharing. În esenţă reprezintă doar o modalitate de a împărţi capacitatea de stocare aferentă unui singur server în mai multe părţi. Subsistemele de stocare sunt conectate la mai multe servere, iar capacitatea de stocare este împărţită între subsisteme diferite. Volumele-disc logice sunt definite în interiorul subsistemului de stocare şi atribuite serverelor. Discul logic este adresabil de către server. Un disc logic poate fi: - un (super)set de discuri adresabil numai de către subsistemul însuşi (fig.6_23, a); - definit ca subseturi formate din câteva discuri fizice (tehnica stripping) (fig.6_23 (b), (c)). Capacitatea unui volum-disc este setată atunci când este definită. Ex.1: Două discuri logice, de capacităţi diferite (de ex. 50 GB şi respectiv 150 GB) pot fi create dintr-un singur disc de 300 GB, fiecare find asignat unui servere diferit, iar restul de 100 GB rămânând neasignaţi. Ex. 2: Se poate crea un singur disc logic, de 2000 GB, din mai multe discuri fizice Fig. 6_23 amplasate în subsisteme de stocare diferite. Controllerul de stocare care oferă suport discului logic trebuie să beneficieze de un suport logic care să permită gestionarea grupării volumelor şi să garanteze accesul sigur la date. Fig. 6_23 prezintă modalitatea prin care mai multe servere accesează volume logice create folosind câteva dintre alternativele menţionate mai sus. Tehnica File Pooling Curs6 / 9

10 Fig. 6_24 Curs6 / 10 Prin tehnica File Pooling se atribuie spaţiu disc care are dimensiunea necesară pentru a conţine fişierul care urmează a fi creat. În loc de a asigna capacitate disc la servere individuale folosind discuri logice sau fizice, sau folosind funcţii ale SO (ca de ex. z/os) pentru a administra capacitatea, tehnica File Pooling prezintă serverelor de aplicaţie un spaţiu de nume care poate fi montat (mountable name space). Această tehnică este asemănătoare modului în care se comportă sistemul de fişiere NFS actual. Diferenţa constă în faptul că există un canal de acces direct, nu unul de reţea (cum este cazul NFS), între serverele de aplicaţie şi disc(uri) atunci când se stochează fişierul. Capacitatea-disc este asignată numai atunci când fişierul este creat şi este eliberată atunci când fişierul este şters. Fişierele pot fi partajate între servere în acelaşi mod (suport din partea SO, blocări, securitate, etc.) ca şi cum ar fi stocate pe un disc fizic sau logic partajat. Fig. 6_24 prezintă mai multe servere care accesează fişiere în spaţiul de stocare partajat. Spaţiul de stocare neasignat poate fi reasignat oricărui server, la cerere, atunci când se creează noi fişiere. Partajarea reală a datelor (true data sharing) Tehnica True data sharing asigură facilitatea de accesare concurentă a aceleiaşi copii a datelor de către mai multe servere. Utilizarea sa oferă avantaje cum ar fi economiile considerabile relativ la spaţiul de stocare precum şi oferirea bazei necesare pentru construirea consolidării stocării. Există câteva nivele diferite pentru partajarea datelor: - acces se tip secvenţial, point-in-time sau one-at-a-time. Datele se atribuie întâi unei aplicaţii, apoi alteia, pe acelaşi server sau pe altul, ş.a.m.d.; - acces în citire simultan, de către mai multe aplicaţii. În acest model este posibilă citirea simultană a aceloraşi date, de către mai multe aplicaţii de pe unul sau mai multe servere, dar numai o aplicaţie poate să le modifice, astfel că nu pot apare probleme relative la integritatea datelor; - acces în citire/scriere a mai multor aplicaţii. Este cazul True data sharing. Această situaţie se deosebeşte de precedenta prin aceea că toate hosturile pot modifica datele partajate. Există două versiuni ale acestui tip de acces: (a) Toate aplicaţiile sunt pe aceeaşi platformă (cazul omogen); (b) Aplicaţiile sunt pe platforme diferite (cazul heterogen). Este necesar un mecanism de serializare pentru a garanta că datele scrise de mai multe aplicaţii sunt înscrise pe disc într-o manieră ordonată. Mecanismele de Fig. 6_25 serializare pot fi definite a.î. să realizeze serializarea scrierii datelor provenite dintr-un grup de volume disc fizice sau logice într-un bloc fizic individual de date aparţinând

11 unui fişier sau unei baze de date. O astfel de formă de partajare a datelor necesită coordonări complicate privind activitatea mai multor servere, la o scară mult mai mare comparativ cu cazul tehnicii file locking. (a) Cazul omogen În fig. 6_25 se prezintă modalitatea de accesare şi partajare a aceloraşi date de către mai multe hosturi cu aceeaşi platformă. Mecanismul de codificare care priveşte toate hosturile este unul obişnuit şi de obicei depinde de platformă. Hosturile sau subsistemul de stocare trebuie să furnizeze un mecanism de serializare pentru accesarea datelor. (b) Cazul heterogen Fig. 6_26 Curs6 / 11 În partajarea heterogenă a datelor (fig. 6_26 ) SO-uri diferite accesează aceleaşi date. Problematica este similară cazului omogen, dar cu o trăsătură suplimentară foarte importantă: datele trebuie să fie stocate într-un sistem de fişiere comun, putând exista următoarele două situaţii: - codificare comună şi convenţii diferite; - codificări diferite, caz în care este necesară utilizarea unei logici speciale aferente sistemului de fişiere pentru a realiza conversiile necesare ale codificărilor EBCDIC sau ASCII şi respectiv pentru a trata problemele aferente celorlalte diferenţe Soluţii pentru mutarea datelor Soluţiile pentru mutarea datelor impun ca datele să se mute între DS asemănătoare sau diferite. Mutarea sau replicarea datelor se pot realiza de către unul sau mai multe servere. Serverele citesc date de la disp. sursă, pot transmite datele altui server (prin LAN sau WAN) şi apoi datele sunt scrise pe disp. destinaţie. Acestă sarcină consumă cicluri-procesor şi face ca datele să se deplaseze de două ori prin SAN: o dată de la disp. sursă la server, a doua oară de la server la disp. destinaţie. Obiectivul soluţiilor de mutare a datelor în care este implicat un SAN este acela de a evita copierea datelor prin intermediul serverului (soluţii de tip server-free) şi respectiv prin LAN sau WAN (soluţii de tip LAN-free), astfel eliberând ciclurile procesor, respectiv lăţimea de bandă LAN sau WAN. În momentul de faţă replicarea datelor dintr-un SAN se poate realiza prin utilizarea unui gateway inteligent care oferă suport comenzilor de copiere third-party SCSI-3. Implementările de tip third-party copy mai sunt cunoscute şi sub denumirile de outboard data movement. Servicii de copiere 1. Copierea tradiţională Una dintre cele mai frecvente sarcini executate de catre un space manager este reprezentată de mutarea datelor utilizând instrumente diferite. Astfel, o entitate care utilizează frecvent metoda copierii tradiţionale este TSM Tivoli Space Manager. Folosind SAN, copierea tradiţională se poate realiza într-o manieră server-free, simplificând operaţiunile de planificare şi mărind viteza de execuţie. 2. Tehnica de copiere T-0 Un alt serviciu de copiere de tip outboard data movement posibil atunci când se utilizează tehnologia FC este copierea de tip time-zero (T-0). Constă din preluarea unei copii instantanee (snapshot) sau din îngheţarea datelor (prin date înţelegând baze de date, fişiere sau volume) la un moment de timp specificat, urmând ca apoi să se permită aplicaţiilor să actualizeze datele originale pe timpul cât datele îngheţate sunt duplicate. Caracterisiticile de flexibilitate şi extensibilitate

12 oferite de FC permit ca aceste copii instantanee să se facă atât pe dispozitive locale cât şi pe dispozitive aflate la distanţă. Această tehnică a apărut pentru a asigura sistemelor cu baze de date critice caracterul de disponibilitate de tip 24X7. 3. Copiere la distanţă Copierea la distanţă reprezintă o cerinţă impusă de interesele legate de afaceri, în scopul protejării datelor împotriva dezastrelor sau al realizării migrării lor dintr-o anumită locaţie, pentru a evita timpii morţi ai aplicaţiilor pe timpul perioadelor de inactivitate planificată, cum sunt de ex. cele aferente operaţiunilor de mentenanţă HW sau SW. La ora actuală soluţiile de copiere la distanţă sunt fie sincrone, fie asincrone şi ele impun nivele diferite de automatizare în scopul garantării consistenţei datelor din (subsistemele) disc. Actual aceste soluţii au implementări doar pentru discuri la nivel de volum fizic sau logic. Datorită apariţiei tehnicilor de management al stocării mai avansate, ca de ex. outboard hierarchical storage management şi respectiv file pooling, în viitor soluţiile de copiere la distanţă vor trebui implementate la nivelul fişierelor. Volumul datelor de copiat va creşte, vor fi necesare tehnologii mai avansate pentru a garanta consistenţa datelor memorate în fişiere, discuri şi benzi din medii multiserver heterogene. Utilizarea SAN va fi obligatorie pentru a oferi suportul necesar lăţimii de bandă şi managementului unor astfel de medii Soluţii pentru continuitatea afacerii (Business continuance) La ora actuală, protecţia datelor memorate pe mai multe servere ataşate la reţea se realizează în conformitate cu una sau mai multe paradigme de backup şi recuperare (recovery): (a) backup şi recuperare realizate local ; (b) backup şi recuperare folosind reţeaua. a) Paradigma backup şi recuperare realizate local are avantajul vitezei, deoarece datele nu circulă prin reţea. Apar însă costuri suplimentare (corespunzătoare overhead-ului): - trebuie achiziţionate dispozitive locale fiecărui server, care nu se pot utiliza eficient; - trebuie să se asigure suport pentru mai multe drivere şi biblioteci de benzi, trebuie să se realizeze mai multe operaţii de montare. b) Paradigma backup şi recuperare folosind reţeaua este mai eficientă din punctul de vedere al costurilor, deoarece permite centralizarea DS-urilor folosind unul sau mai multe dispozitive ataşate la reţea. Această centralizare permite o mai bună recuperare a investiţiilor, deoarece dispozitivele instalate vor fi utilizate mai eficient. O bibliotecă de benzi poate fi partajată între mai multe servere. Managementul mediului în care operaţiunile de backup şi recuperare folosesc reţeaua este adesea mai simplu decât cel în care aceste operaţiuni se realizează local, deoarece se elimină posibilele operaţii de montare efectuate manual pe mai multe servere. SAN-urile utilizează o combinaţie a ceea ce este mai bun din cele două abordări. Acest lucru este realizat prin managementul central al operaţiilor de backup şi recuperare, atribuind unul sau mai multe dispozitive bandă fiecărui server, şi utilizând protocoale FC pentru a transfera datele direct de la dispozitivul disc la dispozitivul bandă şi invers, prin SAN. 1. Mutarea de tip LAN-free a datelor Paradigma backup şi recuperare folosind reţeaua presupune că datele circulă dinspre clientul operaţiunilor de backup şi recuperare (uzual un server de fişiere sau de baze de date) către serverul care realizează aceste operaţiuni (folosim abrev. neconsacrată SBR pentru serverul care realizează backup şi recuperare) sau între servere SBR, folosind o conexiune de reţea. Situaţia este aceeaşi şi pentru aplicaţiile de management al stocării ierarhice sau al arhivelor. Adesea o conexiune de reţea reprezintă o îngustare (bottleneck) a fluxului de date, datorită lăţimii de bandă limitate a reţelei. SAN-ul reprezintă o alternativă la transportul prin reţea. Partajarea driverului de banda şi a bibliotecii de benzi O cerinţă de bază pentru o tehnică de backup şi recuperare de tip LAN-free sau server-free constă în abilitatea de a partaja drivere şi biblioteci de benzi între SBR-uri şi respectiv între un SBR şi clientul său (uzual un server pentru baze de date). Clienţii de tip end-user ataşaţi la reţea vor utiliza încă reţeaua pentru transportul datelor. În abordarea în care se partajează driverul şi biblioteca de benzi, SBR sau clientul care Curs6 / 12

13 solicită copierea unei copii backup (de) pe bandă vor scrie sau citi datele direct (de) pe dispozitivul bandă folosind comenzi SCSI. Astfel se elimină neajunsuri cum ar fi de ex. latenţa transportului prin reţea. În ex. din fig. 6_27 se prezintă un exemplu pentru partajarea driverului sau bibliotecii de benzi. În acest ex., au loc etapele: 1. Un client al operaţiunilor de backup şi recuperare solicită una sau mai multe benzi pentru a realiza operaţiunile de recuperare. Cererea este trimisă printr-o cale de control, care ar putea fi o conexiune standard (deci nu de retea!!!) între client şi server. SBR asignează apoi unul sau mai multe drivere de bandă clientului pe durata operaţiei de backup. 2. SBR solicită apoi benzile care urmează a fi montate în drivere folosind calea de management. 3. SBR notifică apoi clientul asupra Fig. 6_27 Curs6 / 13 faptului că benzile sunt în starea ready. 4. Clientul realizează operaţiunile de backup şi recuperare folosind calea de date. 5. Atunci când clientul termină (completes) operaţiunile, el notifică serverul asupra terminării, iar benzile pot fi eliberate. 6. SBR cere ca şi casetele de benzi să fie supuse operaţiunii de dismount, folosind calea de management pentru fluxul de comenzi. Mutarea de tip server-free a datelor În abordările precedente, totdeauna a fost nevoie de intervenţia serverului pentru a copia date de pe dispoz. sursă pe dispoz. destinaţie. Datele au fost citite de pe dispoz. sursă în memoria serverului şi scrise apoi din memoria serverului pe dispoz. destinaţie. Tehnica de mutare de tip server-free a datelor evită utilizarea oricărui server sau reţea IP pe timpul mutării datelor, folosind doar SAN-ul pentru realizarea funcţiei de copiere de tipul SCSI-3 third-party (vom fol. pt. această funcţie abrev. neconsacrată S3PC). Fig. 6_28 ilustrează această tehnică. Managementul driverelor şi casetelor de bandă este abordat într-un mod asemănător celui precedent. Clientul lansează o comandă de copiere de tipul S3PC care va avea ca efect copierea datelor de pe disp. sursă pe disp. destinaţie. Nu se utilizează nici cicluri procesor şi nici lăţime de bandă de reţea IP. În ex. din fig. 6_28, clientul operaţiunilor de backup şi recuperare a lansat o comandă de copiere S3PC pentru a realiza operaţiunile amintite folosind tehnica tape pooling. Într-o altă implementare este posibil ca SBR-ul să iniţieze o comandă S3PC ca urmare a

14 solicitării de la un client, folosind tehnica disk-pooling. Comanda de tipul S3PC defineşte operaţiuni la nivel de bloc, ca şi în cazul comenzilor SCSI. Protocolul SCSI nu are cunoştinţă despre structurile sistemului de fişiere sau ale bazei de date. Folosirea unei copieri S3PC pentru mutarea datelor la nivel de fişier necesită ca sistemele de fişiere să furnizeze funcţii de mapare între fişierele din sistemele de fiş. şi adresele dispozitivelor-bloc. Această mapare reprezintă un prim pas către operaţiunile sofisticate de backup şi recuperare ale bazelor de date, aoperaţiunilor aferente log archiving, etc. Partea de server a aplicaţiei de tip backup şi recuperare realizează în plus multe alte sarcini care necesită cicluriprocesor ale serverului pentru mutarea datelor (de ex. migrarea datelor şi reciclarea şi reactualizarea (reclamation) datelor). Pe timpul operaţiunilor de tip reclamation, datele sunt citite de pe caseta bandă în scopul de a fi reclaimed în memoria serverului, Fig. 6_29 şi apoi sunt scrise din memoria serverului pe noua casetă bandă. Prin tehnica de mutare a datelor de tip server-free (fig.6_29) se evită utilizarea ciclurilor procesor pentru mutarea datelor. Acţiuni pentru backup şi recuperare a datelor în caz de dezastru SAN-urile pot facilita soluţiile de backup în caz de dezastru datorită mai bunei flexibilităţi permise atunci când se conectează DS la server precum şi datorită distanţelor mai mari pentru care se oferă suport prin comparaţie cu restricţiile SCSI-urilor. Când se utilizează o infrastructură SAN este posibilă realizarea de backupuri la distanţe mari pentru recuperarea în caz de dezastru în interiorul unui campus sau al unui oraş, ca în fig. 6_30. Atunci când distanţele sunt prea mari, SAN-urile trebuie conectate folosind gateway-uri şi WAN-uri. În funcţie de cerinţele specifice afacerii, implementările aferente protecţiei împotriva dezastrelor pot folosi fie servicii de copiere implementate în subsistemele disc şi în bibliotecile de benzi (care ar putea fi implementate folosind servicii SAN), fie serviciile de copiere SAN, fie - cel mai probabil - o combinaţie a ambelor. În plus vor fi necesare servicii şi soluţii asemănător cu Geographically Dispersed Parallel Sysplex (GDPS) pentru serverele zseries în scopul monitorizării şi managementului acestor medii. fig. 6_30 Curs6 / 14