Как запустить WordPress через 2 виртуальных машины для обеспечения высокой доступности

Microsoft Azure требует, чтобы приложения использовали два экземпляра в нескольких центрах обработки данных для достижения SLA с высокой степенью готовности и гарантировали, что ваши сайты не будут работать для текущего обслуживания. Они даже говорят вам, какие пары центров обработки данных никогда не будут отправляться на техническое обслуживание в одно и то же время.

Это все хорошо и хорошо, но как бы вы сделали это на практике для такого приложения, как WordPress с базой данных MySQL на той же виртуальной машине? Я не чужд балансировке нагрузки между двумя виртуальными машинами, но установка репликации базы данных ускользает от меня. Мы бы не хотели, чтобы две версии данных могли выйти из синхронизации. Для репликации MySQL, по-видимому, требуется настройка ведущего-ведомого, которая не сможет синхронизировать изменения с основной БД, если пользователь приземлился на подчиненный экземпляр.

Я просто недопонимаю эту концепцию? Любая помощь высоко ценится!

Solutions Collecting From Web of "Как запустить WordPress через 2 виртуальных машины для обеспечения высокой доступности"

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

Хорошие новости. Практически все поставщики облачных услуг (включая Azure) имеют абстракции, которые позволяют вам обойти эти ограничения дизайна.

По сути, вы будете решать следующие проблемы:

  • Балансировка нагрузки Трафик между двумя (или более) «внешними» серверами веб-приложений и приложений WordPress. Не слишком сложно, так как WordPress МОЖЕТ быть включенным без учета состояния, если вы не позволяете пользователям входить на сайты. Это делается с помощью комбинации DNS и Load Balancers. Вам понадобится поддержка двух IP-адресов для ваших серверов приложений. 1 комплект будет подключаться к подсети, которая маршрутизируется через Интернет (хотя, надеюсь, защищена брандмауэром, не описанным ниже), а остальные два будут в РАЗЛИЧНОЙ подсети, изолированной от в другой сети и содержит экземпляры сервера баз данных, но базовый контур выглядит так:
                      / - (10.0.0.1 - eth0) wp1.domain.com (10.0.1.1 - eth2)
 (Публичный IP) wp.domain.com          
                      \ - (10.0.0.2 - eth1) wp2.domain.com (10.0.1.2 - eth3)
  • Управление сессиями, если вы разрешаете пользователям входить на сайты. Если это так, вам нужно будет убедиться, что когда они войдут на сервер 1, либо все его будущие запросы будут перенаправлены на этот сервер (липкие сеансы) или что не имеет значения, к какому серверу они обращаются, поскольку сеансы управляются с помощью какого-либо другого механизма (например, посредством кластеризации сеансов сервера Zend ).

  • Управление учетными записями администратора, если вы разрешаете некоторым пользователям войти в фоновый код для управления контентом (аналогично выше).

  • Выбор системы БД, которая ТАКЖЕ высокодоступна. Нет смысла иметь два фронтальных сервера, если сбой в работе вашей базы данных приведет к сбою всей системы. Вам нужно будет использовать репликацию MySQL Master / Slave через ClearDB или изменить WordPress через плагин, чтобы использовать SQL Server, чтобы вы могли использовать свои собственные системы кластеризации . Это означает, что вам нужно как минимум 4 виртуальных машины, если вы хотите самостоятельно управлять уровнем БД (2 x App & 2 x DB). Вот как это может выглядеть:


                / - wp1.domain.com (10.0.1.1) \ --- / (10.0.1.3) db1.domain.com (10.0.2.3) \
          wp.domain.com X |           
                \ - wp2.domain.com (10.0.1.2) / --- \ (10.0.1.4) db2.domain.com (10.0.2.3) /

  • ПРИМЕЧАНИЕ. Чтобы обеспечить надежный переход на другой ресурс и защитить систему безопасности, сеть THIRD обычно используется для соединения двух узлов базы данных друг с другом через частный канал, который отделен от других сетей связи, используемых серверами приложений для общения с база данных и серверы приложений используют для общения с внешним миром.

  • Включение пула соединений для максимизации производительности и надежности подключений базы данных вашего сервера приложений.

  • Использование кэширующего плагина, такого как W3 Total Cache или Super Cache, чтобы минимизировать нагрузку на интерфейсные серверы.

В следующих руководствах подробно описаны способы решения каждой из вышеперечисленных задач. Существует несколько способов обработки каждого из них в Azure, поэтому вам решать, как вы хотите атаковать каждую проблему, а затем справляться с ограничениями, которые каждый из этих вариантов налагает при работе вверх и вниз по стеку.

  • Масштабируемый WordPress
  • Как разместить масштабируемый и оптимизированный WordPress для Azure за считанные минуты
  • Развертывание веб-приложения MVC с высокой степенью доступности на Microsoft Azure – часть 1
  • Развертывание веб-приложения MVC с высокой степенью доступности на Microsoft Azure – часть 2
  • Новое «Масштабируемое» предложение WordPress в Azure
  • Корпоративный WordPress для Azure App Service
  • Как запустить сайты WordPress Enterprise Grade на сайтах Azure