Комментарии 58
10 лет назад я занимался проектами с использованием PostgreSQL. И в связи с этим на одной из конференций (highload, кажется) пообщался с нашими постгри-профовцами. О правильности подбора/организации железного сета для БД.
Так вот, они мне тогда посоветовали использовать hdd контроллеры "с батарейкой". Сейчас я моделей уже не помню, а тогда пошёл и нашёл - на рынке было много предложений.
Смысл железки заключался в следующем. У hdd/ssd есть батарейка и своя память. И потому при внезапном отключении питания батарейка позволит hdd ещё сколько-то проработать и своя память контроллера окажется сброшенной на диск с гарантией.
Это приводило к тому, что системный вызов fsync происходил условно-мгновенно.
А что сейчас с этими технологиями? Всё ещё нужны или канули в Лету?
или вот эта пара, что Вы описали (ssd внутри hdd) именно для этого и предназначена?
Они вам не советовали ups купить :)? Действительно некогда были контроллеры с отдельным питанием, но сейчас то вам это зачем ? Питание любого сервера и так обеспечивается, а обслуживать отдельные батарейки "такое себе".
Подозреваю с кешем на ssd ничего не будет и при потери питания. Он же там физически записан. Ну т.е. хороший контроллер доперепишет на hdd когда сможет.
Питание любого сервера и так обеспечивается
оно и тогда обеспечивалось. но из-за пусть и низкой, но ненулевой вероятности мгновенного выключения, подобные девайсы были популярны, и их можно было дозаказать в свою стойку в любом ДЦ. И время выполнения fsync при этом становилось минимизировано.
когда железо даёт гарантию чего-то, то эта гарантия всегда небесплатна.
Подозреваю с кешем на ssd ничего не будет и при потери питания. Он же там физически записан. Ну т.е. хороший контроллер доперепишет на hdd когда сможет.
да похоже это и есть реинкарнация той же технологии просто на современном уровне
BBU вполне остался в хардварных рейдах. но смысла в контексте статьи в нем никакого, тк в датацентры идет несколько вводов питания. при пропадании одного упс отрабатывает до переключения ввода.
ещё разок (мне кажется я эту мысль высказал, но она осталась незамеченной).
Сколько бы UPS вы ни делали, а софт будет писаться исходя из парадигмы, что его могут выключить в произвольный момент времени. По крайней мере, к БД это относится напрямую.
Потому аппаратные решения, позволяющие сократить время fsync будут популярны в любое время. И, как я понял, сегодня ssd заменяет ту батарейку, что была популярна 10-15 лет назад.
Дело тут не в батарейке, а в логике работы системы либо рейд контроллера
Вообще-то ведь даже в windows раньше точно можно было переключать политику. И если выбрать менее безопасные режимы, то все будет работать как вы пишите. Совершенно без батареек.
но если переключить режимы на менее безопасные, то станет менее безопасно :)
даже в windows раньше точно можно было переключать политику
Что винда, что Линукс предоставляют api для прямой записи, минуя системные кэши, а примерно любой софт, который сам беспокоится о сохранности собственных данных (те же сервера SQL), ими пользуется. Поэтому энергонезависимый кэш оказывается востребован вне зависимости от ситуации в ЦОДах и кэширования ОС.
Питание любого сервера и так обеспечивается, а обслуживать отдельные батарейки "такое себе".
Там может стоять ионистор (или несколько) - тогда ничего обслуживать не нужно. Сейчас, например, во многие видеорегистраторы для автомобилей ставят ионисторы - чтобы на жаре не взрывались литий-ионные АКБ, хватает на полминуты-минуту, чтобы корректно завершить запись файла.
У вас есть опыт долговременного использования ионисторов ? Там не всё так благополучно, как кажется. Менять их тоже может понадобится. Ну т.е. это всё совершенно невечное.
Сейчас то вам это в сервере зачем ? Зарезервировано же обычно питание даже на уровне отдельных дублирующих бп.
У вас есть опыт долговременного использования ионисторов ?
Видеорегистратор в авто 5 лет уже пашет. Пока жив и признаков сбоев не подает.
В RAID контроллерах уже лет 15 вместо BBU ставят FBWC (Flash-Backed Write Cache), там как раз ионистор в сочетании с NAND flash. Заряда ионистора с запасом хватает чтобы скинуть данные кэша на флеш память, и это намного надежнее, потому что ионистор в сравнении с LiPo аккумом практически вечный.
Регистратор 70mai с супер конденсатором ( так заявлял производитель, что по факту внутри я не знаю) работает с 2017 года, пока вроде не заметно деградации по питанию
Батарейка только кэш запитывала, чтобы сбросить на диски, когда питание сервера снова появится. Чтобы весь массив дисков крутить, она слишком маленькая была.
Ну, по крайней мере у тех контроллеров, с которыми я дело имел.
Там есть два варианта - более старый, когда батарейка кэш подпитывает (а когда заряд кончился - то ой), и более новый, когда суперконденсатор нужен затем,чтобы кэш сбросить на ssd - после чего уже "условно сколько угодно" можно ждать, пока восстановится питание.
И да, в отличии от ИБП - это сработает независимо от ОС и даже от значительной части остального железа. Так что для любителей бюджетных решений с допустимыми рисками - ИБП "на всё", для тех, кому не охота рисковать - и ИБП, и контроллер с внутренним сохранением кэша.
Серьёзные NVMe SSD энтерпрайз класса на борту имеют конденсаторы предназначенные ровно для этого же - сбросить при потере питания данные из набортного RAM кэша на флеш. Если это накопитель в формфакторе обычной PCI-E карты, то там прям внушительный такой набор электролитов стоит. В M2 формфакторе конечно поскромнее но тоже есть.
Всё поменялось.
Вы говорите, скорее всего, о write-back cache.
Корпоративные SSD-диски, которые мы, в частности, используем, давно встраивают power loss protection. Поэтому сам по себе вопрос отпал.
Наличие батареи конденсаторов для сброса кеша у корпоративного диска никак его не защитит от того, что кеш аппаратного рейда уйдёт в небытие при неожиданной потере питания, если конечно включен write-back на этом самом рейде (благо многие рейды на попытку его включить без BBU либо красно-красно ругаются и предупреждают, либо просто шлют лесом и не включают).
Вообще рано хоронить HDD-диски, Western Digital разрабатывает HBD и Dual Pivot, что позволит приблизиться к скоростным характеристикам SSD. На сколько я знаю, диск в целом надежнее.
Не позволит ни то, ни то. Вернее, может сократить отрыв в сценариях линейного чтения, но в случайном ощутимо ничего не поменяет. А основные преимущества SSD - именно в скорости случайного доступа.
Почему не поменяет? Пара независимых головок явно быстрее одной, а восемь - быстрее двух. С оперативкой многоканал почему-то работает же.
восемь - быстрее двух.
Потому что если вы с HDD снимете не 200 IOPS, а 800, это никак не поменяет того, что даже у SATA SSD все равно останется 80К, что на пару порядков больше. И не забываем, что скорости SSD тоже на месте не стоят.
Идея о нескольких блоках головок не нова, ей лет сорок уже. Насколько я знаю, регулярно пытаются сотворить что-то такое, но в серию ни разу не пошло.
Статистика по простому бытовому использованию, сколько умерло носителей за ~20+ лет пользования ПК:
0 HDD - примерно 7 было.
1 SSD - было 4 диска.
Плюс HDD еще в том, что он не умирает мгновенно, вполне вероятно что еще успеете сохранить нужные для себя данные перед смертью диска.
У вас просто слишком мало статистики.
И HDD и SSD иногда мрут мгновенно.
У меня статистика ровно обратная. Из десятка примерно HDD в личном пользовании сдохли своей смертью 6. Из 5 SSD - ни один, замена только из-за морального устаревания (120 гигабайт нынче ни о чём)
С SSD иногда бывает такая раскоряка, что умирают несколько сразу. У меня такое было давно с нынче почившими OCZ - померли сразу два в зеркале RAID.
Может оно сейчас и получше, но недавние ошибки в прошивках вроде бы HP, когда они дозли просто через Х часов аптайма уверенности не добавляют... софт старых HDD всё же сильно проще.
В RAID-ах не только SSD массово мрут.
померли сразу два в зеркале RAID.
(Зловещим голосом:) Осталось семь дней тысяч часов...
А сдохли, случайно, не одно-двухтерабайтные Сигейты?
Из тех, кого я могу припомнить сдохли:
1 Quantum Fireball 6.5 Гб
2 20-гиговых сигейта
1 40-гиговый сигейт
2 250-гиговых сигейта (не с концами, но покрылись бедами прилично)
1 ноутбучный WD Blue
Это личные. По работе я HDD пачками списывал (и разбирал на магнитики), но к моменту массового пришествия SSD я с пользовательским железом уже перестал работать, так что сравнить не могу.
В организации, где много десктопных компов, и не очень много серверов статистика такая, что потребительские hdd мрут, но не очень часто, потребительские ssd мрут заметно чаще, целый мешок (полу-)трупов уже от разных производителей. Серверные hdd мрут редко, за 20 лет всего несколько штук, серверных ssd за 10 лет пока не умерло ни одного из где-то полусотни intel и kioxia.
Backblaze по поводу надёжности с вами не очень согласится, думаю.
Да и я сам не так давно присматривал за фермой с около 35 тысяч дисков (150ПБайт или около того) - они, конечно, дохли, но совсем не так часто. Раз в неделю меняли несколько штук, вроде бы. И те часто по SMART, а не фактической смерти.
Внутри идут вращение шпинделя, позиционирование головки, трение. Из-за этого количество операций ввода-вывода IOPS физически ограничено.
Я все еще не могу убить 15-ти летний HDD торентокачалкой...
В то время как у меня уже два SSD подохло.
+1, включил быстренько мониторинг обновлений, который раз в пару минут для этой цели делал apt update(сей момент был упущен по принципу "ну не будет же он реально на конфиге по умолчанию каждый запуск это делать"). Потребительского TLC диска не стало через год по самодиагностике (остаточный ресурс 10%) и это с учетом того, что занятое место на диске не превышало 20% от его объёма. Блины же живут и есть не просят, до сих пор жив рейд-5 на Samsung F1 хардах.
У меня пара десятков Hitachi 3Тб уже трудится больше десяти лет 24х7, часов наработки на них 100 тысяч (11.3 года нон-стоп). И хоть бы один, гад, сдох :)
SMART
=== START OF INFORMATION SECTION ===
Model Family: Hitachi Ultrastar 7K3000
Device Model: Hitachi HUA723030ALA640
Serial Number: MK0371YVH9Y0RA
LU WWN Device Id: 5 000cca 234d29bcb
Firmware Version: MKAOAA10
User Capacity: 3,000,592,982,016 bytes [3.00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 2.6, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Tue Mar 31 19:48:28 2026 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 100 100 016 Pre-fail Always - 0
2 Throughput_Performance 0x0005 136 136 054 Pre-fail Offline - 83
3 Spin_Up_Time 0x0007 146 146 024 Pre-fail Always - 525 (Average 534)
4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 233
5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0
7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0
8 Seek_Time_Performance 0x0005 123 123 020 Pre-fail Offline - 31
9 Power_On_Hours 0x0012 086 086 000 Old_age Always - 99512
10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 178
192 Power-Off_Retract_Count 0x0032 098 098 000 Old_age Always - 2758
193 Load_Cycle_Count 0x0012 098 098 000 Old_age Always - 2758
194 Temperature_Celsius 0x0002 120 120 000 Old_age Always - 50 (Min/Max 8/71)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 1
Недавно поменял часть их только потому, что размер уж очень маленький...
HDD выдаёт около 150–200 IOPS. Задержка — миллисекунды.
SSD (SATA/SAS) — десятки тысяч IOPS.
SSD NVMe — сотни тысяч IOPS.
Разница — не в разы, а на порядки.
Как с жптишкой пообщался
Вы выдаете желаемое за действительность
Я бы только не торопился совсем уж хоронить HDD. Для архивов, бэкапов и всякого редкого чтения они ещё долго проживут, просто как рабочая основа под живую многопользовательскую нагрузку это уже сильно компромиссная штука
Нам проще и надёжнее обслуживать парк SSD (нет движущихся частей, ниже риск внезапного отказа)
Вы хороший человек, но немного наивный (C)
С внезапными отказами у SSD всё "хорошо"
Зачастую мрут быстро.
И "надежно" захватывают с собой информацию.
SSD конечно должен перейти, в случае отказа, в режим только чтение... Но так происходит далеко не всегда.
Главная проблема HDD в том, что о потере данных узнаешь только при обращении к ним. Проблемы с механикой компенсирует RAID. По поводу кэширования. Увы, но ресурс SSD тает быстро. Из-за этого, в свое время, перестали выпускать т.н. "гибридные" диски. Вообще можно было бы рассмотреть вариант с кэшированием в оперативную память с дальнейшим разделением. Мелкие файлы копятся и пачкой отправляются в SSD, крупные - сразу пишутся на жесткий диск.
У нас тоже есть тариф с HDD-хранилищем, но он довольно давно тариф с HDD-содержащим хранилищем, потому что уже пять-шесть лет (в зависимости от страны) мы закупаем SSD вместо HDD. Совсем скоро последние хрустящие диски уйдут из эксплуатации, и это будет тариф типа SSD с ограничением по скорости для совместимости с легаси-ценами.
То есть, в описании тарифа будет обещано HDD , а по факту это будут SSD ?
Для бэкапов и холодных архивов механика все еще топ. Списывать hdd в утиль пока рано, магнитные ленты это вообще отдельный мир для параноиков с петабайтами логов
У меня есть сигейт 120гб, который работает уже не помню сколько лет, вот же делали вещи :)
Почему мы полностью отказались от HDD