Nous avons un cluster GlusterFS que nous utilisons pour notre fonction de traitement. Nous voulons y intégrer Windows, mais nous avons du mal à trouver comment éviter le point de défaillance unique qu'est un serveur Samba desservant un volume GlusterFS.
Notre flux de fichiers fonctionne comme ceci:
- Les fichiers sont lus par un nœud de traitement Linux.
- Les fichiers sont traités.
- Les résultats (peuvent être petits, peuvent être assez grands) sont réécrits dans le volume GlusterFS au fur et à mesure.
- Les résultats peuvent être écrits dans une base de données à la place, ou peuvent inclure plusieurs fichiers de différentes tailles.
- Le nœud de traitement récupère un autre travail hors de la file d'attente et GOTO 1.
Gluster est génial car il fournit un volume distribué, ainsi qu'une réplication instantanée. La résilience aux catastrophes est agréable! On aime ca.
Cependant, comme Windows n'a pas de client GlusterFS natif, nous avons besoin d'un moyen pour nos nœuds de traitement basés sur Windows d'interagir avec le magasin de fichiers de manière similaire et résiliente. La documentation de GlusterFS indique que la façon de fournir un accès à Windows consiste à configurer un serveur Samba au-dessus d'un volume GlusterFS monté. Cela conduirait à un flux de fichiers comme celui-ci:
Cela ressemble à un point de défaillance unique pour moi.
Une option consiste à regrouper Samba , mais cela semble être basé sur un code instable en ce moment et donc hors de fonctionnement.
Je cherche donc une autre méthode.
Quelques détails clés sur les types de données que nous diffusons:
- La taille des fichiers d'origine peut aller de quelques Ko à des dizaines de Go.
- La taille des fichiers traités peut aller de quelques Ko à un Go ou deux.
- Certains processus, tels que creuser dans un fichier archive comme .zip ou .tar, peuvent provoquer BEAUCOUP d'écritures supplémentaires lorsque les fichiers contenus sont importés dans le magasin de fichiers.
- Le nombre de fichiers peut atteindre des dizaines de millions.
Cette charge de travail ne fonctionne pas avec une configuration Hadoop de «taille d'unité de travail statique». De même, nous avons évalué les magasins d'objets de style S3, mais nous les avons trouvés manquants.
Notre application est écrite en Ruby et nous avons un environnement Cygwin sur les nœuds Windows. Cela peut nous aider.
Une option que j'envisage est un simple service HTTP sur un cluster de serveurs sur lesquels le volume GlusterFS est monté. Puisque tout ce que nous faisons avec Gluster est essentiellement des opérations GET / PUT, cela semble facilement transférable à une méthode de transfert de fichiers basée sur HTTP. Mettez-les derrière une paire d'équilibreurs de charge et les nœuds Windows peuvent HTTP PUT au contenu de leur petit cœur bleu.
Ce que je ne sais pas, c'est comment la cohérence de GlusterFS serait maintenue . La couche proxy HTTP introduit une latence suffisante entre le moment où le nœud de traitement signale que l'opération est terminée et l'écriture réellement visible sur le volume GlusterFS, que je crains que des étapes de traitement ultérieures ne tentent de récupérer le fichier. trouve le. Je suis presque sûr que l'utilisation de l' direct-io-mode=enableoption de montage vous aidera, mais je ne sais pas si cela suffit . Que dois-je faire d'autre pour améliorer la cohérence?
Ou devrais-je poursuivre une autre méthode entièrement?
Comme Tom l'a souligné ci-dessous, NFS est une autre option. J'ai donc fait un test. Étant donné que les fichiers mentionnés ci-dessus ont des noms fournis par le client que nous devons conserver et peuvent venir dans n'importe quelle langue, nous devons conserver les noms de fichiers. J'ai donc construit un répertoire avec ces fichiers:
Lorsque je le monte à partir d'un système Server 2008 R2 avec le client NFS installé, j'obtiens une liste de répertoires comme celle-ci:
De toute évidence, Unicode n'est pas conservé. Donc, NFS ne fonctionnera pas pour moi.
ctdbstable et prête à l'emploi et la première phrase du lien que vous avez donné rend la seconde invalide car elle n'a jamais été mise à jour. J'avais l'intention d'établir cela, mais avant d'y arriver, j'ai basculé les travaux vers un environnement presque sans fenêtres.