4 SAN, Storage Area Network

Storage

6/4 SAN, Storage Area Network 6/4.1

iSCSI en Novell Cluster Services

De term high availability is een van de nieuwe buzz-words. Elke zichzelf respecterende organisatie heeft het erover. Toch zie je dat de invulling die eraan wordt gegeven, per bedrijf of bedrijfstak verschillend is. Dit heeft te maken met de kosten van de implementatie van een high available-oplossing. Zoals zo vaak in de automatisering, is er geen eenduidige oplossing te bieden die opgaat voor elke situatie. Ten aanzien van beschikbaarheid is dit verhaal nog veel lastiger. Iedere gebruiker en manager van een netwerk zal een zo hoog mogelijke beschikbaarheid willen hebben… totdat er over de prijs wordt gesproken. Als over beschikbaarheid wordt gesproken, hebben we het vrijwel automatisch over clustering en clustering vereist nu eenmaal een Storage Area Network (SAN) voor opslag van gegevens die door meerdere servers moeten kunnen worden gebruikt. Hoe de servers dat doen, zal in de loop van dit hoofdstuk duidelijk worden.

Novell Netwerkoplossingen, aanvulling 11

6/4.1-1

SAN, Storage Area Network

Tot de komst van iSCSI waren er feitelijk maar twee opties voor bedrijven die een hoge beschikbaarheid wilden hebben: • fibre SAN; • SCSI SAN. Van beide typen SAN zal worden uitgelegd wat de voor- en nadelen zijn. Aan de hand van deze voor- en nadelen zal worden uitgelegd wanneer iSCSI een goed alternatief kan zijn.

Definities

6/4.1-2

6/4.1.1 Beschikbaarheid Omtrent beschikbaarheid worden veel termen gebruikt, vaak echter in de verkeerde context. Toch zijn deze termen en definities heel belangrijk om te kunnen begrijpen wat een oplossing of systeem waard is. De belangrijkste vraag is wat we mogen verstaan onder beschikbaarheid (availability). Drie definities zijn hierbij belangrijk: • Mean Time Between Failure (MTBF) De gemiddelde tijd tussen twee storingen aan een device. • Mean Time To Recover (MTTR) De tijd die het kost om een opgetreden storing op te lossen en de systemen hun normale manier van werken te laten hervatten.


Storage

•

Availability (Beschikbaarheid) Het percentage van de totale systeemtijd dat het systeem beschikbaar is voor normaal gebruik. De formele definitie van beschikbaarheid is: availibility (%)=

MTBF MTBF + MTTR

Uit de formele definitie van beschikbaarheid blijkt overigens dat het onmogelijk is om een 100%-beschikbaarheid te kunnen garanderen. De MTTR zou in dat geval immers gelijk moeten zijn aan 0. Aan de andere kant kunnen we ook stellen dat beschikbaarheid een ‘state of mind’ is. Als een server of service een periode (minuten of zelfs uren) niet beschikbaar is geweest, maar gebruikers hebben er niets van gemerkt, zullen ze het gevoel hebben dat het systeem voor 100% beschikbaar is geweest.

DEC

6/4.1.2 Clustering Hoewel pas de laatste jaren binnen de pc-serveromgeving wordt gesproken over clustering, is het in feite al een oude technologie. Digital Electric Corporation (DEC) heeft de term in de jaren tachtig verzonnen voor de VAX/VMS-systemen. Nu het pc-platform steeds meer een mission criticalomgeving is geworden, zijn er vele implementaties van clustering. Clustering gaat ervan uit dat hardware-storingen niet kunnen worden voorkomen. Waar voor moet worden gezorgd, is dat bij een storing aan een stuk hardware de functionaliteit (de services) die wordt geboden, door die storing niet verloren gaat. Binnen een cluster wordt een groep van servers dus verantwoordelijk gemaakt voor een aantal ser-


6/4.1-3


vices. Als een van de servers binnen de cluster crasht, hoeft dat geen probleem te zijn, als een van de andere servers de services maar overneemt. Als die overname snel genoeg verloopt (binnen enkele seconden), zal de gebruiker hier zelfs helemaal niets van merken.

Zo kan een complete GroupWise postoffice binnen enkele seconden van server 1 naar server 3 springen bij een storing aan server 1. De connecties van gebruikers worden automatisch weer opgebouwd en niemand heeft dus in de gaten dat er op een andere machine wordt gewerkt. Vanuit het oogpunt van gebruikers is er dus geen storing geweest. 6/4.1.3 SAN en NetWare Voor het bouwen van een SAN is het SCSI-protocol in veel opzichten te beperkt. Ten eerste is de maximale lengte van een bus niet voldoende om (bijv.) servers in verschillende serverruimten te plaatsen. Daarnaast is het aantal devices dat op een SCSI-bus geplaatst kan worden beperkt. Een derde reden waarom SCSI minder geschikt is voor een omgeving waar een hoge beschikbaarheid wordt verlangd, heeft te maken met de termination van de SCSI-bus. Bij het uitvallen van een van de machines treden toch regelmatig problemen op binnen de SCSI-bus.

6/4.1-4


Storage

Disk-subsysteem

Toch wordt SCSI veel gebruikt voor met name kleine(re) geclusterde omgevingen. De reden hiervoor is dat de aanschaf van een fibre SAN een dermate hoge investering is, dat bedrijven die wél beschikbaarheid willen maar een beperkt budget hebben, toch vaak naar SCSI kijken als alternatief. De grote leveranciers zijn hier goed op ingesprongen en bijvoorbeeld HP, Dell en IBM verkpen disksubsystemen die speciaal geschikt zijn gemaakt voor clustering. De controller van het disk-subsysteem lost hierbij de SCSI-busproblemen op, waardoor binnen een cluster de overlevende node een goede verbinding met de SAN blijft houden. Een nadeel van dit soort systemen blijft echter dat het aantal nodes (servers) dat kan worden aangesloten, beperkt is tot twee. Volgens de definitie van een cluster bestaat een cluster altijd uit minimaal drie nodes. In de praktijk hebben we er geen moeite mee om een 2-nodesysteem ook een cluster te noemen, omdat het feitelijk alle functionaliteiten van een cluster biedt. Als we kijken naar de manier waarop NetWare met clustering omgaat, is het weliswaar veiliger om een 3-nodesysteem te hebben, maar het werkt in vrijwel alle gevallen toch ook goed op basis van twee nodes. De keuze voor het disk-subsysteem werd tot voor kort dus feitelijk altijd gemaakt op basis van het aantal nodes: twee nodes is SCSI, meer nodes wordt automatisch fibre. De komst van iSCSI heeft er echter een derde mogelijkheid aan toegevoegd. Internet SCSI (iSCSI) is een protocol dat is gemaakt om SCSI-commando’s over een TCP/IP-netwerk te kunnen verzenden. Hiermee worden twee van de belangrijkste problemen van SCSI (afstand en aantal devices) direct opgelost.


6/4.1-5


iSCSI SAN versus fibre SAN Ten opzichte van fibre heeft iSCSI feitelijk maar één nadeel (afgezien van de beperkte beschikbaarheid op dit moment), namelijk dat iSCSI niet de performance kan bieden die fibre wel biedt. Omdat er voor iSCSI altijd vertaalslagen nodig zijn op het disksysteem (in iSCSI-termen de target genoemd) en op de server (de initiator) zal een 1 Gb IP-netwerk dus altijd trager zijn dan een 1 Gb fibresysteem. Voordelen

iSCSI heeft echter ook voordelen ten opzichte van fibre. De technologie die binnen SANs wordt gebruikt, is altijd proprietary, waardoor uitwisselen van bijvoorbeeld HP- en EMC2 SAN-devices niet of met heel veel moeite mogelijk is. Ook de kennis die nodig is om het SAN te kunnen beheren, is dus proprietary en hierin zal behoorlijk moeten worden geïnvesteerd: trainingen voor SAN-technologiëen zijn kostbaar. iSCSI heeft dit probleem in veel mindere mate. Omdat IP wordt gebruikt als transportprotocol, gelden dezelfde regels voor een iSCSI-SAN als voor een normaal IP-netwerk. Hoewel niet wenselijk (in verband met performance) zouden we zelfs de iSCSI-commando’s over hetzelfde netwerk kunnen laten lopen als het normale verkeer.

Een ander duidelijk voordeel van iSCSI zijn de kosten: de aanschaf van enkele gigabit ethernetkaarten, kabels en een switch is veel goedkoper dan de aanschaf van fibre optic host bus-adapters, fibre-kabels en een fibre-switch. Het aansluiten van een node op een bestaand fibre SAN kost tussen de 5.000 en 10.000 euro. Op basis van iSCSI liggen de kosten grofweg tussen de 500 en 1.000 euro.

6/4.1-6


Storage

De verwachting is dat grote, data-intensieve (terrabytes aan data) omgevingen fibre zullen gaan of blijven gebruiken en dat de kleinere omgevingen meer gebaat zijn bij iSCSI. De gemiddelde Nederlandse organisatie die een hoge beschikbaarheid wil hebben, is dus een ideale omgeving voor iSCSI. NetWare 5.1 & 6.0 kunnen worden geconfigureerd als iSCSI-initiator (een server die disken uit de iSCSI-SAN gebruikt). De drivers die hiervoor noodzakelijk zijn, kunnen worden gedownload van http://download.novell.com. NetWare 6.5 kan naast initiator ook iSCSI-target zijn. NetWare 6.5 kan zijn disken dus ook als SAN-disken aanbieden. Bij de installatie van NetWare 6.5 kan worden aangegeven dat deze functionaliteit moet worden geïnstalleerd:

De mogelijkheid om iSCSI-target te zijn, lijkt weliswaar voor productieomgevingen minder geschikt, omdat het een single point of failure creëert (de server die de disken servicet). Op zich is dit echter niet zo gek veel anders dan het


6/4.1-7


werken met een single disk-subsysteem (ook dat is een single point of failure). Daarbij zijn we met NSS in staat om NSS-pools (softwarematig) te mirrorren en kunnen we dus op eenvoudige wijze een systeem bouwen met een gemirrorde SAN. In NSS versie 3 is het mirrorring-proces zodanig aangepast dat de performance-hit die we voorheen te verduren kregen bij softwarematig mirrorren, niet meer optreedt.

6/4.1.4 iSCSI in de praktijk Een van de al genoemde voordelen van iSCSI is dat de configuratie veel gemakkelijker is dan van een SAN gebaseerd op fibre-technologieën. De enige versie van NetWare die ook iSCSI-target kan zijn (dus disken kan aanbieden), is NetWare 6.5 en deze software wordt niet standaard mee geïnstalleerd. De reden waarom dit niet standaard wordt gedaan, is eenvoudig: als een NetWare-server als iSCSI-target wordt gebruikt, zullen we deze machine uit oogpunt van belasting (en dus snelheid) en stabiliteit waarschijnlijk nergens anders voor willen gebruiken. Tijdens de installatie van NetWare 6.5 is het daarom mogelijk om de machine via de pattern install al specifiek te configureren als ‘iSCSI SAN Storage server’. Als voor een testomgeving of om een andere reden toch ook andere services op de iSCSI-target moeten kunnen worden gebruikt, kunnen de onderdelen die noodzakelijk

6/4.1-8


Storage

zijn ook los worden geselecteerd. Kies vanuit de manual installation in elk geval de volgende drie services (naast NetWare zelf):

De ervaring is dat het wellicht een goede keuze is om altijd de iSCSI-target te installeren. Hiermee worden namelijk enkele rechten en pointers geplaatst die het werken met iSCSI-initiators eenvoudiger maken. Tijdens of na de installatie kan vanuit iManage of vanuit de nnsmu.nlm de diskconfiguratie worden beheerd. Een van de opties is om iSCSI-partities te maken. iSCSI maakt namelijk geen gebruik van NSS voor beheer van diskruimte. Om deze reden móét tijdens de installatie dus ook diskruimte apart worden gehouden om als iSCSI-disken te kunnen configureren of moeten later disken worden bijgeplaatst. In de nnsmu.nlm kiezen we voor ‘partitions’. In het partitions-scherm kunnen we met INS voor het toevoegen van een partitie kiezen. In het submenu dat nu wordt getoond, zijn maar twee keuzes mogelijk: NSS en iSCSI. Voor iSCSI hoeft alleen de grootte en een (optioneel) label te worden ingevoerd.


6/4.1-9


Om de disken ook daadwerkelijk beschikbaar te stellen, moet op het server-console eerst de software voor de iSCSI-target worden gestart. Dit wordt gedaan met de TON.NCF. Als deze .NCF niet in de autoexec.ncf staat, kan hij met de hand worden gestart, maar het is zeer aan te bevelen om de ncf-file altijd automatisch te starten vanuit de autoexec.ncf: een goede reden om een diskserver op te laten starten zonder zijn disken aan te bieden is er niet. Dit is alles wat op de target-server moet worden gedaan! Controleren of er iSCSI-partities beschikbaar zijn, kunnen we op de target doen met het commando ISCITAR targets:

De lange objectnaam (iscsi-00b188c2- …) is hierna nodig om de rechten op de disk te kunnen regelen. De naam van de partitie (iSCSI partition disk0) kan hiervoor helaas niet worden gebruikt. Om een andere server gebruik te kunnen laten maken van de disken van de target, moeten nu nog twee dingen gebeuren: 1. De servers moeten het recht krijgen om de iSCSI-target te mogen gebruiken. 2. Op de initiator-server moet de software om initiator te zijn nog worden gestart. Dit gebeurt met het commando: ION.NCF.

6/4.1-10


Storage

Rechten op de iSCSI-target Start iManager op en kies voor ‘rights’ en dan voor ‘modify trustees’. Selecteer het iSCSI-object (dit is de informatie van het iscsitar-targetscommando):

Voeg alle servers toe die rechten moeten krijgen op deze partitie of kies voor [public] om toegang tot de iSCSI-target vrij te geven. Dit laatste is alleen noodzakelijk als de iSCSI-target niet in dezelfde tree zit als de initiators, maar dat is natuurlijk een security-risico. Door middel van normale IP-packet-filters (filtcfg.nlm) kan dan op de target worden bepaald wie toegang tot deze server heeft. Connecten met behulp van de ION.NCF Start op de initiator de ion.ncf-file op. Hierdoor worden de drivers gestart waarmee gebruik van iSCSI mogelijk is. Geef vervolgens het commando ISCSINIT DISCOVER IP-adres om de disken te ontdekken. Als de target-server op 10.100.0.1 draait, moet de volgende informatie te zien zijn:


6/4.1-11


Geef vervolgens het commando: ISCSINIT CONNECT 10.100.0.1 om de disken te connecten. Om ervoor te zorgen dat ook op de initiator alles vanzelf verloopt, is het verstandig om deze commando’s op te nemen in de autoexec.ncf:

Herhaal deze acties voor alle servers die gebruik moeten kunnen maken van de shared storage. In het geval van cluster-servers dienen dus alle nodes te worden geconfigureerd om de disken te kunnen gebruiken.

6/4.1-12


deel 6_4_AV19

19-04-2006

13:54

Pagina 13

Storage

iSCSI-initiator

6/4.1.5 Configuratie van iSCSI Als u iSCSI wilt gebruiken voor gedeelde opslag, zijn er in het netwerk twee componenten nodig. De eerste component is de iSCSI-target. Dit is een node in het netwerk die een gedeelde harddisk aanbiedt aan de andere nodes. Hiervoor kan gebruikgemaakt worden van een speciale storage router die voor dit doel ontworpen is, maar ook is het mogelijk gebruik te maken van een server waarop iSCSItargetsoftware geïnstalleerd en geconfigureerd is. In deze paragraaf maken wij van het laatste gebruik. Naast de iSCSI-target die gebruikmaakt van gedeelde opslag, is er de iSCSI-initiator. Dit is een stuk software dat contact maakt met de iSCSI-target om de gedeelde opslag te benaderen. In principe is het aantal nodes waarop de iSCSI-initiator draait om contact te maken met een iSCSI-target onbeperkt. U dient er echter rekening mee te houden dat afhankelijk van het bestandssysteem dat op een iSCSIharddisk gemaakt wordt, maar één node gelijktijdig naar de gedeelde partitie kan schrijven. In het onderstaande leest u eerst hoe u iSCSI-target en -initiator aanmaakt op SuSE Linux Enterprise Server. Na de bespreking van de procedure vanuit de grafische interface, wordt aandacht besteed aan de configuratiebestanden die met deze procedure aangemaakt worden zodat u ook op andere Linuxdistributies met iSCSI aan het werk kunt. Verschillende projecten Er zijn verschillende projecten die pogen een iSCSI-stack beschikbaar maken voor het Linux-platform. Een aantal van deze projecten heeft een commerciële basis. Wij bespreken de openiscsi implementatie, een volledig open source-implementatie van de iSCSI-protocolstack.


6/4.1-13

deel 6_4_AV19

19-04-2006

13:54

Pagina 14


Configuratie van de iSCSI-target In SuSE’s YaST zit onder de optie miscellaneous een toepassing waarmee u de iSCSI-target kunt configureren. In de onderstaande procedure leest u hoe u hiervoor te werk gaat. Voordat u echter begint, dient u zich er van te verzekeren dat u een harddisk hebt die u in zijn geheel met behulp van iSCSI kunt delen. 1. Start vanuit YaST de iSCSI-targettoepassing. De software vraagt nu of u de hiervoor benodigde packages wilt installeren. Doe dit door op Continue te klikken en volg de aanwijzingen die nodig zijn voor de installatie van de softwarepackages. 2. U ziet nu een venster met daarin drie tabs. Selecteer op de tab Service de optie When booting, dit zorgt ervoor dat elke keer bij het opstarten van uw server de iSCSI-targetservice gestart wordt. Zorg er ook voor dat de optie Open Port in Firewall geselecteerd is zodat de SuSE firewallverkeer naar de iSCSI-target toestaat. 3. Op het tabblad Global stelt u de wijze waarop authenticatie geregeld moet worden in. Maak hier gebruik van als u ervoor wilt zorgen dat niet iedereen met behulp van een iSCSI-initiator zomaar contact op kan nemen met uw iSCSI-target. U regelt de authenticatie door CHAP secrets op te geven: deze bestaan uit een gebruikersnaam en een bijbehorend wachtwoord. Deze gebruikersnaam en wachtwoord hoeven niet in de lokale gebruikersdatabase /etc/passwd te bestaan, de enige vereiste is dat de iSCSI-initiator gebruikmaakt van dezelfde gebruikersnaam en wachtwoord. Tevens is het mogelijk inkomende en daarnaast ook uitgaande authenticatie te configureren. Hiermee voegt u een extra beveiligingslaag toe. Om het eenvoudig te houden, kiezen wij er in deze procedure voor gebruik te maken van

6/4.1-14


deel 6_4_AV19

19-04-2006

13:54

Pagina 15

Storage

de standaardoptie waarin geen gebruikgemaakt wordt van authenticatie.

Om een extra laag van beveiliging toe te voegen, kunt u gebruikmaken van een gebruikersnaam en wachtwoord voor authenticatie.

4.

Nu moet u aangeven hoe de iSCSI-target geïdentificeerd moet worden. In principe mag u hier elke mogelijke identificatie gebruiken, zolang u maar consequent bent en ook naar dezelfde gegevens verwijst wanneer u de iSCSI-initiator configureert. Om de iSCSI-target aan te maken, hebt u vier soorten gegevens nodig:


6/4.1-15

deel 6_4_AV19

19-04-2006

13:54

Pagina 16


• Target: Hier geeft u de naam op van de iSCSI-target. Gebruik hiervoor het formaat iqn.yyyymm..sitenaam, bijvoorbeeld iqn.2006-03..site. • Identifier: Geef een korte naam op basis waarvan u de iSCSI-target kunt identificeren. • LUN: Specificeer hier het logische device ID. • Path: Dit is een belangrijk onderdeel: u verwijst hiermee namelijk naar het device dat u wilt delen. U mag hiermee verwijzen naar een block device, een LVM-volume, een RAID array of zelfs naar een bestand. Wij raden u aan hiervoor ofwel een logisch volume, ofwel een complete harddisk (bijvoorbeeld /dev/sdb) te gebruiken.

Om de iSCSI-target aan te maken, geeft u vier verschillende soorten eigenschappen op.

6/4.1-16


deel 6_4_AV19

19-04-2006

13:54

Pagina 17

Storage

5.

Nadat u alle gewenste eigenschappen van de iSCSItarget opgegeven hebt, klikt u op Next om verder te gaan. De wijzigingen worden nu weggeschreven. Vervolgens wordt gevraagd of u de iSCSI-targetsoftware opnieuw wilt starten om de wijzigingen te activeren. Accepteer dit voorstel door op Yes te klikken.

Handmatige configuratie van de iSCSI-target Als u handmatig de iSCSI-target wilt initialiseren, moet u ervoor zorgen dat de benodigde configuratiebestanden aangemaakt worden. Hieronder staan de meest belangrijke onderdelen van de iSCSI-target: • ietd: Dit is de iSCSI Enterprise Target Daemon. Dit proces wordt doorgaans gestart met een rc-script als /etc/init.d/iscsitarget; kijk op uw distributie wat de exacte naam is. • Het configuratiebestand /etc/ietd.conf. In dit configuratiebestand wordt gespecificeerd welke targets er allemaal beschikbaar gesteld worden door deze targetsoftware. De specificatie van de target kan er als volgt uit zien: Target iqn.2006-03..site:harddrive Lun 1 Path=/dev/sdb,Type=fileio

Deze specificatie van de naam van de target bestaat uit twee onderdelen. In het eerste deel wordt de naam van de target gespecificeerd. Het is niet bijzonder belangrijk welke naam u hier gebruikt, zolang deze naam maar uniek is. Standaard begint deze naam altijd met de aanduiding iqn, gevolgd door het jaar en de maand waarin de target voor het eerst geïnitialiseerd werd. Daarna volgt de naam van de site waarop de target in gebruik is en daarna een aanduiding van het storage device. In het voorgaande is de naam van de site vrij eenvoudig, als een internet DNS-site-


6/4.1-17

deel 6_4_AV19

19-04-2006

13:54

Pagina 18


naam in de targetnaam verwerkt wordt, zou dit er bijvoorbeeld uit kunnen zien als iqn.2006-03.com.sandervanvugt:harddrive. In de tweede regel van de target specificatie wordt aangegeven welk device (of bestand) gedeeld wordt door de target. Er bestaat een mogelijkheid te werken met meerdere logische units (LUN’s), wij raden u aan om voor het gemak slechts een logische unit te gebruiken en deze de naam Lun 1 te geven. Daarachter specificeert u naar welk fysiek device de LUN verwijst. Tot slot geeft u met de optie Type aan wat voor type target het moet worden. In vrijwel alle gevallen zal het type ingesteld staan op fileio omdat het de bedoeling is bestanden te schrijven van en naar de target. Nadat u het configuratiebestand ietd.conf op de juiste wijze gestart hebt, kan de bijbehorende targetsoftware gestart worden. Uw iSCSI-target is dan operationeel. Tip

Let erop dat de meeste firewalls toegang tot de iSCSI-target standaard niet toestaan. Als er op uw systeem een firewall actief is, zorg er dan voor dat in deze firewall de iSCSI-targetpoort open staat. Installatie van de iSCSI-initiator Nadat u ergens op het netwerk een iSCSI-target aangemaakt hebt, wordt het tijd ook een iSCSI-initiator te configureren. Dit is het stuk software dat contact gaat maken met de driver die u met behulp van de iSCSI-target gedeeld hebt. Typisch doet u dit op meerdere nodes op het netwerk, dat is immers precies waar het bij de configuratie van gedeelde opslag om gaat. 1. Activeer vanuit YaST het menu Miscellaneous en klik dan op iSCSI-initiator.

6/4.1-18


deel 6_4_AV19

19-04-2006

13:54

Pagina 19

Storage

2.

3.

4.

5.

Klik op Continue als gevraagd wordt of u de iSCSI-initiatorsoftware wilt installeren. Zorg ervoor dat het juiste installatiemedium aanwezig is om deze installatie af te ronden. Kies op het tabblad Service de optie When booting om ervoor te zorgen dat de iSCSI-initiatorsoftware tijdens het opstarten automatisch geactiveerd wordt. Klik nu op het tabblad Discovered Targets. Hier hebt u de gelegenheid aan te geven met welke iSCSI-target u contact wilt maken. Klik hiervoor op Add en voer dan het IP-adres in van de target waarmee u contact wilt maken. Als dat gebeurd is, neemt de software contact op met de target om een lijst op te vragen van alle targets die beschikbaar zijn en de devices die door die targets gedeeld worden. Activeer nu het tabblad Connected Targets. Hierop geeft u aan met welke iSCSI-targets deze initiator moet verbinden. Dat mogen meerdere targets zijn, dit ligt echter niet voor de hand. Klik hier op Add om de dialoog te openen waarmee u iSCSI-targets toe kunt voegen. Vervolgens klikt u op de target waarmee u contact wilt maken. Klik dan op Connect om een verbinding met deze target tot stand te brengen. Klik op Finish om het scherm af te sluiten.


6/4.1-19

deel 6_4_AV19

19-04-2006

13:54

Pagina 20


In het venster Connected Targets moet u aangeven met welke iSCSI-target u contact wilt maken.

6.

Als alles goed gegaan is, bent u nu verbonden aan de iSCSI-target. Dit betekent dat u er toegang tot een andere schijf bij hebt gekregen. Dit kunt u controleren met behulp van de opdracht sfdisk -l; deze opdracht toont een overzicht van alle devices die op dit moment bekend zijn. Trek u er niets van aan als voor het nieuwe device aangegeven wordt dat deze een unrecognized partition table heeft, waar het om gaat is dat u op dit moment verbonden bent.

De iSCSI-initiator vanaf de commandoregel Als u geen gebruikmaakt van SuSE Linux, is het ook mogelijk een iSCSI-initiator te configureren. In dat geval moet u ervoor zorgen dat een en ander met behulp van de juiste configuratiebestanden wordt geregeld. Een iSCSI-configu-

6/4.1-20


deel 6_4_AV19

19-04-2006

13:54

Pagina 21

Storage

ratie bestaat uit een aantal onderdelen die hieronder worden genoemd: • De iSCSI-database. Dit is een database waarin de aan iSCSI gerelateerde informatie wordt opgeslagen. Als u gebruikmaakt van iSCSI uit het openiscsi-project, wordt deze database aangemaakt in /var/db/iscsi. De database bestaat uit twee onderdelen: de discovery table (discovery.db) en de node table (node.db). U benadert deze database doorgaans niet rechtstreeks, maar met behulp van de opdracht iscsiadm. Gebruik bijvoorbeeld iscsiadm -m node om een overzicht te krijgen van alle nodes die door de iSCSI-initiator ontdekt zijn. • Het commando iscsiadm. Met behulp van deze opdracht beheert u de iSCSIdatabase. Zoals in het voorgaande aangegeven, kan bijvoorbeeld de opdracht iscsiadm -m node gebruikt worden om een overzicht op te vragen van alle nodes waar op dit moment verbinding mee bestaat. Een ander zeer handige opdracht is de opdracht iscsiadm -m session waarmee een overzicht gegenereerd wordt van huidige sessies die tot stand gebracht zijn. De verbindingen die hier worden aangegeven, geven aan met welke iSCSI-target op dit moment een geïnitieerde verbinding bestaat. De opdracht iscsiadm kan werken in twee modi: een discovery modus en een node modus. De discovery modus is met name handig omdat deze het mogelijk maakt dynamisch te ontdekken welke targets er beschikbaar zijn en daar automatisch op in te loggen. Om dit met behulp van iscsiadm voor elkaar te krijgen, gebruikt u de opdracht iscsiadm -m discovert –type=SendTargets –portal=10.0.0.10 –login. Deze opdracht zorgt ervoor dat op de node met het genoemde IP-adres


6/4.1-21

deel 6_4_AV19

19-04-2006

13:54

Pagina 22


•

•

6/4.1-22

automatisch contact gemaakt wordt met alle targets die daar beschikbaar zijn en dat daar bovendien automatisch op wordt aangemeld. Met de optie — type geeft u aan op welke wijze de discovery uitgevoerd moet worden. Hiervoor zijn drie methodes beschikbaar: SendTargets, SLP en iSNS. SendTargets is de meest robuuste methode omdat deze in het iSCSI-protocol gespecificeerd is en u er niets extra’s voor nodig hebt. iSNS is universeler omdat dit naast iSCSI ook werkt op FibreChannel en SLP maakt gebruik van het Service Location Protocol om de targets dynamisch door middel van SLP te ontdekken. Op het moment dat dit geschreven werd, was deze laatste methode nog niet geïmplementeerd. De iSCSI-services. Om een iSCSI-initiator te starten, wordt gebruikgemaakt van het proces /sbin/iscsid. Dit proces zal meestal gestart worden door een rc-script met een naam als /etc/init.d/iscsi. Gebruik dus bijvoorbeeld /etc/init.d/iscsi start om de iSCSI-services te starten. Het configuratiebestand /etc/iscsid.conf. In dit configuratiebetand kan de werking van het iSCSI-proces geoptimaliseerd worden. De meeste parameters die u in dit bestand tegenkomt zijn parameters waarmee de werking van het protocol geoptimaliseerd kan worden. Doorgaans bestaat er geen reden om deze parameters aan te passen. Het enige dat doorgaans voor aanpassing in aanmerking komt, zijn de parameters die betrekking hebben op gebruikersnaam en wachtwoord: hiermee stelt u indien nodig de gebruikersnaam en het wachtwoord in die nodig zijn voor CHAP-authenticatie op de target.


deel 6_4_AV19

19-04-2006

13:54

Pagina 23

Storage

•

Het configuratiebestand /etc/initiatorname.iscsi. In dit bestand wordt een naam opgenomen voor de iSCSI-initiator. Deze naam wordt dynamisch gegenereerd bij de installatie van iSCSI. In sommige implementaties kan deze naam gebruikt worden om permissies op het gebruik van de iSCSI-target te regelen. Dit is momenteel binnen de openiscsi-stack niet geïmplementeerd.


6/4.1-23

deel 6_4_AV19

19-04-2006

13:54

Pagina 24


6/4.1-24


Storage

6/4.2

Voordelen

SAN’s en clusters

6/4.2.1 Inleiding In veel automatiseringsomgevingen is tegenwoordig een cluster opgenomen. Soms is het niet duidelijk waarom zo’n cluster er is, maar meestal hebben ze als doel het bieden van een hoge mate van redundancy om services en resources on line te laten bij uitval van een server, iets wat high availability wordt genoemd. Daarnaast biedt zo’n cluster, zij het in mindere mate, load balancing. In een clusterconfiguratie is veelal een Storage Area Network (SAN) aanwezig. Een SAN is een techniek die voor de gebruikers een gedeelte van de IT-omgeving ontsluit door alle servers aan te sluiten op een speciaal netwerk waarbij de fysieke storage areas (de schijven) zijn geplaatst in gedeelde machines. Deze machines zijn schijfconfiguraties die voor alle servers beschikbaar zijn. Door hierbij cluster-services in te zetten, is het mogelijk om een high availability-oplossing te bouwen, omdat bij uitval van een server de storage areas beschikbaar blijven via een andere server binnen de configuratie. Dit levert de volgende voordelen op: • De aan te schaffen servers hoeven niet zo ‘zwaar’ te zijn als in de stand-alone manier van werken. De hardware redundancy wordt verkregen vanuit de cluster-services. • De configuratie van de schijven gebeurt op een eenduidige manier, omdat ze worden ingesloten in een enkel schijvencabinet. • De vervanging van fysieke componenten bij uitval is snel en efficiënt uit te voeren als er gebruik wordt gemaakt van ‘standaard’-componenten en de configuratie op gedeelde media is opgeslagen.


6/4.2-1

SAN’s en clusters

In hoofdstuk 3 van dit boek wordt het nodige gezegd over redundantie en clusters maar toch ook hier wat uitleg over waar een geclusterde omgeving uit bestaat: • Cluster Nodes: servers die onderdeel van het cluster zijn. Hierop draait een operating system en clusteringsoftware. De nodes zijn middels een of twee fiber channel storage controllers verbonden aan het SAN. Daarnaast heeft elke node minimaal een verbinding met het netwerk. • SAN (Storage Area Network): een netwerk van devices die middels fiber channel zijn gekoppeld. De kern van een SAN zijn de switches waarop alle devices zijn aangesloten. De devices zijn: – de nodes (fysieke servers); – storage controllers, waarachter de fysieke storage hangt; – Management Appliance, (vaak) een black box met de beheerderssoftware; – Tape-units die middels een Modular Data-router is verbonden aan het SAN. IT-organisaties die een cluster hebben of bezig zijn er een aan te schaffen, weten dat alleen al de aanschaf van de hardware een kostbare onderneming is. Heel soms is het mogelijk om vooraf een kosten-batenanalyse te maken. Hierbij worden de aanschaf en de ontwikkeling van een clusteromgeving uitgezet tegen de vermoede kosten die de down-tijd van een serverpark met zich mee brengt. Vaak is de analyse moeilijk te maken omdat de wens van de gebruikersorganisatie zich niet altijd in getallen laat omzetten. Een andere reden hiervoor is dat het werk van de gebruikers niet per definitie stil ligt als er systemen niet on line zijn.

6/4.2-2


Storage

De kosten die de implementatie van een cluster met zich meebrengt, zijn enerzijds de hardware, vaak het grootste deel. Anderzijds zijn er de kosten van het ontwerpen en de kosten van het bouwen.

Relatief eenvoudig

Om met het laatste te beginnen, eenieder die met NCS (Novell Clustering Services) heeft gewerkt, weet dat het bouwen van een cluster een relatief eenvoudige klus is: de wizards volgen en in no time draait het cluster. Ook de configuratie van een SAN is een klus die niet lang hoeft te duren als men maar weet hoe de interface van de beheermodules werkt. In de praktijk blijkt echter dat heel vaak het ‘echte ontwerpen’ van een cluster achterwege blijft, wat resulteert in een configuratie die niet overeenkomt met de wensen van de gebruikers of de beheerders. Zo kunnen bijvoorbeeld voor de gebruikers ongewenste vertragingen optreden. Voor de beheerders kan het bijvoorbeeld een systeem worden dat met zeer veel effort dient te worden beheerd. Dit hoofdstuk gaat in op alle aandachtspunten die bij een cluster en SAN-ontwerp relevant zijn, van harddisk tot de clusteringsoftware. 6/4.2.2 Ontwerp Allereerst is het van belang te bepalen welke diensten (services) zo belangrijk zijn voor de organisatie dat ze met een high availability-oplossing moeten worden aangeboden. Zoals gesteld is de implementatie van high availability kostbaarder dan dedicated servers – dus als de oplossing niet hoeft te worden gebruikt, scheelt dat weer in de effort en de kosten. Om services aan te bieden in een clusteromgeving, dient eerst bekend te zijn wat wordt aangeboden. Hiermee kan worden bepaald of de services


6/4.2-3

SAN’s en clusters

binnen een clusteromgeving dienen te worden geplaatst of dat ze op dedicated servers actief moeten worden.

Gebruikers- en processervices

Grofweg zijn de meeste services onder te verdelen in twee categorieën. Gebruikersservices en processervices. Gebruikersservices zijn die diensten die door de gebruikers direct worden benaderd. Processervices zijn diensten die of indirect door de gebruikers worden benaderd, of helemaal niet door de gebruikers worden benaderd. In het laatste geval zijn het services die alleen dienen voor het functioneren van de IT-omgeving als geheel. De gebruikersservices bestaan onder andere uit: • file-services; • printservices; • mailservices; • authenticatie-services (DS-services); • webservices; • applicatieservices; • terminal-services. De processervices bestaan onder andere uit: • indirecte services (voor de gebruikers DHCP, SLP, DNS enz.); • directory- en databaseservices (deze dienen voor een juiste werking en vulling van de diverse subsystemen en van het netwerk). Hierin vindt opslag plaats van alle objecten van de IT-omgeving evenals de koppelingen tussen de diverse systemen. Vervolgens kan er worden bepaald wat belangrijk genoeg is om op te nemen in een clusteromgeving. Dit is uiteraard per organisatie verschillend. Er zijn echter een paar services die (bijna) overal even (on)belangrijk zijn. Samen met de (on)mogelijkheid om ze te clusteren, bepalen ze

6/4.2-4


Storage

Richtlijnen

voor een groot deel het ontwerp. Er zijn een paar globale richtlijnen die we kunnen volgen: • Kunnen de gebruikers enige tijd zonder de service? Als dit het geval is, is het wellicht niet nodig om de service te clusteren. • Heeft de service storage nodig? En zo ja, is het mogelijk de informatie op shared storage te plaatsen? Als we kijken naar de eerder genoemde services, zijn er een paar hele opmerkelijke bij. • DHCP: Indien de clients op een netwerk afhankelijk zijn van DHCP, is dit een van de belangrijkste services om in een cluster op te nemen. Zonder DHCP zou immers niemand kunnen werken. Een andere belangrijke reden om dit in een cluster op te nemen, is dat het niet mogelijk is om twee DHCP-servers te activeren voor hetzelfde subnet. Dus twee dedicated servers is hierbij geen oplossing. • DNS: In veel IT-omgevingen wordt steeds meer gebruikgemaakt van DNS resolving. Belangrijk genoeg dus om in een cluster op te nemen. Aan de andere kant is het echter een service die op meerdere servers tegelijk kan draaien. Dit laatste kan dus een argument zijn om de service niet te clusteren maar simpelweg op meerdere servers actief te maken. DNSservers worden zelden opgenomen in een clusterconfiguratie. • SLP: In moderne Novell-netwerken is SLP een onmisbaar protocol voor het lokaliseren van services. De default-configuratie is echter niet echt de gewenste set-up, dus dient er een Directory Agent te worden ingericht. Deze service is belangrijk genoeg om in een cluster op te nemen. Echter… net als DNS is het mogelijk meerdere DA’s op een netwerk te plaatsen


6/4.2-5

SAN’s en clusters

•

•

(Novell adviseert vaak om het er bij één te houden). Uit dat oogpunt is het clusteren van de service dan weer niet nodig. Daarnaast is het niet gewenst op een cluster, omdat de techniek het tegenhoudt. File-services: Deze services zijn traditioneel een service die voor clustering in aanmerking komt. Indien de gebruiker niet bij zijn of haar informatie kan, zal voor deze persoon het werken vaak heel moeilijk worden. NDS/eDirectory/LDAP/authenticatie-services: Deze service wordt bijna nooit meegenomen in een geclusterde omgeving omdat hij simpelweg niet te clusteren is (buiten Radius dan). Net als bij DNS wordt deze service verspreid over diverse servers, al dan niet opgenomen in een cluster. Het inzetten van een cluster heeft daarentegen wel invloed op bijvoorbeeld het NDS-ontwerp. In de volgende paragraaf wordt besproken wat de invloed van replicaplaatsing kan zijn op een clusterontwerp.

Enkele grote vs vele kleintjes Traditioneel worden er vaak dedicated servers ingezet voor de diverse klussen. Waarom? Ze zijn beter te tunen en er kunnen specifieke aanpassingen op worden gedaan. In die lijn der gedachten worden ook vaak clusters ingezet.

6/4.2-6


Storage

Voordelen

Nadelen

Op deze manier is – zoals te zien in de figuur – een ‘traditioneel’ Novell-cluster te realiseren. Per service is een groep nodes aangewezen als hosts (functioneel cluster). Aan deze opzet kleven een aantal opmerkelijke voordelen: • Duidelijk te berekenen wat de benodigde hardware is (bijv. data, server x en duizend gebruikers). • De tuning kan per server plaatsvinden en de resource-servicerelatie is één op één, wat het beheer overzichtelijk maakt. In een dergelijke set-up wordt uitgegaan van bijvoorbeeld één GroupWise postoffice per server met een groot aantal gebruikers. • Een nadeel is dat in het geval van een fail-over de postoffice wordt verplaatst en dat een andere server de complete load van twee servers moet dragen. Hierop dient de server capaciteit dus te zijn berekend.


6/4.2-7

SAN’s en clusters

•

Een tweede nadeel is dat bijvoorbeeld bij GroupWise het niet de voorkeur geniet om meerdere postoffices op een enkele server te plaatsen. Doordat elk postoffice-agent een maximaal percentage van de CPU-tijd mag gebruiken, kunnen twee postoffices elkaar in de weg gaan zitten bij bijvoorbeeld het indexeren.

Een ander nadeel is dat een bepaalde service maar door één link beschikbaar is. Dit lijkt op zich geen probleem, mits er wordt uitgegaan van deze functionele clusters. Echter, door de functionele cluster te mixen, ontstaat de mogelijkheid om services verder te verdelen over het totale aantal nodes. Dit levert het voordeel op dat services die veel I/O vereisen (GroupWise controleert elke minuut of er nieuwe mail is) kunnen worden samengevoegd met services die minder I/O vereisen (dataopslag vereist alleen I/O bij het lezen en schrijven). Als voorbeeld: een cluster met twee GroupWise-servers en twee dataservers heeft als resultaat dat het ‘totale’ GroupWise-systeem middels twee netwerklinks beschikbaar is, terwijl als GroupWise en de data opslag worden verdeeld over alle vier de servers, GroupWise (het meest I/O-intensief) over vier netwerkverbindingen beschikbaar is (handmatige load balancing).

Task slots

6/4.2-8

Om dit te realiseren, zou een service kunnen worden verdeeld in task slots. De gedachte is om het aantal task slots per services te zetten op het aantal nodes in een cluster –1. Dus een server voor dataopslag (één server met één volume gemount) wordt verdeeld in een server met (aantal nodes –1) volumes. Een task slot is een meeteenheid om capaciteit (of belasting) weer te geven.


Storage

Schematisch zou dit er als volgt uitzien:

Te zien is dat er 6 dedicated servers met die ene bepaalde service hosten. Deze services worden in (6–1=) 5 task slots verdeeld. Door deze task slots door elkaar te halen, ontstaat de situatie als in de volgende figuur, waarbij het GroupWise-systeem dus over meer dan twee verbindingen is te benaderen.

Let op

Als er twee task slots zijn met GroupWise op een enkele node, wil dit niet zeggen dat er twee postoffice-agents aanwezig zijn. Het is zoals eerder gesteld een meeteenheid om te behalen waar wat komt te draaien. Hierbij geldt wel de voorwaarde dat de tuning voor de diverse services ongeveer gelijk is. Zo is het niet mogelijk om eDirectory (vanwege het cache-gebruik) en BorderManager-services (vanwege de I/O-configuratie) te mixen. Een mix van


6/4.2-9

SAN’s en clusters

dataopslag en GroupWise is wel mogelijk, omdat de I/Oconfiguratie nagenoeg gelijk is en er alleen op volumeniveau verschillen zijn. Door verschillende volumes te gebruiken, kan dit op een enkele server aanwezig zijn. Het verlies in minimaal. Vervolgens zal met behulp van bovengenoemde configuratie en de eerdergenoemde gewenste services moeten worden bepaald hoe een en ander moet worden geconfigureerd, onder meer hoe op migraties en fail-overs moet worden gereageerd. Een ander groot voordeel van het werken met de task slots is dat in het geval van een fail-over niet de volledige load van één server bij één andere server terechtkomt, maar dat de tasks slots over de servers kunnen worden verdeeld. Dit is de reden dat het aantal task slots gelijk is aan het aantal nodes –1. In het volgende voorbeeld zijn de task slots verdeeld en gemixt over de 6 nodes.

Node twee krijgt bijvoorbeeld een abend en wordt uit het cluster verstoten. Nu kunnen de tasks slots worden verdeeld over de resterende 5 nodes, waardoor het volgende plaatje ontstaat.

6/4.2-10


Storage

Nogmaals dient te worden gesteld dat niet elk task slot bijvoorbeeld één agent is. Dus wellicht kan de verdeling niet zo ‘mooi’ als hier worden weergegeven. Dit dient per cluster te worden bekeken. Bovenstaande techniek is alleen interessant voor clusters met meer dan 4 nodes Deze opzet pleit ervoor zoveel mogelijk te granuleren. Liever vier kleinere servers dan twee grote. Er kleeft wel een nadeel aan deze opzet. De servers zijn nu namelijk niet volledig te tunen voor de service die ze hosten. Op zich is dat geen groot probleem als we bedenken dat een deel van de tuning bijvoorbeeld bestaat uit file system-parameters die per schijf zijn in te zetten. Een ander veelgehoord argument is dat het niet is aan te raden diverse soorten services te mixen. Als we kijken naar het soort belasting per service, valt dat eigenlijk mee. Hierna is in een tabel opgenomen welke service welke belasting oplevert.


6/4.2-11

SAN’s en clusters

Service

I/O-belasting

Memorybelasting

CPU-belasting

File-services

Laag met hoge pieken

Hoog

Mailservices

Matig met hoge pieken

Matig

Printservices DS-services IP-services

Laag met hoge pieken Laag Matig met weinig pieken Hoog Laag (veel ‘klein’ verkeer) Laag

Laag met enkele pieken Matig met enkele pieken Laag Matig Laag

Zoals te zien is, kunnen bijvoorbeeld file-services en mailservices prima samen draaien. De pieken zijn vaak zo kort, dat ze niet samenvallen. Uiteraard is een en ander afhankelijk van de hoeveelheid clients. Tip!

6/4.2-12

Het hiervoor genoemde model is gebruikt in een omgeving met ongeveer 25.000 gebruikers en daarbij zijn een paar opvallende zaken geconstateerd die van invloed zijn op het clusterontwerp maar niet direct in het ontwerp thuishoren. Als bijvoorbeeld de user home directory’s worden verspreid over meerdere volumes (meerdere task slots), wordt geadviseerd ervoor te zorgen dat er DS-informatie van die gebruikers op de betreffende node aanwezig is. Bijvoorbeeld: user1 heeft zijn home directory staan op USR1. Initieel laadt dit volume op node 1. In dit geval dient node 1 een replica te hebben van de container waarin het gebruikersaccount van user1 zit. Als dit niet het geval is, zullen er external references en backlinks ontstaan naar de servers waarop wel een replica aanwezig is en ontstaat er een hoop extra verkeer. Daarbij is het ook aan te raden om het message server-attribuut van de user te laten verwijzen naar de node waarop zijn home directory initieel aanwezig is. Dit om ongewenste connecties naar andere servers te voorkomen. Bij een fail-over zal het ongewenste verkeer wel ontstaan, maar dat is dan ook een Novell Netwerkoplossingen, aanvulling 13

Storage

noodsituatie. Het DS-ontwerp werkt dus nauw samen met het clusterontwerp. In een ontwerp is het van net zo’n groot belang dat wordt bepaald hoe een noodsituatie wordt afgehandeld als het bepalen waar de services initieel draaien. De gewenste situatie is immers dat de services zich verspreiden over alle andere nodes. Hiervoor wordt een fail-over-schema gemaakt. Daarin staat welke service waar initieel draait en waar deze naartoe gaat in het geval een of meerdere servers uitvallen. Hieronder is een fail-over-schema gemaakt voor een 4node cluster met 12 services. Node

Primary Service

Fail-over to

FS1

APPL1 MAIL1 HOME1 APPL2 MAIL2 HOME2 DATA1 HOME3 WEB DATA2 HOME4 DHCP

FS2 FS3 FS4 FS1 FS3 FS4 FS1 FS2 FS4 FS1 FS2 FS3

FS2

FS3

FS4



Indien er een storing optreedt, moet een eventuele failover snel en efficiënt plaatsvinden. Hiervoor wordt vooraf bepaald welke server de services overneemt van een andere server.


6/4.2-13

SAN’s en clusters

Er dient altijd een uitwijkmogelijkheid meer te zijn dan het aantal fail-overs dat is toegestaan ofwel het minimale aantal servers dat moet blijven draaien om het cluster actief te houden. Dit is nodig om te voorkomen dat een cluster resource in comatose state eindigt omdat alle nodes waarop de service mag draaien down zijn. Het aantal failovers voor de berekeningen dient (aantal nodes –1) servers te zijn. De schuin genoteerde nodes in de kolommen ‘Fail-over to:’ in de tabel hiervoor behoeven niet daadwerkelijk te worden ingevuld. De reden hiervoor is dat een clusteruitval door software abends ervoor zouden kunnen zorgen dat alle nodes uiteindelijk onderuitgaan. De afweging is echter wel dat een aantal resources zo lang mogelijk beschikbaar moet blijven, omdat daarvoor juist een clusteropstelling is gekomen. 6/4.2.3 Inrichting SAN Een clusterontwerp en een clusterimplementatie die de eerdergenoemde richtlijnen volgen, hebben invloed op de inrichting van het SAN. Ook hiervan dient een gedegen ontwerp te worden gemaakt met daarbij de noodzakelijke keuzes. Redundancy Als eerste moet worden bepaald hoe belangrijk de continuïteit is ten opzichte van de investeringen. Een SAN bestaat immers al uit minimaal 3 nodes met fiber channel host bus adaptors (FCHBA), een switch (fabric) en storage. Nu kan ook een switch uitvallen wat zou betekenen dat het hele SAN stopt met functioneren. Het is mogelijk om switches, fchba’s en dergelijke dubbel uit te voeren.

6/4.2-14


Storage

De eerste optie is een fiber channel-architectuur op basis van No-Single Point of Failure (NSPoF)-configuratie. Dit betekent dat er twee fysiek gescheiden fiber channel fabrics worden geconfigureerd. Meerdere aan elkaar gekoppelde switches vormen gezamenlijk een logische eenheid die een ‘fabric’ wordt genoemd. Schematisch is deze architectuur weergegeven:

Het plaatje is een voorbeeld, een 2-node cluster is géén cluster.

Een andere fiber channel-architectuur is een meer schaalbare oplossing. Dit betekent dat er een fiber channel fabric wordt geconfigureerd, bestaande uit twee switches. Meerdere aan elkaar gekoppelde switches vormen gezamenlijk een logische eenheid, die een ‘fabric’ wordt genoemd. Echter, bij het uitvallen van een switch, zal een deel van het cluster niet meer functioneel zijn. Is er maar één switch opgenomen, dan zal bij switch of controller failure het hele cluster onbereikbaar zijn.


6/4.2-15

SAN’s en clusters

Voor een hoge mate van redundancy en om meerdere poorten te verkrijgen, kan het SAN worden ingericht met edge switches waarop de nodes zijn aangesloten en core switches (een centrale switch) waarop de edge switches zijn aangesloten.

Secure Path

Op het moment dat er hardware redundancy wordt gemaakt, betekent het wel dat een node langs meerdere wegen storage ziet. Het pad van HBA (PATH) naar disk kan langs meerdere kanalen lopen. Om problemen te voorkomen, zal er software actief moeten worden die deze zogenaamde multi-path kan regelen en beheren; voor een HP/Novell-cluster is dit Secure Path. Secure Path is multi-path-serversoftware die zorgt voor automatisch herstel van verbindingsfouten tussen servers en opslagsubsystemen. Secure Path maakt het mogelijk om gebruik te maken van redundante fibre channel-paden tussen serversystemen en de RAID-storage-systemen, wat de databeschikbaarheid verhoogt. Indien een component in het pad tussen de server en het storage-subsysteem faalt, dan zorgt Secure Path ervoor dat alle openstaande I/O-ver-

6/4.2-16


Storage

zoeken worden omgeleid van het falende pad naar een alternatief pad. Dit voorkomt dat het falen van een HBA, kabel, switch of controller de datatoegang belemmert. Nadat een pad is hersteld, is Secure Path in staat om een automatische fail-back uit te voeren naar het originele pad. Sommige operating systems beschikken over native support van multi-path; deze platformen vereisen geen additionele software. NetWare 6.5 heeft deze feature, al werkt het niet altijd.

SPM

NetWare hosts worden beheerd via de Secure Path Manager v4 (SPM). Dit is een managementapplicatie voor het monitoren van de multi-path-omgeving, het weergeven van de path-status en waarschuwingen. Secure Path Manager presenteert een SAN-wide overzicht van de verbindingen tussen de managed hosts en de LUN’s. SPM wordt geïnstalleerd op de SWMA. Bij de configuratie van Secure Path worden de volgende instellingen gehanteerd: Instelling

Waarde

Autofailback Load distribution Path verification Polling interval

Enable Disable Enable 300

Middels SPM kan de preferred path per LUN worden ingesteld. Deze dient dusdanig te worden aangepast voor alle LUN’s, dat er geen ISL-verkeer ontstaat. In de inrichting van het SAN worden twee belangrijke zaken geregeld, zoning en disken. Novell Netwerkoplossingen, aanvulling 13

6/4.2-17

SAN’s en clusters

Zoning Ten eerste wordt bepaald welke node welke storage mag zien. Iedereen kan zich wel voorstellen wat er gebeurt als er een node actief is buiten een clusterconfiguratie die wel de storage ziet van een cluster. Vooral het activeren van een Windows-server in een Novell- of UNIX/Linuxomgeving heeft desastreuze gevolgen. Deze techniek wordt ook wel zoning of LUN masking genoemd.

Mogelijkheden

Met behulp van ‘Zones’ kan een FC Fabric worden onderverdeeld in administratieve eenheden. Zoning kan zijn gebaseerd zowel op switch-poortnummers (hardware zoning) als op WWID’s van de aangesloten componenten (software zoning). Door componenten op een FC Fabric in dezelfde zone te plaatsen, wordt het mogelijk om communicatie tussen beide componenten te bewerkstelligen. Zoning biedt de volgende mogelijkheden: • Creëren van fabric-functionele gebieden, zoals het opdelen in productie en onderhoud gebieden; • Versimpelen van resource-gebruik, door logisch groeperen van resources; • Beveiliging, toegang tot resources wordt geregeld op switch-poortniveau. De componenten in verschillende zones kunnen elkaar niet zien; • Scheiden van operating system-typen en applicaties, om de toegang tot resources te controleren. Om de zonering op de switches inzichtelijk te maken, wordt er op de switches een aliastabel gedefinieerd. Aan elke poort wordt een logische naam gekoppeld, die aangeeft welke component is aangesloten. Op deze wijze is niet alleen te zien welke poorten in een zone zijn geconfigureerd, maar tevens welke server en host bus adapter, welke poort van een HSx, MSA1000, enzovoort.

6/4.2-18


Storage

Disken Ten tweede worden uiteraard de disken gedefinieerd, met als belangrijkste parameters de grootte en de RAID-configuratie. Virtual RAID (VRAID)-technologie Bij de traditionele manier van inrichten van storage-omgevingen wordt een specifiek aantal disk-drives aangewezen om een bepaalde mate van redundantie te realiseren. Men stelt hierbij dat een RAID 0+1-set een hoge mate van redundantie kent, maar het dubbele aantal disk-drives behoeft ten opzichte van de benodigde nettocapaciteit en dat een RAID 5-set een lagere mate van redundantie kent, maar slechts één schijf meer vereist dan voor de gewenste capaciteit nodig is (N+1 redundantie). RAID 0 kent geen redundantie maar biedt, in vergelijking met RAID 1 en RAID 5, de hoogste performance. Zie ook de volgende figuur.

De benadering zoals hiervoor geïllustreerd, levert een inefficiënt gebruik van storage op. Beter is het om een ‘pool’ van disk-drives te creëren en daar horizontaal een verdeling in te maken voor de benodigde capaciteit en de gewenste redundantie. Dan ontstaat de volgende situatie:


6/4.2-19

SAN’s en clusters

Drie niveaus

Een Enterpise Virtual Array (HP) maakt gebruik van de VRAID-techniek. Op basis van benodigde capaciteit en de gewenste redundantie bepaalt de controller hoeveel en welke disk-drives benodigd zijn om dit te realiseren. Er bestaat geen direct verband tussen een geconfigureerd volume en de onderliggende schijven. Ten behoeve van redundantie worden drie niveaus onderscheiden: • VRAID0: geen fouttolerantie • VRAID1: alle data is gedupliceerd binnen het storage-systeem. Dit is de hoogste fouttolerantie. • VRAID5: alle data is beschermd d.m.v. parity. Storage-pools Binnen bijvoorbeeld de EVA worden de aanwezige schijven in één of meerdere Disk Groups ondergebracht. Een Disk Group kan worden gezien als een ‘pool’ met schijven (capaciteit) waaruit volumes kunnen worden betrokken. De aangemaakte volumes ofwel Virtual Disks worden verspreid over de binnen de Disk Group aanwezige schijven. Dit betekent bijvoorbeeld dat relatief kleine VRAID5-volumes over meer schijven worden verdeeld dan op de traditionele arrays, met als resultaat een hogere performance. Daarnaast kan men een bestaande storage-‘pool’ on line uitbreiden. Door toevoegen van disk-drives aan de storage-‘pool’ wordt de totale capaciteit van de ‘pool’ groter. In tegenstelling tot de traditionele manier, waarbij de toegevoegde capaciteit alleen beschikbaar komt op de nieuw geplaatste disk-drive, zal bij VRAID de toegevoegde capa-

6/4.2-20


Storage

citeit beschikbaar komen op alle disk-drives in de storage‘pool’ (Storage Pool Load Leveling). Dit geeft wederom een verbetering van de performance. Zie ook de volgende figuur.

Binnen de Enterprise Virtual Array kan men 16 van deze storage-‘pools’ realiseren en derhalve 16 gescheiden omgevingen creëren. Een pool bestaat uit minimaal 8 fysieke disk-drives. LAN De verschillende nodes in een cluster communiceren met elkaar om te kijken of alle servers binnen het cluster nog in de lucht zijn. Er worden twee methodieken gebruikt voor deze communicatie: een quorum device (cluster partition) en een heartbeat-principe over het LAN. Deze communicatie is nodig om te verzekeren dat de resources on line blijven en voor split brain detection. Quorum device

Het quorum device is een stuk shared storage waarop alle servers een eigen deel hebben en waarin periodiek waarden worden gezet. Verandert een van de waarden niet,


6/4.2-21

SAN’s en clusters

dan is de desbetreffende node down. Daarnaast wordt een heartbeat gebruikt over een LAN-aansluiting. Middels heartbeat controleren de nodes elkaar of men nog actief is. Er is dus geen controlemechanisme in het reguliere interserververkeer. De combinatie LAN-heartbeat en quorum device maakt dat er bijvoorbeeld communicatie mogelijk is als de connectie met het LAN of de SAN down is. De communicatie bestaat bijvoorbeeld uit het uitdelen van een poison pill om een server down te laten gaan of het overnemen van de resources.

Redenen

6/4.2-22

De keuze bestaat om de heartbeat over de primaire LANconnectie te laten verlopen of een extra dedicated LAN in te zetten. Dit extra LAN dient dan een andere reeks te krijgen. Er dient goed te worden bekeken of een dedicated LAN benodigd is. De redenen hiervoor zijn: • Als bij de inzet van een dedicated heartbeat-netwerk de primaire NIC defect gaat, wordt dit niet gedetecteerd. Immers, de heartbeat messages worden ontvangen en het updaten van het quorum device blijft ook werken. Novell Cluster Services 1.6 ondersteunt geen multi-heartbeat-network. • Beheer vanuit iManager en ConsoleOne loopt via het heartbeat-netwerk. Dit betekent dat of een van de servers IP forwarding enabled moet hebben (en dus een router) of een externe router moet worden gebruikt om bij dat netwerk te komen. • Het falen van de NIC in het heartbeat-netwerk zal leiden tot het slikken van een poison pill en het down gaan van de node. Dit terwijl de connectie met het werkstation nog steeds Up and Valid is.


Storage

Echter… een heartbeat-principe levert veel verkeer. Als dit wordt opgeteld bij het reguliere verkeer en de som van beide is zo groot dat heartbeat messages te laat aankomen, kan dit leiden tot ‘valse’ poison pills. In dat geval móét een heartbeat-netwerk worden toegepast. Dit betekent echter wel een extra netwerkkaart, aangezien alle servers middels de on board NIC’s dubbel worden ontsloten. Een andere oplossing zou zijn om de netwerkkaarten ook dubbel uit te voeren en LAN-teaming op basis van FT/LB te gebruiken (fault tolerant/load balancing). Indien een cluster al redundant is uitgevoerd, is dit de beste optie, aangezien een netwerkkaart geen grote kosten met zich meebrengt. Het bouwen De opbouw van een SAN gaat in grote lijnen als volgt: Hosts Alle connecties van het SAN worden opgebouwd. Dit lijkt logisch maar het is van groot belang dat gedefinieerd is welke (FC) Host adaptor waar zit. Dit gaat aan de hand van een (uniek) World Wide Number. Deze definities zijn nodig voor de presentaties van de disks aan de nodes.


6/4.2-23

SAN’s en clusters

VDisks Vervolgens dienen de disken te worden gemaakt. Afhankelijk van het systeem (bijv. IBM ESS of de HP MSA1000 of EVA) dienen de disks te worden gegroepeerd en dienen er virtuele disks te worden aangemaakt.

In bovenstaande figuur is exact te zien waar een schijf zich bevindt. Dit is weer nodig voor het aanmaken van de VDisks. Vervolgens dienen de virtuele disks te worden aangemaakt. In ons voorbeeld wordt de fysieke disk aan een Disk Group gekoppeld waaruit de virtuele disks worden gemaakt. De controller bepaalt vervolgens welke stukken storage worden gebruikt. In de Disk Group worden de fysieke schijven ondergebracht zoals hierna is te zien.

6/4.2-24


Storage

En de virtual disk haalt zijn storage weer uit een Disk Group. Hiermee vervalt de directe link tussen Vdisks en raid-set.

Tips

Om efficiënt en flexibel te blijven en om storingen te voorkomen, is het nodig om de relatie Vdisk, Partition, Pool, Volume 1:1:1:1 te houden. Vooral bij de niet-virtual-array-


6/4.2-25

SAN’s en clusters

systemen kan een fout in de virtualisatie desastreuze gevolgen hebben. De node mist dan een stuk informatie of schijf en zal opnieuw gaan initialiseren met alle gevolgen van dien. Het is dus bij het ontwerp van groot belang dat we van tevoren bepalen wat we nodig hebben aan schijven. Het is absoluut niet aan te raden om meerdere partities en pools op een enkele Vdisk te plaatsen. Cluster Services maakt de fail-over op basis van pools, maar de impact van een storing is vele malen groter dan wanneer het op een Vdisk staat. Dit betekent dat er dus ook Vdisken dienen te worden aangemaakt voor het quorum device (SBD-partitie). Maak twee disken aan voor het quorum device en kies bij de installatie van clusterservices voor een gemirrorde SBDpartitie. Ondanks dat een SBD-partitie snel is te reproduceren, zal het cluster niet functioneren zolang deze SBDpartitie er niet is. Bij een mirror set-up kan het maken van de SBD-partitie worden gepland, zodat er overdag geen verstoring in de services optreedt. Bij een EMC, ESS, MSA1000 of een oudere MA8000 bestaan de disken direct uit raid sets van een – deel van een – aantal schijven, zoals in de volgende figuur is te zien.

6/4.2-26


Storage

Het grote nadeel van deze manier van werken is dat als er twee disken defect raken binnen een raid-set van bijvoorbeeld drie schijven, de informatie alsnog verloren kan gaan. Presentatie Als laatste en niet de minst belangrijke dienen de Vdisken te worden gepresenteerd aan de nodes (de virtualisatie). De regel is simpel: alle nodes van een cluster dienen alle storage bij dat cluster te zien. Per default zal een aantal systemen (zoals de MSA 1000) alles naar alles openzetten. Op zich geen probleem, buiten het feit dat er dan niet per ongeluk een Windows en Novell based node tegelijkertijd mogen worden aangesloten. Het is dus raadzaam om de configuratie zelf te maken en vanuit het ontwerp te bepalen welke paden er mogelijk moeten zijn. De instellingen worden gemaakt vanuit de Vdisken zoals in de volgende figuur is te zien:


6/4.2-27

SAN’s en clusters

Om een goede controle uit te voeren en om te bepalen welke node welke storage ziet, kan vanuit een gedefinieerde host worden bekeken welke storage voor hem beschikbaar is. Dit is tevens de lijst die op een Novell-console kan worden verkregen met het commando ‘list devices’.

6/4.2-28


Storage

Bij de ESS, MSA1000 of MA6000/8000 is daarbij tevens te zien onder welke raid-configuratie de disken zijn aangemaakt.

Server OS en clusteringsoftware Als laatste stap dient het operating system van de nodes en de clustering te worden geïnstalleerd en geconfigureerd, waarbij de geclusterde services aan de gebruikers kunnen worden aangemaakt en aangeboden. Een beschrijving van de installatie en de inrichting van Novell en NCS is te vinden in hoofdstuk 3 van dit boek. 6/4.2.4 Conclusie Clustering is cool! Voor de beheerders dan. Clustering is een aanwinst voor de gebruikers, al zullen zij er in de praktijk weinig van merken. Uitvallende services worden immers niet gemist. Clusteringtechnieken gaan echter heel erg ver, en het is van groot belang dat een geclusterde omgeving goed


6/4.2-29

SAN’s en clusters

wordt opgezet, waarbij ‘goed’ betekent: naar de wensen van beheerders én gebruikers.

6/4.2-30


4 SAN, Storage Area Network

Recommend Documents