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

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

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

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

Author: Bryan 'BJ' Hoffpauir Jr., 2015-07-13
Source

1 answers

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

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

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

  • Балансировка нагрузки трафика между двумя (или более) "интерфейсными" Wordpress веб-серверы/серверы приложений. Не слишком сложно, так как Wordpress в ОСНОВНОМ не имеет гражданства, если вы не разрешаете пользователям входить на сайты. Это делается с помощью комбинации DNS и балансировщиков нагрузки. Вам потребуется поддержка 2 IP-адресов для серверов приложений - 1 набор подключится к подсети, которая маршрутизируется через Интернет (хотя, надеюсь, защищена брандмауэром, не описанным ниже), а два других будут находиться в ДРУГОЙ подсети, изолированной от другой сети и содержащей экземпляры сервера базы данных, но основная схема выглядит так:
                     /-- (10.0.0.1 - eth0) wp1.domain.com (10.0.1.1 - eth2)
(Public 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 приложение и 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 или супер кэш, для минимизации нагрузки на серверы переднего плана.

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

 12
Author: Bryan 'BJ' Hoffpauir Jr., 2015-07-20 23:34:26