Всем привет! Меня зовут Константин Малолетов, я архитектор облачных сервисов в компании Arenadata. Сегодня хочу рассказать, как мы решаем задачу эффективного размещения ресурсоёмких систем, таких как Arenadata DB, в облаке.

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

Цель исследования

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

Чтобы плавно перейти от плотности размещения виртуальных машин (далее VM — Virtual machine) к исследуемым сценариям, придётся сделать небольшое теоретическое отступление.

Немного скучной теории

Здесь нужно вспомнить, как работает планировщик вычислительных ресурсов Linux с учётом технологии SMT, в частности Intel Hyper-threading. Подробно на технологии останавливаться не буду, напомню лишь, что каждое физическое ядро процессора представляется в операционной системе двумя логическими процессорами, на каждый из которых планировщик может назначить свой поток выполнения.

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

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

Подобное поведение планировщика справедливо в том числе для распределения потоков выполнения VM, если мы говорим о планировщике физического сервера. В операционной системе, установленной на VM, также есть свой планировщик, который распределяет потоки выполнения внутри виртуальных машин на выделенные им виртуальные процессоры (vCPU).

Стоит отметить, что всё описанное выше — это стандартное поведение планировщика. При размещении Arenadata DB в облаке мы рекомендуем использовать технологию CPU pinning / processor affinity. Она модифицирует стандартное поведение планировщика и позволяет VM не зависеть от количества и нагруженности соседних по физическому серверу виртуальных машин, а также получать стабильно одинаковую производительность каждого узла кластера, что важно для MPP-систем. К сожалению, если говорить о публичных российских облачных провайдерах, эта технология в большинстве случаев не реализована.

Исследуемые сценарии плотности размещения VM

Сценарий № 1: «Идеальный».

В идеальном сценарии суммарное количество vCPU всех VM, размещённых на физическом сервере, не должно превышать количество физических ядер на этом сервере. Этим сценарием мы хотели эмулировать ситуацию, когда каждому потоку выполнения VM выделяется в пользование физическое ядро целиком.

Условные обозначения:

• VM — виртуальная машина;

• vCPU — виртуальный процессор;

• Scheduler — планировщик физического сервера;

• T — логический процессор;

• pCore — физическое ядро;

• CPU — физический процессор;

• Server — физический сервер.

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

Сценарий № 2: «Базовый».

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

У подавляющего большинства облачных провайдеров функционал hyper-threading включён и один vCPU равен одному логическому процессору. Планирование двух потоков выполнения на одно физическое ядро с hyper-threading мы не считали переподпиской.

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

Сценарий № 3: «Переподписка».

В сценарии «Переподписка» суммарное количество vCPU всех VM, размещённых на физическом сервере, должно превышать количество логических процессоров (удвоенное количество физических ядер). Так мы эмулировали переподписку, когда количество потоков выполнения VM, ожидающих процессорного времени, больше, чем количество логических процессоров в физическом сервере.

На практике такая ситуация может сложиться, когда вы покупаете вычислительные ресурсы с переподпиской.

Для наглядности сведу условия всех сценариев в таблицу:

Здесь стоит сделать оговорку, что схемы специально упрощены для наглядности размещения VM. Конечно же, мы не использовали в тестах однопроцессорный трёхъядерный сервер и VM с двумя vCPU. Описание реального тестового стенда приведу далее.

Тестовая среда

В качестве площадки проведения исследования использовалось публичное облако одного из российских облачных провайдеров, построенное на базе связки Linux + Qemu + KVM. В каждом физическом сервере было по 48 физических ядер (pCore) с поддержкой технологии Hyper-Threading, что давало 96 логических процессоров (T). Если говорить о плотности размещения VM, то суммарные 96 vCPU — та граница, после которой начинается переподписка. На самом деле реальная граница даже ниже, если учитывать ресурсы процессора, которые использует для своих нужд сам гипервизор.

Кластер Arenadata DB был развёрнут в следующей конфигурации:

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

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

Значение переподписки для сценария № 3 составляет 1:1,33 (128 vCPU / 96 T). Здесь вполне уместным может оказаться вопрос — почему было взято соотношение 1:1,33? Почему не 1:2, не 1:3? Ответ прост: такое значение получилось после размещения всего кластера Arenadata DB на одном физическом сервере.

Инструмент тестирования

В качестве основного инструмента тестирования производительности и стабильности работы Arenadata DB мы используем свой форк отраслевого стандарта TPC-DS. Параметром сравнения производительности считаем время исполнения запросов в мультипользовательском режиме (параметр CONCURRENCY задаёт количество одновременно работающих пользователей). Исходный тест состоял из 99 запросов, выполняемых последовательно в рамках одной пользовательской сессии. В нашем форке мы выделили 51 самый быстрый запрос и обозвали этот тест lite. Этот тест позволяет в приемлемые сроки оценить производительность кластера под высокой параллельной нагрузкой (до 100 пользовательских сессий включительно). Можно сказать, что это стресс-тест для вычислительных мощностей физического сервера. Исходный же набор в 99 запросов мы обозвали full и используем его с целью нагрузить по полной подсистему ввода/вывода физического сервера. Для такого теста высокая параллельная нагрузка не нужна (тестируем до 8 пользовательских сессий).

Результаты

Для каждого сценария проводилось три замера серии тестов lite и три замера серии тестов full. Серия тестов — один замер с последовательным ступенчатым увеличением параметра CONCURRENCY. В таблице ниже приведены средние значения времени выполнения всех запросов при заданной CONCURRENCY. Трактовать значения времени просто — чем быстрее завершился тест, тем лучше.

Для оценки нехватки вычислительных ресурсов также использовали дополнительный показатель: количество предупреждений о неудачной доставке датаграмм в журналах Arenadata DB. Дело в том, что ADB в качестве сетевого транспорта по умолчанию использует протокол UDP, а контроль доставки реализует сама. При отсутствии подтверждения доставки датаграммы от принимающего сегмента отправляющий сегмент повторяет её отправку, а когда таких неудачных повторов накапливается 100 штук подряд, фиксирует одно предупреждение в журнале событий. В виртуальной среде мы довольно часто видим подобные предупреждения на больших CONCURRENCY. Обычно они связаны с высокой конкуренцией за вычислительные ресурсы и их нехваткой для того, чтобы успеть обработать сетевой трафик за отведённые таймауты. Чем позднее (на больших значениях CONCURRENCY) появляются эти предупреждения и чем их меньше, тем лучше. В идеале их вообще быть не должно.

За эталон был взят идеальный сценарий № 1. Относительно него высчитывали изменение времени в сценариях № 2 и 3. Положительные значения % означают увеличение времени исполнения пользовательских запросов.

_{x — при CONCURRENCY = 24 завершился только один замер из трёх, начиная с CONCURRENCY = 28 успешно завершённые замеры отсутствуют.}

Ухудшение производительности в сценарии № 2 объясняется описанной выше логикой работы планировщика задач Linux. В этом сценарии всем vCPU (64) не хватало физических ядер (48), и поэтому активно использовалась многопоточность (hyper-threading). Стоит резонно заметить, что при размещении VM с 96 vCPU вместо 64 (всё ещё без переподписки) производительность упадёт ещё больше.

В сценарии № 3 ситуация значительно ухудшается. Из 96 доступных логических процессоров одновременно запрашивается 128 (без учёта потребностей самого гипервизора). Потоки выполнения вынуждены простаивать в очереди за процессорными ресурсами, что выражается увеличением времени исполнения запросов в два-три раза! Более того, в сценарии № 3 в процессе запусков тестов lite виртуальные машины кластера становились недоступны, и требовалась ручная перезагрузка с последующей ребалансировкой сегментов для восстановления работоспособности кластера. При втором замере потребовалась полная копия данных для восстановления сегментов. При третьем все VM кластера перешли в состояние недоступности.

Дополнительно стоит отметить, что с ростом плотности размещения VM на физическом сервере раньше начинают появляться предупреждения сети. Так, в сценарии № 1 они отсутствовали вовсе, в сценарии № 2 появились начиная с CONCURRENCY = 24, в сценарии № 3 — с CONCURRENCY = 20.

Ниже приведены графики утилизации процессора CPU usage % и CPU steal, также в процентах. Если с CPU usage, я думаю, всё понятно, то про steal time вкратце позволю себе напомнить. Это время, в течение которого виртуальная машина не получает ресурсы процессора для выполнения, то есть она готова исполнять код и ожидает процессорные ресурсы, которые в данный момент заняты. Эта метрика отдаётся гипервизором внутрь VM, и изнутри VM мы её и снимали, как и CPU usage.

Сценарий № 1 lite

Сценарий № 1 full

Сценарий № 2 lite

Сценарий № 2 full

Сценарий № 3 lite

Сценарий № 3 full

На графиках видно, что CPU steal в сценариях № 1 и 2 показывают околонулевые значения, в то время как в сценарии № 3 можно наблюдать пики до 40%, что подтверждает дефицит процессорных ресурсов.

Ну и в последний раз приведу таблицу сценариев, дополнив её результатами исследования:

Итоги

Сценарий № 1 обеспечивает наилучшую производительность и стабильную работу кластера Arenadata DB, а также одинаковую производительность каждого узла кластера. По этим показателям он наиболее близок к размещению на baremetal. Этот сценарий требует организации частного решения в облаке.

Размещение VM по сценарию № 2 — это то, что можно ожидать в облаке без переподписки. Производительность кластера ниже, чем в сценарии № 1, но, во всяком случае, он работает стабильно, без падений. Производительность узлов кластера непостоянна, она зависит от наличия и «шумности» соседей по физическому серверу. Постоянство производительности узлов можно обеспечить дополнительными техническими средствами, например применением технологии CPU pinning.

Сценарий № 3 с применением переподписки по вычислительным ресурсам существенно замедляет работу кластера Arenadata DB, а по достижении определённого порога нагрузки возможно его падение. Производительность узлов кластера также непостоянна.

Исследование показало, что кластер Arenadata DB может быть запущен в облачной среде с переподпиской по вычислительным ресурсам и что он способен функционировать в такой среде. Однако подобное размещение приводит к значительному ухудшению производительности и стабильности работы кластера. Возможные падения системы и, как следствие, простои в обслуживании пользователей делают использование подобного подхода крайне рискованным. Такое поведение системы не позволяет предоставлять качественные услуги технической поддержки. В связи с этим настоятельно не рекомендуется применять переподписку по вычислительным ресурсам в продуктивных средах.