Флеш-массив EMC XtremIO: коротко о главном

Про флеш-массивы писать дело неблагодарное, этого не делал еще только ленивый. Но все-таки мы решили рискнуть и написать о нашем массиве XtremIO, потому что он действительно выделяется. И расскажем не надоевшие маркетинговые истории на тему флеш-массивов, а интересные подробности по технической части.

Введение

Флеш-массивы (обычно этим словом называют СХД, в которые нельзя поставить ничего, кроме флешек) сейчас тема популярная. Про них пишут много, но зачастую упирают лишь на производительность (время отклика и IOPS). А ведь это лишь одна сторона медали. Вообще, мало кому действительно необходимы сотни тысяч IOPS. И мы разрабатывали с нуля наш XtremIO не ради лабораторных IOPS (ну ладно, не только ради них), здесь-то как раз все довольно просто. У нас все намного интереснее. Мы старались сделать самый-самый флеш-массив, в котором бы использовались технологические особенности флеш-памяти, позволяющие организовать новую, недоступную ранее функциональность и модель использования массива.

Исторический контекст

XtremIO — устройство новое, идея его создания появилась в 2009 году. Как тогда выглядел рынок флеш-массивов? С одной стороны, всем стало окончательно ясно, что будущее за флеш-памятью, и ей нужно заниматься. На рынке присутствовали компании «первой волны», которые делали ставку на флеш-модули и контроллеры собственной разработки. Одновременно начало вырисовываться понимание, что и рынок требует, и технологии позволяют сделать кое-что поинтереснее, чем просто быстрые и примитивные хранилища. Необходимо было предложить более универсальные системы, но тут нужна и дедупликация, и продвинутая функциональность, и так далее. А в таком случае на «железке» с RAID далеко не уедешь. Так и родилась идея флеш-массива, приведшая к созданию XtremIO.

Какие особенности ему присущи:

• Построен на x86 и SSD, вся магия в софте;
• Все вендоры любят говорить «разработан для флеш», но за этим скрываются разные вещи. Бывает, что и просто существующий массив переименовывают. У нас много ноу-хау, которые без флеш просто невозможны (схема размещения данных, работа с метаданными), подробнее об этом — ниже;
• Простота;
• Дедупликация и другие дата-сервисы.

Разберем это поподробнее.

Железо

Базовый блок состоит из двух контроллеров (фактически это серверы стандартной архитектуры), полки с SSD и батарей UPS.

На первый взгляд, странная конструкция. Но, помимо стандартизации, за таким дизайном стоит четкая логика. В сервере можно обеспечить большой объем памяти (256 или 512 Гб) и два многоядерных процессора с немаленьким теплопакетом. Что не всегда возможно в своем конструктиве.

UPS применен потому, что NVRAM проигрывает оперативной памяти по времени доступа, а, как мы увидим далее, для нас это критично. В итоге получилась максимально унифицированная конструкция с огромным объемом быстрой памяти и кучей ядер. И для нового поколения достаточно взять новые серверы, где будет еще больше памяти и ядер — в этом заключается прелесть стандартной платформы.

Такие кубики из двух контроллеров и полки с SSD называются X-Bricks, и могут соединяться друг с другом по Infiniband и формировать кластер (от 1 до 6 «бриков» с линейным ростом производительности). Об этом мы сейчас и поговорим.

Scale-Out

Изначально XtremIO рассчитан на кластерную (Scale-Out) архитектуру. Что это значит? В массиве может быть много контроллеров, все они равноправные и обеспечивают доступ к одному и тому же пулу данных. При этом нагрузка автоматически равномерно распределяется между ними.

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

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

Очень упрощенно «зоны ответственности» модулей можно описать так:

• модуль R (Routing) отвечает за общение с хостом и считает хэши блоков,
• модуль С (Control) отвечает за маршрутизацию запросов и журнал,
• модуль D (Data) отвечает за метаданные (об этом чуть ниже) и запись на SSD.

Каждый модуль также содержит внутри себя много потоков.

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

И это еще одно важное отличие от многих софтовых стеков традиционных СХД, которые в принципе не рассчитаны на Scale-Out. Данную возможность нужно закладывать в архитектуру с самого начала, «прикрутить» позже уже не выйдет.

Метаданные

Уже несколько раз упоминались какие-то таинственные метаданные, хэши и большой объем памяти. Речь вот о чем. Чтобы сделать простой в управлении, сбалансированный и кластерный массив, необходимо отвязать физическое расположение данных на SSD от их логического адреса. Тем более, что для SSD не имеет значения последовательность размещения данных, они идеальны для рандомной нагрузки.

Для этого в XtremIO используется следующая схема. Есть две таблицы с метаданными. В первой хранится соответствие логического блока (например, блок с LBA 12345 с LUN 1) и его хэша. А во второй — соответствие хэша и адреса его физического размещения (грубо говоря, блок 6789 на SSD номер 5 во втором «брике»).

То есть физическое расположение блока определяется его адресом.

Еще одно приятное следствие — в массиве всегда используется принцип thin provisioning. Пока в логический блок ничего не записано, записи в таблицах метаданных для него не создаются и физический блок не выделяется.

И все эти таблицы хранятся и обрабатываются целиком в оперативной памяти, так как нужно до минимума сократить задержки. Естественно, на случай отказа есть копия на SSD.

Заложив такую архитектуру, можно получить множество преимуществ, в принципе невозможных с традиционными СХД, и важнейшее из них, как многие уже, наверное, догадались, это инлайн-дедупликация.

Дедупликация

Дедупликация (то есть поиск одинаковых блоков данных и хранение их лишь в одном экземпляре) во многих случаях работает отлично. Представьте виртуальную ферму, где внутри каждой виртуальной машины львиную долю пространства занимает одна и та же ОС. У многих она есть, но обычно пост-процессинговая. То есть после того, как данные сохранены, по ним пробегается специальный процесс и удаляет дубликаты. Это хорошо работает для архивных задач, но категорически не подходит в ситуациях, когда требуется самая высокая производительность.

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

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

Снэпшоты

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

XDP

И последнее. Еще одну ноу-хау, невозможное без использования флеш: наша схема защиты данных. Как обычно защищают данные в привычных СХД (помните, речь идет про задачи, для которых нужна высокая производительность, в том числе не последовательный доступ с маленькими блоком)? RAID 10 — данные зеркалируются и страйпятся по дискам. Быстро, но слишком дорого при использовании SSD: двукратная избыточность хранения. Было бы здорово использовать широкий RAID-6, но он не подходит для «рандомных» нагрузок по причине высоких накладных расходов при записи не полного страйпа (partial updates). Например, каждая 4К-запись потребует трех чтений и трех записей для корректного обновления страйпа, что убивает производительность.

Значит, нужно писать только полные страйпы целиком. Но у нас же есть две супер-вещи: «врожденная» способность SSD отлично работать с полностью «рандомной» нагрузкой, и архитектура, позволяющая отвязать физическое размещение данных от их логического адреса. Отсюда вытекает следующая идея — давайте сформируем в массиве набор широких страйпов с двойной четностью (см. рисунок, в действительности там 23+2, то есть k=23, а не 5), при записи будет накапливать данные (притом все, относящиеся к разным LUN) и потом записывать их «пачкой» в самый малозаполненный страйп. Так достигается экономия места (коэффициент полезной емкости около 80%), высокая производительность (минимальная паразитная нагрузка от partial updates) и хорошая работа даже при заполнении СХД.

Есть еще много всего: и быстрейшее клонирование в VMware с использованием VAAI, так как при этом обновляются только метаданные, и компрессия данных «на лету», позволяющая сэкономить емкость даже для плохо дедуплицируемых данных, например, БД, и многое другое, но обо всем в одном посте не расскажешь.

Что получилось и где это нужно

Такой набор ноу-хау позволил сделать очень интересный продукт с инлайн-дедупликацией, scale-out, простотой и автоматической балансировкой нагрузки, «бесплатными» снэпшотами и многими другими преимуществами. И все это приносит совершенно реальную пользу.

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

Вот несколько примеров:
• VDI-инфраструктура. Там, с одной стороны, высокие требования к производительности, а с другой — необходимо эффективно хранить тысячи одинаковых рабочих мест. Обычно емкость экономят с помощью Linked clones на уровне ПО, что привносит много сложностей. А с XtremIO можно использовать полные клоны, а о дедупликации позаботится сам массив.
• Виртуальная инфраструктура. Здесь дедупликация тоже отличная, благодаря чему можно уместить в несколько юнитов тысячи виртуальных машин. Развертывание новых клонов практически моментальное, уровень производительности по сравнению с традиционными массивами потрясающий.
• Или массив для СУБД, в котором производительности всегда достаточно, и можно делать снэпшоты без влияния на производительность. Это может полностью изменить способ построения тестовых ландшафтов. Вместо сложной конструкции с пересозданием клонов и репликацией на массив для test/dev, можно собрать все в одной маленькой коробке.

Конкуренты

Такого набора ноу-хау нет ни у кого. И именно такая архитектура и функциональность — это то, что отличает XtremIO от всех остальных игроков на рынке. И таким набором функционала (дедупликация «на лету», компрессия, scale-out, снэпшоты, и все это в едином массиве без дополнительных шлюзов и сложных конструкций), пожалуй, никто не обладает.

Некоторые вендоры в качестве AFA используют привычные массивы, только заменяют диски на SSD. Но у них не получается добиться такой простоты, scale-out, inline-дедупликации и далее по списку.

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

А мы искренне верим, что выбрали правильный путь развития СХД и изначально правильную архитектуру.

PS

Как вы уже, наверное, поняли, мы – компания EMC – начали свой блог. Stay tuned!

Автор: ekrasikov

Источник ^[1]