3 заметки с тегом

ONTAP

Volume rehost

Хотел рассказать про новую функцию volume rehost, которая появилась в ONTAP 9, но за меня это отлично сделал Justin Parisi. Поэтому мне осталось всего лишь перевести его пост.

Но для начала я бы хотел напомнить, что такое Storage Virtual Machine (SVM). Потому что часто сталкиваюсь с тем, что даже у опытных пользователей NetApp отсутствует четкое понимание. Чего уж говорить о новичках.

Итак, SVM, которые раньше назывались Vservers, появились в кластерной версии Data ONTAP. По-простому, это виртуальная СХД. Но не у всех есть понимание какие ресурсы кластера явлются общими, а какие привязаны к SVM.

Все ресурсы кластера грубо можно разделить на физические:

  • controller или node, которые объединяются в HA-пару
  • disks и RAID-group
  • aggregates
  • network ports, как Ethernet, так и FC

И логические:

  • FlexVol (тома)
  • LUN
  • qtree
  • files
  • igroup
  • LIF (logical interface)
  • namespace
  • exports и shares
  • и т. д.

Так вот SVM это виртуальная система хранения, которая объединяет в себе логические ресурсы и реализует доступ к данным по одному или нескольким доступным нам протоколам. Эти логические ресурсы не привязаны жёстко к физическим ресурсам. Можно переносить тома с агрегата на агрегат. Агрегаты при этом могут принадлежать разным контроллерам и HA-парам. LIF могут мигрировать с одного физического порта на другой, и также не привязаны к нодам (исключение с SAN LIF, они не мигрируют). В кластере может существовать больше одной SVM. И они спокойно могут размещать свои логические ресурсы на одних и тех же физических ресурсах. Каждая SVM изолирована от другой. У каждой SVM свой администратор и ими можно управлять независимо.

——

В Clustered Data ONTAP (теперь уже NetApp ONTAP) применяются виртуализированные контейнеры хранения, называемые Storage Virtual Machine (SVM). Они обеспечивают безопасную изоляцию в многопользовательских средах.
Каждая SVM владеет объектами вроде сетевых интерфейсов, FlexVol и выступает в качестве отдельной системы хранения поверх кластера из контроллеров и дисковых полок. В предыдущих версиях ONTAP тома были жёстко привязаны к SVM и перенос их на другую SVM в кластере был не так прост. Необходимо было использовать SnapMirror для репликации тома или скопировать данные другим способом. Процесс занимал время, был неэффективным и клиенты долгое время просили добавить возможность простой миграции томов между SVM.

Эта функциональность в ограниченном варианте была доступна в Data ONTAP 8.3.2 для использования во время миграции с 7-mode при помощи Copy-Free Transition.
Но теперь в ONTAP 9 мы можем перемещать тома между SVM без фактического копирования данных.

Как это работает?

Каждая SVM имеет уникальный идентификатор — UUID. Для того, чтобы узнать его необходимо выполнить следующую команду в advanced режиме:

ontap9-tme-8040::*> vserver show -vserver parisi,SVM1 -fields uuid
vserver uuid
------- ------------------------------------
SVM1 05e7ab78-2d84-11e6-a796-00a098696ec7
parisi 103879e8-2d84-11e6-a796-00a098696ec7
2 entries were displayed.

Когда том находится во владении SVM, то он ассоциируется с UUID SVM. И для него имеется специальный файл-хендлер, связанный с root namespace SVM.

В прошлых версиях ONTAP вы могли пренести том “руками”, если вы знаете секретную последовательность команд и у вас хватит на это смелости. Теперь же команда volume rehost автоматизирует весь этот процесс. Нет необходимости самостоятельно править кластерные базы и проверять, что нигде не напортачили.

К делу!

Теперь посмотрим как эта команда работает на практике. Ниже вывод man из ONTAP 9. Но имейте в виду, что использовалась предварительная версия “девятки” и в релизе вывод мог ненмого поменяться.

ontap9-tme-8040::*> man volume rehost
volume rehost Data ONTAP 9.0 volume rehost

NAME
 volume rehost -- Rehost a volume from one Vserver into another Vserver

AVAILABILITY
 This command is available to cluster administrators at the admin privilege
 level.

DESCRIPTION
 The volume rehost command rehosts a volume from source Vserver onto desti-
 nation Vserver. The volume name must be unique among the other volumes on
 the destination Vserver.


PARAMETERS
 -vserver <vserver name> - Source Vserver name
 This specifies the Vserver on which the volume is located.

-volume <volume name> - Target volume name
 This specifies the volume that is to be rehosted.

-destination-vserver <vserver name> - Destination Vserver name
 This specifies the destination Vserver where the volume must be
 located post rehost operation.

{ [-force-unmap-luns {true|false}] - Unmap LUNs in volume
 This specifies whether the rehost operation should unmap LUNs
 present on volume. The default setting is false (the rehost opera-
 tion shall not unmap LUNs). When set to true, the command will unmap
 all mapped LUNs on the volume.

| [-auto-remap-luns {true|false}] } - Automatic Remap of LUNs
 This specifies whether the rehost operation should perform LUN map-
 ping operation at the destination Vserver for the LUNs mapped on the
 volume at the source Vserver. The default setting is false (the
 rehost operation shall not map LUNs at the destination Vserver).
 When set to true, at the destination Vserver the command will create
 initiators groups along with the initiators (if present) with same
 name as that of source Vserver. Then the LUNs on the volume are
 mapped to initiator groups at the destination Vserver as mapped in
 source Vserver.

Том, который будет “менять” SVM называется “move_me” и принадлежит SVM1.

ontap9-tme-8040::*> volume show -vserver SVM1 -fields msid,dsid,uuid,vserver -volume move_me
vserver volume dsid msid uuid
------- ------- ---- ---------- ------------------------------------
SVM1 move_me 1027 2163225631 cc691049-2d84-11e6-a796-00a098696ec7

Чтобы перенести этот том, просто вводим команду:

ontap9-tme-8040::*> volume rehost -vserver SVM1 -volume move_me -destination-vserver parisi

После запуска команды появляется предупреждение:

Warning: Rehosting a volume from one Vserver to another Vserver does not
 change the security information on that volume.
 If the security domains of the Vservers are not identical, unwanted
 access might be permitted, and desired access might be denied. An
 attempt to rehost a volume will disassociate the volume from all
 volume policies and policy rules. The volume must be reconfigured
 after a successful or unsuccessful rehost operation.

В общем, предупреждают, что, если на другой SVM используются отличные от первой настройки AD или LDAP, то могут быть проблемы с доступом к тому. (Vserever это то же самое, что и SVM).

Через несколько секунд получаем результат:

[Job 42] Job succeeded: Successful

Info: Volume is successfully rehosted on the target Vserver.
Set the desired volume configuration - such as the export policy and QoS policy - on the target Vserver.

Проверяем том. Он не принадлежит старой SVM:

ontap9-tme-8040::*> volume show -vserver SVM1 -fields msid,dsid,uuid,vserver -volume move_me
There are no entries matching your query.

Теперь том в новой SVM:

ontap9-tme-8040::*> volume show -vserver parisi -fields msid,dsid,uuid,vserver -volume move_me
vserver volume dsid msid uuid
------- ------- ---- ---------- ------------------------------------
parisi move_me 1028 2163225632 cc691049-2d84-11e6-a796-00a098696ec7

Другая SVM. Другие MSID/DSID. Тот же UUID для тома (это UUID именно тома, а не SVM, поэтому он не меняется). Для файлового доступа достаточно перемонтировать том, так как поменлся IP-адресс и хендлер.
Для LUNов можно использовать следующие флаги:

{ [-force-unmap-luns {true|false}] - Unmap LUNs in volume
 This specifies whether the rehost operation should unmap LUNs
 present on volume. The default setting is false (the rehost opera-
 tion shall not unmap LUNs). When set to true, the command will unmap
 all mapped LUNs on the volume.

| [-auto-remap-luns {true|false}] } - Automatic Remap of LUNs
 This specifies whether the rehost operation should perform LUN map-
 ping operation at the destination Vserver for the LUNs mapped on the
 volume at the source Vserver. The default setting is false (the
 rehost operation shall not map LUNs at the destination Vserver).
 When set to true, at the destination Vserver the command will create
 initiators groups along with the initiators (if present) with same
 name as that of source Vserver. Then the LUNs on the volume are
 mapped to initiator groups at the destination Vserver as mapped in
 source Vserver.

А что с FlexClones?

Тома могут иметь клоны (FlexClone). FlexClone — это копия тома, доступная на запись и чтение, котрая создана на основе снепшота, и не занимающая места пока в этот клон не начнут вносить изменения.

Что будет, если попытаться перенести том, у кторого есть клон, из одной SVM в другую?
Для начала создаём клон:

ontap9-tme-8040::*> volume clone create -vserver parisi -flexclone clone -type RW -parent-vserver parisi -parent-volume move_me -junction-active true -foreground true
[Job 43] Job succeeded: Successful

А потом узнаём, что rehost для томов с клонами пока не работает:

ontap9-tme-8040::*> vol rehost -vserver parisi -volume move_me -destination-vserver SVM1 -force-unmap-luns false -allow-native-volumes false

Error: command failed: Cannot rehost volume "move_me" on Vserver "parisi"
 because the volume is a parent of a clone volume.


ontap9-tme-8040::*> vol rehost -vserver parisi -volume clone -destination-vserver SVM1 -force-unmap-luns false -allow-native-volumes false

Error: command failed: Cannot rehost volume "clone" on Vserver "parisi"
 because the volume is a clone volume.

Вот и все для начала.

——

2016   9   9.0   FlexVol   ONTAP   SVM   tutorial

Что такое inline data compaction?

Сегодня у нас перевод статьи из рассылки Tech ONTAP про новую функцию для повышения эффективности хранения, которая появилась в NetApp ONTAP 9 — inline data compaction.
...

В NetApp ONTAP 9 мы добавили новую функцию для увеличения эффективности хранения, которая называется inline data compaction (уплотнение данных на лету). Так как эта концепция нова для большинства, я решил потратить немного времени на объяснение в этой статье как работает уплотнение и как эта технология взаимодействует с другими технологиями повышения эффективности хранения.

Данные уплотняются последовательно в том же порядке, что они и попадают на контроллер. Пока данные в памяти контроллера, мы берём “куски” данных, каждый из которых в обычной ситуации занял бы целый 4KB блок (если кто забыл ONTAP оперирует данными с гранулярностью в 4KB — прим. переводчика), и уплотняем их. Благодаря уплотнению больше одного “куска” данных помещаются в 4KB физический блок. Это можно сравнить с упаковкой чемодана или рюкзака. Мы можем взять блоки, часть которых содержит нули или пустое пространство, избавиться от пустого пространства и тем самым уплотнить их.

Операция уплотнения происходит в процессе создания consistency point (CP). Это часть сборки “тетриса”: у меня есть несколько маленьких “кусков” данных. Могу ли я быстро их совместить так, чтобы они уместились в один физический блок до того как я запишу его на носитель? Пока мы разрабатывали технологию уплотнения, мы подали на регистрацию немало патентов. Наш метод инновационный. Уплотнение работает по-умолчанию в системах All-flash FAS. И его опционально можно включить на обычных FAS системах, как на HDD агрегатах, так и на Flash Pool агрегатах. В любой случае, вы ничего не платите за эту функцию, она находится в ядре ONTAP, как дедупликация и компрессия.

Уплотнение это механизм дополняющий существующие технологии. Оно ортогонально дедупликации, но очень хорошо работает совместно с адаптивной компрессией (алгоритм, который используется в AFF и использует 8KB группы — прим. переводчика). При использовании адаптивной компрессии на лету, мы создаём группы компрессии, когда данные можно сжать на 50 и более процентов. После сжатия данных мы смотрим можно ли совместить в одном физическом 4KB блоке несколько мелких “кусков”, которые получились после сжатия. Так как это всё происходит в процессе CP, то операция уплотнения требует очень мало ресурсов, максимум 1% или 2% CPU. У вас никогда не должно быть ситуации, когда дополнительные 1%-2% нагрузки на CPU, критически меняют ситуацию с загрузкой. В такой ситуации ваша система уже перегружена.

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

Вот как хронологически работают технологии эффективности на контроллере, при условии, что все они активны:

  1. В первую очередь мы детектируем любые блоки, состоящие целиком из нулей. Такие блоки мы вообще не записываем, мы лишь обновляем метаданные. По существу эти блоки лишь увеличивают счётчик ссылок.
  2. После мы применяем адаптивную компрессию. Этот процесс очень эффективен с точки зрения производительности. Мы определяем можно ли сжать блок на 50% и более. Мы не тратим циклы CPU, пытаясь сжать данные на 49% (это не даст никакой выгоды).
  3. Дальше работает инлайн дедупликация. Эта функция появилась в ONTAP 8.3.2. В данном алгоритме сравниваются и дедуплицируются только блоки, которые находятся в памяти. В ONTAP 9.0 расширили размер хранилища хэшей отпечатков и туда теперь включаются блоки, которые были недавно записаны. Если вы хотите увеличить выигрыш от дедупликации, то мы советуем в дополнение использовать фоновую дедупликацию по расписанию.
  4. И наконец, срабатывает уплотнение. Любые данные, которые уже были сжаты, или наоборот не рассматривались, в качестве кандидатов на сжатие, подходят для уплотнения. Это могу быть, например, маленькие несжатые файлы или данные сжатые на 75% и более. Процесс уплотнения собирает физический 4KB блок из двух или более таких “кусков”. Чем выше степень сжатия или чем меньше файлы, тем выше выгода от уплотнения. То есть мы можем получить множественный эффект, совмещая малые блоки, сжатие и уплотнение. Вы скорее всего не узнаете какой эффект от уплотнения вы можете получить, пока не начнёте использовать эту технологию. При уплотнении используется эвристический анализ во время CP. Алгоритм динамически меняет количество ресурсов, которые затрачиваются на уплотнение. Цель — найти оптимальное соотношение затраченных ресурсов на полученную степень уплотнения.

Вы можете использовать уплотнение данных без компрессии и дедупликации. Допустим у вас среда, в которой хранятся только очень маленькие файлы, 2KB и меньше. Эти файлы не сжимаются и скорее всего от дедупликации будет мало толку. Зато при использовании уплотнения вы получите выигрыш всякий раз, когда два или более файла будут сохраняться в одном 4KB физическом блоке.

Порядок применение технологий повышения эффективности хранения данных

В случае с репликацией, если источник и получатель использует одни и те же политики эффективности, то выгода от технологий эффективности будет сохранятся. Нет никакой необходимости заново прогонять данные через все алгоритмы на получателе. К примеру, вы используете систему AFF, на которой все процессы эффективности включены по-умолчанию, и реплицируете данные с неё на обычный FAS с помощью SnapVault. Если вы хотите сохранить выгоду от дедупликации, компрессии и уплотнения в процессе передачи данных, то вам необходимо, чтобы соответсвующие поликти были включены на FAS системе.

Суммируя, уплотнение данных на лету никак не изменяет сами данные. Мы просто пытаемся более эффективно упаковать данные. Если у вас не хранится множество мелких файлов, то проще всего думать об уплотнении, как о технологии, которая повышает эффективность работы адаптивной компрессии. Уплотнение поможет вам, если у вас есть операции меньше 4KB. Учитывая то, что уплотнение почти не тратит ресурсы CPU, при этом даёт дополнительное полезное пространство, его однозначно стоит использовать с All-flash FAS.

...

На самом деле примерно оценить эффективность работы уплотнения, как и компрессии с дедупликацией можно с помощью утилиты SSET (Space Savings Estimation Tool). Она доступна для партнёров и клиентов NetApp на support-сайте.

2016   9   9.0   AFF   compaction   compression   deduplication   ONTAP   ONTAP 9   WAFL

FlexGroups

В конце июня стала доступна новая версия Data ONTAP. 9. Правда теперь Data ONTAP стала называться просто ONTAP. Есть три варианта ONTAP. ONTAP, ONTAP Cloud и ONTAP Select. Про первые два варианта все понятно, а ONTAP Select это продолжение идеи Data ONTAP Edge. Хорошая статья про Select есть на Хабре.
Про нововведения в основной версии ONTAP тоже написано уже немало. Статья на английском.
Про ONTAP 9 рассказывали 22 июня в Москве. На техническом семинаре по обновлениям продуктов — NetApp TechUpdate.
Но есть одна интересная функция в новой ONTAP, про которую почти никто не говорит :) Это — FlexGroups.
Далее перевод (с небольшими сокращениями) поста Justin Parisi, который является Technical Marketing Engineer по NAS протоколам и name services в NetApp.

Объемы данных растут

Времена, когда 100TB для файловой системы в одном томе это достаточно, прошли. Размеры файлов растут, объемы активно обрабатываемых данных растут. К примеру, представьте те объемы данных, которые приходится хранить сервисам по работе с медиа-данными. Или компаниями, которые работает с GPS данными. Или с аналитикой по разведке месторождений нефти и газа. Обычно таким компаниям приходится работать с огромными массивами данных и миллиардами файлов.

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

Некоторое время системы хранения схожие с ONTAP использовали единственный контейнер для хранения файловых данных — Flexible Volume (FlexVol).

FlexVol прекрасны, но…

Для большинства случаев FlexVol идеальны. Они позволяют хранить достаточный объем данных (до 100TB) и большое количество файлов (до 2 миллиардов). В случае с файловым доступом вы можете решить почти все задачи, используя FlexVol. Но у вас могут начаться проблемы, если у вас будет расти количество операций с метаданными (прим. переводчика — часто для решения этих проблем мы используем кэширование метаданных на FlashCache или FlashPool). Операции с матаданными выполняются последовательно на уровне FlexVol и не могут использовать все доступные ядра и потоки CPU. К тому же FlexVol привязан к конкретному агрегату и контроллеру, соответственно и работа с файловой системой будет ограничена производительностью агрегата и контроллера. Если у вас кластер из 10 нод, каждая с несколькими агрегатами, то у вас скорее всего не выйдет получить максимально доступную по ресурсам производительность.

Вот здесь и пригодятся FlexGroups

FlexGroups разработаны для решения множества проблем масштабных файловых нагрузок:

  • Объем хранимых данных — до 20PB
  • Большое кол-во файлов — до 400 миллиардов файлов
  • Производительность — распараллеливание файловых операций по CPU, нодам, агрегатам и FlexVol
  • Автоматическая балансировка нагрузки — использование всех доступных ресурсов для набора данных
  • Отказоустойчивость — исправление ошибок метаданных в реальном времени без остановки доступа

Теперь с FlexGroups файловые нагрузки могут утилизировать все доступные в кластере ресурсы. Даже если вы используете однонодовый кластер, FlexGroups могут балансировать нагрузку между несколькими FlexVol и агрегатами.

Как работают FlexGroups?

FlexGroups используют прекрасную концепцию FlexVol и улучшают её, соединяя множество FlexVol в единое пространство имен (namespace), которое для клиентов и администраторов выглядит как единый FlexVol.

Грубо FlexGroups можно изобразить вот так:

Как это будет выглядеть для NAS клиента:

Файлы пишутся в конкретные FlexVol, составляющие FlexGroup. Файлы не разбиваются на части. Степень параллелизации, которую можно получить с FlexGroup, зависит от количества FlexVol из которых она будет состоять. В данный момент максимальное количество FlexVol для FlexGroup — 200. Максимальный размер тома 100TB и максимальное количество файлов 2 миллиарда. Так мы и получаем наши “20PB, 400 миллиардов файлов”. Имейте в виду, что это протестированные на данный момент лимиты. Теоретически эти значения могут сильно вырасти.

Когда клиент создает файл в FlexGroup, ONTAP решает, какой из томов лучше всего подходит для записи файла. Решение основывается на нескольких критериях, например, свободное место, throughput, загруженность ноды, к какому тому обращались последний раз и т. д. Все происходит без вмешательства клиента. Идея в том, чтобы члены FlexGroup были максимально сбалансированы и этом все не вредило предсказуемости производительности.

Запрос на создание файла может прийти на любую ноду кластера. Если ONTAP решает сохранить файл на другой ноде, создается жёсткая ссылка и запрос передаётся соответствующему тому на другой ноде. Операции чтения и записи для уже созданного файла происходят также как и в обычном FlexVol; система сообщит клиенту расположение файла и укажет на соответсвующий FlexVol.

Чем это лучше?

Когда файловые операции могут быть раскиданы между множеством FlexVol мы не сталкиваемся с проблемой последовательных операций с метаданными в системе. Вместо этого мы распределяем нагрузку по множеству файловых систем (FlexVols) соединенных вместе (FlexGroups). И в отличии от Infinite Volumes здесь нет единого тома для хранения метаданных. Каждый том в FlexGroup может принимать участие в работе с метаданными.

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

То, что для параллелизации операций в большой инфраструктуре лучше всего создавать несколько FlexVol, давно перестало быть секретом. Но всё еще существовало ограничение в 100ТБ на том и трудности с управлением точками монтирования при переносе томов и т. д. Планирование оптимального расположения томов для получения максимальной производительности — отдельная головная боль для администраторов.

Теперь, с появлением FlexGroups, все эти проблемы будут решены за вас. И вам не надо заниматься планированием оптимального размещения данных.

Каков потенциальный прирост производительности?

По предварительным тестам FlexGroup против одного FlexVol мы увидели прирост производительности в 6 раз. И это с обычными SAS HDD. Конфигурация была следующей:

  • Одна нода FAS8080
  • SAS HDD
  • 16 FlexVol членов FlexGroups
  • 2 агрегата
  • 8 томов на агрегат

В качестве тестовый нагрузки была работа с исходными кодом в Git. По графикам ниже можно заметить, что самый большой прирост получился на операциях checkout и clone.

Если увеличить количество нод, агрегатов и томов в FlexGroup, то результаты будут еще лучше. А если подумать о добавлении AFF (All-flash FAS), то время выполнения теста сократится еще больше.

Snapshots

В первом релизе FlexGroup у нас реализована функциональность снэпшотов. Они работают как обычные снэпшоты в ONTAP — на уровне FlexVol.

Но так как FlexGroups это коллекция нескольких FlexVol, то мы хотим быть уверенными, что все снэпшоты создаются в одно и то же время и сохраняется консистентность файловой системы. Поэтому создание снэпшотов FlexGroup координируется ONTAP. Если не получается создать снэпшотов какого-то из томов, то весь снэпшот FlexGroup отменяется и ONTAP подчищает снэпшоты созданные в других томах.

Автоматическая инкрементальная отказоустойчивость

В FlexGroup включен новый механизм по исправлению ошибок в метаданных. Этот механизм сканирует метаданные и в случае нахождения неконсистентности при обращении клиента, исправляет ошибку, в реальном времени. Без остановки доступа к данным. Вся FlexGroup остаётся доступной и клиенты даже не замечают, что происходит исправление метаданных. Никто бы и не знал об этом, если бы не надоедливые сообщения в EMS-логе для администраторов. Мне кажется, что это немного недооценённая возможность FlexGroups.

Как начать пользоваться FlexGroups?

Сейчас FlexGroups доступны в ONTAP 9.0RC1 (и RC2 — примечание переводчика)
Первый релиз поддерживает следующие функции:

  • только NFSv3 (позже будет NFSv4 и CIFS — примечание переводчика)
  • непродуктивные нагрузки (подразумевается, что техподдержка не будет решать вопросы с FlexGroups — примечание переводчика)
  • снэпшоты
  • перемещение томов-членов FlexGroup (VolMove)
  • 20PB, 400 миллиардов файлов

Для получения лицензии на FlexGroups или дополнительной информации можно писать на flexgroups-info@netapp.com

2016   9   Cluster-Mode   FlexGroups   NAS   NFS   ONTAP   ONTAP 9