В прошлом году мы активно взялись за быстродействие больших тяжелых баз данных в нашем облаке. На первый взгляд казалось, что у нас только 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).

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