Как мы разгоняли кластер для нагруженных баз Microsoft SQL и получали заветные 200 000 IOPS
В прошлом году мы активно взялись за быстродействие больших тяжелых баз данных в нашем облаке. На первый взгляд казалось, что у нас только 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).
Решение: как и какие цифры получили
Производительность измеряли двумя независимыми инструментами. В качестве рекомендуемого использовали фреймворк 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% Random Read |
|
BW (MB/s) per Volume |
19000 |
|
BW (MB/s) per VM |
380 |
Второй тест. Нам хотелось узнать максимум, на что способны эти хосты, так что решили нагрузить их по полной. Переподписку уменьшили до 2:1 (по 25 ВМ на хост), а порог загрузки CPU убрали. Паттерн теста был такой: 100% рандомное чтение блоком 4К с 4 тредами и глубиной 16 каждая. Вот что мы получили на выходе.
Сравнили результаты с FIO и с удивлением обнаружили, что данные практически одинаковы.
В результате для сервиса DBaaS Microsoft SQL мы смогли без сверхдорогих СХД значительно улучшить производительность. Для базы данных до 4 ТБ можем гарантировать до 200 000 IOPS с задержками менее 1 мс при 100% чтении блоком 4k.
Сейчас мы планируем цикл вебинаров по внутреннему устройству и принципам работы гиперконвергентных решений на базе Windows Server 2019 и технологии Storage Spaces Direct. Так что буду рад вашим вопросам!