Я рассматриваю хранилище для электронной почты. Эта система хранения работает на моем собственном частном облаке (уже реплицирована), поэтому мне не важна репликация.
Я думаю о 2 вариантах:
1- Я создам несколько «дисков» (томов в облаке) и создам файловую систему Btrfs на нескольких дисках; а когда файловая система заполнится, я создам еще один «диск» и добавлю его в файловую систему Btrfs следующим образом:
btrfs device add /dev/vdX /mnt
btrfs filesystem balance /mnt
Эта точка монтирования (/mnt) будет доступна через NFS, и мой сервер Dovecot смонтирует этот экспорт и будет хранить на нем электронные письма.
2- Я создам несколько "дисков" (томов в облаке) и создам распределенный том GlusterFS на этих дисках; а когда файловая система заполнится, я создам еще "диски" и добавлю новые "диски" в распределенный том GlusterFS, и заново его сбалансирую. Мой Dovecote смонтирует этот том с помощью glusterfs-client и будет хранить на нем электронные письма.
(Повторяю: мне не нужна репликация, потому что мой «диск», том в частном облаке, реплицирован изнутри)
Как вы думаете, какой вариант лучше:
- производительность? (много-много небольших операций чтения/записи ввода-вывода)
- стабильный?
- гибкий?
решение1
Вам необходимо учитывать схему ввода-вывода почтового сервера: чтение/запись.многонебольшие файлы как можно быстрее. Оба ваших варианта действительно не подходят для этого при работе с большим количеством клиентов, ИМХО.
Ни одна из FS не достаточно быстра, и я полагаю, что особенно существенными будут накладные расходы на блокировку GlusterFS. Затем вы добавляете еще один слой с NFS, у которого есть свои накладные расходы. Вместо этого я бы попытался подключить почтовое хранилище с минимальными накладными расходами и быстрой файловой системой. Обычно это означает подключение к физическому хранилищу как можно более напрямую, но поскольку вы скрываете свою архитектуру за ерундовыми терминами бинго вроде «частное облако», мы не знаем, что будет возможно.
Один из подходов, который вы могли бы попробовать, — экспортировать хранилище через iSCSI на почтовый сервер, а затем использовать файловую систему, которая быстро работает с большим количеством небольших файлов, и, возможно, если это действительно важно, использовать LVM, чтобы иметь возможность легко добавлять пространство к этой файловой системе в виде дополнительных томов iSCSI (что добавляет некоторые накладные расходы).
Но что бы вы ни попробовали, вам придется сравнить разные варианты и посмотреть, получите ли вы требуемую производительность.
решение2
Если вам нужно выбрать один из двух вариантов выше, то, я думаю, NFS предпочтительнее.
GlusterFS теряет все свои преимущества как распределенной файловой системы в вашей настройке, поскольку тома OpenStack по-прежнему монтируются из центрального хранилища. Он не более стабилен и не более умен, поскольку он должен заботиться о распределенной блокировке файлов, в то время как блокировка NFS выполняется на одном сервере.
Я не уверен, что объединение вашего хранилища с нескольких устройств — хорошая идея. В качестве альтернативы вы можете рассмотреть возможность пропуска высокоуровневой функциональности службы томов OpenStack и предоставления вашего хранилища напрямую — отформатированный том LVM(/ZFS/SAN), экспортированный NFS. Поступая таким образом, вы исключите ненужный уровень iSCSI и сможете увеличить пространство для хранения почты по требованию, пока в основном хранилище достаточно свободного места.