Les blogs multisites peuvent-ils être accessibles à partir de deux sous-domaines différents?

Contexte rapide:

Nous avons une seule instance WordPress, avec Multisite activé, hébergeant trois blogs distincts. (blog.example.com/blog1, blog.example.com/blog2, blog.example.com/blog3).

Ce multisite sera équilibré en charge sur un niveau Web de quatre serveurs, tous accédant à la même base de données. Je comprends que blogs.dircela devra être synchronisé à travers le niveau Web, afin que les médias soient présents, quel que soit le serveur qu'un client rencontre.

Question:

Puis-je avoir un cinquième serveur Web (c.-à-d. post.example.com), Dont le seul but est de permettre aux éditeurs de se connecter et de publier du nouveau contenu, pour l'un des trois blogs? De cette façon, les serveurs à charge équilibrée ne sont que des récepteurs de contenu téléchargé post.example.com.

Je sais que la synchronisation est possible, mais je ne sais pas comment configurer WordPress pour être accessible à partir de deux sous-domaines différents. Est-ce possible?

Edit: je dois ajouter qu'un objectif supplémentaire en le configurant de cette façon, est que nous espérons gagner en sécurité grâce à l'obscurité, en bloquant l'accès au /wp-admin/niveau Web, de sorte que vous ne pouvez vous connecter qu'à partir d'un seul serveur Web ( post), mais de bien sûr que tout dépend de la question susmentionnée. :)

Se moquer ci-dessous:

Oui, cela est possible et un certain nombre d'agences de presse et d'actualités travaillent avec des approches similaires dans WordPress.

Quel est votre processus éditorial?
L'étape la plus importante est de comprendre votre processus éditorial et le degré de contrôle dont vous avez besoin sur le contenu avant sa mise en ligne.
- par exemple, considérez ces 3 points:
1. Avez-vous besoin d'approbations tierces pour les images?
2. Vous ou votre client devez-vous approuver la copie / les images / la vidéo / la mise en page avant la publication du contenu?
3. Est-ce que vous, les rédacteurs, travaillez sur différentes semaines ou problèmes et planifiez que le contenu soit mis en ligne des semaines à l'avance ...

Si vous avez répondu Oui à l'une de ces questions, alors une seule base de données partagée entre votre serveur Pre-Live / Staging et votre serveur Live n'est pas «possible». Pourquoi demandes-tu? car un nouveau message doit être publié avant de pouvoir être vu par des non-utilisateurs ou des tiers à qui vous ne souhaitez pas également vous connecter. (BTW ... tout est possible avec du temps, de l'argent et des compétences pour personnaliser les rôles d'utilisateur et les niveaux d'accès).

Revenons donc à la solution évolutive WordPress

Le DOMAINE A (vers lequel vont vos clients et visiteurs) devra être dirigé vers un équilibreur de charge HTTP.

L'équilibreur de charge dirigera le trafic client vers l'un des nombreux serveurs Web. Ces serveurs esclaves sont conservés dans LSYNC avec un serveur MASTER.

Idéalement, il devrait y avoir 2 serveurs DB distincts (pour l'équilibrage de la charge des demandes de lecture / écriture et de la mise à l'échelle). Vous pouvez vous attendre à beaucoup de trafic READ de la part des visiteurs, mais vous voulez vous assurer que le trafic WRITE des nouveaux articles, etc. n'interrompt pas vos demandes READ.

Le DOMAINE A peut également être pointé vers un équilibreur de charge HTTPS qui est configuré pour
1. autoriser uniquement le trafic à partir de votre adresse IP Office et 2. FORCE la connexion SSL pour Admin / Login.

Il s'agit d'une modification facile du wp-config.phpfichier.

Voici un diagramme de ce que nous avons construit (avec un certain support de Rackspace)

HyperDB
Au final, nous avons obtenu la configuration HyperDB pour gérer les multiples serveurs et requêtes DB. C'était aussi facile car c'est principalement un plugin avec un long script de configuration.

W3TC W3 Total Cache
Nous avons également obtenu la configuration HyperDB et W3TC .. cela a également pris beaucoup de charge des serveurs DB

La principale raison pour laquelle nous avons utilisé le W3TC était de décharger tout le contenu statique sur Rackspace. La configuration du Content Delivery Network dans le W3TC est également très simple :)