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

зеркальная файловая система на нескольких серверах

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

Я искал некоторые решения:

Любые другие предложения приветствуются.

Первый вопрос, который я задам, - хотите ли вы, чтобы это было реплицировано на два сервера или более чем на два сервера? Для двух серверов я бы выбрал DRDB, для трех или более я бы выбрал gluster.

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

DRDB будет сложно получить работу в режиме master <-> master с 3 или более серверами. Вы должны настроить установку на основе кольца, и я бы не рекомендовал это. Однако для двух серверов DRDB - это просто фантастика. Мастер <-> Мастер режим несложен в настройке, и вам не нужно изучать какие-либо особенности файловой системы.

lsycd отлично подходит для настройки ведущий / ведомый, но, похоже, вам это не нужно.

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

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

Вы должны изучить OpenAFS - это в основном распределенная файловая система, которая позволяет хранить несколько копий данных, распределенных по кластеру, и каждый может читать / писать в FS одновременно.

У него также есть множество других полезных функций (хорошая аутентификация, шифрование по сети, встроенное локальное кеширование на клиентах, собственный клиент Windows, переносимость между множеством версий unix и т. Д.)

Однако это немного сложно настроить.

Как насчет Ceph или Блеск?

Заставить это работать с DRBD будет действительно сложно - проблема не в том, что n8whnp, похоже, думает о проблеме многосторонней репликации (вы просто делаете все узлы полосами в зеркальном наборе), а в управлении параллелизмом - вы ' d необходимо запустить кластерную файловую систему поверх зеркалирования поверх DRBD.

lsyncd еще хуже, поскольку нет практического решения для управления параллелизмом.

Я бы порекомендовал решение типа AFS (AFS, OpenAFS) как зрелое, стабильное и открытое решение. Я бы держался подальше от блеска с тех пор, как Oracle отключил его. Не слишком знаком с glusterfs, но поскольку он полагается на распределенное, а не на реплицированное хранилище, я бы рекомендовал вам внимательно посмотреть, как он будет вести себя в режиме разделения мозга (AFS OTOH предназначен для работы в автономном режиме).

NFS также может работать нормально, в зависимости от ваших потребностей.