Как мы разгоняли кластер для нагруженных баз 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. Так что буду рад вашим вопросам!

MS SQL как сервис
MS SQL как сервис

Сервис по предоставлению готовой базы данных MS SQL с необходимыми параметрами на основе инфраструктуры DataLine.

  • Аутсорсинг всех вопросов по администрированию БД, физической, виртуальной инфраструктуры и ОС.
  • Русскоязычная техподдержка от специалистов 24х7 по почте и телефону.
  • В услугу включено резервное копирование с регулярной проверкой восстановления копий.
  • Быстрое развертывание готовой базы данных необходимой конфигурации.
Больше информации об услуге по ссылке
Расскажите друзьям и коллегам о статье
  • Поделиться
  • Поделиться
  • Поделиться

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

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

02 сентября
Антон Турсунов

Тестовая миграция и DR между платформами с помощью Hystax DR 3.7.1701.

26 августа
Валерий Петренко

Что делают инженеры наших дата-центров для подготовки ко встрече со стихией.

12 августа
Алексей Сидоров

Подпишитесь на нашу рассылку

Получайте свежие и полезные материалы и приглашения на наши мероприятия