Neopod: une base de données objet distribuée

Neopod: une base de données objet distribuée

Gaël LE MIGNOT — Bruno DUPUIS

Pilot Systems

11 juillet 2011

Gaël LE MIGNOT — Bruno DUPUIS Pilot Systems Neopod: une base de données objet distribuée

Plan

1 IntroductionZODBImplémentationsexistantes

2 Architecture GénéraleSchéma GénéralRéplication

3 Opérations internesConnexion du clientLecture

CommitAjout d’un nœud« Mort » d’un nœud

4 ObjectisFonctionnementd’ObjectisLes limitations

5 Neoppod sur ObjectisObjectifs visésLa solution

6 Conclusion


Introduction

Introduction


ZODB

La ZODB (Zope Object Database)

Écrite en PythonCréée pour ZopeBase de données ObjetRespect des contraintes d’ACIDité


Implémentations I

FS Storage

Un fichier en append-onlyLe process Python lit et écrit directementPas de concurrence possibleMauvaise scalabilité


Implémentations II

ZEOArchitecture client-serverLe server lit et écrit dans un fichier en append-onlyLe server gère la concurrence entre les clientsCache sur les clientsLe server gère les invalidations de cacheMauvaise scalabilitéAucune tolérance à la panne


Implémentations III

ZEO-RaidRéplication de type RAID-1Scalabilité limitée : chaque nœud possède l’intégralité dela base

RelStorage

Stockage des objets sous forme de pickles dans une baseSQLPosgreSQL et MySQLRéplication possible au niveau SQLScalabilité limitée : chaque nœud possède l’intégralité dela base


NEO

Historique2005 : Démarrage du projet par Nexedi (ERP5)2009 : Création du consortium System@ticfev. 2010 : ReleaseDéploiements (ERP5, Plone3, Plone4)


System@tic


Architecture Générale

Architecture Générale


Schéma général


Réplication

Nœud maîtreRéplication simpleUn primaire et plusieurs secondairesEn cas de panne, élection d’un nouveau primaire

Nœud de stockage

Choix du niveau de réplicationLe nœud maître décide des données possédées parchaque nœud de stockageLe nœud maître maintient une table de partition qu’ilpartage avec les nœuds de stockageEn cas de panne : le maître redistribue les données


Opérations internes

Opérations internes


Connexion

Connexion du client

HandshakeLe client se connecte sur le nœud maîtreLe nœud maître enregistre le clientLe nœud maître envoie au client la table de partitionactuelle


Lecture

LectureLe client vérifie qu’il n’a pas l’objet en cacheLe client trouve un nœud de Stockage qui contient ladonnéeLe client interroge directement le nœud de Stockage


Commit I

Commit


Ajout d’un nœud de stockage

Ajout d’un nœud


« Mort » d’un nœud de stockage

« Mort » d’un nœud


Objectis

Objectis


Présentation

Objectis c’est...Une plateforme d’hébergement gratuit en Zope/PloneActuellement, propose des sites en Plone 4Des instances contiennent des sites en Plone 1 à 3 et enZope purNécessite un code de validation, via myplone

Objectis c’est aussi...Une communauté avec un forum et un tracker de supportUn site traduit en 8 langues18 257 sites au total


L’architecture


Création d’un site


Gestion des instances

Les slots et les instancesChaque instance Zope possède un type (Plone 3, Plone 4,...)Sur chaque instance Zope, on défini des slots (400 à 600)On regroupe les instances similaires sur une VM

Utilisation des slotsLes sites sont créés sur un Zope du bon type ayant desslots libresSupprimer un site libère le slotQuand il n’y a plus de slots, on ne peut plus créer decompteIl faut alors manuellement créer une autre instance


Objectis fonctionne mais...

Sur la gestion des slots

Créer une instance Objectis est assez délicatÀ cause du GIL, un Zope ne peut utiliser plus d’un cœurLa répartition de charge entre les instances est irrégulièreUne fois une instance pleine, on ne peut plus grand chosepour elle

Autres problèmesPas de tolérance de panneInstances vulnérables au DoS


Neoppod sur Objectis

Neoppod sur Objectis


Les objectifs visés

Meilleur tolérance de panneUne instance plantée ne doit pas couper ses sitesÀ terme, on veut même pouvoir éteindre une VM sanscouper le service

Meilleur gestion des instances

Éviter le problème de l’instance ayant tous les gros sitesÉviter de devoir configurer sans cesse des nouvellesinstancesPouvoir ajouter des ressources supplémentairessimplement


La solution magique

NeoppodOn utilise Neoppod pour les donnéesOn met un cluster Neoppod par version de Plone

EffetsOn a de la tolérance de panne entre les instancesOn peut ajouter des instances Zope et des noeuds destockage, à la voléeLes ressources sont totalement mutualisées


L’architecture


L’architecture complète


Conclusion

Conclusion


Conclusion

L’état actuelPlone 3.3 et 4.0 sous NeoppodTout fonctionne tranquillementPour l’instant, une VM par version de Plone

Le futurMise en place de tolérance de panneRépartition de charge entre les VMsPour ça, il nous faut plus de monde !


En attendant

Un cadeauUn code offert pour 50 sites : rmll2011-neo

La page de pub

Pilot Systems, société de services en logiciels libres :http://www.pilotsystems.net

Slides en licence CC-By-Sahttp://contributions.pilotsystems.net/

Des questions ?


Technology

Neopod: une base de données objet distribuée