Есть у меня в хозяйстве неплохая FC-СХД IBM SystemStorage DS3400, и живём мы с ней дружно и счастливо с Сентября 2010 года.
Диски, полочки добавляем — красота!
На ней крутятся виртуальные машинки VMware.

И ничто не предвещало беды, но в 10:30 понедельника всё практически встало — страшные тормоза на Exchange 2010 стали первым вестником надвигающегося апокалипсиса.

Т.к. проблема началась с системы Exchange 2010, много времени было потрачено на поиск специфичной для неё проблемы, и только спустя час стало ясно что проблема касается всех ВМ в кластере.
Первым делом в консоль СХД:
— «Storage Subsystem status is optimal.»
— «Operations in Progress: 0»,
т.е. всё нормально с ней и ничего она не делает.

Ладно, смотрим мониторинг: сразу-же подтверждаются подозрения в некой общей проблеме на СХД — отсутствие нагрузки при увеличившемся в 100 раз времени записи на СХД:

Сначала долго искали источники «невидимой» нагрузки: если не объём, то кол-во обращений и т.д. и т.п. — не нашлось НИЧЕГО.

Сейчас мы обновляем железо одного из хостов кластера VMware, с этим есть определённые проблемы, и по совету суппорта IBM все PCI слоты были переведены в режим Gen1 вместо Gen2 — в т.ч. и FC-контроллеры. Исходя из этого следующей идеей стало, что этот один хост тормозит все остальные. Только почему именно в 10:30 понедельника, когда изменения вносились в пятницу? Но как-бы то ни было, выключение этого хоста ни к чему не привело (видно на графике в 13:30).

Перебирались разнообразные версии разной степени нелепости: «не отображаемое зависание» какой-то ВМ, старые версии Vmware Tools на ВМ, глюки хостов ESX. Были изучены логи ESXов, ВМ, vCenter и пр.

Поскольку здравые и не очень идеи кончились и логика также не помогала, было принято решение лечить симптоматически, т.е. снизить нагрузку на СХД, оставив только самые критичные для бизнеса сервисы, и продолжить разбор полётов вечером/ночью когда можно будет всё выключить/перезагрузить.
Это дало результат и Exchange заворочался чуть быстрее — очередь начала уменьшаться, прочим сервисам тоже полегчало.

В процессе сбора диагностической информации для отправки запроса на поддержку в IBM и VMware, на всякий случай просматривая информацию для саппорта от СХД, обнаружил причину происходящего:

Date/Time: 04.04.11 10:31:04
Sequence number: 2218
Event type: 7310
Event category: Internal
Priority: Informational
Description: Learn cycle for battery started
Event specific codes: 0/0/0
Component type: Battery Pack
Component location: Enclosure 85
Logged by: Controller in slot A

 

Date/Time: 04.04.11 10:30:51
Sequence number: 2217
Event type: 210A
Event category: Internal
Priority: Informational
Description: Controller cache not enabled or was internally disabled
Event specific codes: 0/0/0
Component type: Controller
Component location: Controller in slot A
Logged by: Controller in slot A

 

Date/Time: 04.04.11 10:31:18
Sequence number: 2216
Event type: 7310
Event category: Internal
Priority: Informational
Description: Learn cycle for battery started
Event specific codes: 0/0/0
Component type: Battery Pack
Component location: Enclosure 85
Logged by: Controller in slot B

 

Date/Time: 04.04.11 10:31:04
Sequence number: 2215
Event type: 210A
Event category: Internal
Priority: Informational
Description: Controller cache not enabled or was internally disabled
Event specific codes: 0/0/0
Component type: Controller
Component location: Controller in slot B
Logged by: Controller in slot B

 

Date/Time: 04.04.11 9:30:54
Sequence number: 2214
Event type: 7304
Event category: Internal
Priority: Informational
Description: Battery learn cycle will occur in one hour
Event specific codes: 0/0/0
Component type: Battery Pack
Component location: Enclosure 85
Logged by: Controller in slot A

Что произошло:

  • Раз в 13 недель СХД проводит обучение аккумуляторов в контроллерах.
  • Процесс занимает приблизительно 15 часов.
  • На это время отключается кэширование записи на всей СХД, что приводит к катастрофическому падению производительности.

Предыдущее выполнение этой операции попало на новогодние праздники — и не было замечено. Ещё одно было в рабочее время, но совпало с активностью ВМ (да и самих ВМ тогда было меньше — т.е. общая нагрузка меньше, и последствия не так заметны) и не было связано нами с СХД.

После завершения процесса обучения в 01:08 вся система работает без сбоев в штатном режиме.
Последующие запуски перенесены на 23:00 пятницы.

Вопросы к IBM:

  • Почему предупреждение о начале обучения аккумуляторов за час появляется только в диагностическом логе? На почту сложно alert послать?
  • Почему в процессе обучения система показывает «Storage Subsystem status is optimal.» и «Operations in Progress: 0», хотя это явно не так?
  • Почему в системе для России дефолтное время начала обучения стоит «понедельник 10:00»? У нас выходные с пятницы начинаются.