`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Что для вас является метрикой простоя серверной инфраструктуры?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

NVMe и Microsoft SQL

+88
голосов

Для производительной работы с базами данных Microsoft SQL не обязательно строить гиперконвергентную инфраструктуру Storage Spaces Direct на нескольких серверах или инвестировать в дорогостоящую SAN. Локальные NVMe-накопители ускоряют обслуживание запросов «малой кровью», без ущерба надежности.

Серверы баз данных – приложения, критичные к скорости обработки запросов случайного доступа, с большой долей операций записи. Флэш-технологии быстро вытесняют из них механические диски – те неспособны обеспечить низкие задержки обращения к данным. Надо быть закоренелым старовером, чтобы сегодня снарядить OLTP-сервер массивом SAS HDD:

NVMe и Microsoft SQL

 NVMe vs Legacy (16 х SAS 15K HDD RAID 10). Источник: Micron

Поскольку ускорение операций ввода-вывода (I/O) разгружает CPU от процесса ожидания обработки дисковых очередей, вычислительный ресурс можно отдать другим приложениям и обойтись меньшим числом серверов. Ниже затраты на оборудование, энергоснабжение, охлаждение, программные лицензии. Ради более производительного I/O стоит отказаться от вложений в SAN и дисковые массивы - дорогие, сложные в управлении.

В гиперконвергентной инфраструктуре (например, Microsoft Storage Spaces Direct, S2D) данные хранятся на локальных дисках. Емкости современных твердотельных накопителей достаточно для обслуживания большинства баз данных. Реализации all-flash (AF) S2D на типовых серверах проще и продуктивнее инфраструктуры SAN. В AF-узлы ставят NVMe SSD (Cache) и SAS/SATA SSD (Capacity). Больше узлов –выше устойчивость к сбоям, эффективнее использование дискового пространства, гибче политики кэширования. Пример масштабной постановки.

Что SAN, что распределенное хранение построены на приоритете доступности данных над производительностью I/O. «Непрерывность» всегда дается дорогой ценой, потому никогда не помешает здравая оценка рисков и оптимизация затрат. Есть простые, но действенные способы обустройства серверов баз данных, с приоритетом продуктивности и разумным балансом избыточности/общей стоимости решения.

Преимущества NVMe над SAS и SATA SSD

В борьбе за рост IOPS и снижение задержек из серверов вытесняются промежуточные звенья между CPU и устройствами хранения: контроллеры интерфейсов, стеки SAS (SCSI) и SATA. Вычислительные циклы, которые уходят на преобразования сигналов в них, тратятся впустую. Подключение NVMe по шине PCIe непосредственно к CPU позволяет обрабатывать жесткие рабочие нагрузки приложений компактными решениями с меньшими накладными расходами.

NVMe поддерживает 64K очередей I/O, 64K команд в каждой – тогда как SAS и SATA работают одиночными очередями, с глубиной 254 и 32 команд соответственно. Но главное преимущество NVMe – в низкой латентности, на уровне 25 микросекунд у NVMe SSD на памяти NAND и 10 микросекунд у Intel Optane на памяти 3D XPoint. Это в 3-8 раз лучше, чем у SAS/SATA SSD (65-75 микросекунд), и в десятки раз лучше показателей HDD с их миллисекундами.

Потенциал протокола многогранен, а уместное применение NVMe-накопителей дает серверам радикальный прирост производительности.

Windows Storage Spaces

Технология Storage Spaces (SS) встроена в операционную систему Microsoft Windows Server. C ее помощью накопители собирают в логические объединения и презентуют приложениям как виртуальные диски с выбранными политиками отказоустойчивости.

NVMe SSD хороши под кэширование записи (write back cache), в качестве быстрого слоя (tier) перед массивом HDD в гибридной конфигурации, в томах под данные, требующие минимальных задержек – как журнал транзакций MS SQL.

Для нагруженных реляционных баз данных достаточно одноуровневых томов NVMe SSD – и под данные DB, и под SQL log. Двухуровневое хранение (tiering) применяется реже, для объемных баз с существенной долей «холодных» данных. Чтобы построить два уровня (tiers) в AF-постановке, понадобится небольшой трюк. У SS есть параметр MediaType автоматического определения типа носителей. Он принимает одно из трех значений: HDD, SSD, SCM (используется для томов на памяти NVDIMM). Без HDD любые массовые носители на флэш-памяти с точки зрения SS будут иметь одинаковый MediaType — SSD. Простой способ создать два уровня хранения из таких дисков – переименовать одну из групп: оставив имя SSD для Tier 0 на NVMe SSD и назвав Tier 1 на SAS/SATA SSD псевдонимом HDD. Подробнее: Производительное хранение средствами Windows Server 2016.

Не все данные одинаково критичны

Ускорить отклик дисковой подсистемы можно добавлением в существующие серверы NVMe SSD под временные данные. К таким относятся tempDB - базы промежуточных объектов (таблиц, переменных, процедур), создаваемых при старте Microsoft SQL. Какое бы решение под базу данных не использовалось: SAN высокой доступности, Windows Storage Spaces/SAS JBOD, или  Always On Availability Groups, сложные запросы, требующие создания большого количества временных таблиц, выполняются быстрее на локальных дисках.

Под активную запись множества мелких файлов, как в tempDB, хороши любые NVMe на флэш-памяти, но абсолютный чемпион - Intel Optane на  памяти 3D XPoint. Его производительность: 2-2.5 GB/s в последовательном, 500-550 K IOPS в случайном доступе, с латентностью в 10 микросекунд, причем на малой очереди запросов. Optane дороже NAND SSD, но область данных tempDB обычно невелика, хватит накопителей малой емкости. Например, NVMe SSD HGST Ultrastar SN200 на 800GB  обойдется в $1,100, а если достаточно 280GB – идеально подойдет Intel Optane серии 900P ($550).

Поскольку данные tempDB все равно временные, никаких требований к высокой доступности нет. При сбое Microsoft SQL построит все заново.

Ускоряем Always On Availability Groups

Решение высокой доступности Always On Availability Groups построено на встроенной репликации базы данных Microsoft SQL между отдельными серверами - синхронной или асинхронной, в зависимости от нужд приложения. Локальная дисковая подсистема этих серверов, собранная на SSD (SATA, SAS, или NVMe), обеспечивает низкие задержки, в то время как за доступность данных отвечает сама технология Always On. Кроме того, такая архитектура эффективна в бизнес-приложениях с интенсивным чтением – Always On позволяет создавать множественные read-only копии живой базы данных на различных серверах. Например, можно запускать требовательные к ресурсам CPU аналитические запросы на зеркальной копии данных, не влияя на продуктивность работы активных пользователей базы данных. Используя NVMe SSD, получаем высочайший уровень производительности в критичных приложениях, перекладывая заботы по доступности данных на Microsoft SQL. 

HGST Ultrastar SN200/260 в диапазоне от 800GB ($1,100) до 7.68TB ($6,300) закрывают мыслимые потребности в производительных носителях: свыше 6GB/s в чтении последовательного доступа, больше 2GB/s по записи, до 1.2M IOPS в чтении случайного доступа, 200K IOPS по записи и 580K IOPS под смешанной нагрузкой, типичной для баз данных (70% R/30% W).

Обвязка

Современные серверные платформы в большинстве своем готовы к использованию NVMe. Унификация под формат U.2 (NVMe в 2.5’) развязала руки застройщикам – теперь в типовом сервере 1U можно разместить 8-12 SSD фронтального доступа, 2-4 из которых могут быть NVMe. Стандарт уверенно прокладывает себе дорогу в приложениях, критичных к производительности I/O.

+88
голосов

Напечатать Отправить другу

Читайте также

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT