Bonjour,

J'aimerais créer un cluster pour y stocker mon cloud (emails / seedbox / fichiers personnels) pour ne plus être dépendant de services externe et pour apprendre à gérer une infrastructure redondée.
Comme je ne veux absolument pas perdre de données, je veux une réplication des données x2 au minimum (toutes les données seront répliqués sauf les données de ma seedbox) sur 2 serveurs physiques et pouvoir déployer facilement et avoir une configuration portable. Comme je travail très souvent sur mes serveurs, il arrive tès souvent que j'ai des downtimes que j'aimerais à partir de maintenant éviter avec la mise en place du cluster.

Je me suis penché sur la solution Docker Swarm en mode intégré qui est plutôt facile à mettre en place et simplifie beaucoup la mise en place d'un cluster depuis la version 1.12. Par contre la feature est nouvelle (Mai 2016) et manque encore de fonctionnalités en cours de développement comme le déploiement d'une stack sur un cluster (genre un docker-compose pour déployer des services).

Je compte louer 2 serveurs Kimsufi pour le stockage + 1 VM DigitalOcean, tous en mode managers (Docker Swarm impose au minimum 3 managers pour maintenir le cluster en cas de panne d'un host). Soit un total d'~40€/mois pour 2To redondé.

Pour le stockage je songe à utiliser GlusterFS, DRDB ou encore Ceph qui me paraissent fiables comme solutions.
  • * Dans quel cas utiliser un stockage type block storage ou file system ?
    * Est ce que le block storage est un peu "passe partout" comme c'est une couche au dessus du file system ?
    * Lequel utilisez vous et pourquoi ?
    * Ces solutions m'ont l'air plutot magiques, mais si un des nodes lag, est ce que ça impact tout le cluster ?
    * Si j'ai bien compris, en mode block storage, je peux aussi faire de la réplication de base de données sans passer par de solutions genre Mysql Cluster ou Galera Cluster comme la réplication est gérée à un niveau au dessus ?
    * Docker ne fait pas encore de la réplication de volume, il faut passer par un driver... Lequel me conseillez vous ?
Pour le load balancing, je pense mettre un container HAProxy sur chaque serveur pour faire du load-balancing.
Chaque IP de chaqu'un des hosts aura une entrée DNS pour encore faire du load-balancing sur une couche au dessus en round-robin.

Problème, après la résolution DNS, si une IP d'un host est down, le navigateur ne tente pas d'accéder à une autre IP, je dois retirer l'entrée en fonction de la disponibilité depuis le serveur DNS avec un TTL très bas.
Connaissez vous une solution, dockerizé si possible pour modifier les entrées DNS Bind d'un NDD en fonction de la disponibilité d'un host ? Ou dois-je faire un script pour modifier à la main avec nsupdate par exemple ?
J'ai vu aussi que OVH propose de faire de l'IP loadbalancing pour load balance sur mes IP en fonction de la disponibilité de mes hosts mais j'aimerais éviter de payer en plus 10€/mois pour une infra perso.

J'ai besoin de votre avis et de vos retours d'expérience sur vos clusters.
Merci
Salut,

J'ai justement bossé sur un dossier similaire il y a peu de temps. En l’occurrence mon client avait besoin d'un cluster (100To) pour faire tourner des VM/CT, c'est pas exactement ton cas mais je te partage ma maigre expérience. Je me doute que d'autres, dont c'est le cœur de métier, seront plus complets

J'ai employé GlusterFS. D'une parce que je l'avais déjà utilisé, de deux parce qu'il voulait du chiffrement et que c'est avec ce système que j'ai compris le plus vite comment m'y prendre...

Niveau file storage je dirais que tout dépend de ce que tu veux en majorité y mettre. Si ce sont plutôt de gros fichiers (BDD, VM/CT, vidéos etc) autant partir sur du block, plus fiable, plus rapide. Si au contraire tu comptes stocker masse .odt/.pdf/.mp3 (tu vois le genre) alors là je pense que le file system sera plus adapté.

Faut aussi penser à louer tes serveurs dans des DC pas trop éloignés (ie PAS Canada/Roubaix). Sinon pour la réplication tu vas pleurer en voyant la vitesse...

Concernant le lag, avec seulement 2 machines en effet tu va ressentir des effets sur l'ensemble du cluster. Avec 4 et + si un bloc est HS ça va peut-être ajouter une latence de quelques secondes le temps que les clients assimilent qu'il n'est plus là et continuent leur job avec ceux qui restent.
Le problème c'est que dans ton cas de figure tu pars sur seulement 2 serveurs. D'ailleurs est-ce que le clustering est la solution qu'il te faut ? Pourquoi pas plutôt de la duplication via rSync ?
Merci pour ton retour.

Je n'ai pas de grosses base de données, plutot beaucoup de fichiers qui prennent de la place et des fichiers vidéos d'~5Go donc je pense que le file system serait le plus adapté à ma situation et gluster à l'air simple à mettre en place. Mais si j'utilise quand même le block storage, ça risque vraiment d'impacter les performances ? Je pourrais utiliser le block storage pour split mes données en plusieurs blocks virtuel avec le file system de mon choix...

Mes données ne sont pas d'une criticité extrème, j'hébergerais dans 2 mêmes DC.

Alors, encore, dans mon cas Rsync peut être suffisant mais je choisirais quand même le clustering parce que j'ai envie d'apprendre. Mes choix seront peut être overkill mais au moins j'aurais testé la solution dans le cas ou j'en aurais besoin dans un cas concret.

Pour mon cluster j'aimerais qu'il soit le plus portable possible pour pouvoir changer de machine rapidement et ne pas refaire toute la configuration à chaque fois (encore une fois overkill je l'avoue). Genre seulement le Docker Engine et quelques règles sur le pare feu sur chaque host à configurer à la main tout le reste c'est des DockerFile.
Pour le stockage, je suis obligé d'installer le daemon Gluster sur chaque machine à la main. L'idéale serait de stocker les données dans des containers qui se répliquent entre eux. J'avais trouvé BlockBridge qui était la solution idéal, mais je n'ai pas réussi à mettre en place (ça bug).

Peut être que je suis trop exigeant ou il existe des solutions à mes problèmes ?
tounefr wrote:Je n'ai pas de grosses base de données, plutot beaucoup de fichiers qui prennent de la place et des fichiers vidéos d'~5Go donc je pense que le file system serait le plus adapté à ma situation et gluster à l'air simple à mettre en place. Mais si j'utilise quand même le block storage, ça risque vraiment d'impacter les performances ?
Je ne pense pas que ça se remarque beaucoup, à moins que tu ne traitent beaucoup de petits fichiers très souvent. Et en te relisant je vois que ta SB, la plus encline à générer des I/O de la sorte, ne sera pas répliquée. Donc "osef"

tounefr wrote:Mes données ne sont pas d'une criticité extrème, j'hébergerais dans 2 mêmes DC.
Alors, encore, dans mon cas Rsync peut être suffisant mais je choisirais quand même le clustering parce que j'ai envie d'apprendre. Mes choix seront peut être overkill mais au moins j'aurais testé la solution dans le cas ou j'en aurais besoin dans un cas concret.
Avec la 1ère phrase je t'aurais encore conseillé rSync 😛 Mais je comprends, je ne suis pas non plus le dernier à vouloir tester tout plein de trucs !

tounefr wrote:J'avais trouvé BlockBridge qui était la solution idéal, mais je n'ai pas réussi à mettre en place (ça bug).
Je ne suis pas assez calé sur Docker pour t'en dire plus
J'ai mis en place GlusterFS sur 2 serveurs Kimsufi (l'un en France, l'autre au Canada, je me suis trompé à la commande :S).
Malgré la distance, j'ai quand même de bons débits en faisaint un dd en ssh (j'atteinds les 100mbits) mais la réplication avec gluster est lente même en transferant de gros fichiers (30mbits max pour de gros fichiers, sinon quelques kbits).
As déjà tu eu ce problème Aerya avec ton expérience avec Gluster ?
Pas avec Gluster mais rSync. J'ai jamais testé Gluster sur des serveurs dans des zones différentes
Répondre…