Источник

Arenadata DB — мощная распределенная аналитическая база данных для высоконагруженных проектов. Эта СУБД может в короткие сроки обслуживать огромное количество аналитических запросов к данным, но такой режим работы делает ее требовательной к производительности дисков: она должна быть высокой, чтобы обеспечить быстрый отклик системы. Из-за этого Arenadata DB не так просто развернуть в облаке: «под капотом»? должны быть быстрые диски и возможность выбора их типа с учетом нагрузки проекта — для достижения нужной скорости работы.

Обычно облака не гарантируют скорости отклика, подходящей для работы со сверхнагруженными системами. Но на платформе Mail.ru Cloud Solutions запущена полностью управляемая Arenadata DB Cloud и есть быстрые диски для ее работы High IOPS SSD. Их производительности вполне достаточно для большинства приложений. А для систем с особо высокими нагрузками, где критически важно минимизировать время задержки до десятых долей миллисекунды, теперь можно подключить и сверхбыстрые диски Low Latency NVMe — они предназначены для задач, где скорость отклика выходит на первый план.

Меня зовут Дмитрий Яценко, я являюсь преподавателем-исследователем в Южном федеральном университете, тренером по продуктам в Arenadata, а также по совместительству разработчиком и системным интегратором в других организациях. В этой статье я покажу результаты тестирования Arenadata DB c Low Latency NVMe, которые помогли улучшить производительность СУБД при по-настоящему высоких нагрузках.

Быстрые и сверхбыстрые диски: как сделать правильный выбор?

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

По исходным данным о проекте можно подобрать число нод, процессоров, объем дисков, но производительность получится определить только с помощью тестов. Так, для Arenadata DB провайдер Mail.ru Cloud Solutions рекомендует использовать один из двух видов дисков:

• быстрые High-IOPS SSD — повсеместно используемые отказоустойчивые диски, имеют время отклика и полосу пропускания, подходящие для подавляющего большинства применений. Но для очень высоких нагрузок их возможностей может не хватать;
• сверхскоростные Low Latency NVMe, у которых большая пропускная способность (и величина IOPS) по сравнению с High-IOPS SSD, а гарантированное провайдером время отклика дисковой подсистемы при нагрузках составляет не более 0,5 мс (для блока 4 KB). Они идеальны для сверхнагрузок. Отказоустойчивость этих дисков обеспечивают два инструмента: регулярный снапшот дисков, который производит платформа и RAID-режим работы дисков NVME. Оба инструмента гарантируют отказоустойчивость и доступность данных в любой момент без задержки производительности.

Чтобы наглядно продемонстрировать разницу между High IOPS SSD и Low Latency NVMe, приведу фрагмент их SLA для объема дисков 250 GB (именно такой объем будет использован нами в тестировании). С полным перечнем SLA для дисков Mail.ru Cloud Solutions можно ознакомиться по ссылке.


Для блоков 4KB гарантируется время отклика (latency) 0,5 мс.

И для каждого проекта встает вопрос: достаточно ли будет High-IOPS SSD или их скорости мало, лучше подключить Low Latency NVMe? Любые Highload-нагрузки нужно тестировать: High-IOPS SSD дают очень хорошие цифры, но для по-настоящему нагруженных систем их бывает недостаточно.

Возможность подключить в облаке сверхбыстрые Low Latency NVMe позволяет использовать облака для таких категорий приложений, где ранее это было недоступно из-за недостаточной скорости отклика.

Ниже я покажу результаты одного такого теста по выбору типа дисков. Вы увидите, какие показатели дают Low Latency NVMe, а также сможете соотнести результаты с вашими требованиями, чтобы определиться, подойдет ли такой вариант вашему приложению.

Задача тестирования

В процессе тестирования мы проверяли работоспособность СУБД Arenadata DB и оценивали результаты, демонстрируемые системой. Как я уже говорил, она использует много ресурсов. Решение построено на Greenplum — MPP-системе, работающей на основе PostgreSQL. Внутри одного кластера Greenplum могут размещаться сотни логических сегментов — инстансов PostgreSQL, распределенных по различным серверам (сегмент-хостам). Каждый инстанс отвечает за обработку своей части данных. При выполнении запроса все инстансы работают одновременно.

В результате генерируется значительный объем трафика: растет нагрузка на сеть, CPU и дисковые подсистемы.

Внутри Greenplum есть встроенная утилита GPCHECKPERF, которая позволяет тестировать нагрузку на диски и сеть. В ее основе работает Linux-утилита dd: создается файл заданного объема, для которого проводится запись и чтение данных с измерением скорости. Так как Greenplum — MPP-система, подобные тесты необходимо одновременно и параллельно выполнить на всех узлах кластера (сегмент-хостах). С помощью этой утилиты я провел комплексную оценку скорости чтения/записи дисковой подсистемы. Точно так же протестировали сеть — есть встроенная утилита GP, которая запускает пакеты данных между узлами кластера, анализируя пропускную способность сети.

В ходе тестирования хотели достичь следующих показателей:

• Пропускная способность сети не менее 1 Гбит/с. Это минимальная скорость передачи данных по сети, которая необходима для работы Greenplum. Если этот показатель меньше, сеть может стать узким местом, что приведет к замедлению обработки запросов.
• Скорость чтения и записи дисковой подсистемы не менее 0,8 Гбит/с. Чем выше этот показатель, тем быстрее происходит считывание и запись данных с диска.
• Время отклика (Latency) не более 100 мс. Хотя со стороны Greenplum нет жестких рекомендаций для данного показателя, желательно, чтобы его величина была минимальной.

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

Первые тесты производительности СУБД Arenadata DB на дисках High-IOPS SSD

Стенд для первого теста (рис. 1) — 16 серверов (8 CPU для каждого сервера) и 64 GB RAM. На каждом сервере (сегмент-хосте) размещалось по 4 основных логических сегмента (инстанса PostgreSQL) и 4 вспомогательных. Вспомогательные сегменты выполняли роль «зеркал» для повышения отказоустойчивости.

Утилита GPCHECKPERF размещалась на мастер-сервере и запускала утилиту dd параллельно на всех сегмент-серверах. Та, в свою очередь, сначала записывала данные в файл, а затем считывала их, анализируя скорость дисковой подсистемы. Еще одна утилита GP измеряла скорость передачи файла по сети от одного сегмент-хоста к другому, тестируя таким образом полосу пропускания канала.

  

Рисунок 1. Стенд для первого теста: 16 сегмент-хостов по 4 основных и 4 вспомогательных сегмента в каждом

По нагрузке на сеть для Arenadata DB требовалась минимальная пропускная способность 1 Гбит/с. В тестах на стандартных машинах с дисками High-IOPS SSD я достиг данного показателя, применив специальную настройку сети Multiqueue, которая помогает задействовать CPU виртуальной машины для обработки трафика между серверами.

Минус такого решения: CPU задействованы в обработке трафика, то есть больше ресурсов уходило на обработку, а не на дополнительные вычисления внутри кластера.

По нагрузке на дисковые подсистемы диски High-IOPS SSD дали хорошую производительность в рамках SLA, но в рамках поставленной задачи их скорости было недостаточно.

В процессе тестирования на разных дисках была показана скорость чтения/записи — от 320 до 550 Мбайт/с (рис. 2), время отклика дисков — около 25 мс (рис. 3). Это допустимые показатели  — нагрузка на разные компоненты может варьироваться, так что производительность с точки зрения клиентской нагрузки также будет меняться. При этом показатели в пределах SLA и тестирование подтвердит, что всё в порядке. В большинстве случаев такой производительности дисков будет вполне достаточно, но в рассматриваемом случае я рассчитываю на лучшие показатели.


Рисунок 2. Значения скорости записи дисковой подсистемы, полученные по 16 сегмент-хостам, которые использовались во время первого тестирования (на дисках High IOPS SSD)


Рисунок 3. Значения времени отклика, полученные по 16 сегмент-хостам, которые использовались во время первого тестирования (на дисках High IOPS SSD)


Рисунок 4. Значения IOPS, полученные по 16 сегмент-хостам, которые использовались во время первого тестирования (на дисках High IOPS SSD)

Небольшой экскурс о том, откуда берется разница в производительности на этом типе дисков, почему есть разброс скорости от 320 до 550 Мбит/с.

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

Например, на одном гипервизоре работают 10 виртуальных машин с дисками на одной системе хранения и ВМ сильно нагружают сеть хранения (SAN) и клиентскую сеть, а на другом гипервизоре намного меньше ВМ и их диски расположены на другой системе хранения, на которой меньше дисков клиентов, а значит, и нагрузка меньше. То есть во втором случае скорость работы дисков будет выше — существенно меньше нагружены SAN, система хранения, сеть, а значит, ВМ получают больше ресурсов. Можно уравновесить скорость, «размазав» виртуальные машины равномерно по гипервизорам внутри облака — облачная платформа и ее планировщик позволяют это сделать.

Итак, после тестов с дисками High-IOPS SSD стало понятно, что нам нужны диски более производительные, чем High-IOPS. Ну а если говорить формальным языком, то для нас это означало, что нам нужен повышенный SLA и новый тип дисков.

Второе тестирование СУБД Arenadata DB с дисками Low Latency NVMe

Когда я связался со специалистами платформы с результатами первого теста, мне предложили поучаствовать в закрытом тестировании тогда еще нового типа дисков — Low Latency NVMe. Как оказалось, провайдер облачной платформы незадолго до того запустил эти диски в стадию опытной эксплуатации. Они расположены непосредственно на гипервизорах и работают существенно быстрее.

Стенд для второго теста (рис. 5) — 10 виртуальных машин (16 CPU на каждый сервер) и 64 GB RAM. Архитектура и схема взаимодействия компонентов идентична первому тесту, с той лишь разницей, что вместо 16 сегмент-серверов использовано 10. На каждом сервере так же размещалось по 4 основных и 4 вспомогательных сегмента (инстанса PostgreSQL).


Рисунок 5. Стенд для второго теста: 10 сегмент-хостов по 4 основных и 4 вспомогательных сегмента в каждом

Использование Low Latency-дисков сейчас подразумевает подключение High-Freq-флейворов серверов, где в два раза больше CPU и повышенная частота процессора (Basic/Advanced — 2,2 ГГц, High-Freq — 3,0 ГГц).

По пропускной способности сети получили увеличение в 10–15 раз — 10–15 Гбит/с.

По дисковой подсистеме получили хорошие результаты по скорости записи (1,1 Гбайт/с) и чтения (1,2 Гбайт/с) (рис. 6) На всех серверах скорость была одинаковой на всех дисках. При этом время отклика составила не более 0,3 мс (рис. 7) — что даже лучше, чем задекларированный для этих дисков SLA Mail.ru Cloud Solutions, который равен 0,5 мс. Скорость отдачи запросов внутри СУБД также значительно увеличилась.


Рисунок 6. Значения скорости записи дисковой подсистемы, полученные по 10 сегмент-хостам, которые использовались во время второго тестирования (на дисках Low Latency NVMe)


Рисунок 7. Значения времени отклика, полученные по 10 сегмент-хостам, которые использовались во время второго тестирования (на дисках Low Latency NVMe)


Рисунок 8. Значения IOPS, полученные по 10 сегмент-хостам, которые использовались во время второго тестирования (на дисках Low Latency NVMe)

Процесс внедрения нового типа диска требует немного времени: создается виртуальная машина с параметрами, выбирается тип диска, разворачивается СУБД. Вся установка Arenadata DB заняла около часа. С техническими проблемами в процессе тестирования не столкнулись.

Замечание: вполне ожидаемо, что у меня возникли вопросы о надежности дисков, которые я адресовал владельцам платформы. Как мне пояснили, несмотря на то, что диски Low Latency являются локальными и физически установлены в гипервизор, они резервированы, что позволяет производить замену диска без прерывания сервиса. При необходимости обслуживания гипервизора облачная платформа также предоставляет возможность миграции виртуальной машины и дисков на другой гипервизор с аналогичными дисками без прерывания сервиса.

Основной результат

Тестирование показало возможность успешного использования Arenadata DB as a Service на платформе Mail.ru Cloud Solutions как на быстрых, так и на сверхбыстрых дисках. В обоих случаях гарантируется быстрая и стабильная работа дисковой подсистемы. Однако использование дисков Low Latency NVMe увеличивает скорость обработки запросов и больше подходит для задач, в которых скорость отклика критична. Это важно, так как СУБД используют в проектах, где IT-инфраструктура должна быстро и безошибочно обрабатывать сложные аналитические запросы над большим объемом данных: ритейл, банки, предприятия общественного питания, провайдеры контента и игровых платформ, биржевые и финансовые сервисы.

Сегодня на платформе Mail.ru Cloud Solutions также стала доступна Enterprise-версия Arenadata DB Cloud с расширенной поддержкой от разработчика решения. С этой версией также можно использовать сверхбыстрые диски Low Latency NVMe. Если вы хотите протестировать Arenadata DB в облаке и проконсультироваться по тонким настройкам, вы можете оставить заявку на странице решения.

UPD: Исправили ошибки в таблице. Спасибо amarao, что обратил внимание.

Что еще почитать:

1. Как реализуется отказоустойчивая веб-архитектура в платформе Mail.ru Cloud Solutions
2. Быстрые и сверхбыстрые диски в облаке: как получить максимум от облачной системы хранения данных
3. Наш Телеграм-канал об облачных технологиях и цифровизации