Vous êtes ici : Accueil / 2010 / Juin / Neoppod sur Objectis

Neoppod sur Objectis

Par Gaël Le Mignot Dernière modification 18/06/2010 11:18 — Mots-clés associés : , , , , ,
Comme annoncé dans l'article précédant, Neoppod débarque sur Objectis. Voici quelques explications techniques et pistes pour le futur.

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

Slots, instances et serveurs

Commençons par le commencement. Au début il y avait le néant, le vide quantique. Puis le big bang. Bon, ne remontons peut-être pas aussi loin alors.

Mais tout de même, comment fonctionne Objectis ?

Objectis est composé d'un ensemble de serveurs, chaque serveur étant une machine virtuelle dans le parc « PODP » de Pilot Systems. Sur chaque machine virtuelle se trouve plusieurs instances Zope, écoutant sur un port différent. Et sur chaque instance Zope se trouvent un certain nombre de slots. Chaque slot possède un type de service. Jusque là tout va bien ? Non ? Bon, prenons un exemple. Sur la machine gummo se trouve une instance z8080 (accessible donc en gummo:8080) qui contient 600 slots de type de service [1] Plone 3.1.

Donc nous avons des serveurs qui contiennent des instances qui contiennent des slots. Un slot par exemple c'est gummo:8080/hosting_home/slot17191. Dans un slot, on peut créer un site. Le slot est alors occupé, et le sera jusqu'à ce que le site soit supprimé. C'est ce qu'il se passe lorsque vous créez un site depuis le site Objectis. Objectis va localiser un slot libre correspondant au type de service, et créer le site dedans. Et il va noter que votre site, par exemple http://tk31.objectis.net [2], a été créé sur le slot17191.

Il va noter ai-je dit ? Oui, dans une base de données relationnelles. C'est le cœur d'Objectis. Une grosse base PostgreSQL, avec des tables pour les sites, les utilisateurs, les instances, les slots, les types de services, les quotas, les vétos, les codes de validation, et tout ce qui va avec.

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] :

objectis.png

Quelques informations supplémentaires

Tous les types de service sur une instance Zope sont homogènes, mais par contre, sur un même serveur, il peut exister plusieurs instances ayant des types différents. Par exemple, les instances Plone 2.5 et Plone 2.1 sont sur la même machine, groucho. La répartition dépend de différentes paramètres, en général, on regroupe les instances ayant des versions similaires de Python et de Zope sur la même machine virtuelle.

Dernière précision : les sites de gestion d'Objectis, c'est à dire le frontal http://www.objectis.org, le back-office et le site de demande de jetons MyPlone sont sur l'infrastructure Pilot Systems comme des sites de clients, utilisant donc notre Apache frontal redondé, par exemple.

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 :

neo.png

Et donc au final :

neo-objectis.png

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.

[1]Un type de service correspond en général à une version de Plone, mais peut aussi correspondre à une utilisation particulière. Par exemple, lors du Forum des Associations de Paris, Pilot Systems a offert 400 comptes Objectis d'un type particulier aux associations. Ces comptes ont des paramètres (quotas, produits disponibles, ...) qui peuvent différer des comptes normaux.
[2]Un site ouvert par moi pour tester les comptes Objectis 3.1, sans intérêt.
[3]En réalité il y a un cache devant tout ça, pour éviter d'interroger la BDD à chaque requête HTTP.
[4]En simplifié, par exemple, tout ce qui est sauvegarde et supervision n'apparaît pas sur ce schéma.
[5]Certes, on peut aussi augmenter la RAM allouée à la machine virtuelle, et on ne s'en prive pas.

Actions sur le document