Faire du « grid computing » avec un etl... c'est possible

Le Grid Computing est une architecture méconnue dans le monde de la BI mais qui, à bien des égard, peut s'avérer très utiles. Voici comment.

Les prémisses du Grid Computing

L’informatique, depuis qu’elle est apparue, est sollicitée pour pouvoir offrir toujours plus de puissance de calcul.

Les fabricants avec leurs chercheurs ont tenté alors d’apporter des réponses via deux courants de pensée :

-          La construction d’une super machine, « le super calculateur » : une machine surpuissante conçue physiquement pour calculer intensivement et massivement (pour faire un résumé simpliste, on réunit sur une même machine plusieurs processeurs)

-          L’assemblage physique de plusieurs machines pour n’en former qu’une : Le Cluster

L’arrivée du « Cluster » a fait apparaître avec lui la notion de calculs distribués et surtout de parallélisme au niveau serveur (ce n’est plus une unité de calcul qui travaille sur un traitement, mais plusieurs serveurs possédant chacun leur unité de calcul, « l’union fait la force »).

La solution « Grid Computing »

L’architecture Cluster séduit, mais présente certaines contraintes : si un des serveurs tombe en panne, c’est l’ensemble qui subit la panne et le système entier est arrêté. Il est nécessaire également que chaque composant constituant le cluster soit identique.
Un autre souci moins pénalisant, mais qui limite l’application massive dans les entreprises, c’est que le cluster ne permet aucune souplesse d’exécution. En effet, dès qu’un traitement est lancé, toutes les machines du cluster sont monopolisées même si le traitement en lui-même ne demande pas autant de ressources.

Sur ces contraintes, la technologie « Grid Computing » nait. L’architecture de cette solution pour assembler ces serveurs ne va pas se baser sur l’aspect matériel, mais le côté logiciel. Le cœur de la solution réside dans ce qui s’appelle le moteur de la grille (Grid Engine), qui a pour but de faire dialoguer les serveurs entre eux quelle que soit la nature des serveurs (hormis le système d’exploitation).

Pour son fonctionnement, la solution grille fait apparaître la notion de serveur « maître » (« moteur ») et de serveur « esclave » (« calcul »).

Le serveur « moteur » a deux tâches :

• Savoir l’état de la grille de serveurs, quels sont ceux qui sont « en attente », en « occupé » ou ne répondent plus
• Faire exécuter un traitement que l’on a soumis à la grille sur des serveurs « calcul » en « attente »

Le serveur « calcul » a deux tâches lui aussi :

• Renseigner son état au serveur « moteur » : occupé ou en attente
• Exécuter la tâche assignée par le serveur « moteur »

Avec ce mécanisme, les contraintes du cluster sont résolues. Si un serveur « calcul » plante, il apparait comme non disponible, mais la grille reste opérationnelle. Le serveur « moteur » peut réquisitionner l’ensemble des serveurs « calcul » ou une partie.

Le maillon faible, le serveur « moteur », est résolu via le moteur de grille qui implémente la notion de serveur « moteur » de backup; si un serveur « moteur » tombe, un autre « dormant » prend la relève.

Les limitations ETL

Les outils d’alimentations BI travaillent depuis longtemps sur la notion de parallélisme d’un traitement, si bien qu’on arrive maintenant à ce que l’outil ETL consomme intensivement un serveur jusqu’à le saturer.

Deux cas se présentent alors :

Si l’entreprise a les moyens financiers, on répond alors en changeant le serveur par un autre plus costaud (plus de processeurs, plus de cœur, etc.), les développements ETL s’adaptant en un clin d’œil à ce changement. Que faire si on a déjà le top du top ? On fait du bricolage, on revoit les développements ETL pour qu’ils soient dispersés sur différents serveurs ETL ou alors on déporte certains traitements en base de données. On tolère également des temps d’exécution plus longs.

Si l’entreprise n’a pas les moyens financiers, on commence alors à faire du bricolage en mettant en place des mécanismes qui vont brider les développements ETL et aussi de déporter certains traitements en base.

Remarque : Déporter des traitements en base est une fonctionnalité que permettent aussi certains ETL nativement; cela n’est pas forcément une mauvaise solution.

La solution ETL« Grid Computing »

De par son architecture, la technologie Grid peut offrir une puissance de feu avec des serveurs peu puissants, l’important étant leur nombre. Lorsque la Grid arrive également à saturation, il suffit alors d’ajouter, à chaud même, un serveur de calcul. Sur cet ajout, le moteur de Grid prendra en compte cette nouvelle machine dynamiquement et les programmes ETL s’adapteront de façon transparente.

Autre intérêt : si on retire des projets ETL de la Grid, on pourra alors avoir un serveur de calcul pour le réaffecter à un autre besoin de l’entreprise. On n’est pas obligé de garder notre bête de course si on ne lui donne plus suffisamment de boulot, impensable avec une solution non Grid.

À l’heure actuelle, pour une entreprise qui souhaite opter pour la mise en place d’une plateforme unique ETL, la solution Grid est la solution qui permettra de s’adapter aux besoins actuels, et surtout futurs, de l’entreprise.

 

Pour en savoir plus, contactez-moi.