Nous avons souvent vu, chez des clients victimes de leur succès, une application devant faire face à des centaines de transactions par seconde alors qu’elle était prévue pour une dizaine seulement.
Dans ce cas, on améliore le système par l’adjonction de nouveaux éléments qui permettent d’augmenter sa capacité transactionnelle. Il existe également des techniques de basculement dans le cas de crash. Dans ce cas, on ne fait que des reprises automatiques d’activité sans faire appel à de la répartition de charge.
Cette solution est intéressante lorsqu’un nœud supporte le volume de transaction et que l’ajout d’un répartiteur de charge fait augmenter la charge du système.
Dans ce qui va suivre, j'essaierai de vous présenter quelques solutions applicables à différentes parties d'une chaîne applicative n-tiers classique. Quels sont les principes de répartition de charge ?
Il n’existe pas beaucoup de familles de solution. On n'a globalement que deux techniques :
- L’ajout d’un étage supplémentaire pour gérer le pool de ressource ;
- L’utilisation d’une répartition de charge par round-robin via le DNS ou par mécanisme applicatif.
Ces méthodes ont leurs avantages et leurs inconvénients. Le gestionnaire de pool augmentera la complexité mais apportera plus de souplesse et de sûreté vis-à-vis des pannes. La solution à base de round-robin DNS ou applicatif sera plus simple mais entraînera une complexification de la chaîne applicative.
Néanmoins certains produits permettent de gérer cette répartition de charge en interne, comme par exemple Tomcat, JBoss ou MySQL. Pour ce dernier, on doit installer un proxy.
Certains serveurs d’applications Java permettent de gérer une répartition de charge à leur niveau. Par exemple, multi-pool JDBC pour les connexions aux bases de données ou gestion des grappes de serveurs via l'utilisation de pilotes JDBC.
Quels produits peuvent en bénéficier ?
Plusieurs grandes familles de produit peuvent profiter des solutions de répartition de charge. Chez simia, nous sommes intervenus sur des bases de données, serveurs Web, serveurs Java/J2EE...
Certaines techniques sont très simples, comme l’ajout d’un répartiteur de charge au niveau TCP. D’autres réclament des connaissances très fines du produit, voire de l’application. Par exemple, le découpage au sein d’une application des requêtes en base entre lecture et écriture.
L’impact budgétaire ne sera donc pas le même selon le type de produit. Attention également à bien évaluer les ressources nécessaires.
Nous recommandons de qualifier où se trouve la contention dans la chaîne applicative n-tiers et de privilégier les solutions simples. Il est inutile d’optimiser certaines chaînes très performantes, comme un serveur web de page statique, alors que la contention se trouve au niveau d’une base surchargée.
Paradoxalement, les produits les plus performants s’intègrent généralement très facilement au sein d’une boucle de répartition de charge. On le constate pour les serveurs Web/Java/J2EE. Alors que d’autres seront plus difficiles à intégrer comme les bases de données.
Serveur Web
Le serveur Web reste de loin l’élément le plus simple à mettre au sein d’une boucle de charge. En dehors de quelques problématiques de sessions, vous n’aurez pas à vous soucier de la réplication et de la fraîcheur de vos données comme vous auriez à le faire sur une base de données, par exemple.
HAProxy
Ce produit, beaucoup moins connu qu’Apache, répond scrupuleusement à la philosophie Unixienne. C’est-à-dire « un outil par besoin ». Son fonctionnement est très simple. Vous le positionnez en frontal des produits que vous avez à mettre dans votre boucle de répartition de charge. Vous renseignez un fichier de configuration. Vous lancez le process. Votre boucle de répartition de charge est en place !
Vous pourrez facilement faire une répartition de charge sur n’importe quel type de protocole TCP. La documentation est bien faite avec de nombreux exemples qui vous permettront de le déployer facilement dans votre infrastructure. De plus, depuis la version 1.3, il est possible de gérer une redirection en fonction du contenu de la requête au niveau HTTP (page dynamique vs statique) et de bloquer les requêtes en fonction de leur contenu. Une description complète des fonctionnalités du produit est disponible sur leur site Web [HAPROXY]
Enfin, ce produit met à disposition des binaires pour les Unix Solaris (Sparc et Intel) ou Linux (Intel et AMD64).
Greffons Apache/J2EE
L’utilisation d’un serveur d’application n’implique pas forcément une notion de répartition de charge. Néanmoins on peut faire appel à des greffons Apache qui s’y prêtent très bien.
Les avantages sont multiples :
- Meilleure utilisation de vos ressources : à volumétrie égale, votre serveur Apache répondra plus vite avec une empreinte mémoire plus petite sur les objets statiques ;
- Compression à la volée de vos pages statiques et dynamiques pour une meilleure utilisation de la bande passante ;
- Possibilité de mise en place de grappe avec gestion des sessions des utilisateurs. Dans le cas où le crash d’un serveur avec la perte des sessions rattachées serait problématique, cette solution est là pour garantir une reprise transparente de l’activité.
Pour le clustering des sessions, Tomcat ou JBoss offrent ce type de service. Certains serveurs d’application propriétaire comme WebLogic ou WebSphere également (à un prix conséquent). Toutefois, ils ont l’inconvénient d’augmenter la charge processeur ainsi que la communication réseau entre les serveurs J2EE de votre grappe. Plus vous augmentez le nombre d’éléments dans votre boucle de charge, plus vous augmentez le poids de cette surcharge processeur et réseau de manière exponentielle. Il est donc important de qualifier sérieusement vos besoins par des benchmarks afin de valider une solution. Il est également important de savoir si la notion de grappe de serveurs est essentielle ou non à votre système d’informations.
Vous pouvez par exemple découper votre application en fonction de la criticité de ses différentes parties. La consultation est moins critique en qualité de service mais plus gourmande en ressources. Un formulaire de paiement réclame une quantité de transaction moins élevée mais avec une qualité de service beaucoup plus exigeante.
Une répartition de charge à l’aide de greffon J2EE pour Apache implique de séparer le contenu statique d’un site Web (feuille de style, images, pages HTML statiques) de la partie dynamique. Une réorganisation du contenu de vos applications sera très utile.
Reverse proxy
Le Reverse Proxy permet d’envoyer vos requêtes – via un algorithme de répartition de charge – aux différents nœuds d’une boucle de répartition de charge. Outre cette répartition de charge, il peut aussi procéder aux opérations suivantes :
- Cache des éléments statiques : réduit la bande passante utilisée dans notre réseau interne ;
- Compression à la volée des éléments HTML dynamique et statique de notre site Web : réduction de la consommation de bande passante ;
- Chiffrement SSL : si le besoin se fait sentir de chiffrer vos communications, plutôt que d’augmenter la consommation processeur et de modifier la configuration des serveurs Web, déléguez ce chiffrement en amont ;
- Sécurité : ce nouvel étage vous permet d’installer plus simplement un système de DMZ qui éloigne d’autant vos serveurs sensibles du réseau Internet.
Avec le reverse proxy sur un greffon J2EE, vous n’aurez pas à vous soucier de l’organisation de votre application (séparation du contenu statique du contenu dynamique). En revanche, vous ne pourrez pas bénéficier des mêmes possibilités en termes de gestion de persistance des sessions au sein d’une grappe que peut offrir un greffon J2EE. Rien ne vous empêche de combiner les deux solutions.
Base de données
Les bases de données comme MySQL et PostgreSQL, les deux références incontournables du marché, sont de grands centres de consommation de ressources. Chacune ont des solutions de répartitions de charge, fiables et reconnues.
Avant tout, il convient de qualifier le ratio lecture/écriture lors de la mise en place d’une répartition de charge sur ce type de produit. Ces solution se comportent beaucoup mieux dans le cas d’un fort ratio en faveur des lectures.
Remarque : dans le cas d’un ratio en lecture à 100%, il est tout à fait imaginable de procéder à la mise à jour des données par un autre moyen. Rien n’empêche par exemple d’utiliser un moyen classique d'export/import ou batch de mise à jour sur chaque nœud.
Regardons pour MySQL et PostgreSQL les réplications maître/esclave de vos données – étape essentielle pour garantir la mise en place d’une répartition de charge sur plusieurs nœuds – et la répartition des lectures sur plusieurs bases.
Répartition de charge et réplication avec MySQL
Cette fonctionnalité fait partie intégrante de MySQL. Elle est très souple en termes de fonctionnement. Le principe est assez simple : vous définissez un nœud comme étant le maître et vous lui rattachez un ou plusieurs esclaves. Le produit prendra en compte les modifications au fil de l’eau et gardera les requêtes en attente dans le cas d’une interruption de service. Petit raffinement intéressant, il est possible de croiser les réplications et donc de faire des réplications maître/maître. Cette partie ayant été souvent documentée, je vous propose de vous reporter aux articles dans la section bibliographie [MYSQL].
Autres fonctionnalités intéressantes : le filtrage des bases à reproduire. En effet, votre application peut avoir besoin d’un emplacement temporaire de stockage pour des données de sessions, un contenu de caddie etc. Alors, il est possible de ne répliquer qu’une seule partie de vos schémas de données. Cela réduit d’autant le besoin de resynchronisation entre vos différents nœuds. Bien sûr, si vos sessions ne doivent pas perdre d’information, vous devez répliquer toutes les données.
La réplication en place, il reste à mettre en œuvre mysql-proxy. Il suffit de donner en paramètre la liste de vos serveurs MySQL, le port d’écoute de votre proxy et de changer l’adresse/port de votre base. Vous pointez ainsi sur votre proxy et disposez d’une répartition de charge automatique. Une limitation à cet outil : il ne sait pas – pour l’instant – faire de séparation au niveau des requêtes en lecture/écriture. On doit donc gérer la gestion des adresses en lecture et en écriture au niveau de l’application.
Pour de plus ample détail, vous pouvez vous reporter aux articles sur le proxy de MySQL proposés en bibliographie [Proxy-MySQL].
Avant propos sur les solutions avec PostgreSQL
Contrairement à MySQL, PostgreSQL ne dispose pas directement de solution de réplication. On doit faire appel à un produit Tiers comme SLONY ou PGPOOL.
PostgreSQL Slony-I
Le principe pour Slony est simple. Vous donnez le nom d’une base à répliquer, le nom des bases dans lesquels vous devez recopier et enfin le nom des serveurs correspondants.
Cette solution présente des limitations à plusieurs niveaux :
- Slony n’a pas d’algorithme par défaut pour détecter des problèmes sur les bases esclaves ;
- Il n’y a pas de méthode de temporisation des données à mettre à jour en cas de crash d’un des nœuds de la grappe. Par conséquent, en cas de crash, la garantie de l’intégrité des données devra se faire par des méthodes tierces ;
- Il n’existe pas de réplication maître/maître ;
- Il est nécessaire de séparer les opérations d’écriture et lecture ;
- Il n’y a pas de réplication du schéma de la base.
Le problème de non temporisation des écritures peut être considéré comme secondaire dans la mesure où en cas de crash d'une machine, la reprise se fait rarement sans intervention. D'autre part, en cas de crash sur MySQL, des fichiers sont créés sur la machine maître. Si le service est trop long à se rétablir avec une activité transactionnelle soutenue, vous pourrez saturer vos disques !
Enfin, on est dans l’obligation d’ajouter un produit permettant de faire un proxy des requêtes [PL/Proxy] ou de gérer au niveau de l’application.
PostgreSQL pgpool-II
Là encore, sa mise en place se révèle assez simple pour la répartition de lectures et écritures sur plusieurs nœuds.
Il est aussi capable de gérer des partitions (répartition des tables en fonction de règles). Un exemple simple de ce type d'application est de répartir une table sur plusieurs nœuds en utilisant, par exemple, la parité ou le résultat d'une division entière sur une clé primaire de type entier. On découpe ainsi la volumétrie et la charge entre les différentes machines de la boucle de charge.
Comme toujours, de nombreux tutoriels existent (voir la bibliographie de l'article [PGPOOL]).
En résumé, pgpool est plus riche en terme de fonctionnalités. On peut noter les points forts suivants :
- Mécanisme de reprise automatique de réplication en cas de crash d'un des nœuds ;
- Mécanisme de cache des requêtes et réplication automatique des données entre les différents nœuds ;
- Configuration simple.
Serveur d'application Java et Pilotes proxy JDBC
Les proxys JDBC, outils de clustering de base de données, sont complètement génériques. Ils fonctionneront pour toutes les bases de données du marché possédant un pilote JDBC. Leur principal défaut est de ne fonctionner que pour les serveurs Java/J2EE.
Le principe est simple, ils se substituent au pilote Java utilisé pour gérer habituellement les connexions à votre base. On précise ensuite en paramètre le nom de l'ancien pilote sur lequel on va s’appuyer pour se connecter réellement à la base. Il existe quelques références comme [SEQUOIA], [C-JDBC] ou [HA-JDBC], l'avantage de ces outils étant de supprimer le besoin de disposer d'un élément servant de proxy.
Comme toujours, lors de l'adoption d'une de ces solutions, il vous faut qualifier l'impact sur les performances sur le système informatique en réalisant un benchmark.
Avant d’aller plus loin
Les solutions sont très nombreuses ? C’est pourquoi, avant d’en adopter une, il est important de qualifier les impacts lors de l'ajout de ces composants et de gérer le risque. Rien ne doit être entrepris au détriment des performances.
Bibliographie
[HAPROXY] fonctionnalités du HAProxy : http://haproxy.1wt.eu/#desc
[MYSQL] Réplication master/master MySQL : http://www.howtoforge.com/mysql_master_master_replication
[MySQL-Proxy]
Réplication master/master MySQL : http://www.oreillynet.com/pub/a/databases/2007/07/12/getting(...)
Manuel d'utilisation du proxy MySQL : http://dev.mysql.com/doc/refman/6.0/en/mysql-proxy-using.htm(...)
[SLONY] Réplication master/slave PostgreSQL/Slony http://www.linuxjournal.com/article/7834
[PL/Proxy] Tutoriel d'utilisation de PL/Proxy : http://plproxy.projects.postgresql.org/doc/tutorial.html
[PGPOOL] Répartition de charge avec pgpool : http://pgpool.projects.postgresql.org/pgpool-II/doc/tutorial(...)
[SEQUOIA] Sequoia solution transparente de clustering : http://www.continuent.com/community/tungsten-connector
[C-JDBC] Ancêtre de Sequoia : http://c-jdbc.ow2.org/
[HA-JDBC] Proxy léger et transparent pour JDBC : http://ha-jdbc.sourceforge.net/
Aller plus loin
- Fonctionnalités du HAProxy (154 clics)
- MYSQL : Réplication master/master MySQL (183 clics)
- SLONY : Réplication master/slave PostgreSQL/Slony (54 clics)
- Sequoia (tungsten-connector) solution transparente de clusturing (74 clics)
- HA-JDBC, Proxy léger et transparent pour JDBC (56 clics)
# RDBMS sucks
Posté par Nÿco (site web personnel) . Évalué à 7.
http://couchdb.apache.org/
http://www.erlang.org/doc/apps/mnesia/
http://jackrabbit.apache.org/
http://www.mongodb.org/
http://incubator.apache.org/cassandra/
...ne sont que quelques exemples...
[^] # Re: RDBMS sucks
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: RDBMS sucks
Posté par Laurent Cligny (site web personnel) . Évalué à 4.
[^] # Re: RDBMS sucks
Posté par mortimer . Évalué à 2.
Domino serait-il à la pointe du buzz ?
[^] # Re: RDBMS sucks
Posté par herodiade . Évalué à 7.
> http://www.erlang.org/doc/apps/mnesia/
> http://jackrabbit.apache.org/
> http://www.mongodb.org/
> http://incubator.apache.org/cassandra/
> ...ne sont que quelques exemples...
D'ailleurs sur ce point, une dépêche, un journal (ou mieux un article de Linux Mag !) recensant l'état des divers projets de key-value-stores (et autre imitations de Google BigTable / Amazon Dynamo) serait une bénédiction.
J'ai récemment cherché à faire le point, et ai découvert qu'il y a une orgie d'implémentations, toutes très jeunes, au point qu'il ai vraiment difficile de choisir le bon cheval.
J'avais recensé (en ne considérant que les implémentations libres ayant un nom sonnant "nom de tribu de hard tech/gabber" ;) :
Project Voldemort, CoucheDB, Ringo, Scalaris, Kai, Dynomite, ThruDB, MemcacheDB, Cassandra, HBase, Hypertable, MongoDB, Neptune, SimpleDB, Redis, Tokyo Tyrant + Toky Cabinet, Tripod, Dystopia.
Autrement dit, un bon paquet. Ceci m'a aidé, mais ce n'est pas complet ni à jour :
http://www.metabrew.com/article/anti-rdbms-a-list-of-distrib(...)
L'un de vous aurait des expériences à partager sur le sujet ?
[^] # Re: RDBMS sucks
Posté par ckyl . Évalué à 5.
Derrière tout ces produits tu as des objectifs un peu différents à chaque fois. Certains cherchent vraiment la performance sur des opération très simple et limités (exemple voldemort, tokyo cabinet). D'autre cherche un compromis entre structuration/fonctionnalités et performance (couchDB, HBase). De même la performance peut concerner le débit, la latence, le volume de donnée, la resistance aux lectures/écritures, la tolérance aux pannes etc.
Je pense que c'est pour cela qu'on voit apparaitre autant de solutions. Ce genre de techno n'est utile que pour des projets déjà gros et chaque fonctionnalité présente ou absente peu avoir un impact important sur le design de l'application et des performances. Pour le moment j'ai l'impression que tout le monde réécrit exactement ce dont il a besoin et que le consensus est plus difficile à trouver que pour un bête cache cle/valeur par exemple.
# Comment ne rien améliorer
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Nous avons souvent vu, chez des clients victimes de leur succès, une application devant faire face à des centaines de transactions par seconde alors qu’elle était prévue pour une dizaine seulement. Dans ce cas, on améliore le système par l’adjonction de nouveaux éléments qui permettent d’augmenter sa capacité transactionnelle.
J'aurais tendance à dire "dans ce cas, on vire le chef de projet et l'architecte logiciel, et on engage des gens qui font faire à leurs programmeurs un logiciel robuste dès de départ. Et si ça suffit pas, on rachète de la ram."
On fait pas un logiciel "pour une dizaine de transactions". On fait pour une seule, ou pour un nombre arbitrairement grand. La conception c'est un art et un métier. (Il faut réglementer l'industrie logicielle, définir des responsables pénaux en cas de bug, légiférer l'obtention ou la perte d'un titre de programmeur, architecte, chef de projet, bla, bla, etc)
[^] # Re: Comment ne rien améliorer
Posté par ckyl . Évalué à 10.
Premièrement des applis web complexes qui scalent linéairement ça n'existe tout simplement pas. Donc pour "un nombre arbitrairement grand" c'est du grand n'importe quoi. Chaque archi à ses limites et tu choisis l'archi en fonction du cahier des charges. Après tu itères en fonction de l'évolution du trafic, de l'usage, des nouvelles fonctionnalités, des bottlenecks etc.
Deuxièmement écrire quelque chose qui supporte 1, 10, 1000 ou 100 000 000 de transactions/ seconde ca n'a pas le même coût. Tu ne peux viser au plus haut rien que pour la beauté du geste, ca coute très cher. Plus tu tapes haut, plus tu t'éloignes du "modèle traditionnel" et plus tu dois faire du custom. Quand tu as atteint les limites d'écriture de ton master DB, il est temps de passer à autre chose: caching type memcached, passer du relationnel à du key/value, déporter tout tes traitements en batch, découper tes bases en shard etc.
Ce genre de trucs, en plus d'être couteux, c'est pas forcement une bonne idée de le faire à priori. Ca donne un système complexe et "optimisé" en aveugle sans savoir ce qui va réellement poser problème en prod (et ca évolue très très vite).
http://www.slideshare.net/techdude/scalable-web-architecture(...) résume bien les techniques courantes.
Bref pour une fois c'est bidon ce que tu dis. Attention j'ai pas dit qu'il fallait pondre une bouse dès le départ. non plus.
[^] # Re: Comment ne rien améliorer
Posté par Frederic Bourgeois (site web personnel) . Évalué à 3.
J'aurais tendance à dire dans ce cas, on vire le chef de projet et l'architecte logiciel, et on engage des gens qui font faire à leurs programmeurs un logiciel robuste dès de départ. Et si ça suffit pas, on rachète de la ram.
Ajouter juste de la ram je la note celle là, je me casserais moins la tête parfois ...
[^] # Re: Comment ne rien améliorer
Posté par Stéphane Davy . Évalué à 5.
Pfff, pourquoi on n'y pas pensé plus tôt?
[^] # Re: Comment ne rien améliorer
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
L'inertie est encore trop forte et l'appât du gain aussi.
Personnellement, j'attends le gros désastre qui fera enfin se dire "ah, j'aurais peut-être du choisir un prestataire de qualité".
Connaitre l'informatique ne fait pas de toi un informaticien, ou quelqu'un susceptible de prendre des décisions concernant un développement informatique. De même qu'un fan de médecine n'est pas médecin, et qu'un accro à la mécanique n'est pas garagiste. Et si ton garagiste n'y connaissais rien, mais ne faisait ça que pour l'argent, tu ne retournerais pas chez lui. Mais en CS/IT, l'offre est si pourrie que tu restes chez lui quand même…
Et pour le "sinon, on rachète de la ram", c'était pour faire allusion aux gens qui veulent résoudre un problème NP-complet plus rapidement (même si je veux croire que P=NP)
# PostgreSQL master/master
Posté par Laurent Cligny (site web personnel) . Évalué à 5.
http://www.postgresql.at/english/pr_cybercluster_e.html
Il s'agit d'un PostgreSQL 8.3 modifié pour supporter ce type de réplication. La licence est toujours la BSD.
[^] # Re: PostgreSQL master/master
Posté par Fabien . Évalué à 3.
Fût un temps où je les ai testé, aucun ne m'a apporté satisfaction, je me suis rabattu sur du drbd/heartbeat qui fonctionne bien.
[^] # Re: PostgreSQL master/master
Posté par Laurent Cligny (site web personnel) . Évalué à 2.
[^] # Re: PostgreSQL master/master
Posté par lululaglue (site web personnel) . Évalué à 2.
un retour d'expérience la-dessus ?
[^] # Re: PostgreSQL master/master
Posté par geb . Évalué à 2.
Soit du rw d'un coté et du ro de l'autre (pour une base de donnée cela peut s'envisager)
Soit un fs que tu puisse monter un rw sur les deux nodes,
- Ocfs2
- GFS si tu es sûr du redhat, centos etc
On trouve pas mal d'articles sur le sujet sur le net, les gens s'en servent par exemple pour faire de la virtualisation par dessus.
# Test de montée en charge
Posté par passant·e . Évalué à 8.
- OpenSTA - libre et gratuit
- Mercury LoadRunner - $$$$
- JMeter - libre et gratuit
Le fonctionnement est assez simple. imaginez que vous avez un magasin en ligne. Il y a un certains nombre d'étapes à respecter pour qu'une transaction soit terminée
- page d'accueil
- choisir un ou plusieurs produits : visiter le site
- S'identifier ou créer un compte
- Confirmer la commande
- Effectuer le paiement
- Page de confirmation de paiement
- Logout : des fois, des fois non
Sur chacune de ces étapes vous installer un timer. Ensuite, vous demandez à votre programme de simuler de quelques dizaines à plusieurs centaines d'utilisateur. Vous pouvez également, du côté des serveurs, installer des suivis de consommation processeur, memoire, disque dur, etc...
ET voilà. Une fois terminé vous pourrez-voir comment se comporte les durée de transaction en fonction du nombre de user et les ressources que cela consomme. Ce genre de teste permet de rapidement savoir ce qui pose problème. Par expérience, les problème qui arrivaient le plus souvent étaient un serveur de base de donnée sous dimensionné et une surutilisation des lock pour certaines opérations.
my 2cents
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: Test de montée en charge
Posté par Xavier MOGHRABI (site web personnel) . Évalué à 4.
A part JMeter, n'existe pas des logiciels libres permettant de faire des tests de montée en charge qui soient multi-OS ?
[^] # Re: Test de montée en charge
Posté par mortimer . Évalué à 3.
[^] # Re: Test de montée en charge
Posté par Laurent Morel . Évalué à 3.
On dirait un message de commercial chargé de la vente des produits...
Attention, pour avoir utilisé jmeter, je puis témoigner :
- qu'il peut être long de faire un plan de test réaliste
- qu'il est encore plus long de le rendre 'dynamique' (histoire que tous les pseudo-clients ne fassent pas toujours les mêmes recherches, etc. sinon on voit bien que cela va biaiser les résultats)
- que l'interprétation des résultats n'est pas immédiate (surtout si on souhaite agréger, comme tu le proposes, d'autres informations intéressantes : charges serveurs, etc.)
- qu'il subsiste un certain nombre de bogues et de limitations
Donc OK pour les tests de performance, mais c'est un mini-projet en soi.
[^] # Re: Test de montée en charge
Posté par passant·e . Évalué à 2.
ça doit être les restes de l'ex-consultant :-)
Je voulais juste présenter des applications qui permettent d'agir en amont, avant l'utilisation de système de répartition de charge. L'idée étant de ne pas doubler une infrastructure pour faire de la répartition de charge alors que le problème vient d'un programme mal codé.
Sinon c'est vrai que ces programmes ne s'utilisent pas en trois clics de souris ou deux modifications de fichiers de configuration.
Je trolle dès quand ça parle business, sécurité et sciences sociales
# Réplication Mysql master/master
Posté par Seb . Évalué à 5.
Attention, la réplication mysql master/master existe et est possible, mais avec certaines limitations : en particulier il n'y a pas de garantie de temps de réplication, elle est asynchrone. de plus il n'y a pas de gestion des conflits.
exemple de cas problématique :
j'insère une donnée avec auto incrément à gauche.
ma réplication a du retard. avant que ma donnée soit répliquée, une autre donnée est insérée à droite sur la même table. quand je rattrape mon retard, ma première donnée venant de gauche s'insère à droite. sauf que son id primaire est déjà pris par ma donnée insérée à droite --> conflit.
donc globalement la réplication master/master est possible, mais avec des limitations dont il faut tenir compte dans le développement de son appli.
[^] # Re: Réplication Mysql master/master
Posté par herodiade . Évalué à 10.
> j'insère une donnée avec auto incrément à gauche.
Heu non, super mauvais exemple.
MySQL dispose d'une paire de paramètres, auto-increment-increment et auto-increment-offset, qui permettent de faire en sorte que les valeurs générées par auto increments soient systématiquement différents sur les divers serveurs.
Exemple, si on a deux serveurs, on mettra :
* my.cnf du server1:
auto-increment-increment = 2 # le nombre total de serveur du cluster
auto-increment-offset = 1 # un nombre unique par serveur inclus entre 1 et auto-increment-increment
* my.cnf de server2 :
auto-increment-increment = 2
auto-increment-offset = 2
Dès lors, server1 ne générera que des incréments impairs et server2 que des incréments pairs : pas de conflits possibles sur les clefs primaires tant qu'on utilise l'auto increment natif.
Le même principe fonctionne avec n serveurs (on aura un "auto-increment-increment = n" partout, des "auto-increment-offset = x" distincts sur chaque serveurs, et les ids générés sur les divers serveurs seront des multiples de "n % x", toujours distincts).
Hop, la doc de ref : http://dev.mysql.com/doc/refman/5.1/en/replication-options-m(...)
> donc globalement la réplication master/master est possible, mais avec des limitations dont il faut tenir compte dans le développement de son appli.
Exact, disons qu'elle est asynchrone et qu'il n'y a pas de verrous partagés ; donc il est possible que des transactions exécutées sur divers serveurs simultanément s'exécutent bien, mais que leurs modifs respectives soient écrasées lors de la synchro, en particulier dans le cas des UPDATE (ce qui est assez différent d'un très gênant conflit sur une clef primaire).
Ca peux néanmoins suffire prou des applis très exigeantes en termes de répartition de charge et perfs et moins exigeantes en terme de garantie de persistance des modifs (cas courant pour des applis du "web 2.0 social"), ou du moins pour la partie (le "bulk") des données pouvant tolérer ces contraintes (il n'est pas forcément toujours nécessaire de répartir la charge en écriture sur un cluster master-master sur l'ensemble des données).
Le cas échéant (applis ayant un besoin impérieux de garanties), ça peux toujours servir pour préparer un hot spare redondant sur lequel on n'écrit pas (on peux y lire, l'utiliser comme un slave), mais dont on sait qu'il est vraiment pret à prendre la main de façon robuste et supportera bien les problèmes éventuels de flip-flop ; bref, assortis à keepalived ou hearbeat ou wackamole, un "slave amélioré" prêt à être promu en vrais master sans bidouille / intervention manuelle / exécution de script / bricolage de protection (pas besoin de s'inquiéter, par ex., que le précédent master déchu puisse être de retour et re-promu en master principal). L'automatisation de la reprise d'activité sur des environnement ne supportant que la réplication unidirectionnelle (master->slave) est toujours très dangereuse et fragile...
[^] # Re: Réplication Mysql master/master
Posté par Seb . Évalué à 2.
Merci pour les corrections/précisions !
[^] # Re: Réplication Mysql master/master
Posté par yannig (site web personnel) . Évalué à 1.
[^] # Re: Réplication Mysql master/master
Posté par _jean . Évalué à 1.
http://code.google.com/p/mysql-master-master/
Le projet permet, via un ensemble de scripts, de gérer un environnement mysql en réplication master-master en se basant sur des adresse ip virtuelles: 1 adresse d'écriture, 2 adresses de lecture (à utiliser ensuite pour effectuer du load balancing entre les master pour les lectures).
Un moniteur présent sur une 3ème machine se charge de distribuer les adresses ip en fonction de l'état des serveur mysql.
A l'instant t, 1 seul des master dispose de l'ip d'écriture, le second master est en mode read_only. 1 adresse de lecture est distribuée sur chaque master.
Dans le cas où 1 master ne répond plus, le moniteur va redistribuer les adresses ip sur le master qui répond encore.
Le moniteur gère également le monitoring de réplication, notemment au niveau du lag de réplication: si le serveur en lecture seule subit un lag de réplication, son ip de lecture lui est retirée afin de ne pas proposer aux clients de la base des informations obsolètes.
# Et les SSI ?
Posté par Jean Parpaillon (site web personnel) . Évalué à 2.
Pour rappel, ces solutions créent un SMP virtuel en aggrégeant les CPUs des noeuds d'une grappe. L'avantage est que ces solutions (au niveau noyau) ne demandent aucune configuration spéciale des applications. Vous pouvez augmenter le nombre de processeurs au fur et à mesure des besoins.
[1] http://kerrighed.org/
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: Et les SSI ?
Posté par yannig (site web personnel) . Évalué à 2.
Je tiens qu'en même à préciser qu'il ne s'agit en aucun cas d'une solution miracle. D'après ce que m'avait dit les gars de la société (je les avais vu lors d'une Linux expo ou un truc du genre), ça ne fonctionnait que sur certains types de traitement mais qu'effectivement, lorsque la solution fonctionne bien, il s'agit vraiment d'une solution miracle.
[^] # Re: Et les SSI ?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Et comme je l'ai vu de mes yeux planter il n'y a pas si longtemps, je conseillerais d'attendre l'ajout et la suppression de noeud à chaud qui devrait enfin arriver.
# et les annuaires ?
Posté par mortimer . Évalué à 5.
La gestion du failover sur les annuaires ldap est prévue dans le protocole, puisqu'il est possible de spécifier plusieurs serveurs lors d'une connexion. Un client respectueux des textes essaiera de lui-même successivement les différents serveurs en cas d'échec de connexion.
Pour ce qui est de la répartition de charge, les solutions sont multiples : referrals (découpage de l'arbre en sous branches servies par des serveurs différents), reverse proxy avec plusieurs annuaires derrière, etc.
La réplication des données d'un annuaire ldap n'est pas éloignée du cas des sgbd. D'ailleurs, avec openldap, il est possible d'utiliser un mysql par exemple comme backend de stockage des données (voir http://www.mysql.com/news-and-events/web-seminars/display-36(...) à ce propos). Dans le cas le plus courant, il s'agit de bases Berkeley, et la réplication est faite au niveau ldap (avec ici encore plusieurs solutions et plusieurs configurations possibles). Des produits comme l'annuaire de Sun, ou de Redhat/Fedora (même racine que Sun) communiquent sur leur capacité à monter des configurations à 4 serveurs avec deux maîtres (donc réplication mutlimaître entre eux) et chacun un esclave (http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Managin(...) voire 4 maîtres et n esclaves (http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Managin(...) Openldap, après avoir longtemps refusé d'officialiser le support de la réplication multimaître (c'était un fonctionnalité non documentée pendant un moment, mais les développeurs ont toujours pensé que ce genre de conf apportait plus de risques que d'avantages, et qu'il était rarement impossible de s'en passer http://www.openldap.org/cgi-bin/wilma_hiliter/openldap-softw(...) http://www.openldap.org/lists/openldap-software/200206/msg00(...) a fini par l'intégrer officiellement dans la version 2.4 (http://en.wikipedia.org/wiki/OpenLDAP#Release_summary).
Enfin voilà, quoi.
[^] # Re: et les annuaires ?
Posté par herodiade . Évalué à 2.
D'autant que si les écritures sont vraiment nombreuses, il y a d'autres solutions que le multimaster horizontal/non hiérarchisé : le protocole supporte le fait de rediriger les écritures (et aussi les lectures, en fait) sur des parties de l'arbre vers divers serveurs dédiés. En gros, le "sharding" est prévu d'emblée, c'est mignon tout plein.
> D'ailleurs, avec openldap, il est possible d'utiliser un mysql par exemple comme backend
> de stockage des données ([...]). Dans le cas le plus courant, il s'agit de bases Berkeley, et
> la réplication est faite au niveau ldap [...]
J'en profite pour signaler, parce que c'est un fait souvent peu connu, que BDB dispose de fonctionnalités de réplication :
http://www.oracle.com/technology/documentation/berkeley-db/d(...)
(sans rapport immédiat avec le commentaire parent, car effectivement dans le cas d'utilisation décrit, la réplication applicative native est bien plus judicieuse).
[^] # Re: et les annuaires ?
Posté par yannig (site web personnel) . Évalué à 2.
- réplication temps réel pour fail-over
- réplication via LDAP de rebond (pour des raisons de sécurité, on ne va répliquer qu'une partie de l'arbre LDAP et on le proposera à nos partenaires via une DMZ)
Contrairement à une base, l'annuaire LDAP n'est que très rarement sollicité pour l'hébergement et la mise à jour fréquente des données. J'imagine qu'il doit y avoir des situations qui obligent à une mise en place de répartition de charge (on trouvera toujours des fous partout !). D'autant que la scalabilité doit être assez bonne étant donné le ratio écriture/lecture. Merci pour la remarque, j'essaierai d'en parler une prochaine fois :).
# Ça tombe bien
Posté par MCMic (site web personnel) . Évalué à 5.
Par contre le mien causera plus de la réplication multi-maître (éventuellement asynchrône).
J'ai prévu d'y présenter mes résultats de test pour SymmetricDS et Bucardo, ça complètera tes retours.
Bon après je sais pas quand est-ce que je ferais ce journal, mais ça devrait finir par arriver ><
[^] # Re: Ça tombe bien
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
[^] # Re: Ça tombe bien
Posté par patrick_g (site web personnel) . Évalué à 6.
# Autre article
Posté par geb . Évalué à 5.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.