Yet Another Blog about NetApp

Блог о технологиях NetApp и системах хранения данных в целом

Ctrl + ↑ Позднее

Сайзинг Flash Pool

Попробуем разобраться как подобрать нужное количество SSD-кэша для систем NetApp. Эти советы подойдут тем, у кого уже используется NetApp или есть возможность взять систему в тест. Даже демо-система без SSD дисков, позволит понять насколько эффективно будет работать кэш с вашими данными.

К сожалению, универсального ответа на вопрос «Как понять процент “горячих” данных?» без тестирования на реальном оборудовании у меня нет. Если кто-то поделится таким рецептом для каких-либо приложений, буду рад.

Как понять насколько эффективно работает Flash Pool в текущей конфигурации? Какая ёмкость SSD-кэша в Flash Pool будет оптимальной, если вы только собираетесь добавлять кэш к обычному агрегату?

Поговорим про AWA — Automated Workload Analyzer. Инструмент, который помогает получить ответы на эти вопросы.

Некоторую статистику по работе FlashPool можно увидеть в OnCommand System Manager. Но она не особо информативна и, например, не позволяет понять какие тома больше используют кэш, а каким он в принципе не нужен.

Куда больше информации можно получить, запустив AWA. Это часть ONTAP. Появилась эта функциональность в Data ONTAP 8.2.1 и доступна для 7-mode и cluster-mode. AWA собирает и анализирует статистику по определенному агрегату. На основе собранных данных рекомендует оптимальный размер SSD-кэша, показывает предполагаемые показатели cache hit rate для рекомендуемой ёмкости Flash Pool и аналогичные показатели при меньшем размере кэша. С выходом Data ONTAP 8.3.1 можно посмотреть информацию в разрезе томов на агрегате.

AWA — это по сути 3 node-shell команды:

- wafl awa start
- wafl awa print
- wafl awa stop

Вот как это выглядит на практике (вывод можно копировать):

Последовательность действий следующая. Сначала мы запускам AWA для агрегата. Ждём 24 часа, а ещё лучше несколько дней. Останавливаем работу AWA. Желательно, чтобы в период работы AWA на СХД была типичная нагрузка. В процессе можно смотреть результаты работы, используя wafl awa print. Можно запускать анализ сразу нескольких агрегатов одновременно. Максимально работа AWA “отъест” 2% CPU, независимо от количества анализируемых агрегатов и не более 0.2% от кэша контроллера на каждый агрегат.

Для просмотра информации по томам используется опция -t. Если добавить после неё число n, то выведется информация по n самым нагруженным томам.

AWA можно запускать на агрегатах, где уже используется Flash Pool.

Само собой, результат работы AWA, показанный выше далёк от того, что можно увидеть в реальной жизни. Я запускал это на симуляторе.

Вот например, как выглядят результаты работы AWA на «боевой» системе после сбора статистики в течение 2 недель. Это FAS8040 у клиента, который предоставляет облачные услуги.

### FP AWA Stats ###

                     Host NA-Store-A                    Memory 28342 MB
            ONTAP Version NetApp Release 8.2.1 Cluster-Mode: Fri Mar 21 14:48:58 PDT 2014
              AWA Version 1
           Layout Version 1
               CM Version 1

Basic Information

                Aggregate aggr_SAS
             Current-time Fri May 13 15:14:56 FET 2016
               Start-time Fri Apr 29 00:21:37 FET 2016
      Total runtime (sec) 1263213
    Interval length (sec) 600
          Total intervals 2111
        In-core Intervals 1024

Summary of the past 1023 intervals
                                   max
          Read Throughput      247.095 MB/s
         Write Throughput      274.819 MB/s
       Cacheable Read (%)       78.298 %
      Cacheable Write (%)       35.510 %
 Max Projected Cache Size     5888.973 GB
   Projected Read Offload       60.000 %
  Projected Write Offload       28.000 %

Summary Cache Hit Rate vs. Cache Size

       Size        20%        40%        60%        80%       100%
   Read Hit     46.000     52.000     55.000     59.000     60.000
  Write Hit     26.000     26.000     26.000     26.000     28.000

The entire results and output of Automated Workload Analyzer (AWA) are
estimates. The format, syntax, CLI, results and output of AWA may
change in future Data ONTAP releases. AWA reports the projected cache
size in capacity. It does not make recommendations regarding the
number of data SSDs required. Please follow the guidelines for
configuring and deploying Flash Pool; that are provided in tools and
collateral documents. These include verifying the platform cache size
maximums and minimum number and maximum number of data SSDs.

### FP AWA Stats End ###

Что мы можем понять из этого вывода?

  • Read throughput and write throughput: Это максимальные показатели throughput из всех 10-минутных интервалов. Учитывается случайная и последовательная нагрузки.
  • Cacheable read and cacheable write: Это показатели из интервала, который имеет максимальные значения cache hit. Причём это может быть интервал отличный от интервала из предыдущего пункта. Flash Pool кэширует все случайные операции чтения на агрегате, то есть Cacheable Read (%) это процент случайного чтения с агрегата. Значение Cacheable Write (%) показывает операции записи, которые могут попасть в Flash Pool при использовании политики по-умолчанию “random-write” (это случайные операции перезаписи). Вообще про работу Flash Pool и доступные политики я сделаю отдельный пост. Когда-нибудь.
  • Max projected cache size: Это то, ради чего и запускается AWA — рекомендуемый размер кэша для агрегата. Чем дольше работал AWA, тем выше это значение может быть.
  • Summary cache hit rate vs. cache size: Это таблица показывает показатели cache hit при использовании меньшего объема кэша, чем указано в Max projected cache size. Иногда на значение Max projected cache size может влиять нетипичная нагрузка в течение некоторых интервалов. И в таблице можно будет увидеть, что меньшее количество кэша может дать такую же выгоду.

Рекомендую не забывать использовать AWA с новыми только настраиваемыми системами с SSD под Flash Pool. NetApp не даёт возможности удалить диски из агрегатов, в том числе используемые для кэша, без разрушения агрегата. Поэтому, чтобы в будущем не было “мучительно больно” из-за неправильного распределения кэша, лучше разбить диски по агрегатам, а добавление кэша отложить. В течение пары недель собрать статистику с помощью AWA, и на основе этой информации оптимально сконфигурировать Flash Pool.

AWA можно использовать и для сайзинга Flash Cache. Для этого надо обращать внимание только на показатели связанные с чтением, так как Flash Cache работает только как кэш на чтение.





2016   AWA   Flash Cache   Flash Pool   SSD   tutorial

NetApp Innovation Russia 2016

8 ноября состоится ежегодная конференция NetApp для клиентов и партнёров.
Расскажут про новую линейку оборудования, про интеграцию с актуальными технологиями на рынке — OpenStack, контейнеры. Будут демонстрации и примеры решения реальных задач у заказчиков. Например, обновление систем без миграции данных с помощью Copy-Free Transition, резервное восстановление с помощью Microsoft Azure Site Recovery.
Ну и самое главное, ради чего стоит посещать такие мероприятия — живое общение.

Доступная на данный момент программа.

Регистрация

2016   Innovation   netapp   Russia

Новые системы NetApp под управлением ONTAP 9.1

Во время ежегодной конференции для партнёров и заказчиков NetApp Insight было объявлено о выходе новых систем хранения данных, работающих под управлением операционной системы ONTAP. Обновились системы FAS и AFF.

Вместе с выходом нового оборудования будет доступна новая версия ONTAP — 9.1.
Для начала разберёмся, что же нового в железе.

FAS. Всем FlashCache. Первые СХД с 40GbE и 32Gb FC.

Начнём с обновления гибридных массивов FAS. Выходит 4 новые модели: FAS2620, FAS2650 — системы начального уровня, FAS8200 — система среднего уровня для корпоративных заказчиков и FAS9000 — high-end система с абсолютно новым (для NetApp) подходом в построении шасси.

Новые системы стали существенно производительнее:

  • Используются новые процессоры Intel на архитектуре Broadwell
  • Доступно больше кэша и NVRAM
  • NVMe FlashCache
  • В старших контроллерах доступны интерфейсы 40GbE и 32Gb FC
  • Для подключения дисков используется SAS-3 12Gb

Как видно, моделей стало меньше, что вполне логично при возможности горизонтального масштабирования. Клиенты, которым будет не хватать FAS8200, а FAS9000 покажется слишком производительной, могут брать 4-контроллерные кластеры из FAS8200.

FAS2600

Теперь в младшей линейке две модели. FAS2620 заменяет FAS2554, а FAS2650 — FAS2552. Модели аналогичной урезанной в функциональности FAS2520 теперь нет. И это вполне логично, в моей практике эти модели продавались очень редко.

FAS2620 и FAS2650, как и прошлое поколение, используют одинаковые контроллеры. Отличаются только шасси. В первом случае это шасси на 24 SAS или SSD дисков. А FAS2620 имеет шасси на 12 дисков SATA или SSD.

Обе эти системы конвертируются в дисковые полки для подключения к новым контроллерам в случае апгрейда на старшие модели. Только полки теперь DS224C и DS212C. Это полки с 12Gb SAS интерфейсом. Принцип наименования остался прежний — Disk Shelf, количество юнитов, количество дисков и скорость интерфейса. C — 12 в hex. При желании новые полки можно подключить к текущим контроллерам FAS8000. Надо всего лишь приобрести соответствующий SAS HBA. В новых полках ACP не требует отдельных портов и работает внутри SAS.

Новые системы обещают быть в 3 раза быстрее поколения FAS2500:

  • 2 шестиядерных процессора на основе микроархитектуры Intel Broadwell
  • 64GB DDR4 памяти
  • 8GB NVRAM
  • 1TB NVMe M.2 FlashCache

Да-да-да! FlashCache на младших моделях, еще и NVMe, и в базовой конфигурации.
Увеличились максимальные лимиты на общее количество кэша на контроллерах на основе FlashPool и FlashCache до 24TiB.

Вот как выглядят технические характеристики новых контроллеров в сравнении с текущим поколением:

Вид контроллеров сзади:

Какие порты для чего используются:

Наконец-то, есть выделенные 10GbE порты для кластерного интерконекта. И нет необходимости чем-то жертвовать для получения конфигурации iSCSI/NFS/CIFS/FCoE + FC.

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

Из нюансов: FAS2620 не будет доступна в конфигурации all-SSD. Необходимо иметь минимум 8 SATA дисков. FAS2650 таких ограничений не имеет.

FAS8200

FAS8200 пришла на замену сразу двум моделям текущего поколения — FAS8020 и FAS8040. Пара контроллеров FAS8200 находится в одном корпусе и занимает всего 3U. Дисков в этом шасси нет.
Обещают прирост производительности по сравнению в FAS8040 около 50%:

  • В 2 раза больше ядер
  • В 4 раза больше памяти
  • 2 TiB NVMe FlashCache в базе с возможностью расширения до 4TiB
    Характеристики FAS8200 в сравнении с FAS8040:

Так контроллеры выглядят сзади:

Подробнее про порты:

И что же мы имеем? Контроллеры мощнее и занимают меньше места. В контроллерах меньше слотов расширения и они поддерживают меньше дисков. Но всё не так плохо.

Разберёмся сначала с дисками.
По статистике более 80% продаж FAS8040 идут с менее чем 150 дисками, то есть реальной необходимости в поддержке 720 дисков у целевой аудитории FAS8200 нет. Если лимит в 480 дисков кого-то беспкоит, то всегда можно добавить в кластер еще пару контроллеров и максимальное количество дисков увеличится до 960.

Что же делать с меньшим количеством слотов расширения? Слоты расширения в 8040 часто используются под FlashCache, который в FAS8200 теперь на материнской плате и слоты под него не нужны. Дополнительные слоты нужны при построении MetroCluster для плат FC-VI, через которые происходит зеркалирование NVRAM на удалённую площадку. Теперь для этих целей можно использовать уже имеющиеся на контроллере порты UTA2. Дисков поддерживается 480, так что нет необходимости занимать слоты SAS HBA картами.

Получается слоты нужны только для портов Ethernet или FC, если базовых портов на контроллере не хватает. И тут мы вспоминаем, что теперь в ONTAP 9.1 NetApp поддерживает использование портов 40GbE и 32Gb FC. Порты 40GbE могут использоваться в качестве 4 по 10GbE.

40GbE порты поддерживаются только в новых контроллерах, а карты 32Gb FC будут доступны и для текущего поколения FAS/AFF.

FAS9000

Ну а теперь поговорим про монстра, который пришёл на замену FAS8060 и FAS8080 EX.

В текущем поколении вся линейка FAS80x0 делит одну архитектуру шасси. В FAS9000 применили новый подход, который упрощает обслуживание и расширение.

Но начнём с технических характеристик и сравнения с FAS8080 EX.
Прирост производительности по сравнению с FAS8080 EX 50% за счёт:

  • 72 ядер — 4 процессора по 18 ядер
  • 1024GB DDR4 памяти — в 4 раза больше
  • В два раза больше NVRAM
  • 2TiB NVMe FlashCache, расширение до 16TiB
  • Зеркалирование NVRAM с пропускной способностью в 80Gb/sec

Таблица сравнения с FAS8080 EX:

Ну а теперь самое интересное — вид сзади:

Новый модульный дизайн. Контроллеры не имеют клиентских портов. Контроллеры и модули расширения поддерживают горячую замену. Благодаря тому, что модули расширения теперь “живут” отдельно от контроллера, при их замене нет необходимости производить failover и нет сложностей с кабелями из других модулей. И самое интересное, что это шасси позволяет в будущем заменить контроллеры FAS9000 на новые.

Несмотря на меньшее количество слотов и отсутствие портов на самих контроллерах, масштабируемость по подключению клиентов не страдает. FlashCache использует отдельные слоты. Поддерживаются порты 40GbE и 32Gb FC. Кстати, для кластерного интерконекта теперь используются 40GbE порты.

AFF A300 и  AFF A700

Разобрались с FAS, переходим к all-flash системам.

All-flash моделей теперь две и они немного поменяли способ именования.

Самые догадливые конечно поняли, что для AFF систем используется та же самая железная платформа, что и для FAS8200 и FAS9000. Поэтому подробно расписывать технические характеристики я не буду, остановлюсь только на некоторых из них.

  • A300 даёт на 50% больше производительности при задержках 1мс, чем AFF8040
  • Поддерживает до 384 SSD
  • Доступны SSD 15.3TB, 3.8TB и 960GB
AFF A300 AFF A300
  • A700 выдаёт в два раза больше производительности, при задержках в два раза ниже, чем AFF8080
  • Поддерживает до 480 SSD
  • Доступны SSD 15.3TB, 3.8TB и 960GB
AFF A700 AFF A700

Ну и конечно обе модели поддерживают интерфейсы 40GbE, 32Gb FC.

А теперь поговорим немного про производительность.

Такого прогресса не достичь простым обновлением железной платформы. С выходом ONTAP 9.1 NetApp первым начал начал поддерживать технологию Multi-Stream Write для SSD. Изначально эту технологию разработали в Sаmsung. В конце 2015 эта технология стала частью стандарта T10 SCSI. Она также будет в стандарте NVMe.

Multi-stream write (MSW) SSD

Что это за технология?
Для начала немного общеизвестной информации.
Всем известно, что запись на SSD сильно отличается от записи на HDD. SSD по сути не имеет такой операции как перезапись. При изменение каких-то данных необходимо стереть старые данные и заново записать измененные данные. Проблема в том, что чтение и запись в пустое место происходит с гранулярностью страницы, а вот при удалении необходимо стирать блок, который состоит из нескольких страниц. Это всем известные P/E циклы (Program/Erase). Всё это ведёт к уменьшению срока службы SSD и снижению производительности при заполнении диска.

Срок службы снижается, так как NAND-ячейки рассчитаны на определенное количество P/E циклов. Что касается производительности, контроллер SSD старается писать изменении данных в пустые страницы. Периодически для очистки блоков с устаревшими данными запускается Garbage Collector, который освобождает блоки. Пока есть свободные страницы для записи новых и измененных данных, GC работает в фоне и особо не влияет на производительность. Но при достижении определенной степени наполненности диска, GC начинает работать более активно, и производительность SSD на запись существенно снижается. SSD приходится производить больше операций, чем на него приходит со стороны хоста. Это называется write amplification. На графике производительности SSD виден типичный write cliff.

В Samsung решили классифицировать данные, которые идут со стороны хоста. Данные ассоциируются с определенным потоком. В один поток попадают данные, которые с высокой вероятностью будут одновременно изменяться или удаляться. Данные из разных потоков пишутся в разные блоки на SSD.

Такой подход позволяет увеличить долговечность SSD, повышает производительность и обеспечивает стабильные задержки.
По внутренним тестам Samsung технология multi-stream write вполовину снижает write amplification, endurance вырастает до 3 раз, задержки в большинстве случаев снижаются на 50%.

Всё это теперь доступно в AFF системах NetApp с ONTAP 9.1.

Подробнее о Multi-stream SSD:
Презентация “The Multi-streamed Solid State Drive” — Jeong-Uk Kang, Jeeseok Hyun, Hyunjoo Maeng, and Sangyeun Cho

Доклад USENIX “The Multi-streamed Solid-State Drive” — Jeong-Uk Kang, Jeeseok Hyun, Hyunjoo Maeng, and Sangyeun Cho

Презентация “Multi-Stream Write SSD Increasing SSD Performance and Lifetime with Multi-Stream Write Technology” — Changho Choi, PhD

ONTAP 9.1

Что еще нового в следующей версии ONTAP?
Поддержка FlexGroups. Это масштабируемые файловые контейнеры, которые могут хранить до 20PB и 400 млрд файлов. Одна FlexGroup может располагаться на нескольких контроллерах в кластере, при этом при записи файлов кластер автоматически балансирует нагрузку. Подробнее про FlexGroups.

Поддержка шифрования данных без специальных self-encrypting дисков и внешних менеджеров ключей. NetApp Volume Encryption (NVE). Шифрование происходит на уровне тома. То есть можно выбирать какие тома шифровать, а какие нет. Для каждого тома используется отдельный ключ шифрования. Шифрование происходить в программном модуле встроенном в ONTAP, используются hardware acceleration на уровне процессоров Intel. При этом сохраняется польза от всех технологий эффективности NetApp. WAFL отрабатывает до того как данные будут зашифрованы.

Поддерживается работа в MetroCluster. Есть возможность реплицировать данные из незашифрованных томов на другую систему в шифрованные тома. Поддерживается ONTAP Select. А параноики могут использовать два способа шифрования: NVE и шифрование на уровне NSE дисков.
К сожалению, это всё будет недоступно в России. Будет использоваться два разных образа ONTAP — с поддержкой NVE и без.

ONTAP Select теперь поддерживает конфигурации all-flash.

А ONTAP Cloud официально заработал в MS Azure.

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




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
Ctrl + ↓ Ранее