Согласно оценкам аналитиков, к 2019 году затраты на технологии цифровой трансформации во всем мире достигнут 2,1 трлн долл., увеличиваясь ежегодно почти на 17% с 2014 года. Например, в IDC ожидают, что число предприятий, реализующих проекты по цифровой трансформации, к 2020 году удвоится (с 22 до почти 50%), однако при этом только у 27% компаний сегодня имеется стратегия по цифровому обслуживанию заказчиков. Для перехода к цифровому предприятию требуются новые технологии, в частности хранения данных, причем нужны универсальные платформы, способные решать широкий спектр задач, поскольку подразделение ИТ не может постоянно отвлекаться на выбор системы для конкретной задачи, обслуживание разнородной техники, непрерывный вывод и ввод в эксплуатацию очередного типа оборудования. Системы хранения должны быть как можно более емкими и обладать как можно большей надежностью — в цифровую эпоху бизнес непосредственно зависит от информации, потери которой недопустимы. Производительность должна быть высокой: требуется мгновенно анализировать и реагировать на полученные сведения, чтобы удовлетворить или предвосхитить запросы клиентов. В условиях широкого выбора систем хранения и унификации всегда можно переключиться на другого поставщика, поэтому первоначальная цена и предсказуемость стоимости эксплуатации решения также интересуют бизнес и подразделения ИТ.
Оптимальную систему хранения, удовлетворяющую всем этим требованиям, найти довольно сложно. В классических системах вроде EMC Symmetrix используется много нестандартных программных и аппаратных компонентов, что сказывается на их цене, а ядро таких систем было написано достаточно давно и не всегда может быть адаптировано к требованиям цифровой эпохи. Системы IBM XIV используют стандартные компоненты, это позволяет снизить стоимость, однако применение зеркалирования вместо четности для обеспечения защиты снижает емкость и не позволяет защититься от скрытых ошибок — их можно обнаружить, но нельзя скорректировать. Кстати, обе эти системы — детище Моше Янаи, работавшего в корпорации EMC и основавшего в Израиле компанию XIV, приобретенную IBM [1].
Попытку переосмыслить алгоритмы и архитектуру с учетом развития компонентов и перспектив использования информационных систем вновь предпринял Янаи, который организовал свою очередную компанию, Infinidat, и предложил систему Infinibox.
ИТ-решения, лежащие в основе цифровой трансформации, требуют масштабируемых систем хранения практически неограниченной емкости. Хранить большие объемы данных можно путем предоставления неограниченного виртуального адресного пространства — Virtual User Address space (VUA). Все объекты Infinibox, доступные пользователю (тома, снимки и файловые системы), представлены в VUA, причем их общая емкость и есть текущий размер VUA. Такая адресация не связана с дисками — размер VUA может быть заведомо гораздо больше любой доступной физической дисковой емкости, причем «диск» здесь является чисто логическим понятием.
Все адресное пространство разбивается на шесть частей (virtual unit, VU), между которыми равномерно распределяется адресное пространство каждого объекта, например тома. Запись идет блоками по 64 Кбайт, и в процессе работы можно быстро понять, какому VU принадлежит данный адрес тома — остаток от деления адреса блока по LBA (Logical block addressing — механизм адресации блока данных на диске, не учитывающий его физические параметры: число цилиндров, головок, секторов на дорожке) на 64 Кбайт, функция modulo выполняется за минимальное число циклов процессора. Такое разбиение упрощает работу с пространствами меньшего размера, а кроме того, образует первый уровень абстрагирования от физических носителей и основу для отказоустойчивости системы на уровне контроллеров. Имеются три контроллера (физических сервера), каждый из которых отвечает за функционирование двух других VU и одновременно является для них резервным. Контроллер не обслуживает VU, для которого он является резервом, но при этом получает от другого контроллера метаданные и операции записи для данного VU, чтобы в случае сбоя основного контроллера сразу подхватить всю работу с этим VU. В случае выхода из строя одного контроллера, два других берут на себя работу с его VU. Если выходит из строя еще один контроллер, то оставшийся обслуживает все VU.
Размер VUA определяется количеством и емкостью устройств хранения (за вычетом четности, метаданных и пространства для замены вышедших из строя компонентов). Для постоянного хранения используются жесткие диски, но при этом нет привязки к аппаратному обеспечению и в перспективе можно использовать вместо них другой тип памяти, например твердотельные накопители или 3D Xpoint. Связь между VUA и внутренним пространством для хранения, Virtual Disk Address (VDA), организована через префиксное дерево (рис. 1). Каждая запись в дереве — это указатель из VUA на внутреннее пространство VDA.
.png "Рис. 1. Префиксное дерево") |
| Рис. 1. Префиксное дерево |
Адресация в виде префиксного дерева позволяет адресовать блоки любого размера — когда на диск записывается элемент любого размера (файл, последовательный поток данных, объект), он адресуется одной записью в дереве, что делает его компактным. Наиболее важной особенностью дерева является высокая производительность при поиске и расширении дерева: поиск выполняется при операции чтения, когда необходимо найти блок с заданным адресом на диске. Расширение дерева происходит во время записи, когда новые данные складируются на диск, и к дереву надо добавить их адрес. Производительность крайне важна при работе с большими структурами, и префиксное дерево позволяет ее достичь с запасом на будущее — например, на случай увеличения объема компонентов. Размер VUA может намного превышать размер VDA, но VUA не связан с VDA, пока в последний ничего не записали. Так реализуется динамическое распределение (thin provisioning): при записи выделяется место на диске и формируется связь VUA с VDA. На один VDA может ссылаться больше чем один VUA.
Такая организация адресации позволяет обеспечить быстрое создание снимков и динамическое распределение: создание моментального снимка в данном случае представляет собой простое обновление метаданных в памяти и фактически не занимает времени. Как правило, при создании снимков классические системы хранения прекращают обновление метаданных или ввод-вывод, для того чтобы гарантировать целостность транзакций, что ведет к неравномерности задержек операций ввода-вывода. Система Infinibox работает иначе: никакие операции не останавливаются, а для определения попадания операции в снимок используется отметка времени (timestamp) из метаданных блока (64+4 Кбайт). Таким образом, система может делать сотни тысяч снимков, не замедляя работы: том с сотнями снимков и том вообще без снимков имеют одинаковую производительность. Поскольку все делается в памяти и это штатные процессы, то на группы томов можно делать десятки снимков в секунду, что позволяет реализовать асинхронную репликацию на мгновенных снимках с разницей между копиями в секунды и даже меньше, причем не снижая производительности.
Операции ввода-вывода поступают через порты всех трех контроллеров. Физический адрес (World Wide Name, WWN, аналог MAC-адреса) порта можно настроить как виртуальный, при этом в случае сбоя самого порта или на пути к нему система вывесит этот WWN на другой порт и с точки зрения сервера путь не пропадет. Таким образом, серверу не требуется идентифицировать сбойный путь и потом его восстанавливать. Драйверы портов работают в пользовательском пространстве, что позволяет легко их перезапускать, если какая-либо комбинация событий на портах приведет к сбою драйвера. В традиционных реализациях все эти операции выполняет ядро операционной системы хранения и устранение сбоя возможно лишь после перезапуска контроллера целиком.
Далее поток операций записи разбивается на секции по 64 Кбайт плюс 4 Кбайт, они служат для защиты от «тихих ошибок» (silent errors — ошибки, не обнаруживаемые ни диском, ни ОС), и в них записываются контрольные суммы, время и дополнительная информация об операции, которая используется для ее классификации, оптимизации кэширования и упреждающего чтения. Если кэширование записи можно считать достаточно тривиальной операцией, то кэширование чтения хорошо работает только в том случае, если известно, что именно надо считывать. В классических системах при последовательном доступе для этого используются алгоритмы упредительного чтения. Но что делать при произвольном? Полностью произвольный доступ редко встречается в работе реальных приложений, и даже правильно эмулировать его достаточно сложно: написание генератора реально случайных чисел весьма интересная задача. Если рассматривать каждую операцию ввода-вывода отдельно, как происходит в классических системах, то все они являются произвольными и непредсказуемыми, однако если смотреть целиком на весь поток ввода-вывода, как это сделано в Infinibox, то можно обнаружить закономерности, объединяющие разные операции.
Кэш принципиально ничего не знает о томах, файлах и вообще о любой логической структуре, построенной на VUA, а смотрит только на секции и на их метаданные, строя алгоритм кэширования на основе анализа их поведения и атрибутов, что позволяет находить зависимости между разными приложениями. Для операций ввода-вывода строятся векторы активности, таблицы, отражающие статистику по вводу-выводу, — система накапливает информацию, строит закономерности, затем пытается идентифицировать текущий ввод-вывод и привязать его к известным векторам или построить новый. После идентификации происходит упредительное чтение по вектору, то есть предсказывается поведение приложений и делается упредительное чтение для внешней произвольной нагрузки.
Для того чтобы сбросить операции записи из кэша на диски, 14 секций собираются в так называемый страйп. Это выполняет специальный процесс, подбирающий секции для такого страйпа. Далее подсчитываются две секции четности — и страйп готов к записи на диски. Четность подсчитывается через несколько операций на основе XOR, это в два раза быстрее, чем на базе кода Рида — Соломона [2], применяемого в большинстве традиционных систем хранения. Дальше страйп (14+2 секции) присваивается RAID-группе (RG) — объекту для хранения нескольких страйпов. Страйпы собираются в группу (рис. 2) один над другим, а вертикальный столбец называется членом RAID-группы. Дисковое пространство, доступное для пользовательских данных, — VDS (Virtual Disk Space), а VDA — это адреса в нем. Столбец или член RAID-группы записывается на один диск (Physical Drive, PD) в одной полке (Disk Unit). Место, куда записывается член RAID-группы, называется разделом диска (Drive Partition, DP), число которых на диске постоянно и равно 264, а размер зависит от размера диска, что позволяет равномерно нагрузить все диски. При этом алгоритм системы распределяет столбцы из одной RAID-группы максимально далеко друг от друга, на разных дисках и полках, поэтому при выходе из строя одновременно двух дисков оказывается, что количество общих страйпов на них минимально и система переходит из состояния защиты N в N+1 за минуты, перестраивая только те страйпы, где не хватает сразу двух столбцов. Все это и позволяет получить надежность «семь девяток» (кроме наличия защиты, надо еще уметь быстро восстанавливать ее уровень).
.png "Рис. 2. Группа страйпов") |
| Рис. 2. Группа страйпов |
Физическая реализация архитектуры Infinibox получается достаточно лаконичной и исключает использование заказных компонентов. Контроллеры между собой соединяются по Infiniband, а с дисками — через SAS. Каждый контроллер может обратиться к каждому диску, причем если нет связи между диском и контроллером, то последний через Infiniband может запросить данные через другой контроллер, выступающий как прокси. Полки содержат в себе SAS-коммутаторы для одновременного доступа к дискам. Контроллеры включают две группы твердотельных накопителей: одна — системная (для сброса оперативной памяти), а вторая — для кэширования операций чтения (до 86 Тбайт на систему). Такой большой кэш позволяет предиктивно читать большими кусками, а поскольку в страйпе подбираются данные с примерно одинаковой частотой обращения, то они имеют большие шансы быть востребованными приложением в ближайшее время, к тому же снижается нагрузка на физические диски. Применение емких дисков для постоянного хранения и SSD для ускорения работы дает высокую производительность при большой емкости, а использование стандартных компонентов позволяет снизить стоимость системы хранения.
Что система Infinibox дает компаниям, вступившим на путь цифровой трансформации? Во-первых, огромную емкость хранения: в одном стандартном шкафу можно поместить 2 Пбайт полезной информации без учета компрессии. Во-вторых — высокую скорость работы приложений: кэширование и создание моментальных снимков не сказываются на производительности, при этом система позволяет лучше, чем в традиционных архитектурах, защищать информацию при решении любых задач пользователя. Применение стандартных компонентов благотворно влияет на цену и позволяет использовать реальную модель Capacity on Demand, когда система изначально поставляется в максимальной конфигурации, а дополнительная емкость мгновенно предоставляется при необходимости. Надежность системы Infinibox — 99,99999%, что важно при обработке критичной для цифрового бизнеса информации.
***
На рынке постоянно появляются новые технологии хранения, интерфейсы и протоколы, однако в корпоративных системах хранения по-прежнему применяются идеи многолетней давности: например, для оптимизации хранения — иерархическое хранение по востребованности информации, а для повышения надежности — контроль по кодам Рида — Соломона, предложенным более полувека назад. В цифровую эпоху такие решения, «зашитые» в системное ПО, замедляют работу и усложняют конфигурацию, а значит, создают дополнительные риски для бизнеса, информационные системы поддержки которого оказываются неспособны воспользоваться всеми преимуществами новых технологий. Требуемая для любого цифрового бизнеса гибкость достигается за счет отсутствия жесткой связи между программным обеспечением и оборудованием, а также благодаря независимости приложений от архитектуры системы хранения.
Литература
- Леонид Черняк. XIV — новая философия хранения // Открытые системы.СУБД. — 2008. — № 10. — С. 24–27. URL: http://www.osp.ru/os/2008/10/5831607 (дата обращения: 18.05.2016).
- Леонид Черняк. Хранилище данных на кодах Рида — Соломона // Открытые системы.СУБД. — 2012. — № 2. — С. 52–53. URL: http://www.osp.ru/os/2012/02/13014124 (дата обращения: 19.05.2016).
Василий Кострюков (vasilyk@infinidat.com) — сотрудник, компания Infinidat (Москва).
