Re: [FRsAG] ISCSI vs NFS

[frsag]

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/
> 


-- 
"UNIX was not designed to stop its users from doing stupid things, as
that would also stop them from doing clever things." – Doug Gwyn
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Olivier Le Cam]

Le 24/06/2017 à 18:03, fr...@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

--
Olivier
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Fabien]

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, fr...@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/

Re: [FRsAG] ISCSI vs NFS

[frsag]

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, fr...@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/
> 


-- 
"UNIX was not designed to stop its users from doing stupid things, as
that would also stop them from doing clever things." – Doug Gwyn
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Alarig Le Lay]

On sam. 24 juin 19:12:32 2017, fr...@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.

-- 
alarig


signature.asc
Description: PGP signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Raphael Mazelier]

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










___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Johan Fleury]

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).

-- 
Johan Fleury
PGP Key ID : 0x5D404386805E56E6



signature.asc
Description: OpenPGP digital signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Colin J. Brigato]

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/

Re: [FRsAG] ISCSI vs NFS

[Renaud Galante]

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/

Re: [FRsAG] ISCSI vs NFS

[Raphael Mazelier]

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

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Colin J. Brigato]

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
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Laurent Cligny]

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/


--

Laurent CLIGNY
Responsable Exploitation IT


___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Guillaume Hilt]

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/


___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Jean-Baptiste COUPIAC]

Au pif, je dis Thin-Provisionning !

+

__

[image: NFrance Conseil] 

*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  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/
>
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[lemonnierk]

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.


signature.asc
Description: Digital signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Fabien]

Merci à tous pour vos retours et vos précisions !

Fabien


Le 26/06/2017 à 11:31, lemonni...@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/


___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Alarig Le Lay]

On lun. 26 juin 11:15:14 2017, Guillaume Hilt wrote:
> Pourquoi qcow2 ? raw est généralement plus performant non ?

Quitte à faire du raw, autant passer directement sur du LVM ou du ZFS,
ça évite le côté FS over FS.

-- 
alarig


signature.asc
Description: PGP signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Julien Escario]

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




smime.p7s
Description: Signature cryptographique S/MIME
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Corentin BONNETON]

Bonjour 

> Le 30 juin 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).

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/

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Luc Didry]

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).
-- 
Luc
https://fiat-tux.fr/
https://luc.frama.io/
Internet n'est pas compliqué, Internet est ce que vous en faites.

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Remy Dernat]

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/


--
Rémy Dernat
Ingénieur d'Etudes
MBB/ISE-M

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Remy Dernat]

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/


--
Rémy Dernat
Ingénieur d'Etudes
MBB/ISE-M

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Julien Escario]

Le 30/06/2017 à 11:28, Corentin BONNETON a écrit :
> Bonjour 
> 
>> Le 30 juin 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).
> 
> 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



smime.p7s
Description: Signature cryptographique S/MIME
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[lemonnierk]

> 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.


signature.asc
Description: Digital signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[David Ponzone]

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  a écrit :
> 
> Le 30/06/2017 à 11:28, Corentin BONNETON a écrit :
>> Bonjour 
>> 
>>> Le 30 juin 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).
>> 
>> 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/

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Un]

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.




--
A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Julien Escario]

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



smime.p7s
Description: Signature cryptographique S/MIME
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[David Ponzone]

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  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/

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Julien Escario]

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



smime.p7s
Description: Signature cryptographique S/MIME
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Remy Dernat]

Le 30/06/2017 à 12:06, lemonni...@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/


--
Rémy Dernat
Ingénieur d'Etudes
MBB/ISE-M

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Johan Fleury]

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

- Why we are not leaving the cloud


-- 
Johan Fleury
PGP Key ID : 0x5D404386805E56E6



signature.asc
Description: OpenPGP digital signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[frsag]

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
> 
> - Why we are not leaving the cloud
> 
> 
> 
> 
> ___
> Liste de diffusion du FRsAG
> http://www.frsag.org/
> 


-- 
"UNIX was not designed to stop its users from doing stupid things, as
that would also stop them from doing clever things." – Doug Gwyn
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Johan Fleury]

Le 30/06/2017 à 22:56, fr...@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 ?

-- 
Johan Fleury
PGP Key ID : 0x5D404386805E56E6



signature.asc
Description: OpenPGP digital signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[frsag]

On 30/06/2017 23:46, Johan Fleury wrote:
> Le 30/06/2017 à 22:56, fr...@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/
> 
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Raphael Mazelier]

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



___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Frédéric MASSOT]

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.
> 
> http://docs.ceph.com/docs/master/cephfs/

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.


-- 
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] ISCSI vs NFS

[Julien Escario]

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.
>>
>> http://docs.ceph.com/docs/master/cephfs/
> 
> 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



smime.p7s
Description: Signature cryptographique S/MIME
___
Liste de diffusion du FRsAG
http://www.frsag.org/