Как мы разгоняли кластер для нагруженных баз Microsoft SQL

Рассказываем, как мы тестировали новую конфигурацию DBaaS и получали те самые 200 000 IOPS для баз до 4 TB.

28 января  • 

В прошлом году мы активно взялись за быстродействие больших тяжелых баз данных в нашем облаке. На первый взгляд казалось, что у нас только 2 варианта: недорогие СХД с медленными дисками или очень дорогие СХД – с быстрыми.

Мы же хотели ускорить работу высоконагруженных баз данных Microsoft SQL и при этом предложить клиентам выгодную стоимость услуги. В результате тестов мы собрали решение “Кластер для нагруженных баз данных Microsoft SQL в облаке”. Сегодня заглянем внутрь и добавим чуть больше технических вводных и конкретных цифр.

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

Условия задачи: на чем проверяли быстродействие БД

Как выбирали железо под кластер. На старте мы искали серверы с такими характеристиками:

  • Имеют форм-фактор 1U. Какое-то время у нас были громоздкие четырехсокетные платформы с форм-фактором 2U, но так у нас было меньше возможностей “размазать” кластер по залам и повысить отказоустойчивость. Плюс в случае 1U уменьшается еще и домен отказа: меньше виртуальных машин перезагружается при падении хоста.
  • Поддерживают установку бэкплейна на 10 отсеков с дисками формата U.2. В этом случае можно поставить много модных сейчас быстрых дисков NVMе. А чем больше у нас дисков, тем больше места для данных.
  • Поддерживают Intel Optane DC Persistent Memory модули.
  • Находятся в Hardware compatibility list (HCL) вендора Microsoft – так мы будем уверены в поддерживаемости конфигураций вендором.
  • Ну и цена должна нас устраивать.

В результате мы остановили свой выбор на бренде Supermicro и модели 1029U-TN10RT:

Как мы и хотели, это сервер форм-фактора 1U, на котором можно разместить 2 процессора Intel Xeon Scalable.

Вот полная спецификация:

  • Шасси – Ultra 1U SYS-1029U-TN10RT.
  • CPU – 2 x Intel Xeon Gold 6246 (3.3GHz, 12C).
  • Storage – 10 x Intel DC P4510 1TB NVMe SSD, 1DWPD.
  • DRAM – 12 x 64GB DDR4-2666.
  • Persistent Memory – 2 x 128GB DDR4-2666 Intel Optane DC PMMs.
  • Network – 2 x 25GbE Mellanox ConnectX-4 Lx.

Практически вся передняя часть занята отсеками 2,5 дюйма для накопителей NVMe: как раз те самые 10 отсеков для дисков формата U.2.

Как организовали отказоустойчивость на уровне софта. На программном уровне работу платформы обеспечивают Windows Server 2019 и технология Storage Spaces Direct. Она позволяет объединить локальные диски серверов в подобие сетевого RAID – избыточного массива независимых дисков.

Сначала мы провели тест на двухузловом кластере и в итоге перешли к более надежной трехузловой конфигурации. Узлы кластера серверов разнесены по трем машинным залам. В качестве уровня избыточности томов используется 3-way Mirroring, так что данные каждой виртуальной машины хранятся в 3 копиях.

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

Как разбирались с задержками сети. Мы старались минимизировать задержки случайных операций записи и повысить производительность сети и хоста. Для этого мы уменьшали нагрузку на процессор и повышали пропускную способность. В результате решили использовать RDMA – удаленный прямой доступ к памяти. Выбрали сетевые карты Mellanox ConnectX-4 Lx c поддержкой RoCEv2 (RDMA over Converged Ethernet).

Удаленный прямой доступ к памяти (RDMA) обеспечивает прямой доступ из памяти одного хоста к памяти другого хоста без привлечения удаленной операционной системы и процессора
Благодаря RoCE мы разгружаем транспорт и процессор. Картинку взял у Mellanox

Решение: как и какие цифры получили

Производительность измеряли двумя независимыми инструментами. В качестве рекомендуемого использовали фреймворк VMFleet от Microsoft, а для чистоты эксперимента измеряли еще и при помощи FIO.

Первый тест. Для тестирования мы смоделировали среднестатистическую нагрузку для “тяжелых” баз данных. Развернули около 150 виртуальных машин c “толстыми” дисками по 40 GB, по 50 виртуальных машин на хост. Переподписка – 4:1, порог утилизации CPU – не более 60%. Количество томов – 3, объемом по 3 TB каждый.

На выходе мы получили такие данные.

CPU Oversubscription 4:1

Pattern: t1, o32, b16k
Metrics 100% Random Read 90% Random Read / 10% Random Write 70% Random Read / 30% Random Write
IOPS per Volume 475000 275000 169000
Latency per Volume 0,2 ms 0,2 ms / 0,4 ms 0,2 ms / 0,4 ms
BW (MB/s) per Volume 7750 4500 2750
IOPS per VM 9500 5500 3380
BW (MB/s) per VM 155 90 55
IOPS per GB 237 137 84
Pattern: t1, o32, b4k
Metrics 100% Random Read 90% Random Read / 10% Random Write 70% Random Read / 30% Random Write
IOPS per Volume 509000 282000 190000
Latency per Volume 0,12 ms 0,12 ms / 0,33 ms 0,13 ms / 0,36 ms
BW (MB/s) per Volume 2000 1150 780
IOPS per VM 10180 5640 3800
BW (MB/s) per VM 40 23 15
IOPS per GB 254 112 76
Pattern: t1, o32, b2m
Metrics 100% Sequential Read
BW (MB/s) per Volume 19000
BW (MB/s) per VM 380

Второй тест. Нам хотелось узнать максимум, на что способны эти хосты, так что решили нагрузить их по полной. Переподписку уменьшили до 2:1 (по 25 ВМ на хост), а порог загрузки CPU убрали. Паттерн теста был такой: 100% рандомное чтение блоком 4К с 4 тредами и глубиной 16 каждая. Вот что мы получили на выходе.

Видим, что задержки Read Lat довольно низкие
Видим, что задержки Read Lat довольно низкие

Сравнили результаты с FIO и с удивлением обнаружили, что данные практически одинаковы.

В результате для сервиса DBaaS Microsoft SQL мы смогли без сверхдорогих СХД значительно улучшить производительность. Для базы данных до 4 ТБ можем гарантировать до 200 000 IOPS с задержками менее 1 мс при 100% чтении блоком 4k.

Сейчас мы планируем цикл вебинаров по внутреннему устройству и принципам работы гиперконвергентных решений на базе Windows Server 2019 и технологии Storage Spaces Direct. Так что буду рад вашим вопросам!

Расскажите друзьям и коллегам о статье
  • Поделиться
  • Поделиться
  • Поделиться

Последние статьи

Как мы следим за средней мощностью стойки и благодаря этому экономим свои ресурсы и ресурсы заказчика.

04 марта
Кирилл Шадский

Фотоэкскурсия по новом петербургскому ЦОДу на Жукова, 43.

25 февраля
DataLine

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

18 февраля
DataLine

Комментарии

Подписка на статьи

randomness