VMware vSphere Storage Appliance (VSA)

Dans la nouvelle version de son infrastructure virtuelle, vSphere 5, VMware lance un nouveau produit, apparemment intéressant pour les PME, la vSphere Storage Appliance. 

Le concept est simple, VSA permet d’utiliser le stockage local des ESX (les disques locaux des serveurs) comme Datastores NFS, permettant de stocker sans risque des VMs en production. Autrement dit, VSA permet aux petites structures de se passer de SAN ou de NAS, en utilisant les disques locaux des ESX. Ceci sans danger, car VSA réplique les données des ESX entre eux, pour assurer la continuité du service en cas de perte d’un ESX. On parle donc bien de stockage redondant, hautement disponible.

Tout d’abord, comment cela fonctionne?

–       une Virtual Appliance VSA est installée sur chaque ESX participant au cluster VSA (2 ou 3, pas plus) la Virtual Appliance va utiliser l’espace de stockage restant des disques locaux des serveurs ESX.

–       L’espace de stockage sera divisé en deux sur chaque ESX, une partie data et une partie réplica. Chaque Virtual Appliance va utiliser l’espace réplica de l’autre serveur ou d’un des deux autres (si 3 nœuds) pour répliquer son volume data.

–       Le VSA manager, module additionnel du vCenter, permet de manager, monitorer et configurer le cluster VSA.

–       Les Datastores ainsi créés par le cluster VSA sont présentés par le réseau aux ESX du même Datacenter, et montés sous forme de shares NFS.

–       En cas de panne d’un ESX, les données sont toujours disponibles car le membre du cluster VSA hébergeant le réplica du serveur tombé en panne va le rendre actif.

–       Les appliances VSA utilisent deux réseaux, le Front-end Network, pour l’accès aux Datastores et la communication avec le VSA manager ; et le Back-end Network pour la réplication des données et les communications du cluster.

 

Soyons positifs, commençons par les avantages :

–       On utilise des serveurs physiques, et leurs disques locaux, donc plus besoin de SAN ou NAS.

–       Les performances dépendent directement de votre matériel (et de votre budget) et peuvent être tout à fait concurrentielles avec du SAN FC (par exemple avec du 10Gbit Ethernet pour la réplication; malheureusement, pour l’instant le SSD n’est pas supporté).

–       HA, vMotion, (donc logiquement DRS) fonctionnent (les shares NFS fournis par le cluster VSA sont bien sur considérés comme shared storage).

–       Le coût. Plus besoin de SAN ou NAS, juste de disques locaux (beaucoup et performants).

 

Les inconvénients :

Commençons par les ESX :

–       Raid 10 obligatoire, 4, 6 ou 8 disques SATA ou SAS (pas de mélange de taille ou de types)

–       24 GB de RAM recommandés (6 minimum 72 maximum) juste pour VSA, sans compter les VMs qui tourneront sur ces ESX.

–       9 adresses IP statiques pour un cluster à 2 nœuds, 11 pour un cluster à 3 nœuds.

 

Au niveau du vCenter :

–       un vCenter ne peut manager qu’un cluster VSA (donc maximum 3 membres VSA par vCenter)

–       Le vCenter, si il est virtuel, ne doit pas tourner sur un des ESX du cluster VSA, donc physique ou VM sur un autre ESX hors cluster VSA.

–       pas d’upgrade (pour l’instant) dans un cluster VSA

–       pas de reconfiguration possible sans tout reformater. Si l’on a besoin de plus de place, on ajoute des disques partout et on reformate le tout !

 

VSA, bien que très prometteur, est pour l’instant relativement dur à mettre en œuvre dans une infrastructure existante. Les ESX que l’on va utiliser pour VSA ne doivent pas être membres d’un autre cluster, ne pas faire tourner de VMs, pas avoir de configuration réseau. Bref, autant dire qu’ils doivent être tout frais installés. Paradoxalement, c’est pour les très petites structures que la difficulté va augmenter, car si tous les ESX (2 ou 3) sont membre du cluster VSA, et qu’il n’y a aucun autre ESX ou espace de stockage pour recueillir les VMs dans une phase de transition, toute la production devra être arrêtée, voir les VMs devront être copiées à la main, en cas de changement dans la configuration. Mais pour une nouvelle arrivée dans le monde de la Virtualisation, les avantages et la facilité d’implémentation devraient convaincre facilement.

 

Reste à parler des licences, le prix est de 6500.- CHF sans licence vCenter et sans licence support et… sans les licences ESX (qui doivent être Essential Plus au minimum).

 

Conclusion :

L’idée est séduisante car bien souvent le SAN fait peur aux PME. Les performances et le coût semblent tenir leurs promesses, et le fait d’avoir la main sur toute son infrastructure depuis le vCenter va plaire. Pour les gros besoins d’espace de stockage, cette solution risque d’atteindre rapidement ses limites, selon la formule :

Q = (q * N/2) * (Y /2)

Où :

Q = la capacité de stockage total du cluster VSA

q = la capacité d’un disque

N = le nombre de disque dans un serveur (sans compter le spare)

Y = le nombre de serveur dans le cluster VSA

(sans tenir compte des quelques GB nécessaire à l’installation d’ESX)

Si nous prenons un exemple avec 8 disques de 1TB dans chaque serveur, cela fait 1TB multiplié par 8 / 2 (8 disques en raid 10, reste 4 disques utiles) multiplié par 3 ESX, divisé par 2 car la moitié de chaque volume est utilisée comme réplica. Soit au total 6 TB utiles sur 24 TB bruts. Ce qui est assez peu, mais la sécurité coûte cher.

 

Les problèmes que je vois actuellement sont surtout des problèmes de jeunesse. Le plus gros étant le manque de souplesse et d’évolutivité. Impossible de reconfigurer son VSA sans formater l’ensemble. Donc on n’ajoute pas de place, on n’ajoute pas un 3ème membre, on n’upgrade pas son VSA en version 1.1, etc. Ces limitations vont être améliorées certainement dans une prochaine version mais pour l’instant, sachant que la solution s’adresse aux PME qui n’ont pas de SAN ou NAS et donc pas d’alternative de stockage, que faire de toutes mes VMs pendant que je reformate mon VSA ? Réponse à suivre.

 

Merci de votre lecture, et n’hésitez pas à commenter.

 

Stéphane

 

Sources :

–       vSphere Storage Appliance Installation and Configuration http://pubs.vmware.com/vsphere-50/topic/com.vmware.ICbase/PDF/vsphere-storage-appliance-10-install-config.pdf

–       Cours vSphere Install Configure and Manage

A propos de 

http://ch.linkedin.com/in/sgrimbuhler

Stéphane GRIMBUHLER 

Virtualization & Storage Architect (VCP / VCAP-DCA)
VMware Instructor (VCI)
vExpert 2012 to 2014

twitter : @sgrimbuhler
sgrimbuhler@virtualgeek.ch

  1. Bonjour

    Voici différents scénarios issus des blogs VMware, pour décrire le comportement de VSA en cas de panne.

    Scénario 1, Panne du réseau back-end

    Scénario 2, panne du réseau front-end

    Scénario 3, Perte d’un host

    Bonne lecture.

  2. Bonjour

    Je viens d’apporter quelques modifications à mon article, suite à des précisions apportées par VMware lors du VMworld :

    – les disques SSD ne sont pas supportés dans les ESX VSA
    – Raid 10 obligatoire dans les ESX VSA, avec 4, 6 ou 8 disque

    Produit à suivre de près.
    Bien à vous,
    Stéphane

  3. Bonjour,
    Merci pour ce retour d’expérience.
    Je surveille cette technologie mais je me pose des questions d’architectures et de performances: sur ce produit vmware VSA, est-ce lque ‘espace de fichier partagé peut servir comme stockage de VM et si oui, est-ce que le fait de créer un espace de fichier issu d’un espace de stockage de machines virtuelles est performant ?
    Sinon, Avez vous des retours sur les autres produits commerciaux VSA (falccon store VSA, stormagic svsan, nexenta nexentaStor, HP LeftHand P4000 Virtual SAN Appliance Software) et des produist opensource comme glusterfs 3.2 ou autre.

    salutations

    • Stéphane Grimbuhler

      Bonjour Hervé

      Les virtual appliances VSA vont utiliser le stockage local des ESX et les présenter comme shares NFS. La moitié du volume local de l’ESX sera utilisé comme volume Data (un share NFS) et l’autre moitié comme replica d’un volume Data d’un autre ESX VSA. Donc si j’ai deux ESX dans mon cluster VSA, j’aurai 2 shares NFS.

      Après, il s’agit juste de share NFS, en théorie, je pourrais les utiliser de n’importe quelle façon, mais bien sur, dans le cas présent, la meilleure façon est de présenter ces share à tous les ESX comme stockage partagé, afin d’y stocker des machines virtuelles.

      En ce qui concerne les performances, la réponse la plus adaptée est aussi la plus agaçante : cela dépend.
      – Toutes les I/O d’une appliance VSA passent par le réseau interne d’un ESX (une VSA va faire les IOs dans le volume local de l’ESX sur lequel elle se trouve) et donc pas de problème à ce niveaux, puisqu’en théorie, un paquet qui ne sort pas de l’ESX (réseau interne) peut transiter à une vitesse pouvant aller jusqu’a 27Gbps.
      – Le serveur ESX fera les IOs par son contrôleur SCSI interne, et écrira sur ses disques internes. Donc cela dépendra du matériel (type de disque, nombre d’axes, limite d’IOPS du contrôleur, cache du contrôleur). Mais là encore, pas trop de craintes de performances, bien que cela dépende aussi du nombre de VM écrivant sur le share NFS, les contrôleurs internes ne sont pas beaucoup plus lent que du SAN.
      – La réplication. Chaque VSA va faire ses IOs en local sur l’ESX, mais également envoyer une copie des écritures à l’autre VSA pour être faite sur la réplique du volume. L’acknowledgment de l’opération ne se fait qu’après que les DEUX écritures aillent été faites. Et donc là, de la latence est possible, puisque les paquets sortent sur le réseaux Ethernet externe (possibilité de mettre du 10Gb Ethernet pour garantir les performances).
      – VSA va consommer passablement de ressources des ESXs (mémoire et CPU) et donc en cas de contention, par exemple plus assez de CPU, les performances du stockage VSA vont baisser.

      Malheureusement, pas encore de retour d’expérience, car le produit est tout neuf, et n’a pas encore pris dans nos contrées.

      J’ai eu l’occasion de voir en détail le design de la VSA HP (p4000), qui semble très intéressante. Ce qu’il apporte en plus de la VSA VMware, c’est déjà bcp de souplesse en cas d’ajout de disques ; possibilité de mirrorer ou non entre les VSA (obligatoire avec VSA VMware) ; le SSD est supporté ; on peut mixer les types de disque dans l’ESX ; on peut présenter des shares NFS ou des volumes iSCSI ; il y a une couche d’abstraction entre les volumes physiques et les volumes présentés (un peu comme de la virtualisation de stockage FalconStor ou Datacore) c’est à dire que l’on peut présenter aux VSA un gros raid group de 2T et VSA va “tailler” dedans des volumes de 500GB (par ex.) à présenter aux ESX.

      Voilà, j’espère avoir répondu.
      Très bonne journée.

      Stéphane Grimbuhler.

  4. Merci pour cet article. En complément: article sysKB

    • Stéphane Grimbuhler

      Bonjour Hatmos

      Mon article ne parle pas de vCenter Server Appliance, mais de vSphere Storage Appliance. Quoi qu’il en soit merci pour le lien et pour l’article intéressant.

      Je me permettrais juste d’ajouter une petite note personnelle:
      – en base de donnée externe, Oracle ET DB2 sont supportés.
      – autre limitation, IPv6 n’est pas supporté.
      – vSphere 5 Web Client n’est pas supporté non plus, il requiert un serveur Windows à part.

      Cela reste une très bonne alternative pour des petits déploiement, mais pour moi le plus inquiétant est l’absence de l’Update Manager. Il est important de pouvoir patcher ses ESXi aussi souvent que possible.

      Merci de votre participaiton.
      Stéphane.

  5. Bonjour

    Suite à des modifications annoncées par VMware, je vous renvoi sur l’article de Cédric Mégroz qui complète celui-ci : http://www.virtualgeek.ch/blog/2012/01/26/vsphere-storage-appliance-raid-5-et-6-autorises/

    Bonne lecture.
    Stéphane.

Laisser un commentaire


NOTE - Vous pouvez utiliser les éléments et attributs HTML tags and attributes:
<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>