Bonjour la liste,
J'ai une question théorique concernant le stockage
Y a-t-il une réelle différence de performance entre le NFS et l'ISCSI ? Certaines situations nécessitent elle l'utilisation de l'une ou l'autre techno ?
Merci de votre aide
*Fabien*
Bof, ils ne comblent pas le même besoin (tu peux faire plus de chose avec iSCSI qu'avec NFS)
Comment est-ce que tu souhaites t'en servir ?
On 24/06/2017 17:57, Fabien wrote:
Bonjour la liste,
J'ai une question théorique concernant le stockage
Y a-t-il une réelle différence de performance entre le NFS et l'ISCSI ? Certaines situations nécessitent elle l'utilisation de l'une ou l'autre techno ?
Merci de votre aide
*Fabien*
Liste de diffusion du FRsAG http://www.frsag.org/
Je monte un lab Proxmox
Je me pose donc la question de savoir quelle techno utiliser pour le stockage de VM/Conteneur
Merci
*Fabien
* Le 24/06/2017 à 18:47, Olivier Le Cam a écrit :
Le 24/06/2017 à 18:03, frsag@jack.fr.eu.org a écrit :
Bof, ils ne comblent pas le même besoin (tu peux faire plus de chose avec iSCSI qu'avec NFS)
(oui mais il y a des choses que tu peux faire en NFS qui ne sont pas possible en iSCSI)
:P
Bah au feeling, je pense que iSCSI est plus adapté (et donc plus performant)
Mais ce peut être plus compliqué au niveau opérationnel
NFS est régulièrement utilisé pour ce genre de projet, j'imagine que cela fonctionne convenablement (j'ai de très mauvaises expériences avec NFS ..)
Sinon, est-ce que tu as regardé rbd ? Ce peut être adapté à ton infra (et rbd, cephabuleux :D)
On 24/06/2017 18:47, Olivier Le Cam wrote:
(oui mais il y a des choses que tu peux faire en NFS qui ne sont pas possible en iSCSI)
Vraiment ? Avec un FS distribué construit sur le dev block exporté par iSCSI, tu peux faire tout ce que fait NFS, non ?
On 24/06/2017 19:04, Fabien wrote:
Je monte un lab Proxmox
Je me pose donc la question de savoir quelle techno utiliser pour le stockage de VM/Conteneur
Merci
*Fabien
Le 24/06/2017 à 18:47, Olivier Le Cam a écrit :
Le 24/06/2017 à 18:03, frsag@jack.fr.eu.org a écrit :
Bof, ils ne comblent pas le même besoin (tu peux faire plus de chose avec iSCSI qu'avec NFS)
(oui mais il y a des choses que tu peux faire en NFS qui ne sont pas possible en iSCSI)
:P
Liste de diffusion du FRsAG http://www.frsag.org/
On sam. 24 juin 19:12:32 2017, frsag@jack.fr.eu.org wrote:
On 24/06/2017 18:47, Olivier Le Cam wrote:
(oui mais il y a des choses que tu peux faire en NFS qui ne sont pas possible en iSCSI)
Vraiment ? Avec un FS distribué construit sur le dev block exporté par iSCSI, tu peux faire tout ce que fait NFS, non ?
iSCSI t’expose un blockdevice, donc il faut ajouter un FS dessus pour l’utiliser. Depuis une VM où le but c’est juste de pousser un backup ailleurs, ça peut être bien d’écrire directement sur un NFS.
Sur une VM où c’est le /, j’aurais plutôt tendance à partir sur de l’iSCSI par contre, mais ça reste du feeling :p
Actuellement on fait du ZFS directement sur la machine, donc sans réseau nul part pour le stockage.
Il est quand même important de bien faire le distinguo entre une techno d'exposition de block device (SAN donc, ou pourrait citer FC, FCoe, iscsi, atoe, etc...) et une techno de FS réseau sans block device partagé (NFS, Smb ?).
Vraiment ? Avec un FS distribué construit sur le dev block exporté par iSCSI, tu peux faire tout ce que fait NFS, non ?
C'est franchement différent. Tu penses j'image à OCFS2, GFS2 ? Le problème de ces FS c'est la gestion du lock (NFS s'en sort mieux à ce niveau même si ça reste un gros soucis). Je ne les conseillerais vraiment pas.
iSCSI t’expose un blockdevice, donc il faut ajouter un FS dessus pour l’utiliser. Depuis une VM où le but c’est juste de pousser un backup ailleurs, ça peut être bien d’écrire directement sur un NFS.
Sur une VM où c’est le /, j’aurais plutôt tendance à partir sur de l’iSCSI par contre, mais ça reste du feeling :p
Pour le stockage de VMs cela parait intuitivement plus logique d'utiliser du block. Le problème c'est que par définition tu vas avoir beaucoup de vm(s) et donc potentiellement autant de target que de vm(s). Ça se fait c'est du SAN à l'ancienne on va dire.
On utilise en général une approche différente, on utilise un ou plusieurs gros block device avec un FS distribué ou chaque vm(s) est stocké dans des fichiers (qui sont des images disques). Par exemple VMFS over FC, over iscsi ; ou directement NFS pour vmware. Sous XEN je connais des gens qui ont la même approche, export d'un gros share NFS ou on stocke des images disques des vm(s).
Ça se passe globalement bien, car en général une vm n’accède qu'une seule ou fois à son fichier d'image disque, du coup pas de problème d'accès concurrent au fichiers, lock unique au démarage de la vm.
Et après il faut bien regarder l'implémentation coté server aussi. Exemple assez connu, Netapp a avant tout été construit pour faire du NFS/Smb avec un FS interne (WAFL) prévu pour. L'implémentation d'isci au début était moche (un fichier image over WAFL). Du coup NFS était beaucoup plus performant sur Netapp qu'iscsi.
En tout cas malgré tout le mal que je pense de NFS c'est certainement plus simple et adapté pour du stockage de VMs.
L'immense problème de NFS (mais iscsi aussi) c'est la redondance et le scaling (vertical only).
Alors on peut être tenté d'utiliser un vrai block device partagé (Ceph avec RDB). On règle les deux problèmes au prix d'une certaine complexité.
Pour du container alors la par contre je dirais ni l'un ni l'autre ; un container ne devrait pas avoir besoin de stockage persistent, ou alors du stockage objet (S3 like).
-- Raphael Mazelier
Le 24/06/2017 à 20:26, Raphael Mazelier a écrit :
Pour le stockage de VMs cela parait intuitivement plus logique d'utiliser du block. Le problème c'est que par définition tu vas avoir beaucoup de vm(s) et donc potentiellement autant de target que de vm(s). Ça se fait c'est du SAN à l'ancienne on va dire.
Tu peux très bien faire un thin volume LVM sur ta cible iSCSI et stocker les disques de tes VM dans ce volume.
C’est ce que fais Proxmox sur le disque local pour les nouvelles installations (il n’y a plus de point de montage pour /var/lib/vz).
Pour du container alors la par contre je dirais ni l'un ni l'autre ; un container ne devrait pas avoir besoin de stockage persistent, ou alors du stockage objet (S3 like).
:s,container,container\ Docker,
Sans animosité aucune mais les “containers” existent depuis bien avant l’usage spécifique "Dockeresque"d’aujourd’hui, et ceux-ci méritaient en général tout autant un stockage persistant, du coup.
Et sinon pour le “ou alors du stockage objet”, ca reste une couche de présentation : si c’est que ca qui chiffonne et qu’on à de vieilles habitudes : s3fs, riofs, ou meme goofys – pour l’empreinte plus "container-rationel” même s’il est lent, pour ne citer qu’eux.
P’tet meme qu’on peut stocker des images disques pour [insérez une techno de virtu ici] et monter du S3 sur l’hyperviseur. Juste pour rire.
--Colin
Petite précision pour le cas proxmox.
SI on fait du iSCSI, le disque présenté aux serveurs proxmox devra être en LVM. Et il y aura un LV par VM.
Ce qui est naze, c'est qu'en faisant cela, on a pas de snapshot de VM niveau proxmox. On pourrait utiliser le LVM Thin, qui autorise les snapshot de VM,
sauf que le disque lv thin est considéré comme local (normal dans la logique lvm, un volume thin provisionning est un LV (qui en contient d'autre), donc actif à un instant T sur une seule ressource ...)
Donc dans ce cas, impossible de migrer la VM sur un autre host.
Donc si tu n'as pas besoin de snapshot de VM, part sur iscsi / LVM, sinon, un nfs avec des disques qcow2 par VM, c'est très bien. Après; le iscsi, ca peut être galère au début, y'a plein de pièges dans le quel il ne faut pas tomber, mais ca c'est un autre débat :-D
Reno.
Le 24/06/2017 à 21:01, Colin J. Brigato a écrit :
Pour du container alors la par contre je dirais ni l'un ni l'autre ; un container ne devrait pas avoir besoin de stockage persistent, ou alors du stockage objet (S3 like).
:s,container,container\ Docker,
Sans animosité aucune mais les “containers” existent depuis bien avant l’usage spécifique "Dockeresque"d’aujourd’hui, et ceux-ci méritaient en général tout autant un stockage persistant, du coup.
Et sinon pour le “ou alors du stockage objet”, ca reste une couche de présentation : si c’est que ca qui chiffonne et qu’on à de vieilles habitudes : s3fs, riofs, ou meme goofys – pour l’empreinte plus "container-rationel” même s’il est lent, pour ne citer qu’eux.
P’tet meme qu’on peut stocker des images disques pour [insérez une techno de virtu ici] et monter du S3 sur l’hyperviseur. Juste pour rire.
--Colin
Liste de diffusion du FRsAG http://www.frsag.org/
Pourquoi qcow2 ? raw est généralement plus performant non ?
Guillaume Hilt
Le 25/06/2017 à 12:34, Renaud Galante a écrit :
Petite précision pour le cas proxmox.
SI on fait du iSCSI, le disque présenté aux serveurs proxmox devra être en LVM. Et il y aura un LV par VM.
Ce qui est naze, c'est qu'en faisant cela, on a pas de snapshot de VM niveau proxmox. On pourrait utiliser le LVM Thin, qui autorise les snapshot de VM,
sauf que le disque lv thin est considéré comme local (normal dans la logique lvm, un volume thin provisionning est un LV (qui en contient d'autre), donc actif à un instant T sur une seule ressource ...)
Donc dans ce cas, impossible de migrer la VM sur un autre host.
Donc si tu n'as pas besoin de snapshot de VM, part sur iscsi / LVM, sinon, un nfs avec des disques qcow2 par VM, c'est très bien. Après; le iscsi, ca peut être galère au début, y'a plein de pièges dans le quel il ne faut pas tomber, mais ca c'est un autre débat :-D
Reno. Le 24/06/2017 à 21:01, Colin J. Brigato a écrit :
Pour du container alors la par contre je dirais ni l'un ni l'autre ; un container ne devrait pas avoir besoin de stockage persistent, ou alors du stockage objet (S3 like).
:s,container,container\ Docker,
Sans animosité aucune mais les “containers” existent depuis bien avant l’usage spécifique "Dockeresque"d’aujourd’hui, et ceux-ci méritaient en général tout autant un stockage persistant, du coup.
Et sinon pour le “ou alors du stockage objet”, ca reste une couche de présentation : si c’est que ca qui chiffonne et qu’on à de vieilles habitudes : s3fs, riofs, ou meme goofys – pour l’empreinte plus "container-rationel” même s’il est lent, pour ne citer qu’eux.
P’tet meme qu’on peut stocker des images disques pour [insérez une techno de virtu ici] et monter du S3 sur l’hyperviseur. Juste pour rire.
--Colin
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Au pif, je dis Thin-Provisionning !
+
__
[image: NFrance Conseil] http://www.nfrance.com/
*Jean-Baptiste COUPIAC* Tél. : +33 5 34 45 55 00 <%20+33534455500> 4 rue Kennedy 31000 Toulouse - France | www.nfrance.com
Le 26 juin 2017 à 11:15, Guillaume Hilt frsag@shadowprojects.org a écrit :
Pourquoi qcow2 ? raw est généralement plus performant non ?
Guillaume Hilt
Le 25/06/2017 à 12:34, Renaud Galante a écrit :
Petite précision pour le cas proxmox.
SI on fait du iSCSI, le disque présenté aux serveurs proxmox devra être en LVM. Et il y aura un LV par VM.
Ce qui est naze, c'est qu'en faisant cela, on a pas de snapshot de VM niveau proxmox. On pourrait utiliser le LVM Thin, qui autorise les snapshot de VM,
sauf que le disque lv thin est considéré comme local (normal dans la logique lvm, un volume thin provisionning est un LV (qui en contient d'autre), donc actif à un instant T sur une seule ressource ...)
Donc dans ce cas, impossible de migrer la VM sur un autre host.
Donc si tu n'as pas besoin de snapshot de VM, part sur iscsi / LVM, sinon, un nfs avec des disques qcow2 par VM, c'est très bien. Après; le iscsi, ca peut être galère au début, y'a plein de pièges dans le quel il ne faut pas tomber, mais ca c'est un autre débat :-D
Reno.
Le 24/06/2017 à 21:01, Colin J. Brigato a écrit :
Pour du container alors la par contre je dirais ni l'un ni l'autre ; un container ne devrait pas avoir besoin de stockage persistent, ou alors du stockage objet (S3 like).
:s,container,container\ Docker,
Sans animosité aucune mais les “containers” existent depuis bien avant l’usage spécifique "Dockeresque"d’aujourd’hui, et ceux-ci méritaient en général tout autant un stockage persistant, du coup.
Et sinon pour le “ou alors du stockage objet”, ca reste une couche de présentation : si c’est que ca qui chiffonne et qu’on à de vieilles habitudes : s3fs, riofs, ou meme goofys – pour l’empreinte plus "container-rationel” même s’il est lent, pour ne citer qu’eux.
P’tet meme qu’on peut stocker des images disques pour [insérez une techno de virtu ici] et monter du S3 sur l’hyperviseur. Juste pour rire.
--Colin
Liste de diffusion du FRsAGhttp://www.frsag.org/
Liste de diffusion du FRsAGhttp://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
On Mon, Jun 26, 2017 at 11:15:14AM +0200, Guillaume Hilt wrote:
Pourquoi qcow2 ? raw est généralement plus performant non ?
J'ai du mal à voir la différence en perf perso, et le qcow2 est quand même bien pratique (copy, snapshot, thin provisionning ..) En général ça vaut le coût.
Merci à tous pour vos retours et vos précisions !
Fabien
Le 26/06/2017 à 11:31, lemonnierk@ulrar.net a écrit :
On Mon, Jun 26, 2017 at 11:15:14AM +0200, Guillaume Hilt wrote:
Pourquoi qcow2 ? raw est généralement plus performant non ?
J'ai du mal à voir la différence en perf perso, et le qcow2 est quand même bien pratique (copy, snapshot, thin provisionning ..) En général ça vaut le coût.
Liste de diffusion du FRsAG http://www.frsag.org/
On 24/06/2017 21:01, Colin J. Brigato wrote:
:s,container,container\ Docker,
Sans animosité aucune mais les “containers” existent depuis bien avant l’usage spécifique "Dockeresque"d’aujourd’hui, et ceux-ci méritaient en général tout autant un stockage persistant, du coup.
Alors en effet si on parle de super chroot (jails, zones ou autres).
Et sinon pour le “ou alors du stockage objet”, ca reste une couche de présentation : si c’est que ca qui chiffonne et qu’on à de vieilles habitudes : s3fs, riofs, ou meme goofys – pour l’empreinte plus "container-rationel” même s’il est lent, pour ne citer qu’eux.
Oui et non. Ça ne m'amuse pas particulièrement d'accéder à mes "assets" en mode http ou s3 (et donc d’éduquer les devs). Si tu arrives à me sortir le FS magique distribué, auto-scalable qui fait la même chose j’achète. Mais à part si j'ai loupé un truc, cela n'existe pas. Tout les tricks qui présentent du S3 en FS peuvent aider en transition.
Le truc que je dis, c'est que globalement je ne penses pas que les applications aient réellement besoin d'une sémantique FS (au sens Posix du term) pour lire et stocker leurs data. Cela force meme à se poser de bonne question sur les metadata(s).
P’tet meme qu’on peut stocker des images disques pour [insérez une techno de virtu ici] et monter du S3 sur l’hyperviseur. Juste pour rire.
A tester, mais pas sur que S3 soit fait pour lire régulièrement le même objet et faire des seeks. ?
-- Raphael Mazelier
Si tu arrives à me sortir le FS magique distribué, auto-scalable qui fait la même chose j’achète. Mais à part si j'ai loupé un truc, cela n'existe pas.
Y’avais un Sysadmin a l’ancienne qui à longtemps cherché ça… Nicola Flamel un AlchiSops à la recherche du Flesystem Philosophale.
Blague à part oui ce FS n’existe pas, et plus ses prétendants s’en réclament, pire sont les compromis, le cout humain, et au final le résultat
Le truc que je dis, c'est que globalement je ne penses pas que les applications aient réellement besoin d'une sémantique FS (au sens Posix du term) pour lire et stocker leurs data. Cela force meme à se poser de bonne question sur les metadata(s).
Et c’est exactement “La” bonne question que celle des metadata en 2017 et au vu de l’état de l’art général du traitement de l’Information en général
A tester, mais pas sur que S3 soit fait pour lire régulièrement le même objet et faire des seeks. ?
Je ne pense pas, à moins qu’on puisse abuser de truc du genre du Partial Content pour l’assimiler à des Seek. En fait je pensais surtout à des “petits systemes” peut être même bare-metal like voir carrément no-os et puis du cache du cache du cache.
—
Colin J. Brigato
Le 25/06/2017 à 14:44, Raphael Mazelier a écrit :
Si tu arrives à me sortir le FS magique distribué, auto-scalable qui fait la même chose j’achète. Mais à part si j'ai loupé un truc, cela n'existe pas. Tout les tricks qui présentent du S3 en FS peuvent aider en transition.
Sur une infra Ceph, CephFS semble se rapprocher pas mal de ça il me semble. A voir, je n'utilise que le stockage bloc pour ma part.
http://docs.ceph.com/docs/master/cephfs/
Le 26/06/2017 à 08:43, Laurent Cligny a écrit :
Le 25/06/2017 à 14:44, Raphael Mazelier a écrit :
Si tu arrives à me sortir le FS magique distribué, auto-scalable qui fait la même chose j’achète. Mais à part si j'ai loupé un truc, cela n'existe pas. Tout les tricks qui présentent du S3 en FS peuvent aider en transition.
Sur une infra Ceph, CephFS semble se rapprocher pas mal de ça il me semble. A voir, je n'utilise que le stockage bloc pour ma part.
Est-ce que quelqu'un a déjà testé ou utiliser en prod Sheepdog ?
https://github.com/sheepdog/sheepdog http://sheepdog.github.io/sheepdog/
C'est sensé être un système distribué, auto-scalable pour les VM QEMU.
Le 02/07/2017 à 16:19, Frédéric MASSOT a écrit :
Le 26/06/2017 à 08:43, Laurent Cligny a écrit :
Le 25/06/2017 à 14:44, Raphael Mazelier a écrit :
Si tu arrives à me sortir le FS magique distribué, auto-scalable qui fait la même chose j’achète. Mais à part si j'ai loupé un truc, cela n'existe pas. Tout les tricks qui présentent du S3 en FS peuvent aider en transition.
Sur une infra Ceph, CephFS semble se rapprocher pas mal de ça il me semble. A voir, je n'utilise que le stockage bloc pour ma part.
Est-ce que quelqu'un a déjà testé ou utiliser en prod Sheepdog ?
https://github.com/sheepdog/sheepdog http://sheepdog.github.io/sheepdog/
C'est sensé être un système distribué, auto-scalable pour les VM QEMU.
Très curieux aussi. Je voulais faire un test drive mais le manque de maturité évident m'avait bien refroidit d'y passer 2/3 jours.
Le projet n'a pas l'air vivace mais quand même quelques commit. Maitenant, tout semble reposer sur un dev unique, pas forcément un gage de continuité à long terme ...
Julien
Le 24/06/2017 à 20:26, Raphael Mazelier a écrit :
Il est quand même important de bien faire le distinguo entre une techno d'exposition de block device (SAN donc, ou pourrait citer FC, FCoe, iscsi, atoe, etc...) et une techno de FS réseau sans block device partagé (NFS, Smb ?).
Vraiment ? Avec un FS distribué construit sur le dev block exporté par iSCSI, tu peux faire tout ce que fait NFS, non ?
C'est franchement différent. Tu penses j'image à OCFS2, GFS2 ? Le problème de ces FS c'est la gestion du lock (NFS s'en sort mieux à ce niveau même si ça reste un gros soucis). Je ne les conseillerais vraiment pas.
iSCSI t’expose un blockdevice, donc il faut ajouter un FS dessus pour l’utiliser. Depuis une VM où le but c’est juste de pousser un backup ailleurs, ça peut être bien d’écrire directement sur un NFS.
Sur une VM où c’est le /, j’aurais plutôt tendance à partir sur de l’iSCSI par contre, mais ça reste du feeling :p
Pour le stockage de VMs cela parait intuitivement plus logique d'utiliser du block. Le problème c'est que par définition tu vas avoir beaucoup de vm(s) et donc potentiellement autant de target que de vm(s). Ça se fait c'est du SAN à l'ancienne on va dire.
On utilise en général une approche différente, on utilise un ou plusieurs gros block device avec un FS distribué ou chaque vm(s) est stocké dans des fichiers (qui sont des images disques). Par exemple VMFS over FC, over iscsi ; ou directement NFS pour vmware. Sous XEN je connais des gens qui ont la même approche, export d'un gros share NFS ou on stocke des images disques des vm(s).
Ça se passe globalement bien, car en général une vm n’accède qu'une seule ou fois à son fichier d'image disque, du coup pas de problème d'accès concurrent au fichiers, lock unique au démarage de la vm.
Et après il faut bien regarder l'implémentation coté server aussi. Exemple assez connu, Netapp a avant tout été construit pour faire du NFS/Smb avec un FS interne (WAFL) prévu pour. L'implémentation d'isci au début était moche (un fichier image over WAFL). Du coup NFS était beaucoup plus performant sur Netapp qu'iscsi.
En tout cas malgré tout le mal que je pense de NFS c'est certainement plus simple et adapté pour du stockage de VMs.
L'immense problème de NFS (mais iscsi aussi) c'est la redondance et le scaling (vertical only).
Alors on peut être tenté d'utiliser un vrai block device partagé (Ceph avec RDB). On règle les deux problèmes au prix d'une certaine complexité.
Pour du container alors la par contre je dirais ni l'un ni l'autre ; un container ne devrait pas avoir besoin de stockage persistent, ou alors du stockage objet (S3 like).
Heu... ? Un container c'est pas forcément du stateless hein... Il y a d'autres technos que Docker (ou rkt) dans la vie.
Rémy
-- Raphael Mazelier
Liste de diffusion du FRsAG http://www.frsag.org/
On 30/06/2017 11:44, Remy Dernat wrote:
Heu... ? Un container c'est pas forcément du stateless hein... Il y a d'autres technos que Docker (ou rkt) dans la vie.
Plus qu'une question de technos (c'est bon j'ai utilisé massivement les jails, ou les zones solaris), c'est plus une question de philosophie. De nos jours la vm ne coûte rien (et quasi zero overhead) je ne vois personnellement l’intérêt des containers que pour des environnements où tu as besoin de densité applicatives. Après je fais des exceptions et je ne fais pas que du stateless dans mes containers (mais c'est plus pour de raisons de praticité/homogénéité qu'autre chose).
-- Raphael Mazelier
Le 24/06/2017 à 17:57, Fabien a écrit :
Bonjour la liste,
J'ai une question théorique concernant le stockage
Y a-t-il une réelle différence de performance entre le NFS et l'ISCSI ? Certaines situations nécessitent elle l'utilisation de l'une ou l'autre techno ?
Alors, même si ces deux technos ont l'avantage de la simplicité, à ta place, pour un cluster Proxmox 'moderne', je regarderais plutôt du côté de Ceph ou DRBD.
Ma préférence va, pour le moment, à DRBD même si son support est plus léger dans Proxmox (erreur de calcul de l'espace disque).
Le soucis de Ceph, c'est qu'il faut 4 machines pour démarrer et je ne suis pas certain que tu puisses utiliser ces machines pour faire tourner tes hyperviseurs. DRBD9 (avec drbdmanage), c'est deux machines pour démarrer et elles peuvent être à la fois noeud de stockage et hyperviseurs. Ca fait de belles économies pour démarrer. Tu devrais pouvoir monter jusqu'à 32 nœuds sans trop de soucis. Attention : c'est de le techno plus ou moins beta, attends toi à mettre les mains dans le cambouis quand il va y avoir un soucis. Jusqu'à présent, j'ai toujours réussi à repartir et retrouver une redondance suite à un incident avec un downtime minimal (quelques minutes le jour où j'ai dû faire un reboot d'un hyperviseur).
Autre astuce : utiliser un export NFS en plus du DRBD. Avec la fonctionnalité de déplacement du stockage à chaud dans Proxmox, tu peux basculer de NFS (lent) à DRBD (plutôt rapide, dépend de la latence et des disques) et les migrer sans shuter tes VMs le jour où ça commence à merdoyer (par exemple, si ta synchro DRBD est H.S. sur un noeud).
My 2 cts, Julien
Bonjour
Le 30 juin 2017 à 10:51, Julien Escario escario@azylog.net a écrit :
Le 24/06/2017 à 17:57, Fabien a écrit :
Bonjour la liste,
J'ai une question théorique concernant le stockage
Y a-t-il une réelle différence de performance entre le NFS et l'ISCSI ? Certaines situations nécessitent elle l'utilisation de l'une ou l'autre techno ?
Alors, même si ces deux technos ont l'avantage de la simplicité, à ta place, pour un cluster Proxmox 'moderne', je regarderais plutôt du côté de Ceph ou DRBD.
Ma préférence va, pour le moment, à DRBD même si son support est plus léger dans Proxmox (erreur de calcul de l'espace disque).
DRBD c’est toujours par grappe de 2 du coup c’est pas le top (a moins que j’ai rater une version)
Le soucis de Ceph, c'est qu'il faut 4 machines pour démarrer et je ne suis pas certain que tu puisses utiliser ces machines pour faire tourner tes hyperviseurs. DRBD9 (avec drbdmanage), c'est deux machines pour démarrer et elles peuvent être à la fois noeud de stockage et hyperviseurs. Ca fait de belles économies pour démarrer. Tu devrais pouvoir monter jusqu'à 32 nœuds sans trop de soucis. Attention : c'est de le techno plus ou moins beta, attends toi à mettre les mains dans le cambouis quand il va y avoir un soucis. Jusqu'à présent, j'ai toujours réussi à repartir et retrouver une redondance suite à un incident avec un downtime minimal (quelques minutes le jour où j'ai dû faire un reboot d'un hyperviseur).
Pour ceph tu as plusieurs façons de faire a voir selon les recommandations, mais en clair avec 2 serveurs distinct, moyen de faire un petit cluster ceph, les perfs seront pas top mais ça tient bien.
Dans mon cas j’ai un cluster ceph rattacher a proxmox avec 2 machines sata + 1 serveur de cache-tier, ça tourne plutôt bien.
L’intéraction avec proxmox est pas mal, snapshot / resize par contre des soucis pour le déplacement a chaud.
Autre astuce : utiliser un export NFS en plus du DRBD. Avec la fonctionnalité de déplacement du stockage à chaud dans Proxmox, tu peux basculer de NFS (lent) à DRBD (plutôt rapide, dépend de la latence et des disques) et les migrer sans shuter tes VMs le jour où ça commence à merdoyer (par exemple, si ta synchro DRBD est H.S. sur un noeud).
Dans la prochaine version de ceph qui sort dans 10-15 jours il prévois l’intégration de NFS avec comme backend Objet RGW (rados gateway).
Corentin
My 2 cts, Julien
Liste de diffusion du FRsAG http://www.frsag.org/
vendredi 30 juin 2017, 11:28:33 CEST Corentin BONNETON wrote:
Bonjour
Le soucis de Ceph, c'est qu'il faut 4 machines pour démarrer et je ne suis pas certain que tu puisses utiliser ces machines pour faire tourner tes hyperviseurs. DRBD9 (avec drbdmanage), c'est deux machines pour démarrer et elles peuvent être à la fois noeud de stockage et hyperviseurs. Ca fait de belles économies pour démarrer. Tu devrais pouvoir monter jusqu'à 32 nœuds sans trop de soucis. Attention : c'est de le techno plus ou moins beta, attends toi à mettre les mains dans le cambouis quand il va y avoir un soucis. Jusqu'à présent, j'ai toujours réussi à repartir et retrouver une redondance suite à un incident avec un downtime minimal (quelques minutes le jour où j'ai dû faire un reboot d'un hyperviseur).
Pour ceph tu as plusieurs façons de faire a voir selon les recommandations, mais en clair avec 2 serveurs distinct, moyen de faire un petit cluster ceph, les perfs seront pas top mais ça tient bien.
Dans mon cas j’ai un cluster ceph rattacher a proxmox avec 2 machines sata + 1 serveur de cache-tier, ça tourne plutôt bien.
Perso, j'ai commencé un cluster ceph avec une seule machine qui contenait un monitor et deux OSD. Après j'ai rajouté une machine pour ajouter 2 OSD de plus, et quand j'ai ajouté la 3ème machine qui ne fait que monitor, j'ai ajouté un monitor sur la 2ème machine (parce que deux monitor, ça peut faire des élections foireuses).
Et là, à 3 machines (3 mon, 4 OSD), ça tourne nickel.
Après, c'était pas pour servir de backend disque à une solution de virtualisation, j'avoue que j'ai un peu fait ça comme un porc au début (mais bon, j'allais pas louer 3 machines pour faire un test dès le départ, du coup j'ai commencé avec une).
Le 30/06/2017 à 11:28, Corentin BONNETON a écrit :
Bonjour
Le 30 juin 2017 à 10:51, Julien Escario escario@azylog.net a écrit :
Le 24/06/2017 à 17:57, Fabien a écrit :
Bonjour la liste,
J'ai une question théorique concernant le stockage
Y a-t-il une réelle différence de performance entre le NFS et l'ISCSI ? Certaines situations nécessitent elle l'utilisation de l'une ou l'autre techno ?
Alors, même si ces deux technos ont l'avantage de la simplicité, à ta place, pour un cluster Proxmox 'moderne', je regarderais plutôt du côté de Ceph ou DRBD.
Ma préférence va, pour le moment, à DRBD même si son support est plus léger dans Proxmox (erreur de calcul de l'espace disque).
DRBD c’est toujours par grappe de 2 du coup c’est pas le top (a moins que j’ai rater une version)
Nope, plus maintenant, en version 9 avec drbdmanage. En gros, tu fixe ta redondance (2/3 etc ...) et Proxmox réparti tes images de VMs en fonction de l'espace (en prenant les n machines ayant le plus de dispo).
Après, à la mano, tu peux assigner d'autres nœuds DRBD à telle ou telle ressource et en virer d'autres. (drbdmanage assign/unassign).
Rappel : DRBD, ce n'est pas du stockage distribué dans le sens où c'est simplement n réplicas de ton image de VM avec la capacité de te servir l'image même si elle n'est plus dispo QUE sur un nœud.
Ceph, c'est bien du stockage distribué qui s'arrange pour balancer chacun des blocs (en RBD) sur n nœuds et il se démerde ensuite pour te servir le bloc que tu demandes (la magie du CRUD).
Le gros défaut que j'avais trouvé à Ceph, c'était la lourdeur du rebalance lorsque tu rajoutes un OSD. Il replace une tonne de blocs et ça peut prendre pas mal de temps et pas mal de ressources (liens 10gbps quasi obligatoires). D'ailleurs, OVH en a fait les frais pendant un temps.
Et pas de support d'un mode asynchrone. Après, c'était il y a deux ans, ça a eu le temps de changer ...
Julien
Donc en DRDB, si tu as 4 noeuds avec 10To par noeud, tu n’as qu’au max 20To utile (si tu ne configures qu’un seul réplica), c’est ça ?
Le 30 juin 2017 à 11:57, Julien Escario escario@azylog.net a écrit :
Le 30/06/2017 à 11:28, Corentin BONNETON a écrit :
Bonjour
Le 30 juin 2017 à 10:51, Julien Escario escario@azylog.net a écrit :
Le 24/06/2017 à 17:57, Fabien a écrit :
Bonjour la liste,
J'ai une question théorique concernant le stockage
Y a-t-il une réelle différence de performance entre le NFS et l'ISCSI ? Certaines situations nécessitent elle l'utilisation de l'une ou l'autre techno ?
Alors, même si ces deux technos ont l'avantage de la simplicité, à ta place, pour un cluster Proxmox 'moderne', je regarderais plutôt du côté de Ceph ou DRBD.
Ma préférence va, pour le moment, à DRBD même si son support est plus léger dans Proxmox (erreur de calcul de l'espace disque).
DRBD c’est toujours par grappe de 2 du coup c’est pas le top (a moins que j’ai rater une version)
Nope, plus maintenant, en version 9 avec drbdmanage. En gros, tu fixe ta redondance (2/3 etc ...) et Proxmox réparti tes images de VMs en fonction de l'espace (en prenant les n machines ayant le plus de dispo).
Après, à la mano, tu peux assigner d'autres nœuds DRBD à telle ou telle ressource et en virer d'autres. (drbdmanage assign/unassign).
Rappel : DRBD, ce n'est pas du stockage distribué dans le sens où c'est simplement n réplicas de ton image de VM avec la capacité de te servir l'image même si elle n'est plus dispo QUE sur un nœud.
Ceph, c'est bien du stockage distribué qui s'arrange pour balancer chacun des blocs (en RBD) sur n nœuds et il se démerde ensuite pour te servir le bloc que tu demandes (la magie du CRUD).
Le gros défaut que j'avais trouvé à Ceph, c'était la lourdeur du rebalance lorsque tu rajoutes un OSD. Il replace une tonne de blocs et ça peut prendre pas mal de temps et pas mal de ressources (liens 10gbps quasi obligatoires). D'ailleurs, OVH en a fait les frais pendant un temps.
Et pas de support d'un mode asynchrone. Après, c'était il y a deux ans, ça a eu le temps de changer ...
Julien
Liste de diffusion du FRsAG http://www.frsag.org/
Le 30/06/2017 à 12:08, David Ponzone a écrit :
Donc en DRDB, si tu as 4 noeuds avec 10To par noeud, tu n’as qu’au max 20To utile (si tu ne configures qu’un seul réplica), c’est ça ?
Yup !
Il faut vraiment le voir comme un RAID1 over network. Même en RAID1 (même si c'est rarement utilisé), tu peux mettre 2, 3, 4 replicas.
Subtilité : avec DRBD manage, tu peux outrepasser le nombre de replicas que tu souhaite pour chaque ressource (aka image de VM). Par exemple, positionner à deux (par défaut 3 dans Proxmox d'ailleurs), et rajouter d'autres replicas sur la VM-super-critique-qui-ne-doit-jamais-tomber.
Après, sauf si y'a un truc que je ne vois pas bien, si tu veux que ta donnée soit disponibles en cas de crash du stockage d'une donnée, il faut bien la répliquer au moins une fois ailleurs donc perte de 50% de l'espace utile cash non ? Hum, ou alors avec une bidouille à base de parité à la RAID5 pour 3+ replicas. Moui, ça pourrait être fun comme concept mais casse gueule quand on parle de stockage réseau.
Julien
Hmm c’est en tout cas une évolution intéressante pour migrer de LVM/iSCSI et Qcows2/NFS. Reste que d’après ce que je lis, c’est pas sec-archisec, donc ça mérite peut -être d’attendre encore 1 ou 2 ans.
Question subsidiaire: ça supporte comment un freeze du switch 10G ?
Le 30 juin 2017 à 12:19, Julien Escario escario@azylog.net a écrit :
Le 30/06/2017 à 12:08, David Ponzone a écrit :
Donc en DRDB, si tu as 4 noeuds avec 10To par noeud, tu n’as qu’au max 20To utile (si tu ne configures qu’un seul réplica), c’est ça ?
Yup !
Il faut vraiment le voir comme un RAID1 over network. Même en RAID1 (même si c'est rarement utilisé), tu peux mettre 2, 3, 4 replicas.
Subtilité : avec DRBD manage, tu peux outrepasser le nombre de replicas que tu souhaite pour chaque ressource (aka image de VM). Par exemple, positionner à deux (par défaut 3 dans Proxmox d'ailleurs), et rajouter d'autres replicas sur la VM-super-critique-qui-ne-doit-jamais-tomber.
Après, sauf si y'a un truc que je ne vois pas bien, si tu veux que ta donnée soit disponibles en cas de crash du stockage d'une donnée, il faut bien la répliquer au moins une fois ailleurs donc perte de 50% de l'espace utile cash non ? Hum, ou alors avec une bidouille à base de parité à la RAID5 pour 3+ replicas. Moui, ça pourrait être fun comme concept mais casse gueule quand on parle de stockage réseau.
Julien
Liste de diffusion du FRsAG http://www.frsag.org/
Le 30/06/2017 à 12:34, David Ponzone a écrit :
Hmm c’est en tout cas une évolution intéressante pour migrer de LVM/iSCSI et Qcows2/NFS. Reste que d’après ce que je lis, c’est pas sec-archisec, donc ça mérite peut -être d’attendre encore 1 ou 2 ans.
On a déjà eu un ou deux moments ... intéressants ;-)
Le plus gros : le stack DRBD qui ne communique plus avec le management : à priori, un lock sur une I/O quelconque qui n'a jamais rendu la main, reboot du nœud indispensable. Résolu depuis d'après Linbit, à voir, je n'ai pas encore fait la montée de version.
En fait, en prod, ca marche. Linbit, quand ils parlent de not production ready, c'est notamment parce qu'ils incluent encore des changements non retro-compatibles avant la version finale. Du coup, mon upgrade à venir va être assez fun semble t'il. L'été, c'est fait pour ça ;-) (sérieux, qualité, toussa).
Sinon, c'est surtout des pertes de synchro sur une ressource ici et là, sans qu'on sache pourquoi. Avec un bon monitoring, un simple unassign/assign résoud le problème. On doit le faire 3 fois par mois pour ~ 80 VMs sur ce cluster.
On a aussi un cluster marrant pour un client avec deux machines réparties dans deux DCs et un VPN entre les deux (tincd sur ... ipv6). Ben figure toi, que ça marche nickel ! Peut être pas des perfs monstrueuses mais ca fait le job.
En fait, on fait du RAID1 (parce qu'on est riches) avec du LVM-thin (ZFS ferait le boulot aussi) et DRBD créé un LV par image de VM dans le vg thin. Dans l'absolu, le RAID1 soft est un peu excessif puisque la redondance est faite au dessus. On peut se permettre de perdre un disque sans downtime.
En revanche, mercredi, on a voulu restaurer une VM suite à une upgrade qui a très mal tourné et on a plafonné à 15Mo/s, même avec la synchro DRBD coupée (ressource mono-nœud). Je pense plutôt à une merde avec le format VMA introduit dans Proxmox. Pas mal de râleries là dessus sur le forum (si quelqu'un a des infos, je prends).
Question subsidiaire: ça supporte comment un freeze du switch 10G ?
Ben, les VMs vont continuer à tourner tranquillement et le secondary récupèrera les diff des blocs écrits entre temps au moment où il repassera en connected. Sur une petite coupure, on resync entre 5 et 10% des blocs. Idem si un nœud reboote complètement.
En revanche, il y a des setups bien plus touchys que ceux qu'on fait nous : avec du RDMA en IPoIB par exemple. Linbit a pas mal bossé là dessus semble t'il et quand les perfs comptent vraiment, ça doit pouvoir suivre (d'après la comm de Linbit, hein !).
La vache, chuis trop bavard et j'ai faim.
Julien
Le 30/06/2017 à 11:57, Julien Escario a écrit :
Le gros défaut que j'avais trouvé à Ceph, c'était la lourdeur du rebalance lorsque tu rajoutes un OSD. Il replace une tonne de blocs et ça peut prendre pas mal de temps et pas mal de ressources (liens 10gbps quasi obligatoires). D'ailleurs, OVH en a fait les frais pendant un temps.
Et pas de support d'un mode asynchrone. Après, c'était il y a deux ans, ça a eu le temps de changer ...
Parce que c’est fait pour la résilience, pas pour faire du NFS++ avec des performances de dingue.
GitLab s’est posé la question de migrer vers du bare-metal et du CEPH, ils ont vite changé d’avis :
- How We Knew It Was Time to Leave the Cloud https://about.gitlab.com/2016/11/10/why-choose-bare-metal/ - Why we are not leaving the cloud https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-the-cloud/
Mouais gitlab ..
Je note que beaucoup (trop) de gens prennent du matos qui traine, font un cluster ceph à la rache et s'imagine avoir un truc miraculeux qui va faire apparaître des IOPS par magie
Et du coup, déception et "Be very very careful about Ceph hype"
Ceph n'est pas NFS, les besoins sont différents, il est important de bien les comprendre (mais bon, c'est le métier de base du sysadmin, donc ça ne dois pas trop poser de problème ... ..)
On 30/06/2017 22:45, Johan Fleury wrote:
Le 30/06/2017 à 11:57, Julien Escario a écrit :
Le gros défaut que j'avais trouvé à Ceph, c'était la lourdeur du rebalance lorsque tu rajoutes un OSD. Il replace une tonne de blocs et ça peut prendre pas mal de temps et pas mal de ressources (liens 10gbps quasi obligatoires). D'ailleurs, OVH en a fait les frais pendant un temps.
Et pas de support d'un mode asynchrone. Après, c'était il y a deux ans, ça a eu le temps de changer ...
Parce que c’est fait pour la résilience, pas pour faire du NFS++ avec des performances de dingue.
GitLab s’est posé la question de migrer vers du bare-metal et du CEPH, ils ont vite changé d’avis :
- How We Knew It Was Time to Leave the Cloud
https://about.gitlab.com/2016/11/10/why-choose-bare-metal/
- Why we are not leaving the cloud
https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-the-cloud/
Liste de diffusion du FRsAG http://www.frsag.org/
On 30/06/2017 23:46, Johan Fleury wrote:
Le 30/06/2017 à 22:56, frsag@jack.fr.eu.org a écrit :
Ceph n'est pas NFS
On dit la même chose non ? De même pour les personne de la communauté qui ont écrit à GL, ou je me trompe ?
Oui, attention aux retours d'expériences de gens qui n'ont pas forcement saisi cela
Liste de diffusion du FRsAG http://www.frsag.org/
Le 30/06/2017 à 10:51, Julien Escario a écrit :
Le 24/06/2017 à 17:57, Fabien a écrit :
Bonjour la liste,
J'ai une question théorique concernant le stockage
Y a-t-il une réelle différence de performance entre le NFS et l'ISCSI ? Certaines situations nécessitent elle l'utilisation de l'une ou l'autre techno ?
Alors, même si ces deux technos ont l'avantage de la simplicité, à ta place, pour un cluster Proxmox 'moderne', je regarderais plutôt du côté de Ceph ou DRBD.
Ma préférence va, pour le moment, à DRBD même si son support est plus léger dans Proxmox (erreur de calcul de l'espace disque).
Pour info, on peut aussi faire un cluster glusterfs aussi maintenant dans Proxmox. Moi je fais du ZFS en local. Mais on peut aussi faire du ZFS over iSCSI + tout ce qui a déjà été cité. Concernant le stockage sur du NFS distant, je m'en sers pour faire mes dumps, mais pour les grosses VMs ou les gros containers, ça arrive que je me prenne des timeouts (malheureusement pas réglables)...
Rémy
Le soucis de Ceph, c'est qu'il faut 4 machines pour démarrer et je ne suis pas certain que tu puisses utiliser ces machines pour faire tourner tes hyperviseurs. DRBD9 (avec drbdmanage), c'est deux machines pour démarrer et elles peuvent être à la fois noeud de stockage et hyperviseurs. Ca fait de belles économies pour démarrer. Tu devrais pouvoir monter jusqu'à 32 nœuds sans trop de soucis. Attention : c'est de le techno plus ou moins beta, attends toi à mettre les mains dans le cambouis quand il va y avoir un soucis. Jusqu'à présent, j'ai toujours réussi à repartir et retrouver une redondance suite à un incident avec un downtime minimal (quelques minutes le jour où j'ai dû faire un reboot d'un hyperviseur).
Autre astuce : utiliser un export NFS en plus du DRBD. Avec la fonctionnalité de déplacement du stockage à chaud dans Proxmox, tu peux basculer de NFS (lent) à DRBD (plutôt rapide, dépend de la latence et des disques) et les migrer sans shuter tes VMs le jour où ça commence à merdoyer (par exemple, si ta synchro DRBD est H.S. sur un noeud).
My 2 cts, Julien
Liste de diffusion du FRsAG http://www.frsag.org/
Pour info, on peut aussi faire un cluster glusterfs aussi maintenant dans Proxmox.
Ça fait un moment. Ça marche plutôt bien d'ailleurs, on l'utilise beaucoup, mais il y a depuis plus d'un an un bug qui fait qu'on ne peut pas augmenter un volume shardé (un volume pour stoquer des VM en gros) sans corrompre tous les disques. Bref, c'est cool et ça marche bien, mais pour de la VM considérez que le l'ajout de brick est impossible pour l'instant. À noter qu'ils ont (enfin) réussi à le reproduire de leur coté, donc ça devrait être fix soon j'espère.
Le 30/06/2017 à 12:06, lemonnierk@ulrar.net a écrit :
Pour info, on peut aussi faire un cluster glusterfs aussi maintenant dans Proxmox.
Ça fait un moment. Ça marche plutôt bien d'ailleurs, on l'utilise beaucoup, mais il y a depuis plus d'un an un bug qui fait qu'on ne peut pas augmenter un volume shardé (un volume pour stoquer des VM en gros) sans corrompre tous les disques. Bref, c'est cool et ça marche bien, mais pour de la VM considérez que le l'ajout de brick est impossible pour l'instant. À noter qu'ils ont (enfin) réussi à le reproduire de leur coté, donc ça devrait être fix soon j'espère.
Cool ! Super nouvelle. Effectivement, je trouve que GlusterFS est un super produit, c'est dommage qu'il soit si souvent délaissé au profit d'autres solutions. Ceci dit, il nécessite quand même un bon réseau pour l'échange des métadonnées...
Liste de diffusion du FRsAG http://www.frsag.org/
Le 30/06/2017 à 10:51, Julien Escario a écrit :
Le 24/06/2017 à 17:57, Fabien a écrit :
Bonjour la liste,
J'ai une question théorique concernant le stockage
Y a-t-il une réelle différence de performance entre le NFS et l'ISCSI ? Certaines situations nécessitent elle l'utilisation de l'une ou l'autre techno ?
Alors, même si ces deux technos ont l'avantage de la simplicité, à ta place, pour un cluster Proxmox 'moderne', je regarderais plutôt du côté de Ceph ou DRBD.
Ma préférence va, pour le moment, à DRBD même si son support est plus léger dans
Pour le stoquage sur disque, t'a le bon vieux mirror de SAN|iSCSI. Très simple à comprendre, à administrer, utilisant des technos & process connu, ça m'a bien servi de durant de nombreuse années... Et ca permet le déplacement|reconfiguration a chaud sur la majorité des OS, donc pour des VM, c'est juste simple et efficace.
-
Alarig Le Lay -
Colin J. Brigato -
Corentin BONNETON -
David Ponzone -
Fabien -
frsag＠jack.fr.eu.org -
Frédéric MASSOT -
Guillaume Hilt -
Jean-Baptiste COUPIAC -
Johan Fleury -
Julien Escario -
Laurent Cligny -
lemonnierk＠ulrar.net -
Luc Didry -
Olivier Le Cam -
Raphael Mazelier -
Remy Dernat -
Renaud Galante -
Un