«clustering» et «load balancing» avec Zope et ZEO

IN53 Printemps 2003 «clustering» et «load balancing» avec Zope et ZEO Professeur : M. Mignot Etudiants : Boureliou Sylvain et Meyer Pierre

Sommaire Introduction...3 1. Présentation générale de ZEO...4 1.1. La philosophie ZEO...4 1.2. Fonctionnalités offertes...5 1.3. Quand utiliser ZEO?...6 1.4. Installation et lancement de ZEO...6 2. Distribution de la charge : «load balancing»...7 2.1. Sites miroirs...8 2.2. Le «Round-Robin DNS»...9 2.3. Le «Layer 4 Switching»...10 2.4. Gestion des points de défaillance...11 3. ZEO et le stockage des données...12 3.1. Cas d un serveur Zope isolé...12 3.2. Cas d un cluster ZEO...12 4. Configuration matérielle et logicielle...13 4.1. Matériel nécessaire...13 4.2. Amélioration de la sécurité et de la performance...13 4.3. Logiciels permettant de faire du «Load Balancing»...14 4.4. Exemple : le portail de l Université de Savoie...14 Conclusion...15 Adresses utiles...16 2

Introduction Zope est un serveur d application «open source», multi plateforme, permettant la création d applications web (intranet, extranet, boutique électronique, etc ). Zope est orienté gestion de contenu. Lorsqu un serveur web reçoit plus de requêtes qu il ne peut traiter, il peut devenir lent et instable. Dans le pire des cas, le serveur arrête de traiter les requêtes et peut en arriver jusqu à crasher. Ce problème ne concerne pas uniquement Zope mais tout type de serveur d applications. Utiliser plusieurs machines permet de pallier à ce problème, cependant cela implique quelques désavantages. Par exemple, les machines doivent posséder les mêmes informations dans leur base de données, ces informations doivent être synchronisées. Bien évidemment, pour un petit site dont les informations sont rarement modifiées, la synchronisation ne pose pas trop de problème, mais ça devient vite un cauchemar pour des gros sites manipulant des milliers d objets souvent modifiés! C est pour gérer ces problématiques que la Zope Corporation a créé ZEO («Zope Enterprise Objects»). Un site professionnel nécessitant une grande capacité de montée en charge doit répondre aux objectifs suivants : Disponibilité de 99.99 % (voir 100 % pour des services vitaux tels que aéronautique, hôpitaux pour lesquels des coupures de service ne sont pas acceptables). Accepter un grand nombre de clients simultanés, sans que la qualité ne se dégrade. Supporter de forts pics de charge, c'est-à-dire continuer à réagir de façon fluide même dans le cas de fortes sollicitations passagères (par exemple : couverture d un événement important, publication presse ) Pour ces besoins (montée en charge et haute disponibilité), ZEO et la mise en cluster permettent de répartir le risque de panne matérielle et la charge en multipliant les serveurs d application Zope. 3

1. Présentation générale de ZEO 1.1. La philosophie ZEO ZEO est un système qui permet de faire tourner un site internet sur plusieurs machines différentes. Cette méthode s appelle «clustering» ou «load balancing» («répartition de charge»). En faisant tourner Zope sur plusieurs machines séparées, on peut ainsi dispatcher les requêtes sur les différents serveurs, mieux encore, on peut ajouter d autres machines en même temps que le nombre de requêtes augmente. De plus, si une machine crashe, les autres prennent le relais pendant le temps de la réparation. ZEO utilise une architecture client/serveur. Les serveurs Zope sont considérés comme des clients ZEO et tous les clients sont connectés à un serveur ZEO central comme montré sur la figure suivante. Supposons qu on dispose de n machines à mettre en cluster. Ces serveurs sont utilisés de la manière suivante : - Le ZEO Server joue le rôle de serveur de stockage, il contient la ZODB (base de données objet). - n-1 ZEO Client. Ces machines se comportent comme des serveurs Zope standards. Elles ont à charge de servir les pages Web. Une seule machine est propriétaire de la base objet ZODB qui contient toutes les données. Les autres instances de Zope sont des clients ZEO qui viennent chercher auprès du ZEO Server les informations dont elles ont besoin. Grâce au système de cache interne à Zope, les conversations entre les clients et le serveur sont réduites au strict nécessaire. 4

L architecture ZEO utilise des protocoles de communication Internet standardisés. Ceci implique d autres avantages : les clients et le serveur peuvent se situer dans la même pièce, ou dans différents pays! Remarque : il n est pas obligatoire que chaque client ZEO utilise le même système d exploitation, mais l utilisation de machines Unix est fortement conseillé (ZEO fonctionne également avec Windows). La même version de Zope doit être installé sur toutes les machines. 1.2. Fonctionnalités offertes Haute disponibilité : si l un des serveurs du cluster cesse de fonctionner, le site fonctionne toujours. Montée en charge : en divisant la charge par le nombre de serveurs, le site est capable d accepter plus de clients simultanés et ainsi de faire face à la montée en charge. Distribution de charge : avec plusieurs serveurs et la répartition de charge bien conçue, la répartition de l activité permet une plus forte réactivité du site. Mise à disposition de ressources temporaires : en cas d événement prévisible (publication de presse, élections ) ou pour faire face à une montée en charge brutale, il «suffit» d ajouter des machines au cluster pour voir la disponibilité du site augmenter. Ces serveurs peuvent ensuite être supprimés après le passage du pic. Multiplication de serveurs : en multipliant le nombre de machines, on a une diminution du risque «physique» pour les serveurs, et donc une augmentation de la disponibilité théorique. La probabilité que toutes les machines tombent en panne en même temps diminue fortement si on augmente le nombre de machines. Intégrité transactionnelle : il existe des règles permettant de régler les problèmes de mises à jour simultanées de l information par deux serveurs concurrents. Remarque : En respect du modèle Web, ZEO est très efficace si le site respecte le ratio 90/10 : 90 % de lecture d information pour 10 % d écriture. Au-delà, si le site doit écrire plus d informations dans la ZODB, on pénalise le système en augmentant le nombre de conflits d accès. Dans ce cas, la meilleure solution est de stocker plus de données dans une base SQL supportant bien les écritures multiples et concurrentes. 5

1.3. Quand utiliser ZEO? Avant d envisager l utilisation de ZEO il faut faire un constat du trafic sur le serveur. Si le serveur ne reçoit pas plusieurs millions de requêtes par jour, il est probable que ZEO ne soit pas nécessaire. ZEO est une bonne solution dans les cas suivants : le serveur n arrive pas à traiter toutes les requêtes qu il reçoit le site est critique et a besoin d être opérationnel 24h/24, 7j/7 le site doit être distribué sur plusieurs sites miroirs un serveur doit être arrêté pour maintenance tout en gardant le site opérationnel Dans le cas contraire, il est inutile d installer ZEO. 1.4. Installation et lancement de ZEO L architecture la plus répandue correspond à un serveur ZEO et plusieurs clients ZEO. Il y a certains points auxquels il faut faire attention : les clients doivent disposer de la même version de Zope, des mêmes produits les clients doivent avoir accès aux mêmes ressources (base de données, serveur mail, etc.) la connexion entre les clients et le serveur doit être rapide sous peine de dégrader les performances de ZEO Une fois le serveur et les clients installés, il faut tout d abord lancer le serveur et lui demander d attendre les connexions sur un port particulier. Ensuite, il faut lancer chacun des clients en lui indiquant l adresse du serveur ZEO ainsi que le port de connexion. L architecture ZEO est maintenant mise en place et pleinement fonctionnelle. 6

2. Distribution de la charge : «load balancing» Une fois l architecture mise en place, un problème se pose : comment distribuer les requêtes sur les clients ZEO? Les utilisateurs ne connaissent que le serveur ZEO servant de frontal, mais pas les machines clientes tournant derrière. On ne peut pas spécifier pour chaque utilisateur, quel client utiliser, d autant plus que l utilisation des ressources ne serait pas du tout optimisée. En fait, la seule machine que l utilisateur «voit» est la machine chargée de la distribution de la charge. Cette machine est chargée de désigner le client ZEO qui va servir la page demandée par le client. Une des machines du cluster se charge donc du calcul de la page demandée, en se référent aux données présentent dans son propre cache, ou si nécessaire aux données disponibles sur le serveur ZEO. Les section suivantes dresse une liste des différentes façon de distribuer les requêtes sur plusieurs machines en utilisant différentes technologies (gratuites, commerciales, hardware, etc.) 7

2.1. Sites miroirs C est la méthode la plus facile à mettre en œuvre, elle ne nécessite aucun logiciel ou matériel supplémentaire. Le serveur ZEO présente à l utilisateur une liste de sites miroirs disponibles. L utilisateur choisit alors quel site miroir il désire utiliser. Cette méthode est dite «passive» (on ne choisit pas le client ZEO) et «volontaire» (l utilisateur doit choisir volontairement le client ZEO). Si on n a aucun contrôle administratif sur les sites miroirs cette solution est très facile à mettre en œuvre. Si un site miroir tombe, l utilisateur peut retourner sur le serveur ZEO (sur lequel on a un contrôle) et choisir un autre site miroir. A un niveau global, cette méthode améliore les performances. L utilisateur peut choisir le client ZEO qui lui est le plus proche géographiquement, et ainsi améliorer les temps d accès. Remarque : Une autre façon de procéder est de renvoyer aléatoirement vers un des serveurs miroirs disponibles sans demander l avis à l utilisateur : <dtml-call expr="response.redirect(_.whrandom.choice(mirror_servers))"> 8

2.2. Le «Round-Robin DNS» Le «Domain Name System» ou DNS est le mécanisme qui traduit les noms d ordinateurs en adresses IP. On peut ainsi obtenir plusieurs adresses IP pour un seul nom d ordinateur. La méthode la plus simple est donc d utiliser la répartition de charge à l aide du «Round-Robin DNS» comme illustré ci-dessous. La répartition de charge est placée au niveau du DNS. Le serveur DNS retourne alternativement les adresses de chaque client ZEO (les adresses distribuées sont équi-réparties : distribution séquentielle). Ainsi, le premier utilisateur sera redirigé sur le premier client, le second utilisateur sera redirigé sur le second client, et ainsi de suite. Puis on retourne à nouveau l adresse du premier client, etc. Cette méthode n est pas parfaite car les informations DNS sont mises en cache par les autres serveurs de noms du web. Ainsi, dès qu un utilisateur aura récupéré l adresse IP d un client ZEO, toutes les requêtes suivantes pour cet utilisateur iront sur le même client, ce qui pose des problèmes si le serveur correspondant est crashé (car le client garde en mémoire l adresse IP pour plusieurs heures). Le résultat général est correct, mais les requêtes ne seront pas dispatchées de manière homogène sur les différents clients. Pour conclure, l utilisation du «Round-Robin DNS» est très utile mais pas optimisée. Les serveurs DNS ont chacun leur propre politique de mise en cache et ces politiques peuvent avoir des incidences néfastes sur le fonctionnement de la répartition de charge. 9

2.3. Le «Layer 4 Switching» Les requêtes passent de manière transparente à travers un switch vers une ferme de serveurs. Des produits Zope sont disponibles pour mettre en place du «Layer 4». Les équipements du marché les plus souvent mis en place sont les modèles Alteon et LocalDirector de Cisco Systems. Le switch est configuré pour choisir un client ZEO dans la ferme de serveurs d après les paramètres qu on lui aura donnés. La figure suivante explique le fonctionnement du système. Il y a plusieurs solutions logicielles et matérielles disponibles pour mettre en place une telle architecture. Citons parmi les solutions logicielles le «Linux Virtual Server» (LVS) qui est une extension du système d exploitation Linux et qui permet de transformer un ordinateur sous Linux en «Layer 4 Switch». Il existe aussi une solution matérielle fournie par Cisco Systems, le LocalDirector qui est un routeur fonctionnant comme un «Layer 4 Switch» 10

2.4. Gestion des points de défaillance Sans ZEO, un serveur Zope représente un point de défaillance unique. ZEO permet de dispatcher ce point de défaillance sur plusieurs machines. Ainsi, si un client ZEO tombe, les autres clients ZEO prennent le relais automatiquement. Bien évidemment il subsiste un point de défaillance unique : le serveur ZEO puisqu il est le serveur de stockage central. Mais cette méthode permet de minimiser les risques de défaillance sur plusieurs clients. Une méthode très populaire pour accepter le risque de défaillance d un point unique est de le minimiser au maximum en utilisant du matériel de très bonne qualité (RAID, redondance dans la connectique, redondance de l alimentation etc ), avec une politique de sécurité de haut niveau, par exemple, en faisant régulièrement des sauvegardes. Ceci permet de diminuer la qualité des composants matériels présents sur les clients. Il existe par ailleurs des outils tels que fake, qui permettent la mise en place de serveurs ou de Switch Layer 4 redondants. 11

3. ZEO et le stockage des données 3.1. Cas d un serveur Zope isolé Zope Application File Storage Zope ne sauvegarde pas directement toutes les données sur le disque. En effet, il utilise un composant particulier appelé storage lui permettant de savoir pour chaque objet manipulé où il doit être sauvegardé. Ceci permet de minimiser les accès au disque ou à la base de données. Zope est connecté à un File Storage, ce qui signifie que tous les objets sont sauvegardés dans un seul et même fichier sur le système de fichier (data.fs). 3.2. Cas d un cluster ZEO Zope Application Client Storage File Storage Storage Server Le FileStorage est remplacé par un Client Storage qui au lieu de sauvegarder les objets dans un fichier, les envoie à un composant Storage Server via le réseau. C est le Storage Server qui a pour mission de sauvegarder les objets sur le système de fichier du serveur ZEO (File Storage). 12

4. Configuration matérielle et logicielle 4.1. Matériel nécessaire Un serveur pour héberger Apache (pour les accès non authentifiés non cryptés), Apachessl (pour les accès authentifiés et cryptés), et faire du LoadBalancing. Des serveurs pour héberger les serveurs dédiés au traitement (Zeo client). Un serveur pour héberger la ZODB (Zeo Storage Server). 4.2. Amélioration de la sécurité et de la performance Il y a encore 2 points de défaillance sans redondance : le serveur apache et la base de données. Pour le serveur apache, il est relativement simple de mettre en place une seconde machine qui prendrait le relais en cas de défaillance de la première. Pour le serveur Zeo, la meilleure solution est sans doute d'utiliser Zeo Replication Server de Zope Corp. Si les usages augmentent, il sera nécessaire d augmenter le nombre des serveurs Zope, cela implique seulement d'ajouter les nouvelles adresses IP au logiciel ayant pour rôle de faire le Load Balancing. Un autre moyen d augmenter les performances est de mettre en place une politique de cache, mais ceci s'avère relativement difficile pour un serveur très dynamique Si les accès en écriture deviennent vraiment trop important, une solution peut être de mettre en place plusieurs serveurs ZEO qui seront eux mêmes clients ZEO pour un serveur ZEO central (architecture à trois niveaux). 13

4.3. Logiciels permettant de faire du «Load Balancing» Apache via le mod_backend Balance (http://balance.sourceforge.net/) qui est réputé pour être facilement installé et configuré. Ce logiciel est distribué sous licence GPL. Pound (http://www.apsis.ch/pound/) est un très bon logiciel étant à la fois un reverse proxy, un load balancer et un http front-end. Spécialement créé pour être utilisé avec Zope et ZEO, Pound est une très bonne alternative à la solution Apache/Apachessl/Balance. Il est très simple à configurer. Ce logiciel est distribué sous licence GPL. 4.4. Exemple : le portail de l Université de Savoie 1 machine Apache : serveur à base de bi xeon 2Ghz avec 4GO de RAM 1 serveur ZEO : serveur à base de bi xeon 2Ghz avec 4GO de RAM 3 clients ZEO : bi PIII à 900Mhz avec 1GO de RAM et 600GO de DD Zope ZEO : distribué sous licence GPL Pour comparaison, voici le prix d une solution commerciale : WebSphere Application Server V4.0 (création, gestion et exploitation d application Internet). - Advanced Single Version : 9219,13. - Advanced Edition : 13073,95. - Plus achats de nombreuses briques logicielles plus ou moins chères) Charge sur le système : 12000 sessions par jours pour 6500 membres, 600Mo de data.fs (base de données interne à Zope : ZODB) une fois packée et 60Go de données sous forme d'extfile (fichiers externes à la ZODB). 14

Conclusion Nous venons de présenter à travers cette étude une solution adaptée aux applications Internet permettant le déploiement d un cluster et la mise en place d une solution de répartition de charge, à l aide des logiciels libres Zope et ZEO. Cette solution devient aujourd hui de plus en plus populaire, supportée par l élargissement permanent de la communauté d utilisateurs et de développeurs autour du logiciel Zope, et l utilisation de ce type de solution dans de grande institutions telles que certaines de nos universités ou administrations. Zope Corporation inclura ZEO dans la prochaine grande évolution de Zope : Zope 3. 15

Adresses utiles ZEO : http://www.zope.org/products/zeo Présentation de Zope : http://pref.msg-software.com:6969/sylvain/presentations/zope/zope_index.html Installing, configuring, and administering ZEO : http://www.zope.org/members/mmceahern/installing_zeo Zope : http://www.zope.org/ Pound : http://www.apsis.ch/pound/ Balance : http://balance.sourceforge.net/ Mod_ssl : http://www.modssl.org/ Openssl : http://www.openssl.org/ Apache : http://www.apache.org/ Python : http://www.python.org 16