Bonsoir nal,
FAImaison, membre de la fédération FDN, commence à avoir du matériel suite à des dons (tellement que l'on va pouvoir en donner à d'autres membres de FDN).
Les services de FAImaison exigent une plus grandes souplesses ainsi qu'une meilleur évolution.
A ce jour, il y a 2 serveurs qui fonctionnement en redondance(manuel) grâce à DRDB, donc pas d'évolution possible.
L'objectif de ce "draft" est de travailler sur l'évolution de infrastructure technique (une approche d'hyperconvergence) pour 2018 et au-delà.
La première étape est la mise en place d'un draft pour définir les besoins ainsi que les technologies stockage (SDN: Software Define Storage) à mettre en œuvre.
Objectif de la démarche:
Fournir des machines virtuelles sécurisées (données sur des volumes en RAID), répliquées (sur site ou sites distants) et sauvegardées (sur site ou sites distants)
Les besoins techniques:
- Sécurisation des données en mode RAID sur les disques physiques d'un serveur ou sur plusieurs serveurs physiques (l'unité de départ de la solution est 1 serveur et non 3).
- Réplication des blocs selon différent niveau de RAID (1, 10, 6) sur un même serveur.
- Réplication des blocs selon différent niveau de RAID (1, 10, 6) sur plusieurs serveurs de la même zone.
- Réplication des blocs selon différent niveau de RAID (1, 10, 6) sur plusieurs serveurs de la même zone.
- Réplication de VM sur une ou plusieurs zones.
- Sauvegarde de VM sur une ou plusieurs zones.
- Support des snapshots, thinprovisionning, déduplication, compression.
- Pas de JAVA.
Les besoins fonctionnels:
L'idée est de gérer des zones/sites sur lesquelles l'on définit des niveaux de sécurisation des données.
Cela veut dire que l'on peut définir le niveau de service par VM (VM sécurisées (RAID), VM répliquées sur n-site, VM sauvegardées sur n-site).
Les techniques:
Il existe une solution propriétaire: Symplivity
Mais je pense qu'il existe des solutions opensources (CEPH, ROZOFS, XOSAN, etc.).
L'idée de cet appel à commentaires et de faire ressortir les solutions existantes puis de les évaluer.
Merci de vos retours ou questions
Je sais que l'on cherche la solution miracle mais nous ne sommes pas pressés pas le temps.
Certains membres de FFDN ont des solutions de stockages distribués avec une solution de sauvegarde à coté. Mais l'idée est d'avoir tout en un.
# Openstack ?
Posté par Bruno (Mastodon) . Évalué à 1.
A vérifier toutefois pour la question des niveaux de services.
[^] # Re: OpenNebula ou Proxmox ?
Posté par tetraf . Évalué à 2.
Plus simple à mettre en place et à maintenir : https://opennebula.org/
Proxmox offre un poil moins d'abstraction à l'utilisateur mais est très bien aussi : https://www.proxmox.com/
Les deux permettent d'utiliser Ceph.
# OpenIO
Posté par Tonio (site web personnel) . Évalué à 2.
On m'a donné l'info sur OpenIO: un SDS
# Glusterfs / Proxmox
Posté par root_rtfm . Évalué à 1.
Bonjour,
Glusterfs est similaire à ceph, il permettrait d'avoir une réplication sur 1 ou plusieurs nœud en local et à distance (géoréplication).
Proxmox a déjà été cité plus haut, il permet la gestion de vm sur 1 ou plusieurs serveurs en cluster.
Cdlt
[^] # Re: Glusterfs / Proxmox
Posté par claudex . Évalué à 5.
GlusterFS me semble plus adapté à des petites infra (quelques nœuds pour la réplications) alors que Ceph me semble plus adapter quand on a beaucoup de nœuds.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Glusterfs / Proxmox
Posté par aplc (site web personnel, Mastodon) . Évalué à 2.
Jusqu'à la prochaine version GlusterFS supporte jusqu'à 128 noeuds maxi. Ça laisse de la marge et la prochaine version arrive en 2018. Ici [1], ils ont fait un test avec 84 noeuds.
Sinon, pour bien fonctionner, CEPH demande une base de 7 serveurs physiques là ou Gluster peut démarrer sur un seul serveur. Par ailleurs, CEPH est plus approprié pour un mode objet ou bloc là où Gluster est mieux pour du bloc et du fichier.
[1]http://www.gluster.org/gluster-scale-out-tests-an-84-node-volume/
[^] # Re: Glusterfs / Proxmox
Posté par Misc (site web personnel) . Évalué à 2.
7 serveurs physiques, ça me parait un chouia trop. Tu peux t'en sortir avec moins si tu mets les OSD et les moniteurs sur les mêmes machines, en partant du principe que tu as dimensionné ça de façon à ce que ça passe (genre, avoir un disque, asse de ram et un CPU par OSD, et donc un CPU et assez de ram pour le moniteur, avec "assez" documenté sur ceph.com).
Ensuite, ça dépend aussi de la topologie réseau que tu va mettre des patterns d'accès, de la volumétrie, des perfs que tu veux avoir.
[^] # Re: Glusterfs / Proxmox
Posté par Framasky (site web personnel) . Évalué à 2.
Chez Framasoft, on a 4 OSD sur 2 serveurs différents (2 serveurs x 2 OSD), et 3 monitor (un sur chaque serveur qui contient les OSD + une VM) et ça tourne très bien.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Glusterfs / Proxmox
Posté par MTux . Évalué à 5.
Hm, Gluster fait de la répli niveau block ? Il me semble que c'est au niveau fichiers uniquement.
Sinon ouais Ceph, mais il faut une grosse infra (3 serveurs bien dimensionnés) et il faut savoir faire face en cas d'incident car dans mon expérience c'est très résilient (on a jamais perdu de données) mais au niveau continuité de service c'est pas trop ça (des petits incidents qui n'auraient pas du avoir d'impact mais qui font tomber le cluster).
[^] # VM obligatoire ?
Posté par Tangi Colin . Évalué à 1.
Une solution a base de VM est obligatoire ou une solution à base de conteneur pourrait être envisagé ? Si on peut faire du conteneur à la place soit Kubernetes soit Mesos (j'ai un penchant perso pour Mesos).
Coté storage soit ceph soit gluster comme déjà évoqué. Glusterfs niveau performance c'est pas la panacée surtout quand tu es sur beaucoup de petits fichiers. Ceph j'ai jamais pu l'expérimenté il me semble plus intéressant mais aussi plus lourd à mettre en place.
[^] # Re: VM obligatoire ?
Posté par TutoMaker . Évalué à 1.
L'un de vous a-t-il testé une des nombreuses alternatives? (ou vous citez juste des noms de logiciel lu sur google?)
Si vous codez un logiciel sans une interface chatoyante, alors vous faites de la merde. Donation bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: VM obligatoire ?
Posté par MTux . Évalué à 2. Dernière modification le 24 octobre 2017 à 17:18.
Testé les 2
Utilisés actuellement en prod même
[^] # Re: VM obligatoire ?
Posté par TutoMaker . Évalué à 2.
N'hésites pas à partager ton retour d'expérience, je suis en train de faire un article pour comparer les différentes alternatives (car je souhaite passer de glusterfs que je trouve beaucoup trop buggé à autre chose mais je ne sais pas encore quoi).
Si vous codez un logiciel sans une interface chatoyante, alors vous faites de la merde. Donation bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: VM obligatoire ?
Posté par Tonio (site web personnel) . Évalué à 2.
Très bonne idée, cette comparaison des solutions.
Je suis intéressé pour voir le document quand il sera disponible
[^] # Re: VM obligatoire ?
Posté par TutoMaker . Évalué à 0.
Il risque hélas de rester brouillon durant encore quelques mois (je dois tout installer/tester à la mano, ça prend pas mal de temps *1)
Mais promis quand il sera terminé je le signalerai sur LinuxFR.
*1 et a part Mtux ci-bas, quand je demande des retours d'expérience je me tape des gros vides :D
Si vous codez un logiciel sans une interface chatoyante, alors vous faites de la merde. Donation bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: VM obligatoire ?
Posté par MTux . Évalué à 3.
On bosse avec de vielles versions de gluster et on en est plutôt contents. C'est très résilient, on a jamais perdu de données. C'est pas trop lourd pour les serveurs, ils peuvent même faire office de brick+client "croisés" (pas besoin d'un nas dédié, même si c'est quand même plus propre). On a juste eu des problèmes la fois où on a voulu connecter un client récent à un vieux serveur: tout le cluster est tombé, moralité il faut utiliser les mêmes versions partout. Mais sinon c'est solide.
On utilise Ceph pour stocker des VMs sur une ferme d'hyperviseurs Xen. Ça nécessite du lourd, minimum 3 serveurs avec beaucoup de RAM (8GB mini) et des SSD pour le journal. L'architecture Ceph est beaucoup plus complexe que Gluster et en cas de pépin il faut savoir s'en sortir. Au niveau intégrité des données nous n'avons jamais eu de soucis, par contre nous avons déjà eu 2 incidents qui ont fait tomber le cluster alors qu'un gluster aurait tenu. Nous avons aussi un bug qui fait gonfler les nodes en ram, c'est visiblement un souci upstream et nous attendons un correctif (bon c'est pas trop critique, il y a 1 petite commande à faire pour vider la ram sans devoir redémarrer).
Sinon comme on l'a déjà dit, Gluster c'est pour du stockage fichiers alors que Ceph c'est block (bien qu'il existe CephFS, mais je n'ai jamais testé).
[^] # Re: VM obligatoire ?
Posté par TutoMaker . Évalué à 0. Dernière modification le 29 octobre 2017 à 13:59.
Je n'ai pas encore testé Ceph (la longueur des tutos démotive) mais il a l'air de nécessiter beaucoup beaucoup beaucoup plus de ressources machine que GlusterFS.
As-tu testé GlusterFS en WAN ? (j'ai testé dernièrement, tellement lent qu'apache2 n'arrivait pas a fonctionner correctement)
Les replica 3 arbiter 1 fonctionnent chez vous?
Les nœuds n'ont jamais de soucis de reconnexion?
Quelqu'un aurait un/des retour(s) d'expérience sur les autres alternatives? (MooseFS, OrangeFS, Tahoe-LAFS, etc)
Si vous codez un logiciel sans une interface chatoyante, alors vous faites de la merde. Donation bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: VM obligatoire ?
Posté par MTux . Évalué à 2.
On ne bosse qu'avec deux serveurs donc en replica 2, et en LAN. Pas de souci de reconnexion.
Par contre dans les dossiers contenant de très nombreux fichiers il y a quelques latences, notamment pour ls.
[^] # Re: VM obligatoire ?
Posté par TutoMaker . Évalué à 2.
Vous n'avez pas peur du split brain? (surtout sachant qu'il arrive que les peers glusterfs, bien qu'en ligne, soient marqué comme Disconnect quand on lance gluster peer statu (j'ai ce bug depuis le début que je testé glusterfs soit deux bonnes années, et autant sur ubuntu que raspbian))
Il se passe quoi encore si un des deux serveurs tombe en panne durant quelques heures (j'ose pas faire le teste par peur d'encore péter mon raid).
Si vous codez un logiciel sans une interface chatoyante, alors vous faites de la merde. Donation bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: VM obligatoire ?
Posté par MTux . Évalué à 2.
Nous n'avons jamais eu de split brain.
C'est arrivé qu'un serveur tombe, quand il remonte il se reconstruit. Et nous n'avons jamais eu de peer offline.
Mais oui dans l'idéal ce serai sûrement plus sûr d'en avoir 3.
[^] # Re: VM obligatoire ?
Posté par root_rtfm . Évalué à 0.
Proxmox et gluster en prod
[^] # Re: Glusterfs / Proxmox
Posté par Misc (site web personnel) . Évalué à 2.
Il suffit de répliquer les images de VM stocké sur le disque.
[^] # Re: Glusterfs / Proxmox / VM oui
Posté par Tonio (site web personnel) . Évalué à 1.
Je cherche surtout une solution au niveau bloc pour des VM.
Pour du stockage objet, il y a des "trucs" sympa actuellement…
[^] # Re: Glusterfs / Proxmox / VM oui
Posté par TutoMaker . Évalué à 0.
Je n'ai pas testé : gluster-block
Si vous codez un logiciel sans une interface chatoyante, alors vous faites de la merde. Donation bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
# Les retours de GitLab
Posté par Anonyme . Évalué à 4.
Pour info (même si c’est pas forcément comparable dans l’utilisation et la volumétrie), il y a quelque temps GitLab s’est posé la question de quitter le cloud pour du bare-metal et au vu des retours de la communauté (« vous êtes dev, l’infra c’est pas votre métier et c’est très cher »), ils sont revenu en arrière :
[1] https://about.gitlab.com/2016/11/10/why-choose-bare-metal/
[2] https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-the-cloud/
Ils pensaient aussi utiliser CEPH pour le stockage.
[^] # Re: Les retours de GitLab
Posté par mathgl . Évalué à 2.
Ils ont utilisé CEPHFS pendant un moment avant de retourner sur du NFS. C'était peut-être pas le meilleur moment.
CEPH est plus mûre pour les machines virtuelles (via RBD) que en tant que système de fichiers…
# ça manque de données
Posté par Misc (site web personnel) . Évalué à 4.
Le draft manque AMHA d'info.
Par exemple, ça parle de réplication, mais est ce que l'idée est d'avoir une réplication en temps réel (et donc synchrone) auquel cas les performances vont chuter si tu fait ça sur un site distant, ou d'avoir des trucs asynchrones et de la magie pour revenir quand ça explose ?
Il n'y a pas spécialement de discussion sur la volumétrie non plus ou la question du lien entre les sites.
Le type de données va aussi importer. L'utilisation de GlusterFS pour stocker des images de VM fait parti des cas supportés par le projet (vu que c'est des gros fichiers, ç'est assez performant), et le projet ovirt le supporte. Mais de la même façon, des gens placent le stockage en mode bloc dans Ceph.
Mais si le but est d'avoir des machines dont tu fait des snapshot, je pense que tu peux pas éviter d'aller dans la VM et faire des choses pour que les données sur le disque soit cohérentes.
J'ai par exemple du mal à voir comment une synchro des blocs ne va pas corrompre une base de données et une appli web si ça pête au mauvais moment, vu que c'est rarement atomique (sauf à tout mettre dans la base de données, et à avoir des transactions, mais je pense que pas grand monde vérifie ça, et qu'à choisir entre une appli qui va exploser sous un cas critique, et pas d'appli, les gens prennent l'appli quand même).
Du coup, si tu fait la redondance au niveau au dessus, tu as moins besoin au niveau en dessous.
Donc les besoins vont dépendre des applis. Est ce qu'il faut avoir de la HA automatique, ou remonter rapidement suffit ? Comment le systéme va devoir se débrouillé en mode dégradé ?
Pour reprendre l'appli d'exemple de toute à l'heure, une solution de stockage classique avec une base SQL répliqué suffirait, avec des frontends sans état, pas besoin de sortir des trucs complexes (pour peu que les VMs soit identiques)
Et sinon, on est en 2017, les archis à base de conteneurs ont le vent en poupe, et ont le bon gout de pousser à séparer données et codes, ce qui permet aussi de se focaliser sur ce qui AMHA importe, les données. Je dit pas que c'est une bonne idée, mais je pense que c'est pas déconnant de regarder. Et pas regarder docker tout nu, plus des choses comme kubernetes/openshift ou mesos, avec idéalement une stack supporté.
Et la partie "pas de java" me parait quand même restrictive et sans doute mal exprimé. Parce que je suis sur que pour certaines choses, y a sans doute d'autres languages qui vont faire pire que java (cough golang et rust pour du statique, ruby pour tirer 5T de deps), donc je suis sur qu'il y a plus précis comme demande.
[^] # Re: ça manque de données
Posté par Tonio (site web personnel) . Évalué à 1.
Merci pour ces questions
Effectivement je n'ai pas détaillé certains points pour éviter d'alourdir le draft mais qui auraient contribué à la compréhension.
Pour la sécurisation des données, il y a plusieurs niveaux:
Tout d'abord, au niveau local il peut y avoir une sécurisation des données grâce à du RAID (dans la machine ou dans sa grappe de serveur). Cette méthode est synchrone. C'est une obligation pour s'assurer de la sécurisation des données.
=> Le HA est assurée pour la réplication synchrone des VM (données) ainsi que les accès des serveurs physiques aux volumes contenant les VM.
Entre site, la réplication des VM ne se fera qu'en asynchrone. Pour la réplication, le plus simple est de faire un snapshot de la VM puis de la répliquer.
=> Le PRA peut être assuré, vu que données ont été répliquées dans un mode consistant.
Pour la partie conteneur, je suis d'accord avec cette approche. Nous allons y travailler. Mais aussi permettre aux membres d'assurer eux-même leur plan de reprise/sauvegarde.
L'idée est de proposer différents niveaux de services et de besoins:
- VM de sauvegarde sans réplication l'espace de stockage
- VM dans l'espace de stockage avec sécurisation locale
- VM dans l'espace de stockage avec sécurisation locale + réplication distante
- VM dans l'espace de stockage avec sécurisation locale + réplication distante + sauvegarde distante
Pour les conteneurs, cela sera sur des VM(ou non) sur un espace de stockage avec sécurisation locale.
Je suis d'accord pour les langages de programmation. Je connais quelques solutions en JAVA qui ont de bonnes fonctionnalités mais qui sont difficilement 'extensible'.
[^] # Re: ça manque de données
Posté par oau . Évalué à 2.
Bonjour,
vraiment regarde du coté de ceph. Ça fait tout ce dont tu as besoin et ça marche vraiment bien. 2ans que j'ai deux cluster ceph et aucun problème.
Ma prod est à cheval sur les deux cluster :
4 front web. 2 sur le cluster cephA et 2 sur le cluster cephB.
2 serveurs d'application python 1 sur le cluster cephA et 1 sur le cluster cephB.
2 serveurs de base de données (pg) en réplication. Un sur le cluster cephA et l'autre sur le cluster cephB.
Le tout en mode bloc avec rbd et pas de raid. Plus jamais. La resync d'un cluster de 2to prend quelques minutes et n'a encore jamais échoué. Alors que combien de fois j'ai vu un raid1 ou 5 mourir pendant sa reconstruction. Reconstruction dramatiquement lente. Surtout en raid5
Ensuite j'ai un cluster cephC de drp sur lequel je synchronise les images des vm avec un délais avec rbd-mirroring.
Mes vm sont en ha avec pacemaker.
Ça marche vraiment bien. Le seul inconvénient que je vois c'est que un cluster ceph c'est minimum 3 machines et que du 10G pour le réseau est recommandé.
Ce que j'ai fait c'est que j'ai pris des machines chez ovh avec 2 disk et chacune de mes machines est à la fois dans le cluster cephA et cephB. Oui Si je perds une machine je "casse" mon cluster ceph mais si j'ai une corruption sur un cluster j'ai toujours l'autre. Le jour ou je serais riche j'aurais plus de machine :). Bien sur le tout est backup avec borg toutes les heures sur le nfs d'ovh.
Ceph c'est bien vraiment.
[^] # Re: ça manque de données
Posté par Tonio (site web personnel) . Évalué à 1.
Merci pour ce retour
Je crois que l'on va commencer avec des baies de stockage que nous avons récupérer puis réaliser des maquettes pour valider la meilleur solution.
Mais l'on va sérieusement regarder CEPH.
[^] # Re: ça manque de données
Posté par Psychofox (Mastodon) . Évalué à 2.
Je ne vois pas bien le rapport tu parles de deux choses qui n'ont rien à voir entre elles.
[^] # Re: ça manque de données
Posté par oau . Évalué à 1.
il peut utiliser ses baies de stockage pour faire du ceph. Avec un osd par disk. Sans raid. C'est un peu l'idée de ceph. Utiliser tout et n'importe quoi pour stocker des données. Ensuite il faut faire attention à pas trop déséquilibrer les clusters.
[^] # Re: ça manque de données
Posté par Misc (site web personnel) . Évalué à 2.
Le RAID, j'ai pas tendance à voir ça comme une sécurité des données plus que s'assurer de la disponibilité et que l'uptime ne prends pas un coup si un disque tombe (en partant du principe que tu as un niveau de raid différent de 0). Parce que le RAID sécurise pas vraiment contre un effaçage par erreur ou contre un bug du FS :/
En fait, j'ai vraiment tendance à ne pas aimer qu'on parle de sécurisation sans dire "contre quoi", parce que ç'est indispensable pour savoir ce qui manque, surtout si c'est à destination des membres, qui vont pas forcément avoir le réflexe de penser "ok, qu'est ce qui se passe si tel truc arrive".
Plus simple oui, mais je suis pas sur que ça marche à 100%. Encore une fois, tu peux avoir le disque dans un état non consistant. Et ça, c'est quand tu as pas des données sur plusieurs disques (exemple, un serveur sql partagé et X serveurs webs avec des applis différentes), parce que ça devient vite compliqué Ensuite, je donne le pire cas possible, il est possible que ça marche suffisamment bien et que tu puisses corriger à la main le reste du temps (e.g, aller tripoter dans la DB si besoin), donc je suppose qu'il ne faut pas faire une usine à gaz.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.