Лучший способ предоставить общий доступ к файлам для загрузки на веб-серверах с горизонтальным масштабированием

В настоящее время я пытаюсь настроить горизонтально масштабируемый кластер для веб-приложения на основе Drupal, который выглядит примерно так, как на диаграмме ниже:

Балансировщик нагрузки реализует липкие сеансы, поэтому пользователь сохраняет состояние, когда ему назначен сервер для работы.

Каждый сервер приложений имеет следующее:

• лак спереди
• Drupal 6 в середине работает на стек лампы
• Memcached на спине

Два сервера базы данных mysql находятся на общем IP-адресе, и они находятся в кластере высокой доступности с DRBD и звуковым сигналом, так что потеря одного не приведет к разрушению всей платформы.

Есть несколько вещей, в которых я не уверен, что я был бы признателен за ваше мнение:

Как масштабировать хранилище файлов по горизонтали?

Я думаю об использовании NFS для монтирования каталога общих файлов на каждом сервере приложений, поэтому файл, загруженный в одном месте, доступен на всех из них. Я думаю о NFS, потому что он существует уже целую вечность, и у меня нет опыта работы с MogileFS или GlusterFS, и это то, что мы использовали раньше, поэтому мы более знакомы с ним.

Существуют ли какие-либо рекомендации по определению количества серверов, на которых разумно делить каталог по NFS таким образом?

Как HA следует предоставлять в общем хранилище файлов здесь?

Одна из проблем заключается в том, что сервер NFS является единственной точкой отказа.

Мы уже используем Heartbeat и DRBD на серверах Mysql, и я бы предпочел, чтобы количество технологий, задействованных в стеке, было как можно меньше - какие подводные камни могут возникнуть, если бы я использовал ту же стратегию высокой доступности для файла серверы тоже?

Альтернативный подход

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

Учитывая это

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

Я также рассматриваю возможность сделать эти два веб-сервера более мощными, чтобы они могли обрабатывать пиковую нагрузку между ними, и настроить unison или rsync для двух в задании cron, чтобы:

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

Похоже ли это на возможный способ обойти возможные головные боли сложности NFS / DRBD HA?

Спасибо,

С

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

Мое предложение состояло бы в том, чтобы сконцентрировать все записи на одном из серверов приложений (возможно, иметь один сервер приложений, выделенный для записи на сервере NFS) и несколько серверов приложений чтения, монтирующих его только для чтения (я знаю, что у drupal есть некоторые динамические миниатюры, которые необходимо быть написано, но вы можете держать большую часть этого на RO FS). Вам потребуется как минимум второй сервер NFS (для обеспечения высокой доступности лучше использовать DRBD, если у вас нет общего хранилища, такого как SAN).

Наконец, взгляните на Gluster и другие распределенные системы.

Вы можете попробовать mogileFS. Я использовал это один из наших проектов. Он прост в использовании и настройке, может масштабироваться, и нет единой точки отказа.

http://danga.com/mogilefs/

Лучший способ - найти хорошее решение для хранения. В зависимости от масштаба и типа приложения вы можете использовать хороший NAS с поддержкой NFS и по крайней мере двумя гигабитными портами и источниками питания (ознакомьтесь с некоторыми корпоративными решениями).

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