IaaS, VPS, VDS, Частное и публичное облако, SSL
282,92
рейтинг
10 июля 2015 в 11:17

Разное → Твердотельные накопители дали слабину перевод



/ фото Aaron und Ruth Meder CC

Совсем недавно мы рассказывали о различных аспектах разработки облачного сервиса 1cloud (например, о реализации функции управления дисковым пространством сервера на лету), но немало интересного можно почерпнуть и из опыта зарубежных экспертов. Сегодня мы поговорим о том, как команда поискового сервиса Algolia пыталась решить внезапно возникшую проблему с SSD-дисками.

Инженеры Algolia, работающие над технологиями поиска, столкнулись с проблемой индексации поискового API. В ходе данного инцидента запросы к новому API были корректно перенаправлены на другие машины кластера, но ясности по поводу произошедшего не было.

Индексирование контролировалось процессом supervise, но проблема была не в его зацикливании. Файловая система оказалась доступной только для чтения. Самое интересное заключается в том, что подобный инцидент воспроизвел себя и на других машинах ровно через сутки. Таким образом, под прицел аналитиков попало ПО, которое участвует в работе стека системы хранения и его недавние изменения.

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

  • Баг в файловой системе ext4
  • Баг в утилите mdadm
  • Баг в драйвере
  • «Умирают» SSD

Анализ очередной машины показал отсутствие частей файлов. дата изменения файлов и размер остались прежними, просто некоторые их участки были заполнены нулями. Маленькие файлы оказались полностью стертыми.

Системные области памяти были недоступны, и инженеры взяли в работу версию с багом ext4. Журнал изменений ядра показал наличие огромного числа багов, которые могли негативно сказаться на работе серверов. Вероятность того, что баг закрался в ext4, не была исключена полностью, но была практически нулевой. Далее была проверена версия с mdadm. Просмотр журнала изменений убедил инженеров в том, что корень проблемы определенно не здесь.

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

В ходе аналитических работ инженеры выяснили, что всегда терялись данные объемом 512 байт (что равняется одному блоку диска). Что может обнулить блок? TRIM. Чтобы проверить теорию, TRIM был отключен на всех серверах. Именно этот ход и привел к решению проблемы, но только на некоторое время. Спустя месяц после определения проблемы один сервер перезапустился и загрузился с поврежденными данными.

Копаясь в исходном коде ядра, в поисках кода хоть как-то связанного с TRIM, инженеры наткнулись на чёрный список TRIM. Этот черный список настраивает специфическое поведение для определенных типов SSD-приводов, идентифицируя диск по названию с помощью регулярных выражений.

Система принуждала TRIM стирать пустые блоки, команда неправильно интерпретировалась диском, в результате контроллер затирал те блоки, которые не должен был. Вот почему в некоторых файлах появлялись блоки с 512 байтами нулей, а файлы меньше этого размера стирались полностью. Проблема возникла не из-за команды Queued TRIM (на дисках компании использовались обычные команды TRIM).

В итоге поставщик дисков был проинформирован и сообщил сведения о проблемах представителям компании Samsung. Algolia заменили диски другими и не рекомендуют использовать любые SSD, которые определяются ядром Linux как плохие.

Неработающие SSD:

  • SAMSUNG MZ7WD480HCGM-00003
  • SAMSUNG MZ7GE480HMHP-00003
  • SAMSUNG MZ7GE240HMGR-00003
  • Samsung SSD 840 PRO Series недавно появился в черном списке 800 серии
  • Samsung SSD 850 PRO 512GB попал как отдельно, под названием 850 Pro, так и в список 800 серии

Работающие SSD:

  • Intel S3500
  • Intel S3700
  • Intel S3710

Финал истории: «Твердотельные накопители от Samsung оправданы. Проблема оказалась в ядре Linux»

P.S. Мы делимся не только собственным опытом работы над сервисом по предоставлению виртуальной инфраструктуры 1cloud, но и опытом западных экспертов в нашем блоге на Хабре. Не забывайте подписываться на обновления, друзья!
Автор: @1cloud Adam Surak
1cloud.ru
рейтинг 282,92
IaaS, VPS, VDS, Частное и публичное облако, SSL

Комментарии (50)

  • +13
    Всегда поражаюсь подобным рассказам — читается прямо как детектив)
    Рад, что всё закончилось более-менее хорошо.
    А как так контроллер неправильно интерпретирует команду, что затирает не те блоки? И разве у производителей нет каких-либо тестов для проверки этого?
    • 0
      Есть, конечно. Но там внутри кода — почти как в ext4, чтение логов к которой привело автора в уныние, а ошибки в них правят куда меньше людей…
    • 0
      Детектив — не то слово, но всё-таки историю про радиоактивную кэш-память в Sun SPARC'е не переплюнуть )
      • +17
        Тут не все эту историю знают, будет здорово если вы поделитесь)
        • +29
          Блин, к сожалению никак не получаетя нагуглить этот триллер (

          Суть была в том, что Sun сделала сервера на основе процессора UltraSPARC II. Там была внешняя кэш-память. Затем в течение целого года к инженерам поступали отчёты о необъяснимых падениях софта у клиентов. Причем анализируя дампы инженеры видели иногда полный бред: типа записи в память значения, а затем падение в том месте, где условное ветвление по записанному значению пошло по противоположному условию. Они искали ошибки везде где только можно, начиная от HDL АЛУ, в масках для производства чипов и так далее, но это не давало результата, пока один инженер не припер в шутку счетчик Гейгера. И тогда-то оказалось, что IBM отгружало Sun'у кэш-память, которая почему-то слегка светила альфа-частицами. ECC как водится не было, но самое главное, что потом выяснилось, что в IBM знали об этой проблеме, но не сказали Sun.
          • 0
            > кэш-память, которая почему-то слегка светила альфа-частицами

            А не выяснилось, почему так вообще было? Это же пипец какой-то просто.
            • 0
              К сожалению, нет. Я читал историю от лица инженера Sun, думаю, что IBM с ними не поделилась из-за чего такое произошло.
            • 0
              вероятно, естественная радиоактивность материала.
              маловероятно обнаружить радиометром на базе счетчика Гейгера без целенаправленных исследований.
        • 0
          Начинать копать можно отсюда. Но интернет не был так развит ещё и материалов не много.
          • +2
            Эту статью я нашел, но она не повествует о том, как инженеры радели над этой проблемой. Просто упоминает этот факт и всё. А тот рассказ, который я читал, реально захватывает дух, как данный пост.
  • +17
    Прямо призрак Барракуды какой-то.
  • 0
    Хм а какой на самом деле размер сектора у SSD?
    512 байт или 4Кб как у HDD последних версий. Если второе то есть вероятность что TRIM трём весь сектор на 4Кб, при этом если по каким то причинам кластер FS не попадает на физический кластер то может затираться кусок следующего кластера. Но верить в такое не очень хочется.
    • +3
      Разные SSD прикидываются дисками 512N (512 байт логический/физический сектор), 512E (4096 байт физический сектор, 512 байт логический) и 4KN (4096 байт логический/физический сектор), но разумеется «физический сектор» тут буквально понимать нельзя. Страницы больше, а блоки (стирание возможно с гранулярностью блока) еще больше. Например, для Samsung 840 Pro — 8КиБ страницы и 1МиБ блоки.
      Естественно, хост про это не ничего не знает, его задача — передать от одного слоя абстракции (ФС) к другому слою (псевдо-HDD с 512 или 4096 секторами) информацию о секторах с невалидными (в результате удаления файлов) данными. Дальше уже контроллер SSD занимается сборкой мусора — из кусочков с невалидными данными собирает большой блок и стирает его.
      • 0
        Никогда не понимал, что им мешает сообщать реальные размеры секторов. Ну скажи ты операционной системе честно, что ты 4096/1M.
        • +4
          Обратная совместимость. Остаётся только научить ОС работать с этим знанием, про мегабайтные сектора ни одна ОС не знает. Только-только всё улеглось с 4К-секторами, но 4К — это не только современная ОС + загрузка через EFI, а ещё и куча всяких нюансов с софтом, использующим блочную репликацию. В Linux помимо физических/логических секторов среди т.н. IO hints для блочных устройств есть ещё необязательные optimal_io_size и minimum_io_size. Какие-то СХД и SSD их сообщают, какие-то нет.
          P.S. В некоторых SSD, например, в последних Toshiba под SAS3 есть возможность менять размер «физического» сектора при форматировании как раз для ликвидации тех самых проблем с репликацией. В Fusion IO ещё такое видел. Но, конечно, только те же 512 и 4096 вместе с их «толстыми» разновидностями.
          • 0
            Тут есть интересная тонкость: 4К удалось «осилить» относительно малой кровью потому, что 512К сектора реально никому (кроме загрузчика) никогда интересны не были. Вся «серъёзная» работа в современных ОС идёт со страницами, а их размер (на x86) — как раз 4КиБ. Так что переход на 4КиБ оказался достаточно безболезненным.

            Работа же с блоками большего размера требует либо переписывания всего на свете, либо создания специального слоя трансляции. Но кто будет делать подобный слой трансляции бесплатно если его можно выгодно продать в составе SSD?
            • 0
              Перейти принудительно на huge pages как вариант на таких системах, но там еще больше проблем возникнет.
          • 0
            А не подскажите, когда и в каких ОС планируется поддержка более емких секторов? Очень интересно! Просто обратная совместимость нужна, но и современные реалии тоже нажно учитывать.
            • +2
              Ничего не могу сказать про далёкое будущее, но сейчас никакой острой проблемы, IMHO, нет. Запись на SSD блоками меньше его «блока стирания» приводит лишь к неоптимальному расходу запаса чистых блоков, т.е. потеря производительности. Упомянутые minimum_io_size и optimal_io_size — это на самом деле не какая-то внутренняя особенность Linux, а вполне себе часть стандарта SPC-3 (т.е. для SCSI устройств). В спецификациях NVMe наверняка тоже что-то на этот счёт есть. Определённое приложение или компоненты ОС вполне могут использовать эти данные для оптимизации производительности.
              Но зачем же жёстко запрещать, например, писать блоки меньше 1М — серверные SSD и так справится (есть большой кэш, много Over Provisioning, интенсивная сборка мусора), адесктопным сильно поможет TRIM, и никому не придётся переписывать тонны софта.
    • +1
      Вам уже ответили, но пропустили важный этап, без которого понять ответ нельзя. Блоки, с которыми оперирует современный NAND огромны — куда больше, чем 512 байт или 4КиБ. Там речь зачастую идёт на мегабайты. Причём этих размеров не один, а два — вы можете писать «маленькие» страницы 4-8КиБ (и чем дальше, тем больше), но только поверх «прочищенных» блоков размером от 1-2МиБ (и чем дальше, тем больше). Потому что, грубо говоря, «нуль» в транзистор с плавающим затвором записать просто, а «единицу» — сложно.

      И поверх всего этого нужно «эмулировать» обычный жёсткий диск со случайным доступом к данным. Весьма непростая задача, надо сказать…
  • +12
    Было бы отлично, если бы вы потом по результатам от Samsung сделали бы заметку. Всё же довольно солидная контора — интересно, как они подобные проблемы решают.
  • +4
    Что было после 19 июня авторы не сообщают? =(
    • +5
      Skynet перестал прятаться и восстал.
    • 0
      Месяц вместе с Samsung пытались воспроизвести проблему, но долго не получалось. Вчера сообщили, что наконец-то удалось.
      Samsung had a concrete conclusion that the issue is not related to Samsung SSD or Algolia software but is related to the Linux kernel. Samsung has developed a kernel patch to resolve this issue and the official statement with details will be released tomorrow, July 18 on Linux community with the Linux patch guide.

      Коротко: виновато ядро Linux. Ребята из Samsung подготовили патч, сегодня его должны представить.

      1cloud, было бы неплохо обновить пост новой информацией.
      • 0
        Коротко: виновато ядро Linux.
        Можно подробнее? Вот есть определенный SATA-протокол, ядро его как-то некорректно использовало, причем так, что это проявлялось только на некоторых накопителях?
        Патч поможет другим накопителям из черного списка?
        • +1
          Скорее всего дело в каких-то таймингах. Я буквально на днях за'backup'ил машину, а при проверке sha512sum (ну паранойя у меня) у пары файлов сумма не совпала. И то же самое — мелкие файлы, в backup'е превращены в файлы такой же длины состоящие исключительно из нулей. Воспроизвести не удалось, но статью я сразу вспомнил.

          На Samsung грешить не получится так как в машинке два накопителя — один Intel'овский SSD на 180GB (система, часто используемые файлы), другой — Seagate'овский HDD на 1TB (вот как раз на нём беда и наблюдалась).

          P.S. При этом история с одним из битых файлов выла такая — в backup попали нули, а видел я нормальный файл. С другим файлом — наоборот. Такое ощущение что иногда ядро забывает читать данные…
  • +2
    Спасибо за дополнения — увидел заметку в рассылке ceph-users, но там не было на тот момент изменений о настолько плотной работе с вендором. Держите в курсе, пожалуйста, крайне любопытно, чем всё закончится.
    Кстати, в самом списке рассылки тоже много интересного попадается об особенностях SSD, благо сейчас появляется всё больше кластеров SSD-only, да и в качестве кэша\журнала SSD must have.
  • +2
    Как-то опечалил захардкоженный блек-лист (причем, немаленький!) с моделями прямо в ядре. Новые диски выходят раньше заплаток, да и обновление ядра — вообще целая «история» для многих. Не говоря уже про то, что патчи из ванильного ядра попадают далеко не сразу в дистрибутивы.
  • +1
    >>Зная, что корень проблемы лежит где-то среди комбинаций программного обеспечения с приводами, мы установили на серверы с разными дисками идентичные программные пакеты. И? Ничего, файлы все равно были повреждены. Теперь можно было с уверенностью сказать, что проблема связана с дисками, а не с программным обеспечением.

    А объясните логику этого заключения? Диски разные, ПО одинаковое, проблема наблюдается на всех дисках — значит, виноваты диски?
    • 0
      Интересно, что среди всех обсуждающих этот странный текст заметили это только вы один. :-/
      • +1
        Не он один, мне тоже глаз резануло, но потом я решил, что это просто неудачная формулировка, автор чересчур положился на контекст. Непосредственно перед этим он говорит, что заподозрили диски, но разные версии софта не давали в этом убедиться. Чтобы проверить гипотезу, синхронизировали версии. Выяснилось, что да, [на тех же «подозрительных» дисках] файлы по-прежнему повреждались.

        В отличие от перевода, в оригинале это звучало с несколько большей привязкой к контексту: «Nothing, the corruption appeared again.» Не просто «файлы были повреждены», а "the corrpution" — определённый артикль указывает на то, что это не абы какое повреждение каких-то файлов где-то там, а что речь идёт о конкретном (пока ещё гипотетическом) баге с конкретными моделями дисков, который как раз и пытаются выявить этим тестом.
  • 0
    Ещё раз убедился в правильности принципа «В рейд — диски от разных производителей. Причём всегда, когда это хоть как-то возможно.» С тем, что какойнить seastern samshiba dbla4000 будет на 5% медленнее чем higital vobla 99, можно будет смириться, нервы дороже.
    • 0
      И чем бы этот «принцип» помог в описанной ситуации?
      • +4
        Тем, что mdadm выплюнул бы на всех серверах самсунги(или была бы найдена лажа только на них), что позволило бы локализовать проблему быстрее. А уже дальше спокойно разбираться в темпе вальса (заменив самсунг на что-то другое), «а фигли пять серверов выплюнули диски от одной конторы», а то можно получить вышеупомянутый «призрак барракуды» сразу на всех серверах с промежутком в десять минут(и куковать дальше, когда станет ясно, что за 1 минуту их всех не поднять). В результате к причине (глючный TRIM) пришли бы с меньшим бы геморроем на голову.
        • 0
          mdadm выплюнул бы на всех серверах самсунги(или была бы найдена лажа только на них


          На основании чего это произошло бы, и почему, по-вашему, mdadm не «выплюнул» эти диски у авторов статьи?
          • +1
            На основании того, что если есть рейд, то очень полезно переодически мучать его командой verify. Которая в случае расхождения (для R5/6 и их производных) спокойно заявит об этом, в случае зеркала — увы нет. У авторов могло быть оно самое. У авторов могло не выплюнуть из-за отсутствия проверок дисков. И да, в скобках указано, что было бы в варианте без выплёвывания, раз уж авторы полезли под капот софтового рейда смотреть глазами
            • 0
              Заявит, если повезет — если записи в тот же набор блоков не было, и четность не пересчиталась заново. А если повезет — много ли толку? Вот у вас блок четности не соответствует данным на N дисках, здравствуй, silent data corruption, мы тебя нашли. Но на каком диске битый блок? Или это четность битая? И в результате — битый том целиком, а не сбойный конкретный диск.

              Итого, если вы наберете рейды из разных дисков, получите сразу два эффекта:

              1. У вас возникнут проблемы на большем количестве томов (два условных самсунга в паре, два интела в паре — один проблемный том и один целый, а две пары самсунг+интел — сразу два проблемных тома)
              2. Под подозрение попадут все модели задействованных дисков.

              Оно вам надо?

              И, наоборот, если все массивы из дисков одного типа — вот тогда можно куда быстрее увидеть, что все проблемы — только на таких-то моделях.
              • 0
                Если массив из дисков одной модели, то можно очень быстро увидеть, что поздно пить боржоми.
        • 0
          У вас случайно есть ссылка на статью про «призрак барракуды»?
          Заинтриговало, хочу ознакомиться.
          Но в сети не могу найти, видимо не так ищу :)

          Спасибо!
  • 0
    Вот у меня парочка Kingston SSDNow mSATA 120GB SMS200S3 в RAID1 средствами BTRFS, и вот раз в неделю при запуске fstrim улетали пачки файлов чаще всего из одной или нескольких папок, такое происходило 2 или 3 раза, потом прекратилось, уже месяца полтора всё в порядке, но улетали даже файлы в несколько мегабайт. Хорошо что делаются полные бекапы много раз каждый день и на другой диск.
    Я так понимаю, основной вывод из статьи — нужно иметь резервные копии и уметь их быстро поднимать, желательно автоматически.
  • 0
    Недавно имел проблему с Samsung SSD 840 PRO Series.
    Писал код в Visual Studio, нажал F7 (сохранить и скомпилировать).
    Винда (8.1) ушла в экран ошибки и перезагрузилась.
    После загрузки обнаружил два файла с исходным кодом (которые как раз должны были сохраниться) заполненные одинаковым байтом.
  • +1
    возможные решения, которые, в соответствии со списком выше, ранжировались от суперпростых до суперсложных.
    Интересное у них ранжирование. «Появился баг в файловой системе ext4» это значит тривиально, чуть ли каждый день случается. А на тупо помирающий SSD стали грешить в последнюю очередь.

    И жаль не написали, отправили ли патч в ядро с новой регуляркой.
  • 0
    Забыли сказать самое главное — размер проблемы. Как часто случаются сбои? 1 из 100 дисков и 1 из 10000 это немного разные вещи.
    • +1
      все диски указанных моделей подвержены
  • +7
    Кстати, не первый случай кривого трима.

    Я, помню, пару недель тупил над сырцами блочного стека линукса, пытаясь понять, почему mkfs.xfs сносит голову серверу.

    Оказалось, WRITE SAME 16, DISCARD (аналог TRIM для SAS-SSD) приводил к зависанию диска, причём в крайне неудобном для enclosure положении, снося при этом связность и с другими дисками в enclosure. Задним умом я сейчас понимаю, что можно было бы сделать sg_reset для enclosure и обойтись без перезагрузки, но всё равно было неприятненько.

    А команду (точнее, IOCTL 'BLKDISCARD') посылал mkfs.xfs.

    Вендор долго сопротивлялся и рассказывал сказки про Windows Server, в котором пони и радуга, пока я не включил отладку HBA и не прислал полный лог IO, приводящий к зависанию. После этого прислали обновлённую прошивку (и даже не извинились).
    • +1
      Жжошь.
      Поставили костыль в прошивке HBA? Кстати HBA чьи?
      • +3
        Фирмварю у ssd. А отладку включал у hba (lsi), тогда он(а) логгирует все, что посылает по scsi. Точнее, сами команды, без данных.
  • –3
    Хмм. Я был уверен, что корень зла лежит именно в mdadm. Лет пять назад похожая проблема была с нашими серверами, на которых стояли обычные HDD включеные в софтверный рейд на Ubuntu. Концы файлов также отсутствовали, последние изменения периодически не записывались. Проблема решилась покупкой и установкой hardware RAID контроллеров.

    Ребята проделали огромную и стоящую работу по нахождению проблемы. Однако причина кроется по большей мере в кустарной архитектуре: сервера скорей всего были собраны самостоятельно из разных компонентов. При покупке готовых серверов проблемы, возможно, можно было бы избежать, т.к. компании-производители подвергают свои продукты нагрузочному тестированию на отказоустойчивость. Ну и SW RAID — это несерьезно, в основном для домашнего использования.
    • +3
      Будто вы не видели списки critical firmware updates для брендовых линеек… Или сраных fakeraid'ов в брендовых серверах, которые ставят туда с тем же успехом, как и не в брендовые.
    • +2
      > SW RAID — это несерьезно, в основном для домашнего использования.
      Ага-ага. Только почему-то softraid живет и здравствует, а критические баги в железных рейдах чинят пачками каждый год.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное