about NetApp

Автор блога NTAPgeek расспросил Ника Триантоса, одного из ведущих инженеров NetApp, по поводу All-Flash FAS систем, стоящих за ними технических решений, и чем AFF отличается от других flash-стораджей, в том числе и тех, что производит сам NetApp, например уже известного вам EF550.

Ник говорит:

“Наибольшая проблема для нас была не в том, как WAFL пишет; на деле это как раз большой плюс архитектуры. Основные проблемы и задачи при разработке были:

Оптимизация под многоядерные процессоры – Долгое время Data ONTAP не умела эффективно использовать многоядерность процессоров. Проект по проведению оптимизации под многоядерность стартовал с версии 7.3 и продолжался вплоть до релиза Data ONTAP 8. Я уверен, что вам доводилось видеть ситуацию, когда один CPU работает с загрузкой 90% и другой - на 20%! Если нагрузка упирается на уровне ONTAP domain, который должен выплняться на одном единственном ядре, то возникает узкое место для роста производительности. ?? при этом неважно, что другие ядра были недозагружены. Эта задача была, в итоге, решена.

Управление метаданными – Когда вы используете маленькие блоки данных, например у NetApp это 4K, то при этом вы получаете множество метаданых, которыми нужно управлять. Для того, чтобы получить максимально быстрый доступ к даным, вам нужно сперва максимально быстро получить доступ к их метаданным. А где быстрее всего доступ к метаданым? В оперативной памяти. Вот почему мы используем так много оперативной памяти на контроллерах серий FAS2500 и FAS8000; мы стараемся как можно больше метаданных при работе держать в быстрой памяти контроллера.

Защита данных – Это связано с темой выше. Системы AFF имеют больше возможностей по защите данных, чем любая другая система c flash (и, кстати, не только flash) на сегодняшнем рынке. Хотя это и полезная штука, есть определенные недостатки. Недостатки состоят в более динных путях ввода-вывода, так как метаданные размещаются и валидируются отдельно от блоков данных.
Как вы защищаетесь от lost writes? Что случится, если вы торговая компания, и на вашей системе хранения SSD сказал, что данные записаны, а на деле он их не записал, или записал не так или не туда? Вы рискуете огромными финансовыми потерями. Data ONTAP не только обнаруживает такие ситуации, но и защищает, а также помогает восстановить данные, испорченые в результате lost writes (это крайне коварная проблема).”

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

Другими словами, хорошая скорость работы и устойчивость к отказам сразу двух дисков – недостаточны для того, чтобы считать, что ваши данные надежно защишены. В особенности, когда flash-хранилища используются для бизнес-критичных приложений. Вам следует проанализировать возможные ситуации отказов, и убедиться, что ваше хранилище устойчиво к ним, а данные - защищены. Более 20 лет мы совершенствеум и развиваем Data ONTAP, и достигли в ней очень высокого уровня надежности и устойчивости против всех видов отказов и различных их комбинаций.”

Напомним, бандлы NetApp AFF имеют:

1. Больше памяти
   Больший объем кэша чтения-записи в FAS8000, что позволяет держать в нем больше метаданных
2. Более быстрый NVRAM
   Быстрее отрабатываются ACK, как следствие – ниже отклик и задержки
3. Значительно оптимизированную многоядерную эффективность OS
   Проводилась начиная с Data ONTAP 7.3
4. Continuous Segment Size Cleaning (CSS)
   Переменный размер сегмента Data ONTAP  (4K-256K)
5. ??нтеллектуальные алгоритмы упреждающего чтения, определяющие типовые паттерны операций:
   • Последовательное чтение с тем же (например 32k) и различными размерами блоков (4k,64k,4k,64k)
   • Скачущее (strided) чтение: Начнем с блока N и прочитаем, считая с него, блоки 10 и 12, но пропустим блок 11
   • Обратное чтение: Начнем с блока N, и прочитаем –10 блоков, считая от него
   • Несколько потоков чтения, читающих из разных точек

Бандлы NetApp AFF доступны к заказу с 23 июня 2014 года.

Мне в очередной раз на хвосте мышко притащила свежие слухи о ближайшем будущем этой темы.

Во первых, многие заметили, произошел отказ от аббревиатуры A-SIS, в пользу более понятного NetApp Dedupe и просто Deduplication. Шаг естественный. Немногие сходу вспомнят, что A-SIS это Advanced Single Instance Store, еще меньше - поймут о чем речь. Переход от “инженерной” аббревиатуры к “самоописывающему” названию есть вполне правильный путь.

Во вторых, проект “Дедупликация” скоро будет иметь две ветви: FAS Deduplication (ныне существует), и VTL Deduplication, ожидаемый давно, и обещаемый в первом ограниченно доступном для клиентов виде в конце этого года (сейчас она проходит ограниченное бета-тестирование).
Казалось бы, что за труд внедрить уже работающую технологию на параллельной линейке той же компании? Однако же как оказалось не все так просто. По сути под названием VTL Deduplication мы будем иметь некий принципиально новый продукт.
Не зря официальные лица так настойчиво повторяли весь год про “backup-oriented” и “stream optimized”.

Прежде всего, это действительно, в отличие от FAS Deduplication, ориентированного более на General Purpose применение, будет специализированное решение для дискового бэкапа, специально для этого заточенное. Причем заточенное настолько, что, как у меня сложилось впечатление, это будет принципиально иной по своему “коду” продукт под уже “раскрученным” названием. В пользу этого говорит и то, насколько долго с ним возятся.

Так, например, в VTL Dedupe, кроме уже известного режима post-process, который сохранился, добавится и некий inline. То есть система будет пытаться проводить дедупликацию в том числе и непосредственно “в онлайне”, в процессе поступления данных на диски, аналогично online compression.

Практический кейс: У меня есть 100 идентичных образов виртуальных машин по 1GB каждая (ну например 100 установленных Windows XP, отличающихся только несколькими байтами hostname). Я бэкаплю их на диски NetApp со включенной дедупликацией. Сколько понадобится выделить под это места? Нет, не 1GB. Даже несмотря на дедупликацию сперва нам нужно будет все 100GB, а затем 99GB нам вернутся, когда система завершит цикл дедупликации, происходящий в постпроцессе, в “оффлайне”.
В случае VTL Dedupe скорее всего какая-то часть дедупликации пройдет уже в процессе записи.

Второй момент, натолкнувший меня на мысль о принципиально ином продукте, был сведениями о том, что VTL Dedupe будет оперировать переменными размерами блока.

Напомню вкратце принцип работы FAS Deduplication.
Система хранения NetApp FAS устроена таким образом, что для каждого блока данных WAFL “внутри системы” вычисляется и хранится некая хэш-строка. Она довольно давно используется для дополнительного контроля целостности данных при их обработке в системе. Как я понимаю, для дедупликации просто воспользовались уже существующей в системе возможностью. Следствием стало то, что включение дедупликации как таковой, почти никак не затрагивает производительность самой системы. Ведь система и так уже эту функцию имела, добавился только некий процесс с существующими данными, осуществляемый в фоне, с низким приоритетом. Это позволило использовать дедупликацию в том числе и для систем хранения “общего применения”, что на сегодня не предлагает ни один из конкурентов.

??так, каждый 4kb-блок WAFL сопровождается хэш-строкой, идентифицирующей, с той или иной степенью достоверности, его уникальность. Если мы находим два идентичных хэша, то мы можем предположить, что соответствующие им блоки данных также иденичны. Для того, чтобы избежать так называемой “hash collision”, когда по какой-то причине один и тот же хэш соответствует разным блокам, такое возможно при не слишком сложном алгоритме вычисления хэша (который применяется в NetApp, дабы не грузить излишне систему) система проводит для таких блоков “контрольную проверку” путем простого побайтного сравнения этих 4kb-блоков. Если блоки действительно совпали, то один из них освобождается, а в таблице размещения указатель на него переставляется на оставшийся.

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

Это является основной причиной иногда наблюдаемой на практике невысокой эффективности дедупликации. Так, например, в случае VMFS-файлов VMware, обычно строго выровненных относительно границы блока, эффективность дедупликации будет высока. Однако, например, файлы резервных копий, создаваемых системами резервного копирования, часто имеют внутри себя то или иное смещение, при том, что физически содержимое их может быть и идентично.
??льдар, похоже это вот как раз твой случай.

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

Однако, как и в случае с FAS Deduplication, NetApp сохранил очень приятную для нас, “конечников”, модель с бесплатной лицензией. То есть лицензия-то все равно есть, и для включения дедупликации она все равно нужна, но она бесплатна. Нужно ее только заказать через вашего партнера. То есть ситуация как с лицензией для iSCSI. Она есть, но она бесплатна.

?? еще несколько слов в заключение. Уважаемые ребята из московского представительства: Роман, Роман, Саша :). Я знаю, что вы меня читаете ;) Бога ради, если вы считаете, что я вдруг опять ненароком тут засветил какую-то Страшно Охраняемую Военную Тайну, которую Рано Показывать Публике - свяжитесь со мной, что-нибудь придумаем, исключительно из соображений доброй воли. Угум?