Источники и составные части производительности ввода-вывода серверов. Вид снаружи

Сервер неуместного наполнения сводит на нет возможности прикладного ПО. И наоборот, учет особенностей трафика данных при выборе компонентов поднимает результативность и позволяет избежать лишних трат. Инфраструктура вычислений и хранения набирается из стандартных аппаратных «кирпичиков» - об этом было в первой части «Источники и составные части производительности ввода-вывода серверов. Вид изнутри». Вот несколько примеров доводки типовых платформ под специфические нужды приложений. 

Серверы баз данных

В погоне за производительностью обычно начинают с переноса файлов баз данных (database, DB) на SSD. Профиль нагрузок баз данных – обращения случайного доступа c большой долей операций записи и относительно невысокими в среднем, но значительными пиковыми нагрузками в IOPS. Размещение DB на SSD позволяет сглаживать эти пики и записывать данные с минимальными задержками, недостижимыми механическим дискам.

При запуске MS SQL сервера создается tempDB – системная база временных, часто перезаписываемых объектов (таблиц, переменных, процедур). Запросы к ним просаживают общую производительность систем с большим количеством расчетных и сравнительных операций: в производственном планировании, логистических задачах учетных систем, обмене данными с другими базами. Активной записи во временные таблицы обычно сопутствует активное чтение из основной базы данных, и наоборот, поэтому стараются вынести tempDB на отдельные от DB физические носители (а то и в оперативную память, с указанием резервного пути на постоянный носитель).

У каждой базы SQL сервера есть журнал транзакций log, в котором фиксируются все изменения данных. Это важная составляющая базы данных, позволяющая при сбое вернуть ее в согласованное состояние. Транзакция не окончена, пока не сделана запись в журнал. Протоколирование, плотный поток коротких линейных операций, критично к задержкам записи. Ради производительности, а также по соображениям сохранности данных, файлы журнала и основной базы хранят на разных физических носителях. При этом tempDB и log могут совмещаться на одном томе SSD.

Каков бы ни был размер основной базы данных, вспомогательные области: файлы индексов, временных таблиц, журналов – сравнительно невелики. Под них имеет смысл отводить самые скоростные носители – NVMe SSD. Появление Intel Optane SSD на памяти 3D XPoint добавляет возможностей управления производительностью.  Хотя 3D XPoint SSD дороже NAND SSD, для размещения на них tempDB и SQL log уж очень привлекательна высокая производительность Optane на коротких очередях запросов. 

Пример дисковой подсистемы cервера SQL:

Серверы - узлы Storage Spaces Direct

Storage Spaces Direct (S2D) – технология распределенного хранения данных в составе Windows Server 2016 Datacenter Edition. Cерверы с локальными дисками объединяются в отказоустойчивый масштабируемый кластер, защищенный от выхода из строя как отдельных дисков, так и серверов целиком. Программно-определяемое решение без единой точки отказа позволяет обойтись без традиционных массивов SAN или NAS. Высокая производительность операций ввода-вывода достигается локализацией дисковых обращений, использованием кэширования, многоуровневого хранения, оптимального сочетания накопителей NVMe/SAS/SATA, cетевого протокола RDMA.

S2D работает с тремя типами дисков: NVMe, SSD, HDD, в различных комбинациях:

Для S2D под нагруженными VM (в том числе, с SQL OLTP) важно обеспечить предсказуемо низкие (менее миллисекунды) задержки между случайными операциями чтения/записи любых данных и много IOPS. Для этого используются флэш-накопители, обычно связка NVMe SSD for Cache + SATA SSD for Capacity. 

NVMe принимают на себя интенсивные операции записи журнала и данных, перенося их на SATA SSD только при необходимости или по расписанию – для уменьшения износа слоя Capacity. Запись «на скорости NVMe» - отличительная особенность S2D. Чтение обслуживается непосредственно с SATA SSD, достаточно быстрых для этого.

Усугубляет дисковую нагрузку «блендер виртуализации», который перемалывает совокупные запросы ввода-вывода VM (включая линейные) в поток обращений случайного доступа с малым размером блока. В грануляте велика доля операций записи (до 50-70%) – что накладывается на без того высокие требования SQL к быстрому обслуживанию файлов баз данных, журналов и временных таблиц. При таких условиях роль кэширующего слоя NVMe неоценима.

Пример дисковой подсистемы узла S2D:

Серверы – узлы VSAN

Virtual SAN (VSAN) – конвергентная архитектура VMware, платформа хранения данных корпоративного уровня. Распределенная инфраструктура вычислений и хранения строится из блоков – серверов. VSAN собирает из локальных дисков серверов виртуальное «внешнее» хранилище, доступное всем вычислительным узлам кластера виртуализации. Двухуровневое хранение включает кэширующий слой (Cache) и постоянный слой (Capacity). Поддерживается All-flash (AF) и гибридная (SSD/HDD) архитектура. На каждом серверном узле может быть от 1 до 5 дисковых групп, как минимум один кэширующий накопитель и до семи дисков постоянного хранения в каждой.

В VSAN AF оба уровня хранения реализованы на SSD. Cache - это буфер, через которых прогоняется вся запись, потому накопители под него ставят Write-intensive, High endurance. Слой Capacity набирают из менее дорогих, Read-intensive SSD. Соотношение объемов Cache/Capacity не должно быть ниже 1:10.

Хотя VSAN и дает определенную свободу в выборе «железа», имеет смысл оставаться в рамках списка гарантированно совместимого с VMware VSAN оборудования. Появление SSD на памяти 3D XPoint, а затем включение Intel Optane P4800X в список поддерживаемого оборудования VSAN AF, вызвало большой энтузиазм в сообществе VMware.  Со слоем кэширования на Optane ожидаемый прирост производительности в задачах с интенсивной записью составляет 2.5 раза против прежде эталонной серии Intel P3700 NVMe SSD.

Возможная структура дисковой группы узла VSAN AF (1 NVMe + 3 SSD):

Таких дисковых групп в 1U можно организовать две.

Серверы VOD

Сети распространения контента (CDN) приближают выдачу данных к потребителю и становятся весомым драйвером развития локальных ЦОД. Особенно быстро растет спрос на цифровое видео, доставка которого коммерческими сетями составляет основную часть их дохода и съедает львиную долю общего сетевого трафика.

Медийной индустрии и ее спутникам CDN нужны надежные, предсказуемые, масштабируемые решения хранения и раздачи контента. Услуга просмотра видео (Video on Demand, VOD) не будет востребована, если непрерывной доставке данных в реальном времени будет мешать низкая скорость соединения, непредсказуемость качества из-за буферизации, зависимость от нагруженности источника.

Цифровое видео проигрывается с высоким битрейтом. Подборки видео хорошего качества съедают десятки и сотни терабайт дискового пространства HDD на стороне поставщика. На практике, серверы VoD обслуживают несколько потоков чтения одновременно. Даже если речь идет о множественных запросах к одному и тому же файлу с популярным видео, одновременное обращение к разным частям этого файла равносильно чтению случайного доступа (Random Read). В результате, многопоточное  чтение видео с высоким битрейтом требует от дисковой подсистемы серверов VOD большой отдачи по ширине потока и способности к быстрому переключению между областями контента.

Механические диски резко теряют пропускную способность с увеличением числа конкурентных потоков чтения, тогда как SSD сохраняют ее на высоком уровне при сотнях потоков. Появление флэш-памяти в раздатчиках видео закономерно, но высокая скорость чтения случайного доступа - не единственная критичная метрика. Взаимодействие между объемными библиотеками контента на HDD и фронтальными устройствами выдачи на SSD должно учитывать особенность спроса, профиль которого постоянно меняется, даже в течение суток. К примеру, утром смотрят новости и кулинарные шоу, днем – сериалы, вечером – развлекательные программы, спортивные трансляции и ситкомы. Соответственно, «горячее» ядро видеоданных постоянно перестраивается, а кэширующие флэш-носители должны быстро подкачивать файлы с основного слоя хранения на HDD.

Наилучшими кандидатами на роль Edge storage в задаче VOD будут емкие NVMe SSD, c их низкими задержками обращения, высочайшими показателями чтения случайного доступа и линейной записи. Например, такие:

Серверы-мутанты

Приведенные примеры показывают, как можно адаптировать типовые серверные платформы 1U под специфические задачи. Все описанные приложения достаточно требовательны к ресурсам процессоров и памяти. Тем не менее, лицо серверов определяет обустройство ввода-вывода: дисковой и сетевой подсистем. Требуемый cетевой адаптер ставится как карта расширения в стандартный слот PCIe или как мезонин OCP. Простор вариаций по дискам велик – благо платформы поддерживают сочетания U.2/SAS/SATA накопителей, в общей корзине, с горячей заменой.   

Казалось бы, какое дело конечному пользователю до того, стандартная его платформа или нет – лишь бы выполняла свою роль и помещалась в бюджет. В том-то и дело, что типовые платформы обходятся дешевле специфических и проще в обслуживании - все узлы стандартные. А еще их можно научить новым трюкам. Серверы живут дольше, чем держится мода. Кто знает, не понадобится ли через два-три года дать вторую жизнь старым вещам.