Флеш-массив 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!
