Какой объем SSD соответствует требованиям к обработке корпоративных данных?

Понимание реальных характеристик ёмкости SSD: сырая, полезная и эффективная ёмкость

Как резервирование (over-provisioning) и накладные расходы прошивки снижают полезную ёмкость SSD

Цифры, указанные на корпоративных SSD, как правило, относятся к объёму «сывой» NAND-памяти внутри них, а не к тому объёму, который фактически доступен пользователю. Когда производители упоминают выделение резервного пространства (over-provisioning), они отводят примерно 28 % этой «сырой» памяти для таких функций, как сборка мусора и выравнивание износа — эти механизмы обеспечивают стабильную работу накопителя при интенсивной записи данных. Кроме того, прошивка занимает ещё 7–10 % объёма на такие задачи, как исправление ошибок, управление дефектными блоками и хранение информации контроллера. В результате всех этих выделений фактический объём полезного пространства значительно сокращается. Например, накопитель, заявленный как 1 ТБ, обычно предоставляет пользователю около 930 ГБ. Эта разница имеет большое значение при проектировании ИТ-инфраструктуры. Специалисты, работающие с базами данных или виртуальными машинами, хорошо знают: стабильная производительность операций ввода/вывода — это не просто удобство, а ключевой фактор, напрямую влияющий на соблюдение соглашений об уровне обслуживания (SLA) или их нарушение в периоды пиковой нагрузки.

Эффективное увеличение ёмкости SSD за счёт аппаратно-ускоренной сжатия и дедупликации

Современные корпоративные SSD борются с потерей ёмкости за счёт аппаратно-ускоренных методов сжатия и дедупликации, которые выполняются автоматически непосредственно в контроллере. Метод сжатия LZ4 показывает отличные результаты при обработке текстовых файлов и записей журналов, часто уменьшая их объём примерно наполовину — на две трети. Дедупликация применяется тогда, когда в различных виртуальных машинах или образах контейнеров присутствуют дублирующиеся блоки данных. При совместной работе этих двух технологий создаётся так называемая эффективная ёмкость, которая фактически в 1,5–2 раза превышает физический объём NAND-памяти. Например, стандартный QLC-SSD объёмом 15 ТБ может эффективно хранить до 27 ТБ логических данных благодаря этим оптимизациям. Мы получили впечатляющие результаты при работе с наборами данных для обучения ИИ, которые, как правило, содержат множество повторяющихся фрагментов — такие как контрольные точки моделей и пакеты синтетических данных. В таких случаях экономия места достигает 80 %, что позволяет использовать решения для высокоплотного хранения в целях архивирования и подготовки данных без заметного влияния на такие показатели производительности, как задержка (latency) и пропускная способность (throughput).

Соответствие емкости SSD основным корпоративным рабочим нагрузкам

SQL-базы данных: баланс плотности операций ввода-вывода, объема журнала и емкости SSD

Планирование емкости SSD для транзакционных баз данных имеет решающее значение, если мы хотим соответствовать требованиям к случайным операциям ввода-вывода (IOPS) и одновременно управлять ростом журналов транзакций. При работе с интенсивными по записи OLTP-нагрузками такие журналы могут занимать около 20–30 % доступного дискового пространства. При недостатке дополнительного места система начинает интенсивнее работать над управлением операциями записи, что ускоряет износ SSD и замедляет отклик. Согласно отраслевым стандартам, большинству систем, обрабатывающих примерно 50 тысяч транзакций в минуту, требуется как минимум в 1,5 раза больше «сырой» емкости данных только для хранения этих журналов, а также буферного пространства и временных операций с базой данных. Оставление запаса емкости в размере примерно 15–20 % действительно оказывает существенное влияние: это обеспечивает стабильность производительности в периоды пиковой нагрузки и увеличивает срок службы накопителей. Это особенно важно, поскольку существует прямая связь между достаточным запасом выносливости (endurance headroom) и поддержанием надежной работы в течение длительного времени, особенно в критически важных бизнес-средах, где простои влекут за собой финансовые потери.

Виртуализированные среды (vSphere/ Hyper-V): масштабирование емкости в зависимости от плотности виртуальных машин и политик создания снимков

Когда компании переходят на виртуализацию, им требуется значительно больше дискового пространства из-за большого количества совместно размещённых виртуальных машин (VM), а также потому, что каждая гостевая операционная система занимает определённый объём памяти. И не стоит даже упоминать о множественных снимках (snapshots), которые появляются повсюду. Большинству виртуальных машин требуется от 40 до 100 гигабайт только для установки операционной системы и приложений. Однако будьте осторожны при создании снимков во время обновлений программного обеспечения или резервного копирования — в этот момент объём используемого хранилища может вырасти почти вдвое. Если в среде одновременно работает более 50 виртуальных машин, специалистам ИТ, вероятно, следует зарезервировать дополнительно около четверти объёма SSD-пространства специально для хранения метаданных снимков, временных клонов и «назойливых» файлов подкачки (swap), накапливающихся со временем. Тонкое выделение (thin provisioning) действительно помогает сэкономить место на начальном этапе, однако никто не хочет столкнуться с внезапной нехваткой хранилища в дальнейшем, поэтому регулярный мониторинг является обязательным условием предотвращения проблем с производительностью. Для достижения наилучших результатов частоту создания снимков следует согласовывать с характером рабочих нагрузок. Критически важные производственные системы могут требовать ежечасных снимков, тогда как среды разработки и тестирования, скорее всего, обойдутся ежедневными. Такой подход снижает количество избыточных копий данных без ущерба для возможностей восстановления при возникновении проблем.

Серверы файлового и объектного хранилища: накладные расходы на метаданные по сравнению с требованиями к последовательной пропускной способности

Хранилище SSD распределяется между обработкой метаданных и перемещением фактических данных при работе с файловыми и объектными хранилищами. Системы, обрабатывающие большое количество метаданных — например, архивы медицинских изображений или массивные коллекции юридических документов — зачастую выделяют примерно четверть–треть всего объёма хранилища исключительно на такие задачи, как индексация файлов, навигация по каталогам и управление правами доступа. Подобным системам для обеспечения быстрого отклика при работе с большим количеством небольших файлов требуется как минимум 15 000 операций ввода-вывода в секунду (IOPS) на каждые десять терабайт. В свою очередь, конфигурации, ориентированные на высокую пропускную способность передачи данных, а не на случайный доступ к ним — например, рабочие станции для видеомонтажа или пулы долгосрочного хранения данных — в первую очередь требуют высокой линейной скорости. Им обычно необходимо обеспечивать непрерывную скорость записи свыше 1,5 гигабайта в секунду. SSD на основе ячеек QLC экономически оправданы для хранения подобных архивных данных, однако здесь есть важное уточнение: если ежедневно перезаписывается более трёх десятых от полной ёмкости дисков, их срок службы сокращается значительно сильнее, чем ожидалось.

Прочность и архитектура SSD: почему ёмкость должна соответствовать рабочим нагрузкам на запись

Влияние TBW, DWPD и типа NAND: SSD с ячейками SLC, TLC и QLC в условиях эксплуатации

Срок службы SSD зависит от трёх основных факторов: объёма данных в терабайтах, который можно записать (TBW), ежедневной ёмкости записи (DWPD) и типа используемой внутри технологии NAND. SLC NAND сохраняет работоспособность значительно дольше других типов, выдерживая от 50 000 до 100 000 циклов записи до износа. Недостаток? Её стоимость существенно выше, поэтому её применяют преимущественно в кэш-системах, где критически важна скорость — например, в платформах высокочастотной торговли в финансовой сфере. TLC занимает промежуточное положение: срок её службы составляет примерно от 1 000 до 3 000 циклов. Это делает её достаточно надёжной для типовых корпоративных задач хранения данных, при которых часто выполняются как операции чтения, так и записи. QLC же позволяет разместить значительно больше данных в меньшем физическом объёме и обеспечивает более низкую стоимость за гигабайт. Однако здесь есть подвох: её ресурс ограничен — максимум около 1 000 циклов. Такой показатель вполне приемлем для сценариев, где данные читаются гораздо чаще, чем записываются, например, для резервных копий, системных журналов или временных кэшей веб-сайтов, доставляющих контент.

Конвейеры обучения ИИ/МО: оценка жизнеспособности высокопроизводительных SSD с ячейками QLC при длительных операциях записи

Конвейеры обучения ИИ/МО предъявляют уникальные, чрезвычайно высокие требования к операциям записи в течение продолжительного времени — зачастую речь идёт о многократном импорте, перемешивании и создании контрольных точек (checkpointing) наборов данных объёмом в несколько терабайт. В таких условиях SSD с ячейками QLC подвергаются ускоренному износу: непрерывная запись круглосуточно может исчерпать их ресурс прочности за месяцы, а не за годы.

Выделение резервной ёмкости (over-provisioning) помогает продлить срок службы SSD с ячейками QLC, но не способно компенсировать фундаментальные архитектурные ограничения. Для производственной инфраструктуры ИИ выбор типа NAND-памяти должен соответствовать ожидаемой интенсивности операций записи — а не только потребностям в объёме хранения — чтобы избежать незапланированной замены накопителей, резкого падения производительности или рисков потери целостности данных.