Особенности работы дискового массива HPE 3PAR

В жизни специализироваться только на SAP Basis у меня получается далеко не всегда. Да и лично мне больше интересно строить и администрировать системы на всех уровнях, начиная от аппаратного обеспечения и операционных систем, и заканчивая тонкостями серверов приложений SAP. Поэтому периодически приходится сталкиваться с нюансами работы того или иного оборудования. Всю свою карьеру до текущего момента я тесно работал с оборудованием компании Hewlett Packard. В 2009 году я уже публиковал похожий пост "Особенность работы HP EVA-5000", в котором я описал нюансы работы дискового массива EVA-5K, с которыми столкнулся на практике.

Сегодня расскажу про дисковый массив HPE 3PAR StoreServ. Один из заказчиков выбрал данное решение при переносе своей SAP инфраструктуры. Об этом я упоминал в посте про миграцию. Дисковый массив обладает хорошей производительностью и отказоусточивостью. RAID массив полностью на SSD дисках, конечно же, показывает очень хорошие результаты по времени отклика и количеству IOPS. Но уже дважды сталкиваемся с одной особенностью поведения системы, о которой я и решил рассказать. 

Дисковый массив подключен к серверам через SAN сеть, что является проверенным решением Enterprise уровня. У дискового массива 2 контроллера, в каждом из которых по 6 оптических портов. В реализованном у заказчика решении дублирование оптической сети реализовано через резервирование SAN-коммутаторов. Таким образом, от дискового массива до каждого из вычислительный серверов идёт, как минимум, 4 оптических линка (задействованы не все порты контроллеров). 

На всех аппаратно-программных уровнях SAN сети используется, рекомендуемый (и со стороны 3PAR, и со стороны VMware) multipathing, когда все линки используются по кругу, распределяя нагрузку и повышая производительность.

Пока все линки живы, всё работает просто прекрасно. Но, если хотя бы один линк "погибает", то наблюдается странная картина. Дело в том, что дисковый массив не отключает оптический порт, а просто фиксирует на нём ошибки контроля чётности (CRC error), объявляя порт деградировавшим (рис. 1).

Рис. 1. Пример ошибки оптического порта на HPE 3PAR.

Со стороны метрик производительности дискового массива фиксируется увеличение показателей Service Time даже при незначительной нагрузке. Особенно в плане операций записи (средний график) (рис. 2). Здесь видны колебания до 3 мс, когда обычно (при всех работающих линках) показатели не превышают 0,5 мс.

Рис. 2. Метрики производительности на уровне HPE 3PAR при сбое SAN порта.

Со стороны виртуальной среды VMware видна идентичная картина с метриками производительности дисковой подсистемы (рис. 3). Здесь тёмная линия  это Usage в Кб/сек. А голубая линия - это более интересный показатель - Latency в мс. Стоит отметить, что когда все линки работают без сбоев, то при любой нагрузке, генерируемой всеми вычислительными системами в текущей инфраструктуре, параметр Latency никогда не превышает 0 мс. А тут периодически выстреливает аж до 600 мс.

Рис. 3. Метрики производительности дисковой подсистемы со стороны VMware.

Всё это было бы не так страшно, но реальное приложение, SAP система, ведёт себя очень странно. В своей карьере я ничего подобного не видел. Периодически возникают дикие фризы, когда в очереди диспетчеров SAP инстанций накапливаются рабочие процессы с запросами типа COMMIT и UPDATE (рис. 4). Такая картина висит несколько секунд, иногда до 30-40, потом всё проскакивает и очередь сбрасывается до 5-8 работающих процессов. Между фризами система работает нормально минуту-две.

Рис. 4. Пример зависания SAP системы.

Так как резервное копирование выполняется по той же SAN сети, то время на создание копии также вырастает более, чем в 2 раза (рис. 5).

Рис. 5. Пример увеличения времени резервного копирования базы данных при сбоях SAN порта.

Как я уже говорил, дисковый массив не отключает SAN порты, а крутит линки по кругу. Натыкаясь на сбойные, все операции подвисают (работа фризится), увеличивая задержки на всех уровнях. Затем, когда массив понимает, что через эти линки ничего не отправить, он переключается на рабочие и моментально проводит все запросы (SSD же :) ). Работать очень не комфортно, ощущения как от зубной боли.

Помогает в данном случае, ручное отключение сбойных портов. После чего производительность работы системы нормализуется. Посмотрите на графиках выше точку времени около 12:30. В этот момент порты были отключены (переведены в OFFLINE). Для наглядности детальный график Latency (рис. 6).

Рис. 6. График Latency в момент отключения портов на работающей системе.

Корректное это поведение дискового массива или нет, судить не берусь (но больше склоняюсь, что это ненормально). Причём стоит отметить, что от количества сбойных портов поведение системы не зависит. Один порт с ошибками или половина из всего списка - картина идентична: фризы и зубная боль.

Пока остаётся только учитывать этот факт, при работе с данным оборудованием. Если начались проблемы с производительностью, проверить оптические порты на 3PAR. При наличии сбойных, временно (до того момента, когда инженеры устранят аппаратный сбой) отключить их.

Автор: Шиболов Вячеслав Анатольевич