about NetApp

NetApp Data Motion – новая технология “непрерывающей” миграции данных между системами хранения NetApp. Эта технология несколько напоминает VMware vMotion, но для хранилищ данных, при которой виртуальные машины могут, не прерывая работы, мигрировать между хост-серверами, например в зависимости от их загрузки, или состояния. Это также чем-то похоже на VMware Storage vMotion, но выполняется целиком “аппаратно”, средствами системы хранения, и не привязано к какому-либо софтверному решению на хостах.

Она объявлена для версий новой “линейки” Generation 8, но в январе выйдет и в “Classic”, “Generation 7”, в версию Data ONTAP 7.3.3, для тех, кто вынужден оставаться на старой линейке.

Для работы NetApp Data Motion необходимы следующие компоненты и лицензии:

1. Multistore – лицензия позволяющая создавать на контроллере NetApp так называемые vFilers, “виртуальные файлеры”, изолированные, виртуализованные средствами самого NetApp ONTAP, “псевдофайлеры”. Раньше эта лицензия обычно использовалась для того, чтобы разделить физический “файлер” на несколько “виртуальных”, например для того, чтобы подключить его в многодоменную CIFS-сеть, или раздать такие “виртуальные файлеры” различным администраторам подразделений в крупной организации или компании-провайдере услуг хранения. Однако идея NetApp, стоящая за Multistore была куда шире.
2. SnapMirror в режиме Semi-sync – лицензия на средство репликации данных между системами хранения NetApp, осуществляемое, в данном случае, в “квази-синхронном” режиме, по IP-сети.
3. Средство управления Provisioning Manager версии 4, являющееся частью продукта Operations Manager v.4. Это сравнительно новый для пользователя продукт, обеспечивающий GUI-управление, в том числе и процессом Data Motion, размещающийся на администраторском компьютере.

Процесс миграции заключается в предварительной репликации данных с одной физической системы хранения, где находится мигрируемый vFiler, на другую, когда предварительная baseline replication завершена, то, с помощью Provisioning Manager-а администратор может отдать команду, и vFiler “переключится” с одного контроллера на другой, на котором уже к тому времени будут находиться его данные, при этом ресурсы, такие как, естественно, данные, адреса, имена шар, LUN и их маппинг, также смигрируют вслед за vFiler.

Пока технология не лишена недостатков и ограничений.

1. Пока не поддерживаются LUN с работой по FC. Но работает iSCSI. Поддержка FC будет реализована позднее в 2010 году. Разумеется работает NFS и CIFS, однако, в случае CIFS, текущая, на момент миграции, сессия CIFS будет прервана, и ее надо будет переустановить (что связано со stateful-природой CIFS как протокола).
2. Необходимо, чтобы оба контроллера, и источник и получатель миграции,  находились в одной IP-подсети.
3. Оба контроллера (пока) должны быть однотипными, в случае неоднотипности, миграция возможна с контроллера с меньшим размером NVRAM на бОльший (но в этом случае миграция будет однонаправленная). Также (пока) не поддерживается вариант миграции данных с FC/SAS-дисков на SATA.
4. Естественно не поддерживаются traditional volumes (кто-то их использует по доброй воле еще?).
5. Мигрируются все тома, принадлежащие данному vFiler.
6. SnapLock и FlexCache (пока) не поддерживаются.
7. Дедуплицированные данные переносятся дедуплицированными, и сохраняют доступность в своем дедуплицированном виде, но соответствующие им метаданные на “получателе” репликации надо заново перегенерировать, чтобы новые записываемые данные могли также дедуплицироваться вместе со старыми, так как метаданные (база фингерпринтов) остаются на уровне aggregate, и не мигрируют.
8. Мигрированные FlexClones - “развернутся”, “девиртуализируются”, и займут “положенное им по объему” (это, к сожалению, свойство их репликации с помощью SnapMirror).
9. Пока управление процессами Data Motion возможно только через GUI Operations Manager-а, не через командную строку.

Будем надеяться, что значительная часть ограничений, присущих любому продукту “версии 1.0” со временем будет устранена. Сама же Data Motion это логичный шаг в направлении глобальной стратегии NetApp – построении “облачного” распределенного хранилища, с глобальным “пространством хранения”, распределенным и прозрачно мигрирующим между множеством различных физических хранилищ.

В основу поста легла заметка в блоге Аарона Делпа, по новостям с NetApp Insight 2009, и презентации Ларри Туше, инженера “команды виртуализации” NetApp.

Любителям статистики может быть полезно:

По отчетам IDC, NetApp сегодня входит в Top5 производителей систем хранения, вместе с EMC, IBM, HP и Dell/Equalogic. При этом, в сегменте “сетевых дисковых систем” (то есть NAS + IP-SAN (iSCSI) + FC SAN)  занимая “в деньгах” (Revenue) 4-5 место, а “в проданных петабайтах” – второе, сразу после EMC (что связано с методикой подсчета IDC и свойствами систем NetApp).
А в сегменте Enterprise NAS – второе, также вслед за EMC (38,7% и 26,1% рынка, соответственно).

Рынок в исследуемый период (Q2Y2008-Q2Y2009) упал в сегменте “External Disks” на 15,3%, из них отдельно SAN – 23,8%. Падение рынка в сегменте NAS – 6,8%, при этом сегмент IP-SAN (iSCSI) вырос на 27,2%.

За рассматриваемый период EMC потеряла в revenue за этот период - 19,5%, а NetApp всего 8,1%.

Читая все это уже совсем не кажется нереальной задача, озвученная на NetApp Insight 2009 – стать #1, для начала, на рынке EMEA, результаты которого за прошедший квартал были чрезвычайно оптимистичными.

Продолжим составление списка полезных команд управления в консоли NetApp.

• license : отображает/добавляет/удаляет лицензии на системе хранения
• maxfiles : показывает и добавляет inodes на томе
• aggr create : создает aggregate
• vol create <volname> <aggrname> <size> : создает том на aggregate
• vol offline <volname> : переводит том в offline
• vol online <volname> : переводит том в online
• vol destroy <volname> : уничтожает и удаляет том
• vol size <volname> [+|-]<size> : изменяет размер тома
• vol options : отображает/изменяет опции тома
• qtree create <qtree-path> : создает qtree
• qtree status : отображает статус qtrees
• quota on : включает механизм квоты на системе хранения
• quota off : выключает квоты
• quota resize : изменяет значения квот
• quota report : сообщает значения квот и использованного места
• snap list : показывает список всех снэпшотов на томе
• snap create <volname> <snapname> : создает снэпшот вручную
• snap sched <volname> <schedule> : назначает расписание создания снэпшотов
• snap reserve <volname> <percentage> : показывает/устанавливает резервирование места под снэпшоты

продолжение следует

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

Однако как обстоят дела с последовательным (sequental) доступом, ведь такой тоже имеет место быть (пример – записи в лог базы данных)? Очевидно, что тут-то и должна проявиться в полный рост проблема фрагментации, и ее влияния на производительность.

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

Автор создавал сильно фрагментированный, кусками по 2MB и 128KB (5000 и 60000 кусков соответственно), файл, общим размером 10GB, и тестировал на нем последовательные чтения и записи. В качестве дискового хранилища использовались как диски самого сервера (на графиках - DAS), так и раздел на SAN-хранилище EMC Symmetrix DMX-2.

Вот как описывает тестовое оборудование сам автор: The server was a standard DL580 with 4 single-core sockets (2.0GHz Xeon) with 4GB of RAM. The disk array was a DMX2 with 10K rpm 146GB FC drives in a RAID10 config. The test LUN was 96GB in size (with 8GB disk slices from 24 spindles). Two Emulex LP8000 HBAs were load balanced with PowerPath.

Первый результат был обескураживающим. В случае использования высокопроизводительного SAN-стораджа, результаты для фрагментированного и дефрагментированного файла, и тестирования последовательной записи блоками по 1К,  были практически идентичными. Очевидно, что эффективное кэширование и хороший запас быстродействия DMX “съели” возможное снижение быстродействия из за присутствия фрагментов.

Далее автор создал аналогичный раздел на дисках серверов (DAS), и протестировал его.

?? тут мы уже видим значительный эффект от фрагментированности файла при последовательном доступе (почти 30% снижение быстродействия).

Далее автор уменьшил размеры “блоков фрагментации” до 128KB (то есть увеличил количество фрагментов своего 10GB тестового файла), и проверил эффект на последовательном чтении.

?? снова мы видим, что эффект хорошо заметный на DAS, практически отсутствует на высокопроизводительном SAN-массиве.

Проявляется ли хоть как-то эффект от фрагментации вообще? Автор обнаружил лишь один параметр:

На файле размером в 10GB, состоящим из 60 тысяч хаотически разбросанных по диску фрагментов заметно выросло время Latency, задержек чтения. Обратите внимание, что для такого же 10GB-файла с 2MB блоками, разбитого на 5000 таких же разбросанных фрагментов, не было даже и такого эффекта.

??, наконец, автор измерил время ряда операций:

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

Любопытная новость обнаружилась в блоге Дейва Хитца, вице-президента, сооснователя компании, и первого блоггера NetApp (теперь в корпоративном каталоге блоггеров уже десятки имен, но он был первым,и одним из первых блоггеров в индустрии систем хранения вообще).

За прошедшие 52 недели, то есть, по простому, за календарный год (364 дня), NetApp, впервые в своей истории, отгрузила клиентам 1000 петабайт объема хранения, то есть, иначе, ровно экзабайт дискового пространства. Единица с восемнадцатью нулями байт.
Такая вот веха.

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

• sysconfig -a : показывает развернутую информацию по аппаратной конфигурации
• sysconfig -d : показывает информацию о дисках, подключенных к контроллеру
• version : показывает версию Data ONTAP OS version.
• uptime : показывает время uptime
• dns info : выводит данные по dns, такие как число попаданий в кэш dns и промахов
• nis info : выводит название домена nis, серверов yp, и т.д.
• rdfile : похоже на "cat" в Linux, используется для отображения содержимого текстового файла
• wrfile : создает/перезаписывает файл. Похоже на "cat > filename" в Linux
• aggr status : показывает статус aggregate
• aggr status -r : показывает конфигурацию RAID, информацию о ходе ребилда
• aggr show_space : показывает использование пространства на aggreate, WAFL reserve, overheads и т.д.
• vol status : выводит информацию о томе
• vol status -s : показывает spare disks системы
• vol status -f : показывает сбойные (failed) диски системы
• vol status -r : показывает конфигурацию RAID, информацию о ходе ребилда
• df -h : отображает использование пространства на томе
• df -i : отображает количество inode на всех томах
• df -Ah : отображает данные "df" применительно к aggregate

продолжение следует

Одной из вечных тем FUD-а конкурентов NetApp является “проблема” с фрагментаций данных в WAFL.
Оставим сейчас в стороне вопрос, насколько фрагментация действительно проявляется в практической жизни (я на эту тему уже писал ранее). Рассмотрим только вопрос того, насколько такой эффект вообще имеет место быть в теории.

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

Он заполнил таблицу из ста строк сотней случайных чисел, взятых с random.org, в первом столбце, которые изображают фрагментированные данные, затем второй столбец также случайными числами, изображающими то, какой блок программа запросила, в случае рандомного доступа к данным. ?? наконец он сравнил суммарное расстояние “seek” в случае считывания запрошенных данных (второй столбец) из максимально фрагментированного массива (первый столбец) и упорядоченного (то есть просто от 1 до 100).

С точки зрения “здравого смысла” мы бы ожидали, что фрагментированный столбец даст значительно (или хотя бы заметно) большую величину “seek”, по сравнению с упорядоченным, однако этого не произошло! Более того, столбец со случайно заполненными данными, из которого столь же случайно “запрашиваются” числа имел даже чуть меньший “seek” чем полностью упорядоченный! (Впрочем, ясно видно, что на достаточно большом интервале эти числа будут стремиться сравняться, так что можно просто принять их равными).

Несколько неожиданный для “здравого смысла” результат, однако, поразмыслив, нельзя не признать его правильным. “Случайное” помноженное на “случайное”  не дает “случайное в квадрате”. :)

Отсюда немного парадоксальный вывод: В случае случайного (random) по характеру доступа к данным, а именно такой тип нагрузки обычно и принято тестировать в первую очередь, так как он наилучшим образом соответствует работе современных многозадачных серверных систем и баз данных OLTP, фрагментация (случайность их размещения) данных на диске практически не увеличивает количество “вредоносного” seek distance по сравнению со случайным чтением упорядоченных данных, и не ухудшает характеристики производительности!

Хочу обратить внимание моих читателей на существование специальной группы на YouTube, под названием NetApp TV. В этой группе выкладываются видеоподкасты, скринкасты и демонстрации различных технологий NetApp. Может быть интересно.
Вот, например, рассказ про новинку - NetApp Data Motion.
Data Motion это средство прозрачной и непрерывающей миграции данных (и работающей с этими данными нагрузки в виде клиентов) между системами хранения NetApp, что-то вроде того, что делает VMware vMotion для виртуальных машин, но для данных.
Требует лицензии SnapMirror и Multistore, в продакшн выходит на ONTAP 8 в начале следующего года.

Вы уже знаете, что системы хранения NetApp - мультипротокольны. В зависимости от введенных лицензий они позволяют работать с данными по протоколам CIFS и NFS (как NAS), а также по "блочным" протоколам, таким как FC, FCoE и iSCSI (IP-SAN). Но немногие знают, что кроме перечисленных протоколов, данные с NetApp также могут быть также доступны по протоколам HTTP (WebDAV) и FTP.

По умолчанию работа демона ftpd выключена. Для его включения введите в командной строке консоли контроллера команду:

> options ftpd

Вы увидите список опций, относящихся к ftpd:

Как вы видите, изначально ftpd остановлен (ftpd.enable off),вы можете включить его командой options ftpd.enable on.

Далее вы можете установить параметр ftpd.dir.override на директорию, которую вы хотите отдавать по FTP (options ftpd.dir.override /vol/vol1/my-home/my-shared-directory/). Теперь можно попробовать войти с помощью ftp-клиента и скорее всего вы увидите что-то типа 530 Login incorrect - User has no home directory., если директория, указанная в ftpd.dir.override это не корень тома. Это может означать, что пользователь, которым вы входите, не имеет так называемых traversal rights для директории, отдаваемой по FTP, поэтому вам нужно исправить это, либо если вы используете Data ONTAP 7.3.0 или старше, то в можете включить опцию ftpd.bypass_traverse_checking (options ftpd.bypass_traverse_checking on).

В заключение хочу напомнить, что протокол ftp это довольно простой и даже примитивный, в особенности с точки зрения безопасности данных, протокол. Все логины и пароли, а также содержимое файлов данных пересылается "открытым текстом", а реализованные в более современных и совершенных серверах ftp методы безопасного подключения и передачи данных в имеющемся в Data ONTAP ftpd не используются. Кроме того, надо понимать, что протокол ftp, как и сервер ftpd в системах NetApp никогда не планировался для напряженной и интенсивной работы, и, наверняка, не тестировался как следует ни на безопасность, ни на стабильность работы, играя сугубо вспомогательную роль, поэтому организовывать на нем "рапидшару", открытую во внешний интернет, наверное все же не стоит.

??сточник: http://www.m4r3k.org/english/netapp/ftp-services-on-netapp/

В одном из постов, опубликованных ранее, посвященному “мнимой дешвизне” дисков SATA, и проблемами при построении системы хранения заданной производительности в IOPS, меня спрашивали об источниках приведенных показателей IOPS отдельных дисков в зависимости от их типа.

Нашлась вот такая картинка, с графиками тестирования различных типов дисков.