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


13

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

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

  • DRBD : репликации на уровне блоков, кажется немного излишним;
  • lsyncd : выглядит очень просто, но у меня есть сомнения по поводу производительности;
  • GlusterFS : похоже, это было бы неплохо, еще не выяснили, как именно работает режим репликации. Будет ли у него характеристики, которые мне нужны?

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


Вы смотрите на настройку без совместного использования или вы подключите все серверы к одной и той же внутренней сети SAN?
HampusLi

по логике он не разделял ничего (физически это EC2 с EBS).
vartec

Ответы:


6

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

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

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

lsycd отлично подходит для установки master / slave, но вы, похоже, этого не хотите.

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

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


Первоначально я начну с 2 серверов на кластер, но я хочу иметь возможность иметь более 2 серверов для масштабирования; Настройка кластера, которую вы описываете, будет ли она обрабатывать сбой одного из серверов? Было бы легко добавить дополнительный сервер?
vartec

2

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


Поддерживает ли Luster Ubuntu Server? Я проверяю Ceph сейчас, спасибо за предложение.
vartec

Из вики ceph: «Ceph находится в стадии интенсивной разработки и пока не подходит для каких-либо целей, кроме тестирования и анализа». Ceph.newdream.net/wiki
Джефф Басби,

2

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

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

Хотя это немного тяжело для установки.


тот же вопрос, что и с NFS: «разрешить несколько копий». Хорошо, но нужно ли синхронизировать эти копии?
vartec

Ага. И это возможно, хотя и раздражает, чтобы оправиться от потери основного мастера. Но тривиально иметь несколько записывающих устройств и полученные блоки хранятся на нескольких хостах.
Крис

Ключом к пониманию OpenAFS является то, что это система управления кешем - есть одно пространство имен (в IE существует только один «файл»), но везде есть кэшированные копии файла и протокол, обеспечивающий согласованность всех кэшированных копий. , Если вы потеряете мастер, вы можете превратить одну из кэшированных копий в мастер, но в такой ситуации не идеально.
Крис

1

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


AFAIK, NFS не предоставляет способ монтирования реплицированных серверов, но не сама репликация. Но я давно не пользуюсь NFS, так что, возможно, это изменилось. Не могли бы вы дать ссылку на документы NFS, описывающие такую ​​настройку?
vartec

Единственным выходом было бы скопировать каталоги на несколько серверов nfs, на одном из которых есть основной vip, и перенести vip между серверами, если один из них выйдет из строя. Или круглый Робин днс может быть. Сама NFS может делать не все, что вам нужно, но в сочетании с кластерными службами heartbeat или red hat это может быть то, что вам нужно. Я не уверен, что в первоначальном вопросе были все требования. Вы можете даже выполнить rsync на нескольких серверах, скажем, каждый час или около того, для действительно быстрого и простого решения.
LSD

Пропустить часть о rsync. Он будет выполнять репликацию, но в основном для установок только для чтения, что не соответствует вашим требованиям. Я хотел отредактировать мой комментарий выше, но он не позволил бы мне.
LSD

1

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.