équilibrage de charge de plusieurs instances drupales horizontales

J'ai développé une WebAPI REST à l'aide du module Services. Ça fonctionne bien. J'ai un client de cette API avec une utilisation projetée nécessitant une mise à l'échelle horizontale de mon instance Drupal. Notez qu'en raison de la nature de mon API, nécessitant des ressources CPU et GPU importantes, je ne peux pas utiliser de serveurs cloud. De plus, en raison de la nature de mon API, les instances Drupal doivent s'exécuter sur le système d'exploitation Windows. (Mon application nécessite un logiciel uniquement disponible sur Win64.) J'ai maintenant un serveur assez costaud dans une colocalisation, et pour ce client ambitieux, je prévois de faire évoluer horizontalement mon matériel de la manière suivante:

• Un serveur CentOS exécutant HaProxy comme équilibreur de charge frontal,
• Deux pour commencer, avec plus si nécessaire, des serveurs Windows Server 2008 R2 hébergeant Drupal,
• Un serveur de base de données CentOS fournissant une base de données unique pour les multiples instances Drupal,
• Un serveur de base de données CentOS fonctionnant en mode de réplication en cas de décès du serveur DB 1.

Mes questions concernent le fonctionnement de l'équilibreur de charge HaProxy. Je suppose que les sessionIds créés par les instances Drupal seront uniques les uns des autres. L'équilibreur de charge examine-t-il l'ID de session et achemine-t-il toutes les demandes vers le même serveur qui a produit cet ID de session? Comment une communication REST WebAPI fonctionnerait-elle si l'équilibrage de charge entraînait le transfert de chaque demande d'API vers un serveur différent? Est-ce que toutes les données référencées par WebAPI doivent être stockées dans la base de données parce que je ne peux pas garantir que plusieurs demandes d'API pour la même ressource seront routées vers la même instance Drupal?

Avoir plusieurs serveurs Web derrière un équilibreur de charge / proxy inverse est assez courant pour Drupal et bien pris en charge. Le vernis est généralement utilisé dans le monde Linux parce que cette chose est incroyablement rapide lorsqu'il est possible de l'utiliser réellement, ce qui signifie des visiteurs anonymes. Ce qui n'est évidemment pas le cas pour votre site.

Les sessions sont stockées dans la base de données par défaut, ce n'est donc pas un problème. La seule autre chose qui doit être partagée entre tous les serveurs est le répertoire des fichiers publics et tout autre comme les fichiers privés si vous utilisez quelque chose comme ça). Dans la plupart des cas, un système de fichiers partagé / distribué comme NFS est utilisé pour cela, bien qu'il existe des approches plus avancées. Sur un site où je suis impliqué est le système de fichiers fourni par un autre serveur qui est un montage NFS sur les serveurs Drupal (donc l'accès y est lent) et est distribué sous un domaine différent par Lighthttpd. Mais encore une fois, cela n'est probablement pas si pertinent pour vous que vous n'allez pas beaucoup serveur d'images et de fichiers CSS, je suppose.

Comme mentionné par rocketeerbkw, il existe des backends de cache pour Memcache, Redis et autres. Jusqu'à présent, je n'ai utilisé que Memcache, mais j'ai récemment commencé à étudier Redis et cela semble très prometteur, mais je ne sais pas s'il est disponible pour Windows. Cependant, il serait possible de configurer un serveur Linux distinct à utiliser pour le cache. Drupal 7 s'appuie fortement sur les caches, pouvoir les retirer de la base de données est très important pour deux raisons:

1. Des outils comme Redis et Memcache sont conçus pour des recherches rapides basées sur des clés et ils gardent toujours leurs données en mémoire pour rendre la recherche aussi rapide que possible. Ils ont également intégré la prise en charge du nettoyage automatique des anciennes données de cache si la limite configurée se rapproche.

2. Peut-être encore plus important, cela aide à réduire la charge de la base de données. Une fois la configuration de base en place, l'ajout de serveurs Web supplémentaires est facile. Une fois que vous commencez à atteindre les limites d'un seul serveur de base de données, les choses deviennent beaucoup plus compliquées et vous devez vous pencher sur des choses comme la réplication maître / maître (Drupal 7 n'a pas vraiment beaucoup à gagner des environnements maître / esclave).

Donc, c'est essentiellement votre propre API dont vous devez vous occuper. Si possible, vous devez vous assurer que tout est toujours disponible sur tous les serveurs. Vous pouvez utiliser soit la base de données, le système de fichiers ou autre chose (Drupal peut également utiliser MongoDB pour stocker certaines données, par exemple des champs). Si ce n'est pas une option, vous devrez utiliser des sessions persistantes afin que les utilisateurs se retrouvent toujours sur la même instance. Vous devriez cependant vraiment essayer d'éviter cela car si l'un des serveurs tombe en panne, alors tous les utilisateurs qui se trouvaient sur ce serveur doivent se reconnecter à un autre serveur, ce qui risque de perdre des données.

Par défaut, PHP stocke les sessions sur le disque. Si un utilisateur se connecte au serveur 1, puis atteint le serveur 2, il sera déconnecté. Il existe quelques options pour résoudre ce problème:

1. Ne stockez pas de sessions sur le disque
2. Assurez-vous que les utilisateurs touchent toujours le même serveur
3. Montez un système de fichiers partagé sur tous les serveurs

Pour implémenter # 2 et répondre à vos questions sur HAProxy; Dans la configuration la plus basique, vous pouvez l'exécuter en mode TCP et utiliser l'algorithme d'équilibrage "source" ( http://cbonte.github.com/haproxy-dconv/configuration-1.4.html#4-balance ) pour vous assurer que les utilisateurs atteignent le même serveur. Vous devriez lire les documents pour déterminer s'il y a des inconvénients pour vous en utilisant cette approche.

Pour # 1, vous pouvez utiliser un magasin de clés / valeurs comme Redis ou Memecached auquel tous vos serveurs se connecteraient et récupéreraient des sessions. Cela permet de charger / enregistrer les sessions très rapidement et vous pouvez également l'utiliser comme cache Drupal partagé.