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

Что использовать для программного общего хранилища файлов?

Ситуация: настройка балансировщика нагрузки

В настоящее время у нас есть все наши серверы (под управлением CentOS Linux) попарно в нашем центре обработки данных: каждый сервер имеет зеркальный сервер. На данный момент мы не используем балансировку нагрузки, поэтому serverA получает весь трафик, и в случае сбоя (аппаратного или программного обеспечения) мы можем быстро переключиться на serverB, настроив IP-адрес serverA на serverB. Мы используем репликацию master / master в MySQL (хотя мы могли бы просто использовать репликацию master / slave для текущей настройки) и rsync, чтобы синхронизировать файлы vhost (serverA синхронизируется с serverB).

Это хорошо работает для нас, но совершенно неэффективно, поскольку у нас 50% вашего оборудования ничего не делает, пока машина не выйдет из строя. Мы думаем о том, чтобы поставить балансировщики нагрузки перед парами серверов, чтобы мы могли разделить нагрузку на обе машины, а также добавить дополнительные серверы на кластер.

Проблема: совместное использование хранилища файлов

Настройка этого, вероятно, не потребует намного большего, чем поставить балансировщик нагрузки перед каждой парой серверов, а затем он разделит трафик на каждый сервер пары. За исключением одного: файлового хранилища. В настоящее время rsync «проталкивает» изменения с serverA на serverB, но не наоборот. Мы можем настроить его так, чтобы rsync также запускался с serverB на serverA, но проблема в том, что rsync никогда не знает, создавать или удалять файл, который существует на serverA, но не на serverB. я смотрел на Унисон, но этот проект, похоже, прекращен.

Вопрос: какое решение для программного общего хранилища файлов лучше всего?

Итак, я ищу другое решение. Пожалуйста, учтите, что я не хочу добавлять дополнительное оборудование (поэтому нет решения NAS / SAN). Также учтите, что нам нужен небольшой объем хранилища (менее 500 ГБ) на кластер и что все серверы находятся в одной локальной сети. У нас есть достойное решение для резервного копирования (резервное копирование выполняется каждые 3 часа).

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

DRBD великолепен.

Хорошие вещи:

  • Он отлично справляется с репликацией данных
  • DRBD в нескольких случаях предотвратил аварию, когда обнаружил, что том уже был смонтирован на другом узле, о чем не могут сообщить нам необработанные тома, которые мы получаем из SAN.
  • Heartbeat уже имеет отличную поддержку DRBD.

Испытания:

  • Не забывайте следить за этим должным образом, чтобы вы обнаружили разделение мозга, когда оно произойдет, и сможете справиться с этим.
  • DRBD не может быть смонтирован на обоих серверах без файловой системы с поддержкой кластера сверху - у меня нет опыта работы с этой частью.
  • Серверы можно легко настроить, настроив DRBD на использование всей доступной полосы пропускания для синхронизации дисков. Просто настройте на более низкую пропускную способность, и все в порядке.

Для монтирования «одной и той же» файловой системы на нескольких узлах мы продолжаем возвращаться к NFS, несмотря на то, что продолжаем тестировать различные решения для этого. У меня нет проблем с производственной установкой: NFS поверх EXT4 поверх DRBD. Я бы не осмелился сделать это с файловыми системами баз данных, но для wwwroot это нормально.

DRBD прозрачно зеркалирует данные в реальном времени. Обратите внимание на некоторые моменты, указанные ниже:

  • Вам нужна кластерная файловая система для двойного основного режима. OCFS2 поддерживается только CentOS 5. Если вы используете CentOS 6, вам следует использовать GFS2 вместо.
  • Хотя все серверы находятся в одной локальной сети, я все же рекомендую подключаться с помощью перекрестного кабеля.
  • У вас должен быть механизм мониторинга для обнаружения расщепленный мозг, например: Nagios's check_drbd плагин.
  • Не забывай измерять и оптимизировать Производительность DRBD

Если вы хотите установить 3 или 4 узла, взгляните на:

Почему бы вам не настроить две (или более) службы на кластер и не позволить запускать по одной на каждой стороне по умолчанию?