WPMU et scalabilité (Créer un compte)

  • Statut : non résolu
6 sujets de 1 à 6 (sur un total de 6)
  • Auteur
    Messages
  • #450382
    quentin
    Membre
    Chevalier WordPress
    315 contributions

    Bon ben lancons la pompe ;).
    Alors voila comme premier sujet, celui qui m’a probablement posé le plus de problèmes depuis que unblog a atteint une taille honorable, la scalabilité. Par scalabilité j’entends réussirà traiter un nombre illimités d’utilisateurs, simplement en rajoutant des machines et en ayant le minimum de changement software à effectuer une fois le setup en place.
    Le premier problème qui s’est posé à moi est celui du nombre de répertoires dans la section d’upload. Passé 32000 utilisateurs, linux coince. Alors bien sur on peut effacer les blogs innactifs, ca marche bien, mais à terme on finit toujours par atteindre le nombre fatidique.
    Le 2eme problème est quand on se met à avoir besoin de 2 serveurs. La, on peut commencer par séparer base de données et front, c’est bien mais c’est un peu reculer pour mieux sauter, et quand arrive le besoin d’une 3eme machine, ca ne marche plus.

    Perso, j’ai fait un setup qui me permet de croitre de manière illimitée au niveau du nombre d’utilisateurs, et qui résout un peu tous ces problèmes à la fois:
    – j’ai mis un reverse proxy devant le site (pour l’instant c’est mod_rewrite dans l’apache du serveur de front qui fait le job, quand j’aurai besoin de mon prochain serveur je vais surement regarder un reverse proxy plus performant.
    – mod_rewrite me permet de router les users en fonction de leur nom vers une install se trouvant sur une des machines en backend, en utilisant des noms fictifs au niveau de BIND, et en ayant modifié légèrement wp-settings pour que les pages soient générées comme si elles venaient toutes du serveur de front. Derrière, j’ai une install de WPMU par lettre, synchronisées par rsync. J’ai un blog de test dans un environnement a part dans lequel je déploie les nouvelles fonctions, les teste, puis rsync vers les différentes installs du système.
    – ce qui est cool, c’est que c’est facile avec MU de faire ca, les tables sont déja séparées pour chaque utilisateur, ceux-ci peuvent donc etre déplacés à droite à gauche facilement. Un serveur devient trop chargé ? Je prend les utilisateurs d’une lettre et je les mets sur un autre serveur. Je dispose aussi de 32000 blogs potentiels par lettre, ca laisse le temps de voir venir.
    – Toutes les instances se connectent sur une seule machine pour les tables principales. Comme ca, pas de réplication, de master/slave à gérer, de nécessité de VPN et de bande passante de fou. Simplement des modifs à faire dans le wp-db pour savoir ou exécuter chaque requete.
    – autre avantage, les modifs à faire dans MU sont minimes. Chaque instance se comporte comme un MU à part. Faut faire quelques modifs au script de newblog aussi pour qu’il crée les nouveaux blogs dans la bonne instance, selon leur première lettre.

    Bref, le tout est résumé la (le doc est un peu vieux et pas 100% correct, mais l’idée est la):
    http://www.creerunblog.fr/scaling.gif

    Il n’y a pas trop de désavantages que j’ai pu constater jusqu’à maintenant dans ce setup. Son seul inconvénient selon moi par rapport à un setup basé sur de la réplication, c’est qu’il ne permet pas la redondance (enfin c’est possible mais faudrait faire plus de boulot).

    #590899
    AmO
    Participant
    Maître WordPress
    4447 contributions

    Ton système est très intéressant, mais il y a des limites, plutôt problématique.

    Pour répartir l’inscription des blogs sur tes serveurs, tu découpe selon les lettres de l’alphabet, et tu travaille avec blind, d’accord.

    Mais il y a forcément des lettres à fort succès et des lettres peu utilisé
    (d’ailleurs tu as une répartition blogs par lettre ?)

    Le cas des lettres peu utilisé n’est pas intéressant.
    Poussons le raisonnement un peu plus loin, imagine, tu as 20 000 blogs commençant par S.
    Ton serveur sera à pleine charge, comment tu vas gérer cette lettre à l’avenir ? si ton serveur est à 100% ?

    Re-découper la base en question selon les 2ères lettres me semblent peu réalisable.
    Ce cas t’es déjà arrivé ?
    Tu as fait comment, si c’est le cas ?

    Pour mon projet, le choix de l’architecture sera statué la semaine prochaine, nous allons surement nous orienté vers une semi redondance. (je préciserai un peu la chose, une fois le choix fait.)

    #590900
    quentin
    Membre
    Chevalier WordPress
    315 contributions

    cela ne m’est pas encore arrivé non, pour qu’un serveur entier ne serve pas une lettre seule il me faudra encore pas mal de croissance (il y a de la marge, pour l’instant chaque serveur tiens au moins 5-6 lettres). Le jour ou ca arrivera, c’est effectivement le découpage à l’intérieur de cette meme lettre qui permettra le dispatching du load sur plusieurs machines. Il ne s’agit que de simples regles mod_rewrite, et j’ai un petit script qui me créer un nouvel environnment / déplace les utilisateurs tout ce qu’il y a de plus simplement.
    Pour moi ca fait plutot partie des avantages de la solution, etre capable de scaler sur plus de serveurs demande simplement a rajouter une regle mod_rewrite et déplacer quelques tables de temps en temps.

    #590901
    odupuis
    Membre
    Initié WordPress
    6 contributions

    Bonjour,

    Pour ce qui est de la scalabilité, je pense que le caching des pages de squid, diminue drastiquement les besoins en puissance. Cependant l’exigence de redondance m’a imposé de faire tourner WPMU sur (au moins) 2 machines. Hors le problème de la base de donnée (je vais y revenir) le seul problème posé par faire tourner wordpress sur plusieurs machines est la duplication des médias uploadés par l’internaute. Pour cela nous avons rajouté des hook synchronisant chaque fichier uploadé vers les autres machines. Cette synchro passe par un lien dédié en Gigabit.
    A l’avenir (cette année), nous allons connecter les machines sur un filer NFS, nous supprimerons les hooks et pourrons ainsi ajouter (presque) autant de noeud que nous le voudrons. Les machines dans cette architecture servent : de générateur de page pour alimenter le cache squid et de serveur de page d’administration (/wp-admin/…).

    Pour ce qui est de la base de données, pour l’instant nous avons une réplication Maitre/Esclave MySQL et une procédure de bascule (non automatique donc). Mais la réplication MySQL est très décevante car elle n’offre aucune garantie ni outil de diagnostique sur l’état du réplicat puisque qu’aucun méta-data n’est transmis du maitre vers l’esclave. Comme le disait AmO dans la rubrique performance, je pense que la solution est la migration vers PgSql (ou Oracle, mais bon c’est cher). Il est possible que MySql évolue à ce sujet mais je n’ai rien vu venir au sujet de la réplication. Compte tenu de la simplicité des requêtes manipulées par WPMU je pense que cette migration doit être relativement simple.

    #590902
    quentin
    Membre
    Chevalier WordPress
    315 contributions

    oliver, vous utilisez squid au monde ?
    Pour l’instant j’utilise apache comme reverse proxy sans cache, mais je me tate pour passer sur un squid en front avec le cache activé. Il y a d’autres options comme nginx et quelques autres verse proxy qui ont l’air assez efficaces, mais c’est dur de trouver du feedback.

    #590903
    quentin
    Membre
    Chevalier WordPress
    315 contributions

    nvm je viens de voir ton autre post, je m’atele à sa lecture 😉.

6 sujets de 1 à 6 (sur un total de 6)
  • Vous devez être connecté pour répondre à ce sujet.