ProfitBox – услуги DevOps

Тестирование разных вариантов RaidZ на Nexenta

nexenta

Nexenta

Rate this post

В последнее время я довольно много провожу времени, разбираясь с возможностями и проблемами такой интересной системы как 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.

     Вообще рекомендаций очень много и они могут играть огромную роль в работе пула в дальнейшем, поэтому стоит подойти к этому с вниманием. Меня в данном случае мучал вопрос, какой набор дисков лучше выбрать и какой тип рейда лучше использовать. Для этого я попробовал создать несколько разных пулов и потестить их бенчмарком Bonnie++. Вот какие эксперименты я ставил.
1. В начале я решил сравнить два пула один на 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. В дальнейшем хочу написать о том как ставить эту систему и проводить ее конфигурацию, а так же про различные способы подключения это хранилища к клиентским серверам.

Exit mobile version