Является ли GlusterFS хорошим выбором для синхронизации веб-серверов?

9

У меня есть 2 веб-сервера с возможностью добавления дополнительных серверов. Сейчас я синхронизирую эти серверы, используя lsyncd + csync2. Он хорошо работает с точки зрения производительности, поскольку все файлы находятся на обоих серверах (для локального открытия файлов не требуется сетевой доступ), но в других случаях это не так хорошо.

Одним из примеров этого является удаление файла на сервере 1 и немедленная загрузка нового файла на сервер 1 с тем же именем. Затем этот файл затем будет удален с сервера 2, что приведет к удалению вновь загруженного файла на сервере 1, поскольку сервер 2 отправляет событие удаления на сервер 1, чтобы завершить «цикл обновления».

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

Будет ли идея рассмотреть замену lsyncd + csync2 на GlusterFS, настроенную для репликации всех файлов на все узлы, или это плохая идея?

— sbrattla
источник

2

Я могу неправильно понять вашу проблему здесь, но почему бы не использовать сетевое хранилище, разделяемое между серверами?

— mveroone

1

@Kwaio: я бы хотел «отразить» все веб-серверы (как скрипты, так и загруженный пользователем контент), поскольку это предотвратит простои, если что-то пойдет не так с сервером, на котором размещено общее хранилище. Другими словами, я не хочу полагаться на установку, в которой все веб-серверы снова полагаются на одно хранилище файлов.

— sbrattla

Тогда почему не кластер сетевого хранилища высокой доступности?

— mveroone

Конечно, но что это значит? Аппаратные средства?

— sbrattla

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

— mveroone

2

BitTorrent Sync может сделать дело за вас. Я использую его для синхронизации файлов между несколькими внутренними серверами в моем доме, и он прекрасно справляется со своей задачей. Еще одна вещь, о которой вам нужно подумать, это база данных, когда ваше приложение использует CMS. Убедитесь, что идет репликация MySQL или что-то в этом роде.

— whiskykilo
источник

Это интересно. Как BitTorrent Sync справляется с конфликтами? Скажем, у меня есть 5 веб-серверов, и файл обновляется на сервере A. Затем, через 2 секунды, тот же файл обновляется на сервере C, прежде чем изменение на A достигнет C. Есть ли в программном обеспечении алгоритмы для настройки того, какой сервер выигрывает в этих случаях?

— сбраттла

Насколько я понимаю, BitTorrent Sync будет сравнивать дату / время изменения на обеих копиях и сохранять только самые последние, которые могут быть идеальными или могут быть вредными для варианта использования.

— вискикило

1

Gluster решит вашу проблему, потому что он может удерживать блокировки, распространять изменения - удалять файл на всех других узлах, но он может добавить дополнительную задержку, которая может стать проблемой для веб-сервера. Следующая альтернатива - DRBD + OCFS2 или GFS, но, вероятно, она более сложная, так как в случае с кластером, который используется базовой файловой системой - он не работает на уровне блоков, поэтому, если серверы не синхронизированы, это не так сложно исправить, файлы могут так легко повредить из-за расщепления мозгов и т. д.

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

— Jure1873
источник

1

GlusterFS сложно развернуть. Для веб-данных уровень синхронизации файлов, такой как Unison , намного проще в развертывании и обслуживании.

DRBD является идеальным решением для синхронизации данных на уровне блоков. Но вы должны отформатировать их в специальный формат, такой как OCFS2 или что-то подобное.

— truongtx
источник

GlusterFS не похож на DRBD - он работает не на уровне блоков, а на уровне файлов. Но я согласен с тем, что унисон легче развернуть.

— Jure1873

-3

Почему бы вам не использовать такой инструмент, как кукольный ? Напишите один раз в источнике, а когда будете готовы, разверните его по целям, используя «puppet kick» или mcolletive. Это хорошо задокументировано. И вы можете легко добавить серверы позже, если это необходимо.

Вы также можете положиться на инструменты, использующие inotify, такие как lsyncd, работающие на уровне ядра. Он следит за изменениями в папке и запускает синхронизацию. Но если инструмента, предназначенного для синхронизации файлов в кластере, такого как csync2, недостаточно, я не знаю, что будет.

Просто чтобы быть уверенным, изменения происходят также на сервере 2 или только на сервере 1?

— Rosco
источник

3

Downvoted - Puppet не является хорошим способом синхронизации файлов между серверами. Это является тем не менее блестящим инструментом для управления конфигурацией сервера .

— Крейг Уотсон

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

— sbrattla

1

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

— Роско