about NetApp

В этом блоге я уже несколько раз упоминал любопытный инструмент, разрабатываемый в NetApp - инструментарий управления для MS Powershell, продвинутой объектной “командной строки”, имеющейся теперь во всех OS Microsoft. Для работы со сторонними продуктами Powershell расширяется дополнительными модулями объектов-командлетов (commandlets). Вот такой вот модуль и пишут в NetApp.
Ранее уже был выпущен модуль Data ONTAP Toolkit, позволяюший полноценно администрировать систему хранения из командной строки, писать скрипты, создавать и конфигурировать ресурсы, и так далее.

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

Скачать его можно здесь: https://communities.netapp.com/thread/25368

Пока еще не вся функциональность VSC доступна из командной строки, но работы идут. В настоящий момент в основном реализованы задачи модуля Provisioning & Cloning, то есть создание или удаление датасторов, а также средства Rapid Clone. Также есть средства взаимодействия с vCloud Director API.

На проходящей сейчас в Лас-Вегасе конференции Amazon Web Services re:Invent было объявлено, что Amazon Web Services (AWS, крупный облачный провайдер) начнет предлагать услуги “гибридного облака”, то есть решения, сочетающего private cloud, располагающегося закрыто у клиента, и public cloud, то есть традиционное “провайдерское облако”, аналогичное уже хорошо знакомым продуктам AWS, RackSpace, или, допустим, Selectel и ??Т-Град. Строить такую услугу он будет с использованием систем NetApp FAS.

Обычно услуги public cloud больших объемов строятся с использованием commodity hardware, то есть “обычного” компьютерного железа и самостоятельно разрабатываемого (или модифицируемого) софта, наподобие OpenStack. ??менно так поступил и Amazon со своими S3 и EDB (официально о выборе поставщика большие компании предпочитают не растпространяться, но по ряду косвенных признаком можно сделать вывод именно о commodity-based решении). Однако, во многих случаях выбор commodity, при внешней простоте и дешевизне, сопряжен со значительными затратами на разработку и тестирование, причем со своими проблемами вы рискуете оказаться наедине, а vendor lock вы заменяете на developer lock.
Кроме того, часто, могут возникнуть проблемы с взаимодействием с имеющимся клиентским оборудованием, и, часто, это клиенты, которым нельзя сказать “у вас пулеметы не той системы, поменяйте на Linux, иначе нормально не заработает.”

С этой точки зрения подход AWS по интеграции пользовательских сервисов, в рамках такого “гибридного облака”, с использованием технологий NetApp, выглядит вполне здраво.
Для взаимодействия с уже имеющимися сервисами AWS public cloud для установленных в AWS datacenter (AWS availability zones) систем NetApp FAS разработаны средства Amazon Direct Connect к EC2 и S3, а имеющееся оборудование NetApp клиента взаимодействует с таким “колокейшном” обычным образом, с помощью того же SnapMirror, и так далее.

В настоящий момент решение AWS-NetApp разворачивается в регионе US, и в планах в дальнейшем предлагать его в EMEA и APAC.

Отдельной строкой хочу уточнить для читающих по диагонали: в новости не идет речь про переход AWS на NetApp, или замену имеющихся у AWS услуг, типа S3, и прочих, на решения NetApp. Речь идет про дополнительное предложение для компаний, уже использующих NetApp для построения своих датацентров и частных облаков, и желающих интегрировать эти сервисы с сервисами public cloud, предоставляемых AWS для создания “гибридного облака”, например для резервного хранения данных в S3 или Glacier, или для удаленной обработки их в динамически создаваемых инстансах EC2.

Если вы заинтересовались упомянутым ранее продуктом ExpressPod, это недавно появившаяся у NetApp “коробка”, готовый “продукт”, состоящий из стораджа FAS2240/2220 серверов Cisco UCS C-series (1-юнитовых 19”) и коммутаторов Cisco Nexus 3000 (48x 100/1000 Ethernet + 4x 10G, под NX-OS), ориентированный, прежде всего, на задачи построения “платформы виртуализации”, то в библиотеке NetApp появился новый документ:

ExpressPod Infrastructure Solution Implementation Guide
VMware vSphere on ExpressPod
Michael Zimmerman, David Klem, Chris Reno, and Michael Ansel, NetApp
October 2012 | TR-4107

http://media.netapp.com/documents/tr-4107-VMware-vSphere-ExpressPod.pdf

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

На прошедшем на прошлой неделе VMworld NetApp показал крайне интересную штуку – Data ONTAP Edge. Это виртуальный appliance, виртуальная машина, с установленной в ней OS Data ONTAP, работающей как “виртуальная система хранения” в среде VMware ESXi.

Наверняка вы уже знаете и пользуетесь симулятором Data ONTAP (а если не пользуетесь, то самое время пойти почитать про него подробнее). В двух словах: Data ONTAP Simulator это код Data ONTAP, выполняемый не на реальном железе стораджа, а в среде Linux (для Simulator 7.x) или виртуальной машины FreeBSD (Simulator 8.х). Симулятор позволяет создать “эмуляцию стораджа”, протестировать те или иные решения, отработать какие-то процедуры, настроить инфраструктуру, не трогая реальный физический сторадж, проводить обучение и всякие эксперименты. Не позволяет он только сделать на симуляторе реальную систему хранения, так как в код симулятора вшиты строгие ограничения на объем. Сделано это с понятной целью, не провоцировать пользователя на попытку сделать из такой виртуальной машины реальный “сторадж”, так как производительность такого решения не идет в сравнение с нормальным физическим стораджем на физическом железе. ??ли по крайней мере “не шла”.

Однако времена меняются, и некоторое время назад NetApp объявила о появлении у нее продукта Data ONTAP-v, который предоставляется не напрямую, а через партнеров (например Fujitsu в их blade-серверах для SMB), для создания virtual appliance, как раз того самого virtual storage. Data ONTAP-v это, если по-простому, симулятор со снятыми ограничениями. А  на VMworld был сделан новый шаг – объявлено о доступности для конечных пользователей нового решения – Data ONTAP Edge – virtual storage appliance для малых офисов и филиалов.

Data ONTAP Edge это, по сути, код Data ONTAP, практически такой, как он работает в реальном сторадже. Соответственно в таком апплайенсе вы получаете практически все то, что получаете в реальном железном сторадже, то есть универсальный (NAS+SAN) доступ, снэпшоты, thin provisioning, дедупликацию, FlexClone, SnapMirror и SnapVault. Однако, как и в эмуляторе, в Edge и ONTAP-v нет FC. Управлять Edge можно как и обычным нетапповским стораджем, с помощью System Manager, консоли, а также поддерживается Virtual Storage Console в  vCenter.

Цель Data ONTAP Edge – это филиалы и малые офисы. ?? прежде всего я вижу для таких организаций интерес в отношении Edge – это использовать его как SnapVault Primary. К сожалению, прекрасная и очень полезная для как раз малых компаний с филиалами и удаленными офисами идея с централизованным бэкапом через SnapVault разбивается о необходимость для использования всех плюсов SnapVault заводить второй (и более) железный нетапповский сторадж, так как SnapVault Primary, то есть “получатель” снэпшотов на хранение, может быть только нетаппом (SnapVault Secondary, “источник”, может быть даже обычный сервер, например при использовании OSSV, Open Systems SnapVault). Также интересным может быть организация репликации через SnapMirror.

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

Data ONTAP Edge можно скачать в виде 90-дневного триала, в формате OVA, с необходимым набором лицензий. Для установки его необходим, в отличие от симулятора, ряд строгих условий. Edge устанавливается только на ESXi (симулятор можно было установить на почти любой гипервизор), он требует много памяти и процессора (строго 2 выделенных vCPU и 4GB выделенной RAM, 57,5 GB места для самой системы), а также обязательно не ниже 4-ядерного или 2 двухядерных 64bit Intel x86 процессор, более 2,27GHz, четыре и более физических диска на Hardware battery-backed RAID, минимум одна Gigabit Ethernet карта, но в реальности, для современных серьезных продакшновых инфраструктур, эти требования вполне подъемны. Существует список поддерживаемых систем в качестве хоста. Рекомендую также посмотреть и на Data ONTAP Edge datasheet.

Для получения ссылки на скачивание триала вам будет нужен логин на support.netapp.com (бывший NOW), в том числе вы можете получить его и не будучи уже зарегистрированным клиентом NetApp, по “гостевому входу”. Лицензии на триал придут на адрес почты, зарегистрированной на логин.

Обсуждение и ответы на вопросы по Data ONTAP Edge можно получить в специальном разделе communities: https://communities.netapp.com/community/products_and_solutions/data-ontap-edge

Любопытно, что, по слухам, в начале своей истории NetApp серьезно рассмативала вариант выпустить Data ONTAP как софт, устанавливаемый на пользовательское “железо”, то есть не становиться еще одним “вендором железа”, а оставаться софтовой компанией. К сожалению, тогда, в первой половине 90-х состояние дел с надежностью доступного пользователям железа не позволило достичь приемлемого качества и производительности, и пришлось под Data ONTAP строить свою железную платфолрму. Сегодня, как видите, старинная идея переживает второе рождение.

В одном из предыдущих постов я начал описывать то, как, с помошью политик кэширования Flash Pool можно настроить индивидуально параметры кэширования для томов. Однако кроме кэширования чтения у Flash Pool появидлись средства и кэшировать запись. ??х немного, но они есть.

В настоящий момент имеется два варианта настройки кэширования записи (и один – и чтения и записи разом, который зачислен в “чтения”, и о котором я упомянул в предшествующем посте на эту тему):

• write-cache = none – тут нечего особенно рассказывать, это отключение кэширования записи, когда она включена в режиме кэширования во Flash Pool по умолчанию. Параметр этот может быть задан на каждый конкретный том, и использовать его стоит в тех случаях, когда кэширование записи не приносит пользы, например когда рабочая нагрузка не делает многочисленных и частых random-перезаписей данных тома (а напротив, записи идут секвентальные, большими блоками). С использованием такой опции данные пойдут непосредственно на HDD, собственно как они и записывались ранее, в обычных aggregates, без использования Flash Pool. В случае такого характера нагрузки данных тома, вы освободите место на кэше для тех, кому оно действительно необходимо.
• write-cache = random-write – эта опция, напротив, включает кэширование записей на aggregate для данного тома через flash. При этом данные сперва попадают в пространство SSD и кэшируются на нем. Такая политика должна хорошо работать для задач, когда данные, рандомно записываемые на том, часто перезаписываются, или перечитываются сразу после записи. Это значение политики записи по умолчанию.

Как я уже упоминал в предшествующей заметке, для управления настройкой кэширования томов на Flash Pool теперь используется новая команда priority, имеющая следующий синтаксис:

priority hybrid-cache set <volume name> read-cache=<value> write-сache=<value>

Следящие за новостями IT в мире не могли пройти мимо нового баззворда, стремительно катящегося сейчас по англоязычным источникам - Big Data.

Согласно определению Википедии: “Big Data - это серия подходов, инструментов и методов обработки структурированных и неструктурированных данных огромных объёмов и значительного многообразия, для получения человеко-читаемых результатов, эффективных в условиях непрерывного прироста, распределения по многочисленным узлам вычислительной сети, альтернативных традиционным системам управления базами данных и решениями класса Business Intelligence. В данную серию включают средства массово-параллельной обработки неопределённо структурированных данных, прежде всего, решениями категории NoSQL, алгоритмами MapReduce, программными каркасами и библиотеками проекта Hadoop.” Сам же по себе термин “Big Data” (”Большие Данные”) родился в статье 2008 года в журнале Nature, и образован по аналогии с понятиями “Большая Нефть”, или “Большие Деньги”, символизирующие переход количества (объемов, скоростей обработки) данных в их некое новое качество.

Таким образом, в первую очередь, Big Data это то, что не помещается в базу данных, и методы работы с такими данными, когда нельзя “написать SQL-запрос” к ним.

В значительной степени, сложность работы с Big Data как раз и определяется сложностью нового подхода, для которого не получается применять эффективно привычные методы. Представьте, каково это, например, работать с несколькими миллионами или даже миллиардами файлов, искать в них, извлекать из них данные, записывать.
Сравнительно недавняя покупка компанией продуктовой линейки Engenio, и ряда программных продуктов стороних разработчиков, будучи слитой воедино, дала значительный толчок для работ в этом направлении. Так, NetApp активно занялся работами в области Hadoop, одного из открытых продуктов Apache Foundation (один из крупнейших клиентов NetApp - компания Yahoo! - как раз давний и активный пользователь и разработчик решений с Hadoop). ??звестны их работы в области высокопроизводительных решений с использованием Lustre (о использующей Lustre системе хранения для суперкомпьютера в Lowrence Livermore National Laboratory я уже писал ранее).

Другим продуктом, активно развиваемым в NetApp в области Big Data, является решение StorageGRID, объектное хранилище данных, позволяющее, используя высокий параллелизм, строить хранилища данных для миллионов и миллиардов файлов, с мультиплатформенным доступом, в сотни петабайтов объемом.
Недавно вышедшая версия StorageGRID 9.0 добавила к уже существующим возможностям доступа по NFS и CIFS и доступ по недавно описанному и стандартизированному в SNIA протоколу Cloud Data Management Interface (CDMI), который позволяет обращаться к объектному хранилищу с помощью HTTP-подобных запросов, создавать, администрировать и доступаться к данным облачного хранилища, с размерами, превышающими общепринятые сегодня.
Хотя на сегодня, уверен, большинству пользователей такие задачи, что решаются объектными стораджами и Big Data, все еще кажутся далеким будущим, многие вещи, казавшиеся далеким будущим еще три-пять лет назад, стали практически повседневностью сегодня, и готовиться вендорам к таким делам приходится заранее, чтобы не оказаться “на обочине” рынка.

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

В связи же с тем, что, по некоторым смутным слухам, NetApp раздумывает о том, чтобы поставлять решения на базе стораджей E-series, в первую очередь под Big Data, и на российский рынок, вполне возможно, что StorageGRID, CDMI, Hadoop и прочие решения найдут свое место и среди российских компаний.

http://dilbert.com/strips/comic/2012-07-29/

Долгожданный Flash Pool (AKA Hybrid Aggregate) наконец-то вышел в релиз с появлением версии Data ONTAP 8.1.1. О том, что это такое я уже писал, но для тех, кто все пропустил, и не желает посмотреть в поиске по этому блогу, вкратце: это технология, которая позволяет создать комбинированный aggregate на системе хранения NetApp, в которй добавленные в aggregate диски SSD (на flash memory) используются для кэширования данных, читающихся, а также пишущихся на тома этого aggregate. Эта технология расширяет и дополняет уже имеющуюся несколько лет у NetApp для систем его midrange  и highend линейки, технологию Flash Cache, выполненную в виде карты flashmemory, и устанавливаемую внутри контроллера системы хранения.

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

Continue reading ‘Flash Pool: некоторые тонкости применения’ »

В предыдущем посте я показал, как создать и начать использовать гибридный aggregate (flash pool) с использованием дисков SATA для хранения, и SSD для кэширования обращения.
Но aggregate может содержать на себе множество томов, и, часто, разные тома потребуют разных режимов использования. Flash Pool конечно имеет возможности индивидуальной настройки параметров кэширования для тома. Делается это так:
С помощью команды priority можно указать следующие варианты политик кэширования чтения:

• read-cache = none - эта политика отключает кэширование чтения для данного тома вовсе. Например мы хотим сэкономить место в кэше для более ценных данных, или чтение с этого тома редкое и длинными последовательными кусками, затем не перечитываемых повторно, и их кэширование просто непроизводительно замусорит кэш.
• read-cache = meta - эта политика кэширует операции чтения метаданных. Такая политика полезна для томов, на которых значительную часть операций составляют операции чтения метаданных. Например это операции с большим количеством сканирований директорий со значительным количеством (сотни и тысячи) файлов, поиска и выбора среди них.
  Операции чтения метаданных довольно затратны, так как представляют из себя рандомное чтение мелкими блоками, и кэширование таких операций очень эффективно (и при этом может не занимать больших объемов в кэше).
• read-cache = random-read - эта политика, что очевидно из названия, кэширует операции чтения, идущие в произвольном порядке. Причем кэшируются ?? метаданные, ?? собственно данные одновременно. Эта политика как бы включает в себя предыдущую, но расширяет кэш и на собственно считываемые данные. Это политика по умолчанию. Если вы не переопределите ее, то действовать будет именно она. Обратите внимание, что ‘random’ означает, что sequental-операции будут исключены из операций кэширования (оно и правильно).
• read-cache = random-read-write - несколько парадоксальным образом эта политика считается политикой кэширования чтения. С ее использованием к кэшированию операций чтения добавляется новый для NetApp процесс кэширования операций записи. Впрочем, о политиках по кэшированию операций записи мы поговорим в одном из следующих постов.

Командная строка настройки политик кэширования для тома выглядит так:
priority hybrid-cache set <volume name> read-cache=<value> write-сache=<value>

С выходом Data ONTAP 8.1.1 (сейчас он, для самых нетерпеливых, находится в состоянии Release Candidate) появляется долгожданная фича под названием Flash Pool (он же, ранее, Hybrid Aggregate)

??так, давайте посмотрим, как можно создать Flash Pool, то есть aggregate с дополнительными дисками SSD для кэширования данных.
Создадим для начала простой aggregate:

fas01> aggr create flashpool -B 64 -t raid_dp -T SATA -r 16 16

??мя aggregate: flashpool, формат: 64-bit, тип RAID: RAID-DP, тип дисков: SATA, размер RAID: 16

После успешного создания aggregate по имени ‘flashpool’ разрешим на нем собственно flashpool:

fas01> aggr options flashpool hybrid_enabled on

Несмотря на то, что коммерческое название фичи было изменено в релизе с ‘hybrid aggregate’ на ‘flash pool’, опция по прежнему называется ‘hybrid’. Аналогично с дедупликацией, которая когда-то называлась A-SIS (Advanced Single Instance Storage), и до сих пор так называется соответствующая опция в параметрах.

Теперь можно добавить к aggregate диски SSD в количестве 6 штук:

fas01> aggr add flashpool -T SSD 6

??з 6 штук два будет забрано под RAID parity (RAID-DP), а оставшиеся 4 - будут использованы как кэш. Обратите внимание, что сам aggregate не увеличится в емкости хранения! Добавленные SSD недоступны для непосредственного использования и записи на них данных, они будут использованы как кэш.

А теперь просто создадим на получившемся aggregate том (myvol) для хранения данных, емкостью 500GB:

fas01> vol create myvol flashpool 500g

Теперь получившийся том myvol, размером 500GB, можно использовать под данные, причем записываемые и считываемые данные будут автоматически использовать кэш на SSD.
В следующем посте мы посмотрим, какие средства есть для тонкой настройки режимов кэширования томов на Flash Pool.

Я уже рассказывал ранее о появлении у NetApp узкоспециальной “полки высокой плотности” DS4486, на 48 дисков SATA 3TB в 4U конструктиве. Однако не было фотографий ее внешнего вида.
Я обещал опубликовать их, как только найду.
Внешний вид DS4486 не отличается от DS4243:

Однако 48 дисков помещаются в ней хитрым образом - попарно, в трее увеличенной глубины:

Пока не вполне ясно, как происходит замена в случае выхода из строя одного из дисков пары.
??звлекаются они парой, это понятно, а как дальше? Они представляются системе парой независимых дисков, или же одним диском на 6TB, возможно? Если первое, то как система отрабатывает ситуацию, что из aggregate достаются вышедший из строя и один исправный диск?