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.

Tiens, d'ailleurs ça me rappelait quelque chose... http://comments.gmane.org/gmane.org.user-groups.frsag/2106 -- Pierre 'catwell' Chapuis

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

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

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.

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 ? :)

-- 
Greg

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


-- 
Méhdi Denou
Master 2 Architecture des Systèmes en Réseaux,
Université d'Evry.
06 64 18 67 71

...

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/

-- Greg

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

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

-- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D

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 ? -- Greg

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