Привет, Хабр!

Эта история произошла в канун Нового года. Один из последних рабочих дней  медленно подходил к концу, мысли уже давно отмечали праздник. Идиллию нарушил звонок коллеги за два часа до окончания смены — мне предложили заняться проблемой функционирования массива Fujitsu AF650 S3. Попытки делегировать диагностику не увенчались успехом — я остался последним. Что ж, вот моя история.

Ни к чему нам лишние переживания за главного героя — Новый год я отметил с семьей за праздничным столом.

Работает плохо… И это факт

Итак, перед нами странное поведение системы. Неисправность оказалась непростой. Полтора месяца назад, по данным очевидцев, в серверной с оборудованием завелась нечистая сила. Зло оказалось настолько коварным, что не оставляло за собой никаких следов: не было ни сломанных дисков, ни порезанных кабелей, ни перегретых процессоров, ни заблудившихся электронов. Каждую пятницу схема была одинаковой: дождавшись прихода с обеда всех сотрудников, посмотрев с ухмылкой на планы грядущих выходных ответственного специалиста, нечисть останавливала ввод / вывод на массиве и с искренним умилением наблюдала за суетой. Администраторы научились сводить все на нет, но комплексно проблема возвращалась, пока не попала ко мне в руки.

Погружение

Сразу откинув мистику, пошел разговаривать с заказчиком. Конфигурация его информационных систем выглядела так:

• блочная All Flash СХД Fujitsu AF650S3;

• на ней создано семь Raid Group с Stripe Unit Size 64kb и с комбинацией 3D+1P. На каждой из групп — по одному Lun;

• к массиву подключена ферма ESXi;

• на массиве создана еще одна группа с комбинацией 4D+1P. Она целиком добавлена в пул и используется для SnapOPC+ снапшотов совместно с Veeam и последующего резервирования данных гостевых ОС;

• снапшоты создаются каждый день, соответственно, что-нибудь резервируется ежедневно;

• система мониторинга, в которой можно посмотреть нагрузку массива, отсутствует.

Затем по ходу беседы мы составили картину происходящего (на инженерном — все крайне прилично):

• по пятницам в районе 14:00 ввод / вывод на массиве с фермы ESXi практически останавливается;

• оживить массив получается только благодаря удалению снапшотов. Если точнее — остановкой заданий СРК, что в свою очередь и удаляет снапшоты (минутка предельной душноты точности);

• перед самым началом проблемы было внедрено антивирусное ПО «Касперский». По выходным дням оно создавало нагрузку по чтению, но причастно ли оно к пятничным проблемам, осталось неизвестным. Инженеры ИБ внимательно выслушивали мои вопросы относительно работы антивируса, когда он стартует и можно ли его отключить, но отвечать ничего не стали. В лучших традициях они придерживались строгих правил политики информационной безопасности;

• из утилиты управления массивом заказчик делал скриншоты во время проявления проблемы. Ничего криминального на первый взгляд оно не выявило, разве что утилизацию до 100% одного из дисков группы, которая предназначена для СРК. «Но это же SSD, да и диск всего один», — подумал я;

• запросил у заказчика конфигурацию массива.

Игра в одни ворота

После разговора первой идеей стало отключение антивируса, что оказалось бесполезным. Отдел информационной безопасности строго придерживался выбранной политики и ничего не сообщал о работе или выключении антивирусного ПО.

«Оке-е-ей. Спасибо», — ответили мы вежливо одному из инженеров ИБ. У нас же сохранялась потребность в понимании, как массив загружен во время нормального функционирования и проявления проблемы. Мы предложили заказчику установить систему мониторинга stor2rrd, после чего соотнести нагрузку с плохой работой. Но разрешение на установку любого ПО в закрытый контур выдавал отдел ИБ, а связь с ним была односторонняя, что отдаляло инсталляцию на неопределенный срок. Что же, на этом наша команда решила отпустить ситуацию с ИБ и продолжила копать в другом направлении.

Продолжение следует…

Зато в то же время я получил конфигурацию с массива. В документации я надеялся найти шестеренку, которую надо смазать, чтобы все заработало магическим образом (магические принципы же работают в обе стороны, но нет ☹).

Анализируем, смотрим, что плохо и что можно улучшить. С виду ничего необычного: группы RAID5 в комбинации 3D+1P и STU 64kb, на каждой — по тому и презентовано нодам ESXi. Была еще одна группа RAID5 в комбинации 4D+1P, на которой создан пул, и он целиком выдан для снапшотов в связке с СРК Veeam.

В общем, все выглядело хорошо, кроме одного параметра — Resolution, установленный в значение 512кб (х64).

Справка и размышления инженера: эта переменная определяет размер блока данных, адресуемых одним элементом битовой карты репликации. Таким образом, при изменении даже 512 байт на оригинальном томе на снапшотный пул переносится 512 кб. «Ну и что, — подумали мы, — это немало, но у нас же SSD-массив, который переварит все что угодно».

В моменте закрутился вопрос — почему же только один диск загружен на 100%, а остальные менее 50%. Мы предположили, что, вероятнее всего, шел какой-то внутренний процесс, который нагружал один диск. Открыли документацию — там действительно говорилось о процессе Garbage Collection, который периодически запускается и может приводить к «паразитной» загрузке диска. Очень похоже на наш случай. Но оставалось три вопроса на «п»:

Почему один диск?

Почему каждую пятницу

Почему только диски от снапшотной группы?

Наверное, это этап 2

До следующей пятницы оставалось несколько дней. Времени было немного, чтобы предотвратить остановку массива. Тем не менее план действий для себя мы сформировали.

• Во-первых, снизить значение Resolution до 64 кб (х8), так как средний блок записи составлял около 32 кб. Это позволило бы снизить поток записи на снапшотную группу и приводило бы запрос на один диск.

• Во-вторых, разнести задания бэкапов во времени и оптимизировать расписание резервного копирования, чтобы с одного тома не создавались несколько снапшотов одновременно.

• В-третьих, изменить презентацию дисковых ресурсов. Переход на тома меньших размеров снизил бы затраты на обработку снапшотов и уменьшил поток ненужных данных на снапшотный пул. В текущей конфигурации мы имели семь огромных томов, с каждого создавался снапшот для СРК. Но задания бэкапа выполнялись только для части виртуальных машин с одного тома. После завершения работы с одной порцией снапшот тома пересоздавался и резервировалась следующая порция гостевых ОС.

• В-четвертых, установить систему сбора и визуализации статистики с массива stor2rrd.

• В-пятых, обновиться. В Release Notes нового микрокода к массиву нашли баг, который сопровождался откликом для хостов на уровне 25 секунд.

Замечание на полях: шестого пункта не будет. Но так вышло, что наш план сопровождало желание отключить антивирусное ПО на одну пятницу.

К сожалению, выполнить план нам помешали ограничения, а именно — новогодние праздники и молчаливый отдел информационной безопасности. Но гордо заявляем, что первые два пункта не требовали согласований и были реализованы. Да и я пошел отмечать Новый год с семьей.

Первая пятница после изменений прошла спокойно, без каких-либо инцидентов или сбоев. Но это было обусловлено не нашим успехом, а отсутствием тех, кто мог бы зафиксировать проблемы, а также тех, кто мог создать нагрузку. Все были на праздниках.

Этап 3 — школьная арифметика

В ожидании следующей пятницы мой внутренний ученый сказал моему внутреннему инженеру: «Я нашел причину плохой работы, теперь осталась совсем мелочь — посчитать, может ли существующая нагрузка приводить к наблюдаемым проблемам». За дело!

Я взял данные нагрузки по записи на тома с ВМ во время остановки ввода / вывода. Суммарно на тома создавалась запись от 14k до 15k IOPS с потоком записи от 300 до 500 Мб/c. Со старой настройкой Resolution, равной 512 кб при условии полностью случайной записи, которая не попадает в соседние 512 кб, поток записи чистых данных на снапшотную группу составит от 7–7,5 Гб/с.

Берем комбинацию группы R5 4+1 с STU 64kb. С учетом четности 64 кб на каждые 256 кб полезных данных на RG их надо будет записывать со скоростью 8,75–9,375 Гб/c. В итоге на каждый диск будет идти запись 1,75–1,87 Гб/c.

По данным с сайта производителя Samsung, у модели PM1643a — интерфейс диска SAS 3.0 12 Гбит/с и скорость последовательной записи до 2 Гб/с.

А что же у нас? У нас ввод / вывод с диском идет через один SAS-порт диска, так как вся активность с группой обслуживается только одним контроллером. Скорость одного порта SAS 3.0 составляет ~ 1,5 Гб/с. Запись в нашем случае идет большим блоком, и она не совсем последовательная. Помимо этого, мы наблюдаем чтение в рамках резервного копирования, которое одновременно непоследовательное и нагружает диск.

Получается, при условии сильно разнесенной случайной записи в резервируемые тома массив не сможет обслуживать снапшоты из-за превышения максимальной пропускной способности одного порта диска и достижения предельных характеристик работы самого диска.

Уменьшение настройки Resolution до 64 кб приведет к снижению потока записи на снапшотную группу в 8 раз, что в случайной записи уменьшит нагрузку на диск до 0,37 Гб/с. Однако у нас появится чтение на том же уровне, что и запись.

Такие цифры подойдут для нормальной работы без деградации показателей ввода / вывода на массиве. Мы передали наши подсчеты и рекомендации заказчику.

The End

На первой праздничной пятнице сбоев больше не наблюдалось. Наш заказчик потерял к нам интерес стал намного реже отвечать на письма и больше к нам не обращался.

Единичные всплески отклика от массива на уровне 10–150 мс во время пятничных заданий СРК — вот все, что напоминало о первобытном зле. Проблема была решена, ввод / вывод не останавливался, сервера не теряли дисковые ресурсы и жалобы со стороны приложений более не поступали.

Послесловие

Твердотельные накопители с триумфом вошли в вычислительные системы еще в прошлом десятилетии. Обычные пользователи и администраторы крупных информационных сервисов пользуются огромными преимуществами SSD-дисков: ноутбуки меньше шумят, СХД не впихивают ногами в три шкафа, а компактно размещают на трех полках. И самый главный плюс — высокая скорость работы.

Но при всех преимуществах скоростных SSD-накопителей перед механическими дисками HDD остался один неявный недостаток, который поступал с каждым винчестером в коробке, — необходимость правильного проектирования системы. Некорректный сайзинг зачастую приводит к проблемам, причем с неожиданной стороны.

Кто бы мог подумать, что какие-то жалкие 15k IOPS могут практически положить массив?