В индустрии есть устоявшееся мнение, что HDD — это устаревающая технология.
Это с одной стороны. С другой стороны, много у кого написано «Медленные SSD», а по факту при тестах они начинают показывать характерные скорости HDD, характерные бутылочные горлышки HDD и вообще ведут себя как жёсткие диски.
У нас тоже есть тариф с HDD-хранилищем, но он довольно давно тариф с HDD-содержащим хранилищем, потому что уже пять-шесть лет (в зависимости от страны) мы закупаем SSD вместо HDD. Совсем скоро последние хрустящие диски уйдут из эксплуатации, и это будет тариф типа SSD с ограничением по скорости для совместимости с легаси-ценами.
При этом мы используем HDD для долговременного хранения.
Основная проблема HDD — это механика
Внутри идут вращение шпинделя, позиционирование головки, трение. Из-за этого количество операций ввода-вывода IOPS физически ограничено.
HDD выдаёт около 150–200 IOPS. Задержка — миллисекунды.
SSD (SATA/SAS) — десятки тысяч IOPS.
SSD NVMe — сотни тысяч IOPS.
Разница — не в разы, а на порядки. В условиях хостинга, когда дисковый массив — это коммунальная квартира, которую делят сотни клиентов, это критично. Если кто-то один впилится в жёсткий диск записью огромного количества фрагментов меньше кластера и в случайные места на карте диска, то остальные будут стоять в очереди и ждать.
Поэтому, даже если вы просто хотите, чтобы ваши клиенты не испытывали тормозов на скоростях обычного HDD и на тарифе с обычным HDD, надо брать SSD.
Изменился сам веб. Если раньше мы на низком уровне по факту работали с крупными файлами и нагрузка ложилась на оперативку, то сейчас из-за Докера и k8s нагрузка стала дробной. Плюс очень многое стало возможным перераспределять на диски, зная, что они потенциально быстрые. Контейнеры, слои образов, логи микросервисов генерируют огромное количество мелких операций random I/O. Запускать кубера на механическом диске — технически плохая идея: диск просто не справится с очередью запросов, и iowait съест производительность процессора, даже если канал свободен.
Что можно сделать
HDD можно соединять в быстрые RAID (с дублированием). ОК, мы давно так делаем, ограничения — те же, просто чуть расширяются.
Есть устройства класса SSD+HDD или оперативка + HDD, где контроллер выступает кэшем. Условно, у вас есть 10 ТБ-накопитель, у которого 10 ГБ — это кэш контроллера (либо 1 ТБ — быстрый SSD, а остальное — хард, бывают разные вариации). Если вы пишете, скажем, 5 ГБ — их хватает контроллер, записывает в быструю память и потом постепенно распихивает по медленной. Если нагрузки неравномерные, как на десктопе, то всё прекрасно, со стороны это быстрый на запись диск и как-повезёт-на-чтение диск (попали в кэш или нет). То есть он как бы сам внутри себя делит данные на «горячие» и «холодные».
Вариантов там много, но мы такого не используем. Во-первых, они не предназначены для нормальных энтерпрайз-применений, когда запись-чтение может идти постоянно 24 часа в сутки и в разные места: в этой ситуации кэш быстро прокручивается, и вы работаете с HDD почти напрямую. Во-вторых, они создают дополнительные точки отказа, например, очень сложно объединяются в RAID. Рассинхрон кэша и основного диска может привести к полной потере данных. Отказ SSD-кэша делает недоступным весь массив. В-третьих, это зоопарк. А зоопарк мы очень не любим.
В итоге мы оставляем только SSD и NVMe
У нас наш тариф HDD — на самом деле постепенная миграция с HDD на SATA SSD. Мы искусственно режем скорость и IOPS до уровня хорошего жёсткого диска.
Почему так:
Нам проще и надёжнее обслуживать парк SSD (нет движущихся частей, ниже риск внезапного отказа), чем поддерживать зоопарк из разных типов накопителей. Исторически мы очень сильно стремимся к гомогенности железа, потому что это очень сильно облегчает и разработку, и ремонт-обслуживание, и логистику, и закупки, и вообще всё в хостинге.
Если мы переведём всех на быстрый SSD, то нам придётся поднять цены, и тогда клиенты уйдут. На рынке есть умолчание, что есть дешёвый дисковый тариф, но его как раз ограничивают, чтобы он не конкурировал с дорогими. Это искусственное ограничение из-за того, что все так делают — вероятно, в ближайшие годы оно уйдёт.
Есть привычки клиентов. Пользователь видит HDD и интуитивно считывает это как набор параметров + это дёшево и много места. Когда написано SSD — в голове вообще ничего не всплывает. Если тот же тариф назвать «Медленный SSD» или «Throttled SSD», то это вообще никак не поможет UX. HDD тут с годами стал просто красивой метафорой. Хотя на некоторых серверах они ещё остались.
А лента, лента для холодного хранения?
Удел HDD сейчас — долгое холодное хранение. Мы оставим пул HDD в хостинге как раз для этого. По большей части — для бэкапов. Это бэкапы, архивы логов, старый медиаконтент. Там, где нужно дёшево хранить терабайты и редко к ним обращаться, механика по-прежнему выигрывает по цене за гигабайт.
У нас сейчас есть услуга, где можно получить очень много места дёшево для архивов — это как раз массив классических механических HDD, на котором выделяется виртуальный ресурс.
Но в бэкапах есть другая технология холодного хранения — старая добрая магнитная лента. Много кто действительно хранит на ней — за этим, например, замечены Google или ЦЕРН.
В целом мы считали и решили, что та же причина зоопарка того не стоит. Выигрыш на наших масштабах не очень большой. Всё же это решение — для специфических задач вроде научных данных (которые надо всё время копить на тот случай, если они пригодятся через 20 лет), банковских архивов с хранением 50 лет, видеоконтента и так далее.
В хостинге, если клиенту понадобился бэкап, он нужен ему прямо сейчас. Никто не готов ждать час, пока робот найдёт кассету и перемотает её на нужное место. Экономия на носителе не перекрывает потерь от времени простоя и сложности введения дополнительной железяки в обслуживание.
Поэтому там, где надо дешевле, у нас только HDD.
Но ведь HDD дают безлимитное хранилище!
Это просто дикая боль.
Приходят клиенты и говорят, что на рынке есть тарифы с безлимитным хранилищем.
Это, если что, физически невозможно. Ну, без потерь данных.
В физическом мире безлимитов не существует. Канал (скорость записи) имеет ёмкость, а диск имеет объём. На уровне гипервизора всегда стоят жёсткие лимиты, чтобы один активный клиент не положил сервер и не лишил ресурсов остальных соседей. Безлимит — это всегда маркетинг. Вам дадут пользоваться ресурсом, пока вы не начнёте мешать другим и в разумных рамках.
HDD никаким образом не означает безлимит. Но да, часто само слово означает для клиента «бюджетное хранилище».
Итого
Самые дорогие тарифы — NVMe-диски. Никто нормально не решил проблему объединения их в массивы с избыточностью, поэтому, если вылетает один такой диск, теряются данные. Рядом с ними обычно стоят HDD для бэкапов по расписанию, например, раз в сутки или итеративных раз в четыре часа.
Обычные тарифы — SSD-массивы, мы перешли на RAID 10. Вот пост, почему мы так сделали. С них можно подключиться к хранилищу на HDD и получить там виртуальный диск, где физика будет на механических дисках.
Дешёвые тарифы — те же SSD-массивы и иногда уже выводящиеся из эксплуатации HDD. В будущем — только SSD-массивы.
Технические диски — образы операционок, промежуточные бэкапы и так далее — иногда бывают классическими HDD.
Комментарии (127)
kulykovdmytr
31.03.2026 08:35Вообще рано хоронить HDD-диски, Western Digital разрабатывает HBD и Dual Pivot, что позволит приблизиться к скоростным характеристикам SSD. На сколько я знаю, диск в целом надежнее.
ildarz
31.03.2026 08:35Не позволит ни то, ни то. Вернее, может сократить отрыв в сценариях линейного чтения, но в случайном ощутимо ничего не поменяет. А основные преимущества SSD - именно в скорости случайного доступа.
de_gamer
31.03.2026 08:35Почему не поменяет? Пара независимых головок явно быстрее одной, а восемь - быстрее двух. С оперативкой многоканал почему-то работает же.
ildarz
31.03.2026 08:35восемь - быстрее двух.
Потому что если вы с HDD снимете не 200 IOPS, а 800, это никак не поменяет того, что даже у SATA SSD все равно останется 80К, что на пару порядков больше. И не забываем, что скорости SSD тоже на месте не стоят.
some_dude
31.03.2026 08:35Сценарии в которых вам со всей ёмкости стоража надо снимать много IOPS единомоментно, можно пересчитать по пальцам одной руки, и в среднем некроваво тырпрайзном применении они практически не встречаются.
Nalichnik
31.03.2026 08:35Если говорить серьезно, то в современной серверной архитектуре нижний уровень коим является уровень хранения всегда был узким местом. В текущее время в серверной инфраструктуре этот нижний уровень простаивает крайне редко и если это происходит, то скорее по халатности административного персонала поскольку недогруженное оборудование это по сути пустая трата денег. Если что-то не догружено - включите компрессию, дедупликацию, начните использовать простаивающие ресурсы.
VIVAKO
31.03.2026 08:35Идея о нескольких блоках головок не нова, ей лет сорок уже. Насколько я знаю, регулярно пытаются сотворить что-то такое, но в серию ни разу не пошло.
413x
31.03.2026 08:35Статистика по простому бытовому использованию, сколько умерло носителей за ~20+ лет пользования ПК:
0 HDD - примерно 7 было.
1 SSD - было 4 диска.
Плюс HDD еще в том, что он не умирает мгновенно, вполне вероятно что еще успеете сохранить нужные для себя данные перед смертью диска.
linux-over
10 лет назад я занимался проектами с использованием PostgreSQL. И в связи с этим на одной из конференций (highload, кажется) пообщался с нашими постгри-профовцами. О правильности подбора/организации железного сета для БД.
Так вот, они мне тогда посоветовали использовать hdd контроллеры "с батарейкой". Сейчас я моделей уже не помню, а тогда пошёл и нашёл - на рынке было много предложений.
Смысл железки заключался в следующем. У hdd/ssd есть батарейка и своя память. И потому при внезапном отключении питания батарейка позволит hdd ещё сколько-то проработать и своя память контроллера окажется сброшенной на диск с гарантией.
Это приводило к тому, что системный вызов fsync происходил условно-мгновенно.
А что сейчас с этими технологиями? Всё ещё нужны или канули в Лету?
или вот эта пара, что Вы описали (ssd внутри hdd) именно для этого и предназначена?
xSVPx
Они вам не советовали ups купить :)? Действительно некогда были контроллеры с отдельным питанием, но сейчас то вам это зачем ? Питание любого сервера и так обеспечивается, а обслуживать отдельные батарейки "такое себе".
Подозреваю с кешем на ssd ничего не будет и при потери питания. Он же там физически записан. Ну т.е. хороший контроллер доперепишет на hdd когда сможет.
linux-over
оно и тогда обеспечивалось. но из-за пусть и низкой, но ненулевой вероятности мгновенного выключения, подобные девайсы были популярны, и их можно было дозаказать в свою стойку в любом ДЦ. И время выполнения fsync при этом становилось минимизировано.
когда железо даёт гарантию чего-то, то эта гарантия всегда небесплатна.
да похоже это и есть реинкарнация той же технологии просто на современном уровне
max9
BBU вполне остался в хардварных рейдах. но смысла в контексте статьи в нем никакого, тк в датацентры идет несколько вводов питания. при пропадании одного упс отрабатывает до переключения ввода.
linux-over
ещё разок (мне кажется я эту мысль высказал, но она осталась незамеченной).
Сколько бы UPS вы ни делали, а софт будет писаться исходя из парадигмы, что его могут выключить в произвольный момент времени. По крайней мере, к БД это относится напрямую.
Потому аппаратные решения, позволяющие сократить время fsync будут популярны в любое время. И, как я понял, сегодня ssd заменяет ту батарейку, что была популярна 10-15 лет назад.
xSVPx
Дело тут не в батарейке, а в логике работы системы либо рейд контроллера
Вообще-то ведь даже в windows раньше точно можно было переключать политику. И если выбрать менее безопасные режимы, то все будет работать как вы пишите. Совершенно без батареек.
linux-over
но если переключить режимы на менее безопасные, то станет менее безопасно :)
ildarz
Что винда, что Линукс предоставляют api для прямой записи, минуя системные кэши, а примерно любой софт, который сам беспокоится о сохранности собственных данных (те же сервера SQL), ими пользуется. Поэтому энергонезависимый кэш оказывается востребован вне зависимости от ситуации в ЦОДах и кэширования ОС.
Yuriy_krd
Там может стоять ионистор (или несколько) - тогда ничего обслуживать не нужно. Сейчас, например, во многие видеорегистраторы для автомобилей ставят ионисторы - чтобы на жаре не взрывались литий-ионные АКБ, хватает на полминуты-минуту, чтобы корректно завершить запись файла.
xSVPx
У вас есть опыт долговременного использования ионисторов ? Там не всё так благополучно, как кажется. Менять их тоже может понадобится. Ну т.е. это всё совершенно невечное.
Сейчас то вам это в сервере зачем ? Зарезервировано же обычно питание даже на уровне отдельных дублирующих бп.
Yuriy_krd
Видеорегистратор в авто 5 лет уже пашет. Пока жив и признаков сбоев не подает.
sndlr
В RAID контроллерах уже лет 15 вместо BBU ставят FBWC (Flash-Backed Write Cache), там как раз ионистор в сочетании с NAND flash. Заряда ионистора с запасом хватает чтобы скинуть данные кэша на флеш память, и это намного надежнее, потому что ионистор в сравнении с LiPo аккумом практически вечный.
Sna4es
Регистратор 70mai с супер конденсатором ( так заявлял производитель, что по факту внутри я не знаю) работает с 2017 года, пока вроде не заметно деградации по питанию
Stanislavvv
И обломаться с записью э... общения с автоподставой.
Ну и, кстати, я хз, что там и зачем, но в доступных мне напощупать не было полминуты на ионисторе. Было несколько секунд максимум, в одном экземпляре и этого не было.
MountainGoat
UPSы тоже дохнут. Причём вы не узнаете, что он сдох, до тех пор, пока электричество не отключится, и UPS вместе с ним.
AlexM2001
Разве самопроверки ёмкости батареи не штатная функция UPS?
blind_oracle
Штатная. Но у меня были случаи, когда пару дней назад проверка прошла Ок, а потом при реальном отключении всё умерло по вине батареи.
AlexM2001
Криво написанный софт по тестированию батареи IMHO
AlexanderS
А где гарантия, что он в следующей модели не будет кривым? Вот люди эти риски и отрабатывают...
blind_oracle
Возможно. Ну и вообще свинцово-кислотные батареи это такое бэээ. И ёмкость там 50% полезная только и живут они мало.
Я домашние ИБП на LIFePO4 перевёл все - пока что полёт нормальный, посмотрим сколько протянут.
AlexM2001
Подскажите пожалуйста бренд?
А то хороший UPS APC Smart 1500 есть в наличии. Но 15 лет на складе пролежал.
Батареи гарантировано умерли?
KN_Dima
Да.
Но купить новые - не проблема.
AlexM2001
Как вы считаете: UPS APC Smart то что пролежал на складе (отапливаемом) 15 лет, это очень много?
Какова вероятность что рабочие параметры самого UPC (не батарей) остались в пределах паспортных значений?
KN_Dima
Шансы - хорошие.
У меня дома работает APC UPS 1997 г.в.
AlexM2001
Спасибо!
Попробую поискать батареи на замену.
А затем проверить. Без рабочих батарей, работоспособность UPS не проверить?
KN_Dima
Только частично - что включается и пытается тестировать батареи.
PS
Батареи желательно брать хорошие, например CSB
AlexM2001
Спасибо.
Поищу именно CSB
blind_oracle
Бренд батарей или ИБП? ИБП разные, в принципе с LiFePO4 они все совместимы, в общем и целом т.к. напряжение одинаковое плюс минус.
Батареи я на Амазоне заказывал вот такие, но у них BMS слабоват: при переходе на аккум под нагрузкой он выключал батарею. Я его в них поменял и стало хорошо. В принципе можно самому собрать такую батарею из ячеек, это не сложно.
KN_Dima
Судя по фоткам, там внутри Li-Ion, а не liFePO4
KN_Dima
Соответственно, и напряжение там в принципе совпасть не может
blind_oracle
Там LiFePo4, я их вскрывал же чтобы BMS заменить. Там 4S2P (=8 ячеек) LiFePo4 4Ah цилиндрических (26650 формфактор вроде). Ну и в названии товара, очевидно, LiFePo4 написано.
Фото
KN_Dima
blind_oracle
И что?
LiFePO4 это тоже Li-Ion, внезапно. Читайте напряжение - 3.2v, это LiFePO4, 4 банки = 3.2v * 4 = 12.8v (14.4v при полном заряде).
У химий NMC и подобных (то, что под "литий-ионом" обычно подразумевают) - 3.6/3.7v среднее напряжение.
KN_Dima
Вы ёмкость проверяли?
Разрядную кривую?
Написать можно всё, что угодно.
blind_oracle
Проверял, около 96 ватт*часов. Не очень понимаю в чём вы меня пытаетесь убедить.
KN_Dima
Ни в чём. Просто с подозрением отношусь к неизвестным мне изделиям по причине наличия опыта с разнообразными поддельными аккумуляторами.
blind_oracle
Ну, я бы не стал палево рекомендовать.
Этих батарей у меня штук 5 трудится уже больше года, проблем нет. Я бы предпочёл сам собрать, но купить готовую на Амазоне выходит просто дешевле чем заказывать ячейки. Даже с учётом смены BMS, которая стоит ещё 2-3 бакса.
KN_Dima
А на что меняли BMS ?
blind_oracle
На такую вот с Али, на 100А я бы не надеялся, но, по крайней мере, тока для переключения на батарею достаточно. Вроде бы пока с ними проблем не было.
ptr128
Просто свинцово-кислотные АКБ требуют обслуживания. А на халяву, и уксус сладкий )
Через шесть(!) лет они и часа уже не тянут, несмотря на ежегодную десульфатацию, но у меня следующие есть на подходе )
mayorovp
Функция штатная, но не работает. Кучу раз наблюдал - по всем проверкам всё хорошо, но держится питание только полсекунды.
ulovka22
Батарейка только кэш запитывала, чтобы сбросить на диски, когда питание сервера снова появится. Чтобы весь массив дисков крутить, она слишком маленькая была.
Ну, по крайней мере у тех контроллеров, с которыми я дело имел.
SerjV
Там есть два варианта - более старый, когда батарейка кэш подпитывает (а когда заряд кончился - то ой), и более новый, когда суперконденсатор нужен затем,чтобы кэш сбросить на ssd - после чего уже "условно сколько угодно" можно ждать, пока восстановится питание.
И да, в отличии от ИБП - это сработает независимо от ОС и даже от значительной части остального железа. Так что для любителей бюджетных решений с допустимыми рисками - ИБП "на всё", для тех, кому не охота рисковать - и ИБП, и контроллер с внутренним сохранением кэша.
Mur81
Серьёзные NVMe SSD энтерпрайз класса на борту имеют конденсаторы предназначенные ровно для этого же - сбросить при потере питания данные из набортного RAM кэша на флеш. Если это накопитель в формфакторе обычной PCI-E карты, то там прям внушительный такой набор электролитов стоит. В M2 формфакторе конечно поскромнее но тоже есть.
ntsaplin Автор
Всё поменялось.
Вы говорите, скорее всего, о write-back cache.
Корпоративные SSD-диски, которые мы, в частности, используем, давно встраивают power loss protection. Поэтому сам по себе вопрос отпал.
JerleShannara
Наличие батареи конденсаторов для сброса кеша у корпоративного диска никак его не защитит от того, что кеш аппаратного рейда уйдёт в небытие при неожиданной потере питания, если конечно включен write-back на этом самом рейде (благо многие рейды на попытку его включить без BBU либо красно-красно ругаются и предупреждают, либо просто шлют лесом и не включают).
Nalichnik
Именно по этому они и используют программные рейды, т.к. при большом парке серверов облачного провайдера это только удорожает оборудование, а практической пользы не нет