about NetApp

28  сентября, менее чем через месяц, состоится главное публичное мероприятие года в российском NetApp – конференция NetApp Innovation 2010.

Регистрация открыта: http://www.netapp.com/ru/forms/ru-201009-innovation-regform.html

Программа опубликована: http://communicate.netapp.com/content/emea-ru-201009-agenda-innovation
Хотя еще будет дополняться.

Кстати, будет из “топов” главный по “Облакам” и cloud-решениям, так называемый “Облачный царь” (cloud tzar, это официльная должность в компании;), а также интересный блоггер - Val Bercovici.

Кроме того, разумеется, как и ранее, “весь вечер на арене” сотрудники российского представительства. Спешите получить ответы из первых рук на любые вопросы.
В программе также несколько рассказов о Success Stories компании в России, кто (справедливо) жаловался на отсутствие вестей о интересных и удачных решениях с использованием систем NetApp – вам тоже будет интересно.

Вы должно быть заметили, что тема компании Weta Digital в этом блоге появляется с завидной периодичностью. В первую очередь причина этому то, что Weta это давний и стойкий клиент NetApp, а задачи, которыми они занимаются, это настоящий “передний край” и то, что наши англоязычные коллеги называют challenge.

Некоторое время назад в России начал выходить новый журнал - “Суперкомпьютеры”, эта статья найдена в его первом номере, и с разрешения редакции я его тут (ре)опубликую. У журнала уже вышло два номера и сдается третий. В скором времени появится и онлайн-страничка с материалами уже опубликованных журналов. А пока же – отдельная статья. Какое отношение имеет Weta и фильм Avatar к суперкомпьютерам – читайте ниже.

Continue reading ‘«Аватар» глазами сотрудника компании Weta’ »

Недавно в новостях проскочил пресс-релиз NetApp, о том, что NetApp теперь поддерживает Thin Reclamation API компании Symantec. Эта новость имеет непосредственное отношение к теме Space Reclamation, которую я, кажется, в этом блоге еще не затрагивал.
Что такое Space Reclamation и зачем это вам нужно?

Задача Space Reclamation непосредственно соотносится с процессом использования так называемого Thin Provisioning.
Допустим, что мы создали в сети SAN на системе хранения LUN, на котором создана файловая система, и этот LUN постепенно заполняется данными. Мы решили использовать для этого LUN механизм Thin Provisioning, при котором место под LUN не выделяется сразу (хотя прикладная задача, использующая этот LUN "видит" сразу все заявленное место), а LUN может постепенно расти, по мере того, как на LUN записываются данные.
Настает момент, когда данные заполнили файловую систему, лежащую поверх LUN, и мы начали какую-то часть данных удалять, освобождая свободное место на диске.

Однако, у системы хранения НЕТ возможности понять, что ранее занятые блоки на LUN в созданной на нем файловой системе были освобождены. Вдобавок в современных файловых системах процесс освобождения блоков, использованных тем или иным файлом зачастую ограничивается пометкой в "таблице размещения файлов" (как бы она не называлась) блоков, занятых "удаленным" файлом, как "освобожденных", и только.

Таким образом, без "посредника" на уровне OS, драйвера файловой системы, или того или иного API к файловой системе, система хранения не имеет никаких средств, чтобы определить, что данный блок, ранее чем-либо занятый, больше не используется, и его можно не хранить, занимая место на диске.
Все что знает система хранения, что "вот эти" дисковые блоки были хотя бы раз "потроганы" со стороны хоста, а "вот эти" - нет. Понять, с какой целью они были "потроганы" система хранения не может.

По этой причине график использования места на LUN, с точки зрения системы хранения, почти всегда будет выглядеть примерно так:

Как вы видите, такая ситуация сильно снижает эффективность использования Thin provisioning, так как thin-provisioned LUN всегда однонаправленно растет, и единожды занятое место уже не освобождает, даже если фактически, со временем, он опустел.

Эта проблема присуща ВСЕМ системам хранения, независимо от того, как они работают, это не специфическая проблема NetApp, она присуща любым SAN-системам хранения, на которых хранятся LUN-ы в режиме thin provisioned.  
Повторюсь: без "посредника" на уровне OS узнать о том, что происходит на файловой системе поверх LUN, о том, какие из блоков ее теперь "пусты", и, значит, можно как-то их "оптимизировать" у системы возможности нет.

Так происходит с любыми LUN, в особенности это является проблемой при наличии thin provisioned LUN, так как, уверен, вы рассчитывали на то, что после удаления данных на LUN вы сможете использовать освободившееся место под распределение данных других LUN. Но не тут-то было.

То есть просто организовать использование thin provisioning в системе хранения зачастую недостаточно. Неплохо было бы как-то отрабатывать ситуацию с удаленными на LUN данными, иначе, как мы видим, LUN всегда "однонаправленно" растет в объеме, даже если в дальнейшем его содержимое и опустошается. Это, очень часто, сводит на нет все заманчивые перспективы использования thin provisioning в продакшне.

В 2007-м году в новой версии ПО SnapDrive for Windows появилась реализация механизма "hole punching" для файловой системы NTFS. Работая на уровне OS, SnapDrive "видит" содержимое файловой системы, лежащей на LUN, и коммуницирует с системой хранения, сообщая ей, какие из блоков более данных не содержат, и могут быть безболезненно освобождены.

Запуск процесса Space Reclamation в SnapDrive, может значительно уменьшить занимаемое LUN-ом место на дисках системы хранения, если мы создали его "нефиксированного размера", без "capacity guarantee", то есть в виде, который принято сегодня называть thin provisioned.

Недавно NetApp объявил, что он присоединился к инициативе компании Symantec, разработавшей в 2008 году Thin Reclamation API для своего продукта - Veritas File System (VxFS) и Veritas Volume Manager (VxVM). Ранее о реализации поддержки этого API объявили такие компании, как 3Par, IBM, EMC (Clariion), HP (XP), HDS.

Таким образом, пользователям NetApp теперь доступен механизм Space Reclamation для двух файловых систем - для NTFS через SnapDrive for Windows и для VxFS через Thin Reclamation API.

Механизм работы в принципе довольно прост и стандартен, возможно, со временем, мы увидим его реализацию и для других файловых систем. Используется стандартизованная комитетом T10 (организацией, которая занимается разработкой и стандартизацией протокола SCSI) команда SCSI-3 WRITE_SAME с флагом UNMAP. Также предложена для введения в стандарт собственно команда UNMAP, которая облегчает взаимодействие между инициатором и таргетом, в том числе и в таких задачах.

Широкое распространение этого метода откроет новые перспективы использования динамически распределяемого пространства на системах хранения.

Тема якобы катастрофического уменьшения usable space по сравнению с raw space на системах хранения NetApp занимает, по популярности, у наших конкурентов, пожалуй, третье место, сразу за страшилкой про "ужасную фрагментацию", и пугалкой про "эмуляцию LUN-ов поверх файлов на файловой системе". Про первых две я уже писал, и не по разу, пришла пора разобраться и с этой.
Основой для поста послужил перевод статьи в блоге Recoverymonkey.

Ранее я уже рассматривал "первую часть" ситуации, то, как образуется usable disk space, то есть та емкость, которая остается для использования на дисках, после того, как мы вычтем из них parity, hot spare и ряд прочих "накладных расходов". Однако это еще не все, определенный объем на дисках также занимают различные структуры данных. Я называю получившееся пространство, после того, как из usable disk space вычтутся прочие накладные расходы - usable system space.

Во многих виденных мной у конкурентов "документах" такого рода постоянно рассказывается о том, что, якобы, usable system space на системах хранения NetApp составляет менее 50% от купленного raw, а у одного "последовательного борца" с NetApp даже доходила до анекдотичных 34%.
Это смешно для тех, кто знает, как оно обстоит на практике, но все еще производит впечатление на новичков, тех, кто еще не разобрался с тем, как дела обстоят на самом деле.
Ну хорошо, где же истина, которая, как всегда "где-то рядом"?

Цель данного поста - рассмотреть ситуацию с тем, как и из чего образуется usable space на системах NetApp по состоянию дел и технологий на весну 2010 года.
Так как системы NetApp используют свободное пространство на дисках разными способами, а не просто для "хранения LUN-ов" , это постоянно порождает множество непониманий в том, что означают те или иные понятия и параметры, относящиеся к распределению свободного пространства на дисках системы хранения. При этом ряд рекомендаций NetApp изменялись с течением времени, по мере выхода новых версий их OS и взросления используемых технологий. Наша цель - рассмотреть текущее положение дел и обновить понимание вопроса у тех, кто по тем или иным причинам "отстал".

Коротко, "для тех, кому лень читать все"
(то, что называется "Executive summary" ;)

В зависимости от количества и типа дисков и общего дизайна хранилища, исключая самые маленькие системы с очень небольшим количеством дисков, реальная величина usable space целиком системы NetApp может легко превышать 75% от usable space самих дисков. Я видел, например, величину в 78%. Такое значение, конечно же, обеспечивалось при использовании защиты от двойного сбой (RAID-6/DP) и включала spares. Эта величина показывает "честный" объем хранимых данных для NAS или SAN и не включает в себя дедупликацию, компрессию или клоны типа FlexClone; вместе со всеми перечисленными технологиями, эффективность может легко превысить и 1000%. Во многих случаях клиенты NetApp выбирают их системы хранения как раз именно потому, что системы NetApp настолько эффективны с точки зрения usable space. А теперь перейдем к подробностям…

Continue reading ‘Usable Space у NetApp – что стоит за FUD? (часть 2)’ »

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

Одной из самых популярных “страшилок-говнилок” в отношении NetApp является пугалка о том, как неэффективно расходуется пространство на системах хранения NetApp, как мало получается usable space из данного объема raw. Пожалуй, по популярности эта “говнилка” у наших конкуретнов идет сразу за страшилкой о фрагментации (и ее мифическим “катастрофическим влиянием на производительность”), и за пугалкой про “эмуляцию LUN поверх файловой системы”. Я уже писал ранее про то, как обстоит дело с первой, и рассказывал как устроена организация данных на “низком уровне” в WAFL, объясняющая ситуацию со со второй.

Пришла пора разобрать где правда в третьей.
Итак, правда ли, что usable space на NetApp получается значительно меньше на том же объеме raw, например при сравнении с “более традиционными” системами?

Давайте разберем пример, хоть и не исчерпывающий, но довольно зрелищный.

Continue reading ‘О расчете дискового пространства: NetApp FAS и EMC NS – что стоит за FUD (часть 1)’ »

Системы хранения NetApp позволяют ограничить доступ к админской консоли, задав IP-адрес админского хоста либо при установке, либо в параметре admin.hosts

Однако, иногда хотелось бы задать не один конкретный адрес, а подсеть, или несколько адресов.

В этом случае возможен следующий простой трюк. Можно указать в качестве админхоста gateway соответствующей подсети, например в которой находятся рабочие места админов. В этом случае доступ будет ограничен только хостами указанной подсети:

fas1> options admin.hosts 192.168.1.254

Другой вариант – указать их в таком виде:

fas1> options admin.hosts host1.domain.com:host2.domain.com:host3.domain.com

Не забывайте, что это ограничение предельно примитивное, и строить защиту админского доступа только на нем не стоит, так как определяет возможность доступа к логину консоли исключительно по легко изменяемому IP источника. Если стоит задача серьезного разграничения доступа, то стоит использовать как “секурный” доступ по SSH и HTTPS (команда secureadmin), pre-shared key, и средства RBAC (Role-based Access Control), о которых я писал ранее и есть переведенный на русский документ в техбиблиотеке.

В связи с приближающейся долгожданной 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 пока остаются без “восьмерки”. Ждем осени и предполагающегося, подобно прошлому году, объявления новых продуктов.

В блоге Vaughan Stewart-а, “главного блоггера NetApp по VMware” найдена полезная информация. NetApp предлагает специальный скидочный код для покупки full conference pass for individuals для VMworld в San Francisco, а также VMworld в Copenhagen. С дисконтом NetApp цена снижается с $1745 до $1495 (USD) и с € 1150 до € 950 (Euro).

Использовать код можно при регистрации на VMworld по следующему адресу:

http://www.vmworld.com/registration.jspa?sponsorCode=NAPP

Просто введите один из этих кодов при завершении покупки билета:

San Francisco code: NETAPP_EB_US2010
Copenhagen code: NETAPP_EB_EMEA2010

Дополнение: Как пишет Nick Howell, дисконт NetApp работает и “задним числом”, то есть, если вы уже приобрели билет за полную цену, вы можете получить вашу скидку, послав запрос по email: VMworld2010Registration@vmware-events.com.

Довольно долго наблюдаю, как некоторые конкуренты NetApp указывают на то, что системы хранения NetApp якобы лишены механизма Consistency Groups. Для начала, что такое Consistency Group как таковое.

В опеределенных задачах, например в базах данных, при репликации или создания снпшотов, необходимо оперировать двумя и более разделами данных (это могут быть, например, LUN-ы, или разделы NFS) как единой, логически связанной структурой данных.

Например, наша база данных осуществляет запись данных в лог БД об осуществлении операции, и заносит запись в собственно базу, находящихся в разных LUN. Либо наша бизнес-операция требует связанного изменения в различных базах, располагающихся в разных разделах (или даже на разных контроллерах) например при проведении операции продажи уменьшить на единицу количесетво товара на складе, и одновременно увеличить баланс на цену товара. При этом, если мы создадим снэпшот без учета этой связности, а, как назло, момент создания снэпшота придется между завершением одной и началом второй операции, мы получим неконсистентный “слепок” нашей базы, верный лишь частично, и способный создать в дальнейшем серьезные проблемы.

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

Итак, Consistency Groups на NetApp. Какова же ситуация сегодня на самом деле?

Consistency Groups на системах NetApp FAS существуют с версии Data ONTAP 7.2, однако работа с ними со стороны хоста производится через специальный API (ZAPI), который предоставляет, например, ПО SnapDrive. Работать с Consistency Groups можно как непосредственно из SnapDrive (UNIX/Windows), так и вызывая средства API из скриптов, например на Perl.

В рамках этого API так называемый “агент” (это может быть или собственный “высокоуровневый” продукт NetApp, например SnapManager for Oracle, SnapCreator, или же оперирующий вызовами API самодельный скрипт):

• Отдает команду участвующим в процессе контроллеру (или контроллерам, если наша consistency group расположена на разных контроллерах): start-checkpoint.
• Контроллеры приостанавливают (fence) процесс записи на тома, входящие в заданную consistency group (CG).
• Контроллеры подготавливают snapshot для указанных томов.
• Агент получает уведомление fence-success от всех участвующих контроллеров
• Агент отдает команду commit-checkpoint всем участвующим контроллерам
• Приняв команду контроллеры производят одновременное создание снэпшотов томов в CG
• По завершении контроллеры рапортуют об успешном завершении и снимают блокирование записи (unfence).

В случае использования интефейса SnapDrive команда создания снэпшота, использующая CG очень проста.
Допустим, у нас есть база данных (/u01/oradata/prod), расположенная на LUN-ах, лежащая на томах двух контроллеров – filer1 и filer2 (filer1:/vol/prodvol1 и filer2:/vol/prodvol1). Тогда процесс создания консистентной копии в снэпшоте с использованием snapdrive будет прост:

> snapdrive snap create -fs /u01/oradata/prod -snapname snap_prod_cg

Эта команда автоматически инициирует все процессы для всех задействованных в файловой системе /u01/oradata/prod LUN-ов, скомандует их контроллерам, и создаст консистентную копию с именем snap_prod_cg.
Аналогичным образом сработает команда для консистентной копии двух разных файловых систем (u01 и u02):

> snapdrive snap create -fs /u01/oradata/prod /u02/oradata/prod -snapname snap_prod_cg

Так что утверждение, что, якобы, на NetApp нет consistency groups действительности не соответствует. Они есть, работают, и достаточно активно используются, а утверждающим это специалистам конкурентов стоит обновить свои знания о состоянии дел в продукции конкурентов.

Подробнее о Consisency Groups и работе с ними в контексте Oracle:
TR-3858: Using Crash-Consistent Snapshot Copies as Valid Oracle Backups
Очень полезный документ о работе со снэпшотами баз Oracle, использования их как резервных копий, восстановления из них, в том числе много рассматривается тема consistency groups.
Одним из авторов документа является “гуру” темы использования NetApp под Oracle, сотрудник бразильского офиса – Neto, автор весьма интересного (и что еще лучше – регулярно пополняемого) блога на сайте NetApp.

Иногда приходится сталкиваться с неполным пониманием того, что именно и как выводится в команде snap list.

Давайте на примерах разберем “что есть что”, где и как.

У нас есть том vol1 на 100G, практически пустой.

fas3020a> df -h vol1
Filesystem               total       used      avail capacity  Mounted on
/vol/vol1/               80GB       17MB       79GB       0%  /vol/vol1/
/vol/vol1/.snapshot      20GB       61MB       19GB       0%  /vol/vol1/.snapshot
 
fas3020a> snap list vol1
Volume vol1
working…
 
  %/used       %/total  date          name
———-  ———-  ————  ——–
31% (31%)    0% ( 0%)  Mar 08 00:00  nightly.0
47% (29%)    0% ( 0%)  Mar 07 20:00  hourly.0
57% (32%)    0% ( 0%)  Mar 07 16:00  hourly.1
64% (29%)    0% ( 0%)  Mar 07 12:00  hourly.2
69% (32%)    0% ( 0%)  Mar 07 08:00  hourly.3
73% (29%)    0% ( 0%)  Mar 07 00:01  nightly.1
76% (30%)    0% ( 0%)  Mar 06 20:00  hourly.4
78% (31%)    0% ( 0%)  Mar 06 16:00  hourly.5

В этом выводе, колонка %/used показывает объем, занятый снэпшотами, деленный на количество использованных в настоящий момент блоков на томе, независимо от того, заняты ли они в активной файловой системе, или снэпшотах. Первое число – накопительная сумма для всех показанных снэпшотов. Второе число (в скобках) – только для конкретного снэпшота.

Снэпшоты тома vol1 занимают 78% всех занятых на томе блоков, каждый из снэпшотов занимает примерно 29-32% занятых блоков.

Колонка %/total показывает объем занятый снэпшотами, деленный на общий объем диска. Он включает в себя пространство для данных, плюс snapshot reserve, то есть все использованные и свободные блоки тома. На томе 100GB занято примерно 61MB в снэпшотах, что составляет менее 1% общего объема (поэтому значение – 0).
Значение (в скобках) вычисляется аналогично вышеприведенному для %/used.

Давайте посмотрим, как все изменится, если мы уменьшим размер тома vol1 со 100GB до 1GB.

fas3020a> df -h vol1
Filesystem               total       used      avail capacity  Mounted on
/vol/vol1/              819MB       17MB      801MB       2%  /vol/vol1/
/vol/vol1/.snapshot     204MB       61MB      143MB      30%  /vol/vol1/.snapshot

fas3020a> snap list vol1
Volume vol1
working…
 
  %/used       %/total  date          name
———-  ———-  ————  ——–
31% (31%)    1% ( 1%)  Mar 08 00:00  nightly.0
47% (29%)    1% ( 1%)  Mar 07 20:00  hourly.0
57% (32%)    2% ( 1%)  Mar 07 16:00  hourly.1
64% (29%)    3% ( 1%)  Mar 07 12:00  hourly.2
69% (32%)    4% ( 1%)  Mar 07 08:00  hourly.3
73% (29%)    4% ( 1%)  Mar 07 00:01  nightly.1
76% (30%)    5% ( 1%)  Mar 06 20:00  hourly.4
78% (31%)    6% ( 1%)  Mar 06 16:00  hourly.5

Теперь мы видим, что снэпшоты заняли большее относительное пространство на томе в целом (%/total), то есть занятых И пустых, но процент блоков в снэпшотах, относительно всех только занятых блоков на томе (%/used) остался неизменным.

Как всем этим полагается правильно пользоваться?

Величины %/used и %/total полезны при оценке того, насколько правильно выбрана величина snapshot reserve. Нехватка резерва приводит к тому, что снэпшоты “вылезают” за пределы резерва, и начинают занимать место в пространстве данных. Когда команда df показывает величину заняости диска больше 100% – это как раз такой случай: снэпшоты переполнили пространство резерва и начали заполнять пространство собственно данных. Это не страшно, особенно если для тома работает autogrow (и есть место на aggregate) или autodelete (и вы можете безболезненно удалить некоторые старые снэпшоты), но, тем не менее, этого следует избегать для более однозначной организации данных.

Когда вы решаете удалить тот или иной снэпшот, рекомендуется пользоваться командой snap delta или snap reclaimable, чтобы выбрать наиболее эффективный с точки зрения освобождения места снэпшот.
Число после точки в имени снэпшота увеличивается со взятием нового снэпшота. Например, сли вы берете снэпшот каждый час, то hourly.1 взятый в 9 утра, станет hourly.5 в 13:00. Также это работает и в случае daily- или weekly-снэпшотов.
Обратите внимание, что снэпшоты с явно заданным именем (то есть не те, что создаются по расписанию), а также снэпшоты, созданные SnapMirror и SnapVault не изменяют своего имени при создании новых.