NFS на Btrfs на нескольких устройствах.vs. Glusterfs на распределенном объеме?

Я рассмотрел хранилище для электронной почты. Эта система хранения работает в моем собственном частном облаке (уже реплицировано), тогда мне нет дела до репликации.

Я думаю о 2 вариантах:

1. Я создам несколько "дисков" (томов в облаке) и создаю файловую систему Btrfs на нескольких дисках; и когда файловая система заполнится, я создам больше "диска" и добавлю его в файловую систему btrfs:

btrfs device add /dev/vdX /mnt

btrfs filesystem balance /mnt

Эта точка монтирования (/mnt) будет доступна через NFS, и мой сервер Dovecot будет монтировать этот экспорт и хранить на нем электронные письма.

2 - Я создам несколько "дисков" (томов в облаке) и создам распределенный том GlusterFS на этих дисках; и когда файловая система заполнится, я создам больше "дисков" и добавлю новые "диски" в распределенный том GlusterFS, чтобы сбалансировать его. Мой Dovecote будет монтировать этот том с помощью glusterfs-client и хранить на нем электронные письма.

(Повторяю: мне не нужно копировать, потому что мой "диск", том в частном облаке, реплицированный подкоп)

Как вы думаете, какой вариант лучше?

  • спектакль? (много много маленьких операций чтения / записи ввода / вывода)
  • стабильный?
  • гибкий?

2 ответа

Вы должны рассмотреть шаблон ввода / вывода почтового сервера: читать / записывать множество маленьких файлов как можно быстрее. Оба ваших варианта действительно не подходят для этого при работе с большим количеством клиентов, ИМХО.

Ни одна из FS не достаточно быстра, и я думаю, что особенно важны издержки блокировки GlusterFS. Затем вы добавляете еще один слой с NFS, который имеет свои накладные расходы. Вместо этого я бы попытался подключить почтовое хранилище с минимальными накладными расходами и с быстрой файловой системой. Обычно это означает подключение как можно напрямую к физическому хранилищу, но поскольку вы скрываете свою архитектуру за такими бредовыми терминами, как "частное облако", мы не знаем, что будет возможно.

Один из подходов, который вы могли бы попробовать, - экспортировать хранилище через iSCSI на почтовый сервер, а затем использовать быструю FS со многими небольшими файлами и, возможно, если это действительно важно, использовать LVM, чтобы иметь возможность легко добавить пространство к этой FS в форма дополнительных томов iSCSI (что добавляет дополнительные издержки).

Что бы вы ни пытались: вы должны сравнить различные варианты и посмотреть, получите ли вы требуемую производительность из этого.

Если вам нужно выбрать один из двух выше, то NFS предпочтительнее, я думаю.

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

Я не уверен, что объединение вашего хранилища с нескольких устройств - это хорошая идея. В качестве альтернативы вы можете пропустить высокоуровневую функциональность службы томов OpenStack и предоставить доступ к хранилищу с прямым форматом тома LVM(/ZFS/SAN), экспортируемого NFS. Таким образом вы устраните ненужный уровень iSCSI и сможете по мере необходимости увеличивать пространство для хранения почты, если в основном хранилище достаточно свободного места.

Другие вопросы по тегам