SANscreen vergroot flexibiliteit SAN s

Transcriptie

1 SAN-MANAGEMENT DOOR BRAM DONS Storagenetwerken kwetsbaar voor veranderingen SANscreen vergroot flexibiliteit SAN s 16 Naast voordelen van SAN s kennen deze storagenetwerken ook keerzijden die zich vooral in het beheer afspelen. Zo leiden configuraties tot veel werk en groeit de complexiteit van de infrastructuur bij veranderingen in het SAN. Leverancier Onaro claimt hiervoor de oplossing met haar product SANscreen. Bram Dons evalueert de demoversie. De belangrijkste doelstelling voor de implementatie van een SAN is dat organisaties dan efficiënt gebruik kunnen maken van een opslagomgeving. Een SAN is immers een eenvoudige manier om de opslaginfrastructuur uit te breiden. Een SAN-infrastructuur moet wel flexibel genoeg zijn om aan een on demand-behoefte naar opslagcapaciteit tegemoet te komen en moet tevens stabiel genoeg zijn om een betrouwbare en veilige toegang tot data te bieden. Tot op heden is de technologische ontwikkeling bij SAN s voornamelijk gericht op een zo stabiel mogelijke opslaginfrastructuur en minder op flexibiliteit. Als gevolg daarvan functioneren SAN s meestal goed nadat ze zijn geïnstalleerd maar treden er nogal eens problemen op wanneer er een wijziging op moet worden aangebracht. In tegenstelling tot andere netwerktechnologieën, waar afscherming wél deel uit maakt van de beveiliging, vereist een SAN een additionele bescherming tegen het risico van een onbedoelde toegang tussen een server en een opslagsysteem. Bij SAN s wordt voor de afscherming van opslagbronnen twee verschillende en elkaar overlappende technologieën gebruikt, te weten: SCSI LUN-masking en Fibre Channel Zoning. Deze technieken worden in verschillende type producten toegepast. In de praktijk worden ze ook vaak door verschillende beheerteams beheerd. Daarnaast komen nog de aanvullende eisen voor redundantie, hoge beschikbaarheid van de verbinding en het gebruik van multiplex host sessions tussen de afzonderlijke opslagsubsysteem-poorten. Zelfs een betrekkelijke kleine SAN kan dan al tienduizenden potentiële haarden voor configuratieproblemen opleveren. Het is dan ook geen wonder dat een wijziging aan een complexe SAN infrastructuur meestal een tijdrovend en moeizaam proces is. Beperkingen van zoning Bescherming bij SAN s wordt in eerste instantie geboden door twee verschillende en op zichzelf staande voorzieningen: zoning en LUN-masking. Zoning wordt toegepast binnen switches om de verbinding tussen verschillende SAN-nodes te limiteren, LUN-masking wordt gebruikt bij opslagsubsystemen om servers toegang te bieden tot specifieke LUN s. Hoewel beide technieken in het algemeen niet als zodanig worden beschouwd, zijn zoning en masking beide vormen van virtualisatie. Zoning is een zeer eenvoudige en beperkte vorm van een virtueel netwerk terwijl masking een virtuele subset creëert van de beschikbare opslagbronnen. Eén van de belangrijkste uitdagingen voor SAN-beheerders is dat zoning en LUN-masking worden beheerd als twee afzonderlijke en niet-geïntegreerde virtualisatiefaciliteiten die weliswaar volkomen onafhankelijk van elkaar werken maar met overlappende beheergebieden. ZELFS EEN KLEINE SAN KAN TIENDUIZENDEN HAARDEN VOOR CONFIGURATIEPROBLEMEN OPLEVEREN Een verandering in één van de twee kan grote gevolgen hebben voor de ander. Een ander probleem is dat zoning en masking niet vanuit hetzelfde punt kunnen worden beheerd. De techniek zoning, die Apple Computer oorspronkelijk voor AppleTalk-netwerken ontwikkelde, is door de leveranciers van FC-switches geadopteerd om problemen binnen Windows op te lossen bij de toe-

2 Focus: gecentraliseerde provisioning, backup, FS, quota- en capaciteitsrapportage Device provisioning Resource management Switch Array Reporting engine Database Agents Fabric A Fabric B Figuur 1: Overzicht van het SRM- en SSM-landschap. Focus: monitoring & troubleshooting, servicerapportage, changemanagement Service monitoring Service management Business continuity services High availability services Dataservices Simulatie Service-impact, DCA Servicepolicies CMDB Fabric DR A Fabric DR B FS, Capaciteitsrapportagmonitoring Device- quotarapportage Changemanagement Servicerapportage wijzing van opslagruimte. Zoning creëert een virtuele groep met verbindingen waarbij alleen de deelnemers van een betreffende zone toegang tot elkaar hebben op basis van een switchpoort of een WWN. Bij toepassing van port-zoning kunnen FC-kabels van de ene switchpoort naar de andere worden verhuisd. Daarbij kan een foutieve verbinding leiden tot een onbedoelde toegang tot een verkeerde LUN. Bij WWW-zoning bestaat het risico dat bij upgrading en/of verwisseling van een HBA de toegang tot het opslagsysteem niet langer mogelijk is. Bij LUN-masking spelen weer andere problemen. Een LUN kan worden gezien als een virtueel opslagsysteem voorzien van een SCSI-identifier en de communicatie en verwerking van een opslagentiteit binnen een SAN-subsysteem verzorgt. Een LUN wordt via de SAN-poorten van het opslagsubsysteem geëxporteerd waardoor deze zichtbaar wordt voor een host. Een enkele poort kan verschillende LUN s exporteren, afhankelijk van de gewenste prestaties, ofwel zogenaamde oversubscribing van LUN s. Grote disksubsystemen kunnen vele honderden LUN s bevatten, die dus via de poorten van het subsysteem worden geëxporteerd. Het proces van de toewijzing van LUN s aan poorten heet provisioning en is voor beheerders vaak een tijdrovende taak. Reden hiervoor is het aantal te doorlopen stappen en aanvullende eisen om een balans tussen de poorten aan te brengen bij de doorvoerbelasting. Zonder LUN-masking heeft elk systeem dat toegang heeft tot een subsysteem-poort, toegang tot alle geëxporteerde LUN s. Met masking kunnen hosts de gemaskeerde LUN s niet zien en gebruiken. Beide technologieën zijn niet alleen fundamenteel verschillend maar ook het beheer ervan verschilt wezenlijk. Beheerproblemen Een andere kritische complicerende factor binnen SAN s is de toepassing van multipathing en redundante HBA s. De implementatie van high availabilitystructuren binnen SAN s betekent dat zoning en masking niet slechts één maal, maar twee maal met elkaar in overeenstemming moeten worden gebracht om een veilige en stabiele toegang tot data te kunnen garanderen. Op het eerste gezicht lijkt dit niet zo lastig, maar het kan zeer tijdrovend worden wanneer elke (Advertentie) redundante verbinding binnen een SAN moet worden gecontroleerd wanneer er twee of meer HBA s in een server aanwezig zijn. Dit is met name het geval in combinatie met meerdere zones en zoning-configuraties in switches en zestien of meer poorten in subsystemen met geëxporteerde LUN s over redundante en gebalanceerde verbindingen. Wanneer men bovendien nog bedenkt dat er meerdere applicaties, met elk verschillende opslagbehoeften, op servers kunnen draaien dan wordt het scenario voor changemanagement voor een dergelijke SAN-infrastructuur uiterst gecompliceerd. De complexiteit van SAN s groeit dan niet geometrisch maar lineair omdat elke additionele toegangbesturingsvariabele een vermenigvuldigend effect heeft op het aantal betrokken permutaties. Wat zich in eerste instantie voordoet als een paar honderd variaties in SAN-verbindingen kan daadwerkelijk uitdraaien op honderdduizenden of zelfs miljoenen op zichzelf staande permutaties. Het is duidelijk dat het aanbrengen van wijzigingen zonder een goede Change Managementtool in de praktijk vaak tot onvoorspelbare gevolgen kan leiden (zie kader Fibre Channel als state machine). Spreadsheets in changemanagement SAN-beheerders moeten bij wijzigingen aan het SAN opnieuw de zoning en masking met elkaar in overeenstemming brengen om ervoor te zorgen dat er niet per ongeluk ongewenste verbindingen tot stand komen of bestaande verbindingen uitvallen. Vandaag de dag is bij dit uiterst lastige karwei de meest gebruikte methode om de configuratielijsten in spreadsheets door te nemen. Niet alleen moeten de beheerders controleren of de wijzin- Een snelle back-up is nog geen snelle restore En dat zeggen we niet alleen, we laten ook de oplossing zien. Zodat u verloren data ook weer snel kunt terugzetten. In een 1-op-1 sessie met een ISIT consultant. Reserveer nu! 17

3 18 SANscreen Visualisatie Fabric A Fabric B Verificatie Figuur 2: Diensten binnen SANscreen. gen correct kunnen worden uitgevoerd maar ook moeten de betrokken verbindingen aan een cross check worden onderworpen. Het is verbazingwekkend dat SAN-beheerders in een eeuw waar zoveel al geautomatiseerd is, nog steeds ellenlange spreadsheets moeten doorworstelen om potentiële configuratieproblemen op te sporen. Naarmate SAN s in grootte groeien, neemt niet alleen het aantal variabelen toe en zijn er vaak meerdere SAN-beheerders bij het configuratieproces betrokken. Het is dan noodzaak om de spreadsheets van alle beheerders met elkaar te laten overeenstemmen zodat er geen misconfiguraties ontstaan. Het zou dan ook gewenst zijn wanneer er vanuit één beheertool een totaaloverzicht van het SAN is te zien die alle gevolgen van een herconfiguratie in beeld brengt en eventuele misconfiguraties vooraf kan signaleren. Een geavanceerde beheertool voor Storage Service Management (SSM) is SANscreen van de firma Onaro. Data access Redundancy Performance Changemanagement Replication Root Cause Analysis Service Intelligent Engine Configuratie items Service analytics Audit Fabric DR A Fabric DR B opslagbeheer. Hoewel SRM prima geschikt is voor het beheer van disk-bronnen op file- en volumeniveau, verhindert de beperkte view van SRM om IT-beheer als storageservice te kunnen faciliteren. Switches, hosts en disk arrays hebben allemaal hun eigen configuraties die via SRM-applicaties kunnen worden ingesteld en beheerd. Maar al deze mogelijkheden voor configuratie alleen creëren nog geen storageservices, want deze worden eigenlijk via een combinatie van devices en onderlinge afhankelijkheden gecreëerd. Nodig is daarom een servicegecentreerde view die inzicht geeft hoe de verschillende storagedevices met elkaar samenwerken. SRM-applicaties schieten hierin tekort en creëren een onoverbrugbare afstand tussen de device-gecentreerde views en de services die ze zouden moeten kunnen bieden. Het is voor softwareontwikkelaars van storagemanagement-applicaties dan ook een enorme uitdaging om inzicht te krijgen in de structuur, onderlinge verbindingen en aanwezige systemen binnen een opslagnetwerk. Het opslagbeheer met storageservices stelt extra hoge eisen aan het verzamelen van de daarvoor benodigde data en analyse daarvan. Zo kan een doorsnee SAN met slechts honderd redundant verbonden servers al meer dan vijf miljoen verschillende servicecombinaties opleveren. Om vanuit deze gigantische verzameling data enige betekenis te distilleren is een omvangrijk realtime correlatie- en analyseprogramma nodig, zonder inmenging van de operationele omgeving. Onaro SANscreen De technische ontwikkelgroep van Onaro is afkomstig uit een intelligence community waarin de voornaamste taak was het verzamelen, analyseren en correleren van massale hoeveelheden data. Deze kennis vormde de basis voor de ontwikkeling van SANscreen Storage Service Management Application. De architectuur van SANscreen verschilt dan ook fundamenteel van die van SRM-applicaties. Net zoals de meeste SRM-applicaties slaat SANscreen de data van agents over devices op in een gemeenschappelijke master database. SANscreen maakt van haar service intelligence engine gebruik om deze data te transformeren van een device-specifieke naar een servicegerichte view. Daarvoor voert de engine een aantal taken uit, namelijk automatische herkenning van devices, analyse van deviceconfiguraties, intelligente selectie, mapping afhankelijkheden, correlatie en simulatie. Dit gesofisticeerde proces gebeurt in near realtime over de honderden of zelfs duizenden devices. SANscreen laat de zes management disciplines, Visibility, Verification, Change Management, Root Cause Analysis, Reporting en Audit los op de servicedata en brengt enkele fundamenteel verschil- Ontwerp van storagemanagement Met de komst van tools voor storagemanagement is het opslagbeheer snel aan het veranderen. Het stelt IT-organisaties in staat om hun serviceniveau te verbeteren, hogere ROI s te halen en op de juiste manier te voldoen aan allerlei wettelijk gestelde bewaareisen. Dit wordt mogelijk gemaakt door opslag als een service te behandelen, waarmee het verschilt van de meer traditionele applicaties voor Storage Resource Management (SRM). In tegenstelling tot de device-georiënteerde benadering van SRM-applicaties is SSM een servicegerichte benadering van FIBRE CHANNEL ALS STATE MACHINE Een van de factoren bij SAN-changemanagement is het statefull karakter van FC-Services. Fibre Channel is ontworpen om de operationele staat van alle poorten binnen het netwerken zo goed als mogelijke te handhaven en te onderhouden. Wat dat betreft is Fibre Channel een verouderde netwerktechnologie die niet efficiënt en betrouwbaar kan inspelen op dynamische veranderingen binnen het opslagnetwerk. Een FC-SAN kan dan ook worden beschouwd als een state machine waarin alle variabelen statisch worden beheerd, totdat er zich expliciet een verandering in voordoet. Elke discrete verandering aan het SAN, of het nu de bekabeling, server, storage, switch of HBA betreft, resulteert dan ook in een nieuwe SAN-state en die gehandhaafd blijft tot de final state weer is bereikt. Dat betekent in de praktijk dat de operationele condities van het SAN ernstig kunnen worden verstoord door een verandering aan de SAN-configuratie. Bedenk maar eens welke catastrofale gevolgen de uitval van een ISL-verbinding voor de verbroken SAN s kan hebben. Wanneer daar niet vooraf door het IT-beheer zorgvuldig op is geanticipeerd, dan kan dit tot allerlei ongewenste neveneffecten leiden binnen het SAN waarbij de beveiliging en betrouwbaarheid van de opgeslagen data in gevaar komen.

4 Main datacenter Remote Acquisition Unit Remote datacenter C HTTPS Client GUI HTTPS SANscreen Server Local Acquisition Unit Direct acquisition Lokale datacenter A Direct acquisition Lokale datacenter A Switches s & Clusters Storage Devices Figuur 3: Voorbeeld van een SANscreen-implementatie. 19 lende inzichten naar boven over de geanalyseerde opslagarchitectuur. Op basis van interviews en discussies met gebruikers heeft Onaro deze technische verschillen tussen SRM en SSM vertaald naar een aantal doelstellingen op het gebied van opslagbeheer die voor een onderneming van uitermate groot belang kunnen zijn. Dit zijn: Service Quality: beschikbaarheid opslagsystemen, toepassing disaster recovery operaties, snellere toepassingstijd, migraties die in de pas lopen met de laatste opslagtechnologie, voor het bereiken van optimale prestatieniveaus, Return on Storage Cost: kostverlagende doelstellingen voor zowel duurzame investeringen en operationele uitgaven, data center consolidatie projecten en daaraan gerelateerde kostenbesparingen, Compliance: SOX-wetgeving, initiatieven op het gebied van ITIL en ontwikkeling van standaarden bij operationele procedures. Architectuur De applicatie SANscreen bestaat uit drie hoofdonderdelen, namelijk de Server, Acquisition Unit en Client GUI. De SANscreen Server bevat een SQL-database voor het opslaan van SAN-informatie en een impact analysis en simulation engine. De Acquisition Unit communiceert met de SAN-devices en voorziet de Server van device-informatie. Er zijn twee type Local Acquisition Units (LAU) die op de SANscreen Server wordt geïnstalleerd en één Remote Acquisition Unit (RAU) voor installatie op een of meer (optionele) remote servers. De RAU wordt op een remote server geïnstalleerd om SAN-informatie over remote datacenters te vergaren die volledig vanuit de SANscreen Server wordt geconfigureerd en bestuurd. Installatie van een RAU is vereist wanneer de SANdevices zich achter een firewall bevinden, op een remote site of private netwerk. De Server ontvangt de reguliere updates over veranderingen die in het SAN plaatsvinden van de LAU s en eventuele aanwezige RAU s. Deze updates worden via een beveiligd communicatiekanaal naar de Server verstuurd. SANscreen werkt agentless bij het verzamelen van data over storagedevices. Het voordeel van deze methode is dat storageelementen binnen het SAN kunnen worden ontdekt die voorheen voor het ITbeheer niet bekend waren of niet remote konden worden beheerd. De devicedata wordt opgevraagd door middel van SMI s, SNMP, device-specifieke API s, CLI en http. Daarnaast biedt een ServiceConnect API de mogelijkheid voor gebruikers en software ISV s om applicaties bovenop SANscreen te ontwikkelen die voor allerlei ITbeheertaken kunnen dienen. Dit kan de integratie met bestaande beheersystemen en/of processen zijn. DE ARCHITECTUUR VAN SANSCREEN VERSCHILT FUNDAMENTEEL VAN SRM-APPLICATIES De Client GUI is Java-gebaseerd en biedt toegang tot de verschillende voorzieningen binnen SANscreen. Gebruik SANscreen is ontworpen voor SANbeheerders om problemen met SAN s te detecteren, voorkomen en verhelpen. SANscreen ondersteunt alle levensfasen van een SAN, waaronder: planning, simulatie en vooraf validatie van SAN-wijzigingen, uitvoering van consistente, vooraf gedefinieerde, volgorde van SAN-wijzigingen, vooraf uitgebreide automatische validatie, verzekering van de correctheid, melding van verstoringen en zwakheden van SAN s.

5 Het startpunt voor het beheer van een SAN is de Topology pane, dat een grafische presentatie biedt van het SAN. Daarin worden de SAN-devices en verbindingen afgebeeld en deze vormt het middelpunt van waaruit het SAN wordt beheerd. Bij complexe SAN s met veel devices kunnen gebruikers een view creëren waarin bepaalde groepen devices zijn opgenomen. SANscreen plaatst nieuwe devices automatisch in een topology group en subgroup. Zo bevat een switch subgroup alle switches binnen een bepaalde fabric, of alle disk storagedevices in een Storage Device subgroup. 20 Logical Paths SANview s gepatenteerde technologie is gebaseerd op het fundamentele concept van een logical access path waarbij elk pad een relatie voorstelt tussen een bepaalde applicatie op een server en de data op een opslag-device. Een dergelijke logisch toegangspad bestaat uit een opeenvolging van fysiek verbonden componenten. Een SAN kan meerdere fysieke paden voor elk logisch pad hebben. Elk pad bezit attributen waaronder het beveiligingsniveau en de sharing, mapping en masking van volumes. Beheerders selecteren een bepaald pad in de Topology pane waarbij dit pad groen oplicht in het geval dit een authorized path is en rood bij een violating path. In de Change List zijn alle veranderingen in het pad te zien. Bij de creatie van een pad kan de beheerder allerlei autorisaties instellen, waaronder: redundantieniveau (dual fabric, no SPF en none); sharing (any, cluster of none); minimum aantal actieve host ports en maximum aantal switch hops. Violations zijn inconsistenties tussen SANpaden die door SANscreen automatisch worden gedetecteerd en in het menu Violation Display worden weergegeven. Om een violation op te heffen moeten de fysieke en logische verbindingen in het SAN of het geautoriseerde pad worden aangepast. SANscreen detecteert verschillende type violations, waaronder een ontbrekende actieve host poort, afwezigheid van redundantie of pad, SPF bij een geautoriseerd pad, teveel switch hops in het pad of ongeautoriseerd (wel of gedeeld) pad. Figuur 4: Scherm met SANscreen Topology. zien. Afhankelijk van de specifieke violation geeft de Details-pane tabellen met informatie, waaronder de Mask en Zone definitie, device name, Fabric/VSAN, zone naam, member en type (WWN of Port), status (connected port, WWN, wel of niet verbonden met fabric, VSAN member of onbekende WWN). In een aparte Test Tab kunnen de diverse tests worden geselecteerd om de violation nader te analyseren. SANscreen checkt voortdurend op vulnerabilities, ofwel zwakke punten of onvolkomendheden, bij het monitoren van veranderingen in het SAN. In aanvulling op de herkenning van access path violations rapporteert SANscreen ook vulnerabilities, configuratie en gebruiken die problemen kunnen veroorzaken ook al monden ze niet uit in een path violation. Voorbeelden van vulnerabilities zijn geblokkeerde hosts, niet-verbonden zoneen WWW-members, hoog en laag gebruik van fabric-poorten, masking fan out ratio, incomplete cluster volume sharing en ongebruikte masked volumes. Vulnerabilities SANscreen bevat verschillende tools voor het analyseren en identificeren van violations. Om een violation te analyseren klikt de beheerder op de Violation List waarna hij voor de actie Analyze Violation kan kiezen. SANscreen analyseert de situatie en laat de relevante informatie Figuur 5: De DR Violation List.

6 Figuur 6: De Task List van SANscreen. ONARO S SANSCREEN LIJKT VOORALSNOG HET MEEST GEAVANCEERDE SAN-BEHEERPAKKET THANS OP DE MARKT Taken Geplande en ongeplande veranderingen aan SAN s zijn belangrijke oorzaken voor de uitval van applicaties. Met behulp van SANscreen kunnen beheerders van te voren stap voor stap een change plan aanmaken voor het aanbrengen van wijzigingen binnen het SAN. Taken kunnen eerst met een Excel-spreadsheet of met behulp van een template worden aangemaakt en daarna binnen SANscreen worden geïmplementeerd. In het algemeen bestaat een taak uit acties zoals het toevoegen van een host, host aan cluster, HBA aan een host, toevoegen van een, map/mask, Zone, Zone Member, poorten en autorisatiepaden. Dezelfde acties zijn mogelijk met de opties Remove en map/mask. Een taak kan van te voren worden gevalideerd en iedere keer dat er daarna een wijziging in het SAN plaatsvindt automatisch worden uitgevoerd. Wanneer een taak faalt, dan kunnen beheerders in het Future Violations weer de violations zien en met behulp van de tool Violations is elk pad te analyseren die oorzaak is van een violation. In het venster Tracking Task Execution kunnen beheerders de status van elke actie uit te taaklijst volgen. Tenslotte heeft SANscreen uitgebreide rapportage, signalering en monitoring van de prestaties. Conclusies Voor de evaluatie van SANscreen hebben we alleen een uitgebreide database van de firma Onaro ter beschikking gekregen (Advertentie) Een crash kan een organisatie fataal worden En dat zeggen we niet alleen, we laten ook de oplossing zien. Hoe u uw storage omgeving zo kunt inrichten dat uw data altijd beschikbaar is. In een 1-op-1 sessie met een ISIT consultant. Reserveer nu! waardoor we de evaluatie niet echt in de praktijk hebben kunnen testen. Dit is met name belangrijk om de mate van herkenbaarheid van alle aanwezige componenten in een SAN te kunnen checken. Hiermee valt of staat de bruikbaarheid van ieder SAN-beheerpakket. Wanneer we Onaro s lijst Support Matrix for SANscreen 3 mogen geloven, worden de meeste SAN-componenten via API s, SMI s, SNMP of storagemanagement-software ondersteund. Opmerkelijk is dat ondanks alle hype rondom SMI s, alleen nog HDS, IBM, 3Par en Sun/StorageTek daadwerkelijk SMI s ondersteunen. Op basis van alleen de demodatabase kunnen we concluderen dat Onaro s SANscreen vooralsnog het meest geavanceerde SAN-beheerpakket is dat thans op de markt beschikbaar is. In tegenstelling tot de eerder geteste pakketten biedt SANscreen wél een changemanagementvoorziening waardoor terstond kan worden ingespeeld op veranderingen binnen het SAN. De uitbreide rapportage bij optredende fouten, misconfiguraties en de vooraf te controleren SAN-wijzigingen zijn voor een beheerder onmisbare tools bij het beheer van een complexe SANomgeving. De listprice van SANscreen is circa 175 euro per poort. Onaro heeft nog geen referenties in Nederland maar internationaal zijn er al wel diverse installaties. Het gaat dan om grote banken en telecom operators in de Engeland en de VS, waaronder Nationwide, Deutsche Bank, Vodafone, Centrica, JPMC, WallMart, Citigroup, Cisco, HBOS en State Street. BRAM DONS IS ONAFHANKELIJK IT-ANALIST; INFO@IT-TRENDWATCH.NL. 21