XOSAN : un SAN virtuel pour XenServer

18
22
sept.
2017
Virtualisation

XOSAN est une solution d’hyperconvergence destinée à XenServer actuellement en cours de développement par Vates, la société éditrice de Xen Orchestra. Il s’agit d’un SAN virtuel pour créer un espace de stockage partagé en utilisant vos différents espaces de stockages existants. C’est une solution orientée 100 % logicielle.

La seconde phase de la bêta est maintenant déployée et accessible à tous les utilisateurs qui veulent y participer.

N. D. M. : XOSAN n’est pas sous licence libre.

Fonctionnement

XOSAN réunit tous les disques locaux existants de votre infrastructure dans un espace de stockage partagé et virtuel, sans aucune limitation. C’est une solution entièrement orientée logicielle qui ne nécessite pas l’achat de matériel additionnel à votre infrastructure déjà existante. Cette solution est capable de fonctionner sur un disque où XenServer est déjà installé.
XoSAN

Objectifs

Les objectifs et bénéfices de la solution sont multiples :

  • protéger vos données grâce à la réplication des données sur des hôtes multiples ;
  • rendre possible la haute disponibilité pour XenServer, sans avoir besoin d’utiliser un NAS ou un SAN ;
  • rendre son infrastructure plus agile en ajoutant de nouveaux nœuds pour agrandir votre espace de stockage ;
  • offrir la possibilité de travailler sur n’importe quel matériel : du disque dur au SSD en configuration RAID ou non.

Phases de bêta pour XOSAN

Phase I

La première phase de la bêta est terminée et a permis la réalisation d’une solution techniquement solide et performante exploitant la technologie GlusterFS.

Phase II

La deuxième phase de la bêta XOSAN est maintenant ouverte. Cette deuxième phase de bêta a pour objectif d’améliorer l’interface utilisateur et d’apporter une solution clé en main et « user friendly ». Son second objectif est de rendre la solution plus flexible en offrant la possibilité d’ajouter ou de supprimer des nœuds ou encore de remplacer un nœud défaillant.

Phase III (finale)

La troisième et dernière phase se concentrera sur le « tiering », c’est‐à‐dire la possibilité d’utiliser un SSD comme système de cache pour les fichiers qui sont beaucoup utilisés dans le but de gagner en vitesse d’exécution.

Rejoindre la beta

Tous les utilisateurs de XenServer désireux de tester la solution peuvent le faire lors de cette seconde phase de bêta. Il suffit de disposer d’une version gratuite de Xen Orchestra et d’une infrastructure XenServer sur laquelle déployer XOSAN. Pour plus d’infos, vous pouvez consulter la documentation.

ATTENTION : Il s’agit d’un logiciel en version bêta, ne l’utilisez pas en production !

  • # Pour quoi faire ?

    Posté par . Évalué à 4 (+3/-0).

    Bonjour,
    merci pour cette dépêche.
    je reste néanmoins dubitatif sur un certain nombre de points qui peuvent se résumer par :
    Pour quoi faire ??

    Je suis convaincu que l'écosystème du libre [1] s'enrichit de l'arrivée de nouveaux venus sur un sujet aussi pointu que l'hyperconvergence [2] et de la multiplicité des technologies a maîtriser.

    Néanmoins, j'ai quelques difficultés à percevoir l'intérêt de la démarche. Je m'explique en prenant l'exemple du stockage :

    La cible du produit XOSAN, semble être l'entreprise de taille suffisante pour se permettre d'envisager ce type de technologie, mais insuffisante pour ne pas disposer de technologies similaires pre-existantes, voire d'un bataillon d'experts du stockage.
    C'est un monde dominé par les grands constructeurs et éditeurs sur le principe du : Ma donnée c'est mon business, mon cash. Trop peu confiance dans le libre pour lui confier le stockage.
    Pour ceux qui auraient pris le pli d'une solution alternative, type stockage distribué, libre qui plus est, ils font, selon les besoins du hadoop,glusterfs,ceph,…

    Maintenant, monter une technologie de stockage semble être une opération semée d'embûches :
    - BtrFS ne sortira probablement jamais en stable
    - Ceph a mis plus de 5 ans pour passer du concept à la V0 et 4 ans de plus pour fournir une interface en mode fichier stable.

    Donc, quand je lis que la phase 1 aboutit à une "solution techniquement solide et performante", j'opte pour une lecture d'un discours marketing.
    Pourquoi la phase 3 permettra-elle alors de disposer d'un cache de SSD pour gagner en performance ?
    En phase 2, on pourra remplacer un noeud défaillant. Ce qui signifie qu'on fait quoi actuellement sur un noeud de stockage défaillant ? Quelles sont les performances du cluster ? Quel est le niveau de redondance ? l'évolution des IOPS ?

    Comment marche la réplication ?
    La page replicated l'indique. On se retrouve avec un RAID 1 en réseau qui ne semble pas permettre d'évolution vers un autre mode.

    En mode Disperse, un Raid5 en, réseau, je n'ai rien trouvé (peut-être mal cherché) sur la manière dont se répliquaient les données.

    De même, comment se prémunir des secteurs défectueux (raid5 write-hole). ? Un mécanisme de scrubbing existe-il ? Du copy-on write ? du checksumming ?

    Sur l'infrastructure, le même réseau semble utilisé pour la réplication comme pour la distribution des données aux VM. Ne jouez pas à ca sur des clusters Ceph, par exemple, c'est assez nuisible aux performances..

    Après je peux comprendre que chercher à compenser une offre fonctionnelle [3] étoffée comme celle d'un Proxmox force Xenserver a défricher ce terrain.

    Maintenant, si je devais rapidement monter une offre convergée avec une adhérence à Xenserver je monterais un cluster Ceph qui scale linérairement avec le nombre de noeuds.

    Encore une fois, je suis favorable à l'effervescence du libre (même quand ça n'en est pas et même quand c'est cher…. )

    [1] : Bon, le produit n'est pas libre, mais ça ne me semble pas incompatible avec une brève sur Linuxfr.
    [2] : Warning, buzzword inside
    [3] : Je ne juge pas les mérites techniques respectifs.

    • [^] # Re: Pour quoi faire ?

      Posté par . Évalué à 4 (+3/-0).

      Hello !

      1. C'est du Gluster en dessous, donc mature et pas de roue réinventée. Par contre, ça permet de déployer du Gluster sur des XenServer en quelques clics, sans avoir à gérer la complexité.
      2. Comme c'est du Gluster, ça permet de faire plein de choses. Et en plus de ça, les perfs sont pas mal du tout.
      3. On est quasi en phase III de la beta : on peut déjà remplacer des « nœuds » à chaud.
      4. La documentation sur XOSAN est ici : https://xen-orchestra.com/docs/xosan.html On y explique les possibilités d'agrandissement.
      5. N'oubliez pas qu'on parle d'hyperconvergence (data+compute sur le même nœud physique), pas juste de storage d'un côté avec son hardware qu'on peut connecter sur un hyperviseur de l'autre.

      Et bon courage pour monter un cluster Ceph avec du XenServer, sans y passer un bon nombre d'heures (ou d'avoir l'expertise, ce qui coûte aussi) ;)

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.