Многорукий интерфейс серверных SSD

После механических дисков во­об­ще лю­бые твер­до­тель­ные на­ко­пи­те­ли ка­жут­ся про­рыв­ны­ми по ско­рос­ти. При внеш­нем сходстве всех SSD, их (час­то пе­ре­о­це­ни­ва­е­мый) за­пас про­из­во­ди­тель­нос­ти сби­ва­ет с тол­ку и раз­мы­ва­ет и без то­го не­твер­дые убеж­де­ния сер­ве­ро­стро­и­те­лей. Опыт пер­со­наль­ных сис­тем с оди­ноч­ны­ми на­ко­пи­те­ля­ми и ли­ней­ны­ми стра­те­ги­я­ми хра­не­ния не­при­ме­ним в кор­по­ра­тив­ных при­ло­же­ни­ях — не са­дят­ся же с пра­ва­ми ка­те­го­рии “B” уп­рав­лять ав­то­бу­сом или спец­тех­ни­кой (хотя руль и пе­да­ли те же). От­ли­ча­ет под­сис­те­мы ввода-вы­вода сер­ве­ров не так ин­тер­фейс, как на­бор прак­тик. Важ­ны со­че­та­ния на­ко­пи­те­лей под вы­бран­ную про­грам­мно-опре­де­ля­е­мую мо­дель хра­не­ния. Все­му свое мес­то.

SATA, SAS, NVMe

Интерфейс (протокол) подключения SSD определяет, по сути, позиционирование накопителя в инфраструктуре хра­не­ния данных — то, как хост (считай, CPU) общается с внутренними устройствами постоянной памяти, электрически и логически. Локальные накопители подключаются к процессорной шине через посредников (стеки SATA или SAS) или напрямую (NVMe). Протокол задает ограничения (по числу подключений, ширине транспортного коридора, глубине очереди команд) и вносит задержки. Потолок потоковой скорости обмена с устройствами 6Gb SATA — 600MB/s, у них один полудуплексный порт и глубина очереди до 32 команд. 12Gb SAS SSD c дуплексным подключением обслужат по­ток вчетверо шире, с глубиной очереди до 256 команд. SAS позволяет обрабатывать больше операций ввода-вы­во­да одновременно и достаточно просто масштабировать емкость хранения. Обеспечивает доступ к данным по двум пор­там — что неоценимо в отказоустойчивых системах хранения.

С переводом хранения с механических носителей на флеш-память задержки протоколов SATA и SAS стали слиш­ком за­мет­ны­ми в ведомости накладных расходов. Избавление от посредников между CPU и постоянной памятью по­ро­ди­ло NVM Express — интерфейс прямого подключения накопителей в шину PCI Express. Вершина пирамиды хранения, населенная критичными данными, сегодня обслуживается NVMe SSD. Такие решения, как программно-определяемые ги­пер­кон­вер­ген­т­ные системы (HCI) и тран­з­ак­ци­он­ные приложения (OLTP), вышли на принципиально новый уровень производительности — благодаря комбинации пропускной способности NVMe с предсказуемо низкими задержками обращения.

Вот типичные представители классов SSD. Их характеристики говорят за себя. Цена различается в разы, но и эф­фек­тив­ность — в разы.

Table 1

Сводная таблица типовых серверных SSD с различными интерфейсами подключения

Источники: ark.intel и westerndigital.com

Пирамиды местного значения

Природа трафика ввода-вывода корпоративных приложений следует из их структуры потоков данных. Простыми ре­цеп­та­ми из практики ПК не обойтись, одним типом накопителей тоже. Как правило, баланс между стоимостью ре­а­ли­за­ции и про­из­во­ди­тель­но­стью хранения вместе с его емкостью на типовом наборе задач принимает форму «ма­лой пи­ра­ми­ды хра­не­ния» — уместного сочетания накопителей. В качестве примера разовьем кейс из библиотеки Western Digital «Enhancing Performance and Reducing Costs for Microsoft SQL Server».

Как поднять производительность Microsoft SQL Server

Транз­ак­ци­он­ные (OLTP) и аналитические (OLAP) системы — очевидные вы­го­до­по­лу­ча­те­ли от переноса рабочих на­гру­зок на SSD в дискретных или кластерных реализациях Microsoft SQL Server. Вместо громоздкой и до­ро­го­сто­я­щей ин­фра­струк­ту­ры SAN с раз­де­ля­е­мы­ми внешними системами хранения — серверы с локальными SSD, группы сер­ве­ров Always On, кластеры Storage Spaces с общими JBOD или Storage Spaces Direct с распределенным хранением.

За счет быстрого доступа к локальным накопителям сервер тратит меньше процессорных циклов на об­слу­жи­ва­ние ввода-вывода — значит, можно консолидировать нагрузку на меньшем числе устройств (снижение капитальных за­трат, включая стоимость лицензий) и упростить обслуживание (сократить операционные затраты — на питание, ох­лаж­де­ние, администрирование).

Одиночные серверы

Сложные запросы к базам данных SQL сопровождаются формированием многомерных промежуточных таблиц и бу­дут выполняться намного быстрее, если поместить временные файлы с ними (tempDB) на локальные NVMe SSD. Тому есть два основания: ускорение отклика (важно при интенсивной перезаписи большого числа мелких посылок данных) и снижение смешанной нагрузки чтения/записи на основные носители. Это самый простой в реализации способ ус­ко­ре­ния SQL-сервера. Потеря данных временных таблиц не критична, необходимости в их непрерывной до­ступ­нос­ти или ре­пли­ка­ции нет. Основные данные (DB) держат на отказоустойчивом массиве SATA или SAS SSD и ре­пли­ци­ру­ют на со­сед­ний сервер штатными средствами ОС.

Группы Always On

Always On Availability Groups — механизм Microsoft SQL Server поддержания высокой про­из­во­ди­тель­нос­ти и до­ступ­нос­ти данных в группе серверов на уровне самих баз данных. Синхронная или асинхронная (в зависимости от нужд при­ло­же­ния) репликация между серверами с локальными подсистемами хранения обеспечивает состоятельность дан­ных при ава­рии. Низкие задержки, высокая производительность внутренних SSD и относительно небольшие объ­е­мы хра­не­ния — сильный довод в пользу систем all-flash.

Always On создает множественные read-only копии живых баз данных на серверах группы. Подобная архитектура есть и в других бизнес-приложениях с массированной вычиткой данных. Например, аналитические запросы, съе­да­ю­щие ресурсы CPU, удобно выполнять на зеркальной копии данных, без ущерба для производительности пользователей OLTP. NVMe SSD с их показателями потокового чтения и минимальными задержками (важно для син­хрон­ной ре­пли­ка­ции) обеспечивают наивысший уровень производительности в критичных приложениях. Для наращивания объ­ема хра­не­ния на сервере можно использовать SAS или SATA SSD, с RAID-контроллером или без.

Кластеры Storage Spaces

Технология Windows Storage Servers позволяет строить кластеры серверов с общим разделяемым JBOD. Приложения ра­бо­та­ют с дисками JBOD как с локальными. Доступность приложений и данных, их быстрое восстановление при сбо­ях обеспечивает сама ОС. От размещения баз данных на SAS SSD (двух­пор­то­вость!) немедленно выигрывают при­ло­же­ния класса SQL Server. Подсистема хранения легко мас­шта­би­ру­ет­ся по емкости и позволяет воспользоваться пре­и­му­щес­т­ва­ми мно­го­пу­те­во­го (multipath) ши­ро­ко­по­лос­но­го доступа 12Gb SAS. Для до­пол­ни­тель­ного при­рос­та про­из­во­ди­тель­нос­ти tempDB выносят в узлы кластера и размещают на локальных NVMe SSD — временным файлам высокая до­ступ­ность не нужна. Кластеры Storage Spaces — самый экономичный по железу и лицензиям способ создания про­из­во­ди­тель­но­го и ус­той­чи­во­го к отказам ядра серверной инфраструктуры.

Кластеры Storage Spaces Direct

Сегодня в трен­де перевод критичных бизнес-приложений в ги­пер­кон­вер­ген­т­ную инфраструктуру серверов (HCI) под управлением ги­пер­ви­зо­ра. Распределенное хранение на локальных дисках серверов кластера позволяет добиться высокой устойчивости к отказам оборудования, упрощения транспорта данных и эластичности наращивания под на­груз­ки. У Microsoft такие кластеры строятся по технологии Storage Spaces Direct (S2D). Подсистема хранения каждого сервера кластера в all-flash варианте набирается из пары NVMe под кэ­ши­ро­ва­ние и нескольких SATA SSD под ос­нов­ное хранение. В этой связке NVMe автоматически кэ­ши­ру­ют все операции записи. Кроме прибавки про­из­во­ди­тель­нос­ти, это снимает нагрузку интенсивной перезаписи с SSD — что позволяет избежать их раннего из­носа и обо­йтись от­но­си­тель­но недорогими носителями. Данные считываются с основного массива SSD — скорости чтения SATA SSD для баз данных достаточно, при комфорте записи с низкими задержками NVMe. Минус решения — в цене лицензий Win­dows Ser­ver Data­center, без которого S2D не работает.

Каждое из приведенных решений all-flash по-своему использует выгоды накопителей с разным интерфейсом, а «оп­ти­ми­за­ция» — всегда штучный товар.

Table 2

Эффективность all-flash при различных типах серверных нагрузок

Источники производительности

В погоне за производительностью дисковой подсистемы серверов важнее всего анализ трафика данных, и только по­том — под­бор компонентного ряда. Неуместное наполнение сводит на нет возможности системного и прикладного ПО. Дру­гие при­ме­ры доводки типовых платформ под специфические нужды серверных приложений показывают, что

  1. без SSD сегодня не обойтись;
  2. результативность следует из понимания программно-определяемой модели работы с данными;
  3. рациональные сочетания интерфейсов и типов накопителей дают конкурентные преимущества, экономя средства.