Où l’on reparle de memcache

Le 13 juillet 2011 — par

Un faux article style « courrier des lecteurs » histoire d’agrémenter votre before de feu d’artifice. Julien est tombé sur mes articles concernant l’infrastructure de VDM et notamment celui où je parle de memcache. Après avoir lu entre les trolls, il s’est inspiré de mon schéma pour la création de son site, et me pose quelques questions.

betacie_network.png
L’infrastructure que j’ai montée pour VDM/FML

J’ai vu ton schéma w1, w2, etc., et serveurs MySQL en réplication rotative de master/slave (malgré le risque que l’un plante). J’avais en tête de faire à peu près la même chose que toi à quelques petites différences :

Est-ce que chacun de tes serveurs w ne sont destinés qu’à Apache, ou est-ce qu’ils sont également des serveurs MySQL slaves liés aux masters rotatifs ?

Personnellement, je compte utiliser tous les serveurs Apache en réplication MySQL, et faire les SELECT en localhost, et les opérations de UPDATE|INSERT|DELETE sur les masters par loadbalancer (avec APC). De cette manière, chaque serveur est une copie exacte de tous les autres serveurs et fonctionnent quasi-indépendamment les uns des autres…

Qu’est-ce que tu en penses ?

Mes serveurs Apache ne servent qu’au traitement PHP, avec du CDN via lighttpd/nginx et du memcache pour utiliser la RAM non-utilisée par les deux process précédents.

La solution que tu évoques peut être pas mal, mais avec des inconvénients :

– Plus il y a de serveurs MySQL plus il y a de maintenance à faire dessus, ce qui représente beaucoup plus de temps en moyenne que des serveurs Apache.

– Tes slaves ont par définition un master, si jamais le master vient à tomber il faut que les X slaves connectés dessus puissent récupérer leurs données ailleurs qu’en localhost pour les SELECT.

– Tu auras quand même une réplication circulaire au finale puisque tu évoques plusieurs masters. En théorie les données seront identiques, mais lors d’une panne la récupération sur le master défaillant ainsi que les slaves sera plus longue et tu risques de délivrer des données erronées sur les Apache qui servent de slave à ce fameux master défaillant. Donc à prévoir aussi.

En conclusion, il faut que tu testes si doubler les connexions MySQL est plus intéressant que de n’avoir qu’une seule connexion et memcacher un maximum de données pour sauver des SELECT.

Personnellement j’ai choisi cette solution de grosse intégration memcache car les serveurs ne demandent presque pas de maintenance et sont beaucoup plus légers, installables sans problème sur mes petits serveurs Apache. Mais ça se décide en fonction de ton pourcentage de lecture / écriture.

Pour résumer le suite de notre échange, on a évoqué le fait que via son schéma, l’avantage est le déploiement rapide, mais l’inconvénient est qu’un master entraîne beaucoup plus de serveurs dans sa chute.


Le schéma de Julien pour son infrastructure

Les conclusions (temporaires, comme toujours sur Internet) de notre échange ont été de son côté une augmentation de l’utilisation de memcache pour les requêtes les plus utilisées, la mise en place d’outils pour s’adapter rapidement à la mise hors-ligne d’un des masters en réplication circulaire, l’utilisation de MyISAM pour une maintenance plus aisée par rapport à InnoDB, surtout en cas de panne.

De mon côté, le schéma de l’infrastructure VDM/FML ci-dessus a un peu évolué depuis l’année dernière, mais j’en parlerai une fois que tout sera en production. :)

S'abonner au flux RSS du blog
Recevoir les nouveaux articles par e-mail :