Je pense actuellement à migrer certains de nos serveurs et applications vers un environnement coreOS . L'un des problèmes que je vois ici est la gestion des données persistantes car coreOS ne gère pas les volumes Docker lors du déplacement d'un conteneur vers une nouvelle machine. Après quelques recherches, j'ai trouvé glusterFS qui prétend être un système de fichiers en cluster qui pourrait résoudre tous mes problèmes.
Mon idée actuelle est la suivante: j'ai un conteneur glusterFS qui fonctionne comme un conteneur privilégié sur chacune de mes machines coreOS et expose un stockage /mnt/gluster, par exemple. Dans mon Dockerfiles je précise que tous mes volumes doivent être montés sur ce chemin.
La prochaine chose que j'ai envisagée était de savoir quels conteneurs devraient obtenir leurs propres volumes et lesquels devraient en partager un. Par exemple, chaque mysqlconteneur obtiendrait son propre volume car il est capable de gérer lui-même la réplication. Je ne veux pas jouer avec ça. Les serveurs Web qui desservent le même site Web utiliseraient correctement le même volume pour des choses comme les «images téléchargées par les utilisateurs», etc., car ils ne sont pas en mesure de reproduire ces données.
Quelqu'un a-t-il essayé quelque chose comme ça ou y a-t-il quelque chose que j'ai manqué?
Réponses:
Nous avons déployé une configuration similaire avec Atomic ( http://www.projectatomic.io/ ) au lieu de CoreOS sur un système de stockage GlusterFS non distribué répliqué avec trois jeux de réplicas-2. Cela fonctionne très bien.
Cependant, vous devez garder à l'esprit quelques caractéristiques spéciales de GlusterFS. Comme Brian l'a déjà mentionné, Gluster place la cohérence et la fiabilité avant tout. Plus les changements se produisent fréquemment, plus la réplication se produit. Cela met beaucoup, et je veux dire BEAUCOUP, de pression sur votre système.
Assurez-vous que votre sous-système d'E / S est rapide (duh, c'est du stockage), connectez vos nœuds Gluster avec les connexions réseau les plus rapides disponibles. Si vous n'avez que GBit, agrégez! Enfin et surtout, le système de stockage doit être doté d'une puissance de calcul sérieuse, Gluster fait beaucoup de calculs pour vérifier son état. Cela dit, même sous forte charge, Gluster tient ses promesses.
Repensez votre stratégie MySQL. Gluster effectue la réplication pour vous et fournit également une sorte d'équilibrage de charge lors de la livraison. Il pourrait être plus rapide d'utiliser Gluster.
la source
L'utilisation de glusterfs dépend du backend de stockage que vous utilisez. En tant que système de fichiers en cluster, il est destiné à regrouper le stockage physique afin qu'il apparaisse comme un grand volume continu. Ce guide de démarrage rapide officiel contient une bonne explication du processus.
Dans le cas où votre configuration utilise deux ou plusieurs serveurs de stockage backend séparés ou quelque chose de similaire pour stocker tous les volumes de docker, l'utilisation de glusterfs ou d'un autre système de fichiers parallèle similaire peut offrir des avantages de performances significatifs. Si tel est le cas, vous pouvez également envisager d'utiliser Luster , qui est largement utilisé comme système de fichiers parallèle dans la communauté HPC.
Cela étant dit, le réglage, le débogage et la configuration des systèmes de fichiers parallèles / cluster peuvent être une tâche longue qui nécessite beaucoup d'expertise, de patience et parfois une volonté de redémarrer depuis le début. Il serait prudent de s'assurer que les avantages en termes de performances d'une offre de système de fichiers parallèle valent la quantité d'efforts requis pour le configurer et le maintenir.
la source