[Évolution] PluXml en architecture distribuée !
Billy Bob Thornton
Member
Bonjour,
J'ai un besoin pour lequel PluXml correspond parfaitement, le CMS me plaît beaucoup mais je me heurte à une difficulté pour laquelle il n'est pas taillé. Ceci peut être corrigé assez facilement, d'autant plus que le problème risque de se poser, et s'est même déjà certainement posé, pour d'autres utilisateurs.
Je vais exposer mon problème et l'idée que j'ai eu pour le résoudre, seulement il faudrait que la communauté y trouve un intérêt :
Donc, j'envisage d'utiliser PluXml dans le cadre d'un site tournant sur une architecture distribuée, c-à-d dans une infrastructure composée de plusieurs machines dédiées, pour des soucis de redondance et de répartition de charge. PluXml sera un des composants de ce site.
* Problème :
Le problème de PluXml c'est que son architecture n'est pas adaptée à ça. En effet, les données dynamiques se trouvent non pas dans une base de données mais sous forme de fichiers XML à l'intérieur de l'arborescence du système de fichiers.
Donc vous avez trois options :
- vous faites tourner votre PluXml sur une seule machine, sans répartition de charge et sans redondance des données. Simple et efficace, mais la machine doit être en mesure d'absorber tout le trafic et il ne faut pas que le disque lache sinon vous avez du downtime le temps de réparer ;
- vous dupliquez l'arborescence PluXml sur plusieurs machines et vous faites tourner un script de réplication mais alors vous avez le problème de la collision des écritures, bref assez ingérable. Franchement très ingérable ;
- vous montez le répertoire qui contient les articles et les commentaires sur un serveur de fichiers RAID, mais comme mon infrastructure distribuée ne se base pas là dessus, je n'ai pas envie de rajouter un serveur de fichiers RAID en plus.
* Solution envisagée :
La solution que j'envisage est à la fois simple et efficace, mais c'est aussi un peu de l'hérésie pour un CMS sans base de données puisqu'on va, en quelque sorte, s'appuyer sur une base de données. Mais sans abandonner le principe de PluXml qui consiste à utiliser des fichiers. Et sans faire de modifications importantes dans PluXml non plus.
Mon idée est d'offrir une option pour que ceux qui le souhaitent puissent utiliser le système de gestion de fichiers distribué "GridFS" de MongoDB. MongoDB est une base de données NoSQL, ce n'est pas la fonction base de données qui m'intéresse, PluXml continuera à s'appuyer sur des fichiers XML, mais la fonction système de fichiers de MongoDB. Très concrètement MongoDB peut se charger de la gestion de fichiers qu'il voit dans ce cas comme des données et qu'il manipule avec son moteur base de données. Avec tous les avantages de la base :
- la base, et donc les fichiers, peuvent être répartis et dupliqués, sur plusieurs serveurs MongoDB de manière totalement transparente et automatique. Dans une telle infrastructure la charge est automatiquement répartie et les données sont dupliquées afin que le système continue de fonctionner même en cas de panne matérielle d'un des composants.
* Comment faire :
Il suffit simplement que PluXml remplace les appels au système de fichiers PHP par des appels à une API qui se chargera, soit de faire appel au système de fichiers PHP (même fonctionnement qu'actuellement), soit au système de fichiers MongoDB. D'ailleurs de cette manière l'API pourra être enrichie dans l'avenir pour prendre en charge tout autre système de fichiers distribué.
PluXml ne devra faire appel à cette API que pour la partie dynamique (les articles, les commentaires, etc).
Je peux écrire l'API par contre je ne connais pas suffisamment PluXml pour le modifier, d'où mon post ici : l'équipe de PluXml serait-elle intéressée par ce projet ?
Plus d'infos sur MongoDB : http://www.mongodb.org/
J'ai un besoin pour lequel PluXml correspond parfaitement, le CMS me plaît beaucoup mais je me heurte à une difficulté pour laquelle il n'est pas taillé. Ceci peut être corrigé assez facilement, d'autant plus que le problème risque de se poser, et s'est même déjà certainement posé, pour d'autres utilisateurs.
Je vais exposer mon problème et l'idée que j'ai eu pour le résoudre, seulement il faudrait que la communauté y trouve un intérêt :
Donc, j'envisage d'utiliser PluXml dans le cadre d'un site tournant sur une architecture distribuée, c-à-d dans une infrastructure composée de plusieurs machines dédiées, pour des soucis de redondance et de répartition de charge. PluXml sera un des composants de ce site.
* Problème :
Le problème de PluXml c'est que son architecture n'est pas adaptée à ça. En effet, les données dynamiques se trouvent non pas dans une base de données mais sous forme de fichiers XML à l'intérieur de l'arborescence du système de fichiers.
Donc vous avez trois options :
- vous faites tourner votre PluXml sur une seule machine, sans répartition de charge et sans redondance des données. Simple et efficace, mais la machine doit être en mesure d'absorber tout le trafic et il ne faut pas que le disque lache sinon vous avez du downtime le temps de réparer ;
- vous dupliquez l'arborescence PluXml sur plusieurs machines et vous faites tourner un script de réplication mais alors vous avez le problème de la collision des écritures, bref assez ingérable. Franchement très ingérable ;
- vous montez le répertoire qui contient les articles et les commentaires sur un serveur de fichiers RAID, mais comme mon infrastructure distribuée ne se base pas là dessus, je n'ai pas envie de rajouter un serveur de fichiers RAID en plus.
* Solution envisagée :
La solution que j'envisage est à la fois simple et efficace, mais c'est aussi un peu de l'hérésie pour un CMS sans base de données puisqu'on va, en quelque sorte, s'appuyer sur une base de données. Mais sans abandonner le principe de PluXml qui consiste à utiliser des fichiers. Et sans faire de modifications importantes dans PluXml non plus.
Mon idée est d'offrir une option pour que ceux qui le souhaitent puissent utiliser le système de gestion de fichiers distribué "GridFS" de MongoDB. MongoDB est une base de données NoSQL, ce n'est pas la fonction base de données qui m'intéresse, PluXml continuera à s'appuyer sur des fichiers XML, mais la fonction système de fichiers de MongoDB. Très concrètement MongoDB peut se charger de la gestion de fichiers qu'il voit dans ce cas comme des données et qu'il manipule avec son moteur base de données. Avec tous les avantages de la base :
- la base, et donc les fichiers, peuvent être répartis et dupliqués, sur plusieurs serveurs MongoDB de manière totalement transparente et automatique. Dans une telle infrastructure la charge est automatiquement répartie et les données sont dupliquées afin que le système continue de fonctionner même en cas de panne matérielle d'un des composants.
* Comment faire :
Il suffit simplement que PluXml remplace les appels au système de fichiers PHP par des appels à une API qui se chargera, soit de faire appel au système de fichiers PHP (même fonctionnement qu'actuellement), soit au système de fichiers MongoDB. D'ailleurs de cette manière l'API pourra être enrichie dans l'avenir pour prendre en charge tout autre système de fichiers distribué.
PluXml ne devra faire appel à cette API que pour la partie dynamique (les articles, les commentaires, etc).
Je peux écrire l'API par contre je ne connais pas suffisamment PluXml pour le modifier, d'où mon post ici : l'équipe de PluXml serait-elle intéressée par ce projet ?
Plus d'infos sur MongoDB : http://www.mongodb.org/
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
C'est le genre de chose que j'ai mis en place au boulot pour une base Oracle (sauf la partie HAproxy et multipath) et franchement ça dépote. Le SAN (iscsi) est vue comme un disque local par le serveur ensuite tu applique ce que tu veux comme système de fichiers (ne pas oublier la couche LVM), tu a l'avantage d'avoir de la souplesse dans la gestion de l'espace disque, le calcul et la gestion des I/O déporté sur une autre machine.
J'ai un string de l'array
Tu peux aussi très bien monitorer les I/O d'un répertoire est déclencher sur évènement un script ou programme (suivant l'OS) pour aller copier les nouveaux fichiers ou fichiers modifiés sur un espace dédié pour avoir une copie des fichiers sensibles.
La solution simple flipflip la décrite: un lecteur san pour les datas monté en RAID
Je ne connais pas le contexte exact de ce que tu veux faire, mais une démarche professionnelle efficace et de s'appuyer sur des solutions robustes et éviter des solutions "bancales" pour faire des économies de bouts de chandelles. Mieux vaut prévoir un budget, et revoir peut être à la baisse ses ambitions, mais au moins tu auras un parc informatique qui ne ressemblera pas à une usine à gaz.
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
Alors déjà il ne faut pas parler de SAN ou de RAID mais de NAS :
- le SAN ne permet pas d'avoir un stockage persistant sur 2 machines au même instant (mode block - corruption de FS si montage sur 2 nodes en //),
- le RAID est une technologie de protection des données
Ce que font bcp d'hébergeur dans le cadre de cluster HTTP c'est d'avoir :
- un serveur NFS (NAS) avec des disques en RAID où seront tes fichiers PluXml => ton SPOF est ici
- des serveurs HTTP en client NFS pour monter l'arborescence unique de ton serveur NFS. Tu peux donc mettre x serveurs HTTP sans problème.
Ensuite, si tu veux vraiment du distribuer il faut regarder au niveau des gestionnaire de volume de type GFS où là tu n'auras pas de SPOF.
++
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
Le nfs est effectivement fait pour le montage de volume en réseau, d'ou son nom Network File System le hic est qu'il est bien moins performant que passer par un volume en SAN. Il y a bien quelques paramètres pour optimiser la taille de paquets envoyer et reçu mais les perf s'écroule rapidement... Du moins c'est les test que j'ai fais au boulot, surtout dans le cas beaucoup de petits fichiers ce qui est le cas de PluXml.
Il faudrait que tu nous donne un peut plus d'info sur le contexte d'utilisation, l'existant, l'attente, les compétences et surtout le budget.
J'ai un string de l'array
N'exagérons pas, le NAS reste très performant surtout sur notre cas d'école (un site web)
@Billy : pour résumer je te conseille :
- soit un export NFS (un serveur NFS et x client HTTP). OVH avec l'offre NAS HA est pas mal
- soit une étude avec GlusterFS http://www.gluster.org/
- j'ai entendu parler d'un outil rsync avec inotify qui synchronise automatiquement tes datas sur plusieurs serveurs dés qu'une modification est faite sur ton FS.
Je comprends rien à la discussion sauf le dernier terme que tu viens d'utiliser (BEURK)
Un point qui n'a pas été abordé par Billy Bob Thornton est une estimation du nombre d'articles et de visiteurs. Je sais bien qu'il faut prévoir le pire mais il est peut être trop tôt pour sortir le bazouka pour tuer une mouche. Il me semble que PluXml est assez bien construit et optimiser pour alléger la charge côté serveur, ensuite memcache ou d'autre truc du genre peut aider.
Si c'est pour monter une infra qui dépoile les ours polaires mais qu'au final tout le budget du projet a été mis dans l'infra... Comment financer le reste ?
Une petite astuce peut être, avoir un serveur avec énormément de mémoire et charger un max de fichiers en mémoire avec un filesystem en mémoire. Pour choisir quel fichier charger faire un système de stats qui compte le nombre de fois qu'un fichier est appelé, plus le chiffre en grand plus il a de chances d'être en mémoire. Bien sur c'est valable que pour la lecture il faut penser de temps en temps à faire un backup sur disque physique des fichiers modifiés. Au début ça sera un peu lent le temps d'établir une base de stats. Il est facile de rediriger le répertoire data/articles par exemple en faisant un lien symbolique vers le fs en mémoire.
J'ai un string de l'array