Назад | Перейти на главную страницу

wordpress на кластерных (репликационных) серверах

У нас есть кластерная среда, в которой работают наши веб-сайты. Есть два веб-сервера с балансировкой нагрузки и один сервер БД. Весь код развертывается на первичном сервере и автоматически реплицируется на вторичный сервер с помощью программного обеспечения peersync. Это среда Windows.

Wordpress отлично работает в этой среде, за исключением редактирования тем и загрузки мультимедиа. Проблема в том, что любой загруженный контент должен быть загружен на первичный сервер, чтобы он реплицировался на вторичный сервер. Репликация не двухсторонняя. Файл, загруженный или измененный на вторичном сервере, не будет синхронизироваться с первичным сервером.

В ситуации, когда запрос на админку сайта отправляется на первичный сервер, все работает должным образом. Загруженные изображения загружаются по пути wp-content / uploads, а затем реплицируются на вторичный сервер.

То же верно и для редактирования файлов темы. Администратор wordpress редактирует правильные файлы для текущей активной темы.

Проблема обнаруживается, если балансировщик нагрузки отправляет запрос на вторичный сервер. Если пользователь загружает файл или редактирует файл темы через администратора, эти файлы отправляются на вторичный сервер, не реплицируются на первичный сервер, и сайты перестают синхронизироваться. Я пробовал ввести сетевой путь (\ primary_server \ c $ \ inetpub \ wwwroot ...) в диалоговом окне различных настроек, но wordpress, похоже, не любит сетевые пути. Я получаю сообщение об ошибке при попытке загрузить изображения, и я на 99% уверен, что это не проблема безопасности. Это связано с форматом пути.

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

Изначально мы создали правило, которое сообщало балансировщику нагрузки: «если запрос приходит с субдоменом www1, отправить запрос на основной сервер», думая, что мы можем принудительно выполнить все редактирование на основном сервере, если конечный пользователь перейдет на www1.domain.com/wp-admin/. Проблема в том, что wordpress затем хочет записать все ссылки в контенте как абсолютные на www1, что не является намерением. Если все ссылки и контент идут на www1, нагрузка на сайт больше не распределяется для всех намерений и целей.

Может ли wordpress работать в кластерной среде, которую я описываю? Использование mod_rewrite - не лучший вариант, поскольку в IIS я знаю, что есть плагины, которые включают эту функцию.

Если ваш балансировщик нагрузки позволяет вам это сделать, найдите полный путь администратора: «www.domain.com/wp-admin/» в URL-адресе и отправьте запросы для этого на основной сервер.

Пока вы на нем, вы должны изменить папку wp-admin на другое случайное имя для безопасности.

Я решил это, используя GlusterFS чтобы обеспечить точку монтирования, общую для обоих серверов. Это намного лучше, чем использование rsync, поскольку он правильно обрабатывает удаление и поддерживает аварийное переключение - любой узел может выйти из строя, и все по-прежнему будет работать, а когда он вернется, он автоматически восстановит все отсутствующие файлы.

Вставка прозрачных файлов cookie или использование липкости IP в вашем балансировщике lod решает проблему сеанса.

Несколько сложнее обрабатывать обновления тем и плагинов, особенно если вы используете стандартные пакеты для своей установки WordPress. Его также можно было бы добавить в глянцевый блеск, но его отсутствие дает преимущества в производительности.