`

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

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

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

Человек года

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

Продукт года

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

 

Роли SSD в серверах

+77
голосов

Переход на флэш-память взбодрил индустрию хранения - и даже не скачком производительности, а переключением внимания с устройств на сценарии хранения. Те носители хороши, что отвечают особенностям трафика данных.

Серверные приложения работают с различными профилями нагрузок и типами данных. В каждом случае производительность оценивается своим набором метрик и достигается разными средствами. Без анализа нагрузок любой выбор носителей будет слепым. Постановщик задачи хранения сперва препарирует трафик данных, и только потом фильтрует видовое многообразие SSD, по уместности применения.

Кроме емкости, накопители на флэш-памяти отличаются друг от друга интерфейсом (SATA, SAS, NVMe), организацией, типом и избыточностью ячеек, контроллерами и их прошивками, множеством других характеристик. Важны прикладные свойства SSD: производительность (потоковая и случайного доступа), задержки обращения (latency), ресурс перезаписи ячеек (endurance).

Поле критичных параметров кажется не очень большим, но это обманчивое ощущение. Во-первых, SSD в серверах выступают в разном качестве и от каждой роли свои ожидания. Во-вторых, они отличаются разбросом характеристик. Взять метрику DWPD (drive-writes-per-day) прогнозируемого ресурса. Все SSD делятся на классы: повышенной стойкости к перезаписи (25 DWPD), средней (10 DWPD), умеренной (3 DWPD), и накопителей под чтение (0.5 – 1 DWPD). С ростом нагрузок роли могут переходить к совсем другим актерам. В комментариях ниже мы постараемся избегать количественных рекомендаций - в пользу качественных: “повышенная устойчивость к перезаписи”, “минимальные задержки чтения”, “высокая потоковая скорость записи”.

Ролевой подход позволяет избежать прямого ранжирования SSD по метрикам. Анализируя приложения и взаимодействие областей данных, пользователь получает больше оснований для выбора. Рассмотрим сценарии применения SSD, типичные и разные.

Журналы транзакций распределенного хранилища

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

Рассмотрим дисковые операции на примере синхронной репликации между узлами в Windows Storage Spaces Direct. Она используется для критически важных данных и обеспечивает запись данных приложением сразу в два места. Когда приложение перезаписывает оригинал данных, исходное хранилище подтверждает операции ввода–вывода не сразу. Измененные данные реплицируются в удаленную конечную копию, возвращая подтверждение. Только после этого операция ввода/вывода приложением считается завершенной. Так гарантирована постоянная синхронизация удаленного и исходного узлов в кластере хранения.

Роли SSD в серверах

Тот диск, на котором расположен журнал транзакций (Log), интенсивно перезаписывается: любая операции записи в том данных обязательно сопровождается записью в журнале, ее чтением (для перезаписи на основной носитель и подтверждения записи), а затем стиранием этих данных. Естественно, от латентности доступа к такому диску будут напрямую зависеть задержки всей распределённой системы хранения.

Обычно в распределенном хранилище на одних и тех же физических носителях ведется журнал транзакций, кэшируются чтение и запись. По похожей схеме работают многие программно-определяемые системы – например, VMware vSAN и DataCore.

Рекомендации: Ставить SSD с минимальными задержками на запись и чтение, максимальной производительностью в IOPS по записи и чтению, большим ресурсом перезаписи (Microsoft пишет о зеркале из двух NVMe SSD с ресурсом от 5 DWPD и выше), поддержкой длинной очереди команд ввода/вывода (что исключает SATA SSD из списка кандидатов, оставляя в нем NVMe и SAS). Большой емкости дисков под протокол транзакций распределённого хранилища не нужно. Но, с учетом совмещения задач, несколько сотен гигабайт под кэширование чтения и записи лишними не будут.

Кэширование медленных носителей

SSD-кэш – это вспомогательное хранилище данных на флэш-памяти, повышающее производительность ввода/вывода. Его содержимое составляют временные копии данных активного обращения. Сами данные покоятся по месту постоянной прописки - на менее дорогих дисках, не таких быстрых, более емких. Как буфер, кэш не увеличивает общую емкость хранения и может принимать разные формы. В Microsoft Storage Spaces Direct (S2D) вообще прописана возможность использования четырех типов носителей, три из которых – на флэш-памяти: NVDIMM-NVMe-SSD-HDD. Кэшируй как хочется.

 

Роли SSD в серверах

Кэширование на SSD давно практикуют производители RAID­-контроллеров и аппаратных СХД, сейчас без него не обходится программно-определяемое хранение. При всем многообразии стратегий кэширования, общие принципы одни и те же: SSD–кэш сглаживает пиковые нагрузки и поддерживает в тонусе горячее ядро хранения – копии часто запрашиваемых блоков данных. Какие именно данные считаются горячими, каковы принципы их копирования из холодного слоя в кэш, вероятность попадания в него (cache hit) или промаха (cache miss), интенсивность обновления и логика вытеснения копиями новых данных – все это зависит от управляющих алгоритмов и структуры запросов к дискам.

Под кэш нужны SSD c предельно высокими характеристиками: его диски находятся в состоянии постоянного обновления содержимого. Хотя потеря данных кэша не является фатальной (оригиналы данных всегда лежат на основном слое хранения), замена выработавших ресурс носителей занимает время. К тому же, обнуление кэша проваливает общую производительность: до того момента, пока кэш не насытится новыми копиями часто запрашиваемых данных, ввод/вывод будут тормозить медленные диски.

Рекомендации: Брать SSD с минимальными задержками записи, максимальной производительностью в IOPS, большим ресурсом перезаписи. Если поддерживаются, желательны SAS SSD или NVMe SSD. В гиперконвергентных программно-определяемых системах предпочтительны NVMe SSD (с ресурсом повыше). Объем дисков под кэширование зависит от структуры приложений и выбирается из оценок доли горячих данных в общем объеме хранения.

Многоуровневое хранение (tiering)

Если кэширование – это копирование данных, то tiering – перенос данных между уровнями хранения (tiers). Общая емкость системы хранения равна сумме емкостей ее уровней. Уровни отличаются производительностью и размером. Самый верхний строится на флэш-памяти и отводится под горячие данные, он относительно невелик. Обмен данными между уровнями ведет управляющее ПО – на основе анализа собираемой статистики обращений. Горячие блоки перемещаются на уровень выше, остывающие опускаются на более медленные, но емкие носители. Tiering  не исключает кэширования – сглаживание пиковых нагрузок записи остается важной функцией SSD.

Роли SSD в серверахПример отказоустойчивого многоуровневого хранения дает Windows Server 2012R2 / Storage Spaces. Средствами ОС строится кластер файловых серверов SOFS и управление логическими томами данных на дисках SSD/HDD. Все накопители вынесены в JBOD – контейнеры разделяемого доступа, подключенные к серверам по интерфейсу SAS. Кластеры вычислительных узлов и хранилищ образуют сеть SAS SAN, масштабируемую по серверам и дисковым массивам.

В JBOD cтавятся диски SAS, с двухпортовым подключением каждого по двум независимым путям через дублированные экспандеры и модули ввода/вывода. Этим достигается высокая отказоустойчивость и производительность под нагрузкой. SAS SSD объединяются в Tier 0, емкие SAS HDD – в Tier 1. Встроенная технология Storage Spaces Automatic Tiering отслеживает обращения к файлам и переносит блоки данных по расписанию:  горячие на SSD, остывшие на HDD. Расписание можно настраивать, а определенные данные постоянно держать в Tier 0 – если это нужно пользователю.

Рекомендации: Используются SSD с минимальными задержками, максимальной производительностью в IOPS по записи и чтению, средним и выше ресурсом перезаписи. В отказоустойчивых хранилищах разделяемого доступа нужны SAS SSD.

Таблицы баз данных транзакционных приложений

Что-что, а перенос файлов операционных баз данных (DB) на SSD пользователи замечают сразу. Ускоряется реакция на запросы, работа фильтров, подготовка отчетов и выгрузка документов. Требования к DB SSD разнятся, все зависит от алгоритма работы приложений. Регистрация SMS и телефонных голосований, протоколирование звонков или банковских транзакций дает умеренную нагрузку на диски, близкую к линейной записи короткими пакетами. Пример очень высокой нагрузки случайного доступа - загрузка/выгрузка данных из периферийных баз данных в центральную базу распределенных учетных систем, как 1С:Предприятие 8. Киллер-приложением можно считать начисление оплаты в биллинговых системах мобильных операторов, банков, сервис-провайдеров.

Обычный профиль нагрузок учетных систем – пропорция чтения/записи 70R/30W, с относительно невысокими в среднем, но очень высокими пиковыми нагрузками в IOPS, по записи и чтению. Помещение SQL DB в виртуальную среду может поменять соотношение чтения/записи на противоположное - вплоть до 20R/80W (об этом ниже). Такое увеличение требований по скорости записи ужесточает подбор кандидатов среди SSD. 

Рекомендации: При обращении к DB SSD критичны низкие задержки по записи. Хотя операции чтения хорошо кэшируются самой СУБД в оперативной памяти сервера, важны максимальная производительность по чтению/записи в IOPS и поддержка длинной очереди команд (NVMe или SAS). Достаточно среднего ресурса перезаписи – база данных не обновляется каждый день целиком. Большинство рядовых баз данных по объему не превышают нескольких десятков гигабайт. Им достаточно SSD минимальной емкости - лишь бы отвечали реальной нагрузке.

Временные объекты баз данных (tempDB) 

Системная база данных tempdb - общий ресурс пользователей SQL-сервера, содержащий временные таблицы, процедуры и переменные. Эти объекты невелики, но их данные непрерывно модифицируются и могут переписываться в полном объеме несколько раз в день - в отличие от файлов самих баз данных. Скорость отклика tempDB сильно влияет на общую производительность систем с большим количеством расчетных и сравнительных операций (как в производственных или логистических задачах систем учета). Основное требование к носителям – малые задержки доступа. Важны высокая скорость записи и чтения, как в IOPS, так и в MB/sec, в особенности, при обмене данными с другими системами (1С:Предприятие 8, центральная база данных распределенной системы). К отказоустойчивости особых требований нет: временные таблицы можно в любой момент сформировать заново (перезапуском SQL Server) или переадресовать на другой физический носитель (резервный путь прописывается в настройках SQL Server) – например, на том с DB или SQL log.

При малых нагрузках DB и tempDB размещают на одних и тех же носителях, экономя устройства и средства. В средне- и высоконагруженных системах их лучше разносить по разным физическим дискам: активной записи во временные таблицы обычно сопутствует активное чтение из основной базы данных, и наоборот. Любые SSD в режиме одновременного чтения/записи теряют 30-70% производительности – против своих же показателей при чистом чтении или чистой записи. В нагруженных системах иногда практикуют размещение tempDB в RAM Drive (с обязательным указанием резервного пути на аппаратный диск).

MS SQL по умолчанию создает tempDB на системном диске, что не всегда оправданно с точки зрения производительности.

Рекомендации: Под tempDB ставят SSD небольшой емкости, с минимальными задержками, максимальной производительностью в IOPS на запись и чтение, с умеренным ресурсом перезаписи, желательно с поддержкой длинной очереди команд ввода/вывода (NVMe или SAS). Для слабонагруженных систем подойдут SATA SSD. Отказоустойчивое хранилище (RAID 1) под tempDB строить не обязательно, можно обойтись одиночными накопителями.

Журналы транзакций баз данных (log)

Запись в журналы транзакций баз данных (и приложений) носит скорее последовательный характер, хоть и разбита на множество мелких операций. Вначале транзакция фиксируется в журнале, затем данные переносятся на физический носитель (возможно, с отложенной записью), приходит подтверждение записи, и только после этого в журнале появляется отметка о завершении операции. Без стирания данных о самой транзакции. Стирание данных в любых логах – относительно редкая операция, логи многих приложений вообще пишутся линейно, без подтверждений. Таким образом, под протоколы баз данных и приложений подходят диски с быстрой записью, не критичные к скорости чтения и запасу прочности.

Из соображений сохранности данных DB и log желательно хранить на различных физических носителях (из Full SQL log, например, можно восстановить последовательность транзакций даже при утрате DB). Добиваясь производительности, избегают размещения SQL Log на системном диске (MS SQL и это делает по умолчанию).

Рекомендации: использовать SSD с запасом по емкости, минимальными задержками записи, пристойной производительностью в IOPS и MBPs, с умеренным ресурсом перезаписи.

Таблицы баз данных аналитических систем

Как доктор Джекил и мистер Хайд, накопители под OLAP живут двойной жизнью: ночью принимают  потоком большие объемы данных OLTP-систем, днем обслуживают интенсивные операции линейного и случайного чтения. SSD и тут ломают сложившуюся практику применения массивов HDD – тем ночь коротка, цель далека. Аналитика, построенная на поисковых механизмах, тем более требует перехода на флэш-носители. 

Рекомендации: Подойдут SSD с высокой производительностью линейной записи, с низкими задержками чтения, линейного и случайного доступа, умеренным ресурсом перезаписи. Если позволяют объемы данных – переходить на NVMe SSD, с их выдающимися показателями потоковой скорости, низкими задержками и запасом по IOPS.

Файловые хранилища VDI и базы данных в виртуализированных средах

В системах VDI обычно за сутки считывается около 7-12% объема данных VM на диске, а записывается порядка 3-8%. При этом по нагрузке на диски операции записи преобладают над операциями чтения - в среднем, 70-80% операций записи на 20-30% чтения. Объясняется такой перекос эффективным кэшированием чтения на уровне сред виртуализации (с записью такое не провернуть – данные можно и потерять). Требования к дискам под VDI по задержкам невысоки, зато критичны производительность записи и чтения случайного доступа в IOPS. Не ниже средних должны быть показатели потокового чтения/записи в MB/s - для быстрой отработки ночного бэкапа.

Отдельный класс VDI систем – среда разработки. Там нагрузки по записи и чтению могут быть заметно выше типичных. 

Рекомендации: Как правило, достаточно SSD со средними значениями по записи и чтению, ресурсом перезаписи от умеренного до среднего. При значительном количестве небольших баз данных (характерно для сервис-провайдеров) брать диски с высокими показателями записи в IOPS. Разработчикам нужны SSD с поддержкой длинной очереди команд ввода/вывода (NVMe или SAS).

Почтовые базы данных (MS Exchange), средства коллективной работы (MS SharePoint), документооборот

Почтовые хранилища и средства коллективной работы содержат разнородные данные: таблицы, файлы различных форматов, фото- и видеофайлы. К части хранимых данных предъявляются высокие требования по задержкам доступа и IOPS, для других, объемных, важна линейная скорость потоковых операций. Запросы к дискам приходится усреднять. Хорошо (для SSD), что cтирание данных и перезапись – относительно редкие операции.

Для почтовых баз данных и поддержки документооборота идеально подходит автоматизированное многоуровневое хранение (tiering) на смеси SSD/HDD. Пусть ПО отделяет горячее от холодного (рандомное от потокового). Табличные данные частого обращения пользователей осядут на SSD, быстром уровне, сканированные копии документов и прикрепленные файлы пользователей останутся на емких носителях.

Рекомендации: Если делать массив из однотипных дисков – лучше на SAS SSD c умеренным ресурсом перезаписи. В многоуровневом решении в Tier 0 следует поставить NVMe или SAS SSD, а емкость набрать HDD или Read Intensive SSD – они просели в цене.

Системный диск и файл подкачки

Нагрузка на системный диск бывает разнородной. Если установленная ОС представляет собой стабильный, редко обновляемый блок данных, то файл подкачки может при определенных обстоятельствах быстро укоротить срок службы SSD. В общем случае, ставить под систему флэш-накопители c высокой производительностью и большим ресурсом незачем. Но от HDD лучше уходить: SSD обеспечивают загрузку в разы быстрее, меньше времени уходит на обновления, на сброс оперативной памяти в своп-файл, быстрее работают профили пользователей и операции с различными временными данными (1С любит использовать tmp-файлы в локальном профиле пользователя).

Типичную ошибку совершают пользователи бюджетных серверов (под ту же 1С:Предприятие 8), когда SSD отводят под ОС, а HDD – под базу данных. Все наоборот:  зеркало из HDD - под ОС и приложения, зеркало из SSD – под базу.

Рекомендации:  С ролью системного диска управятся младшие модели SATA SSD. Емкость считается по формуле: объем, занимаемый ОС и установленными приложениями + полтора объема RAM + 20-30% резерва.

То ли еще будет 

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

Сведем перечисленные сценарии в одну таблицу. Возможно, качественные оценки применимости SSD в разных ролях окажутся полезнее лобового сравнения продуктов по срезам их паспортных параметров.

Роли SSD в серверах

 

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

+77
голосов

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

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

Очень не хватает сводной таблички, где глаз мог бы сразу уцепиться за случаи, где НЕ требуется низкая латентность, высокая износостойкость и все остальные мега-характеристики.
И пассаж о быстром бэкапе VDI-сред - здравый смысл и бэст практис возражают, это ж вообще лишнее ;-)

А так - спасибо за фундаментальный материал, это редкость.

Некритичность к некоторым параметрам хорошо видна из таблиц типичных нагрузок приложений, вроде той, что цитировалась в http://ko.com.ua/resurs_servernyh_ssd_118891.

Ставить или не ставить SSD, а если да, то какие - вопрос не вкуса, а оценки нагрузок объективными метриками. Иногда достаточно внимательного чтения паспортных параметров. Возьмем, к примеру, интеловские SSD начального уровня. Например, бросается в глаза, что у младшей модели 150GB серии 3520 https://ark.intel.com/products/94037/Intel-SSD-DC-S3520-Series-150GB-2_5... скорость потокового чтения/записи составляет всего лишь 180/165 MBps. Это показатели HDD 7200. У 100GB серии 3610 https://ark.intel.com/products/92225/Intel-SSD-DC-S3610-Series-100GB-2_5... они же равняются 550/520 MBps. Цена 150GB/3520 и 100GB/3610 отличается не сильно.

Понятное дело, 150GB/3520 будут хороши как стартовая пара под ОС, но плохи под базу данных, ее журнал и временные таблицы. А 100GB/3610 - наоборот.

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT