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.
# Pour quoi faire ?
Posté par Phil_S . En réponse à la dépêche XOSAN : un SAN virtuel pour XenServer. Évalué à 4.
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.