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

Question

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

13 июл. 2015 г., 22:35:17

Просмотры: 14.2K

Голосов: 14

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

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

Может быть, я неправильно понимаю эту концепцию? Любая помощь будет очень полезна!

Yaron

360

mysql хостинг amazon облако масштабирование

Комментарии

Зачем размещать WordPress на Azure? Есть более подходящие и дешевые хостинги для WordPress. Например, Digital Ocean.

Alexus

13 июл. 2015 г. 23:20:45

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

Yaron

15 июл. 2015 г. 01:16:07

Понял. Делать то, что нужно :) Я тоже предпочитаю Azure для большинства своих .NET проектов, но WordPress-сайты всегда размещал отдельно.

Alexus

15 июл. 2015 г. 01:51:34

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

Bryan 'BJ' Hoffpauir Jr.

16 авг. 2015 г. 14:42:09

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

Yaron

17 авг. 2015 г. 22:33:33

Все ответы на вопрос

Bryan 'BJ' Hoffpauir Jr. 322 · Accepted Answer · 2015-07-20T21:23:50Z

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

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

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

Балансировка нагрузки между двумя (или более) "фронтенд" веб/прикладными серверами WordPress. Это не слишком сложно, так как WordPress в основном БЕССОСТОЯНИЕ, если только вы не разрешаете пользователям входить на сайты. Это достигается комбинацией DNS и балансировщиков нагрузки. Вам понадобится поддержка 2 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 Session Clustering).
Управление входами администраторов, ЕСЛИ вы разрешаете некоторым пользователям входить в админку для управления контентом (аналогично предыдущему пункту).
Выбор системы БД, которая ТАКЖЕ обладает высокой доступностью. Нет смысла иметь два фронтенд-сервера, если падение БД приведет к отказу всей системы. Вам нужно использовать репликацию MySQL Master/Slave через ClearDB или модифицировать WordPress через плагин для работы с SQL Server, чтобы использовать его встроенные системы кластеризации. Это означает, что вам понадобится как минимум 4 виртуальные машины, если вы хотите управлять уровнем БД самостоятельно (2 x приложение и 2 x БД). Вот как это может выглядеть:


               /-- 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)/

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

Включение пула соединений для максимизации производительности и надежности подключений серверов приложений к базе данных.
Использование плагинов кеширования, таких как W3 Total Cache или Super Cache, для минимизации нагрузки на фронтенд-серверы.

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