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

Привет, Хабр. Меня зовут Василий Степанов. Я руководитель команды разработки Storage в VK Cloud. В этой статье я расскажу о том, как устроено наше дисковое хранилище: какие диски используются в VK Cloud и как мы с ними работаем.

Материал подготовлен на основе моего доклада в рамках InfraDev Meetup. Вы можете посмотреть его здесь.

Немного контекста

VK Cloud — платформа, которая предоставляет клиентам необходимые инструменты, ресурсы и технологии в рамках публичного и частного облака, а также в формате ПАК-поставки. 

Но доступный набор сервисов — это лишь вершина айсберга, в его основе лежат три группы инфраструктурных сервисов:

• виртуальные серверы;

• дисковые хранилища;

• виртуальные сети.

При этом немногие люди знают, как именно устроена эта часть облака, и еще меньше — как это реализовано в VK Cloud. Поэтому попробую приоткрыть завесу и расскажу, как именно у нас построены дисковые хранилища.

Локальный том

Главная ценность для нас как для облачного провайдера — виртуальная машина (ВМ) пользователя. Для поднятия ВМ мы используем QEMU (Quick Emulator) — инструмент для эмуляции и виртуализации, который позволяет запускать операционные системы и программы на различных аппаратных архитектурах.

QEMU у нас располагается на своем сервере виртуализации.

Но ВМ не может существовать без данных, а эти данные нужно где-то хранить.

Самый простой и очевидный вариант — приземлить данные на тот же сервер виртуализации в виде отдельного файла. Для обеспечения отказоустойчивости этот файл можно положить на RAID-массив: в таком случае выход из строя оборудования не приведет к потере данных.

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

Это действительно рабочее решение, которое подходит под многие сценарии и имеет ряд значимых достоинств.

• Высокая скорость. При SLA bs=4k, iodepth=16, randaccess, скорость чтения — 75 000 IOPS, скорость записи — 50 000 IOPS.

• Простая архитектура. В такой реализации участвует меньше сервисов. А чем меньше сервисов, тем меньше возможных точек отказа.

Но работа с локальными томами не лишена недостатков. Так, с увеличением количества серверов виртуализации можно столкнуться с проблемами — например, в ситуациях, когда для балансировки нагрузки ВМ переносят с одного сервера на другой. Здесь возникает сразу несколько нюансов.

• Медленная миграция ВМ. Перенос ВМ и данных может занимать много времени и заметно повышает нагрузку на сеть.

• Риск потери доступа к данным в случае потери гипервизора. Нельзя гарантировать отсутствие сбоев на серверах и их постоянную доступность. Но пока сервер недоступен, файлы на нем также недоступны. И на устранение проблем может уходить до нескольких часов, что во многих сценариях просто недопустимо.

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

Сетевой SDS

SDS (Software-Defined Storage, программно-определяемое хранилище) — технология, которая отделяет управление хранилищем данных от физического оборудования, позволяя централизованно управлять ресурсами через программное обеспечение. 

Фактически это сетевой способ управления, при котором виртуальные машины работают отдельно и используют удаленное хранилище, доступное по сети. Соответственно, значительно упрощается возможный перенос ВМ, поскольку он никак не затрагивает данные и хранилище.

Для организации SDS мы в VK Cloud в качестве сетевого хранилища данных используем Ceph.

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

Для распределения данных по серверам хранения Ceph использует принцип «фрагментации и размазывания»: фактически диск нарезается на объекты размером около 4 МБ, после чего они распределяются по всем доступным серверам.

Сразу отмечу, что каждый блок показан на картинке два раза не просто так: это визуализация реплицирования данных.

При работе с Ceph репликация реализовывается следующим образом:

• Ceph определяет мастер (Master) для каждого объекта на одном из серверов;

• с выбранного мастера данные реплицируются на слейвы (Slave). 

Таким образом, для каждого объекта всегда есть мастер.

Преимущества Ceph сводятся к двум аспектам:

• Равномерная утилизация. Ceph позволяет балансировать нагрузку и равномерно заполнять все доступные серверы. 

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

• Симметричная архитектура. Описанная мной схема работы — классическая Master-Slave-архитектура. Но Ceph позиционируется как симметричная архитектура без единой точки отказа.

Но есть и недостатки. Выделю несколько ключевых.

• Низкая скорость. При идентичных условиях SLA Ceph обеспечивает скорость чтения на уровне 16 000 IOPS и скорость записи в 8000 IOPS.

• Недостаточная предсказуемость. При добавлении в Ceph-кластер новых серверов начинается ребалансировка данных. И заранее определить, какую нагрузку на внутреннюю сеть это создаст и сколько времени займет обмен данными, невозможно.

• Сложность настройки. Работа с Ceph предполагает сложную глубокую настройку. Например, у нас в Ceph сейчас используются 1434 параметра настройки. Соответственно, для поддержки Ceph-кластера нужна глубокая экспертиза и много времени.

Понимая все преимущества и возможные подводные камни, мы в VK Cloud сейчас используем более 30 Ceph-кластеров, в каждом из которых примерно по 300 дисков. 

Переход к High-IOPS

В поисках оптимизации мы начали искать другие варианты хранения данных и таким образом пришли к технологии High-IOPS. 

High-IOPS-диски на платформе VK Cloud — вид хранилища, реализованного поверх нескольких SSD- или NVME-дисков, подключенных локально к одному или нескольким вычислительным узлам. За счет локального подключения и более простой организации, в отличие от, например, дисков Ceph, достигается большая производительность операций ввода-вывода.

Распределение данных в случае High-IOPS реализуется предельно простым образом: выбирается конкретный сервер с достаточным объемом свободного места и диск пользователя полностью загружается на него. То есть подход с размазыванием данных по серверам здесь не работает.

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

У High-IOPS-кластеров есть очевидные преимущества:

• Высокая скорость. При идентичных условиях SLA скорость чтения — 45 000 IOPS, скорость записи — 30 000 IOPS.

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

• Простота. Для управления High-IOPS-кластером достаточно нескольких десятков настроек. 

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

То есть в High-IOPS-кластерах надо держать дополнительный объем в постоянном резерве. И если в отдельно взятом случае это не так критично, то в масштабе облачной платформы с сотнями клиентов и терабайтами данных это довольно ощутимо. Для понимания масштаба нагрузки достаточно посмотреть на график загрузки части наших серверов. Здесь каждая строка — отдельный хост хранения данных, а каждый блок — отдельный диск.

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

Соответственно, к недостаткам High-IOPS можно отнести ребалансировку при расширении дисков и Master-Slave-архитектуру, то есть в случае отказа мастера нужно время на переключение. Но эти издержки с лихвой компенсируются преимуществами, поэтому мы готовы с ними мириться. Сейчас в VK Cloud около 150 High-IOPS-серверов и на каждом из них около 200 клиентских дисков.

Альтернативные варианты и подходы к построению SDS

По степени локализации и распределенности данных подходы к построению SDS можно проранжировать следующим образом:

1. Локальный диск.

2. High-IOPS.

3. Ceph.

Нюанс в том, что «пространство» между High-IOPS и Ceph довольно большое, поэтому, вероятно, есть место для других реализаций.

После небольшого анализа мы нашли другие возможные варианты хранения данных.

Аллокация в начале жизненного цикла

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

При этом, если ни на один из серверов диск не влезает целиком, его можно сразу разбить на большие части (например, 100 ГБ и 50 ГБ) и разнести по разным хостам. 

Если же пользователь захочет расширить диск, новый объем будет выделяться без привязки к конкретному хосту (на любом сервере, где есть нужное место), что упрощает масштабирование. 

Сами же диски никогда не перемещаются между серверами.

Репликация

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

Современные технологии

Помимо упомянутых способов, в контексте новых систем хранения данных также можно отметить несколько альтернативных вариантов:

• io_uring — асинхронный интерфейс ввода-вывода, разработанный для минимизации накладных расходов при системных вызовах. Заменяет устаревшие механизмы вроде epoll и libaio;

• RDMA (Remote Direct Memory Access) — технология прямого доступа к памяти между узлами в сети, минуя CPU и ОС;

• vhost-user-blk на едином Event Loop — механизм виртуализации блочных устройств, где обработка I/O вынесена в пользовательское пространство (Userspace) для улучшения производительности;

• Zerocopy — методы передачи данных без копирования между слоями приложения, ядра и устройств.

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

Вместо выводов

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

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

Подписывайтесь на каналы VK Cloud | Новости сервисов, Вокруг Kubernetes в VK и Данные на стероидах. Обсуждайте новости и рабочие моменты в чате пользователей платформы.