Заметки о Nexenta: Выбор железа

Поскольку материалов и идей по поводу такой системы как Nexenta и ZFS у меня довольно много, появилась мысль набросать небольшой цикл статей, в котором отобразить основные моменты по поводу работы с данной системой. До этого немного ранее я написал небольшую заметочку об различных вариантах raidZ и их работы. Статья получилась несколько вырванной из контекста, так что лучше начать все сначала, от самих истоков, от выбора железа и установки.

Почему вообще возникла мысль работать с Nexenta? Все очень просто, нужно система для мощного, надежного сетевого хранилища, способного подключаться к клиентским серверам по различным протоколам, например NFS или iSCISI. Что обратило взгляд именно на Nexenta? Вообще изначально была идея использовать ZFS. Когда начал копать под ZFS все само собою вытекло к Nexenta. Это и не удивительно, ибо Nexenta – это очень удачный порт с Sun Solaris, в котором реализованные самые новые технологии по хранению данных. Ну например дедупликация, очень вкусная плюшка. Она например присутствует у только самых продвинутых производителей специализированных хранилищ за большие деньги, не будем называть имен, те кто немного в теме прекрасно понимают о ком я.

Вариантов как использовать данное хранилище, у меня было много. Основной рассматривался как хранение бекапов, очень удобно и просто. Другие варианты более сложные, это в качестве iSCISI хранилищ для разных вариантов виртуализации, например для Hyper-v. Ну, а пока что до них руки не дошли, думаю обязательно попробую как нужда заставит, а там и будет повод написать об этом. Пока что, в бою используется вариант как сетевого хранилища для бекапа. Ну что раз сказано, надо делать.

Что у нас есть? Есть сервер, точнее 2 примерно одинаковых сервера, но сейчас речь пойдет об одном. Следующей конфигурации: процессор Intel(R) Xeon(R) CPU X3440 @ 2.53GHz CPU, память 12Гб, 16*2Tb SATA disk. Таким образом, емкости на дисках около 32Тб, но это если просто на дисках, нам же важно еще скорость, удобство и прежде всего надежность. Чтобы все это получить мы и ставим Nexenta. Есть маленький нюанс. Как заметит пытливый читатель, каким образом я подключил все 16 дисков к одной материнской плате? Да, все верно, диски подключаются не напрямую, а через адаптер. Поскольку нам тут не требовалось навороченного адаптера, который мог бы поддерживать сложные, многодисковые рейды, а нужна простенькая плата, которая бы просто транслировала бы диски и позволяла бы загружаться с них, то изначально выбор пал на LSI SAS HBA. Однако тут я столкнулся с первой проблемой, которая чуть не стала последней. Система упорно не хотела ставиться, точнее делала это очень долго и очень меееедленно, настолько долго, что даже прождав сутки я так и не дождался установки до конца.

Такой поворот событий подействовал на меня довольно угнетающе, но все-таки я упорный парень и немного потанцевав с бубном и потыкав диски, было обнаружено, что такая проблема наблюдалась на дисках одного производителя (Western Digital), однако на дисках другого производителя (Seagate) такой проблемы не было. И при этом такое было только в сочетании с платой от LSI. Вот такая вот загогулина. Между прочим, на сайте LSI написано, что Solaris они не поддерживают в принципе. Так что после некоторого размышления, было принято волевое решение, отказаться от данной платы, в пользу старого, проверенного рейда от Adaptec. Но кто хочет пользоваться платами от LSI, у меня она работала только вместе с дисками от Seagate, при этом работала неплохо, но с другими вендорами работать отказывалась напрочь.

На самом деле информации по железу и совместимостям у меня не так уж много, тестировалось мною это не на таком уж большом количестве различных вариантов, так что в будущем, мне кажется, ожидается еще немало удивительных открытий. В любом случае, рекомендации по железу можно выразить следующие. Основное здесь дисковая подсистема, поскольку дисков можно использовать много, практически до бесконечности, то используем большие корпуса с хорошей вентиляцией, с контроллерами, куда можно воткнуть много дисков. Так как с LSI контроллерами я уже обжегся, то использую контроллеры Adaptec, диски подключаются как jbod или simple volume. Система сама по себе много места не требует, так что, под систему используются диски небольшого размера 250Гб вполне подойдет, запросто можно и меньше, у меня меньше просто не нашлось.

По поводу памяти. Память  на хранилище особо ни к чему, если только не запускать на нем приложения какие-то, но тогда это уж не просто хранилище получается. Однако есть один момент, помять нужна для дедупликации, поскольку вся информация о блоках пишется в память, то для этой цели она используется очень активно. Вообще есть вот такая формула:

[number of blocks used] * 320 = [RAM requirements in bytes]

т.е. чем больше блоков у вас в системе и меньше их размер, то тем больше вам требуется памяти. Но память сейчас не такая уж дорогая, так что при необходимости можно дорастить, либо не пользоваться дедупликацией, если она вам не особо нужна. Весь вопрос упирается в целесообразность. Как, в общем-то, и всегда.

Стоит обратить также внимание на сетевушки, раз уж мы разговариваем о сетевых хранилищах, то сеть бы хотелось бы иметь побыстрее. В Nexenta совершенно просто делается агрегация между несколькими сетевыми карточками, так что если ваши свичи это поддерживают, то не стесняемся использовать столько сетевушек сколько вам надо, главное чтобы дисковая подсистема выдержала. Процессор, кстати, используется не так активно, разве что только когда включено сжатие или шифрование, но все равно, мощности современных процессоров хватает за глаза.

В любом случае, есть замечательная статья  в которой очень много рекомендаций по развертыванию ZFS в том числе и тех, которые наводят на мысли о правильном выборе железа для этой цели. Ну и к тому же есть практический подход, пока не попробуешь, не узнаешь, какое решение наилучшее в том или ином случае. В общем и целом, по рекомендациям выбора железа наверное все, хотя обсуждать некоторые момент можно еще долго. Но это делать лучше в другом месте.

 

Тестирование разных вариантов 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.

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