Тестирование разных вариантов RaidZ на Nexenta
В последнее время я довольно много провожу времени, разбираясь с возможностями и проблемами такой интересной системы как 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.
- В начале я решил сравнить два пула один на raidz другой на raidz2 плюс в каждом пуле было по одному диску в host-spare. Итого 2 пула по 7 дисков в каждом в первом 4 диска под данные 2 под контроль четности 1 запасной, второй пул 5 дисков под данные один под контроль четности и один запасной, вот такие вот результаты у меня получились.
|
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. В дальнейшем хочу написать о том как ставить эту систему и проводить ее конфигурацию, а так же про различные способы подключения это хранилища к клиентским серверам.
Комментарии (0)
Добавление комментариев закрыто.

