В прошлом месяце на одном из серверов у нас случился крупнейший сбой за последние пару лет - время даунтайма составило полтора часа, но при этом около суток наблюдались очень неприятные тормоза во время работы, во время которых даже подключится к серверу по ssh было проблемой, так как стандартного тайм-аута большинства программ не хватало чтобы сервер обработал это соединение.
Во вторник утром, около 8 часов по МСК, наши системы мониторинга увидели незначительное повышение IO delay, показателя, который отображает, насколько долго процессору приходится ожидать чтения информации с дисков или записи этой информации на них. Такие ситуации иногда происходят из-за восстановления крупных бэкапов или слишком активного использования диска одним из клиентских серверов, но в таком случае сервер автоматически получает ограничения, а его владелец уведомление, и IO delay приходит в норму, поэтому изначально мы не придали большого значения этому показателю - сервер работал в норме.
Проблемы начались примерно спустя час - значения IO delay не только не понизились, но и выросли примерно до 10% (при норме 0.1-3%). Мы начали поиск причины проблемы, но ни система, ни наши специалисты вручную не смогли найти конкретный источник такой повышенной нагрузки, количество данных, читаемых с дисков и записываемых на диски, было в пределах нормы. В следующий час ситуация стала еще хуже, достигнув значения IO delay до 50% и все операции на сервере стали выполняться очень долго. В связи с этим, мы произвели перезагрузку сервера - это решение помогло и IO delay пришёл в норму, поэтому мы решили, что проблема решена, провели несколько дополнительных проверок и начали анализ причин произошедшего. Изначально мы предположили, что проблема возникла из-за деградации какого-то из дисков, но внимательнее посмотрев логи загрузки мы заметили уведомление о статусе кэш модуля "Cache Module Status — Degraded". На первый взгляд проблема не критичная, но учитывая как недавно работал сервер, мы начали разбираться.
Есть несколько возможных точек отказа:
- Проблема с RAID контроллером.
- Проблема с модулем кэша.
- Проблема с проводами или контактами.
- Проблема с батарейкой.
Первым делом проверили статус батарейки. Статус OK.
Непонятно, загрузимся в HPSSA (HP Smart Storage Administrator). Перезагружаем сервер, при загрузке нажимаем F9 для входа в System Utilities.
Выбираем System Configuration.
Выбираем проблемный контроллер: Embedded RAID 1: Smart Array P440ar Controller.
Выбираем Exit and launch HP Smart Storage Administrator (HPSSA).
Выбираем (уже выбрано) Smart Storage Administrator. Сюда же можно попасть выбрав F10 (Intelligent Provisioning) при загрузке, но нужно будет успеть переключить пункт в этом окне.
Дожидаемся загрузки Smart Storage Administrator.
Видно, что на RAID контроллере Smart Array P440ar светится предупреждение.
Текст ошибки здесь более информативный:
Smart Array P440ar in Embedded Slot has one or more cache module batteries/capacitors that are recharging. Caching operations such Expansion, Extension, and Migration are temporarily suspended until the batteries/capacitors are fully charged. Caching operations will automatically resume when charging is complete.
Получается, батарейка находится в процессе зарядки. Такое случается, если воткнуть разряженную батарейку. Ошибка пропадёт после полной зарядки. Но в нашем случае батарейка уже давно установлена, ошибка сама не пропадает.
Посмотрим на кэш. Tools → Cache Manager → Controller Cache → Controller Cache Details.
- Cache Status: Enabled, but not currently active.
- Cache Status Details: Cache disabled; power source charging is low.
- Battery/Capacitor Status: Recharging
Кэш отключён, т.к. батарейка заряжается, а уровень её заряда низок.
Временное решение проблемы
Помимо кэша контроллера у каждого физического диска есть собственный кэш, который по умолчанию в RAID массивах отключён. Включим.
Smart Array P440ar → Actions → Configure → Modify Controller Settings.
Меняем галку Physical Drive Write Cache State на Enabled. Save Settings.
Установив эти настройки, мы подготовились к отправке в дата-центр для замены батареи, заранее уведомив клиентов сервера о предстоящих тех. работах ночью. У нас образовалось свободное окно и мы впервые за день смогли немного отдохнуть.
Проблема решена? Или нет..
Время было уже позднее, поэтому нам повезло добраться до дата-центра довольно быстро - на дорогу ушло менее 20 минут. Так как нас уже ждал дежурный инженер, проход от КПП до серверной также занял считанные минуты. Еще минута на отключение сервера, и крепкая рука админа устанавливает заведомо рабочую батарею и подключет её к кэш-контроллеру. Подключаем и включаем сервер, предварительно выключая ранее установленный Disk write cache.
Предвкушая отличное состояние статуса кэша, мы открываем нужную страницу и... ничего не изменилось. Батарея также в статусе зарядки, а кэш из-за этого в отключенном состоянии. Но батарея на 100% рабочая и была протестирована перед заменой. В связи с этим, сервер снова жутко тормозил.
Остается единственный вариант - неполадки с самим кэш-контроллером.
Хорошо, что предусмотрительный администратор захватил с собой и рабочий контроллер, хотя о его неисправности в системе не было ни слова (тогда бы мы изначально заменили его вместе с батареей).
Пришлось внепланово продлевать время тех. работ и снова выключать сервер для замены контроллера.
После замены самого контроллера системы показали рабочий статус контроллера и батареи.
Видимо, из строя вышла плата на контроллере, связанная с получением статуса батареи, из-за чего он не мог определить ее статус и указывал на нее, а сам рапортовал о своей полной работоспособности.
Работа над ошибками и обновление логики работы с кэшем
статья дополняется
