У меня есть традиция — каждые полгода я сажусь и пишу пост про то, чего нового в ONTAP. На самом деле нет. Иногда мне лень :)
До конца мая должна стать доступной ONTAP 9.6RC1. Посмотрим, что нас ждёт.

Модель релизов

Для начала поговорим про модель релизов ONTAP. Каждые 6 месяцев происходит выход новой версии 9.x. Эти обновления всегда приносят функциональные изменения. Все исправления багов происходят в P-релизах (9.xPy), которые выпускаются примерно каждые 4 недели. Нечетные версии (9.1, 9.3, 9.5) имеют статус LTS — Long Term Support. Чётные версии такого статуса не имели. С выходом 9.6 эта модель немного меняется. Теперь все версии, начиная с 9.6 будут имёть статус LTS. Считается, что это ускорит распространение новых версий, так как клиенты опасались не-LTS релизов.
По срокам поддержки ONTAP:

• 3 года — Full Support. Поддержка со стороны службы технической поддержки, выход сервисных обновлений.
• 2 года — Limited Support. Прекращается выпуск сервисных обновлений, за исключением исправлений проблем с безопасностью.
• 3 года — Self-service Support. Никакой помощи от вендора, только документация онлайн.

RESTful API и новый OnCommand ONTAP System Manager

В 9.6 появится REST API из коробки без каких-то внешних серверов. Внутри ONTAP давным давно живёт ZAPI, но он слишком развесистый и им не так удобно пользоваться — концептуально он похож на SOAP и передаёт данные в XML. Какое-то время ZAPI и REST API будут сосуществовать, но с 9.6 вся новая функциональность будет получать соответствующие методы только в REST. Например, новые модули для Ansible и WFA уже будут использовать REST API. С выходом 9.6 будет доступен Python SDK, для других языков SDK выпустят позже.
Подробнее про REST API можно почитать в блоге у Justin Parisi.

Поверх REST API будет работать новый ONTAP System Manager, в 9.6 он будет работать в режиме preview. Вносить какие-то изменения через него не получится. В нем обещают сократить количество телодвижений для выполнения привычных задач. Будет доступна статистика по производительности за последний год. В перспективе это отличное решение, так как позволит быстрее добавлять управление новыми фичами ONTAP в System Manager, да и над дизайном проще будет работать.
Все пожелания можно отправлять на [email protected]

OnCommand Unified Manager тоже решили переименовать. В итоге получаем следующее:
OnCommand Unified Manager —> Active IQ Unified Manager
OnCommand System Manager —> ONTAP System Manager

SnapMirror

• Поддержка шифрования при передачи данных по сети (TLS v1.2). Работает для SM (SnapMirror) и SM-S (SnapMirro Sync)
• Добавили NFSv4, SMB 2 и 3. Теперь поддерживаются все протоколы, доступные в ONTAP.
• Добавили поддержку каскадной репликации для SM-S.
• SM-S теперь поддерживает qtree и fpolicy.
• Изменилось лицензирование SM-S. В 9.5 это была отдельная лицензия на ёмкость, теперь эта лицензия входит в Premium Bundle.

Важный нюанс по лицензированию. Если вы не планируете использовать вторую СХД как источник репликации SM-S, то никакие лицензии на этой системе не нужны.

MetroCluster

Наконец-то MetroCluster будет доступен для самых младших систем — AFF A220 и FAS2750. Поддерживается только MetroCluster IP, что логично, так как в этих системах нет слотов для плат с FC-VI портами. Как и в случае со старшими системами для AFF поддерживается ADP, для FAS — нет. И важный момент — для FAS2720 MCC не доступен.

Начиная с 9.6 необязательно иметь выделенные L2 линки между площадками, допускается использовать ISL и для другого трафика.
Поддерживаются ISL со скоростью 10/25/40/100 Gb/sec. Коммутаторы по-прежнему должны быть куплены у NetApp. Скорости 10/25 до этого не поддерживались, но скоро будут доступны новые кластерные коммутаторы BES-53248 с поддержкой 10/25 GbE.

Новые ATTO 7600N FC to SAS Bridge для MCC FC.

Добавили поддержку FlexGroup в MetroCluster.

FlexGroup

Теперь можно переименовывать FlexGroup тома.
Размер FlexGroup можно не только увеличвать, но и уменьшать.
Появилась поддержка SMB Continuous Availability (CA) для MS SQL и Hyper-V.

FlexGroup “под капотом” состоит из множества FlexVol, при записи файлы не разбиваются на части, каждый файл попадает в отдельный FlexVol. В какой FlexVol попадёт файл зависит от нагрузки на агрегат и свободного места в FlexVol. Теоретически возможна ситуация, когда в каком-то из FlexVol места останется меньше, чем в остальных. И при записи крупного файла, места в конкретно этом FlexVol может не хватить. Можно использовать функцию autogrow, чтобы избежать ошибок при записи. Но теперь появилось ещё одно решение для таких ситуаций — FlexGroup Elastic Sizing. Теперь FlexVol, в котором не хватает места для записи файла может “одолжить” это место у других томов. Общий размер FlexGroup не меняется, запись проходит успешно. Как это реализовано внутри ONTAP пока нигде не описано. Важно, что это работает автоматически и незаметно для приложений.
Больше информации есть в блоге у Justin Parisi. И скоро обновится TR-4571. NetApp ONTAP FlexGroup Volumes.

FabricPool

Новые облачные провайдеры для объектного уровня хранения:

• Google Cloud Storage
• Alibaba Cloud Object Storage Service

Политика тиринга backup теперь называется all и позволяет отправлять все данные из тома сразу в облако. На СХД остаются только метаданные. Политика backup поддерживалась только на томах репликах SnapMirror, у all такого ограничения нет.

Inactive Data Reporting теперь работает по-умолчанию. Это опция появилась в 9.4, позволяет посмотреть объем данных, к которым не было никаких обращений за последние 31 день.

Поменялись лимиты на соотношение performance к capacity. Раньше это было жёсткое соотношение 1:20. Теперь всё немного хитрее. Тиринг останавливается, если агрегат заполнен на 98%. И в зависимости от набора данных и количества метаданных требуемого для этих данных, соотношение между performance слоем и capacity слоем может достигать 1 к 50. То есть для 800TB агрегата в облаке может хранится 39.2PB (из расчёт 2% ёмкости агрегата для метаданных).

Улучшения в работе Volume Move. Раньше при перемещении тома выкачивались все данные, которые уже оказались в облаке. Теперь этого не происходит, перемещаются только данные на performance уровне.

Появилась поддержка SVM-DR для FabricPool агрегатов.

Поменялось лицензирование. Теперь FabricPool тоже по подписке. На год или на три года. Тиринг в StorageGRID по-прежнему бесплатно.

FlexCache

FlexCache появился в 9.5, хотя на самом деле это довольно старая функция, которая работала ещё на 7-mode. Надеюсь многие помнят пост на Хабре 8-ми летней давности про, то как NetApp помог с ускорением рендеринга специэффектов в фильме Аватар. Там как раз и использовался FlexCache.
FlexCache позволяет кэшировать файловые данные внутри кластера или на удалённом кластере. Пока поддерживается только NFSv3.

Подробно про FlexCache можно почитать в TR-4743. FlexCache Volumes in NetApp ONTAP. Позже документ обновится с учётом того, что появилось в 9.6
В 9.5 уже была поддержка ONTAP Select как кэша для FlexCache. В 9.6 добавили поддержку Cloud Volumes ONTAP. CVO можно использовать и как кэш, и как источник данных для кэширования. Появляются интересные варианты использования FlexCache:

• Добавили шифрование данных при передаче между источником и кэшем.
• Увеличили лимит на количество кэш-томов до 100 на ноду.
• Добавили поддержку квот и qtree.
• Появилась возможность вносить изменения в уже закешированные файлы на источнике, если произошёл разрыв связи с кэшем.

ONTAP Select

Новый размер — Premium XL. Поддерживает 16 vCPU, 128GB памяти, поддержка NVMe SSD. Обещают удвоение производительности по сравнению с Premium.
Появилась поддержка QoS Minimum.

Еще в 9.5 появилась следующее:

• Возможность конвертации evaluation лицензии в production.
• Плагин для VMware vCenter, который дублирует функциональность Deploy.
• Capacity Pool лицензирование. Общая лицензия на ёмкость без привязки к количеству нод, продаётся на определенный срок (минимум 12 месяцев).

NVMe over FC

• Поддержка 512-byte namespace
• Volume move для namespace
• QoS max для namespace
• Поддержка read-write и read-only в томах с namespace для работы DR

Со стороны ONTAP заявлена поддержка работы с VMware ESXi, Windows и Oracle Linux с ANA (asymmetric namespace access). Теперь ждём подтверждения со стороны производителей этих ОС.

Ах да, лицензия на NVMe/FC теперь бесплатная и входит в Base Bundle.

Шифрование

Не очень актуальная для России функциональность, но как я знаю меня читают не только в России.
NetApp Aggregate Encryption (NAE) шифрование на уровне целого агрегата. На весь агрегат один ключ шифрования. Основное преимущество перед NetApp Volume Encryption (NVE) — более высокая эффективная ёмкость за счет работы дедупликации на уровне агрегата.

Multi-tenant Key Management. Отдельные ключи шифрования на уровне SVM. Работает только с внешними key management серверами. Опция рассчитанная, в первую очередь, на сервис-провайдеров.

А здесь я написал про новую AFF A320.

8 мая NetApp выпустил очередную версию ONTAP и представил несколько новых систем хранения, в том числе первую доступную на рынке end-to-end NVMe all-flash СХД AFF A800. Да я в курсе про Dell EMC PowerMax, о ней мы еще поговорим в посте про A800.
Я решил разделить информацию об ONTAP и новым железе на два поста. Сейчас поговорим про новую версию ONTAP.

Прошло полгода с выхода ONTAP 9.3 и настало время следующей версии. ONTAP 9.4 — это обычный не LTS (Long Term Service) релиз. Подробнее про модель поддержки разных релизов на support-сайте, потребуется логин. Если кратко, то на LTS-релизы патчи выпускаются в течение 3 лет, на обычные релизы — в течение года.

Что нового в 9.4?

Обновления можно разделить на 4 категории:

• Облака
• Безопасность
• FlexGroup
• Общие изменения

Облака

FabricPool теперь работает не только со снепшотами, но и с обычными данными.
Для тех кто не знает, что это, есть пост на Хабре.
SSD до сих пор дорогие, NVMe SSD, кстати еще дороже, SCM тоже никто дёшево продавать не будет, так что варианты удешевления хранения данных на all-flash появляются разные.
До 9.4 в объектное хранилище можно было отправлять данные из снепшотов и из томов-получателей при использовании SnapMirror/Vault, которые по определению неактивные. Теперь эта технология работает и для активных, но холодных данных. Политика для активных данных называется auto. По умолчанию данные отправляются в облако, если к ним не было никаких обращений в течение 31 дня. За это отвечает опция tiering-minimum-cooling-days. Её можно менять в диапазоне от 2 до 63 дней.

Кроме того есть отличия в том, когда блоки из облачного слоя становятся снова горячими.
Политика snapshot-only:
При любом чтении блоков из облачного слоя блок становится горячим и остаётся на SSD.
Политика auto:
Блоки со случайным чтением становятся горячими и остаются на SSD.
Блоки с последовательным чтением остаются холодными и не копируются на SSD.
Политика backup:
При любых операциях блоки остаются холодными.

В качестве облачного/объектного слоя к поддержке AWS и StorageGRID добавилась поддержка Azure Blob Storage. Есть возможность использоваться любые другие приватные или публичные объектные хранилища, но делать это можно только после подтверждения со стороны NetApp.

FabricPool с самого начала работал на ONTAP Cloud. При чем там возможен тиринг между HDD и S3 (st1 и S3). Теперь поддерживается FabricPool и на ONTAP Select. И в качестве performance слоя можно использовать HDD, но рекомендуется все же SSD.

Самое время напомнить какие системы и в каких конфигурациях вообще поддерживают FabricPool.
FabricPool работает на уровне агрегата. К агрегату добавляется capacity слой. Внутри агрегата для каждого тома в отдельности применяются политики или не применяются.
Поддерживаются AFF, all-SSD агрегаты на FAS, ONTAP Cloud и ONTAP Select.
Не поддерживаются Flash Pool и HDD агрегаты на FAS. Не поддерживается MetroCluster.

Отсоединить capacity слой от агрегата можно только разрушив последний. Поэтому очень полезно появление в Object Store Profiler’а. Функциональность в ONTAP, которая позволяет проверить latency и throughput до облачного слоя перед тем, как присоединять его к агрегату.
Вызывается командами storage aggregate object-store profiler start в advanced режиме.

Произошли изменения и в дефрагментации облачного слоя. Прежде чем отправлять холодные блоки в облако они собираются в единый 4МБ объект. Из облака блоки могут читаться объектами от 4КБ до 1МБ. До версии 9.4 4МБ объект удалялся из облака только, если все его блоки становились горячими. Теперь это поведение изменено. Можно менять порог количества блоков без ссылок, при котором начинается дефрагментация 4МБ объекта. За это отвечает опция -unreclaimed-space-threshold в команде storage aggregate object-store modify. Например, если это значение равно 20%, то дефрагментация объекта начнётся, когда 80% данных из этого объекта переедут назад в performance слой. Изменяя значение опции, можно соблюсти баланс между затратами на хранение объектов и тратами за обращение к объектам при дефрагментации. Напомню, что у AWS и Azure есть плата не только за хранение объектов, но  и за операции с ними. Значения по умолчанию для разных типов capacity слоя отличаются:

• 15% Azure Blob Storage
• 20% Amazon S3
• 40% StorageGRID

Теперь в capacity слое сохраняется выгода от inline data compaction, вдобавок к дедупликации и компрессии.

При использовании FabricPool со StorageGRID необходимо устанавливать в ONTAP сертификаты для шифрования управляющего трафика и запросов к API. Теперь необходимость наличия сертификатов можно отключать в тестовых целях.

Безопасность

Очень много изменений с точки зрения безопасности. Часть из них связана с шифрованием и на территории России и некоторых других стран СНГ работать не будет.

Первая функция под названием Secure Purge. Необходима для соответствия требованиям GDPR. Она позволяет “криптографически” удалять файлы из томов зашифрованных с помощью NVE (NetApp Volume Encryption). Пока нет подробной информации по работе этой функции и я могу только догадываться о том, как всё устроено. Упоминается, что файл невозможно будет восстановить, так как ключ шифрования будет удален. В NVE используется отдельный ключ шифрования для каждого FlexVol. Думаю, что том будет заново шифроваться с новым ключом, исключая удаляемый файл.

Protected Controller Reboot — для систем, которые используют Onboard Key Manager (OKM) можно включить требование пароля для загрузки системы. Если пароль не ввести, то в случае с NSE (NetApp Storage Encryption, использование SED дисков) система просто не загрузится, а с NVE тома будут в оффлайне. Защищает на тот случай, если у вас украли сразу весь массив ;-)

Хранение данных OKM на внешнем USB-носителе. Без USB-носителя система с NSE не загрузится, NVE — тома останутся в оффлайне. Для работы ONTAP USB-носитель уже не нужен. Функция доступна только после подтверждения от вендора, так как используется какой-то механизм для защиты от клонирования USB-носителей и не все его поддерживают.

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

Для новых платформ будет поддерживаться UEFI Secure Boot, то есть образ ONTAP будет проверятся во время каждый загрузки. Говорят в полях встречали системы с хакнутыми образами ОС, теперь так не получится. Для работы UEFI Secure Boot не нужен TPM-модуль.

FlexGroup

Более 120ПБ данных уже хранят клиенты NetApp с использованием FlexGroup. Про них я рассказывал в этом посте. С тех пор прошло много времени и функциональность FlexGroup сильно продвинулась вперед. Сейчас поддерживаются NFS 3, SMB 2, SMB 3. В 9.3 добавили поддержку Qtree, SnapVault, Unified SnapMirror (XDP), QoS Max.
В 9.4 добавили следующее:

• Поддержку FPolicy и аудита
• Адаптивный QoS aka A-QoS. QoS-политики, которые работают со значениями IOPS/TB и динамически меняют потолок для файла/тома с изменением его размера.
• QoS Min. Такие политики работают только на AFF.
• Увеличили лимиты для SnapMirror.

Подробнее про FlexGroup можно почитать в TR-4571. NetApp FlexGroup Volume Best Practices and Implementation Guide.

Кстати, с использованием FlexGroups был показан отличный результат в тесте SPEC SFS2014.

Общие изменения

Тут всё такое “вкусное”, что даже не знаю с чего начать.

Улучшили работу дедупликации:

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

Появилась поддержка SMB Multichannel:
Обещают до 90% повышения производительность на high-end системах. Всё за счёт более эффективного использования ядер, утилизации сетевых карт и использования множества TCP/IP сессий.

Fast Drive Zeroing — моментальный zeroing дисков вне зависимости от их типа и размера. Но есть нюансы:

• Работает только на свежих инсталляциях 9.4 или на системах, которые были реинициализированы с 9.4.
• Такую систему нельзя даунгрейдить до 9.3 и ниже.

В OnCommand System Manager добавили поддержку Application Aware Data Management (AppDM) для MS SQL. Это те самые мастера в разделе Applications & Tiers в меню слева. И теперь работать с ними можно через REST API.

Каждый FlexVol теперь поддерживает 1023 снепшота.

Для текущих систем стали доступны 30TB SSD.

Ну и пожалуй самое главное изменение — для обновления ONTAP теперь не нужен ftp или web-сервер, образ можно загружать сразу в браузере.

На этом всё про ONTAP 9.4. Готов ответить на вопросы в комментариях или в нашем уютном телеграм-чате — https://t.me/storagediscussions
А для получения оперативных новостей про NetApp и просто интересные ссылки подписывайтесь на канал https://t.me/storagetalks

Во время ежегодной конференции для партнёров и заказчиков 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

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

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

В конце июня стала доступна новая версия 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 или дополнительной информации можно писать на [email protected]