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

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

Это все хорошо, но как бы вы могли сделать это легко на практике для такого приложения, как WordPress, с базой данных MySQL на той же виртуальной машине? Мне не привыкать балансировать нагрузку между двумя виртуальными машинами, но настройка репликации базы данных ускользает от меня. Нам не нужны две версии данных, которые могут быть не синхронизированы. Репликация MySQL, кажется, требует установки master-slave, которая не сможет синхронизировать изменения в master DB, если пользователь попадет на экземпляр slave.

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

— Ярон
источник

Зачем вам размещать WordPress на Azure? Есть лучший и более дешевый хостинг для WordPress. Цифровой океан например.

— Алексус

Алексус, это не совсем актуально, но у нас довольно большой разброс стека по инфраструктуре Azure, в которой WordPress является лишь одним из компонентов. Azure - фантастическая платформа, и мы очень довольны ею.

— Ярон

Попался. Ты должен делать то, что должен делать :) Мне также нравится Azure для большинства моих вещей .NET, но я всегда размещал сайты WP отдельно.

— Алексус

Ярон, тебе был полезен ответ ниже? Пока получено 3 отзыва, я просто хотел проверить, не нашли ли вы какой-либо важной концепции, поэтому я могу обновить ее для вашего конкретного случая использования.

— Брайан 'BJ' Хоффпауир-младший

Большое спасибо за подробный ответ @ Bryan'BJ'Hoffpauir и извините, у меня не было времени, чтобы попытаться выполнить ваши инструкции, чтобы посмотреть, работают ли они с нашей реализацией. Я помечаю ответ как правильный и снова обращусь, если у меня возникнут проблемы. Еще раз спасибо!!

— Ярон

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

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

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

Балансировка нагрузки трафика между двумя (или более) «интерфейсными» веб-серверами Wordpress / приложений. Не так уж сложно, так как WordPress практически без сохранения состояния, если вы не разрешаете пользователям входить на сайты. Это делается с помощью комбинации DNS и балансировщиков нагрузки. Вам понадобится поддержка двух IP-адресов для серверов приложений - один комплект будет подключаться к подсети, маршрутизируемой через Интернет (хотя, мы надеемся, защищен брандмауэром, не описанным ниже), а два других будут находиться в РАЗНОЙ подсети, изолированной от другая сеть и содержит экземпляры сервера базы данных, но базовая схема выглядит так:

                     / - (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 Server ).
Управление логинами администратора Если вы разрешаете некоторым пользователям входить в бэкэнд для управления контентом (аналогично описанному выше).
Выбор системы БД, которая ТАКЖЕ доступна. Нет смысла иметь два интерфейсных сервера, если сбой вашей БД приводит к выходу из строя всей системы. Вам нужно будет использовать репликацию 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, поэтому вам нужно решить, как вы хотите атаковать каждый вызов, а затем справиться с ограничениями, которые накладывает каждый из этих вариантов по мере работы вверх и вниз по стеку.

— Брайан 'BJ' Хоффпауир младший
источник