Une table ronde pour les fichiers entrants

Un tas de nouveaux fichiers avec des noms de fichiers uniques "apparaissent" régulièrement ¹ sur un serveur. (Comme des centaines de Go de nouvelles données par jour, la solution doit être évolutive en téraoctets. Chaque fichier fait plusieurs mégaoctets, jusqu'à plusieurs dizaines de mégaoctets.)

Il existe plusieurs machines qui traitent ces fichiers. (Des dizaines, si la solution est extensible à des centaines.) Il devrait être possible d' ajouter et de supprimer facilement de nouvelles machines.

Il existe des serveurs de stockage de fichiers de sauvegarde sur lesquels chaque fichier entrant doit être copié pour le stockage d'archivage. Les données ne doivent pas être perdues, tous les fichiers entrants doivent finir livrés sur le serveur de stockage de sauvegarde.

Chaque fichier entrant doit être livré à une seule machine pour traitement et doit être copié sur le serveur de stockage de sauvegarde.

Le serveur récepteur n'a pas besoin de stocker les fichiers après leur envoi.

Veuillez conseiller une solution robuste pour distribuer les fichiers de la manière décrite ci-dessus. La solution ne doit pas être basée sur Java. Les solutions Unix-way sont préférables.

Les serveurs sont basés sur Ubuntu, sont situés dans le même centre de données. Toutes les autres choses peuvent être adaptées aux exigences de la solution.

¹ Notez que j'omets intentionnellement des informations sur la façon dont les fichiers sont transportés vers le système de fichiers. La raison en est que les fichiers sont envoyés par des tiers par plusieurs moyens hérités différents de nos jours (étrangement, via scp et via ØMQ). Il semble plus facile de couper l'interface inter-cluster au niveau du système de fichiers, mais si l'une ou l'autre solution nécessite réellement un transport spécifique - les transports hérités peuvent être mis à niveau vers celui-ci.

Voici une solution à ce que vous recherchez. Aucun java n'est impliqué dans la fabrication de ce système, juste des bits Open Source facilement disponibles. Le modèle présenté ici peut fonctionner avec d'autres technologies que celles que j'utilise comme exemple.

1. Les fichiers sont HTTP POSTed à une adresse DNS Round-Robin spécifique.
2. Le système POSTANT les fichiers supprime ensuite un travail dans un système AMQP (Rabbit MQ ici), au moyen d'une autre paire d'équilibreurs de charge, pour démarrer le workflow de traitement.
3. Les équilibreurs de charge qui reçoivent le HTTP POST se trouvent chacun devant un groupe de serveurs de magasin d'objets OpenStack Swift.
   • Les équilibreurs de charge ont chacun deux ou plusieurs serveurs de stockage d'objets OpenStack Swift derrière eux.
   • «Round Robin n'est pas HA» peut être si les cibles sont HA elles-mêmes. YMMV.
   • Pour une durabilité accrue, les adresses IP du RRDNS peuvent être des clusters LB de secours à chaud individuels.
4. Le serveur Object Store qui obtient réellement le POST livre le fichier à un système de fichiers basé sur Gluster.
   • Le système Gluster doit être à la fois distribué (aka sharded) et répliqué. Cela lui permet d'évoluer vers des densités stupides.
5. Le système AMQP envoie le premier travail, effectuer la sauvegarde, à un nœud de traitement disponible.
6. Le nœud de traitement copie le fichier du stockage principal vers le stockage de sauvegarde et signale les succès / échecs si nécessaire.
   • Le traitement du mode de défaillance n'est pas schématisé ici. Essentiellement, continuez d'essayer jusqu'à ce que cela fonctionne. Et si cela ne fonctionne jamais, exécutez un processus d'exceptions.
7. Une fois la sauvegarde terminée, AMQP envoie le travail de traitement à un nœud de traitement disponible.
8. Le nœud de traitement extrait le fichier vers son système de fichiers local ou le traite directement depuis Gluster.
9. Le nœud de traitement dépose le produit de traitement où qu'il aille et signale le succès à l'AMQP.

Cette configuration devrait être capable d'ingérer des fichiers à des vitesses extrêmes avec suffisamment de serveurs. L'obtention de vitesses d'ingestion agrégées de 10 GbE devrait être réalisable si vous les augmentez suffisamment. Bien sûr, le traitement d'une quantité de données aussi rapide nécessitera encore plus de serveurs dans votre classe de machine de traitement. Cette configuration devrait évoluer jusqu'à un millier de nœuds, et probablement au-delà (bien que la distance dépende de ce que vous faites exactement avec tout cela).

Les défis majeurs de l'ingénierie seront dans le processus de gestion du workflow caché dans le processus AMQP. C'est tout un logiciel, et probablement construit sur mesure pour les exigences de votre système. Mais il faut bien se nourrir de données!

Étant donné que vous avez précisé que les fichiers arriveront via scp, je ne vois aucune raison pour que le serveur frontal existe du tout, car le mécanisme de transport est quelque chose qui peut être redirigé au niveau 3.

Je mettrais un directeur LVS (paire) devant, avec un pool de serveurs de traitement derrière et une politique de redirection à tour de rôle. Cela rend très facile l'ajout et la soustraction de serveurs au / du pool, cela augmente la fiabilité car il n'y a pas de serveur frontal à tomber, et cela signifie que nous n'avons pas à répondre à la question pull / push sur l'obtention des fichiers à partir de l'interface aux serveurs de traitement car il n'y a pas d'interface.

Chaque serveur de pool doit alors faire deux choses lors de la réception d'un fichier: premièrement, copiez-le dans le stockage d'archives, puis traitez le fichier et envoyez-le en cours de route.