В последнее время я довольно много провожу времени, разбираясь с возможностями и проблемами такой интересной системы как Nexenta. Для тех кто немного не в теме и не знает что такое Nexenta, поясняю. Nexenta – это диструбудив на базе ядра SunOS с депозитарием от Ubuntu. Соответственно он вобрал в себя самые интересные фичи от SunOS, а именно ZFS, и легкость в управлении и обновлениях от таких дистров как Ubuntu или Debian. Таким образом главная фишка в Nexenta, это прежде всего ZFS, то ради чего эта ветка по сути и затевалась.
Что же такое ZFS? Если коротко, то это динамическая файловая система, даже больше чем просто файловая система. Она включает в себя и контроль за физическими носителями, менеджер управления логическими томами, папками и многое другое. Разработанная в Sun Microsystems система была анонсированна в 2004 году и быстро привлекла к себе большой интерес. Пределы по объемам данных на этой системе огромны и достижимы только теоретически, простота и надежность, очень и очень впечатляюще, а многие фичи, которые там реализованы и хорошо работают, встречаются только у дорогих хранилищ, навроде EMC или Netapp.
Ну это если совсем коротко про данную файловую систему. Что меня интересовало в Nexenta в данном конкретном случае. Мне она нужна была для организации хранилища. И так что у меня имеется. Сервер, с 16*2Тб дисков из которого очень хочется получить максимум доступного места при высокой надежности и скорости записи. Данный сервер предполагается использовать в качестве сетевого хранилища куда будут сбрасываться бекапы с кучи серверов. После установки системы на 2 диска из которых был сделан зеркальный Raid у меня доступно для организации дискового массива осталось 14 дисков. Требуется организовать наиболее быстрый и надежный массив из этого количества дисков.
Берем доку где описываются рекомендации для организации пулов в ZFS ну и соответственно внимательно ее читаем, лучше несколько раз. Вот некоторые моменты, которые могут быть важны при организвации пулов, которые я отметил для себя:
* Организуем один пул для хранения на всю систему, не желательно разбивать все на несколько маленьких.
* Делаем виртуальные устройства в пуле одинакового размера.
* Используем диски целиком, а не нарезаем диски на слайсы.
* Делать vdev больше чем из 8 дисков не рекомендуется, будет падение по производительности, если дисков больше восьми лучше сделать пул из нескольких vdev.
| NAME | Seq-Wr-Chr | Seq-Write | Seq-Rewr | Seq-Rd-Chr | Seq-Read | Rnd Seeks |
| pool1 | 109 MB/s | 361 MB/s | 187 MB/s | 96 MB/s | 501 MB/s | 1453.4/s |
| pool2 | 112 MB/s | 490 MB/s | 232 MB/s | 93 MB/s | 640 MB/s | 1211.6/s |
Разница в скорости видна и преимущество тут у RaidZ над RaidZ2? что в общем-то понятно ибо дисков в работе больше как раз у второго пула.
2. Во втором случае я решил отказаться от hot-spare и оставить только живые диски. Итого я взял 2 пула: первый пул RaidZ 6 дисков под данные 1 под контроль четности, второй пул RaidZ2 5 дисков под данные 2 под контроль четности.
| NAME
|
Seq-Wr-Chr | Seq-Write | Seq-Rewr | Seq-Rd-Chr | Seq-Read | Rnd Seeks |
| pool3 | 112 MB/s | 499 MB/s | 240 MB/s | 94 MB/s | 690 MB/s | 2453.8/s |
| pool4 | 111 MB/s | 411 MB/s | 218 MB/s | 93 MB/s | 644 MB/s | 1559.6/s |
3. В этом случае был простестирован один большой пул состоящий из двух пулов поменьше RaidZ2 в каждом по 5 дисков под данные 2 под контроль четности. Вот примерно такие числа у меня получились
| NAME
|
Seq-Wr-Chr | Seq-Write | Seq-Rewr | Seq-Rd-Chr | Seq-Read | Rnd Seeks |
| pool5 | 111 MB/s | 432 MB/s | 216 MB/s | 92 MB/s | 608 MB/s | 4482.4/s |
4. В последнем случае я решил немного поэкспериментировать и собрал необычную конфигурацию, один большой пул состоящий из 2 рейдов RaidZ2 в одном 6 дисков под данные 2 под контроль четности, в другом 4 диска под данные 2 под контроль четности. Итого получилась несимметричная конфигурация, которая никак не рекомедуется к использованию в продакшн среде.
| NAME | Seq-Wr-Chr | Seq-Write | Seq-Rewr | Seq-Rd-Chr | Seq-Read | Rnd Seeks |
| pool6 | 111 MB/s | 426 MB/s | 221 MB/s | 93 MB/s | 634 MB/s | 5162.9/s |
Результаты получились очень даже ничего, практически по всем параметрам превосходящие предыдущий пул с симметричной структурой. Результаты заставляют слегка задуматься над тем как лучше конфигурировать, и какой набор дисков лучше использовать для построения дисковой системы. В лубом случае видно, что чем больше дисков используется под сами данные тем выше скорость операций, тем больше этих операций. Однако тут мы сталкиваемся с вопросом безопасности и сохранности данных. Использование вариантов с RaidZ дает большую производительность, однако этот вариант очень ненадежен ибо даже при потери одного диска ведет к большим проблемам и шансам потерять данные, а в случае когда вывалится 2 диска мы гарантированно потеряем все. Несмотря на то что это данные бекапа, хотелось бы таких ситуаций избежать. Поэтому, несмотря на скорость и хорошие результаты тестов с RaidZ, я для работы в дальнейшем выбрал для себя вариант с RaidZ2, а именно 3-й вариант.
Вот такие вот мысли по построению пулов на ZFS. В дальнейшем хочу написать о том как ставить эту систему и проводить ее конфигурацию, а так же про различные способы подключения это хранилища к клиентским серверам.