В эфире продолжение нашей пятничной рубрики про сбои, отказы и прочие факапы. Если пропустили наши предыдущие рассказы, то вот ссылки: один, два, три. А сегодня мы расскажем про неприятности с RAID в одном «маленьком, но гордом» ЦОДе.
История про неконсистентность данных
История началась с того, что вышел из строя один из дисков в RAID 5. Ну вышел и вышел – обычное дело. Диск начал пересобираться, и тут отказал еще один диск. Тоже частая проблема для RAID 5. В результате отвалился целиком дисковый пул, в котором находился этот mdisk. Кто не знает, mdisk — это маленький рейд, а дисковый пул состоит из кучи mdiskов. Решили переключиться на резервный ЦОД. Всё прошло штатно: серверы запустились нормально, ошибок нет. Всё как будто бы работает. Пока данные находились в резервном ЦОДе, мы заново пересобрали сбойный mdisk в основном ЦОДе. Ошибок на нем как будто бы нет: массив светится зеленым, данные реплицируются между массивами на основной и резервной площадке.
Переключаемся обратно и понимаем, что у нас часть данных запускается нормально, а, например, серверы баз данных – с ошибками. Мы видим на них неконсистентность данных.
Проверяем на целостность и обнаруживаем кучу ошибок. Странно, ведь в РЦОДе данные были в порядке, а при обратной репликации в основной ЦОД они пришли уже сбойными. Не понятно. Сначала подумали, что проблема в массиве. Но в логах всё чисто, никаких ошибок.
Тогда стали грешить на процедуру репликации, потому что на массивах в основном и резервном ЦОДе версии прошивок отличались на 2–3 минорные версии. В описании вендора нашли, что действительно бывают ошибки репликации при разных версиях прошивок. Тогда с помощью специальной фирменной утилиты проверили консистентность репликации: все ли фреймы, вылетевшие из одного массива, доехали до другого. Всё работает без проблем, но как только переносим данные из резервного ЦОДа в основной, получаем неконсистентность — часть блоков приходят битыми.
Стали просто копировать данные по сети. Делаем дамп базы и заливаем на массив. Дамп приходит с другими хэш-суммами. Вероятно, где-то по дороге данные теряются. Попробовали отправлять через разные сети — всё то же самое. Получается, что проблема в массиве, несмотря на то, что он бодро рапортует о своей беспроблемной работе.
Решили пересобрать дисковый пул. Те данные, что работали в основном ЦОДе, перегнали обратно в резервный, освободили дисковый массив, целиком отформатировали и заново собрали весь пул. И только после этого неконсистентность данных исчезла.
Причина оказалась в одном сбойном элементе логики RAID-контроллера. Один из mdiskов, то есть RAID-группа, после пересборки работал некорректно. Массив считал его нормально функционирующим, но это было не так. Когда на этот mdisk попадали блоки, он их записывал неправильно. К примеру, файловые серверы пишут не так много, и на них неконсистентности не возникало. А в базе данных информация постоянно меняется, блоки записываются часто и в самых разных местах дискового пула. Поэтому с проблемой неконсистентности мы столкнулись именно на сервере с базами данных.
С момента выхода из строя дискового пула до запуска системы прошло около 4 часов, и всё это время у заказчика не работала одна из критичных бизнес-систем. Финансовые потери были не столь велики, в основном это был удар по репутации.
В нашей практике это был единственный подобный сбой. Хотя для RAID 5 не редкость, когда при умирании одного из дисков нагрузка на оставшиеся возрастает, и из-за этого умирает ещё один диск. Так что совет: обновляйте своевременно прошивки и не допускайте разнобоя в версиях.
Необъяснимая связь
Ещё одна удивительная история, случившаяся с нами впервые. Действующие лица: те же самые массивы и площадки, тоже есть основной и резервный ЦОДы. В РЦОДе заглючил, завис и не поднимается один из контроллеров в массиве. Переусадили – контроллер поднялся, массив заработал. Но в этот самый момент на основной площадке у нас отвалился ввод/вывод на физических Linux-серверах.
Удивительно то, что контроллер в РЦОДе и ввод/вывод в ОЦОДе абсолютно изолированы друг от друга. Единственное, что их связывает, это стоящие на периметре FC-маршрутизаторы. Они просто заворачивают FC-трафик в IP и гонят его между площадками для репликации данных между массивами дискового хранилища. То есть у контроллера и ввода/вывода абсолютно всё разное — SAN, физические площадки, физические серверы.
Оказалось, что в момент включения котроллера на резервной площадке он посчитал себя SCSI-инициатором, вместо того чтобы быть SCSI-таргетом. У нас репликация идёт с основного ЦОДа в резервный. То есть контроллер по идее должен быть SCSI-таргетом, на него должны приходить все фреймы. А он решил, что ему больше подходит активная жизненная позиция, и стал сам пытаться отправлять какие-то данные.
В этот момент драйвер мультипасинга на Linux-серверах с Red Hat 7 отработал некорректно. Он воспринял эти команды дословно. Несмотря на то, что сам является инициатором, он увидел еще одного инициатора и решил на всякий случай отключить все пути к дискам. А так как это были загрузочные диски, то они просто отвалились. Буквально на четыре минуты. Потом они поднялись, но у заказчика было кратковременное проседание бизнес-транзакций. То есть в течение четырёх минут заказчик-ритейлер не мог по всей стране продавать свою продукцию. А при двух тысячах розничных точек каждая минута простоя выражается в приличном денежном эквиваленте, не говоря о репутационных потерях.
Возможно, причина этого происшествия была в наложении багов. А может быть, просто не дружат две технологии: обвязка дискового хранилища и драйвер мультипассинга в Red Hat, который как-то странно себя повел. Ведь даже если появляется ещё один SCSI-инициатор, драйвер просто должен сказать, что теперь тоже является инициатором, и продолжать работать, а не отстреливать диски. Такого быть не должно.
На этом всё. Поменьше вам багов!
Александр Марчук, главный инженер Сервисного центра компании «Инфосистемы Джет»
Автор: JetHabr
