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 и сможете по мере необходимости увеличивать пространство для хранения почты, если в основном хранилище достаточно свободного места.