Salut la liste,
J'aurai besoin de vos lumières pour mettre en place un volume de 12To sur un système de fichier distribué, pour augmenter les temps de réponse et la disponibilité des fichiers. Il s'agit de fichiers pesant entre 10kio et 30Gio, pour un volume total actuel de 6.5Tio.
Est ce que vous auriez des idées sur un système de fichier distribué qui me permettrait d'envoyer du bois dans la chaudière ? Parce que l'actuel NFS commence à un peu à saturer vu le nombre de demandes simultanées qu'il a à traiter.
J'ai entendu parler de GlusterFS, mais je voulais avoir l'avis de la communauté :)
Merci
Cdlt, Jonathan "bartoua" SCHNEIDER
Le 18 octobre 2012 14:05, Jonathan SCHNEIDER bartoua@gmail.com a écrit :
Salut la liste,
J'aurai besoin de vos lumières pour mettre en place un volume de 12To sur un système de fichier distribué, pour augmenter les temps de réponse et la disponibilité des fichiers. Il s'agit de fichiers pesant entre 10kio et 30Gio, pour un volume total actuel de 6.5Tio.
Est ce que vous auriez des idées sur un système de fichier distribué qui me permettrait d'envoyer du bois dans la chaudière ? Parce que l'actuel NFS commence à un peu à saturer vu le nombre de demandes simultanées qu'il a à traiter.
J'ai entendu parler de GlusterFS, mais je voulais avoir l'avis de la communauté :)
Merci
Cdlt, Jonathan "bartoua" SCHNEIDER ______________________________**_________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
Il faudrait plus d'info sur les débits et la latence que tu souhaites atteindre, le matériel (réseau et stockage) dispo, etc...
Sinon LUSTRE peut faire l'affaire.
Le 18/10/2012 14:51, Méhdi Denou a écrit :
Bonjour,
Il faudrait plus d'info sur les débits et la latence que tu souhaites atteindre, le matériel (réseau et stockage) dispo, etc...
Sinon LUSTRE peut faire l'affaire.
Je rajoute aussi un autre critère, veux tu y accéder par un filesystem ou un stockage type abstrait clef/valeur suffit?
En FS pur j'avais testé GlusterFS en 2009, c'était à peu près bien jusqu'à qu'un changement de branche et de configuration ne soit plus adapté à mon usage. A l'époque j'avais de gros stall un peu comme en NFS, je pense que cela s'est amélioré puisque on en parle de plus en plus de cette solution.
Sinon en non posix que j'apprécie beaucoup car très performant, c'est MogileFS, 2 trackers, n nodes, des profils pour savoir combien de répliques tu souhaites pour les fichiers. Et tout le reste se fait en webdav, suffit de mettre un Nginx à la place du daemon perl et ça dépote plusieurs centaines de mo/sec sur deux serveurs.
J'ai vu passer GlusterFS, Ceph et MooseFS. Je n'ai de vraie expérience de prod avec aucun et je n'ai juste jamais testé Moose et Ceph, mais en gros :
- Moose ressemble pas mal à GFS donc *s'il marche bien* ça devrait être un bon choix (encore une fois, jamais testé). Il est censé être fiable et scalable.
- Gluster est simple à configurer et à comprendre niveau architecture, c'est juste un maitre + des esclaves. Par contre du coup il est très rapide en écriture, un peu moins scalable en lecture (mais bien plus que NFS).
- Ceph est complètement distribué, donc pas de SPOF, par contre ça le rend assez compliqué, probablement un peu plus gourmand en espace et difficile à administrer. Ça m'a l'air un peu overkill pour tes besoins.
Pour simplement remplacer un NFS qui a des problèmes de perfs, Gluster me parait pas mal (c'est probablement celui qui s'en approche le plus), sinon peut-être Moose (quelqu'un a testé ?). Les trois sont en standard dans le noyau Linux maintenant. À voir s'ils sont dispo selon les distributions par contre.
Tiens, d'ailleurs ça me rappelait quelque chose...
http://comments.gmane.org/gmane.org.user-groups.frsag/2106
Le 18 oct. 2012 à 15:11, "Pierre Chapuis" catwell@archlinux.us a écrit :
J'ai vu passer GlusterFS, Ceph et MooseFS. Je n'ai de vraie expérience de prod avec aucun et je n'ai juste jamais testé Moose et Ceph, mais en gros :
- Moose ressemble pas mal à GFS donc *s'il marche bien* ça devrait être un
bon choix (encore une fois, jamais testé). Il est censé être fiable et scalable.
- Gluster est simple à configurer et à comprendre niveau architecture,
c'est juste un maitre + des esclaves. Par contre du coup il est très rapide en écriture, un peu moins scalable en lecture (mais bien plus que NFS).
- Ceph est complètement distribué, donc pas de SPOF, par contre ça le
rend assez compliqué, probablement un peu plus gourmand en espace et difficile à administrer. Ça m'a l'air un peu overkill pour tes besoins.
Pour simplement remplacer un NFS qui a des problèmes de perfs, Gluster me parait pas mal (c'est probablement celui qui s'en approche le plus), sinon peut-être Moose (quelqu'un a testé ?). Les trois sont en standard dans le noyau Linux maintenant. À voir s'ils sont dispo selon les distributions par contre.
Bonjour,
J'ai du GlusterFS (une vieille version, 3.0.2) en production depuis 4 ans, sur des volumes assez importants, et notamment énormément de petits fichiers, avec un setup 2 master (full réplication) et une 20aine de noeuds. L'écriture se fait sur les noeuds, et ça réplique sur les masters.
En termes de stabilité, aucun soucis. En termes de rapidité de lecture, sur les petits fichiers, une fois mis en cache sur les nodes, pas de soucis non-plus. Une désynchro master / slave en 4 ans due à un problème réseau => un coup de rsync et ça repart.
Bonne journée
Le Thu, 18 Oct 2012 15:23:28 +0200,
Pour ma part, j'ai eu la même problématique et j'ai testé de manière assez approfondie MooseFS et GlusterFS (dans la version sortie il y a quelques mois).
Je trouve MooseFS particulièrement intéressant, l'ajout de disque ou de serveur se fait très simplement. Pas de possibilité d'erreur dans la configuration, possibilité d'isoler un disque defectueux, les données sont réparties sur les autres serveurs.
Le montage de fait sous Linux et FreeBSd sans soucis avec les paquets.
Une systeme de trash existe ainsi qu'une reprise après sinistre (pas automatisée).
Je le met en prod sur 6To sans aucun souci.
La principale différence avec GlsuerFS se situe au niveau de la données. Effet, MooseFS découpe le fichier en chunks alors que GluserFS les garde entier.
Les débits sont bons, il faut prévoir une bonne config reseau au niveau hardware. Pour une utilisation à max (serveur de max sous forte charge), il est conseillé de mettre un switch dédié avec une config jumbo frame
Bien cordialement,
Jean-Christophe PAROLA
Au niveau de cette infra, c'est du full debian : il y a 3 serveurs physiques pour l'applicatif qui sont des conteneurs de VZ (les VZ contiennent soit un serveur nginx/PHP soit un MySQL) et 2 serveurs NFS en synchro drbd. Les serveurs hébergent des médiathèques qui sont par définition pompeuses de stockage et de bande passante.
Il me faudrait un FS à monter directement sur les VZ, le système clef/valeur est pas possible sur le soft en question.
Au niveau des stats, on est à ~50Gio en lecture par jour et ~60Gio en écriture par jour en moyenne, on peut avoir des rushs qui sont bien pire en montant à ~110Gio/jour en lecture, sur des débits de ~30Mbps.
Bien sûr je cherche à booster le débit autant que possible :) Le volume de données risque d'augmenter de quelques Tio d'ici pas longtemps avec le volume de données échangé.
Donc pour l'instant je retiens donc Gluster, Moose, swift et ceph.
Cdlt, Jonathan "bartoua" SCHNEIDER
On 18/10/2012 16:23, Jonathan SCHNEIDER wrote:
Au niveau de cette infra, c'est du full debian : il y a 3 serveurs physiques pour l'applicatif qui sont des conteneurs de VZ (les VZ contiennent soit un serveur nginx/PHP soit un MySQL) et 2 serveurs NFS en synchro drbd. Les serveurs hébergent des médiathèques qui sont par définition pompeuses de stockage et de bande passante.
Il me faudrait un FS à monter directement sur les VZ, le système clef/valeur est pas possible sur le soft en question.
Au niveau des stats, on est à ~50Gio en lecture par jour et ~60Gio en écriture par jour en moyenne, on peut avoir des rushs qui sont bien pire en montant à ~110Gio/jour en lecture, sur des débits de ~30Mbps.
Bien sûr je cherche à booster le débit autant que possible :) Le volume de données risque d'augmenter de quelques Tio d'ici pas longtemps avec le volume de données échangé.
Donc pour l'instant je retiens donc Gluster, Moose, swift et ceph.
Cdlt, Jonathan "bartoua" SCHNEIDER
A noter que CephFS n'est pas encore considéré comme stable par ses développeurs, et que la techno en question obtient les meilleurs résultats sous Btrfs, lui même non stable.
Néanmoins entre (CephFS over ext4) et (Btrfs seul), je pense que le premier FS est plus fiable.
Olivier
Le 18/10/2012 16:33, Olivier Bonvalet a écrit :
On 18/10/2012 16:23, Jonathan SCHNEIDER wrote:
Au niveau de cette infra, c'est du full debian : il y a 3 serveurs physiques pour l'applicatif qui sont des conteneurs de VZ (les VZ contiennent soit un serveur nginx/PHP soit un MySQL) et 2 serveurs NFS en synchro drbd. Les serveurs hébergent des médiathèques qui sont par définition pompeuses de stockage et de bande passante.
Il me faudrait un FS à monter directement sur les VZ, le système clef/valeur est pas possible sur le soft en question.
Au niveau des stats, on est à ~50Gio en lecture par jour et ~60Gio en écriture par jour en moyenne, on peut avoir des rushs qui sont bien pire en montant à ~110Gio/jour en lecture, sur des débits de ~30Mbps.
Bien sûr je cherche à booster le débit autant que possible :) Le volume de données risque d'augmenter de quelques Tio d'ici pas longtemps avec le volume de données échangé.
Donc pour l'instant je retiens donc Gluster, Moose, swift et ceph.
Cdlt, Jonathan "bartoua" SCHNEIDER
A noter que CephFS n'est pas encore considéré comme stable par ses développeurs, et que la techno en question obtient les meilleurs résultats sous Btrfs, lui même non stable.
A noter que GlusterFS et NFS se prétendent stable depuis des années, ce n'est qu'une question de point de vue ;)
On 18/10/2012 16:40, Gregory Duchatelet wrote:
Le 18/10/2012 16:33, Olivier Bonvalet a écrit :
On 18/10/2012 16:23, Jonathan SCHNEIDER wrote:
Au niveau de cette infra, c'est du full debian : il y a 3 serveurs physiques pour l'applicatif qui sont des conteneurs de VZ (les VZ contiennent soit un serveur nginx/PHP soit un MySQL) et 2 serveurs NFS en synchro drbd. Les serveurs hébergent des médiathèques qui sont par définition pompeuses de stockage et de bande passante.
Il me faudrait un FS à monter directement sur les VZ, le système clef/valeur est pas possible sur le soft en question.
Au niveau des stats, on est à ~50Gio en lecture par jour et ~60Gio en écriture par jour en moyenne, on peut avoir des rushs qui sont bien pire en montant à ~110Gio/jour en lecture, sur des débits de ~30Mbps.
Bien sûr je cherche à booster le débit autant que possible :) Le volume de données risque d'augmenter de quelques Tio d'ici pas longtemps avec le volume de données échangé.
Donc pour l'instant je retiens donc Gluster, Moose, swift et ceph.
Cdlt, Jonathan "bartoua" SCHNEIDER
A noter que CephFS n'est pas encore considéré comme stable par ses développeurs, et que la techno en question obtient les meilleurs résultats sous Btrfs, lui même non stable.
A noter que GlusterFS et NFS se prétendent stable depuis des années, ce n'est qu'une question de point de vue ;)
C'est pas faux. Mais typiquement on avait tenté un remplacement de NFS par Ceph il y a un an environ, mais on a rapidement eu des corruptions de données. Du coup on est repassé sur NFS en attendant que Ceph se stabilise.
NFS scale mal, la tolérance aux pannes m'a l'air très capricieuse, mais on a encore rien perdu avec.
On Thu, Oct 18 2012, Jonathan SCHNEIDER wrote:
J'aurai besoin de vos lumières pour mettre en place un volume de 12To sur un système de fichier distribué, pour augmenter les temps de réponse et la disponibilité des fichiers. Il s'agit de fichiers pesant entre 10kio et 30Gio, pour un volume total actuel de 6.5Tio.
Je peux conseiller Swift, mais qui est destiné à faire du object storage via une API REST:
Il a une couche de compatibilité API Amazon S3 et donc la possibilité d'être monté via FUSE au besoin (mais les perfs ne sont sans doutes pas les mêmes).
<snip>
Une autre piste moins bonne que celles données ici c'est pNFS qui une extension de NFS...
Sinon je pense que tu peux regarder le doc ici : http://fr.slideshare.net/schubertzhang/distributed-filesystems-review
Cordialement,
JYL
Le 18/10/2012 14:05, Jonathan SCHNEIDER a écrit :
Salut la liste,
J'aurai besoin de vos lumières pour mettre en place un volume de 12To sur un système de fichier distribué, pour augmenter les temps de réponse et la disponibilité des fichiers. Il s'agit de fichiers pesant entre 10kio et 30Gio, pour un volume total actuel de 6.5Tio.
Est ce que vous auriez des idées sur un système de fichier distribué qui me permettrait d'envoyer du bois dans la chaudière ? Parce que l'actuel NFS commence à un peu à saturer vu le nombre de demandes simultanées qu'il a à traiter.
J'ai entendu parler de GlusterFS, mais je voulais avoir l'avis de la communauté :)
Bonjour,
j'ai récemment écris un article sur Ceph, où je l'ai installé en production mais pour seulement 450GB :
http://www.duchatelet.net/blog/?post/2012/09/21/Ceph-et-CephFS
NFSv4 j'en ai ras le bol, c'est très pénible coté client en cas de problèmes; GlusterFS j'en ai mangé aussi des problèmes, et la team qui développe ça est plus intéressée par les features que la stabilité, tout le contraire de Ceph.
Pour moi, c'est Ceph l'avenir en FS distribué POSIX, même si je pense que les serveurs clefs/valeurs sont bien plus faciles/scalables/features++ que ces FS si on peut les utiliser...
Yop,
http://www.duchatelet.net/blog/?post/2012/09/21/Ceph-et-CephFS
tu as fait : - planter des mds/ods (pas juste un stop propre) ? - des tests de perfs ?
ça m'intéresserait ;)
Le 18/10/2012 16:55, Maxence Dunnewind a écrit :
Yop,
http://www.duchatelet.net/blog/?post/2012/09/21/Ceph-et-CephFS
tu as fait :
- planter des mds/ods (pas juste un stop propre) ?
oui avec des reboot électrique par PDU notamment : même comportement qu'avec un stop propre.
- des tests de perfs ?
non, je n'ai pas eu le temps et ce n'est pas un besoin primordiale pour l'utilisation que je vais en faire... Mais je peux en faire un, tu aimerai quoi comme tests ? :)
http://www.duchatelet.net/blog/?post/2012/09/21/Ceph-et-CephFS
tu as fait :
- planter des mds/ods (pas juste un stop propre) ?
oui avec des reboot électrique par PDU notamment : même comportement qu'avec un stop propre.
cool :) Et ça se remonte tout seul ?
- des tests de perfs ?
non, je n'ai pas eu le temps et ce n'est pas un besoin primordiale pour l'utilisation que je vais en faire... Mais je peux en faire un, tu aimerai quoi comme tests ? :)
des trucs assez basiques pour commencer. J'ai fait un ptit cluster sur 4 noeuds (3 ods/1 mds) et j'avais des débits minables (genre 10Mbps sur un dd)
Maxence
Ne pas oublier LUSTRE dans le lot.
Il est utilisé dans pas mal de clusters HPC et est connu pour ses débits élevés (plusieurs centaines de Go/s sur de gros clusters). L'idée de lustre est de découper les fichiers et de les répartir (un raid 0 via le réseau en gros). Un serveur gère les métadonnées (le MDS). Les serveurs de fichiers (OSS object storage server) hébergent les données. La redondance est à assurer sur chaque élément (OST *object storage targets, *plusieurs OST par OSS*) *hébergeant les chunks.
Le 18 octobre 2012 17:25, Maxence Dunnewind maxence@dunnewind.net a écrit :
http://www.duchatelet.net/blog/?post/2012/09/21/Ceph-et-CephFS
tu as fait :
- planter des mds/ods (pas juste un stop propre) ?
oui avec des reboot électrique par PDU notamment : même comportement qu'avec un stop propre.
cool :) Et ça se remonte tout seul ?
- des tests de perfs ?
non, je n'ai pas eu le temps et ce n'est pas un besoin primordiale pour l'utilisation que je vais en faire... Mais je peux en faire un, tu aimerai quoi comme tests ? :)
des trucs assez basiques pour commencer. J'ai fait un ptit cluster sur 4 noeuds (3 ods/1 mds) et j'avais des débits minables (genre 10Mbps sur un dd)
Maxence
-- Maxence DUNNEWIND Contact : maxence@dunnewind.net Site : http://www.dunnewind.net
- 33 6 32 39 39 93
GPG : 18AE 61E4 D0B0 1C7C AAC9 E40D 4D39 68DB 0D2E B533
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAlCAH00ACgkQTTlo2w0utTOS9gCfRZFyPKCIWfedrUCktPzcI33o yOsAoLhjca0ke0rFCXr9wYfIxIJplSr3 =HA2J -----END PGP SIGNATURE-----
Liste de diffusion du FRsAG http://www.frsag.org/
Bonsoir,
Le 18 octobre 2012 18:19, Méhdi Denou mehdi.denou@gmail.com a écrit :
Ne pas oublier LUSTRE dans le lot.
Il est utilisé dans pas mal de clusters HPC et est connu pour ses débits élevés (plusieurs centaines de Go/s sur de gros clusters). L'idée de lustre est de découper les fichiers et de les répartir (un raid 0 via le réseau en gros). Un serveur gère les métadonnées (le MDS).
Le MDS dans Lustre est un SPOF. Même si en pratique Lustre est choisis en très grande majorité dans le TOP500 des grands calculateurs, ce qui en fait le n° 1 ?
Greg
Le 18 octobre 2012 17:25, Maxence Dunnewind maxence@dunnewind.net a écrit :
http://www.duchatelet.net/blog/?post/2012/09/21/Ceph-et-CephFS
tu as fait :
- planter des mds/ods (pas juste un stop propre) ?
oui avec des reboot électrique par PDU notamment : même comportement qu'avec un stop propre.
cool :) Et ça se remonte tout seul ?
- des tests de perfs ?
non, je n'ai pas eu le temps et ce n'est pas un besoin primordiale pour l'utilisation que je vais en faire... Mais je peux en faire un, tu aimerai quoi comme tests ? :)
des trucs assez basiques pour commencer. J'ai fait un ptit cluster sur 4 noeuds (3 ods/1 mds) et j'avais des débits minables (genre 10Mbps sur un dd)
Maxence
-- Maxence DUNNEWIND Contact : maxence@dunnewind.net Site : http://www.dunnewind.net
- 33 6 32 39 39 93
GPG : 18AE 61E4 D0B0 1C7C AAC9 E40D 4D39 68DB 0D2E B533
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAlCAH00ACgkQTTlo2w0utTOS9gCfRZFyPKCIWfedrUCktPzcI33o yOsAoLhjca0ke0rFCXr9wYfIxIJplSr3 =HA2J -----END PGP SIGNATURE-----
Liste de diffusion du FRsAG http://www.frsag.org/
-- Méhdi Denou Master 2 Architecture des Systèmes en Réseaux, Université d'Evry. 06 64 18 67 71
Liste de diffusion du FRsAG http://www.frsag.org/
qu'avec un stop propre.
cool :) Et ça se remonte tout seul ?
tant qu'il y a au moins 2 mon et 1 ods et 1 mds, oui, c'est transparent ;)
- des tests de perfs ?
non, je n'ai pas eu le temps et ce n'est pas un besoin primordiale pour l'utilisation que je vais en faire... Mais je peux en faire un, tu aimerai quoi comme tests ? :)
des trucs assez basiques pour commencer. J'ai fait un ptit cluster sur 4 noeuds (3 ods/1 mds) et j'avais des débits minables (genre 10Mbps sur un dd)
A interpréter !
# sur CephFS : perceval-01:/var/local/data# dd if=/dev/zero of=t count=1024000 1024000+0 records in 1024000+0 records out 524288000 bytes (524 MB) copied, 1.62767 s, 322 MB/s perceval-01:/var/local/data# dd if=/dev/zero of=t count=10240000 10240000+0 records in 10240000+0 records out 5242880000 bytes (5.2 GB) copied, 66.4928 s, 78.8 MB/s
# sur le disque : perceval-01:/var/local# dd if=/dev/zero of=t count=10240000 10240000+0 records in 10240000+0 records out 5242880000 bytes (5.2 GB) copied, 30.5241 s, 172 MB/s
Greg
Maxence
-- Maxence DUNNEWIND Contact : maxence@dunnewind.net Site : http://www.dunnewind.net
- 33 6 32 39 39 93
GPG : 18AE 61E4 D0B0 1C7C AAC9 E40D 4D39 68DB 0D2E B533
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAlCAH00ACgkQTTlo2w0utTOS9gCfRZFyPKCIWfedrUCktPzcI33o yOsAoLhjca0ke0rFCXr9wYfIxIJplSr3 =HA2J -----END PGP SIGNATURE-----
Liste de diffusion du FRsAG http://www.frsag.org/
On Thu, 18 Oct 2012 20:51:42 +0200 Greg greg-frsag@duchatelet.net wrote:
A interpréter !
# sur CephFS : perceval-01:/var/local/data# dd if=/dev/zero of=t count=1024000 1024000+0 records in 1024000+0 records out 524288000 bytes (524 MB) copied, 1.62767 s, 322 MB/s perceval-01:/var/local/data# dd if=/dev/zero of=t count=10240000 10240000+0 records in 10240000+0 records out 5242880000 bytes (5.2 GB) copied, 66.4928 s, 78.8 MB/s
# sur le disque : perceval-01:/var/local# dd if=/dev/zero of=t count=10240000 10240000+0 records in 10240000+0 records out 5242880000 bytes (5.2 GB) copied, 30.5241 s, 172 MB/s
C'est un peu plus jeune homme :)
Tu peux faire un dbench ou un iozone ?
Pour plus de 100 To, çà passe comme FS ?
++
Bonjour,
2012/10/18 Jérôme Benoit jerome.benoit@grenouille.com
On Thu, 18 Oct 2012 20:51:42 +0200 Greg greg-frsag@duchatelet.net wrote:
A interpréter !
# sur CephFS :
C'est un peu plus jeune homme :)
Tu peux faire un dbench ou un iozone ?
Pour plus de 100 To, çà passe comme FS ?
Je suis étonné que personne ne parle de système type netapp ou autre emc, qui réponde également au besoin.
Personnellement, j'aurai un peu peur de mettre ma production sur des FS "expérimentaux" type Ceph.
Cordialement,
Le 19 octobre 2012 12:19, seb astien krionux@gmail.com a écrit :
Je suis étonné que personne ne parle de système type netapp ou autre emc, qui réponde également au besoin.
Personnellement, j'aurai un peu peur de mettre ma production sur des FS "expérimentaux" type Ceph.
Cordialement,
Parce que NetAPP ou EMC ne répondent pas au besoin ici il me semble. Il s'agit de SAN/NAS proposant du NFS, CIFS, iSCSI, FC ...
Le 19 octobre 2012 12:23, Ludovic Cartier cartier.ludovic@gmail.com a écrit :
Le 19 octobre 2012 12:19, seb astien krionux@gmail.com a écrit :
Je suis étonné que personne ne parle de système type netapp ou autre emc, qui réponde également au besoin.
Personnellement, j'aurai un peu peur de mettre ma production sur des FS "expérimentaux" type Ceph.
Cordialement,
Parce que NetAPP ou EMC ne répondent pas au besoin ici il me semble. Il s'agit de SAN/NAS proposant du NFS, CIFS, iSCSI, FC ...
--
Pourquoi, parce que ce n'est pas distribué ? Car je pense que ça permet d'augmenter sensiblement les IOs etc...
Pourquoi, parce que ce n'est pas distribué ? Car je pense que ça permet d'augmenter sensiblement les IOs etc...
Disons que le postulat de base était d'avoir un avis sur les FS distribués, or pour moi, NetAPP et EMC ne rentre pas dans cette catégorie. Après, je te rejoins sur un point, je serais plus confiant à mettre ma prod sur de telles appliances que sur un FS distribué "non-finalisé". C'est d'ailleurs ce que j'ai fait il y a moins de 6 mois en achetant du NetAPP.
On Thu, 18 Oct 2012 21:02:41 +0200 Jérôme Benoit jerome.benoit@grenouille.com wrote:
C'est un peu plus jeune homme :)
^s/plus/court
Je relance le sujet, avec notre volonté de ne plus utiliser d'adressage local RFC1918 sur notre nouvelle archi, je me suis retrouvé complètement coincé sur GlusterFS.
J'avais gardé un mauvais souvenir de Gluster lors de la version 1, je me suis dit avec 2 major release de plus pourquoi ne pas retester.
Pour tester je me suis mis en objectif de monter deux serveurs web répliqués car c'est une demande que j'ai souvent, avoir un petit cluster sans monter une grosse architecture avec plein de serveurs. Ces deux serveurs étant dans une DMZ derrière des reverse proxy dual stacks, ils n'ont aucune utilité d'une ipv4 publique et encore moins d'une privée.
Bref je teste donc la dernière version 3.3.1 (à partir de leurs packages) sur une Debian stable. Les procédures d'installations se sont simplifiées, on utilise désormais gluster comme utilitaire de configuration.
Quand j'arrive à l'étape d'ajouter voisins à chaque noeud : gluster peer probe
J'ai un beau message Connection Failed. Après analyse le daemon glusterfd n'écoute pas en v6, il faut ajouter une option pour cela. Après redémarrage le daemon écoute bien en v6 (only c'est d'ailleurs étonnant). En relançant la commande d'ajout, toujours le même message, je lance des tcpdumps sur les deux machines, aucun trafic ...
J'ai eu beau retourner leurs docs, le support, les archives de mailing list, le bugtracker, ipv6 a bien été ajouté dans le branche 3.3.
Ma conclusion est que l'outils gluster nécessaire pour configurer le serveur n'est pas capable d'initier de connexion ipv6.
Voilà encore une fonctionnalité bien testé, ils ont ajoutés ipv6 en écoute sans même tester des machines v6 only.
On est en 2012, y a plus de v4, on a déjà une bonne dizaine de serveurs migrés en full v6 derrière des proxys pour les flux entrants et derrière un nat64 dns64 pour la sortie vers les machines v4 only. Tout marche très bien donc la règle à présent, tout ce qui ne marche pas en v6 ne sera plus proposé aux clients, on estime que cela montre la qualité du développement, de l'intégration des évolutions (ipv6 a plus de 10 ans).
Quand un vieux projet met du temps à adopter de nouveaux usages cela peu se comprendre, autant sur des projets moyennement vieux comme Gluster, ils n'avaient aucune excuse pour ne pas coder directement la bonne écoute de leurs daemon sur la dual stack. Début 2000 on faisait déjà du C/C++ en dual stack dans nos projets ...
Bref je vais tester le suivant Ceph pour ce type de maquette.
Le 19/11/2012 19:15, Wallace a écrit :
J'ai eu beau retourner leurs docs, le support, les archives de mailing list, le bugtracker, ipv6 a bien été ajouté dans le branche 3.3.
Bonjour Pierre-Henry,
c'est ce que je reprochais à GlusterFS déjà en 2009 : proposer des tas de features, mais elles ne fonctionnent pas toute correctement... C'est ce qu'on reproche principalement aux éditeurs propriétaire : ils nous font de super logiciel sur le papier, en pratique il faut des ingé certifiés pour contourner les bugs ...
A part ça je me demande pourquoi tu forces l'utilisation de ipv6 pour le réseau privé ? Simplement pour éviter le dual-stack ?
2012/11/20 Gregory Duchatelet greg-frsag@duchatelet.net:
Le 19/11/2012 19:15, Wallace a écrit :
A part ça je me demande pourquoi tu forces l'utilisation de ipv6 pour le réseau privé ? Simplement pour éviter le dual-stack ?
Hello,
Sans avoir trop réfléchi à la question, je pense que c'est tout bêtement pour que les machines internes aient accès à l'internet v6 _et_ v4 (webservices, etc), non ?
Cordialement,
Le 20/11/2012 10:24, Aurélien a écrit :
2012/11/20 Gregory Duchatelet greg-frsag@duchatelet.net:
Le 19/11/2012 19:15, Wallace a écrit :
A part ça je me demande pourquoi tu forces l'utilisation de ipv6 pour le réseau privé ? Simplement pour éviter le dual-stack ?
Hello,
Sans avoir trop réfléchi à la question, je pense que c'est tout bêtement pour que les machines internes aient accès à l'internet v6 _et_ v4 (webservices, etc), non ?
Cordialement,
A notre avis, l'ipv4 en réseau privé n'a plus lieu d'être, en tout cas pour un réseau de serveurs. Pour le lan entreprise on verra un peu plus tard.
Pourquoi on en a marre d'ipv4 privé : - conflit d'adressage permanent avec les clients, on en était arrivé à utiliser le subnet 192.0.2 de test pour un adressage interne tellement c'était conflictuel. Le nat 1/1 et autre bidouille ça va un moment... - le nat c'est juste lourd à gérer à force, cela ne protège de rien, certaines applications ne sont pas compatibles, ... - routage inter site, inter vpn, ... devenu pénible à gérer avec routage dynamique pour pouvoir ré-annoncer à tout le réseau interne que le petit /28 dans un coin a été mis ailleurs ...
Notre vision pour ipv6 : - ip unique par machine joignable directement ou non depuis internet - facilité d'administration et de supervision, une machine une ipv6 d'office (ipv4 optionnelle) et un nom dns en AAAA et A si besoin. Toutes les machines sont joignables directement, ping / traceroute possible (sans le nat la vie est plus folle). - niveau firewalling c'est super simple, des règles globales, des règles sur les machines, plus de redirection de port !! En gros on route et on filtre c'est tout.
Si on considère par exemple des serveurs mysql qui en tout logique n'ont pas de services à délivrer sur internet, les machines sont en v6 only, la supervision, les machines d'admin, la métrologie, les sauvegardes y accèdent directement sans NAT (quel bonheur mais je crois que je l'ai déjà dit). Les serveurs communiquent entre eux en v6, on a rencontré aucun soucis. Les serveurs savent surfer en v6 et ceux qui sont en v6 only (donc sans dual stack) sont branchés sur un resolver dns64 qui transforme une machine distance v4 only en une adresse v6. Le serveur dispose d'une route spécifique pour le subnet nat64 qui l'envoie vers une passerelle v6/v4 et qui là du coup nat en sortie en v4. Cette passerelle NAT64 sert principalement à joindre les repository qui sont v4 only et faire quelques wget ou autre curl sur des sites v4. Le NAT64 gère très bien udp et tcp, skype/icmp passent pas à travers mais c'est pas grave.
Les seules machines ayant besoin de dual stack sont les machines publiques (et encore pas toute). Typiquement certains clients ont des serveurs web en v6 only et utilisent notre batterie de reverse proxy pour servir en v4 et v6 leurs sites avec en plus la fonction de cache. Comme les machines sont reversées pas besoin de v4 sur le serveur.
Si on doit résumer la philosophie de ma boite à l'heure actuelle, je considère que ipv6 est la norme (on a du faire une nouvelle archi récemment donc on en a profité) et qu'ipv4 est l'exception.
La suite du programme c'est le réseau interne mais là c'est une autre histoire, quand je vois le nombre d'équipements (imprimantes, boitier voip, ...) qui ne sont pas compatible ipv6 ou qui demandent obligatoirement une v4 pour configurer du v6 ...
Alors que passer un réseau interne en v6 avec un nat64 cela suffirait mais depuis 10 ans aucun constructeur ne fait d'effort...
-
Aurélien -
Frédéric de Villamil -
Greg -
Gregory Duchatelet
-
JC PAROLA -
jean-yves＠lenhof.eu.org -
Jonathan SCHNEIDER -
juke＠free.fr -
Julien Danjou -
Jérôme Benoit -
Ludovic Cartier -
Maxence Dunnewind -
Méhdi Denou -
Olivier Bonvalet -
Pierre Chapuis -
seb astien -
Wallace