about NetApp

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

SnapCreator первоначально был разработан в 2007 году как “служебный”, внутренний продукт, внутри подразделения Professional Services и Rapid Responce Engineering Group, для того, чтобы облегчить построение систем защиты данных в снэпшоты системы хранения для пользовательских прикладных систем, не входящих в список поддерживаемых “официальным” продуктом NetApp - SnapManager.
То есть, если у вас используется MS SQL Server, MS Exchange, Sharepoint, Oracle, SAP, Hyper-V или vSphere (и у вас есть деньги на лицензию SnapManager), то все относительно просто. Вы устанавливаете SnapManager для соответствующего программного продукта, и дальше он делает все сам.

Зачем нужен SnapManager, и почему нельзя обойтись просто командой snap create из консоли, или переданной через ssh или rsh? Ну, например потому, что некоторые программы требуют некоей согласованной последовательности действий на своей стороне, чтобы состояние данных, записанных на дисках системы хранения, было корректным, или еще говорят “консистентным”. Ведь, например, какие-то данные могут оказаться в буферах кэша сервера, как на стороне программы, так и файловой системы, базы SQL могут иметь незавершенные транзакции, и так далее. Все это требует, чтобы перед тем, как будет сделан “снимок”, снэпшот состояния данных, эти данные на дисках уже находились какое-то время в некоем стабильном, непротиворечивом состоянии, то есть все равно нужен некий “агент” на стороне программного продукта, умеющий с ним взаимодействовать.

Таким образом, если у вас используется какой-нибудь MySQL, Sybase, Xen, KVM или что-то подобное, вам нельзя так просто взять и сделать снэпшот. Нужно написать какую-то систему-посредник, между вашим софтом, и софтом Data ONTAP. Вот для того, чтобы облегчить такую задачу для специалистов Professional Services и был написан SnapCreator.

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

Официально в настоящее время существуют две линейки, официальная, и так называемая Community Edition. Последняя это, так сказать, unstable, developers edition, где обкатываются все мульки, которые потом деплоятся в официальную поддерживаемую компанией ветку.

Архитектурно SnapCreator является клмент-серверным приложением. Существует так называемый SnapCreator Server, выполняющий код компонента Workflow Engine, который многопоточно обрабатывает поступающие от Агентов и собственного GUI и/или CLI запросы. Так как API открыт, то использовать SnapCreator могут любые внешние системы, например это могут быть коммандлеты PowerShell, другие продукты NetApp, такие как Unified Manager (для него есть свой собственный API), и даже собственные самописанные системы клиентов.

“Другим концом” Snap Creator Server взаимодействует с внутренним API Data ONTAP, обеспечивая все нужные вызовы и отдачу команд.
Конфигурации, jobs, и метаданные плагинов хранятся в специальной структуре - Репозитории (Repository / Extended Repository). Расписания задач, сами задачи (jobs), пользователи и их права доступа (RBAC) хранятся в базе данных (Database).

Наконец, специальный API есть для “клиентов”, агентов SnapCreator.

Посмотрим теперь подробнее на систему SnapCreator со стороны Агента.

Агент - это программный продукт, написанный на Java, чтобы многопоточно выполняться на всех поддерживаемых OS. В ранних версиях в качестве транспорта использовался обычный HTTP, начиная с версии 4.1 взаимодействие Агента и Сервера полностью шифруется в HTTPS.
Основным компонентом, ядром SC Agent является Operation/Execution Manager.
Ядро выполняет запросы от плагинов, которые могут быть как нативными на Джава, так и поддерживаться ранее написанные плагины “не-Java” (значительное их количество для разных программных систем было написано для версий SC 3.6 и 4.0, существовавших ранее), в том числе и на разных скриптовых языках, Perl, PowerShell, даже на UNIX Shell.

В следующих постах разберем то, как пишутся собственно плагины для SnapCreator.

Я чуть было не прошел мимо интересной новости, на которую в конце концов указали мне мои читатели. А именно, в семействе VSC, к уже существующим проектам VSC for vSphere и VSC for Citrix XenServer, в конце февраля добавился VSC for RHEV.

Напомню, для новоподключившихся, что Virtual Storage Console - это плагин для администратора виртуальной инфраструктуры, который позволяет ему удобнее управлять использованием системы хранения NetApp из привычной ему среды управления, в VMware это, например, vSphere Client и WebClient. Основной идеей при создании VSC являлось дать администратору виртуальной инфраструктуры возможность управлять нижележащим хранилищем данных из привычного ему интерфейса, в привычных ему терминах, и с минимальным задействованием для его рутинных операций специального администратора систем и сетей хранения.

До недавних пор у NetApp был VSC для VMware vSphere, чуть позднее появился VSC for XenServer, и вот теперь, как знак того, что RHEV начал играть заметную роль на рынке, теперь есть VSC for RHEV. Этот плагин разрабатывался в NetApp около полутора лет, и, наконец, после периода бетатестирования, вышел в свет и бесплатно доступен всем желающим, использующими KVM/RHEV с системами хранения NetApp, для всех тех возможностей, которые ранее уже получили пользователи vSphere и XenServer.

Кстати поддерживаются как системы 7-Mode, так и Clustered Data ONTAP.

Официальный релиз о RedHat

Видео с демонстрацией preview тогда еще беты v0.7 на Youtube.

В этом блоге я стараюсь все чаще писать про возможности Clustered Data ONTAP, (AKA С-mode, Cluster-mode). Все же новый главный продукт компании, сегодня развивается прежде всего он.
Однако у меня все еще нет ясного представления насчет того, насколько Clustered ONTAP “пошел в массы”.
Он уже появился в России, но насколько тема “C-mode only” заметок интересна русскоязычному читателю?
Для того, чтобы ответить на этот вопрос для автора этого блога и предпринят следующий опрос:

[poll id="11"]

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

Ну, и для заинтересовавшихся темой:

“На прошедшей в начале апреля в Москве конференции NetApp ведущий системный администратор внутренних сервисов новосибирской фирмы 2GIS Константин Ериков рассказал об опыте использования систем хранения этого вендора в своей компании, специализирующейся на разработке электронных справочников для ориентации в городах России и других стран. Сейчас электронные справочники охватывают 250 городов и 2 млн. организаций, десктопной, мобильной и онлайновой версиями пользуются около 18 млн. человек.

Ядром ??Т-инфраструктуры 2GIS являются два ЦОДа, расположенные в разных районах Новосибирска. Они обеспечивают полный жизненный цикл прикладного ПО электронных справочников, в том числе разработку, тестирование и внедрение, и здесь широко применяется технология виртуализации на базе Microsoft Hyper-V и Windows Server 2012. В качестве аппаратной платформы для среды виртуализации в ЦОДах 2GIS раньше использовались блейд-серверы IBM BladeCenter и четыре системы хранения среднего класса NetApp FAS3240 (по две в каждом ЦОДе). Выбор СХД производства NetApp г-н Ериков объяснил мощной поддержкой серверной виртуализации, а также гибкой ценовой политикой этого вендора и наличием в Новосибирске его офиса, который оказал квалифицированную помощь на этапе запуска FAS3240 в эксплуатацию.
…
Читать дальше - там…

Те, кто читает новости в интернете про информационную безопасность, те уже знают о том, что на неделе отрасль столкнулась с одной из серьезнейших угроз безопасности доступа к данным, программный баг опенсорсной библиотеки OpenSSL для организации защищенного канала связи, который уже прозвали Heartbleed.
Баг этот, проникший в код библиотеки по недосмотру программиста и проверявшего за ним код, находился там около 2 лет, и его использование позволяет, как выяснилось недавно, с помощью специально сформированного запроса к системе, работающей по протоколу HTTPS, с использованием для его организации той самой библиотеки OpenSSL версии 1.0.1f, получать с этой системы блоки данных из ее памяти (памяти процесса), размером до 64 килобайт.
Проблема состоит в том, что при работе в памяти процесcа, доступной таким образом, могут при этом находиться данные, которые эта система обрабатывала, например логины и пароли, приватные ключи шифрования, прочая конфиденциальная информация, например на платежных шлюзах это будут данные введенных туда другими пользователями карточек, и так далее.

Понятное описание ситуации от XKCD: http://xkcd.com/1354/

Проблема усугубляется еще и тем, что опенсорсные решения в интернете распространены очень широко, и OpenSSL, фактически, единственная библиотека для организации на них работы по HTTPS. По оценке экспертов, до двух третей HTTPS-серверов могут быть подвержены этой уязвимости. Хуже всего то, что баг сидит в текущей версии библиотеки уже очень давно, не был обнаружен оперативно, и почти все актуальные существующие дистрибутивы (например Linux) уже используют именно уязвимую версию библиотеки.
Однако, стоит сказать, что не подверженными уязвимости остались системы, не использующие OpenSSL, их не так много, но они есть, прежде всего это IIS и вообще Microsoft, а также, думаю, всякие старые Solaris, коммерческие Юниксы, и так далее, которые реализовали работу с SSL своими средствами.

Как же обстоят дела в продуктах NetApp, которые, как вы знаете, довольно широко используют оперсорсные компоненты в своих продуктах?
Буквально сегодня NetApp выпустил по этому поводу отчет о уязвимых и безопасных продуктах компании. Полностью его можно посмотреть тут: https://library.netapp.com/ecm/ecm_get_file/ECMP1516404

А вкратце:
Подтверждено отсутствие проблем с Heartbleed у:

 Data ONTAP® (all versions)
 Data ONTAP® PowerShell Toolkit
 FAS/V-Series Storage Replication Adapter for Data ONTAP® 7-mode
 FAS/V-Series Storage Replication Adapter for clustered Data ONTAP®
 MetroCluster Plugin for vSphere (MCPV)
 NetApp StorageGRID®
 OnCommand® Performance Manager
 OnCommand® Plug-in for Microsoft
 OnCommand® System Manager
 OnCommand® Unified Manager Core Package (6.x)
 SANtricity® Storage Manager
 SnapCreator® Framework (SCF)
 SnapDrive® for UNIX (SDU)
 SnapManager® for Oracle (SMO)
 SnapManager® for SharePoint (SMSP)
 SnapManager for Hyper-V
 SnapManager for Oracle (SMO)
 Virtual Storage Console (VSC) for Apache CloudStack
 Virtual Storage Console for (VSC) Citrix XenServer
 Virtual Storage Console VSC) for Redhat
 Virtual Storage Console (VSC) for VMware vSphere
 vStorage API for Storage Awareness (VASA) 7-mode
 vStorage API for Storage Awareness (VASA) cDOT

Подтверждено наличие уязвимости в продуктах:
 Clustered Data ONTAP® Antivirus Connector
 Data ONTAP® Storage Management Initiative Specification (SMI-S) Agent
 E-Series Storage Management Initiative Specification (SMI-S)
 NetApp Manageability SDK (5.0P1 and later)
 OnCommand® Unified Manager Core Package (5.x)
 OnCommand® Workflow Automation (2.2RC1 and later)

Продолжается исследование возможной уязвимости в продуктах:
 Open Systems SnapVault®
 Recovery Manager for ShareFile
 Replication Director
 Single Mailbox Recovery
 SnapDrive® for Windows
 SnapManager® for Exchange
 SnapManager® for SQL Server
 SnapProtect®

После выхода FAS8000 и Data ONTAP 8.2.1, обновилась рекомендация NetApp по использованию и числу портов 10G Ethernet, задействованных в кластерном интерконнекте, закрытой внутренней сети обмена данными между контроллерами, входящими в один кластер (тот, что именно кластер, в терминах clustered Data ONTAP, или, по старому, C-mode).
Если раньше для подключения в Interconnect использовались два порта 10G на каждом контроллере (каждый - в свой коммутатор, конечно, для надежности и отказоустойчивости, то новая рекомендация - использовать для старших систем по два таких порта, итого - четыре на контроллер. Так как onboard портов у FAS8040/8060 как раз четыре на контроллер, то эта рекомендация не будет создавать особенных сложностей.

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

Трафик интерконнекта состоит, в первую очередь, из трафика между LIF, то есть логического интерфейса SVM, Stotage Virtual Machine (или, по старому, VServer), и ее данными, которые могут оказаться, например в результате миграции SVM, на дисках, обслуживаемых другими контролерами. В этом случае трафик, входя через физические порты, привязанные к LIF с одного контроллера, достигнет своих данных, расположенных на дисках другого контроллера, пройдя через кластерный интерконнект (в терминах NetApp это называется remote workload).
А так как увеличившаяся мощность контроллера и объем NVRAM существенно лучше обрабатывают ряд “трудных” для контроллеров NetApp нагрузок, например linear-типа, способных нагрузить интерконнект трафиком, возникла необходимость рекомендовать решение, снимающее это потенциальное узкое место.

Конечно, если вы используете 7-mode и младшие модели, то вас это все пока не очень касается, но если вы строите по настоящему мощную систему, то советую заранее присмотреться к этой рекомендации. Кстати, следует отметить, что сама процедура добавления дополнительных портов в интерконнект сравнительно проста, доступна для уже построенной системы, и никаких значительных перенастроек в ней не требуется, все внутренние компоненты Data ONTAP, использующие интерконнект, самостоятельно перебалансируются, обнаружив дополнительный интерфейс.

Что называется, новость из серии “срочно в номер”.
??так, вышел в релиз долгожданный Virtual Storage Console 5.0, или VSC, работающий с vSphere Web Client, после выхода vSphere 5.5 - основного средства администрирования vSphere.
Как вы, наверняка, знаете, вот уже пару лет, как VMware объявила, что она отказывается в новых выпусках vSphere от управления многим привычным, так называемым “толстым”, клиентом, устанавливаемым на компьютер админа и работающим локально, а переходит полностью на web-клиент, “тонкий”, работающий в браузере.

Казалось бы, с одной стороны, все хорошо, веб-интерфейс, браузер, все дела. Стильно, модно, молодежно. Проблемы, однако, начались у многочисленных разработчиков дополнений и плагинов, ранее работавших через “толстого” клиента. Всем им пришлось переписываться, причем так как, кроме внешнего изменения клиента, поменялось многое и в общем представлении данных в клиенте, то переход затянулся довольно надолго. Затянулся он и для NetApp. Основной, и очень важный инструмент для работы с хранилищем NetApp в среде VMware, плагин VSC версии 4, работал только с толстым клиентом и это, безусловно, мешало многим пользователям NetApp начать переход на веб-клиент vSphere. С одной стороны - вот он, в версии 5.5 уже объявлен основным, более того, некоторые функциональные возможности управления уже есть только в нем, так как “толстый” клиент официально год как deprecated, а использовать веб-клиент без VSC, при наличии NetApp - довольно бессмысленно.

?? вот, наконец, релиз VSC 5, совместимого с веб-клиентом. Благословясь, можно начинать полный переход на веб-клиента vSphere, сперва в тестовых системах, если они у вас есть, например на симуляторе и в лабе.

Размер VSC 5.0 для скачивания остался примерно тем же, 268 мегабайт, однако вместе с VSC как таковым (он теперь существует только под x64) выпущен также и VASA Provider в виде OVA-модуля, удобного к развертыванию, этот вариант больше. Качайте то, чем в реальности пользуетесь.

??з новинок - конечно же полная поддержка Clustered ONTAP. Также для cDOT выпущен и VASA Provider, позволяющий управлять ОЧЕНЬ большими инфраструктурами. Я немного писал про него тут.

Также хочу отметить, что если вы используете vSphere 5.5, но при этом НЕ переходите по каким-то причинам на web-клиент (например используете также какие-то старые, до-5.5 фермы в своей инфраструктуре), то тогда выш выбор - VSC 4.2.1 полностью совместимый с vSphere 5.5, с одной стороны, и работающий в “толстом” клиенте, обычным образом, с другой. Качается там же.
Но помните, что 5.5 - последняя версия vSphere, поддерживающая “толстый” клиент управления.

Я чуть раньше уже упоминал о выходе нового продукта в семействе OnCommand - OnCommand Performance Manager (OPM). Несколько слов про него подробнее.
Это - Virtual Appliance, то есть образ преконфигуренной виртуальной машины, запускаемой в среде VMware ESXi, на базе ядра Linux (2.6.32) и с веб-интерфейсом, и предназначен для анализа и слежения за производительностью кластерной (clustered Data ONTAP) системы хранения. Обратите внимание, системы 7-mode - не поддерживаются, только для Clustered ONTAP.

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

Анализируется и отслеживается несколько ключевых точек и компонентов системы.

На рисунке выше показана потенциальная проблема в data processing.
Тут же можно посмотреть отчет о соответствующем инциденте.

?? посмотреть рекомендации по устранению.

В заключение следует отметить, что OnCommand Performance Manager бесплатен для клиентов NetApp, не требует покупки лицензий, и бесплатно доступен для загрузки из support.netapp.com.
Отметьте, что для многовендорных, больших инсталляций сходные задачи решаются другим продуктом, OnCommand Insight, который, будучи значительно более мощным и объемным, а также поддерживающим оборудование разных вендоров в составе IT-инфраструктуры, уже стоит существенных денег. Однако если ваши задачи ограничиваются анализом и контролем производительности одного кластера из контроллеров NetApp FAS, то этот продукт - прекрасный вариант решения.

UPD: В блоге Видада Коснока очень детальный Quick Install Guide, который поможет разобраться с установкой.

На Хабрахабре замечен интересный обзор “корпоративных облачных провайдеров”, то есть работающих “на организации”, с SLA, VMware, и прочими серьезными штуками.
Меня там, понятно, интересовала моя область.
Я уже как-то писал про представленность систем NetApp в облачном хостинге, летом 2012 года.
Теперь же можно посмотреть на “динамику”.

??з 12 подробно рассмотренных в обзоре хостеров - половина использует NetApp.

В остальном же вендоры и модели систем хранения распределяются так:
5 - разные модели NetApp FAS, от 6240 у IT-Град, до 2240 у SoftLine.
1 - NetApp E-series у Depo
Два разных EMC VNX.
и далее всех по одному. Один HUS, один EVA и MSA, 3PAR, XIV и Storwise.
Разброд и шатание. Впрочем, если посмотреть на имена, становится понятно, что преимущественно NetApp выбирают компании-исключительно-хостеры, сосредосточенные именно на облачном хостинге как таковом, а вот все прочие вендоры систем хранения, скорее всего, представлены в качестве “своих” партнерами, хостерами-одновременно-интеграторами. Подозреваю, что просто им свои, “партнерские” железки использовать банальнко дешевле выходит.
Немного странно тут выглядит Ай-Теко, который является интегратором-партнером NetApp с наивысшим статусом в России, но при этом набрал у себя наибольший “зоопарк” :).

Тем не менее, объективно видно то, что среди облачных провайдеров NetApp FAS имеет подавляющую популярность и успех.