Webservers, databases, (exotische) besturingssystemen tot hypervisors aan toe, alle zijn ze reeds succesvol gevirtualiseerd. Wat blijft nog over? Het antwoord: softwarematige storage area networks (SAN).       Inderdaad, we spreken over een nieuw idee, het idee om een volledige high-available, high-performante virtuele infrastructuur met alle virtuele voordelen op te zetten met slechts twee fysieke […]

Advertentie

Webservers, databases, (exotische) besturingssystemen tot hypervisors aan toe, alle zijn ze reeds succesvol gevirtualiseerd. Wat blijft nog over? Het antwoord: softwarematige storage area networks (SAN).

 

 

 

Inderdaad, we spreken over een nieuw idee, het idee om een volledige high-available, high-performante virtuele infrastructuur met alle virtuele voordelen op te zetten met slechts twee fysieke servers zonder de (zware) extra kosten van een SAN-server.

 

 

De meest simpele HA KMO-omgeving bestaat uit twee servers met een SAN, al dan niet via IP geconnecteerd (iSCSI/NFS). Meestal is een SAN even duur als de overige twee servers samen, dus het zou een behoorlijke besparing zijn indien we deze volledig zouden kunnen weglaten.

Dankzij een combinatie van technologieën kan dit nu en wel met behulp van zogenaamde virtual storage appliances. In de volgende reeks artikels brengen we u de voor- én nadelen van deze techniek en duiden we aan waar u op moet letten. Verder deden we ook performantie-testing en geven we u een overzicht van de spelers op deze toch al uitgebreide markt.

In de praktijk nemen we twee servers die dubbelen als virtualisatieservers én als SAN. Door beide van veel opslagruimte te voorzien en onderling te laten repliceren kunnen we, zonder downtime, een hardwarefailure overleven.

We maken op een virtualisatieserver een kleine RAID1-set voor hypervisor en één kleine virtuele machine (VM), alle overige schijven steken we in één grote RAID-set en geven we volledig aan die ene lokale virtuele machine. De software in deze VM (de Virtual Storage Appliance) zal de RAID-set aan het LAN aanbieden als SAN. Er zijn nu al tien vendors die software verkopen om binnen die VM te draaien. Sommige zijn purposely-built OS’en, andere zijn plug-ins voor Windows/Linux.

Als we ditzelfde nu ook opzetten op de andere virtualisatieserver, dan kan die kleine VM een blocklevel-replicatie doen. Als er dan een faling is zal de andere VM automatisch de SAN-taken overnemen.

De VSA-software moet dus twee dingen goed aansturen

  • Automatische replicatie zodat de data permanent up-to-date zijn op beide nodes
  • Automatische failover (via een heartbeat), liefst zonder downtime van de VM’s

Concreet zullen de meeste appliances dan werken met een virtueel (gedeeld) IP-adres dat dynamisch aan de ene of de andere SAN-appliance hangt. Alle ‘clients’ (voornamelijk hypervisors, maar andere VM’s zijn uiteraard ook mogelijk) maken dan verbinding via dit IP-adres.

De hypervisor zelf weet niet dat de voorgestelde LUN’s lokaal staan, voor hem lijkt het een gewone SAN en is er geen verschil. Verdere high-availability wordt dan bewerkstelligd door redundante switches en bekabeling tussen de twee servers onderling, de HA-features van de hypervisorcluster blijven uiteraard ook volledig werken. Zelfs live migration is technisch geen enkel probleem.

Een grote speler die verrassend genoeg snel op dit idee sprong is HP met zijn LeftHand StorageWorks P4000 Virtual SAN Appliance.

De appliance is als trial van de website van HP te downloaden en bestaat voor VMware ESX & Hyper-V. Details volgen in een volgend artikel, maar als HP zich op deze markt mengt, moet het zeker een valabele optie zijn.

In een volgend artikel overlopen we één voor één een aantal bekende appliances als Open-E DSS, DataCore SanMelody, HP VSA en OpenFiler.


Geen velden gevonden.