В ближайшие несколько месяцев мы собираемся перевести наш почтовый сервер с postfix / courier на Zimbra. Мы довольно успешно запустили прототип сервера через iSCSI LUN, экспортированный из Dell Equallogic. Equallogic - это не наша «производственная» SAN, а NetApp FAS 2050.
Одна из проблем с системой на основе iSCSI LUN - это отсутствие гибкости. Что, если нам нужно изменить размер, не останавливая всю систему? Я считаю, что включение хранилища данных Zimbra в экспорт NFS поможет с точки зрения
Минусы перехода на NFS
Вопрос в том, будет ли Zimbra (которая запускает целый стек демонов, включая spamassassin, причал и, самое главное, MySQL), достаточно надежной и стабильной для работы под NFS - настраиваем ли мы себя на потерю данных, запускаемых MySQL под NFS? Если мы решим запустить его под NFS - что мы можем сделать, чтобы настроить производительность?
Изменение размера iSCSI LUN на лету в NetApp не представляет большого труда, мы делаем это постоянно. Единственная проблема заключается в уровне поддержки вашей файловой системы для изменения размера блочного устройства на лету. Тем не менее, простота использования снимков и файловой системы журнала WAFL - два больших преимущества NFS в NetApp.
Хотя я не имею дела с Zimbra или любыми другими почтовыми серверами в своей сфере деятельности, это ужасно похоже на споры о FC / iSCSI и NFS для ESX. Запуск ESX на NFS против NetApp не составляет труда, в основном для моментальных снимков и надежности WAFL. Скорость не оказалась проблемой. Существует множество тестов, показывающих, что NFS со скоростью 1 Гбит / с может противостоять FC 4 Гбит / с для ESX (в основном это связано с очень случайным характером трафика ввода-вывода ESX).
Если вы хотите, чтобы идти еще быстрее, вы всегда можете вставить сетевую карту 10 Гбит / с в NetApp (хотя не уверен, что серия 2000 может работать со скоростью 10 Гбит / с ...), и она может сдуть любую (8 ГБ / с) карту FC, которую вы можете купить сегодня.
Eсть размещение на форумах Zimbra по этой самой теме. Плакат там был с NFS.