Технология Storage Spaces в составе Microsoft Windows Server 2016 управляет дисковой подсистемой сервера без применения аппаратных RAID-контроллеров. Получается производительно, надежно, с минимумом ручного управления.
Пройдем пошагово процедуру настройки «производительного сервера баз данных» средствами Windows Server 2016. Начнем с платформы.
Платформа под SQL-сервер
Windows Server 2016 лицензируется по числу физических процессорных ядер сервера: 16 в базовой поставке, за остальные надо доплачивать. Лицензирование SQL Server 2016 тоже привязано к числу процессоров/ядер. При одинаковой стоимости Intel Xeon E5 2690 v4 (14 core, 2.6GHz) и Intel Xeon E5 2667 v4 (8 core, 3.2GHz), затраты на ПО для двухпроцессорных серверов на них могут отличаться вдвое.
Рекомендации по выбору CPU под нагрузку OLTP известны и применимы для любых реализаций SQL. Database Hardware and Infrastructure Trends так и советует: берите процессоры с высокой тактовой частотой. Мы взяли 2 х Intel Xeon E5 2643 v4 (6 core, 3.4 GHz).
Оперативной памяти много не бывает (а современные CPU адресуют до 1.54 TB RAM), но принцип разумной достаточности никто не отменял. Windows Server 2016 для комфортной работы нужно 64 GB RAM. Памяти в сервер ставят столько, чтобы в нее помещалось 20-30% от объема таблиц базы данных. Можно больше — SQL RAM Cache пустит в дело доступный объём.
Storage Spaces
Встроенная в Windows Server 2016 технология Storage Spaces управления логическими объединениями дисков работает с тремя типами устройств:
Их можно комбинировать, ранжируя по скорости/емкости:
В Windows Server 2016 есть технология распределенного хранения, Storage Spaces Direct (S2D). Она собирает локальные диски нескольких серверных узлов в кластер и презентует объединенное хранилище всем серверам кластера. S2D поддерживает три уровня распределения данных (tiers), с участием трех типов дисков:
Кэш и транзакционный лог — на самых скоростных носителях, NVMe SSD
Производительный слой — на следующих по скорости носителях, SATA/SAS SSD
Емкий слой — на недорогих HDD: относительно медленный, но эффективный по цене хранения
S2D работает в кластере, требует минимум двух узлов для развертывания и лицензии DataCenter Edition для каждого узла.
В нашем случае одиночного сервера технология Storage Spaces повторяет двухуровневую стратегию Windows Server 2012 R2: на производительном и емком слоях, без кэша. Три уровня хранения на отдельно взятом сервере будут перебором. Если на роль «горячего слоя» выбраны NVMe, остальные носители (SSD, HDD) становятся «холодным слоем». Именовать слои можно как угодно (например Tier 0 / Tier 1).
Наша дисковая подсистема будет all-flash — мы боремся за производительность. Вообще говоря, двухуровневое хранение средствами Storage Spaces не является универсальным решением под приложения с интенсивной дисковой нагрузкой, но интересно нам в качестве технологического примера. Для нагруженных реляционных баз данных (OLTP) может оказаться более эффективным использование одноуровневых томов: на NVMe SSD под журнал транзакций MS SQL Server, на SATA SSD под данные. Под расчет кубов OLAP можно просто ограничиться емкими SATA SSD. Важно то, что входящая в стандартную ОС технология Storage Spaces дает свободу маневра при выжимании производительности, доступными средствами.
Чтобы построить два уровня (tiers) в all-flash-постановке, придется прибегнуть к небольшому трюку (подробнее о нем ниже). Дело в том, что у Storage Spaces есть параметр автоматического определения типа носителей, MediaType. Он принимает одно из трех значений: HDD, SSD, SCM (используется для томов на экзотической памяти NVDIMM). В отсутствие HDD, любые массовые носители на флэш-памяти с точки зрения Storage Spaces будут иметь одинаковый MediaType — SSD.
К делу. Помимо загрузочной пары SATA SSD под ОС у нас есть:
2 х U.2 NVMe SSD (800 ГБ HGST Ultrastar SN100)
4 х SATA SSD (1.92 ТБ SanDisk CloudSpeed Eco Gen II)
2 х SATA SSD (480 ГБ SanDisk CloudSpeed Eco Gen II)
Первые две группы носителей соберем в логический том таблиц баз данных (DB), он будет с двумя уровнями хранения:
Tier 0 — на U.2 NVMe SSD
Tier 1 — на SATA SSD относительно большой емкости (чтобы хватило любой DB)
Оставшуюся пару небольших SATA SSD соберем в отдельный том под SQL log. Там же можно держать tempDB. Таким образом, планируем создать два логических тома, один из которых двухуровневый.
Дисковые пулы
Вначале создаем пул Pool_DB
Добавляем в него диски 2 х U.2 NVMe SSD 800 ГБ и 4 х SATA SSD 1.92 ТБ
В интерпретаторе командной строки PowerShell получаем список доступных дисков:
Get-PhysicalDisk | Sort-Object FriendlyName |? MediaType -eq SSD | FT FriendlyName,FirmwareVersion,Size,Manufacturer,
LogicalSectorSize,PhysicalSectorSize,MediaType
То, что Storage Spaces не различает NVMe SSD и SATA SSD, хорошо видно на скриншоте в колонке MediaType — оба определяются как SSD. Чтобы собрать в Storage Spaces двухуровневое хранилище Tier 0 / Tier 1, нужны диски с разными значения параметра MediaType для каждой группы дисков. Простой способ создать два уровня хранения из дисков с одинаковым значением MediaType — переименовать одну из групп. Оставим имя SSD для Tier 0 (NVMe SSD), а Tier 1 (SATA SSD) назовем HDD. Заодно, для дальнейшего удобства администрирования, переименуем сами диски (FriendlyName, левая колонка на скриншоте). Запускаем в PowerShell:
Set-PhysicalDisk -FriendlyName «NVMe HUSPR3280ADP301» -MediaType SSD -NewFriendlyName SSD_Tier0
Set-PhysicalDisk -FriendlyName «ATA SDLF1CRR-019T-1J» -MediaType HDD -NewFriendlyName SSD_Tier1
Проверяем получившееся командой:
Get-PhysicalDisk -CanPool $false | Sort-Object FriendlyName | FT FriendlyName,FirmwareVersion,Size,Manufacturer,
LogicalSectorSize,PhysicalSectorSize,MediaType
Имея два набора «разнотипных» дисков, собираем двухуровневый пул хранения Storage Space.
Высокая производительность дисковой подсистемы подразумевает единственную стратегию отказоустойчивого хранения для дисковой группы — mirror.
Из двух оставшихся дисков SATA SSD создаем еще один дисковый пул Pool_tempDB_Log, виртуальный диск SS_tempDB_Log, также mirror.
Таким образом, мы получаем два независимых пространства хранения для SQL-сервера под DB и SQL Log. Одно из которых, Pool_DB, имеет два уровня хранения Tier 0 / Tier 1 с дисками NVMe SSD и SATA SSD соответственно. А второе, Pool_tempDB_Log состоит из одних только SATA SSD дисков, одноуровневое.
После разбивки пространства хранения, MS SQL Server устанавливается стандартным образом: c размещением DB — на томе «Pool_DB», а SQL Log и tempDB — на томе Pool_tempDB_Log .
«Производительный сервер баз данных» готов к работе.
Коротко о целях и средствах
Производительный сервер баз данных можно построить на доступных типовых компонентах, стандартными средствами ОС Windows Server 2016
Для этого не нужны дорогостоящие аппаратные RAID-контроллеры и, тем более, внешние дисковые массивы
Двухуровневое хранение Tier 0 / Tier 1 может быть реализовано на связке SSD/HDD, или, как в нашем случае, на NVMe/ SATA SSD. Конкурентное преимущество состоит в сочетании высокой производительности NVMe SSD и относительно невысокой цены емких, Read-intensive SATA SSD. Его оценят пользователи объемных баз данных (OLTP и OLAP), систем документооборота (как MS SharePoint /MS SQL Server, где есть и таблицы базы данных, требующие максимального быстродействия, и сканированные изображения объемного хранения, которые надо быстро вычитывать).
Как часть гиперконвергентного решения, с ролью SQL-сервера, такой серверный узел легко масштабируется по хранению. Для увеличения объема хранения любого из томов в него добавляются диски, средствами Storage Space пул растягивается на добавленную емкость, без остановки сервиса. Дальнейшее развитие подхода — построение отказоустойчивого кластера серверов на основе технологии Storage Spaces Direct.