NFS на Btrfs на мультиустройствах .vs. Glusterfs на распределенном объеме?
Давайте предположим, что dev VLAN равняется 4, и mgmnt VLAN равняется 5.
На порте коммутатора dom0 включают транкинг VLAN и grantccess к VLAN 4 и 5.
На dom0 настраивают два интерфейса VLAN eth0.4 и eth0.5.
На dom0 настраивают два моста br4 (присоединенный к eth0.4) и br5 (присоединенный к eth0.5).
Имейте использование domUs соответствующий мост.
Альтернативная конфигурация передала бы конфигурацию VLAN в domUs, но это - угроза безопасности.
Вы должны учитывать схему ввода-вывода почтового сервера: Чтение / запись большого количества небольших файлов как можно быстрее. Оба ваших варианта действительно не подходят для этого при работе с большим количеством клиентов, ИМХО.
Ни одна из FS не работает достаточно быстро, и я думаю, особенно накладные расходы на блокировку GlusterFS будут значительными. Затем вы добавляете еще один уровень с NFS, у которого есть собственные накладные расходы. Вместо этого я бы попытался подключить почтовое хранилище с минимальными накладными расходами и с быстрой файловой системой. Обычно это означает максимально прямое подключение к физическому хранилищу, но, поскольку вы скрываете свою архитектуру за бинго-терминологией, такой как «частное облако», мы не знаем, что было бы возможно.
Если вам нужно выбрать один из двух вышеупомянутых, я думаю, что предпочтительнее NFS.
GlusterFS теряет все свои преимущества в качестве распределенной файловой системы в вашей настройке, поскольку OpenStack тома по-прежнему монтируются из центрального хранилища. Это ни стабильнее, ни более умный, поскольку он должен заботиться о распределенной блокировке файлов при блокировке NFS выполняется на sigle-сервере.
Я не уверен, что объединение вашего хранилища с нескольких устройств - хорошая идея. Альтернативно вы можете пропустить высокоуровневую функциональность службы томов OpenStack и открыть доступ непосредственно к хранилищу - том LVM (/ ZFS / SAN), экспортированный с помощью NFS. Поступая таким образом, вы исключите ненужный уровень iSCSI и сможете увеличивать объем почтового хранилища по запросу, если в основном хранилище достаточно свободного места.