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

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

#apt-clone upgrade

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


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

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

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

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

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