about NetApp

Весьма любопытная попалась на глаза презентация о использовании систем хранения NetApp в CERN, для накопления, хранения и предоставления для работы с ними данных, поступающих с детекторов Большого Адронного Коллайдера (БАК, LHC).

Где-то до 15 страницы там идет все больше про адронный коллайдер, с данными котрого и работает система, и кратко о экспериментах, и генерируемых ими объемах данных, идущих на LRC (подробнее о том, что за эксперименты идут на LHC можно почитать на русском в заметке на Хабре) а дальше начинается уже и “наша” часть.

Вкратце: на 2010 год один только Large Hadron Collider (LHC, БАК) генерировал в ходе идущих на нем четырех параллельных экспериментов около 15 петабайт “сырых” данных в год, при сумммарной емкости хранилища свыше 50 петабайт, которые обрабатываются примерно 150 тысячами процессорных ядер в научных учреждениях по всему миру (проект GRID).

Это 2010 год, еще до всех cluster-mode, все довольно просто (если к такой работе можно вообще применять такое слово), и упомянутый в заголовке scalability и performance достигается простым 7-mode и Oracle RAC (10.2.0.5, позднее 11 в Oracle VM), Flash Cache и 10G Ethernet на midrange-class системах.

С 2006 года в CERN эксплуатируют системы хранения NetApp, Oracle на Linux_x64, в конфигурации RAC по NFS, и на момент создания презентации СУБД обслуживала 96 баз.

Так, например, база ACCLOG получала, на момент публикации презентации, примерно 3,5TB записей в месяц (или около 100GB в день), причем после запуска LHC объем входящих записываемых в базу данных вырос примерно вчетверо.

Любопытно, что все это обслуживают сравнительно маломощные стораджи FAS3040 и FAS3140 с дисками SATA 2TB и FC 10Krpm

Наиболее важными для CERN особенностями систем хранения NetApp в презентации называются:

• Хорошая поддержка и удобное администрирование систем.
• Высокий уровень масштабируемости и производительности, стабильности и беспроблемности кластерного файловера, а также непрерывающего работу обновления ПО контроллеров.
• Высокая надежность хранения и поддержания целостности данных (RAID-DP, scrubbing, checksum)
• Удобные и практичные фичи, такие, как snapshots.

Посмотреть PDF презентации можно тут:
http://openlab.web.cern.ch/sites/openlab.web.cern.ch/files/presentations/2010OOW-08.pdf

Долгожданный 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: некоторые тонкости применения’ »

На днях NetApp довел до коммерческого использования и выкатил в паблик фишку, которой давно занимался на уровне исследований и перспективных разработок: Flash Accel.
Это софтовая реализация идеи создания и использования кэш-памяти во flash на стороне хост-сервера. В прошлом году я уже немного упоминал о этой штуке, в связи опубликованным Advanced Technology Group, подразделением NetApp, разрабатывающем перспективные направления и идеи, на конференции USENIX FAST’11 докладом о Project Mercury.

Вкратце о том, что это и зачем.
Если о кэшировании во flash на стороне стораджа слышали уже наверное все, и многие уже даже это успешно применяют, то вариант кэшировать обращения к данным поближе к собственно работающим с этими данными процессорам, а не на другой стороне длинного “провода”, сперва кажется еще более интересным, производительным и многообещающим. Но тут же возникает масса вопросов.
Как управлять этим кэшированием? Как обеспечить “когерентность” кэшей между хост-системой и системой хранения, и между данными в таком кэше и данными, хранимыми на дисках системы хранения? Что делать в случае миграции данных между хост-серверами, например при использовании средств High Availability и кластеризации? Наконец, как быть в случае перезагрузки или “падения” сервера с данными в его локальном кэше?

Многие вендоры систем хранения сейчас занимаются этим направлением, это и EMC, и Dell, и, конечно NetApp, в концепцию Virtual Storage Tiering (VST) которого такая схема ложится как нельзя лучше. Так что появление релиза было в даном случае вопросом времени, я уверен, что остальные вендоры быстро подтянутся.

Пока же кратко о Flash Accel, самое важное:

1. Это полностью программная реализация, поддерживающая VMware ESX и MS Windows 2003/2008, которая работает с любым сторонним продуктом, с любой flash-картой PCIe (Например от FusionIO или LSI), а также и с SSD-диском в сервере, вариантом, становящимся сейчас очень распространенным.
2. Это открытая реализация, она не ограничивает пользователя какими-то определенными вендорами flash-устройств, и не требует для своего использования какого-то железного продукта от самого NetApp. ??нтеграция с Flash Accel каких-то дополнительных сторонних продуктов это открытая “экосистема”, сейчас, например, NetApp объявил о партнерстве с FusionIO, и рядом других вендоров (LSI, Virident).
3. В настоящий момент эта фишка явственно нацелена, в первую очередь, на область систем серверной виртуализации, на интеграцию с хост-серверами виртуальных машин (например VMware vSphere: поддерживаются HA, vMotion, DRS).
4. Поддерживается до 2TB кэша flash на хост, с примерно 0,5% оверхедом по памяти для сервера.
5. В публичную доступность Flash Accel выйдет в декабре этого года.
6. Flash Accel объявлен бесплатным продуктом.

Несомненно, Flash Accel не является продуктом “сам по себе”, а будет интегрирован в общую концепцию NetApp Virtual Storage Tier (VST), вместе с Flash Cache и Flash Pool, решениями кэширования на стороне стораджа, и позволит, своим применением, еще улучшить ситуацию с latency и производительностью по IOPS для виртуальных машин.

В предыдущем посте я показал, как создать и начать использовать гибридный 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.

Любопытная статья обнаружилась в блоге Wahl Network, который я тут уже упоминал в связи с переводами из него про LACP и агрегирование каналов Ethernet/NFS в VMware.
В очередной статье автор показывает, какие странные проблемы бывают порой у бюджетных стораджей. Он собрал для своей домашней лабы сторадж на базе Synology DS411, с 4 дисками SSD в качестве хранилки, и получил, подключившись к ней по iSCSI, чудовищно плохие (и странные) результаты при записи (да и вообще, в целом на iSCSI плохие). При том, что при работе по NFS этой же проблемы нет.
Налицо явная проблема на уровне фирмвари контроллера. ?? кто знает, сколько таких “волчьих ям” поджидает юзеров “домашних NAS”, при попытке использовании их в жестких условиях энтерпрайза.

На днях NetApp опубликовала результаты одного из тестов, которые она проводит для своих стораджей, это так называемый Exchange Solution Review Program, спецификацию которого опубликовала Microsoft. Это небольшой, но довольно популярный у многих вендоров “прикладной” тест-бенчмарк, позволяющий продемонстрировать работу стораджей для использования под хранилище MS Exchange.
Текущая версия использует MS Exchange 2010.

NetApp тестировала по данной программе различные системы, в основном “малого класса”.
Недавний тест продемонстрировал возможности системы FAS2220 для инфраструктуры начального уровня (”начального” это по американским меркам, 1000 mailboxes, размером по 2GB, такие вот там “малые предприятия”).

Подробный отчет о тестировании можно посмотреть здесь:
http://media.netapp.com/documents/netapp-fas2220-mailbox-resiliency-storage-solution.pdf

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

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

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

Я уже немного рассказывал про любопытный софтовый продукт NetApp - NetApp Snap Creator. Это фреймворк для создания резервных копий данных в снэпшоты, с помощью средств системы хранения.

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

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

Для ряда приложений, таких как, например, MS SQL Server, MS Exchange, MS Sharepoint, Oracle DB, SAP, существует “коробочный продукт” - Snap Manager для соответствующего приложения.

Но что делать, если приложение есть, а Snap Manager для него нет?

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

Продукт интересный, и, как мне показалось, на него NetApp многое ставит, так как разных приложений много, и под все SnapManager не напишешь.

Недавно Snap Creator обновился до версии 3.6.0, и в нем появились новые возможности:

• Появилась поддержка для DOT 8.1 Cluster-mode и 7-mode.
• Поддерживается VMware vSphere 4.1 и 5.0, VMware vCloud Director 1.5.0 и 1.5.1, Red Hat KVM, Citrix Xen.
• Расширены имеющиеся возможности плагинов для Domino Server
• Улучшена поддержка в Protection Manager и взаимодействие со SnapVault
• Улучшен GUI и CLI

Берут его там же, где обычно, на сайте support.netapp.com

Рекомендую также посмотреть несколько видео-скринкастов, чтобы лучше разобраться что к чему.
Например:
Introduction to the NetApp Snap Creator Framework - Version 3.6
Snap Creator Agent Installation on Linux
Snap Creator Installation on Windows
Introduction to the Snap Creator GUI - Working with Backup Profiles and Configuration Files
Snap Creator GUI and SnapMirror
Snap Creator GUI and SnapVault

Остальные видео можно поискать тут: тег snap_creator в communities.netapp.com

Если у вас стоит задача интегрировать какое-то приложение со снэпшотным механизмом NetApp, и для которого нет уже готового SnapManager, или функциональность того, что делает SnapManager вас не устраивает, то Snap Creator для вас, несомненно, первый выбор.