Главная » Хабрахабр » Пара историй про RAID’ерский беспредел

Пара историй про RAID’ерский беспредел

В эфире продолжение нашей пятничной рубрики про сбои, отказы и прочие факапы. Если пропустили наши предыдущие рассказы, то вот ссылки: один, два, три. А сегодня мы расскажем про неприятности с 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-инициатор, драйвер просто должен сказать, что теперь тоже является инициатором, и продолжать работать, а не отстреливать диски. Такого быть не должно.

На этом всё. Поменьше вам багов!

Александр Марчук, главный инженер Сервисного центра компании «Инфосистемы Джет»


x

Ещё Hi-Tech Интересное!

[Перевод] Python Developer Tools от Microsoft. Начало работы

Последние несколько лет специалисты Microsoft трудились над тем, чтобы добавить поддержку инструментов разработчика Python в одни из наших самых популярных продуктов: Visual Studio Code и Visual Studio. В этом году все заработало. В статье мы познакомимся с инструментами разработчика Python ...

[Перевод] Вселенная, соответствующая нашим текущим представлениям, может оказаться невозможной

Новая физическая гипотеза бросает вызов лидирующей «теории всего» Один заголовок поразил его так, что он сбросил все остатки сна. 25 июня физик Тимм Вразе [Timm Wrase], живущий в Вене, проснулся, и сонно листал в онлайне список недавно опубликованных физических работ. ...