Могут ли блоги мультисайтов быть доступны из двух разных поддоменов?


8

Быстрый Фон:

У нас есть один экземпляр WordPress с включенным мультисайтом, на котором размещены три отдельных блога. (blog.example.com/blog1, blog.example.com/blog2, blog.example.com/blog3).

Этот мультисайт будет сбалансирован по нагрузке на веб-уровне четырех серверов, каждый из которых имеет доступ к одной и той же БД. Я понимаю, что blogs.dirнеобходимо синхронизировать веб-уровень, чтобы носители присутствовали независимо от того, на каком сервере работает клиент.

Вопрос:

Могу ли я иметь пятый веб-сервер (т. Е. post.example.com), Единственная цель которого - разрешить редакторам входить в систему и публиковать новый контент для любого из трех блогов? Таким образом, серверы с балансировкой нагрузки являются только получателями загруженного контента post.example.com.

Я знаю, что синхронизация возможна, но я не уверен, как настроить WordPress так, чтобы он был доступен из двух разных поддоменов. Это возможно?

Изменить: я должен добавить, что дополнительная цель, настроив его таким образом, мы надеемся получить некоторую безопасность через неизвестность, блокируя доступ /wp-admin/на веб-уровне, так что вы можете войти только с одного веб-сервера ( post), но из Конечно, все зависит от вышеупомянутого вопроса. :)

Макет ниже:

Макет WordPress Архитектура


2
Я подумаю над этим, чтобы посмотреть, смогу ли я найти ответ на ваш вопрос в том виде, в котором он был задан. Одна вещь, которая приходит на ум, которая будет серьезной безопасностью из-за неясности, - это использовать переопределение хостов, чтобы указать blog.example.com на «почтовый» сервер. Если вы не хотите, чтобы всем вашим авторам приходилось редактировать файл хостов, вы можете настроить сервер VPN (что-то простое, например, сервер pptp) и попросить пользователей подключаться и маршрутизировать весь трафик через VPN. Таким образом, при работе в VPN blog.example.com переходит в одно место, а после VPN - в другое.
Мэтью Бойнс

@ MatthewBoynes Спасибо за ваш ответ! К сожалению, я не могу навязать обновления файлов хостов и / или использование VPN. Наши редакторы являются локальными и удаленными и всегда используют разные устройства.
Кай

Ответы:


5

Да, это возможно, и ряд новостных и медийных агентств работают с подобными подходами в WordPress.

Каков ваш редакционный процесс?
Самым важным шагом является понимание вашего процесса редактирования и того, насколько вы должны контролировать контент, прежде чем он будет запущен.
- например, рассмотрите эти 3 пункта:
1. Вам нужны одобрения сторонних производителей для изображений?
2. Нужно ли вам или вашему клиенту подписывать копию / изображения / видео / макет перед публикацией контента?
3. Вы, редакторы, приступаете к работе над разными неделями или проблемами и планируете выпустить контент на несколько недель вперед ...

Если вы ответили «Да» на любой из этих вопросов, то «одна» БД, совместно используемая вашим сервером Pre-Live / Staging и вашим Live-сервером, «невозможна». Почему ты спрашиваешь? потому что новое сообщение должно быть опубликовано, прежде чем его увидят не пользователи или третьи лица, которым вы не хотите давать логины. (Кстати ... все возможно со временем, деньгами и навыками для настройки пользовательских ролей и уровней доступа).

Итак, вернемся к масштабируемому решению WordPress

DOMAIN A (на что ходят ваши клиенты и посетители) нужно указать на HTTP Load Balancer.

Балансировщик нагрузки будет направлять трафик клиента на один из нескольких веб-серверов. Эти подчиненные серверы хранятся в LSYNC с сервером MASTER.

В идеале должно быть 2 отдельных сервера БД (для балансировки нагрузки на запросы на чтение / запись и масштабирование). Вы можете ожидать большой трафик READ от посетителей, но вы хотите убедиться, что трафик WRITE из новых сообщений и т. Д. Не пересекается с вашими запросами READ.

DOMAIN A также можно указать на HTTPS Load Balancer, который настроен на
1. пропуск трафика только с вашего IP-адреса Office и 2. FORCE SSL-соединение для Admin / Login.

Это легко изменить wp-config.phpфайл.

Вот схема того, что мы построили (с некоторой поддержкой Rackspace) Rackspace Scaled WordPress

HyperDB
В итоге мы получили настройку HyperDB для управления несколькими серверами БД и запросами. Это также было легко, так как это в основном плагин с длинным скриптом конфигурации.

W3TC W3 Total Cache
У нас также есть настройка HyperDB и W3TC. Это также потребовало большой нагрузки на серверы БД.

Основной причиной, по которой мы использовали W3TC, было отключение загрузки всего статического контента в Rackspace. Настройка сети доставки контента в W3TC также очень проста :)

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.