Девять лет назад «Международный день телекоммуникаций» был переименован в «Международный день телекоммуникаций и информационного общества». Для золотого миллиарда будущее уже наступило: интернет стал одной из важнейших частей нашей жизни. Ежесекундно по всему миру создаются и потребляются колоссальные объёмы информации, а рынок всевозможных онлайн-сервисов является одним из самых быстрорастущих.

Одной из главных тенденций последнего времени стало развитие облачных технологий. Они используются повсеместно, от файлообменников и видеохостингов до мобильных приложений, сервисов заказа услуг и внутренних корпоративных систем. Подавляющее большинство подобных проектов оперируют неструктурированной информацией, причём ёмкость файловых хранилищ ежегодно увеличивается примерно на 53%. И с ростом объёмов генерируемой и хранимой информации трансформируются и требования к системам хранения данных.

По прогнозу компании Cisco, в 2016 году объём мирового интернет-трафика достигнет 1,1 зеттабайта (в среднем 91,3 экзабайта в месяц). И к 2018 году половина мирового интернет-трафика придётся на сети доставки контента. Мобильный сегмент также переживает этап бурного развития. По данным той же Cisco, в 2014 году мобильный трафик вырос на 69%, достигнув 2,5 экзабайт. И уже в 2012 году половину мобильного трафика составляло видео.

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

Например, при хранении текстовой и визуальной информации (графика, видео) обычно используют две базы данных: отдельно для текста и для контента. Но при размере в сотни терабайт производительность и отказоустойчивых контентных БД существенно снижается.



Кроме того, традиционным файловым хранилищам свойственны следующие недостатки:

• Ограничение на количество и максимальный объём файлов
• Наличие блокировок
• Долгие операции листинга, сканирования и т. д.
• Отсутствие возможности создания геораспределённого хранилища с единой точкой входа
• Отсутствие версионности и поколений данных
• Необходимость проведения операций резервного копирования
• Наличие ограничений файловых таблиц
• Различная скорость работы разных файловых систем с разными объёмами файлов
• Низкий уровень безопасности и защиты данных
• Сложность работы с метаданными
• Существенные ограничения на создание горизонтально-расширяемых хранилищ
• Низкий уровень гибкости и масштабируемости
• Нестабильность работы сетевых файловых систем из-за нестабильной работы каналов связи

С учётом развития мобильных сервисов, к системам хранения всё чаще предъявляются и такие требования:

• минимизация трафика между клиентскими устройствами и хранилищем,
• минимизация использования ресурсов клиентского устройства,
• возможность работы с защищённым API (невозможность работы через файловый или блочный доступ)
• работа через глобальную сеть.

В результате всё большую популярность обретают объектные СХД, лишённые недостатков файловых хранилищ, обеспечивающие высокую производительность и отказоустойчивость при работе с большим объёмом неструктурированных данных. Одним из подобных решений является EMC Elastic Cloud Storage (ECS).

Архитектура Elastic Cloud Storage

EMC ECS — это программно-определяемое хранилище, которое может поставляться как в виде программного решения, так и программно-аппаратной системы.

В основе системы лежит программный модуль хранения неструктурированных данных. Он может устанавливаться на любое стандартное оборудование. На данный момент модуль хранения обеспечивает управление объектными данными и HDFS.



Важными особенностями ECS является неограниченная масштабируемость системы с помощью простого добавления новых узлов. А за счёт исключения единой точки отказа обеспечивается высокая доступность.

В ECS обеспечивается одновременный доступ к данным через различные интерфейсы, а также совместимость с такими API, как Amazon S3, OpenStack Swift, EMC Atmos и Centera CAS. Кроме того, поддерживаются и расширения API: Byte-Range updates, Atomic appends, Rich ACLs и т.д.

Модуль хранения данных может вести журналирование, делать снэпшоты и отслеживать версионность. Все данные хранятся в логических контейнерах — чанках (chunk). Размер каждого чанка составляет 128 Мб. При этом все операции защиты данных осуществляются с чанками, а не с самими объектами.

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

Поскольку ECS работает на типовом оборудовании, то для увеличения производительности был применён ряд решений:

• Исключены такие процедуры, как блокировка при операциях ввода-вывода и проверка кэш-памяти. Это достигнуто за счёт отказа от модифицирования и перезаписи данных в чанках, информация только добавляется. Удаление неиспользуемых данных осуществляется только в фоновом режиме.
• Запись одного и того же объекта может осуществляться одновременно всеми узлами системы на различные наборы дисков. Наращивание количества дисков и сетевых адаптеров лишь увеличивает общую производительность системы.
• Применена буферизация записи небольших объектов: они записываются на диски не по отдельности, а партиями. Это позволяет снизить количество процедур записи.

Алгоритмы записи, чтения и обновления данных

Давайте рассмотрим подробнее, как в ECS осуществляется запись, чтение и обновление данных.

Алгоритм записи:

1. Модуль хранения получает запрос на запись объекта.
2. Одновременно производится запись трёх копий объекта в разные чанкие на разных узлах. При этом в один чанк не записывается более 30 Мб данных одного объекта, это делается для увеличения производительности при работе с большими объектами.
3. После этого в индекс записывается имя объекта и адреса чанков.
4. Одновременно производится запись трёх копий самого индекса, в разные чанки разных узлов. При этом выбираются те узлы, в которых отсутствуют копии объекта.
5. В случае успешной записи всех чанков, модуль хранения подтверждает факт записи объекта.
6. По достижении размера каждого чанка 128 Мб, модуль хранения запускает процесс ”Erasure code” (рассмотрен ниже).
7. После завершения Erasure code три сохранённые копии объекта удаляются в фоновом режиме.

Алгоритм чтения:



Здесь всё просто: после получения запроса на чтение, модуль хранения получает из индекса информацию о расположении объекта, считывает его и отправляет пользователю.

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

Процесс Erasure code

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

В основе Erasure process лежит алгоритм Рида-Соломона. Чанк разбивается на 16 модулей, — 12 модулей данных и 4 модуля кода, — которые записываются на разные узлы. При этом чем больше количество узлов, те выше отказоустойчивость. Обратите внимание, что блоки записываются в одном экземпляре.



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

Защита данных и доступ с нескольких площадок

В ECS применена распределённая защита данных, состоящая из двух компонентов: модуля защиты и механизма управления избыточностью. Для защиты от сбоя на площадке используется резервное копирование каждого чанка:



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



После создания набора данных Е, исходные наборы A и D удаляются. В случае возникновения сбоя на одной из площадок, извлекается тот набор данных, что стал недоступен. Для этого второй из исходных наборов снова пересылается на площадку, где хранится сжатый набор. Восстановленный из копии набор копируется на другую площадку.



В отличие от традиционных систем, в которых данные реплицируются на несколько площадок, в ECS избыточность снижается по мере увеличения количества площадок.



В результате всех применяемых мер, данные сохраняются даже при выходе из строя одной площадки целиком. А в системе из 8 и более площадок возможен безболезненный выход из строя двух узлов на каждой площадке. Также каждая площадка позволяет осуществить локальный ребилд, что позволяет снизить нагрузку на сеть и увеличить производительность в случае сбоя.

Механизм распределённой защиты, помимо своей основной функции, в сочетании с глобальным пространством имён позволяет записывать и читать данные с любой из площадок, вне зависимости от их реального расположения. При этом в ECS обеспечивается строгая консистентность данных между всеми площадками.

ECS Appliance

Зачастую многие компании создают объектные хранилища своими силами, на базе типового оборудования и Open Source-продуктов. Причина очевидна — экономия. Однако максимальная дешевизна может обернуться низкой надёжностью. Кроме того, поддержка работоспособности как оборудования, так и Open Source-решений целиком и полностью ложится на самих пользователей.

Как уже упоминалось, ECS может поставляться в виде программно-аппаратного комплекса ECS Appliance. Он полностью изготовлен из типовых элементов: 4 server nodes in 2U и 3,5-дюймовых SATA-дисков. Притом доступно 2 конфигурации.

U-Series – диски с данными находятся в подключенных дисковых полках.



Доступны пять конфигураций, различающиеся количеством серверов и дисков.



C-Series – диски с данными находятся в самих серверах. Расширение производится однотипными 2U модулями.



При данном типе поставки осуществляется поддержка как программного обеспечения, так и оборудования. Масштабирование СХД возможно, как путём простого добавления новых стоек ECS Appliance, так и стороннего оборудования. Однако в последнем случае развёртывание и настройку ECS делает сам пользователь.

Заключение

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