Mixed use ssd что это

Обновлено: 04.07.2024

Детская загадка: «Три, три, три, что в результате? — Дырка!» — это про SSD. Жизненный цикл флэш-памяти определяется количеством циклов перезаписи P/E (program/erase), на которые она рассчитана.

Владельцам ПК нет особых причин беспокоиться за раннюю выработку ресурса SSD — в персональных приложениях не те режимы работы накопителей. В серверах все иначе. Их пользователи и приложения порождают интенсивные потоки запросов к дискам. Имеют значение шаблон нагрузки (load pattern) и программное окружение. Например, для баз данных на физическом сервере типичным считается соотношение 70/30 (%) операций чтения/записи со случайным доступом к дискам. В виртуальном сервере пропорция может перевернуться с ног на голову, например, в 20/80. Вообще говоря, блендер виртуализации перемалывает любые дисковые запросы в рандомную крупу — потому SSD и вытеснили HDD в критичных к производительности задачах. К сожалению, выносливость флэш-памяти ограничена. Ожидаемая продолжительность жизни SSD, с его типом ячеек, контроллером, прошивками, процедурами и внутренними счетчиками, зависит от числа циклов P/E (program/erase — последовательностей записи, стирания и повторной записи), которые диск способен перенести.

Ячейки памяти NAND SSD объединены в страницы, те — в блоки. Работать с каждой ячейкой отдельно нельзя, данные стираются целыми блоками. По мере заполнения диска пустых страниц и блоков под запись становится все меньше. В результате, команда записи, полученная контроллером SSD, приводит к нескольким циклам P/E: данные блока надо записать в новые ячейки, а оставшийся «мусор» удалить, вернув таким образом блок в свободное адресное поле. Объем данных, записанных на носитель, всегда больше, чем их фактическое обновление, которое ОС передает контроллеру SSD. Этот эффект усиления записи (write amplification) ускоряет износ ячеек. А чем полнее диск — тем меньше остается пространства для маневра, больше переносов данных и медленнее запись.

Необратимость износа ячеек флэш-памяти NAND — еще не приговор для SSD. Сколько протянет диск, зависит от модели нагрузок. Это обстоятельство вносит некоторую неопределенность в проектирование подсистем хранения и удерживает от слепого выбора. Количественная оценка ресурса накопителей (endurance) в определенном шаблоне работы — такой же важный параметр для серверных SSD, как емкость, производительность и цена за гигабайт.

В серверные SSD встроены технологии, отодвигающие их смертный час: оптимизация сбора мусора (garbage collection), выравнивание износа (wear leveling), резервирование ячеек (overprovisioning). Цена вопроса разная, в разных классах SSD. На то у них паспортный параметр endurance, чтобы пользователь заранее сверял нагрузки своих приложений с предельными возможностями SSD. В спецификациях всегда приводится полный ресурс записи в терабайтах (TBW, terabyte written, при пятилетнем сроке службы) или допустимый объем суточной записи относительно емкости самого диска (DWPD, Drive Writes Per Day).

В описаниях накопителей встречаются фразы «Read intensive» или «Write intensive». Это незамысловатый способ их позиционирования, ролевая подача доходчивым языком. У дисков, предназначенных под интенсивную запись, показатели TBW/DWPD должны быть намного выше. Насколько именно — зависит от шаблона нагрузок. А вот понятия «Write unlimited» для SSD не существует — ввиду ограничений перезаписи любых ячеек NAND. Допустимо говорить о малой вероятности выработки ресурса в заданном наборе приложений, но «вечных игл для примуса» нет.

С развитием гиперконвергентных систем (вычисления + хранение) область применения серверных SSD расширяется. Строя инфраструктуру на типовых серверах, пользователь стоит перед соблазном перейти на недорогие носители (мол, все данные все равно многократно дублированы). Теперь уже разработчики ПО, а не поставщики серверов, объясняют, как должна быть устроена дисковая подсистема производительного сервера, предостерегают не использовать бытовые SSD, и прямо указывают в аппаратных требованиях, например, такое: «Ensure SSDs used for cache have high write endurance. We recommend 5+ drive-writes-per-day (DWPD)».

Особенно тщательно к аппаратным рекомендациям подходит VMware, пресекающая самодеятельность за пределами списков совместимости (HCL). Валидируемые компоненты сортируются по целевому назначению, типу подключения и уровню нагрузок. В частности, SSD делятся на классы: от Endurance Class A >=365 TBW до Endurance Class D >=7300 TBW. Застройщик будущей серверной инфраструктуры анализирует списки компонентов и получает представление о коридоре возможностей. Можно сделать по-своему — но оно и работать будет непредсказуемо, если вообще будет.

Оценки дисковой нагрузки типичных серверных приложений известны:

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

Напоследок, примеры производителей и серий их SSD, с сортировкой по интерфейсу подключения и заявленному ресурсу перезаписи ячеек.

Выбор SSD для клиент-серверного варианта 1С для коллективной работы отличается от покупки SSD для своего ноутбука.

Разные производители по-разному трактуют классы промышленных SSD, но в целом можно привести такой пример разделения:

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

Оценка текущей интенсивности записи на диск

Для понимания, какой вам нужен диск, наиболее достоверным действием будет замер ваших текущих нагрузок на диск: какова реальная интенсивность записи на диск.

Если Вы используете 1С в наиболее популярном варианте в связке с MS SQL Server, то основная нагрузка на диск будет через него и с помощью запросов к статистике сервера можно получить оценку интенсивности записи .

Нюанс тут заключается в том, что СУБД оценивает только “свою” запись (то есть не видит любые другие объёмы, записанные другими службами), и полученные цифры говорят об объемах чтения и записи только с момента старта службы MS SQL.
Обратите внимание, что если у вас будут и другие источники значимой интенсивности записи, то ниже показанный способ будет недостаточным. Если вы пишете например в виртуалке на виртуальный диск, расположенный на общем внешнем хранилище дисков, то реальную нагрузку на диски мы можем и не измерить правильно в таком подходе.

Данные с СУБД можно получать сразу в сгруппированном по дискам виде, и сразу с пересчётом в гигабайты, например таким запросом:

SELECT SUBSTRING(saf.physical_name, 1, 1) AS [Диск]

, SUM(vfs.num_of_bytes_read/1024/1024/1024) AS [Прочитано (Гб)]

, SUM(vfs.num_of_bytes_written/1024/1024/1024) AS [Записано (Гб)]

FROM sys.master_files AS saf

JOIN sys.dm_io_virtual_file_stats(NULL,NULL) AS vfs

ON vfs.database_id = saf.database_id

AND vfs.file_id = saf.file_id

GROUP BY SUBSTRING(saf.physical_name, 1, 1)

например, получится вот такой результат:

DECLARE @Days int
DECLARE @Hours int
DECLARE @Mins int
DECLARE @Secs int

SET @Secs = (
SELECT datediff(ss, login_time, getdate())
FROM master..sysprocesses
WHERE spid = 1
)
SET @Days = ((@Secs/60)/60)/24
SET @Hours = ((@Secs/60)/60)%24
SET @Mins = (@Secs/60)%60
SET @Secs = @Secs%60

ВАЖНО. Если с момента рестарта пройдет меньше суток, то надо как минимум подождать пока набегут сутки и повторно посчитать.

ВАЖНО. Интенсивность записи в разные дни может быть сильно разная. Достаточно репрезентативным показательным интервалом времени аптайма сервера для оценки можно считать квартал. Либо генерируете в исследуемом небольшом период пик нагрузки.

ВАЖНО. Любая запись на диски, сделанная НЕ средствами СУБД, например полных бэкапов внешними средствами (например Акронис Бэкап) в замер субд не попадет.

Как видно на снимке, служба сервера запущена 14 дней 19 часов (или 355 часов) назад, и статистика накоплена именно за это время.

Дальше можно просто вычислить средний объём записи в сутки.

Теперь чтобы подобрать SSD, надо посмотреть на подходящий размер и соответствующих “полных перезаписей устройства в день” DWPD.

Если Вы берете диск с 0,1 DWPD intel P4101 емкостью 512 Gb, то 512 * 0,1 = 51,2 Гб/сутки < реальной нагрузки 350 гигабайт в сутки. На практике Вы получите непредсказуемую неудовлетворительную работу диска.
Кроме того, в реальной жизни не только SQL Server генерирует нагрузку, так что надо еще делать поправочный коэф.-т на другую активность.

Требуемый нам диск должен перезаписывать более 400 Гигабайт. Понятно, что кроме этого надо смотреть на требуемый реальный размер диска. Вдруг у нас база размером в терабайт. Рассмотрим на примере диска intel p4610 размером 1,6 Тб

Пересчитываем условно рейтинг износоустойчивости в расчёте “на 1 день”: 12.25 петабайт = 12250 терабайт, делим на (5 лет Х на 365 дней), получаем 6.7 терабайта в день, теперь делим эту величину на объём диска и получаем примерно 4 объёма полной перезаписи в день (то есть DWPD).

Наиболее представительной данная информация будет например, если скриптом получать в некую табличку результат запросов по объёму записи каждый час в течение скажем нескольких дней высокой загрузки, а затем определить интенсивность записи именно в пиковые периоды, когда это могло мешать производительности бизнеса. Например, ночью нагрузка на диски будет большая, но в это время никто в базе не работает, и диски к началу рабочего дня уже могли успеть “прийти в себя”. Но может оказаться и так, что в течение нескольких часов нагрузка на диски по записи существенно превышает паспортную, и производительность записи заметно ухудшается.

Дальше можно просто вычислить средний объём записи в сутки.

В данном примере получается в среднем примерно по 350 гигабайт в сутки. При этом надо понимать, что статистика представляет собой “среднее по больнице”, ведь наверняка в периоды высокой активности пользователей запись существенно больше, или во время ночных регламентов на СУБД, а в другие периоды бывает поспокойней. Наиболее представительной данная информация будет например, если скриптом получать в некую табличку результат запросов по объёму записи каждый час в течение скажем нескольких дней высокой загрузки, а затем определить интенсивность запись именно в пиковые периоды, когда это могло мешать производительности бизнеса. Например, ночью нагрузка на диски будет большая, но в это время никто в базе не работает, и диски к началу рабочего дня уже могли успеть “прийти в себя”. Но может оказаться и так, что в течение нескольких часов нагрузка на диски по записи существенно превышает паспортную, и производительность записи заметно ухудшается (о чём нам как бы намекает из вышеприведённого снимка колонка “Отклик на запись”, где среднее сглаженное время отклика одной операции записи на разных файлах плавает от 13 до 27 миллисекунд, что было когда-то приемлемо для механических дисков, но это много для SSD, особенно с учётом того, что это той же “среднее по больнице” за 13 дней).

Заметим, что производитель решил умолчать в данной спецификации о таких важных параметрах, как DWPD (гарантийный показатель количества перезаписей в день) и гарантийный ресурс устройства на запись. Практически единственным намёком на класс устройства в данной спецификации может служить соотношение IOPS на чтение и запись, а именно 275К против 16К.

Понятно, что это всего лишь один из факторов, который надо учитывать при покупке SSD. Но его недооценка частенько приводит к очень неприятным последствиям.

Арендуя сервер под важные сервисы, вы скорее всего обеспокоены безопасностью данных и надежностью носителя, хранящего эти данные.

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

Производительность и стоимость таких HDD- и SSD-накопителей зависят от конкретных предложений. Ниже указана информация по возможностям этих устройств.

Краткий обзор

Жесткие диски (HDD) и твердотельные накопители (SSD) выпускаются в нескольких вариантах, предназначенных для удовлетворения различных потребностей клиентов. Такое оборудование включает в себя:

твердотельные накопители SAS, Value SAS и SATA: быстродействующие запоминающие устройства для произвольного доступа;
жесткие диски SAS 10K и 15K: эксплуатационная готовность работы с приложениями оптимизированной производительности;
жесткие диски SAS и SATA 7,2K: большая вместимость и уникальная стоимость за гигабайт для приложений с оптимизированной емкостью;
жесткие диски для ввода данных: самые дешевые диски, применяемые в приложениях с низкими показателями использования и неограниченным общим количеством дисков; из-за ограничений, налагаемых на их применение, такие диски встречаются лишь в немногих системах и конфигурациях.

Жесткие диски 512e с повышенной производительностью: предложение технологий 13G и 14G

В начале 2017 года был представлен жесткий диск SAS 900GB 15K 512e 12Gbps в форм-факторе 2,5’’. Новинка была снабжена усовершенствованной кэш-функцией для улучшения считывающей способности в дополнение к функции Advance Write Cache, являющейся стандартной в этой линейке.

Технология улучшенного кэша TurboBoost ™ от торговой марки Seagate Inc. стала самым значительным усовершенствованием в конструкции дизайна стандартного корпоративного жесткого диска (скорость оборотов 10К и 15К в минуту). Этот новый диск 512e включает в себя небольшое количество памяти eMLC NAND в качестве кэша, что уменьшает задержки и значительно ускоряет время реакции, делая его предсказуемым.

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

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

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

Инфраструктура виртуального рабочего стола
Оперативная обработка транзакций
Веб-серверы
Запросы к малым базам данных
Рабочие нагрузки Exchange
Произвольные задачи чтения/записи

Для получения подробной информации о результатах производительности дисков разной емкости см. документ со сравнительными характеристиками.

Рекомендации по твердотельным накопителям

Следующие категории корпоративных накопителей SSD EMC:

Главный интерфейс - накопители SSD EMC совместимы со следующими устройствами:

Также обращаю внимание, что проблема разбирается на конкретной модели Samsung 970 pro и VMWare 6.7. Не надо думать, что все виртуалки и все диски NVMe ведут себя одинаково и бездумно тиражировать текущий подход статьи ко всему. В каждом конкретном случае надо проходить полный путь расследования, как в статье.

Проблема с дисковой производительностью

Ситуация: сервер 1С/СУБД, на котором наблюдаются существенные проблемы с производительностью дисковой подсистемы : время обслуживания дисковых операций исчисляется не единицами миллисекунд (как хотелось бы), не десятками (как ещё допустимо), а несколькими сотнями, причём это же видно и средствами операционной системы.

Выглядит это например вот так:

Первая реакция: такие показатели характерны для загруженного механического (дефакто медленного) диска.

Первые тесты

Дожидаемся технологического окна, когда службы 1С и СУБД можно полностью остановить, нагрузку с диска снимаем, и прогоняем тест CrystalDiskMark

Результаты выглядят вполне прилично для недорогого NVMe SSD (отклик должен быть около 10 мс, а не сотнями мс как у нас). Идём выяснять, что же там “под капотом”. Выясняем, что данные расположены на неплохом (для десктопа, не для сервера) NVMe SSD Samsung 970 Pro, который хоть и не “энтерпрайз класса”, но и вот настолько проседать под такой нагрузкой вроде как не должен.

Вот нормальный результат диска на физическом сервере для сравнения.
Идём разбираться дальше: сервер развёрнут на виртуальной машине на базе VMWare ESXi 6.7, SSD используется в “виртуализованном” виде:

Из диспетчера устройств виртуальной Windows устройство видно например так:

В данном виде гостевая операционная система видит SSD как некий сетевой массив, и управлять этим SSD не может (например, не передаётся команда TRIM). И явно для данного SSD это не является “комфортным” режимом работы. Попробуем это изменить.

Вносим изменения в конфигурацию

И вот здесь наступает пора внести изменения!

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

Затем идём в консоль ESXi хост-машины, где развёрнута наша система, и делаем следующее:

Что же изменилось?

Далее загружаем виртуальную ОС, и внутри наблюдаем вместо устройства с добавлением VMWare “родное” название устройства, рядом с двумя устройствами, для которых проброс не включен и которые продолжают обслуживаться средствами VMWare.

Теперь этот SSD надо заново отформатировать (мы использовали размер кластера 8 килобайт, так как именно таков размер страницы данных в MS SQL, а именно базы СУБД на этом диске и будут расположен).

И настала пора сравнить результаты тестов CrystalDiskMark:

Итоговый результат

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

Результаты снимков монитора ресурсов “до и после” для удобства свели в одну картинку.

Обратите внимание, насколько ускорилось время ответа дисковой подсистемы, и при этом насколько увеличились объёмы чтения и записи. Оборудование сервера по факту не изменилось, но драматически выросла его производительность!

Вывод

Как минимум в данном сценарии, использование десктопного NVMe SSD в VMWare ESXi 6.7 в виртуализованном варианте приводило к существенному ухудшению производительности SSD, при этом “формальный” тест CrystalDiskMark мог выглядеть “вполне прилично” (если не сравнивать “в лоб” с показателями ровно такого же устройства, подключенного напрямую). Подключение же NVMe SSD напрямую в виртуализованную операционную систему привело к тому, что ОС смогла управлять диском напрямую (например, подавать команды TRIM), и производительность диска увеличилась и стала больше соответствовать данной модели NVMe SSD.

статья может оскорбить религиозные чувства многих админов

Затем появились SSD, или твердотельные накопители ( сокращённо они до сих пор называются “диски”, хотя там уже круглого ничего не осталось 🙂 ), скорость которых поначалу той же была хоть и выше, чем у механики, но всё равно “не радующей”, а надёжность вызывала сомнения (до сих пор большое количество айтишников уверены, что “SSD ненадёжные”), и эти SSD тоже по привычке запихивались в RAID-массивы. Однако “внезапно” стало проявляться, что далеко не всегда скорость итогового массива из SSD так же хорошо масштабируется, как если бы это был массив механических дисков, и тому есть ряд причин. Наиболее важные для нас минусы:

На снимке ниже: пример такого массива, собранного “неправильно”, формата RAID50, в котором 10 (десять) SSD. Причём в этом массиве “хорошо” себя показывает только чтение, и только крупными порциями (верхняя строчка Seq в колонке Read каждого из двух результатов). Запись даже крупными порциями (верхняя строчка Seq в колонке Write) показывает нам всего 142 мегабайта в секунду, а многопоточная запись пакетами по 4 килобайта (нижняя строчка 4K QD32 в колонке Write) даёт нам всего около 16 мегабайт в секунду.

По нашим наблюдениям, в массе случаев и владелец бизнеса, и айти-руководитель подходят к выбору личного автомобиля гораздо вдумчивей, тщательней и придирчивей, чем к вопросу подбора сравнимого по стоимости серверного оборудования “на работу”.

Временные данные 1С или СУБД, а также вторичные данные, потеря которых не остановит работу компании.

Вышедшие NVMe PCIe 4.0 диски типа intel D7-P5600 настолько быстры, что современные сервера на RAM-дисках не дадут сколько-то значимого преимущества, но при этом обладают недостатками надежности при отключении питания. Для малого бизнеса есть бюджетные диски типа Samsung 980 Pro.

Основные данные и файлы лицензирования ключей 1С.
Надежность дисков серии intel p3700, p4800 проверена временем. На таких дисках можно смело размещать основные данные. Вероятность выхода из строя таких дисков меньше чем блока питания к примеру. На некоторых проектах такие диски успешно работают более 5 лет.

В итоге: для сервера 1С/СУБД RAID-массив из NVMe SSD в большинстве случаев не является необходимым ни для ускорения, ни для повышения надёжности.

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