Заметки о Nexenta: Подготовка к работе

Раз добрались до этого шага, значит большое дело, а именно сама установка системы с той или иной степенью успешности был вами победно завешен. Закончив победные пляски с бубнами, пора пиступать к следующему этапу – настройке и подготовке к работе. Что я под этим подразумеваю? Тут имеется несколько моментов.

Ну во первых я установил бы последние обновления. Это всегда важно и делать надо всегда и на любой системе, не важно для чего она предназначена. Обновления помогают спасти от многих проблем знаете. На Nexenta, обновления ставятся практически также как на Debian, однако со своими особенностями характерными для фич zfs. Здесь, при большом обновлении, снимается снепшот системного диска, таким образом, чтобы при каких-либо проблемах откатится на предыдущее состояние системы. Очень и очень удобно знаете ли. Поначалу непривычно, но очень впечатляет, когда к этому привыкаешь и осваиваешь в нужном объеме. Делается это с помощью команды apt-clone, примерно таким образом:

#apt-clone upgrade

This operation will upgrade your system using ZFS capabilities. Proceed ? (y/n) y

Updating APT sources ...
Initiating Nexenta upgrade procedure. Please wait...

Не забываем, что надо в /etc/apt/source.lst прописать правильные репозитории, откуда будут качаться обновления, все как в Debian/ Далее будет производится скачивание, и установка нужных пакетов в зависимости от того какая версия nexenta у вас установлена и какие пакеты нужно обновлять. apt-clone работает по тому же принципу что и apt-get за исключением создания снепшота после обновления и ребута после этого самого обновления, если он требуется конечно. Вообще процедура довольно безопасная, но я ее все равно немного побаиваюсь, поскольку первый раз когда я это делал, я запорол систему и у меня не грузилось больше ни чего и ни с какого снепшота. Видимо я что-то делал не так, но поскольку ход моих действить восстановить не представлялось никакой возможности, то это осталось тайной покрытой густым мраком.

После установки обновлений, стоит проверить что все работает по прежнему хорошо. Проверили? Очень хорошо, я и не сомневался, что все по прежнему работает. Далее, я обычно ставлю такую полезную приблуду как napp-it. Это бесплатный веб-интерфейс для управления всеми основными фишками системы, приложениями и вообще практически всем, что есть в системе. Очень удобная штука, особенно по началу, когда только постигаешь возможности системы и опыта не хватает все делать через консоль.

napp-it

 Ну а если у вас NexentaStor, то там необходимости ставить веб-интерфейс нету, там он уже есть, встроен уже разработчиками, остается только через него проапгрейдить систему и поставить нужные плагины, которые вам потребуются по работе. Через napp-it можно делать очень широкий спектр действий с системой, пулами, папками, ну и вообще всем всем. Единственно что он имеет тот же недостато что и все веб-интерфейсы, если операция занимает слишком много времени, она отвалиться по таймауту и резльтатов ее выполнения вы никогда не увидите. Но для таких задач есть консоль, она поможет со всем разобраться.

Важный момент, который я обычно делаю до ввода сервера в основную работу – это настройка аггрегации на сетевых карточках. Сетевых карточек в материнских платах сейчас ставят не мало, зачем использовать только одну если можно использовать все как одну. Для этого, правда, необходимо чтобы ваш свич, куда будут воткнуты эти сетевушки умел поддерживать стандрат IEEE 802.1AX. Вещь это распространенная, во всех более или менее нормальных свичах она есть. Как настраивать свич я рассказывать не буду, там все зависит от производителя. Что касается Nexenta, то там это делается командой dladm. Допустим у вас есть 2 интерфейса на материнке, которые видны как e1000g0 и e1000g1 и вы хотите их аггрегировать по активному типу, тогда комманда которую надо вам будет ввести в консоле, будет выглядеть следующим образом:

dladm create-aggr -L active -l e1000g0 -l e1000g1 aggr1

После выполнения этой команды создасться аггрегирующий интерфейс aggr1, который будет состоять из двух физических интерфейсов e1000g0 и e1000g1. Осталось прописать адреса в стартовые конфиги системы. Для это в каталоге /etc/ создаем файлик hostname.aggr1, куда добавляем всего одну строчку:

xxx.xxx.xxx.xxx netmask 255.255.255.0 broadcast + up

Где xxx.xxx.xxx.xxx это IP адрес. Маску тоже указываем правильную. Шлюз прописывается в файлике /etc/defaultrouter. Вот в общем-то и все, если со свичем у вас тоже все получится, то никаких проблем с использованием подобного рода аггрегации на этой системе не будет, а польза будет. Согласитесь, что совсем не хочется упереться в производительность сети на уже во всю работающем сервере и судорожно искать как эту проблему решить.

Заметки о Nexenta: Установка Nexenta

Доброго времени суток. Итак, вы уже определились с тем что действительно хотите поставить себе дистрибутив Nexenta для тех или иных целей, а так же вполне определились с тем железом куда собираетесь эту систему устанавливать. Соответсвенно логично перейти к следующему шагу – это установке самой системы. Сейчас на выбор есть 3 варианта, ну на самом деле 4-е, но StormOS я сюда не включаю, так как это чисто десктопный проект на базе nexenta. Так что сейчас имеются варианты с Nexenta Core, NexentaStor Community Edition и NexentaStor Enterprise Edition. В чем различия и что выбрать?

Различия прежде всего в функционале и дополнительном функционале, который предоставляется в Enterprise редакции, а так же в поддержке, которую можно получить. Если Nexenta Core, в своем базовом варианте, это просто голая система без красивого веб-интерефейса, но при этом с полным набором функций, который предоставляет zfs и система в целом, единственно,nexenta_install4 надо будет все настраивать самому через коммандную строку, ну или поставить napp-it, который выглядит и действует не хуже веб-интерфейса в NexentaStor. При этом в Core нет никаких ограничений на объем хранимого места или организацию кластера. А вот в NexentaStor Community Edition такие ограничения есть. Там есть ограничения на 18Тб хранимых данных на системе, число конечно не маленькое, но при существующих размерах дисков и данных хранимых на них, это квоту можно выбрать довольно легко. Так же присутствуют определенные ограничения на организацию кластерных систем ну и нет доп. функционала который присутствует в Enterprise Edition. А так в целом, все что надо тут есть, плюс сразу дают красивый веб-интерфейс. Шелл тоже есть, но он до определенный степени обрезан и унифицирован, все что надо можно сделать через него, но ничего больше, непривычно я бы сказал, но работать можно. Если же вы хотите работать без ограничений, плюс к этому получить дополнительные плюшки, тогда вам за Enterprise Edition. В ней, за ваши деньги вы получите полный функционал без лимитов и ограничений, плюс дополнительные плагины типа VM Datacenter, который позволяет интергировать сторадж в систему виртуализвации, например Xen или Hyper-V если вы содираетесь использовать ваше хранилице для этих целей, в целом удобно и позволяет многие вещи упростить, если это действительно необходимо.

Это был небольшой обзор по различным дистрибутивам и тем возможностям, которые они представляют. Думаю пришло время переходить к самой установке. А точнее к ее подготовительной части. Ведь перед тем как устанавливать систему, нужно ее где-то взять. Core Edition можно скачать на сайте http://www.nexenta.org. Что качается NexentaStor то за ней путь дорога лежит сюда http://nexenta.com. На этом же сайте можно пробить себе и лицензионный ключ, он вам понадобиться для установки NexentaStor. Закатываем дистрибутив на диск, и можно переходить непосредственно к самой установке.

 

Установка проста и не требует каких-то особых знаний или какого-то шаманизма, ну разве что у вас не будет каких-то приключений с железом, по типу того что я описывал в предыдущей статье. Но это скорее исключение чем правило. Саму установку я бы разделил, на 3 этапа. На первом этапе у вас загружается система установки, проверяются диски и прочее железо, проверяется возможность установки. Далее следует лицензионное соглашение, выбор часового пояса ну и самое интересное на этом этапе, это выбор дисков для установки. В Nexente, в отличии от например линуксовых систем, есть четкое разделение между системными дисками, дисками которые целиком и полностью оттданы под систему и дисками на которых хранятся данные. Это различие четко становиться видно во время этого этапа установки. Предлагается выбрать диски, которые будут заюзаны конкретно под систему и не под какие другие цели больше. Можно выбрать 1 диск или например 2 под зеркало, или еще больше если не жалко, так же можно выбрать диски под hot-spare в системный раздел. Будте внимательны в дальнейшем эти диски для организации пула хранилища использовать не получиться, так что выбирайте хорошенько подумав сколько дисков использовать под систему. Если дисков мало и жалко тратить ценный ресурс, то используйте 1 диск, если резерв есть, то 2 диска в зеркале будет лучше, для дополнительной надежности.

nexenta_install1

     После выбора дисков под систему, разбивать их не надо, да выбирать системные разделы не придется, все уже выбрано до вас и установиться в соответствии с шаблоном. В этом и заключается весь 2-й этап как я бы его обозвал. Разбиваются диски, организуется zfs-пул под системный раздел и копирутся файлы с системой на диск. После этого наступает время третьего этапа, где можно задать пользователей для доступа, пароль для рута, IP адреса. Завершаем установку и перезагружаемся в новую систему. Поздравляю система установлена и готова к работе. Точнее еще не совсем готова, но осталось не так много, о том как подготовить Nexenta Core к работе я расскажу в следующей статье.

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