Технологии хранения данных — отдельная тема. Не так давно мы косвенно затрагивали ее в нашем материале об управления дисковым пространством сервера.
Сегодня мы поговорим о том, как команда поискового сервиса Algolia пыталась решить внезапно возникшую проблему с SSD-дисками.
/ фото Aaron und Ruth Meder CC
Инженеры Algolia, работающие над технологиями поиска, столкнулись с проблемой индексации поискового API. В ходе данного инцидента запросы к новому API были корректно перенаправлены на другие машины кластера, но ясности по поводу произошедшего не было.
Индексирование контролировалось процессом supervise, но проблема была не в его зацикливании. Файловая система оказалась доступной только для чтения. Самое интересное заключается в том, что подобный инцидент воспроизвел себя и на других машинах ровно через сутки. Таким образом, под прицел аналитиков попало ПО, которое участвует в работе стека системы хранения и его недавние изменения.
Суть проблемы и возможные решения могли быть самыми разными, но команда Algolia остановилась на следующих версиях:
Анализ очередной машины показал отсутствие частей файлов. дата изменения файлов и размер остались прежними, просто некоторые их участки были заполнены нулями. Маленькие файлы оказались полностью стертыми.
Системные области памяти были недоступны, и инженеры взяли в работу версию с багом ext4. Журнал изменений ядра показал наличие огромного числа багов, которые могли негативно сказаться на работе серверов. Вероятность того, что баг закрался в ext4, не была исключена полностью, но была практически нулевой. Далее была проверена версия с mdadm. Просмотр журнала изменений убедил инженеров в том, что корень проблемы определенно не здесь.
Машины продолжали «умирать» все чаще и чаще, а Algolia продолжала совершенствовать процедуру восстановления пока не выяснилось, что единственным отличием были SSD, но все они были от одного производителя. Перевод всех машин на идентичное ПО привел к привычному повреждению файлов, но теперь можно было с уверенностью сказать, что проблема связана с дисками.
В ходе аналитических работ инженеры выяснили, что всегда терялись данные объемом 512 байт (что равняется одному блоку диска). Что может обнулить блок? TRIM. Чтобы проверить теорию, TRIM был отключен на всех серверах. Именно этот ход и привел к решению проблемы, но только на некоторое время. Спустя месяц после определения проблемы один сервер перезапустился и загрузился с поврежденными данными.
Копаясь в исходном коде ядра, в поисках кода хоть как-то связанного с TRIM, инженеры наткнулись на чёрный список TRIM. Этот черный список настраивает специфическое поведение для определенных типов SSD-приводов, идентифицируя диск по названию с помощью регулярных выражений.
Система принуждала TRIM стирать пустые блоки, команда неправильно интерпретировалась диском, в результате контроллер затирал те блоки, которые не должен был. Вот почему в некоторых файлах появлялись блоки с 512 байтами нулей, а файлы меньше этого размера стирались полностью. Проблема возникла не из-за команды Queued TRIM (на дисках компании использовались обычные команды TRIM).
В итоге поставщик дисков был проинформирован и сообщил сведения о проблемах представителям компании Samsung. Algolia заменили диски другими и не рекомендуют использовать любые SSD, которые определяются ядром Linux как плохие.
Неработающие SSD:
Работающие SSD:
Финал истории: «Твердотельные накопители от Samsung оправданы. Проблема оказалась в ядре Linux»
P.S. Мы делимся не только собственным опытом работы над сервисом по предоставлению виртуальной инфраструктуры 1cloud, но и опытом западных экспертов в нашем блоге на Хабре. Не забывайте подписываться на обновления, друзья!
Сегодня мы поговорим о том, как команда поискового сервиса Algolia пыталась решить внезапно возникшую проблему с SSD-дисками.
/ фото Aaron und Ruth Meder CC
Инженеры 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, но и опытом западных экспертов в нашем блоге на Хабре. Не забывайте подписываться на обновления, друзья!
