Быстрый Фон:
У нас есть один экземпляр 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.
Каков ваш редакционный процесс?
Самым важным шагом является понимание вашего процесса редактирования и того, насколько вы должны контролировать контент, прежде чем он будет запущен.
- например, рассмотрите эти 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)
HyperDB
В итоге мы получили настройку HyperDB для управления несколькими серверами БД и запросами. Это также было легко, так как это в основном плагин с длинным скриптом конфигурации.
W3TC W3 Total Cache
У нас также есть настройка HyperDB и W3TC. Это также потребовало большой нагрузки на серверы БД.
Основной причиной, по которой мы использовали W3TC, было отключение загрузки всего статического контента в Rackspace. Настройка сети доставки контента в W3TC также очень проста :)
источник