Примечание переводчика: В нашем блоге мы много пишем о построении облачного сервиса 1cloud (например, о реализации функции управления дисковым пространством сервера на лету), но немало интересного можно почерпнуть и из опыта по работе с инфраструктурой других компаний. Мы уже рассказывали о дата-центре фотосервиса imgix, а сегодня представляем вашему вниманию адаптированный перевод заметки о том, как команда поискового сервиса Algolia пыталась решить внезапно возникшую проблему с SSD-дисками.
Все выглядело как банальный сбой, возникший посреди ночи. Один из серверов нашего поискового API прекратил индексирование по неизвестной причине. Поскольку мы в Algolia работаем над обеспечением высокой доступности и повышением отказоустойчивости, ничего плохого не случалось. Запросы к новому API были корректно перенаправлены на оставшиеся функционирующие машины кластера, а единственным, на ком хоть как-то сказался сбой, был разбуженный среди ночи инженер. Нужно было выяснить, что происходит.
Daemon NGINX, обеспечивающий передачу данных API по HTTP(S), был готов к работе с поисковыми запросами, но тут прервался процесс индексирования. Поскольку индексирование контролируется процессом supervise, то простое зацикливание было бы понятным, но полный выход из строя – это не нормально. Как позже выяснилось, файловая система оказалась доступной только для чтения. Хорошо, предположим, что всему виной космическое излучение; проблемы с файловой системой были исправлены, файлы восстановлены с другого рабочего сервера – все снова выглядело нормальным.
На следующий день файловая система уже другого сервера оказалось доступна только для чтения, через два часа – еще у одного, а у третьего – еще через час. Что-то было не в порядке. После того, как были восстановлены файловая система и все файлы, пришло время провести серьезный анализ, поскольку проблема не была единовременной. Мы выбрали программное обеспечение, которое участвует в работе стека системы хранения, и начали изучать недавно внесенные изменения.
Время найти причину и исправить её!
Сначала мы спросили себя, может ли проблема быть связана с работой нашего программного обеспечения? Может, мы используем небезопасные системные вызовы или обрабатываем данные небезопасным образом? Может, мы некорректно читаем и записываем файлы в память, перед их сбросом на диск?
- Файловая система: появился ли баг в файловой системе ext4? Можем ли мы случайно получить доступ к памяти, в которой хранятся таблицы размещения файлов?
- Mdraid: возможно, баг гнездится в утилите mdadm? Может, мы используем неподходящую конфигурацию?
- Драйвер: баг в драйвере?
- SSD: «умирает» SSD? Или того хуже – проблема в прошивке привода?
Мы предположили, в чем может заключаться проблема, и начали предлагать её возможные решения, которые, в соответствии со списком выше, ранжировались от суперпростых до суперсложных.
Пробежавшись по процедурам хранения нашего программного пакета, мы установили прерывания – теперь, если проблема возникнет снова, мы сможем точнее определить неисправные части. Но глядя на сигналы, которые посылал нам обработчик, мы пришли к выводу, что проблема не связана с нашим способом управления данными. Жаль.
Через час был поврежден еще один сервер. В этот раз мы изъяли его из кластера и начали исследовать бит за битом. Перед исправлением файловой системы мы увидели, что некоторые части наших файлов отсутствовали (были обнулены) – дата изменения файлов и размер остались прежними, просто некоторые их участки были заполнены нулями.
Маленькие файлы оказались полностью стертыми. Это было странно и заставило нас думать, что, возможно, наше приложение может получать доступ к определенным служебным частям памяти операционной или файловой систем, потому что это – единственный способ модифицировать файл без ведома файловой системы. Из-за того, что наше ПО написано на C++, начали рождаться безумные идеи и теории о том, что на самом деле происходит. Но мы зашли в тупик – системные области памяти были недоступны.
Может, проблема связана с ext4? Просмотр журнала изменений ядра в поисках проблемы, связанной с ext4 – это душераздирающее занятие. Практически в каждой версии мы находили исправленный баг, который (в теории) мог негативно сказаться на работе серверов. Должен сказать, что до чтения логов я спал спокойнее.
Мы распределили ядра версий 3.2, 3.10, 3.13 и 3.16 между наиболее часто повреждающимися машинами и ждали, пока какая-нибудь из заложенных «мин» взорвется. Взорвались все. Очередной тупик. Может, проблема заключена в ext4, просто с ней еще никто не сталкивался? Шанс, что мы оказались такими «везунчиками» был довольно мал, да и нам бы не хотелось останавливаться на этой версии. Вероятность того, что баг закрался в ext4, не была исключена полностью, но была практически нулевой.
Что, если проблема связана с mdadm? Просмотр журнала изменений вселил в нас уверенность, что корень проблемы определенно не здесь.
Уровень отчаяния достигал критической отметки, а мы все не могли остановить продолжающиеся ночные страничные нарушения. Мы потратили большую часть двух недель, просто выискивая повреждённые машины и восстанавливая их настолько быстро, насколько могли. Мы даже внедрили в наше ПО функцию, которая искала пустые блоки в индексных файлах, даже когда они не использовались, и предупреждала о них заранее.
Ни дня без повреждений
Машины продолжали «умирать» все чаще и чаще, но мы сумели автоматизировать процедуру восстановления на достаточно комфортном для нас уровне. При каждом падении мы пытались выявить закономерности в надежде найти наименьший общий знаменатель. У них у всех были одни и те же характеристики. Но с каждым разом кое-что становилось все яснее – проблема возникала только на части наших серверов.
Программный пакет был одинаковым на всех машинах, но их аппаратное обеспечение немного отличалось: отличались SSD, но все они были от одного производителя. Это очень нас встревожило, поэтому мы связались с поставщиком серверного оборудования и спросили, не сталкивались ли они с подобными проблемами раньше? Довольно сложно убедить человека из технической поддержки в существовании проблемы, которая периодически возникает на прошивках, обновленных до последней версии, но которую нельзя воссоздать самостоятельно. В этом мы не преуспели, однако это открытие стало нашей первой маленькой победой.
Зная, что корень проблемы лежит где-то среди комбинаций программного обеспечения с приводами, мы установили на серверы с разными дисками идентичные программные пакеты. И? Ничего, файлы все равно были повреждены. Теперь можно было с уверенностью сказать, что проблема связана с дисками, а не с программным обеспечением. Но было неясно, что меняет содержимое блока без ведома системы. Будет еще много подпорченных битов…
Дни превратились в рутину – с утра длительный душ, затем завтрак, восстановление поврежденных серверов, потом обед, снова восстановление поврежденных серверов, ужин и опять восстановление поврежденных серверов. Все это продолжалось до определенного дня, пока я, принимая утренний душ, не задался вопросом: «А насколько длинными являются последовательности испорченных битов?» Как оказалось, всегда терялись данные объемом 512 байт, что равняется одному блоку диска. Стоп, данные не просто терялись, а затирались нулями. Баг в аппаратном обеспечении? Или блок обнулился? Что может обнулить блок? TRIM! TRIM говорит SSD-приводу, какие пустые блоки следует обнулить. Но эти блоки не были пустыми, а другие типы SSD не страдали этой проблемой.
Чтобы проверить теорию, мы отключили TRIM на всех серверах. Это должно объяснить всё!
На следующий день не было повреждено ни одного сервера, два дня тишины, неделя… Кошмар закончился! По крайней мере мы так думали… Спустя месяц после определения проблемы один сервер перезапустился и загрузился с поврежденными данными. Повреждены были только маленькие файлы и сертификаты. Даже неправильное отключение сервера не может вызвать подобное.
Копаясь в исходном коде ядра, в поисках кода хоть как-то связанного с TRIM, мы наткнулись на чёрный список TRIM. Этот черный список настраивает специфическое поведение для определенных типов SSD-приводов, идентифицируя диск по названию с помощью регулярных выражений. Наши работающие SSD полностью удовлетворяли условиям, необходимым для нормальной работы TRIM, но для некоторых дисков нашего поставщика функционал был ограничен. Наши диски, которых коснулась проблема, не попадали ни в одну из категорий, поэтому им по умолчанию был разрешена вся функциональность TRIM.
Полная картина
В этот момент мы полностью осознали что происходит. Система принуждала TRIM стирать пустые блоки, команда неправильно интерпретировалась диском, в результате контроллер затирал те блоки, которые не должен был. Вот почему в некоторых файлах появлялись блоки с 512 байтами нулей, а файлы меньше этого размера стирались полностью. Нам повезло, что неправильно функционирующие команды TRIM попали в суперблок файловой системы, тем самым повредив его. Когда мы отключили TRIM, то большие файлы перестали повреждаться, но маленькие, которые однажды были выгружены в память и с того момента более не изменялись, имели две копии: верную, хранившуюся в памяти, и поврежденную, лежащую на диске. Проверка файлов ничего не находила, так как никогда не загружала копии этих файлов с диска, а просто читала их из памяти. Чтобы восстановить целостность данных была проведена тотальная перезагрузка серверов, и после долгих недель охота на призрака подошла к концу.
Мы проинформировали нашего поставщика оборудования о проблемных SSD, а они сообщили производителю. Мы заменили диски другими и не рекомендуем использовать любые SSD, которые определяются ядром Linux как плохие. Будьте осторожны, даже при выключенном TRIM в Ubuntu 14.04 планировщик cron раз в неделю запускает FSTRIM на всех разделах – секундное зависание хранилища будет вашей наименьшей проблемой.
Резюме
Неработающие 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
Оригинальный материал был опубликован 15 июня 2015 года
Дополнение от 16 июня: Часто во время обсуждений возникали предположения, что проблема возникла из-за недавнего новшества – команды Queued TRIM. Это не так. На наших дисках используются обычные команды TRIM, и проблемы, с которыми мы столкнулись, никак не относятся к последним изменениям в ядре Linux, связанным с отключением этих функций.
Дополнение от 17 июня: С нами связались представители компании Samsung, и мы предоставили им все системные спецификации и всю информацию о проблеме, которой располагали. Мы продолжим сотрудничать с Samsung и попытаемся разрешить эту проблему.
Дополнение от 18 июня: Мы только что провели телефонную конференцию с европейским филиалом Samsung и штабом Samsung в Корее. Их инженеры собираются нанести визит в один из наших дата-центров и совместно с нашим поставщиком серверного оборудования провести проверку упомянутых SSD на нашем программном и аппаратном обеспечении.
Дополнение от 19 июня: 22 июня, в понедельник, команда инженеров Samsung собирается проверить один из наших серверов в Сингапуре, и если они ничего не найдут на месте, то сервер отправится в штаб-квартиру Samsung в Корее для дальнейшего исследования.
ссылка на оригинал статьи http://habrahabr.ru/post/262257/
Добавить комментарий