[IT-инфраструктура, Виртуализация, Microsoft SQL Server, Администрирование баз данных] Как мы разгоняли кластер для нагруженных баз Microsoft SQL и получали заветные 200 000 IOPS
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В прошлом году мы активно взялись за быстродействие больших тяжелых баз данных в нашем облаке. На первый взгляд казалось, что у нас только 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. Решение: как и какие цифры получили Производительность измеряли двумя независимыми инструментами. В качестве рекомендуемого использовали фреймворк 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, b2mMetrics100% Random ReadBW (MB/s) per Volume19000BW (MB/s) per VM380Второй тест. Нам хотелось узнать максимум, на что способны эти хосты, так что решили нагрузить их по полной. Переподписку уменьшили до 2:1 (по 25 ВМ на хост), а порог загрузки CPU убрали. Паттерн теста был такой: 100% рандомное чтение блоком 4К с 4 тредами и глубиной 16 каждая. Вот что мы получили на выходе. 
Видим, что задержки Read Lat довольно низкие.Сравнили результаты с FIO и с удивлением обнаружили, что данные практически одинаковы.В результате для сервиса DBaaS Microsoft SQL мы смогли без сверхдорогих СХД значительно улучшить производительность. Для базы данных до 4 ТБ можем гарантировать до 200 000 IOPS с задержками менее 1 мс при 100% чтении блоком 4k.Сейчас мы планируем цикл вебинаров по внутреннему устройству и принципам работы гиперконвергентных решений на базе Windows Server 2019 и технологии Storage Spaces Direct. Так что буду рад вашим вопросам!
===========
Источник:
habr.com
===========
Похожие новости:
- [Настройка Linux, Системное администрирование, Софт, Накопители] Самый актуальный гайд по установке Linux на SSD-накопители в 2021 году
- [IT-инфраструктура, Сетевые технологии, Сетевое оборудование] Как умные сети ЦОД помогают крупному банку справляться с кризисом
- [Разработка под iOS, Разработка мобильных приложений, Администрирование баз данных, Swift] Быстрый, простой, сложный: как мы выпилили Realm
- [Системное администрирование, Программирование, IT-инфраструктура, DevOps] Создание современных процессов CI/CD для бессерверных приложений с Red Hat OpenShift Pipelines и Argo CD. Часть 2 (перевод)
- [PostgreSQL, SQL, Администрирование баз данных] Расширение кластера PostgreSQL размером 5,7 ТБ и переход с версии 9.6 на 12.4 (перевод)
- [Open source, Администрирование баз данных, Big Data, Data Engineering] EventNative – простой инструмент для записи потока событий в ClickHouse (перевод)
- [Администрирование баз данных, Big Data, Data Engineering] Аналитический движок Amazon Redshift + преимущества Облака
- [Информационная безопасность, Анализ и проектирование систем, SQL, Администрирование баз данных, Геоинформационные сервисы] Внешний ключ должен вести не на сущность, а на актуальную версию этой сущности
- [Анализ и проектирование систем, IT-инфраструктура, Nginx, Mesh-сети, DevOps] Зачем нужен обратный прокси сервер в 5 актах
- [Системное администрирование, Серверное администрирование, Администрирование баз данных, Хранение данных] Понимание LDAP-протокола, иерархии данных и компонентов записей (перевод)
Теги для поиска: #_itinfrastruktura (IT-инфраструктура), #_virtualizatsija (Виртуализация), #_microsoft_sql_server, #_administrirovanie_baz_dannyh (Администрирование баз данных), #_microsoft_sql, #_ms_sql, #_iops, #_blog_kompanii_dataline (
Блог компании DataLine
), #_itinfrastruktura (
IT-инфраструктура
), #_virtualizatsija (
Виртуализация
), #_microsoft_sql_server, #_administrirovanie_baz_dannyh (
Администрирование баз данных
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:08
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
В прошлом году мы активно взялись за быстродействие больших тяжелых баз данных в нашем облаке. На первый взгляд казалось, что у нас только 2 варианта: недорогие СХД с медленными дисками или очень дорогие СХД – с быстрыми. Мы же хотели ускорить работу высоконагруженных баз данных Microsoft SQL и при этом предложить клиентам выгодную стоимость услуги. В результате тестов мы собрали решение "Кластер для нагруженных баз данных Microsoft SQL в облаке". Сегодня заглянем внутрь и добавим чуть больше технических вводных и конкретных цифр. Пост не претендует на deep dive и не раскрывает всех технических нюансов, а лишь демонстрирует результаты нашего тестирования. Я покажу, на каком железе, софте и конфигурации сети мы проводили тесты быстродействия БД, каким способом тестировали и какие результаты получили.  Условия задачи: на чем проверяли быстродействие БДКак выбирали железо под кластер. На старте мы искали серверы с такими характеристиками:
 Как мы и хотели, это сервер форм-фактора 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.
  Как организовали отказоустойчивость на уровне софта. На программном уровне работу платформы обеспечивают 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. Решение: как и какие цифры получили Производительность измеряли двумя независимыми инструментами. В качестве рекомендуемого использовали фреймворк 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, b2mMetrics100% Random ReadBW (MB/s) per Volume19000BW (MB/s) per VM380Второй тест. Нам хотелось узнать максимум, на что способны эти хосты, так что решили нагрузить их по полной. Переподписку уменьшили до 2:1 (по 25 ВМ на хост), а порог загрузки CPU убрали. Паттерн теста был такой: 100% рандомное чтение блоком 4К с 4 тредами и глубиной 16 каждая. Вот что мы получили на выходе.  Видим, что задержки Read Lat довольно низкие.Сравнили результаты с FIO и с удивлением обнаружили, что данные практически одинаковы.В результате для сервиса DBaaS Microsoft SQL мы смогли без сверхдорогих СХД значительно улучшить производительность. Для базы данных до 4 ТБ можем гарантировать до 200 000 IOPS с задержками менее 1 мс при 100% чтении блоком 4k.Сейчас мы планируем цикл вебинаров по внутреннему устройству и принципам работы гиперконвергентных решений на базе Windows Server 2019 и технологии Storage Spaces Direct. Так что буду рад вашим вопросам! =========== Источник: habr.com =========== Похожие новости:
Блог компании DataLine ), #_itinfrastruktura ( IT-инфраструктура ), #_virtualizatsija ( Виртуализация ), #_microsoft_sql_server, #_administrirovanie_baz_dannyh ( Администрирование баз данных ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:08
Часовой пояс: UTC + 5