Bonjour,
Voici une réflexion à voix haute, dans l'espoir d'attirer l'attention de ceux qui maîtrisent certains des points abordés ci-dessous.
Depuis des années, nos répertoires partagés sont servis par des serveurs Samba, montés en cluster via CTDB, formatés en OCFS2.
Le tout tourne sur des Oracle Linux 6 ou des CentOS 6 et ça fonctionne plutôt bien (zéro corruption de données, pas de souci de locking, performances moyennes mais suffisantes, bonne résilience).
Aujourd'hui, je tente de moderniser tout ça selon les réflexions suivantes :
- Passer sur une version 7 de RHEL/OL/CentOS/Fedora…
- Passer à Samba 4.x
- Questionner la pertinence d'OCFS2
Le passage à la version 7 et systemd ainsi que Samba 4 ne pose pas de problème.
La dernière version d'OCFS2 semble assez ancienne, et ne semble plus évoluer depuis 2011.
Le choix d'OCFS2 pour gérer des fichiers partagés vient du besoin suivant : un (en réalité plusieurs) gros LUN contenant des données, et plusieurs serveurs samba qui y accèdent simultanément. En cas de panne d'un serveur Samba, CTDB assure de manière transparente le bon fonctionnement des Samba vivants.
Il s'avère que CTDB nécessite en plus un dossier partagé privé accessible simultanément ("recovery lock file") par chacun des nœuds du cluster, formaté dans un système de fichiers supportant les posix locks.
Dans notre cluster actuel, ce point de montage est formaté en GFS2, car c'est le seul que j'ai trouvé qui supporte les PLOCKS. (GPFS - payant, les supporte aussi, mais voilà, c'est payant).
Afin de limiter la profusion de technos impliquées, j'ai tenter de virer GFS2 et de formater mon espace de PLOCKS en OCFS2 mais cette vieillerie ne les supporte pas. Bref, je vais devoir remettre en place GFS2 et son cortège de DLM, Corosync, cman et autre heartbeateries, et j'avoue que je cache ma joie :(
Ce qui me fait m'exprimer ici est une interrogation sur ce que font les autres :
- Ressentez-vous le besoin de clusteriser Samba ou autre serveur de fichiers ?
- Ou assumez-vous le fait de pouvoir perdre un moteur de serveur de fichiers ?
- Ou avez-vous dupliqué les données, et donc les moteurs ?
Je pourrais passer sur du GlusterFS, ce qui assure la redondance des moteurs, mais implique aussi la 3 x duplication des données, ce qui est presque impossible en terme de volume (et de perfs).
Pour les windowsiens, certains utilisent DFS non seulement en temps que vitrine d’arborescence, mais également comme outil de duplication.
Nous ne l'utilisons que comme vitrine, la duplication de données étant trop coûteuse.
Bref, je suis intéressé par vos façons de faire et vos remarques.
# Essentiel
Posté par Nico C. . Évalué à 4.
Elles sont interessantes tes questions :
Mais ça suppose de revenir à l'essentiel de ton problème :
Sans ça, c'est difficile de te dire si tu fais bien ou pas de t'emmerder avec tout ce bazar…
[^] # Re: Essentiel
Posté par Nicolas Ecarnot (site web personnel) . Évalué à 3.
Bonsoir,
D'abord, merci pour l'accueil que vous avez réservé à mes questions, et merci pour vos réponses.
En terme de volume, on sert une quinzaine de teras de données.
En terme de perfs, on est vraiment très tolérants. On ne mesure pas vraiment car le besoin n'existe pas.
En terme de RTO, j'avoue qu'on ne se pose pas vraiment la question en terme de délais, mais plus simplement, on souhaite automatiser au maximum de sorte à éviter toute intervention humaine lors du recovery.
D'où le choix du cluster actif/actif dès que possible, avec systématiquement du STONITH.
Pour l'instant, ce choix s'est avéré judicieux, et de nombreux crashs (dû à des facteurs externes - pannes elec, saturation réseau, erreurs humaines…) sont passés inaperçus aux users grâce à de tels mécanismes.
Au sujet de Gluster et du replica-3, il est en effet possible de désigner l'un des nœuds comme simple arbitrer : ce nœud se contentera de stocker les meta-données et jouera son rôle de juge de paix en cas de split-brain, mais il n'hébergera aucune données. L'un de nos clusters est construit ainsi, mais j'avoue ne l'avoir par torturé autant que notre cluster OCFS2 pour en dire autant de bien.
Je reste surpris que la clusterisation des serveurs de fichiers ne soit pas davantage systématique, et qu'on évoque des délais de restauration quand j'imaginais concentrer la question sur l'implémentation de solution active/active à base de logiciel libre.
Vos utilisateurs sont-ils plus tolérants que les miens ? (J'en doute)
[^] # Re: Essentiel
Posté par Psychofox (Mastodon) . Évalué à 4.
Réponse D: Ça fait belle lurette que je n'ai plus vu de vrais serveurs de fichier avec nfs/cifs. Dans les 4 dernières boites pour lesquelles j'ai bossé on utilisait/utilise des solutions de stockage proprio style netapp/datadomain.
[^] # Re: Essentiel
Posté par Firwen (site web personnel) . Évalué à 2.
Des solutions proprétaires qui de toute façon donnent des interfaces NFS / CIFS / S3 / (GPFS pour les riches) et qui ont généralement les même tares techniques que les protocoles associés.
Donc ça ne change pas grand chose au final.
# GlusterFS
Posté par EauFroide . Évalué à 1.
Pourquoi 3x?
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: GlusterFS
Posté par Nico C. . Évalué à 2.
Parce que les noeuds GlusterFS vont par 3 pour empêcher les "split-brain". Par contre, je suis pas certain qu'il soit nécessaire de dupliquer autant de fois les données.
Il me semble qu'il existe un mécanisme "d'Arbiter" qui possède une voix dans l'élection du nouveau maitre (après incident sur un noeud) sans faire partie "fonctionnellement" du cluster et donc sans copie des données.
[^] # Re: GlusterFS
Posté par EauFroide . Évalué à 1.
Si tu as un peu de temps, aurais-tu l'amabilité de détailler stp? (j'ai du mal à digérer la documentation de glusterfs qui est volumineuse et uniquement anglophone ^ ^ )
En effet tu peux spécifier le nombre de redondance que tu souhaites avec le paramètre "replica x" ou x est le nombre de copie à maintenir (actuellement je l'utilise en JBOD que j'espère convertir en raid10 quand la thune suivra :P )
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: GlusterFS
Posté par Nico C. . Évalué à 10. Dernière modification le 26 juin 2017 à 18:45.
Un "split brain" arrive quand les 2 noeuds d'un cluster actif-actif sont toujours UP mais c'est le lien réseau entre les 2 (qui leur sert pour les synchro) est rompu. On se retrouve dans ce cas avec potentiellement des données neuves (mais différentes) sur les 2 noeuds à la fois car chaque noeud se croit maître du cluster et avec une impossibilité pour les réconcilier.
Pour régler ce problème, il y a plusieurs méthodes :
- le STONITH (“Shoot The Other Node In The Head”) qui part du principe que tu disposes d'un système de monitoring externe capable de prendre la décision d'arrêter aussi vite que possible un des 2 noeuds le temps que le système de syncho soit de nouveau UP. Solution de bourrin, pas toujours très efficace et assez risquée au final car si le monitoring se trouve lui-même isolé, c'est la merde.
- Ne pas faire de cluster actif-actif mais actif-passif comme la plupart des bases de données relationnelles le conseillent. La bascule se fait de préférence manuellement après diagnostique de la situation. C'est lent, pas automatique mais l'intégrité des données est garantie du moment que les admins font bien leur boulot et suivent les procédures.
- Mettre en place un 3e noeud (ou plus du moment que le total est impair) et laisser le cluster procéder à une élection d'un nouveau maitre en cas de panne d'un noeud. Celui qui dispose de la majorité+1 (le "quorum") est le nouveau maitre. Celui qui est minoritaire se place de lui-même en isolement le temps de revoir ses petits copains.
GlusterFS fonctionne avec 3 noeuds. D'autres font pareil comme MongoDB pour donner un exemple très connu mais on pourrait en trouver des tas d'autres encore…
[^] # Re: GlusterFS
Posté par EauFroide . Évalué à 1.
Gros merci :)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: GlusterFS
Posté par EauFroide . Évalué à 1. Dernière modification le 27 juin 2017 à 01:16.
Bon ben voila la réponse :
Note: Volumes using the arbiter feature can only be replica 3 arbiter 1
source : https://gluster.readthedocs.io/en/latest/Administrator%20Guide/arbiter-volumes-and-quorum/#arbiter-configuration
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: GlusterFS
Posté par Mimosa . Évalué à 2.
Que ce soit Ceph ou GlusterFS, les deux gèrent l'erasure code.
Donc pas forcement nécessaire de faire 2x ou x3 en nb de copie.
L’inconvénient étant que l'erasure code est moins performant (plus consommateur en ressource,CPU principalement).
Concernant le mode cluster ou pas (CTDB)… c'est à voir.
Personnellement j'ai une seul VM, avec la possibilité d'en créer une nouvelle très rapidement en cas d'incident sur la 1er.
Je pense que ce point est cependant fonction de plusieurs facteurs (nb d'utilisateur, bande passante, niveau de disponibilité,…)
Si le parc client est majoritairement sous Windows et que vous avez déjà du DFS, ce peut être une solution. Il y a aussi un mode cluster avec SMB sous Windows (utilisé par exemple dans Windows Storage).
Le problème de DFS est qu'il faut répartir des données manuellement (de ce que j'en ai compris) :
un partage sur tel serveur. si plus assez de place, il faut ajouter un serveur pour tel arborescence à la main,… (enfin d'après ma compréhension)
# ceph
Posté par oau . Évalué à 2. Dernière modification le 27 juin 2017 à 08:05.
ceph c'est vraiment bien :). Pour avoir fait du gfs, du gluster et de l'ocfs2 pendant un moment : avec ceph ça marche. C'est tout, et tu peux vraiment faire des trucs sympa avec la crush map. Pour moi c'est LE fs du futur.
[^] # Re: ceph
Posté par SauronDeMordor (site web personnel) . Évalué à 1.
+1
et tu expose le cephfs via samba. tu as une bonne solution, et aussi une bonne tolerance à la panne.
cotes perf c est pas la panacée la couche cephfs à son ovehead mais ca reste bien meilleur que glusterfs.
sinon, je n ai jamais testé mais il y a aussi l exposition de hdfs via nfs (ca ferait hdfs->nfs->cifs)
en regardants du cotes de rados et de samba, je vois aussi quelques trucs (mais j'ai pas d avis sur le sujet).
[^] # Re: ceph
Posté par Nicolas Ecarnot (site web personnel) . Évalué à 4.
Olivier,
Ton expérience m'intéresse, mais il serait bon que tu expliques ce que tu a fait avec GFS, OCFS2 et glusterFS, et ce que tu fais avec Ceph.
Pour avoir fait en prod du GFS2, du Gluster et de l'OCFS2, je vois qu'il y a un grand écart entre ce que ces FS sont censés pouvoir faire, et ce que - en réalité - ils font correctement :
- GFS2 : gère à peu près bien les nuées de petits fichiers, mais les perfs sont décevantes, et fragmente pas mal
- OCFS2 : en formatage "mail", gère bien les petits fichiers, est convenable en terme de perfs, mais finit par fragmenter assez tôt en pourcentage de remplissage de partition
- GlusterFS : est censé gérer aussi bien les nuées de petits fichiers que les très grosses images de VM. En réalité, gère très mal les petits fichiers, gère très bien les images de VM du moment qu'on utilise le sharding.
Je n'ai d'expérience avec Ceph que des tests en labo, donc rien en prod pour pouvoir en parler. Pourrais-tu détailler l'usage que tu en fais et ce que tu as observé ?
Merci.
[^] # Re: ceph
Posté par oau . Évalué à 2. Dernière modification le 28 juin 2017 à 09:41.
J'utilise ceph pour deux choses. Le stockage d'image de vm. C'est relativement simple à mettre en place et ça s'intègre bien avec la libvirt. Il y a plein de fonctionnalité bien sympa, comme les snapshots incrémentaux et la réplication d'image sur une autre cluster. Ensuite je l'utilise pour stocker des tout petits fichiers (quelques octets). J'en reçois des dizaines de millier tous les jours et je les entasse dans ceph sans me poser de question. La j'utilise radosgw et boto en python/django. Ça marche comme swift ou amazon s3. Je n'ai jamais utilisé cephfs encore.
Cependant beaucoup de gens utilisent ceph + nfs avec ganesha qui permet de monter en nfs un pool ceph.
Pour samba ce que j'ai pu en voir l'usage veut qu'un rbd (une image disk) soit créé dans ceph et monté sur le serveur samba qui ensuite le partage.
Concernant les performances jusqu’à présent la limite a toujours été le réseau. Un réseau 10G dédié et vivement recommandé.
Le seul point négatif que j'y vois pour le moment c'est l'architecture minimum qui est un peu lourde. En dessous de 3 machines et 6/8 osd ceph n'est pas très utile.
Concernant gfs je l'ai utilisé en production il y a de très nombreuses années. J'avais trouvé ça très compliqué à mettre en place et pas mal capricieux. Je n'en ai pas un bon souvenir. On s'en servait pour stocker des photos. Beaucoup de photos.
Pour glusterfs j'ai trouvé les perfs pas top et les splitbrain pénible.
J'ai découvert ceph il y a deux ans et j'ai adoré. Vraiment. C'est stable, c'est propre, c'est cohérent et c'est dans debian :)
[^] # Re: ceph
Posté par Firwen (site web personnel) . Évalué à 1.
De mon expérience, GPFS est une hydre à 25 têtes que seul une poignée de sysadmin au niveau mondial comprennent entièrement. Et ils sont généralement employés par des centres HPC ou des banques (autrement dit, des centres où l'argent n'est pas un problème ).
Le restant de ses utilisateurs étant des
(fous)braves sys-admins qui prient pour que la bête se comportent bien et volent vers le support d'IBM quand les choses tournent mal.[^] # Re: ceph
Posté par Dabowl_75 . Évalué à 1.
J'ai quelques années d'utilisation de GPFS, et on s'en servait de manière très basique (banque).
Typiquement pour de la réplication de filesystem en cluster actif/passif.
Et dans ce genre de cas, on n'avait pas peur de grand chose car ça juste marchait.
Il y a deux trois concept à bien appréhender mais dans l'ensemble ça va.
En revanche, il faut faire très attention au timer du dead man switch, parfois il détecte des pannes avant la couche MPIO.
Ce qui peut donner des situations très très étranges où ton noeud se tue et tu ne sais pas pourquoi.
Et c'est lors de la l'analyse du sysdump que tu vois des I/O sans réponse.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.