У нас есть базовые группы доступности (BAG) SQL Server, настроенные для запуска базы данных SQL, работающей на локальном SSD-диске Intel. Меня попросили переместить базу данных в экземпляр отказоустойчивого кластера SQL Server (FCI), чтобы повысить производительность SQL Server: запустить базу данных на виртуальном диске высокой доступности, работающем на программно-определяемом хранилище. По моему опыту, гиперконвергентный VSAN должен удваивать операции чтения, поэтому задержка ввода-вывода SQL (для чтения из базы данных) должна уменьшиться вдвое.
Таким образом, были протестированы два сценария: SQL BAG и SQL FCI. Для этих двух случаев максимальный объем оперативной памяти сервера 512 ГБ был установлен на SQL Server, чтобы исключить кэширование и выполнять операции справедливого чтения из таблицы базы данных.
SQL Management Studio и SQLQueryStress использовались для тестирования. Оператор SQL SELECT TOP (500000) ... FROM [SQL].[dbo].[table] для чтения первых 500К строк.
Результаты запроса SQL BAG следующие:
Management Studio SQL: время запроса = 15 с.
SQLQueryStress:
Количество потоков = 1: время запроса = 2 секунды
Количество потоков = 2: время запроса = 2 секунды
Количество потоков = 4: время запроса = 2 секунды
Количество потоков = 8: время запроса = 2 секунды
Количество потоков = 10: время запроса = 3 секунды
Количество потоков = 12: время запроса = 4 секунды
Сценарий SQL FCI был построен на отказоустойчивом кластере Windows из двух идентичных аппаратных узлов под управлением Windows Server 2016. Хранилище было настроено с использованием программно-определяемого хранилища (гиперконвергентного VSAN) на SSD-дисках Intel. Таким образом, виртуальный диск был представлен в отказоустойчивом кластере как диск кластера. Для тестирования Cluster Disk я использовал diskspd
Результаты diskspd следующие:
Случайное чтение 4k - 76K IOPS (SSD), 153K IOPS (гиперконвергентный VSAN - кластерный диск)
Случайное чтение 8k - 45K IOPS (SSD), 89K IOPS (гиперконвергентный VSAN - кластерный диск)
Как я и ожидал, гиперконвергентная VSAN удвоила производительность хранилища. В дальнейшем SQL FCI был настроен для хранения файлов базы данных на этом кластерном диске. Еще одна копия базы данных была загружена на сервер, и были выполнены те же тесты.
Результаты запроса SQL FCI следующие:
Management Studio SQL: время запроса = 15 с.
SQLQueryStress:
Количество потоков = 1: время запроса = 9 секунд
Количество потоков = 2: время запроса = 8 секунд
Количество потоков = 4: время запроса = 9 секунд
Количество потоков = 8: время запроса = 8 секунд
Количество потоков = 10: время запроса = 10 секунд
Количество потоков = 12: время запроса = 12 секунд
Вопросы следующие:
Почему задержка одинакова для SQL BAG и SQL FCI, проверенных с помощью Management Studio?
Что может увеличить задержку в 3-4 раза для SQL FCI базы данных?
FCI - это история, придерживайтесь AlwasysOn Availability Groups (AG) для своих новых развертываний. Это намного быстрее (потому что SQL Server знает, что реплицировать), и, по крайней мере, базовые группы доступности включены в стандартную версию SQL Server.