Virtual Storage Appliances: deel III

Virtual Storage Appliances beloven een high available cloud storage zonder de nood van het aankopen van een SAN. En ze kunnen die belofte voor het grootste deel ook waarmaken. Toch zijn er een aantal zaken waar zeker rekening mee gehouden moet worden, niet in het minst naar performantie toe. Ten eerste zijn er natuurlijk de performance-considerations voor iedere tool apart, zoals een dedicated gigabitnetwerklijn voor de synchronisatie. Of het aantal cores of geheugen dat aan de VSA-VM moet toegewezen worden. Toch zijn er ook een aantal algemene bedenkingen die bij elke oplossing van toepassing zijn.

Opstartvolgorde
Als alles van nul opstart dan is er het probleem dat de VSA VM pas opstart als de hypervisor geladen is en dat deze hypervisor dus de overige VM’s niet ziet. Dit gooit het hele autobootproces in de war, waardoor de VM’s (bijvoorbeeld na een stroomuitval) gewoon niet starten totdat de hypervisor zijn HBA’s herscant.

Dit probleem is ook al herkend door HP. Bijvoorbeeld voor ESX zijn er dan speciale scripts die na een gegeven time-out het herscan- en autobootproces hernemen.

Raw Device Mapping
De stack van filesystemen die een guest-OS moet doorlopen om aan zijn data te kunnen, kan behoorlijk groot zijn. Als we eerst een ESX-VM installeren en de grote raidset aan de VSA-VM hangen, kunnen we deze als VMFS formatteren. Meestal zal VSA dan zelf ook een filesysteem installeren (in het beste geval LVM, maar soms ook NTFS).

Deze zal dan dit systeem opnieuw aan de hypervisor aanbieden als iSCSI-target en ESX kan dit dan ook opnieuw formatteren als VMFS. Als een gast-OS dan op dit VMFS-volume wordt geïnstalleerd, dan zal het opnieuw zijn eigen filesysteem gebruiken. Dit betekent in het slechtste geval een passage van vier verschillende bestandssystemen voor de data van uw applicatie worden opgehaald.

Veel van die dingen kunnen voorkomen worden door RDM te gebruiken, maar het is ook zo dat VMFS geoptimaliseerd is voor random access-scenario’s. Werkt dit echter nog als we twee VMFS-systemen in elkaar hebben?

Lokale VM of niet
Een andere parameter die in het spel komt bij gebruik van VSA is de switches die gebruikt worden voordat een ESX en zijn VM’s aan de storage kunnen.

Als we twee VSA-appliances hebben die in een actief-passief-status staan op twee verschillende ESX-systemen, dan betekent dit dus dat alle VM’s die op de ESX staan met de actieve VSA kunnen gebruikmaken van de interne vSwitch van ESX. Terwijl de VM’s die op de ESX-host staan met de passieve ESX telkens voorbij een externe (gigabit-)switch gaan. Het is algemeen bekend dat de interne vSwitch van een hypervisor stukken performanter is dan een externe switch. Een simpele VMotion van een VM kan dan een impact hebben in performantie, doordat de data over fysieke of virtuele netwerk-switchen gaan. Ook dit hebben we even uitgemeten en wel met tweemaal RDM.

Vooral sequentieel is er een behoorlijk verschil. Het is dus aan te bevelen om VM’s die zwaar naar de schijven gaan (bijvoorbeeld fileservers of webservers voor streaming) op de ESX-host te plaatsen met de actieve VSA-appliance. Dankzij vMotion/Live Migration is dit een kwestie van enkele muisklikken.