Utilisation d’Amazon Elastic File System dans une architecture Talend

Lancé en Juin 2016, Amazon Elastic File System est présenté par Amazon comme un service de stockage de fichiers élastique, évolutif et simple à utiliser avec Amazon EC2.

Principale différence avec AWS Elastic Block Store : EFS peut être accédé simultanément par plusieurs instances EC2 alors qu’un volume EBS est attaché à une unique instance EC2.

Dans ce billet de blog, nous allons étudier deux cas d’usage possibles avec AWS Elastic File System et Talend :

1.       Cas d’usage 1 : Utilisation d’AWS EFS dans la mise en place d’un cluster ActiveMQ

2.       Cas d’usage 2 : Utilisation d’AWS EFS dans la mise en place d’un cluster TAC

 

Cas d’usage 1 : Utilisation d’AWS EFS pour la mise en place d’un cluster ActiveMQ

Si vous utilisez Talend ESB, il y a de fortes chances que vous utilisiez également Apache ActiveMQ. Apache ActiveMQ est le broker open source livré avec la solution Talend ESB. Il implémente la spécification JMS et supporte plusieurs protocoles tels que OpenWire, STOMP, MQTT, AMQP. Il permet d’implémenter les patterns d’échange asynchrones dans un Système d’information via la définition de Queues et de Topics, ce qui favorise le couplage lâche dans une architecture.

Lorsque Apache ActiveMQ devient un pilier central de l’architecture, il est fortement recommandé de le configurer en haute disponibilité afin de garantir la continuité de service et la tolérance aux pannes. La Haute Disponibilité d’ActiveMQ se fait par la configuration Master/Slave tel que décrit dans la documentation officielle du projet Apache ActiveMQ.

Il existe plusieurs configurations Master/Slave possibles :

-          Le type Shared File System Master Slave : s’appuie sur un SAN ou un système de fichiers partagé basé sur NFSV4.

-          Le type JDBC Master Slave : le partage des informations s’appuie sur une base de données supportée de votre choix. Dans ce mode, il convient également de configurer la base de données en mode Haute Disponibilité

-          Le type Replicated LevelDB Store : s’appuie sur un quorum Apache Zookeeper pour la coordination du cluster et l’élection du broker Master. Ce mode s’appuie sur le store LevelDB qui est dorénavant déprécié.

Si vous optez pour le type Shared File Master Slave sur le cloud AWS, la bonne nouvelle est que vous avez à votre disposition un service qui vous permet de configurer en quelques minutes un Shared File System NFSV4.1 pour votre cluster Apache ActiveMQ : il s’agit du service Amazon Web Services Elastic File System.

 

La procédure d’installation d’un cluster ActiveMQ Master/Slave avec un Shared FileSystem basé sur EFS est simple et peut se résumer par les grandes étapes suivantes :

1.       Choisir une région puis créer un Virtual Private Cloud afin d’héberger l’architecture. Plusieurs configurations de VPC sont possibles et un guide est disponible. Un VPC privé est recommandé en termes de sécurité même si un VPC public moins sécurisé est suffisant pour tester. Il est également recommandé pour la Haute Disponibilité de créer un VPC qui contient un subnet pour chaque Availability Zone disponible dans la région choisie.

2.       Créer un FileSystem EFS en suivant cette documentation.

3.       Lancer deux instances EC2 distinctes et monter le File System partagé sur chacune des instances. Placer chacune des instances dans un subnet distinct du VPC afin de renforcer la Haute Disponibilité.

4.       Installer ActiveMQ sur chacune des instances et configurer la persistance KahaDB dans le fichier conf/activemq.xml afin que les données soient hébergées sur le File System partagé géré par AWS EFS.

<persistenceAdapter>

  <kahaDB directory="/sharedFileSystem/on/AWS_EFS"/>

</persistenceAdapter>

 

Un tutoriel détaillé est disponible en copiant collant le lien suivant : https://help.talend.com/reader/oz~Cr7CaJQg3tE1kU3Kqqw/ztpQuNeCoAuR3hq6cX...

 

Cas d’usage 2 : Utilisation d’AWS EFS dans la mise en place d’un cluster Talend Administration Center

Maintenant que vous savez comment créer et configurer un File System EFS dans un VPC sur AWS, vous pouvez facilement imaginer plein d’autres cas d’utilisation possibles.

D’ailleurs, un autre cas d’utilisation possible est l’utilisation d’EFS pour le partage de données entre deux instances Talend Administration Center.

En effet, la console TAC est un élément critique en Production : il permet entre autres le déploiement des jobs, l’ordonnancement des tâches, le monitoring, la gouvernance des services. Dans certains contextes de production, il est primordial que la TAC soit en mode Haute Disponibilité afin de prévenir toute interruption dans les exécutions de batchs.

 

La mise en Haute Disponibilité de la TAC passe par les étapes suivantes par ailleurs décrites dans la documentation Talend:

-          Installation de deux instances TAC sur 2 serveurs distincts idéalement répartis sur 2 Availability Zones distinctes si on considère le cloud AWS

-          Configuration du Quartz Scheduler DB pour mettre en cluster le Job Conductor

-          Mise en place d’un Shared FileSystem qui héberge les jobs générés et les logs

Pour mettre en place le Shared File System, la solution la plus simple et la plus rapide sur le cloud AWS sera donc d’utiliser le service AWS Elastic File System. En plus d’être hautement disponible, son élasticité permet de ne pas soucier de l’espace de stockage à prévoir en début de projet.

Conclusion

Il existe bien entendu plusieurs alternatives lorsqu’il s’agit de mettre en place un système de fichiers partagé dans une architecture : NAS, SAN, solutions commerciales (Net App par exemple)… Les avantages à utiliser AWS EFS dans un environnement AWS restent sa simplicité de mise en œuvre, son intégration native avec les autres services AWS et son élasticité.

Share

Leave a comment

Ajouter un commentaire

More information?