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

Sep 30, 2011Написал Alex

 


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





Комментарии (0)


Добавление комментариев закрыто.