Сравнение серверных SSD по TBW и DWPD: как сопоставить модели

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

Два SSD одинакового объема могут вести себя в сервере совершенно по-разному. Один держит ровную скорость при длительной записи и не уходит в «тормоза», другой резко проседает после заполнения кеша. Где-то критична задержка, где-то важнее стабильность на фоне мелких операций, а где-то на первом месте ресурс.

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

Неверная замена - это не только вопрос скорости. Чаще всего риски такие:

• ускоренный износ из-за неподходящего класса выносливости;
• таймауты и «выпадения» из RAID (ложные fault, degraded);
• проблемы с поддержкой, если диск вне списка совместимости;
• неожиданные простои из-за несовместимой прошивки или режимов питания.

Иногда «аналог» действительно достаточен - например, для тестового стенда или второстепенного сервиса, где есть запас по производительности и простой допустим. Для продакшена (БД, виртуализация, критичные сервисы) обычно разумнее добиваться точной совместимости: совпадения по классу (read intensive или mixed use), форм-фактору и интерфейсу, а также по требованиям HCL и версии прошивки.

TBW и DWPD простыми словами: как не ошибиться в цифрах

При сравнении серверных SSD по TBW и DWPD легко попасть в ловушку: числа выглядят точными, но без контекста описывают разные сценарии.

TBW (Total Bytes Written) - это общий объем данных, который производитель «разрешает» записать на диск за гарантийный срок. TBW почти всегда привязан к конкретной модели, ее емкости, типу памяти и методике тестирования. Поэтому корректно сравнивать TBW напрямую можно только между дисками одинакового объема и одного класса (например, read intensive против mixed use).

DWPD (Drive Writes Per Day) переводит выносливость в более понятную меру: сколько раз в день можно полностью перезаписать весь объем диска в течение гарантии. Прикидка простая:

• DWPD = TBW / (емкость диска в TB * количество дней гарантии)
• TBW = DWPD * емкость * дни гарантии

Срок гарантии здесь критичен. Один и тот же DWPD при 3 и 5 годах означает разный TBW. И наоборот: одинаковый TBW при разной гарантии даст разный DWPD. Поэтому сравнение «диск A на 3 года» и «диск B на 5 лет» без пересчета почти всегда вводит в заблуждение.

Почему «больше TBW» не всегда лучше именно для вас? Потому что выносливость - не единственный риск. Для файлового сервера с редкой записью важнее стабильная работа, совместимость с контроллером и предсказуемая задержка, чем максимальный DWPD. Для базы данных с постоянными журналами записи важны и высокий DWPD, и то, как диск держит длительную запись без просадок.

Пример: если диск 3.84 TB имеет 1 DWPD на 5 лет, это примерно 3.84 TB записи в день. Если по мониторингу у вас около 1 TB записи в день, вы, скорее всего, переплачиваете за класс выносливости, который не используете. В такой ситуации выгоднее вложиться в совместимость и поддержку.

Какие данные собрать перед сравнением: не только TBW и DWPD

Цифр ресурса недостаточно. Два накопителя могут выглядеть одинаково на бумаге (емкость и TBW близки), но не встанут в сервер или начнут давать ошибки из-за формата секторов, шифрования или несовпадения точного парт-номера.

Сначала зафиксируйте базовую «геометрию» и интерфейс: SSD или HDD, SATA/SAS/NVMe, форм-фактор (2.5", M.2, U.2/U.3), высота (например, 7 мм или 15 мм), наличие салазок и тип разъема. Эти вещи чаще всего ломают замену «один в один», даже если ресурс и скорость подходят.

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

Удобно держать на каждую модель одну карточку с полями:

• точное обозначение: model name, part number (PN), option kit, FRU, SKU;
• ресурс и гарантия: TBW/DWPD, срок гарантии, условия (что считается записью);
• производительность: IOPS и задержка с указанием профиля (random/sequential, read/write, queue depth);
• профиль нагрузки: read-intensive, mixed-use или write-intensive;
• спецтребования: SED/шифрование, формат секторов 512e или 4Kn, поддержка sanitize/secure erase.

Отдельно запишите энергопотребление (idle и под нагрузкой) и требования к охлаждению. В плотных стойках лишние 2-3 Вт на диск могут поднять температуру корзины и привести к троттлингу.

Небольшой пример: в сервере стоят 4Kn NVMe U.2, а замену выбирают только по TBW и емкости и берут 512e. Диск определяется, но RAID или гипервизор начинает ругаться на формат, и миграция затягивается. Если заранее собрать эти параметры, таких сюрпризов становится заметно меньше.

Шаг за шагом: как сопоставить модели в одной таблице

Чтобы сравнение серверных SSD по TBW и DWPD было практичным, удобнее свести все в одну таблицу и сначала убрать варианты, которые физически не подойдут. Так вы не утонете в «похожих» моделях, которые отличаются критичными мелочами.

1. Отфильтруйте по базовым параметрам: интерфейс (SATA, SAS, NVMe), форм-фактор (2.5", U.2, M.2, E1.S/E3.S), высота корпуса, тип разъема.

2. Приведите выносливость к одному виду на срок гарантии. Удобная формула:

TBW = DWPD × емкость (TB) × 365 × лет гарантии.

Например, 1.92 TB диск с 1 DWPD на 5 лет: 1 × 1.92 × 365 × 5 = 3504 TBW. Так вы сравниваете «ресурс на гарантию», а не разрозненные числа из карточек.

3. Добавьте ограничения, которые часто ломают совместимость: 4Kn или 512e (особенно важно для некоторых контроллеров и старых ОС), наличие power-loss protection, рабочие температуры и требования к воздушному потоку.

4. С производительностью будьте аккуратнее: сравнивайте результаты в сопоставимых условиях (очередь, блоки, тип нагрузки, заполнение), а не «максимум» из рекламной строки. Во многих задачах важнее стабильность задержек, чем пик IOPS.

Чтобы быстро принимать решения, удобно сразу присваивать статус:

• подходит точно;
• под вопросом;
• не подходит.

Тогда таблица становится инструментом выбора, а не справочником.

Прошивки: что нужно знать, чтобы диск работал стабильно

Прошивка (firmware) - это встроенное ПО SSD. Она управляет записью, очисткой блоков, энергосбережением, обработкой ошибок и тем, как диск общается с контроллером сервера. «Серверная» прошивка обычно настроена на предсказуемую задержку, корректные таймауты и аккуратную работу с командами RAID, поэтому два внешне похожих SSD могут вести себя по-разному.

Проблемы начинаются там, где версии firmware отличаются даже у одинаковой модели и объема. На практике это проявляется в странных SMART-показателях, внезапных reset, росте media errors и, самое неприятное, в таймаутах под нагрузкой. Из-за них RAID-контроллер может пометить диск как degraded или failed, хотя сам SSD физически еще жив.

Как проверить прошивку и понять, что обновлялось

Проверьте версию firmware в ОС и сопоставьте ее с документами поставки и спецификацией. Полезно запросить у поставщика release notes именно для этой линейки.

Минимум, который стоит собрать:

• модель и part number;
• текущая версия firmware на каждом диске;
• дата поставки и партия (если есть);
• модель RAID/HBA и версия его firmware;
• логи ошибок и таймаутов за последние недели (если замена делается «по симптомам»).

Когда критична «вендорская» прошивка и почему не всегда стоит прошивать самим

У некоторых платформ производитель сервера тестирует SSD с конкретной прошивкой и добавляет их в матрицу совместимости. В таких случаях поставка дисков с «одобренной» версией снижает риск сюрпризов после ввода в эксплуатацию.

Самостоятельная перепрошивка тоже может быть рискованной: можно получить несовместимость с RAID или бэкплейном, а также потерять поддержку, если обновление сделано не утвержденной утилитой или не по регламенту.

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

HCL и совместимость: как правильно читать списки

HCL (Hardware Compatibility List) - это перечень компонентов, которые производитель сервера или контроллера проверил в конкретной конфигурации. Он часто важнее, чем «подходит по характеристикам»: даже если SSD совпадает по формату и TBW/DWPD, он может вести себя нестабильно из-за прошивки, таймингов, power-loss protection или особенностей работы с очередями команд.

Совместимость обычно фиксируется не «в целом с сервером», а по цепочке: сам сервер, бэкплейн, RAID/HBA, версии BIOS и BMC. Поэтому при замене важно понимать, где именно возможен конфликт.

Как читать запись в HCL

В хорошей записи важны детали, а не бренд. Сверяйте:

• точный part number (PN) и ревизию;
• емкость, интерфейс и форм-фактор;
• требуемую или допустимую версию firmware;
• модель RAID/HBA и режим (RAID, HBA, passthrough);
• ограничения вроде «только для boot» или «нельзя смешивать».

Если диска нет в списке

Отсутствие в HCL не всегда означает «не будет работать». Чаще это «не тестировали» и «не гарантируют». Практичные варианты: запросить результаты валидации, подобрать ближайший PN из HCL или провести пилот на одном сервере с мониторингом логов.

Отдельно проверьте смешивание партий и ревизий в одном массиве. Даже одинаковые модели с разной прошивкой или другим NAND-степпингом могут отличаться по задержкам и износу. В RAID это иногда приводит к неожиданным rebuild-таймам и «сыплющимся» предупреждениям.

Как TBW/DWPD и прошивка связаны с RAID и реальной нагрузкой

TBW и DWPD описывают выносливость, но в RAID они работают не в вакууме. Контроллер распределяет записи, перестраивает данные при сбоях и держит очередь команд. Если прошивка SSD ведет себя иначе, чем ожидает контроллер, вы получаете не просто меньший ресурс, а риск нестабильного массива и просадок скорости.

Один из частых конфликтов - таймауты. При ошибке чтения SSD может слишком долго пытаться «лечить» блок (долгий error recovery). Для одиночного диска это терпимо, а для RAID плохо: контроллер ждет ответ, видит задержку, сбрасывает команду и помечает диск как проблемный.

Смешивание SSD разных серий и даже партий тоже добавляет нестабильности. Причина обычно в «мелочах»: разные алгоритмы SLC-кэша, разные задержки под нагрузкой, отличия firmware. В итоге один диск начинает отставать, растут очереди, появляются reset/timeout, а RAID уходит в degraded чаще, чем должен.

Реальная нагрузка меняет картину износа. База данных и VDI дают много мелких записей и высокий write amplification. Файловый сервер чаще упирается в чтение и метаданные. Системные разделы могут казаться «легкими», но из-за логирования и обновлений создают постоянный фон.

Полезно закладывать запас: держать 10-20% свободной емкости, иметь hot spare той же серии (и по возможности с близкой прошивкой), не смешивать «похожие» модели в одном массиве и заранее понимать, сколько времени массив будет жить в degraded при замене.

Если что-то идет не так, смотрите логи контроллера и ОС: media errors, timeout, reset, переходы в degraded и частоту реконструкций. Эти признаки часто выдают несовместимость или неудачное сочетание прошивки и RAID еще до реального отказа диска.

Пример из практики: замена дисков без остановки бизнеса

В одном проекте у заказчика (офисная ИТ-служба, критичный документооборот) начали выходить из строя SSD в сервере с RAID. Диски менялись «на горячую», но исходная модель уже не поставлялась, а простой даже на час был нежелателен.

Задача была не «найти любой SSD того же объема», а подобрать замену так, чтобы массив не начал сыпать ошибками и не просел по ресурсу. Здесь пригодилось сравнение серверных SSD по TBW и DWPD, но только вместе с проверкой HCL и прошивок.

Как приняли решение

Сначала разделили варианты на два уровня.

«Точный эквивалент» - совпадают форм-фактор и интерфейс (например, 2.5" SATA или U.2), класс диска (read intensive или mixed use), DWPD близко к исходному (обычно допустима разница до 10-15%), а гарантия по сроку не хуже.

«Условный эквивалент» - ресурс подходит под расчет нагрузки, но есть отличия по PN, прошивке или нет подтверждения в HCL.

Дальше проверили совместимость по HCL сервера и RAID-контроллера. Если интерфейс совпадает, но PN другой, это не значит «точно не будет работать». Это значит, что риски выше: контроллер может ругаться на non-certified, не показать SMART как нужно или вести себя нестабильно под нагрузкой.

Чтобы не гадать, сделали пилот: поставили один диск, посмотрели логи RAID и поведение под нагрузкой, и только после этого утвердили закупку партии.

Как оформили для закупки

Свели решение в короткую таблицу выбора:

Так заказчик заменил диски поэтапно без остановки сервиса, а выбор был понятен и ИТ, и закупке: что берем, почему берем и какой риск принимаем.

Частые ошибки при подборе аналогов и почему они дорого обходятся

Самая дорогая ошибка - считать, что «любой SSD одинаковый, главное объем». В сервере диск работает под постоянной нагрузкой, в связке с RAID, очередями команд и требованиями к отказоустойчивости. Поэтому оценка по TBW/DWPD имеет смысл только вместе с совместимостью и прошивками.

Чаще всего ошибаются так:

• берут потребительский SSD вместо серверного из-за цены и емкости;
• сравнивают TBW между моделями с разной гарантией и разным профилем нагрузки;
• игнорируют 4Kn и 512e, из-за чего ломаются установка, миграция или проседает производительность;
• не проверяют требования RAID-контроллера и получают таймауты и постоянные ребилды;
• смешивают ревизии и прошивки «одинаковой» модели, а проблемы всплывают редко и тяжело диагностируются.

В продакшене цена ошибки редко ограничивается покупкой «другого диска». Чаще тратятся дни на диагностику, а сервисные окна растягиваются.

Быстрый чеклист перед покупкой или заменой

Перед заменой зафиксируйте условия задачи: где стоит диск (сервер или СХД), какая роль (журналы БД, виртуализация, кэш), что важнее - ресурс записи, задержки или предсказуемость работы в RAID.

Короткий чеклист:

• Совпадает «механика»: интерфейс, форм-фактор, высота, лоток/крепление, требования по питанию и охлаждению именно в вашем шасси.
• Ресурс сопоставим: TBW/DWPD пересчитаны на срок гарантии и сопоставлены с вашей реальной записью.
• Совместимость подтверждена по спискам: проверены HCL для сервера и RAID/HBA, а также допустимые версии прошивок. Если модели нет в HCL, вы заранее понимаете, что берете риск.
• Прошивки и обслуживание спланированы: кто обновляет, каким инструментом, в какое окно, и что делать при откате.
• Правила замены понятны: без смешивания партий без необходимости, сначала 1-2 диска в пилоте, потом массовая замена.

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

Следующие шаги: как безопасно внедрить выбранную модель

Даже если по TBW/DWPD диск выглядит идеальным аналогом, безопасное внедрение решают «мелочи»: ревизия, прошивка, режимы питания, поведение в RAID и реакция на ошибки.

Начните с короткого пилота и фиксируйте результаты. Лучше потратить 1-2 дня на проверку, чем потом разбирать деградации массива.

Мини-план внедрения

1. Поставьте 1-2 диска в тестовый сервер или в не критичный узел. Прогоните типовую нагрузку (чтение, запись, смешанный профиль). Проверьте логи контроллера и S.M.A.R.T.

2. Сверьте фактическую прошивку диска и контроллера с тем, что допускает HCL. Если прошивка отличается, заранее решите, кто и как будет обновлять, и где лежат проверенные пакеты.

3. Подготовьте план замены: порядок дисков, окна обслуживания, наличие hot spare, правила ребилда, пороги тревог. Отдельно запишите, что делать при росте ошибок или падении производительности.

4. Сделайте пробную замену на одном массиве и замерьте время ребилда, температуру, частоту ошибок и скорость записи под реальной нагрузкой.

5. Зафиксируйте спецификацию для закупки: точные P/N, емкость, форм-фактор, интерфейс, требуемая прошивка и ограничения из HCL (сервер, RAID-контроллер, backplane).

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