about NetApp

Любопытная статья обнаружилась в веб-журнале The Register.

На конференции FAST’11 NetApp читал доклад о экспериментах в рамках проекта Mercury, где исследовалась интересная модель использования flash-памяти для кэширования данных серверов приложений.
Аналогичным работами также занимаются и другие участники “топа вендоров”, например о Project Lightning недавно на своей конференции рассказывал EMC, кроме этого аналогичные эксперименты проделывал Dell, активно прорывающийся в “самую высшую лигу”.

Суть эксперимента состояла в возможнеости связать кэш во flash memory на сервере приложений, с централизованным дисковым хранилищем, чтобы позволить виртуальным машинам использовать сетевой сторадж не теряя преимуществ от использования объемного локального кэша на самом сервере.

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

??нтересный отчет опубликовала сегодня тестовая лаборатория NetApp, анализировавшая производительность Oracle 11g на RHEL и системе хранения NetApp.

Для затравки вам картинка:

Полностью читать – там:
Red Hat Enterprise Linux Protocol Performance Comparison with Oracle Database 11g Release 2
http://www.netapp.com/us/library/technical-reports/tr-3932.html

Прошло 3 месяца с момента объявления о покупке NetApp-ом у LSI его подразделения про разработке и продаже внешних дисковых систем, которое было известно под именем Engenio (ESG).

Я не собирался к этой теме возвращаться (по крайней мере часто), как и вообще к теме FC-систем "традиционной архитектуры", которые приобрела, вместе с Engenio, NetApp, так как, в целом, лично мне, они не очень интересны.

К сожалению, я обратил внимание, что в рунете вокруг этой истории раздулся какой-то непонятно-скандальный "ажиотаж", и возникло много непонимания, поэтому я, этим постом, постараюсь ответить на основные вопросы, развеять слухи и заблуждения, вокруг этой истории возникшие.

Что именно купил NetApp?

NetApp приобрел у компании LSI ее подразделение, занимавшееся разработкой, производством и продажей OEM-партнерам дисковых систем хранения "традиционной" архитектуры блочных FC-систем.

Подразделение носило название Engenio, и, в основном, было известно как OEM-поставщик. Напрямую Engenio эти системы, как я знаю, не продавало, однако являлось (и является), по всей видимости, крупнейшим OEM-производителем в этой области. Engenio производила и поставляла своим партнерам, для их продажи такие популярные и широкораспрстраненные системы, которые рынок знал, как IBM DS35xx, DS4700 и 4800, DS5xxx, Sun StorEdge 35xx и 6xxx, а также ряд систем Dell, SGI и Teradata.

Что НЕ купил NetApp?

Сама компания LSI, материнская, по отношению к своему дочернему подразделению Engenio, продолжает работать как и раньше. Все, что разрабатывала и производила сама LSI продолжает разрабатывать и производить она сама. Это: серверные RAID-контроллеры, прошивки для них, HBA, а также линейка продуктов ONStor. Все это НЕ было приобретено с Engenio, также как не была приобретена сама LSI. Компания LSI и относящиеся к ней продукты продолжают свое существование.

Что еще было приобретено, вместе с Engenio?

Вместе с Engenio были “приобретены” отношения Engenio с ее OEM-партнерами, например IBM, Oracle, и так далее.

Какие системы входят в линейку NetApp E-series?

Это E2600, E5400 и E7900.

Кто и как теперь будет разрабатывать и производить системы хранения Engenio?

??х по прежнему будет разрабатывать и производить команда, ранее работавшая как Engenio, и теперь вошедшая в состав NetApp.

Кто и как теперь будет продавать системы Engenio?

Несмотря на то, что системы Engenio теперь называются NetApp E-series, напрямую, через каналы NetApp и его партнеров, они продаваться не будут. Они будут продаваться через прежние каналы Engenio и его OEM-партнеров, а также через нескольких специализрованных VAR-реселлеров в США (только), которые будут продавать "коробочное решение" для Full-motion Video в US Public Sector.

Как это отразится на OEM-отношениях NetApp и бывшей Engenio с их партнерами?

Пока это не отразится никак. Все ранее заключенные соглашения о OEM продолжают действовать. Не в последнюю очередь (если не в первую) вместе с Engenio NetApp покупала и крупнейшее по объемам в отрасли портфолио OEM-контрактов.

Как это отразится на нынешних OEM-отношениях NetApp, например с IBM или Fujitsu?

Никак не отразится. Все нынешние отношения с партнерами и OEM, как NetApp, так и Engenio останутся и напрямую они не пересекаются.

Зачем это все?

Ну, во-первых, за 480 миллионов был куплен рынок, объемом 750 миллионов в год (2010). Что, по нынешним временам, само по себе неплохо.

Во-вторых, вместе с Engenio была приобретена большая, лояльная и объемная сеть OEM-отношений, которых у NetApp ранее почти не было (если не считать отношений с IBM).

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

Что это за нишевой рынок?

Это рынок для "неинтеллектуальных" систем хранения традиционной блочной FC-архитектуры, для задач, требовательных по bandwidth (полосе пропускания).

Это сравнительно небольшой сегмент (по оценке NetApp это 5 миллиардов долларов к 2014 году, сравните с 47 миллиардами для unified systems самого NetApp, спрогнозированных на тот же 2014).

Пример таких систем - хранилища с большим bandwidth (полосой пропускания) для записи данных Full-motion Video, спутниковых потоковых данных, геосейсмики, науки, а также для специфических задач, например для использования в хранилище под проекты архитектуры Hadoop (о Hadoop – позже).

Еще раз напомню, что NetApp E-series не будет продаваться в традиционном канале продаж NetApp, и не будет конкурировать с привычными NetApp FAS, эти системы покупаются для расширения предложения в узком, ранее неохваченном сегменте рынка, под узкий круг заказчиков систем такого рода (причем, как я подозреваю, под уже существующего конкретного крупного госзаказчика из трех букв, уж больно много подробностей об этом решении), с которыми будут работать традиционные OEM-партнеры Engenio.

Означает ли это отказ от развития и продвижения FAS и Unified-архитектуры?

Нет, не означает. Просто предложение расширяется в те сегменты рынка, где нынешние возможности систем NetApp избыточны, и экономически неоправданны.

Означает ли это признание неудачи в развитии Unified Architecture?

Нет, не означает. Приобретенная линейка E-series ориентирована на специализированный рынок с узким набором специфических требований. Для прежних сегментов рынка по прежнему будет развиваться и продвигаться unified архитектура и системы с ее использованием.

В чем преимущества существующих систем unified-архитектуры, NetApp FAS?

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

Основное направление развития систем NetApp FAS – увеличения возможностей по управлению данными и переход к виртуализированному “облачному” хранению.

В чем преимущества существующих систем "классической" архитектуры, NetApp E-series?

Высокая линейная производительность на запись и чтение, сверхбольшая производительность по полосе пропускания и IOPS, высокая плотность “упаковки” хранилища (1,8PB в 40U).

Основное направление развития систем NetApp E-series – увеличение производительности на специальных типах нагрузки и повышение плотности хранения.

Существуют ли планы по слиянию этих платформ?

Нет, таких планов нет. Две платформы будут существовать независимо, как, например, существовали в продуктовом portfolio NetApp, в свое время, FAS и VTL.

Существуют ли планы по отказу от развития Unified Architecture (FAS)?

Нет, таких планов нет. Системы Unified Architecture (FAS) по прежнему будут развиваться и продвигаться.

Существуют ли планы по закрытию и прекращению развития продуктов Engenio?

Ну а вы бы, купив за 480 миллионов "живыми деньгами" успешный бизнес, принесший в прошедшем году около 750 миллионов, стали бы его убивать ради удовлетворения каких-то своих амбиций? Нонсенс.

Означает ли возникновение в продуктовой линейке решений на базе E-series отказ от систем NetApp C-mode?

Нет, не означает, они нацелены на разные рынки, как и FAS 7-mode.

Ожидаются ли изменения в поддержке продуктов LSI/Engenio в системах NetApp V-series?

Нет, изменения не планируются, поддержка будет осуществляться как и ранее, в прежнем объеме.

Существую ли планы по переносу Data ONTAP/WAFL на системы E-series?

Нет, таких планов нет.

Есть ли планы использовать аппаратные RAID LSI в системах NetApp?

Нет, таких планов нет.

С какими системами будет конкурировать новое решение NetApp для Full-motion Video? EMC? HP?

На самом деле нет. Это конкурент для систем Data Direct Network (если вы такого производителя знаете), а также, отчасти, для BlueArc и Isilon. Это, повторюсь, нишевое специализированное решение, традиционные системы EMC или HP для него не подходят также, как не подходит NetApp FAS.

Что там за возня с Hadoop, и что это вообще такое?

Скоро расскажу. :)

Что я еще не знаю интересного об этой сделке? ;)

Нынешний CEO NetApp, Tom Georgens, до прихода в NetApp был руководителем Engenio.

Как мне тут не раз уже попеняли, некорректно сравнивать tiering-as-datamoving и tiering-as-caching, то есть, например, NetApp Flash Cache и EMC FAST VP. Допустим, как я ни старался в соответствующей статье, я вас не убедил, что обе эти формы повышения эффективности системы хранения для пользователя есть суть одно.

Хорошо, давайте рассмотрим отдельно особенности, достоинства и недостатки только Flash Cache (PAM-II) и FASTcache.

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

Во-вторых если мы посмотрим на то, как у EMC предполагается использовать SSD диски под FASTcache, вы, уверен, вместе со мной поразитесь неффективности.

Допустим, мы разворачиваем систему хранения для 1000 рабочих мест под десктопную виртуализацию на XenDesktop. Рекомендуемая схема включает в себя три диска SSD, из которых один - hotspare, а два других образуют "зеркало" RAID-1. Таким образом, очевидно, что эффективность использования flash в такой конструкции будет примерно 33%, то есть одна треть от купленной емкости flash. Да, при увеличении объема FASTcache, кроме роста цены будет расти и эффективность использования, но она никогда не превысит 50%, за счет использования RAID-1 (плюс hotspare). Больше половины затраченных на SSD денег будут простаивать. По контрасту, если вы покупаете 256GB Flash Cache, вы можете использовать под кэширование и ускорение работы с данными все 256GB, сто процентов от затраченных на них денег.

В третьих, стоит обратит внимание, что использование SSD как дисков вынуждает EMC разместить этот кэш "снаружи" контроллера, в "петле" дискового ввода-вывода на интерфейсе SAS. В то время, как у NetApp плата Flash Cache располагается непосредственно на системной шине контроллера, на PCIe (PCIe v2.0 x8 в моделях 3200/6200, пропускная способность 32Gbit/s в каждом направлении). То есть взаимодействие контроллера с кэшем в случае FASTcache такое: данные пришли через ввод-вывод на контроллер, по каналу SAS к дискам, вышли через другой порт и записались на SSD по интерфейсу SAS. Затем, если к данным кэша обращение, они должны считаться через дисковый канал ввода-вывода по SAS обратно в контроллер, и отдаться через третий канал ввода-вывода, собственно инициатору запроса, по FC или iSCSI, или NFS/CIFS. Все это, безусловно, нагружает и так не бесконечные возможности дискового канала ввода-вывода к полкам, и, потенциально, может привести к ограничению производительности.

Наконец, стоит помнить, что, хотя в FASTcache удалось значительно снизить размер оперируемого "чанка" до 64KB, против гигабайта в FAST-"просто", все же этот размер достаточно велик для многих задач, работающих в random read/write, размер блока кэша, значительно превышающий рабочий для соответствующей файловой системы или задачи, например блока базы данных, также снижает эффективность использования такого кэша, если, допустим, только 4KB из блока в 64KB нам действительно нужны (при 100% random это довольно обычная ситуация), то это значит, что эффективность кэша составляет лишь 1/16 от своего фактического объема.

Что же в плюсах? Очевидно, что это активно "педалируемая" EMC возможность работы такого кэша на запись. Особенно на это нажимают в сравнении с NetApp Flash Cache, который на запись не работает, и эта возможность действительно производит впечатление на тех людей, которые не особенно разбираются как там у NetApp все устроено, и знают только то, что "что-то иметь это гораздо лучше чем не иметь", и уж все знают, что запись надо кэшировать, без кэширования запись на диски очень медленная, это знает даже начинающий пользователь, впервые покупающий кэш-контроллер в сервер.

Чем прежде всего занимается кэш на запись?
Давайте рассмотрим на примере.

Когда клиент записывает блок данных на систему хранения, то, при наличии кэша на запись, этот блок максимально быстро в него помещается, и клиенту отдается сообщение “OK, принято”, клиент не ждет физического помещения блока в сектор жесткого диска, а может продолжать работать, словно записываемый блок уже записан, например отправить следующий блок.
Запись ускоряется путем ее буферизации, и, в дальнейшем, сортировкой и упорядочением процессов записи.

Хотя современный жесткий диск и позволяет обращаться к произвольным фрагментам записанной на него информации, чем отличается от, например, магнитной ленты, которая позволяет считывать и записывать ее только последовательно, однако не позволяет эту произвольно размещенную (random) информацию считывать и записывать _одновременно_, поскольку это физически ограничено возможностями магнитных головок диска.

Если у нас есть жесткий диск, и мы не используем кэширование, то три клиента, пишущих на этот диск, будут вынуждены выстроиться в очередь. Сперва диск спозиционирует головки и дождется подхода нужного сектора для записи блока данных клиента A, а пославшие на запись свой блок клиенты B и C будут вынуждены ждать, затем головки будут переставлены в новое место, диск дождется, когда мимо головок проедет блок, который требуется перезаписать клиенту B, и перезапишет его, а если за это время у клиента A появился еще один блок на запись, то он поставится в очередь следом за блоком клиента C, и будет ожидать, пока выполнятся все операции перед ним.

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

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

Кэш же внутри себя удерживает блок, ожидая подходящего момента на запись, а также оптимизирует записи, с тем, чтобы уменьшить "пробег" магнитных головок по диску, и возможно оптимальным образом перекомпонует записи так, чтобы уложить их максимально эффективным, с точки зрения head seek-а, способом.

Принципиальное отличие WAFL тут состоит в том, что WAFL не перезаписывает блоки уже записанные на диске, и значит при записи клиенты гораздо меньше ожидают seek-а. Вы помните, что в WAFL записи можно провести "чохом", в выделенный сегмент, а не переписывать по одному блоку, мечась по всему диску, здесь и там, ожидая, когда подъедет под головку тот или иной блок. Поэтому даже без традиционного кэширования записи на WAFL клиентские записи быстро оказываются на дисках.

Строго говоря, большой кэш означает, что, используя транспортную аналогию, записи быстро встают в очередь на посадку, но совсем не значит, что при этом они быстро сядут и поедут.

WAFL оптимизирован именно на минимальное время от момента прихода данных "на остановку" и до входа их "в автобус" жесткого диска, превращая записи в записи последовательного порядка (sequental) из поступающих записей в произвольном порядке (random).

Результат хорошо иллюстрируется экспериментом, в котором один aggregate, состоящий из трех дисков SATA 1TB 7200rpm, в RAID-DP (2p+1d), то есть, фактически, из одного действующего диска, показывает при random write блоком 4KB не типичные для SATA 70-80 IOPS, а более 4600!

Объяснение этому простое - записи, поступающие на диск теряют свою "рандомность", и "секвентализируются". Около четырех с половиной тысяч IOPS random-записи на один диск SATA - это как раз то, отчего в системах NetApp нет свойственной для "классических систем" острой необходимости в кэше записи на уровне контроллера.

Таким образом запись действительно надо кэшировать для "классических" систем, да, безусловно, это так. Но это совсем не так безусловно для "неклассических" дисковых структур, используемых, например, в NetApp.

Вот почему NetApp Flash Cache не используется на запись данных, работая всем своим объемом только на чтение. Вот почему необходимость кэширования записи для WAFL не столь безоговорочна, как для "классических" дисковых структур.

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

Это позволило, среди прочего, кстати, значительно упростить алгоритмическую составляющую процесса кэширования, ведь не секрет, что правильная обработка кэширования на запись часто создает значительные проблемы, особенно в наиболее эффективном режиме write-back.

А это, в свою очередь, снизило количество возможных ошибок (как программного кода реализации, так и ошибок при использовании) удешевило устройство и упростило использование.

Прошу извинить меня, что я так затянул с розыгрышем. Я тут как раз переезжал в другое полушарие :)

??так, у нас было семь участников:

Я сходил на random.org, и он мне сказал, что разыгрываемый приз получит участник номер 5: ник Kosmatiy.

Напомню, что мы разыгрывали gift certificate Apple iTunes, или gift certificate Amazon на 25$, или же подарочный сертификат магазина OZON на 1000 рублей, любой один из трех, по выбору победившего.

Победитель, свяжись со мной по адресу romx@mail.ru, чтобы сделать свой выбор и получить выигрыш.

Надеюсь, что вскоре мы проведем еще не один такой розыгрыш, осталось только придумать тему, так что шансы на подарок еще будут. :)

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

NetApp OnCommand 5.0 это результат интеграции нескольких собственных продуктов NetApp (System Manager, My Autosupport, SnapManager, Protection/Provision/Operations Manager, Virtual Storage Console (VSC), а также ApplianceWatch), с двумя сравнительно недавними приобретениями – системы для мониторинга, анализа и планирования SANscreen, приобретенный вместе с компанией Onaro в 2008 году, и продукта BalancePoint, приобретенного с компанией Akorri в феврале 2011. Все эти продукты теперь интегрированы под общей платформой – OnCommand.

OnCommand будет поставляться в двух частях – платной OnCommand Insight, и бесплатной OnCommand Basic.

Если вы уже знакомы с SANscreen (вряд ли, но все же), то ранее существовавшие функциональные модули его переименованы и объединены в составе продукта OnCommand Insight для лучшей архитектурной ясности:

• OnCommand Insight Assure включил в себя компоненты SANscreen Service Insight, Service Assurance, и VM Insight.
• OnCommand Insight Perform это бывший Application Insight.
• OnCommand Insight Plan это бывший Capacity Manager

О Akorri BalancePoint стоит отдельно рассказать подробнее, но для общего представления стоит начать со статьи Ника Триантоса в его блоге. BalancePoint это довольно объемный продукт, поставляемый как преднастроенная виртуальная машина под OS Debian Linux, со всеми необходимыми предустановленными, настроенными и связанными компонентами, с размером диска 80 или 200GB, в зависимости от нужного количества обслуживаемых виртуальных или физических серверов.

• Продукт Akorri BalancePoint, стал OnCommand Insight Balance

OnCommand Insight можно будет покупать как целиком, так и по отдельности, любой из его четырех компонентов. А OnCommand Basic будет доступен бесплатно. Все семейство OnCommand появится в продаже и загрузке с 1 сентября 2011 года.

Обратите также внимание, что OnCommand Insight, хотя и выпущен компанией-производителем хорошо вам знакомых систем хранения, но работает он со всей вашей IT-инфраструктурой, не обязательно и не только с системами хранения NetApp. Строго говоря, даже вообще наличие систем хранения от NetApp для использования средств OnCommand Insight не обязательно, это продукт для инфраструктуры в целом, для VMware vSphere, MS Hyper-V, FC-коммутаторов Brocade, сетевых коммутаторов и маршрутизаторов Cisco, систем хранения EMC или HP – для всех.

Вы уже знаете, что каждая система хранения NetApp, вернее даже каждый ее контроллер, обязательно имеет на подключенных к нему дисках специальный, обычно самый первый, том, так называемый root volume или vol0. На этом томе хранится содержимое настроек и установок внутренней OS Data ONTAP (для знакомых с миром UNIX OS скажу проще – /etc), а также много всего прочего, включая директорию документации и веб-интерфейса, прошивки дисков, конфиг-файлы репликации и прочее жизненно необходимое. Такая схема позволяет легко и просто менять контроллер системы хранения, ведь если все индивидуальные настройки системы находятся на дисковых полках, вместе с данными, а в контроллере только ядро, то подключенный на замену новый (даже другого типа) контроллер загрузится, обнаружит и подключит /etc с дисков, и загрузится в той конфигурации и с теми самыми настройками, которыми обладал старый контроллер.

Том root vol, обычно vol0, создается при начальной установке системы и очень часто уже никогда не меняется. Но что делать, если нам понадобилось изменить положение root vol, создать новый, на других дисках, например? Каким образом правильно перенести root vol на новый том?

Допустим, мы мигрируем с 7.x на 8.0.1, и хотим использовать 64-bit aggregate only. Так как в настоящий момент нет средства преобразовать 32-bit, 7.x-style aggregate в новый, 64-bit, нам придется создать на пустых дисках новый 64-bit aggregate, затем перенести в него root vol и другое содержимое старого aggregate, затем убить старый aggregate и добавить его диски в новый.

??ли, например, наша старая система когда-то создала свой root vol на старых дисках FC 144GB, а теперь мы используем SAS 600GB, и хотим вывести старые полки из эксплуатации, перенеся их содержимое на новые, в том числе и root vol.

Но как вы догадываетесь, root vol это немного особенный том, недостаточно его просто скопировать, надо чтобы его опознало ядро Data ONTAP как “свое”.

Посмотрим на имеющуюся картину:

filer> vol status
Volume State Status Options
vol1 online raid_dp create_ucode=on
vol0 online raid4 root, create_ucode=on

Как вы видите, том vol0 имеет специальный атрибут – root.

Начнем с того, что на нужном aggregate создадим том, который будет в будущем нашим новым root vol.

> vol create <new_root_volname> <aggrname> <size>

Размер тома (size) следует выбрать согласно рекомендациям для используемого типа контроллера (он зависит от используемого в контроллере объема памяти, потому что на нем должно быть место для сброса core dump, “если что-то пошло не так” и дальнейшей диагностики проблем системы, кроме того определенный объем занимают файлы самой OS).

Рекомендованные значения размеров тома:
Для 7.3.х:
FAS2020 – 10GB, FAS2050 – 12GB, FAS2040, FAS3140 – 16GB, FAS3160 – 23GB, FAS3170, FAS6040 – 37GB, FAS6080 – 69GB.

Для 8.х.х:
FAS2040, 3040, 3140 – 160GB,  остальные – 250GB.

Напомню, что размер тома вы можете увеличить и после его создания, но не более, чем на 95% от объема его содержащего aggregate. Проверить доступную емкость aggregate можно командой df -A

Скопируем содержимое старого тома в новый том, например используя ndmpcopy.

Убедимся что ndmp daemon включен или включим его, если он выключен.

> ndmpd on

Скопируем содержимое тома в новый том. В отличие от копирования “через хост”, эта операция осуществляется внутренними средствами системы хранения и не нагружает канал передачи данных.

> ndmpcopy /etc /vol/new_root_vol/etc

Ndmpcopy: Starting copy [ 2 ] …
Ndmpcopy: filer: Notify: Connection established
Ndmpcopy: filer: Notify: Connection established
Ndmpcopy: filer: Connect: Authentication successful
Ndmpcopy: filer: Connect: Authentication successful
Ndmpcopy: filer: Log: DUMP: creating "/vol/vol0/../snapshot_for_backup.4" snapshot.
Ndmpcopy: filer: Log: DUMP: Using subtree dump
Ndmpcopy: filer: Log: DUMP: Date of this level 0 dump: Mon Mar 7 10:18:18 2005.
Ndmpcopy: filer: Log: DUMP: Date of last level 0 dump: the epoch.
Ndmpcopy: filer: Log: DUMP: Dumping /etc to NDMP connection
Ndmpcopy: filer: Log: DUMP: mapping (Pass I)[regular files]
Ndmpcopy: filer: Log: DUMP: mapping (Pass II)[directories]
Ndmpcopy: filer: Log: DUMP: estimated 365193 KB.
Ndmpcopy: filer: Log: DUMP: dumping (Pass III) [directories]
Ndmpcopy: filer: Log: RESTORE: Mon Mar 7 10:18:25 2005: Begin level 0 restore
Ndmpcopy: filer: Log: RESTORE: Mon Mar 7 10:18:25 2005: Reading directories from the backup
Ndmpcopy: filer: Log: DUMP: dumping (Pass IV) [regular files]
Ndmpcopy: filer: Log: RESTORE: Mon Mar 7 10:18:28 2005: Creating files and directories.
Ndmpcopy: filer: Log: RESTORE: Mon Mar 7 10:18:32 2005: Writing data to files.
Ndmpcopy: filer: Log: DUMP: dumping (Pass V) [ACLs]
Ndmpcopy: filer: Log: RESTORE: Mon Mar 7 10:19:06 2005: Restoring NT ACLs.
Ndmpcopy: filer: Log: RESTORE: RESTORE IS DONE
Ndmpcopy: filer: Notify: restore successful
Ndmpcopy: filer: Log: DUMP: 365298 KB
Ndmpcopy: filer: Log: DUMP: DUMP IS DONE
Ndmpcopy: filer: Log: DUMP: Deleting "/vol/vol0/../snapshot_for_backup.4" snapshot.
Ndmpcopy: filer: Notify: dump successful
Ndmpcopy: Transfer successful [ 49 seconds ]
Ndmpcopy: Done

Укажем для OS, что созданный том и есть наш новый root vol

> vol options new_root_vol root

Mon Mar 7 10:21:24 PST [filer: fmmbx_instanceWorke:info]: Disk 8a.37 removed from primary mailbox set
Mon Mar 7 10:21:24 PST [filer: fmmbx_instanceWorke:info]: Disk 8a.36 removed from primary mailbox set
Mon Mar 7 10:21:24 PST [filer: fmmbx_instanceWorke:info]: Disk 8a.35 is a primary mailbox disk
volume new_vol_root will become root volume at the next boot.

При необходимости переименуем новый том понятным именем

> vol rename new_root_vol rootvol

Если вы использовали NAS-шары на старом томe (например для доступа к содержимому /etc и корня root vol, автоматически при инсталляции создаются шары etc$ и c$), они будут автоматически переставлены на новые места. Проверьте это, и, при необходимости, поправьте.

> cifs shares

> exportfs

Проверьте новые настройки томов

filer> vol status
Volume State Status Options
vol1 online raid_dp create_ucode=on
vol0 online raid4 create_ucode=on
rootvol online raid4 root, raidsize=4, create_ucode=on

Как вы видите, созданный вами том rootvol теперь является root.

Перезагрузитесь (в кластерной системе вместо перезагрузки можно сделать кластерный takeover/giveback), и убедитесь, что все хорошо.

> reboot

Готово, вы перенесли root volume на новое место.

UPD: Как правильно заметили в комментариях, я забыл еще одну операцию. Дело в том, что после переноса root vol перестает работать доступ по https в FilerView и System Manager. Поэтому необходимо перегенерировать SSL-сертификаты из командной строки:


filer> options ssl.enable off
filer> secureadmin setup ssl
filer> options ssl.enable on


Как вы, возможно, слышали, загрузить систему хранения NetApp можно по сети, сравнительно традиционным для UNIX-систем способом загрузки OS (ядра и rootfs) через TFTP. Это может помочь, например, если из за неисправности имеющегося ядра, которое располагается в системах NetApp на внутренней CF-карточке.

Для того, чтобы загрузиться с TFTP необходимо при загрузке прервать обычное выполнение процедуры загрузки нажав при включении системы Ctrl-C (или в случае повреждения собственного загрузочного ядра OS система окажется там сама), оставшись в “биосе”. В качестве “биоса” в системах хранения NetApp используется специальный загрузчик, под названием LOADER (в более ранних системах, например FAS270 или FAS3020/3050 использовался немного другой метод – CFE – Common Firmware Environment).

Как для LOADER, так и для CFE для загрузки системы хранения с помошью netboot вам нужно скачать с сайта NetApp netboot-версию OS Data ONTAP нужной вам версии и типа платформы (для современных систем это всегда версия с индексом платформы Q, для FAS3020/3050 индекс платформы будет E, для старых, MIPS-based систем, например FAS270 – M).

Netboot-версия Data ONTAP 7.3.5.1 (наиболее свежей 7.х на момент написания этого поста) имеет размер 27,4MB (7351_netboot.q), версия Data ONTAP 8.0.1 – 144,6MB (801_netboot_q.tgz) и представляют собой kernel и rootfs завернутые в tar.gz, загружающиеся традиционным образом в память.

Далее вам следует установить и настроить в сети, доступной системе хранения, сервер TFTP, и положить туда скачанный образ.

В подсказке LOADER необходимо настроить сетевой интерфейс и запустить сетевую загрузку.

LOADER> ifconfig e0a -addr=192.168.1.10 -mask=255.255.255.0 -gw=192.168.1.1
e0a: Link speed: 1000BaseT FDX
Device e0a:  hwaddr 00-A0-98-03-48-AB, ipaddr 192.168.1.10, mask 255.255.255.0
        gateway 192.168.1.1, nameserver not set

Доступные опции для команды ifconfig можно посмотреть введя в подсказке LOADER команду help ifconfig

Проверяем работу сети пингуя default gateway:

LOADER> ping 192.168.1.1
192.168.1.1 (192.168.1.1) is alive
192.168.1.1 (192.168.1.1): 1 packets sent, 1 received

Запускаем команду netboot

LOADER> netboot tftp://192.168.1.11/tftproot/netapp_7.2.3_x86_64
Loading:. . . . . . . . . . .

Далее Data ONTAP загружается обычным образом. Если /etc , хранящийся на root volume, при этом доступен, то система запустится штатным образом, восстановив все рабочие настройки, если же система повреждена значительно, и, например /etc также  недоступен, то можно попробовать загрузиться без /etc (выбрав соответствующую опцию в boot menu) инициализировать диски, создать новый aggregate, и запустить установку OS “начисто”.

Обратите внимание, что для netboot доступны только встроенные ethernet-порты, не те, что возможно у вас на системе установлены на карте расширения, которая в момент начальной загрузки еще недоступна.

Глазастый блоггер Stephen Foskett (блог PackRat) углядел на фотографиях с презентации Apple о ее новом датацентре в Северной Каролине, который будет использоваться под iCloud, стораджи NetApp в стойках.

Не секрет, что круг клиентов NetApp куда шире, чем те Success Stories, о которых упомянуто на официальном сайте (в России с опубликованными Success Stories внедрений и совсем “бедно”, несмотря на то, что системы NetApp продаются в России и Казахстане очень успешно). Любопытно, порой, бывает встретить такие имена среди пользователей NetApp.

Собственно сами фотографии:

2,3 – различные сервера HP (вероятнее всего DL360G7 и DL380G7), опознанные по характерному виду и фиолетовым элементам на треях дисков :)

4,5 – ясно видная передняя панель корпуса 6U контроллера FAS6200, сверху и снизу (а также рядом, в соседней стойке, ближе к фотографирующему) окруженная несколькими дисковыми полками DS2246.

Кроме указанного, на фотографиях также замечены характерные рэки стоек Teradata Extreme Data Appliance.

Хотя в подавляющем большинстве случаев это и не является необходимым в практике администратора, однако в Data ONTAP имеется механизм принудительного “вывода из строя” и замены диска на конкретный диск из spare.

Для принудительного назначения диска “вышедшим из строя” можно использовать команду

> disk fail <disk.name>

ОСТОРОЖНО! Эта команда относительно легко доступна, а вот “обратная” ей disk unfail требует повышенного уровня привилегий, и доступна только джедаям от третьего уровня и выше. Помеченный как fail диск становится для системы на самом деле fail, и никакие “вынуть-вставить” его от этого состояния не лечат!

Эта команда не позволяет назначить на замену конкретный spare. Если же стоит задача именно корректно заменить один конкретный диск на конкретный другой из блока spare, то следует применить команду

> disk replace start [-f] disk.name sparedsik.name

Эта команда инициирует процесс Rapid RAID Recovery, при котором, напоминаю, считывается все доступное содержимое непосредственно со “сбойного” диска, а не восстанавливается из parity, как при “обычном” RAID Recovery, что гораздо быстрее и меньше нагружает систему, а все что считать таким образом не удалось уже восстанавливается традиционным способом.

После завершения RAID Recovery назначенный для замены диск заменяется на указанный из spare, а сам, в свою очередь, передается в блок spare.

Отменить начавшуюся процедуру замены можно командой

> disk replace stop disk.name