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