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

Репликация SAN + MySQL - это то, что я хочу для своего кластера Drupal с балансировкой нагрузки?

Мне нужно собрать экземпляр Drupal, используя встроенные функции Drupal для работы с несколькими сайтами, что позволит мне использовать единую базу кода для всех сайтов, что значительно сэкономит время и избавит от головной боли. Однако мы собираемся запустить пару десятков сайтов из этой единственной установки, поэтому нам понадобится высокопроизводительный способ прозрачного обмена файлами (включая загрузки пользователей и т. Д.) Между этими серверами. Означает ли это, что нам нужна SAN и несколько локальных подчиненных баз данных? Или я понятия не имею, о чем говорю?

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

1.) база данных - это «просто» в том смысле, что репликация mysql является зрелым, хорошо документированным решением. Репликация или DRBD могут предлагать HA, но для одновременного использования преимуществ нескольких серверов для масштабирования производительности вашему приложению потребуется встроенная возможность разделения запросов на чтение (выбор) и запись (вставка / обновление / удаление) между ведущим и ведомым.

2.) файловая система - это сложнее. «нормальные» файловые системы (ext3 / ntfs) не предназначены для масштабирования с несколькими хостами, а те, которые являются (gfs / ocfs), почти всегда сложнее, чем они того стоят (особенно, если вам нужно спросить здесь). Наиболее распространенным решением является подход на основе NAS (nfs в unix, cifs в Windows), но он вводит единую точку отказа, поэтому это не решение для обеспечения доступности. Обычно это даже не решение для повышения производительности, поскольку вы полагаетесь на производительность одного файлового сервера. Его основная ценность заключается в обеспечении согласованного доступа для чтения и записи с нескольких хостов. Если ваше приложение имеет узкое место в ЦП, то NAS поможет вам масштабироваться, потому что ваши серверы будут тратить время на ожидание завершения ЦП, а не загрузки файлов.

3.) код и конфигурация - обычно это делается в файловой системе, в базе данных или в обеих. Я разделяю его здесь, потому что он обычно намного меньше по объему и больше является проблемой системного администратора, чем более ориентированные на контент хранилища данных №1 и №2. Часто можно обойтись простым ручным (или скриптовым) копированием файлов.

Итак, имея все это в виду, вам необходимо оценить, как drupal обрабатывает эти три категории и как вы можете их воспроизвести. Скорее всего, вы начнете с NAS и балансировщика нагрузки. Маловероятно, что вам понадобится SAN.

Я не уверен, где в него (изначально) входят серверы SAN и Slave, поскольку вы говорите, что это «единичная установка».

Параметр, который вы хотите указать, - это «Путь к файловой системе». Так что, возможно, если вы собираетесь использовать этот каталог среди всех своих сайтов, вы собираетесь создать / указать в качестве значения «sites / all / files» (т.е. БД каждого сайта Drupal будет хранить это значение).

Если / когда у вас есть проблема с масштабированием и вам нужно совместно использовать сайты / все / файлы одновременно для каждого веб-узла, вы можете использовать хранилище SAN (iSCSI) с файловой системой кластера, такой как OCFS2. (т.е. файлы становятся монтированием к хранилищу SAN, которое является файловой системой OCFS2).

Так же и с подчиненными серверами. Используйте для масштабируемости (чтение из ведомых устройств) и / или высокой доступности (продвигайте ведомое устройство на ведущее) или делайте резервные копии с ведомого устройства, но на самом деле это не влияет на вашу первоначальную спецификацию в отношении прозрачного обмена файлами.

Надеюсь это поможет.

Ура