Neoppod sur Objectis

Introduction

Il est désormais possible de créer des comptes « Neoppod » sur Objectis. Cet article a pour objectif de répondre à trois questions :

• comment Neoppod a-t-il été intégré dans l'architecture Objectis ?
• quels sont les avantages d'utiliser Neoppod pour Objectis ?
• quelles sont les pistes pour l'avenir ?

Architecture d'Objectis

Consultation d'un site Objectis

Mais que se passe-t-il donc quand on va sur http://tk31.objectis.net ? Voyons voir :

~ $ host tk31.objectis.net
tk31.objectis.net is an alias for objectis.pilotsystems.net.
objectis.pilotsystems.net is an alias for chloe.pilotsystems.net.
chloe.pilotsystems.net has address 85.118.46.82

On arrive donc sur une machine au doux nom de chloe. Chloe, c'est le frontal d'Objectis. Dessus, il y a un Apache et la base PostgreSQL. L'Apache utilise le mod_rewrite avec un script de réécriture, écrit lui en Python. Quand on lui demande tk31.objectis.net, il vérifie que le site existe, n'a pas été fermé par l'équipe Objectis, et va chercher toutes les informations. Il traduit que http://tk31.objectis.net c'est http://gummo:8080/hosting_home/slot17191/site18203/ et il va donc transmettre la requête à ce Zope, attendre la réponse, puis la renvoyer [3].

Voilà ce que ça donne [4] :

Intégration de Neoppod dans Objectis

Vous vous souvenez de l'article sur Neoppod ? Non ? Ah... Bon, Neoppod, c'est un système de stockage distribué pouvant remplacer ZEO. C'est à dire qu'on branche n'importe quelle instance Zope sur le stockage distribué Neoppod comme on le ferait sur un serveur ZEO (en utilisant le protocole NEO au lieu de ZEO), mais avec de la répartition de charge et tolérance de panne en plus.

Donc, comment faire pour intégrer Neoppod avec Objectis ? Au plus simple, car les solutions les plus simples sont souvent les meilleures. On va tout simplement remplacer une instance Zope classique par un cluster Neoppod complet, définir des slots dessus et tout fonctionnera tout seul. Par contre, avec Neoppod, plus besoin de définir plusieurs instances, on peut tout mettre dans un cluster Neoppod, qu'il suffira de faire grandir au fur et à mesure qu'il se remplira.

Donc, créons une petite VM, nommée par exemple morpheus. Dessus, on installe un Neoppod. Avec deux nœuds de stockage, pour avoir de la réplication. Un nœud master, ça suffira pour l'instant. Et deux instances Zope (configurées comme clients ZEO) devant. Dans le back-office Objectis, on va définir les slots... aïe, je mets comme quoi comme port ? J'ai créé deux instances là, une morpheus:8080 et une morpheus:8082. Qui vont contenir les mêmes sites. Réponse simple : il suffit d'ajouter un répartiteur de charge, par exemple Pound.

Et voilà ce que ça donne, à la place d'une instance Zope :

Et donc au final :

Conséquences de cette intégration

Dans le mode de fonctionnement classique d'Objectis, chaque site est fixé sur une instance Zope, et l'Apache frontal redirige directement vers l'instance où se trouve le site. Avec Neoppod, l'Apache frontal se contente de rediriger vers le cluster Neoppod correspondant au type de service, et ensuite un répartiteur de charge transmet la requête à l'une ou l'autre des instances Zope du cluster.

Les avantages immédiats sont triples :

1. Une meilleur mutualisation de la charge. En effet, avec l'architecture classique, si deux sites sont très actifs au même moment sur la même instance Zope, celle-ci sera surchargée, pendant que l'instance voisine elle sera peut-être inactive. Avec le mode de fonctionnement Neoppod, la charge sera toujours répartie uniformément.
2. Une meilleur tolérance de panne, si une instance Zope tombe ou se plante, le temps qu'elle soit redémarrée, les sites hébergés dessus ne sont plus accessibles avec l'architecture classique.
3. Une plus grande flexibilité dans l'évolution. Nous n'avons plus de lien direct entre le nombre de sites et le nombre d'instances. Si tous les slots sont pleins, on peut créer de nouveaux slots directement dans le back-office d'Objectis. Et dés que la charge du serveur devient trop élevée, on peut lui rajouter une instance, ou un nœud de stockage. Avec le mode de fonctionnement classique d'Objectis, le seul paramètre que l'on peut modifier est le nombre de slots par instance, et il ne peut pas être diminué une fois les sites créés [5] . Cela nous permet aussi de passer en mode dégradé par exemple en cas de panne matérielle, sans devoir aller jusqu'à couper temporairement certains sites (comme c'est déjà arrivé dans le passé sur Objectis).

Pistes pour le futur

Actuellement, le cluster Neoppod est intégralement déployé sur une seule machine virtuelle. Mais dans le futur, ce cluster pourra être réparti sur plusieurs machines virtuelles, suivant les besoins. On pourra ainsi avoir de la réelle tolérance de panne, allant jusqu'à supporter le plantage d'une machine virtuelle, voir même la défaillance physique d'un châssis. Mettre en place de la tolérance de panne absolue nécessiterait de redonder aussi les composants d'infrastructure comme la machine chloe, mais ce serait déjà un net progrès.

Enfin, une autre piste serait de migrer tous les sites Objectis déjà existant vers l'architecture Neoppod, au moins pour les Plone 3.1.

Conclusion

Vous pouvez dés maintenant ouvrir un Plone 3.3.5 (dernière version stable à ce jour) sur Objectis avec back-end Neoppod, en utilisant le code de validation neo_335_kaiNai2i gracieusement offert par Pilot Systems pour tester le service. Au-delà d'une version de Plone plus récente, vous aurez de meilleurs performances, une meilleur tolérance de pannes, et une gestion facilité pour nous !

Attention tout de même, il s'agit encore d'une architecture expérimentale, il est éventuellement possible que des données soient perdues.

N'hésitez pas à nous contacter si vous veniez à découvrir un bug.

Note : cet article a été modifié le 18/06/2010 à 11:20 pour préciser quelques points.