Wordpress sur la réplication IIS avec robocopy


10

Nous avons configuré un environnement wordpress sur 4 serveurs IIS. Nous envisageons d'utiliser une tâche planifiée déclenchant un script robocopy pour répliquer le répertoire wordpress toutes les 5 minutes.

Quelles sont les opinions sur une telle approche? Quelqu'un a-t-il déjà utilisé ceci ou similaire?


Que sont les 4 serveurs IIS physiques ou VM? Que répliquez-vous les données ou les bases de données et les configurations? Je ne sais pas pourquoi vous auriez 4 serveurs 1 en tant que maître (je suppose) et les autres étant passifs si vous essayez d'atteindre HA qui ne fonctionnera pas.
Anthony Fornito

1
deuxième question (et probablement la plus importante) pourquoi utilisez-vous wordpress sur windows?
Anthony Fornito

Merci @AnthonyFornito pour votre réponse. Exécution de wordpress sur Windows pour des raisons internes. J'essaie juste de travailler avec ça. Je suis après la réplication des fichiers du site Web (la réplication de la base de données est déjà gérée via MYSQL). Les frontaux sont des machines virtuelles sur Azure. Je recherche principalement une solution où tous les frontaux partagent les mêmes fichiers de site Web. Y a-t-il quelque chose que vous suggéreriez?
joebegborg07

Réponses:


12

Avoir 4 serveurs frontaux qui partagent les mêmes fichiers en même temps et chacun est capable d'écrire sans utiliser une sorte de DFS ou un programme tiers dédié à la synchronisation d'annuaire serait une jument de nuit.

Avec l'azur, vous pouvez examiner 3 choses.

  1. Stockage partagé, il peut y avoir des coûts associés à l'obtention de votre propre stockage dédié, et je ne suis pas sûr de la configuration, mais Azure le propose. Cela garantirait que tous vos fichiers sont disponibles pour chaque serveur dès qu'ils sont écrits.

  2. Azure DFS, DFS est un outil de synchronisation d'annuaire basé sur Windows qui fonctionne plutôt bien, également pas sûr du coût, mais la configuration pourrait être un peu plus facile. DFS fonctionne de manière asynchrone, il y a donc un peu de retard mais pas beaucoup.

  3. (Je vais expliquer comment cela serait fait et ensuite ne plus en parler, car c'est une idée horrible et échouera.) Créez un script qui comparera d'abord les données sur les quatre serveurs, puis copiera les données différentielles. Vous auriez besoin de partager chaque répertoire sur le serveur exécutant le script, l'autorisation de configuration afin que le serveur puisse lire et écrire, puis dépanner dépanner, dépanner.

L'une ou l'autre des options ci-dessus fera l'affaire, si votre travail dépend de ce travail, je vous recommande de rester à l'écart de l'option 3.

Cela étant dit, et vous n'essayez pas de dépenser de l'argent, suivez les étapes ci-dessous.

  1. regardez un programme appelé "synchronisation de fichiers gratuite". Il y a de très bonnes fonctionnalités dans la version gratuite, je pense qu'il existe une version payante, mais je ne suis pas sûr des améliorations que vous obtenez. Je l'ai utilisé dans beaucoup de mes environnements de développement en essayant de réaliser quelque chose de similaire à ce que vous cherchez à faire et j'étais trop paresseux pour configurer DFS.

  2. Rendre un seul serveur accessible en écriture, cela peut être facilement fait en configurant un URI sur chaque serveur qui indique si créer un article allez sur ServerA, ou une réécriture d'URL dans votre web.config, ou étant que WordPress est utilisé par php:

    en-tête («Emplacement: http://myhost.com/mypage.php »);

Chacun prendra un peu de codage et de connaissances PHP, IIS.

  1. La partie vraiment amusante, avec ServerA étant le serveur auteur (uniquement serveur accessible en écriture) comment diriger le trafic vers ServerB, ServerC et ServerD pour une lecture sans équilibreur de charge?

Réponse courte, vous ne pouvez pas, eh bien ce n'est pas tout à fait vrai, j'ai eu une fois un client qui était catégorique de ne pas utiliser un équilibreur de charge, il a pu grâce à une série de scripts PowerShell pour déplacer une connexion d'un serveur à un autre en fonction de la quantité de processus de travail sur chaque boîte ou quelque chose comme ça. Quoi qu'il en soit, très difficile à faire et ne vaut pas le temps et l'énergie à mettre de l'avant.

Vérifiez si vous ne pouvez pas configurer l'équilibrage de la charge réseau sur les serveurs. Cela nécessitera une adresse IP supplémentaire, mais son seul changement DNS et le trafic peut être distribué pour la lecture sur les 3 serveurs.

Bonne chance!


Merci beaucoup pour vos suggestions. Le stockage central unique était un goulot d'étranglement pour nous car nous avions cette configuration avant mais ne faisions pas face à un trafic élevé. Nous avions besoin d'une solution rapide en raison d'un délai. Nous avons finalement utilisé resilio qui est une solution de synchronisation en temps réel d'égal à égal, qui détecte les modifications sur l'un des serveurs et se réplique sur l'autre serveur. J'espère que quiconque ayant les mêmes problèmes ou des problèmes similaires pourra résoudre ces problèmes de la même manière que pour nous. Je teste votre suggestion de réécriture d'URL pour le backend WP et je pousse les modifications sur d'autres machines. Merci encore.
joebegborg07

NLB ne fonctionne pas sur Azure (il n'y a pas de couche 2, si vous voulez des cauchemars vraiment horribles, essayez simplement de regarder la table ARP sur une machine virtuelle Azure).
Massimo

12

Merci pour toutes les suggestions des gens.

Notre solution utilisait une approche de synchronisation peer-to-peer utilisant un outil appelé resilio.

Resilio nous a permis de configurer un certain nombre d'ordinateurs (dans ce cas, les frontaux IIS) dans un cluster de synchronisation d'égal à égal. Un dossier est sélectionné sur chaque ordinateur du cluster à utiliser pour le processus de synchronisation.

Le service Resilio (service Windows exécuté en arrière-plan), surveille ces dossiers pour toute modification et si une modification est apportée à l'un des dossiers spécifiés sur les frontaux en question, Resilio poussera cette modification vers les autres serveurs.

J'espère que cela pourra aider d'autres personnes confrontées à un problème similaire à l'avenir.


11

Je ne pense pas que les tâches planifiées et Robocopy soient une excellente approche. En raison de la fenêtre de 5 minutes, il y aura des moments où une ressource est demandée mais le serveur sélectionné par l'équilibreur de charge ne la mettra pas à disposition. Pour les sites largement statiques, cela se produira beaucoup moins souvent que pour les sites occupés fréquemment modifiés. Une fréquence plus élevée ou l'utilisation d'une technologie de synchronisation différente comme Bittorrent Sync (maintenant appelée Resilio Sync ) améliorerait considérablement cela, mais n'éliminerait pas le problème.

Placer votre contenu wp ou peut-être simplement le dossier wp-content / uploads sur un lecteur partagé serait une meilleure solution. Une autre façon de voir les choses serait d'avoir l'un des serveurs hébergeant ce dossier et que les autres partagent. Avec la mise en cache du disque, la charge sur le serveur ne devrait pas être beaucoup plus élevée que les autres serveurs.

Mettre à jour

Jetez un œil à cet article pour des idées sur la mise en cache des pages, et celui-ci pour CDN. Il s'agit de Nginx, vous devrez donc le résoudre pour IIS, mais la théorie derrière cela est valable pour tout serveur Web.


Merci pour votre suggestion @Tim. Comme vous l'avez dit, le site Web est dynamique, avec des mises à jour mineures régulières des fichiers en raison des plugins wordpress en place; Cela signifie que chaque frontal peut parfois avoir des fichiers différents. Avez-vous déjà testé un tel environnement de production (environ 500 à 1 000 utilisateurs simultanés); c'est-à-dire stocker les fichiers du site Web dans un référentiel central et mappés via un lecteur partagé? Si oui, comment s'est passée l'expérience.
joebegborg07

Non, je n'ai pas testé ce scénario - je n'en ai pas besoin car je mets en cache et utilise un CDN. Vous devez tester la charge des serveurs frontaux, y compris le serveur de fichiers principal. Cependant, si vos pages ne sont pas personnalisées pour la mise en cache de chaque page utilisateur, cela pourrait réduire considérablement votre charge, comme le ferait une distribution de contenu - CloudFlare a un niveau gratuit. Cela est vrai même si vous mettez à jour toutes les 5 minutes. Google "Nginx Microcaching" pour la théorie derrière, mais vous devrez évidemment l'implémenter différemment sur IIS. La mise en cache des en-têtes est assez critique si vous suivez cette voie. Voir aussi la mise à jour ci-dessus.
Tim
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.