about NetApp

Ну, потихоньку-полегоньку надо начинать привыкать к “восьмерке”.

Еще 3 сентября на NOW появилась версия под названием 8.0.1RC1 и я уже сталкивался с некоторым непониманем того, что такое теперь у NetApp RC.

Если вы знакомы со старой моделью именвания релизов, то помните названия GA – General Availability и GD – General Deployment.

Начиная с июня 2010 года, то есть с версии 7.3.4 и также для всех дальнейших 8.0.х действует новая, упрошенная модель именования релизов. Теперь, если по простому, то нынешний RC это старый GA, а нынешний GA это старый GD.
Теперь версии будут называться RC – Release Candidate, наиболее свежие версии, опубликованные, протестированные, и предназначенные для  ознакомления, использования и годные для установки в продакшн; и GA – General Available, протестированные всеми способами, в том числе подтвержденные на “пять девяток”, что занимает определенное дополнительное время, и GA становятся доступны несколько позднее. Добавление функциональности между RC и GA не производится.

Что же добавилось в 8.0.1?

• Поддерживается новое “железо”, о котором нам объявят в ноябре.
• Появилась поддержка Flash Cache АКА PAM-II, который не поддерживался в версии 8.0.0, что многих сильно огорчало. Теперь поддержка есть для всех PAM, причем как для 7-Mode, так и для Cluster-Mode.
• Теперь есть поддержка SMB 2.0 для 7-Mode. Ранее она была доступна только в “семерке”, а недавно опубликованные результаты показывают значительные преимущества использования SMB 2.0, причем в сетях с задержками в десятки миллисекунд (например распределенные и соединенные через WAN и VPN сети Windows ) разница в производительности с SMB 1.0/CIFS по настоящему огромная.
• Теперь возможно использования root vol (vol0) на 64-bit aggregate, то есть нет нужды держать отдельный “старый” маленький aggregate только ради root vol, жертвуя минимум двумя-тремя дисками на каждом из двух контроллеров. Однако помните, что это не позволит вам “откатиться” на старую версию, только с полной переустановкой системы.
• Появилась поддержка в 7-Mode возможности Volume Snapmirror Compression, которая уже была в наиболее свежих версиях ONTAP “седьмой” ветки, а также (ограниченно) поддерживается Multistore (на уровне 7.3.2). Правда Data Motion для vfiler, базирующийся на функциональности 7.3.3, пока не поддерживается.
• Зато (в 7-Mode только) появилась возможность под названием Data Motion for Volumes, при котором можно мигрировать тома, содержащие LUN (то есть только блочный доступ), не прерывая к ним доступа, на ходу, на другие aggregates. Обратите внимание, типы aggregates должны быть одинаковы, то есть это НЕ способ мигрировать с 32-bit на 64-bit. Средство преобразования типов aggregates вновь обещается, и вновь задерживается.
• Увеличен верхний лимит длины RAID-группы типа RAID-DP для SATA: с 16 до 20.
• В 7-Mode поддерживается онлайн-компрессия данных на WAFL, но только на 64-it aggregates.
• Наконец то увеличен размер тома, на котором возможна дедупликация, для всей линейки, начиная с 2040 (напомню, что 2020 и 2050 в 8.0 не поддерживаются), теперь дедупликация возможна на томе размером 16TB, для всех контроллеров (только для 7-Mode).
• Поддерживается VAAI – VMware vStorage API for Array Integration, новый API для offload операций хранения с хоста VMware ESX, например создание eager zeroed thick volume, а также новый метод локирования данных на LUN при совместном к ним доступе через VMFS (только для 7-Mode).
• Много добавлений по мелочи, например появилась поддержка CDP – Cisco Discovery Protocol, полезного для разбирательств с сетевой инфраструктурой. Команда работы с VIF (Virtual Interface, нетапповским названием для EtherChannel) теперь не vif, а ifgrp. Появилась полезная команда storage show fault, а также поддержка SSL v2 и v3.

Пока нет:

• IPv6
• SnapLock
• Не изменились доступные данному типа контроллера размер 64-bit aggregate, то есть по прежнему: 2040 – 30TB; 3040,3140,3160,3070 – 50TB; 6030,6040,3170 – 70TB; 6070,6080 – 100TB.

В связи с приближающейся долгожданной Data ONTAP 8.0.1 со множеством плюшек и бонусов, хочу обратить внимание владельцев систем хранения NetApp FAS на то, что 8.0.х принципиально работает только на 64-bit процессорах (это связано со сменой внутренней архитектуры), а это значит, что она не пойдет на 32-х разрядных системах в линейке FAS. К 32-разрядным относятся такие системы, как: FAS2020, FAS2050, FAS3020 и FAS3050. Для этих систем следует либо остаться на “ветке” 7, которая пока еще продолжает развиваться и поддерживаться, либо провести аппаратный апгрейд.

Так, FAS3020 может быть проапгрейжена заменой контроллера существующей системы в 64-битную FAS3040, 3050 – в 3070. Но 3020, и уж того паче, 3050, это системы достаточно старые, а более современные 3040/3070 (а также системы линейки 3100) существуют уже около 3 лет. Сложнее ситуация в low-enterprise, с системами серии 2000, успешно и активно продающихся и по сей день.

Если для FAS2020 и есть теоретическая замена контроллера на 64-bit FAS2040, правда за вполне солидные для систем этого сегмента деньги, то FAS2050 пока остается “сбоку”. Есть некоторая надежда на появление аналогичного апгрейда для этого конструктива, назовем его условно “FAS2070”, но пока никаких известий нет, и многочисленные покупатели довольно удачной системы 2050 пока остаются без “восьмерки”. Ждем осени и предполагающегося, подобно прошлому году, объявления новых продуктов.

Недавно вышедшая в релиз Data ONTAP 8.0, среди всего прочего, принесла с собой новые, расширенные аггрегейты, так называемые 64-bit aggregates.

Напомню, что aggregate (“аггрегейт”, русского термина пока не устоялось) это своеобразный “уровень виртуализации хранилища” объединение множества физических дисков, установленных в систему хранения NetApp, позволяющи создавать на них всех “RAID-группы” и тома хранения данных, причем операции ввода-вывода в случае использования aggregate окажутся распараллеленными на все входящие в него диски, даже если, например созданный и используемый вами на нем volume и невелик по размеру.  Таким образом, чем “длиннее” aggregate, чем больше в него входит физических дисков, тем выше производительностьвсех созданных на нем уровнем выше томов данных.

Однако, в версии Data ONTAP 7 максимальный размер aggregate не мог превышать 16TB даже на самых мощных системах FAS6000, что определенным образом снижало возможную производительность на дисковых операциях. Например, в случае использования дисков SATA 2TB, уже поставляемых NetApp, это ограничивает размер aggregate всего восемью такими дисками, что, очевидно, сегодня совершенно недостаточно.

Начиная с версии Data ONTAP 8 поддерживается новая структура под названием 64-bit aggregate, его предельный размер зависит от типа контроллера системы хранения, и варьируется от 30TB на самой младшей из поддерживающих его систем – FAS2040, до 100TB на системах FAS6080. В числе прочего это позволяет создать на таком aggregate непрерывный том данных такого размера.

Для использования 64-bit aggregates необходимо помнить следующее:

• ??з систем FAS2000 они поддерживаются только на FAS2040.
• По умолчанию aggregate создается “старого” типа. Для создания именно 64-bit aggregate, необхдимо создавать его с использованием специального ключа –B
  fas1> aggr create aggr_64 –B 64 24@868  - создать aggregate под названием aggr_64, тип “64-bit aggregate”, и включить в него 24 диска размером минимум 868GB
• Преобразовать “старый” aggregate в новый, 64-bit - нельзя.
• Aggregate для root volume должен по прежнему быть “32-bit”.
• ??спользование 64-bit aggregate ведет к увеличению расхода памяти на метаданные. Это может вести, в ряде отдельных случаев, к ухудшению производительности на некоторых типах нагрузки. В этом случае очень эффективно может проявить себя PAM в режиме кэширования metadata only.
• Операции Volume Snapmirror, vol copy и aggr copy могут осуществляться только для aggregates одинакового типа. Однако QTree Snapmirror, SnapVault и ndmpcopy, не зависяшие от “геометрии” продолжают работать и на aggregates разного типа.
• Дедупликация по прежнему ограничена размером тома 16TB максимум (и далее в зависимости от типа контроллера, например 4TB для FAS3140)
• Ограничения на размер отдельного файла и LUN сохраняются теми же, что и в Data ONTAP 7.3

Подробноее про 64-bit aggregate можно почитать тут:
A Thorough Introduction to 64-Bit Aggregates
http://www.netapp.com/us/library/technical-reports/tr-3786.html

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.