Trinity, Технический блог. Все о серверах, системах хранения данных и виртуализации.: История про интеграцию Unity 400F, Wabi-Sabi и гонке на ¼ мили.

Пошел уже 153 год, как с легкой руки Льюиса Керролла идея о мирах, где “Красная Королева должна бежать, чтобы оставаться на месте” заражает своей модной эпистемой самые широкие круги читателей. Западные традиции, лежащие в основе этого разрыва в археологии знаний настолько сильны, что для душевного равновесия на другую чашу весов требуется поместить не менее фундаментальные восточные концепции. В этом смысле очень показательна история создания СХД Unity. Если обратить внимание на позиционирование этой СХД самим производителем, то у интеграторов может ненароком случиться инсайт или душевное расстройство от предвкушения очередной гонки за выживание:

По показателям $/GB и “Solution Integration” у СХД твердая пятерка, а по отказоустойчивости и стоимости операции – четверка. Просто-напросто, райский уголок для интеграторов в SMB секторе. Когда эта “паутина” в первый раз попалась мне на глаза, то первая реакция на нее была очень резкой – пустой маркетинговый ход. Действительно, если в контексте интеграции решения предлагается сосредоточить внимание сразу на нескольких точках из указанной выше паутины, то, как оценить ее эластичность? Часто подобные диаграммы рисуют исходя из того, что одна твердая пятерка в ней достижима только по отдельности, за счет снижения остальных показателей. В этом смысле, интереснее всего те нагрузочные тесты, в которых СХД демонстрирует размер диагоналей в отмеченной фигуре, а не ее площадь в последовательных тестах по точкам. Тогда и возникает возможность оценки эластичности этой фигуры при комбинировании указанных параметров. Попробуем поставить эту задачу так, чтобы она была еще и с инженерной точки зрения не самой банальной:

· Как испытание на надежность (RAS) влияет на стоимость операции СХД ($/IOps)?

· Как виртуализация клиентской среды (Solution Integration) влияет на стоимость операции ($/IOps)?

Чтобы не растекаться мыслью по древу, для конкретики возьмем виртуализацию на базе VMware. Тогда, общая картина решения при интеграции СХД Unity 400F будет выглядеть в первом приближении так:

Т.е., прежде, чем наводить блеск со стороны СХД, в этом стеке необходимо разобраться с четырьмя верхними уровнями (GQLen, WQLen, AQLen, DQLen):

GQLen: Как создать очередь операций требуемой длинны на стороне приложения:

2. Как контролировать AQLen, WQLen, DQLen (очереди на уровне гипервизора):

И, наконец, как контролировать дисковые очереди на стороне СХД:

Наблюдаем шесть графиков: (чтение, запись, всего) x (SPA, SPB).

Надеюсь, что текст и графики, представленные ниже, несколько упростят жить инженерам, работающим с СХД Unity в полях и в службах технической поддержки интеграторов. Основная цель публикации этих материалов – привлечь внимание к методике «научного тыка» при нагрузочном тестировании СХД, которая, не требуя от инженеров специальной подготовки, позволит быстро оценить уровень производительности Вашей СХД при работе в виртуальных средах. Кроме того, перед обращением за поддержкой у Вас появится шанс свериться с еще одной базовой линией в спектре нагрузочных тестов. Не претендуя на оригинальность, в статье приводится методика оценки производительности СХД и результат ее применения на конкретном примере, без погружения в несущественные детали, вроде тех, где взять IOmeter или как создать VM?

Поехали:

Для начала, выберем из перечня доступных нам, те интерфейсы, по которым мы будем подключать гипервизор с клиентами к СХД:

1. Из соображений максимальной производительности мы воспользуемся прямым подключением по оптике через конвергентный адаптер, встроенный в каждый сервисный процессор СХД (на схеме отмечены зеленым цветом). Коммутаторы для этого не требуются, конфигурация стенда - проще не придумать: один гипервизор (узел генератора нагрузки с двумя картами FC), подключенный напрямую к двум сервисным процессорам СХД:

На стороне СХД поддержка FC реализована на базе CNA QLogic Corp. Device 2831. Это OEM версия CNA, которая выпускается QLogic для производителей СХД. Показатели производительности одного порта в нашей конфигурации - 1600MBps и 500k IOPS:

В тестовом стенде два сервисных процессора в базовой комплектации, без интерфейсных карт (SLIC в терминологии EMC). В каждом SP по одному конвергентному адаптеру с двумя портами (CNA QLogic 2831 FC/Ethernet) и два порта 10G Ethernet (Intel X540-AT2). Поскольку, мы озадачились тем, чтобы снять нагрузочную характеристику СХД, мы не должны испытывать ограничений со стороны генератора. Это в равной мере относится и к вычислительной мощности, и к интерфейсам, связывающим его с СХД, и к его архитектуре. Перед тем, как делать выводы о возможностях СХД необходимо оценить возможности генератора на идеальной нагрузке. Без подобной калибровки влияние нагрузочной кривой генератора на результаты измерений будет весьма драматичным.

Калибровка стенда.

Калибровку будем проводить по частям, отдавая себе отчет в том, что эти части, после объединения в целое, не должны существенно влиять друг на друга. Начнем с оценки возможностей генератора при работе на идеальную нагрузку (не /dev/null на стороне VM, конечно :). В лабораторных условия задачи создания нагрузки решается элементарно:

Но, вот вопрос, откуда взять ее в полях? В этом месте придется прибегнуть к небольшой хитрости, которая, позволит существенно сократить время калибровки и осуществить ее подручными средствами. В конце концов, наши предки почти всё умели делать или палкой-копалкой, или бороной-суховаткой или косой-горбушей. Чем проще инструменты и материалы и сложнее конечный результат, тем интересней инженерная задача. Автомеханики перед полной нагрузкой трансмиссии проверяют ее общую работоспособность, не опуская автомобиль с подъемника. Мы поступим аналогично. Первый нагрузочный тест должен выявить отсутствие ограничений по числу IOps в связке «генератор нагрузки - контроллер СХД», которые могут повлиять на наши дальнейшие тесты. Общая идея, лежащая в основе калибровочных тестов, состоит в том, чтобы на СХД создать конфигурацию, которая минимально ограничена со стороны собственного бекэнда (числом дисков, их типом, размером и т.д.). Постараемся «оторвать колеса от земли» и сконфигурировать СХД таким образом, чтобы показатели производительности ограничивались только ее сервисными процессорами. Общего рецепта того, как «оторвать» сервисные процессоры любого производителя от бэкэнда с дисками, не потеряв гарантии и не нарушая при этом логику их работы, не существует, но, для Unity есть рецепт, к счастью, легко реализуемый. Достаточно заметить, что операции чтения с томов, на которых нет данных, практически не затрагивают дисковую подсистему СХД. Проще всего можно добиться этого, создавая тома “thin provision”.

Из командной строки Unity эта процедура выглядит так:

for lun in `seq 1 16`;

echo create lun spb-test-$lun

uemcli -u admin -p pwd /stor/prov/luns/lun create -async -name spb-test-$lun -pool Platinum -size 500G -thin yes -lunHosts Host_4

done

В такой конфигурации тест в IOmeter с профилем нагрузки (8K, 100% Read, 100% Random) демонстрирует способность связки vm-гипервизор-SP обрабатывать более 400K IOPS:

При этом балансировка нагрузки по каналам и сервисным процессорам СХД работает корректно:

Т.е. «сферический конь в вакууме» у нас уже есть и теперь пора «опустить его колеса на землю» и приступать к тестам, ради которых мы все это и затеяли. Роль клиентов будут играть четыре VM на одном хосте SuperMicro X11 с ESXi 6.0. Профиль нагрузки IOmeter – (8K, 67% Read, 100% Random). Чтобы не греть воздух в пустую, проверим во время теста первую гипотезу: в нашем распоряжении Raid5(8+1) из 9 дисков, каждый из которых справляется с 40 kIOps при записи блоками по 8k. Для проверки этой гипотезы возьмем одну из точек на графике прогнозируемой производительности, соответствующую прикладываемой нами нагрузке (67% Read, 100% Random, 8k):

Погнали…

19:36 - начат тест Unity 400F на четырех VM с одного узла ESXi (16-ть pRDM, по четыре в каждой VM). Тест окончен в 22:10:

Получается, что гипотеза наша подтвердилась и воздух мы грели не даром :)

Список использованной литературы:

https://www.emc.com/ppg/platform-unity.htm

https://blogs.vmware.com/virtualblocks/2016/10/18/whats-new-in-virtual-volumes-2-0/

https://www.emc.com/collateral/white-papers/h15091-emc-unity-virtualization-integration.pdf

https://www.emc.com/collateral/TechnicalDocument/docu69329.pdf

Что удалось сделать в фоновом режиме, за время подготовки стенда к нагрузочным тестам:

1. Проверить на практике возможности интеграции СХД и VMware:

2. Заглянуть под капот:

3. Убедиться в том, что кроме очевидных архитектурных ограничений у СХД существуют еще и ограничения по интеграции, про которые не стоит забывать при ее позиционировании в проекты:

10:40:44 service@(none) spa:~> uemcli /sys/limit show | grep -i vvol

1: ID = Limit_MaxBaseVVolCount

Name = Max Base VVol Count

Description = The maximum allowed number of Base VVols.

2: ID = Limit_MaxBoundNASConfigVVolCount

Name = Max Bound NAS-config VVol Count

Description = The maximum allowed number of bound NAS-config VVols.

3: ID = Limit_MaxBoundVVolCount

Name = Max Bound VVol Count

Description = The maximum allowed number of bound VVols.

12: ID = Limit_MaxNASConfigVVolCount

Name = Max NAS-config VVol Count

Description = The maximum allowed number of NAS-config VVols.

34: ID = Limit_MaxVVolCount

Name = Max VVol Count

Description = The maximum allowed number of VVols.

35: ID = Limit_MaxVVolDatastoreCount

Name = Max VVol Datastore Count

Description = The maximum allowed number of VVol datastores.

10:40:54 service@(none) spa:~>

4. Обновить прошивку контроллеров и дисков под нагрузкой:

5. Проверить корректность работы локализованного интерфейса:

6. Проверить локализацию справочной системы:

7. Определить потребление электроэнергии СХД.

a. В каждом контроллере по одному PSU, максимальной мощностью 1050W (Optimus 1050W Wide-Range GEN1+ OTS PSU(Acbel 611)).

b. При 85% загрузке обоих контроллеров и полностью заряженных BBU потребление СХД с десятком дисков не превышает 400W.

с. В режиме простоя потребление (при BBU с полным зарядом) не превышает 250W.

8. Проверить работоспособность репликации между двумя СХД Unity 300 и Unity 400F

a. Синхронная репликация (CNA в режиме FC, 16Gbps SR, Direct attach)

i. CNA в режиме FC, оригинальные SFPplus модули.

Из замеченных странностей – после завершения начальной синхронизации, наблюдается существенное снижение скорости репликации, если ее приостановить и, затем продолжить. С асинхронной репликацией такой эффект не наблюдается. Для чистоты эксперимента процедура воспроизведена с разными SFPplus (см. ниже) и падение скорости оценено по затратам, необходимым на начальную синхронизацию и на продолжение репликации после временной приостановки. Отличие – более чем на порядок. Это вопрос требует более детальной проработки.

ii. CNA в режиме FC, SFPplus модули не оригинальные (половина Finisar, половина Avago).

b. Асинхронная репликация, через стек коммутаторов

i. Через набортные Intel X540-AT2

ii. CNA в режиме Ethernet (10Gbps)

9. Проверить возможность переключения CNA между режимами FC-Ethernet. Иногда в проектах заранее неизвестно, по каким протоколам придется подключать СХД. Для реконфигурирования режима работы CNA требуется провести процедуру сброса СХД к заводским настройкам.

10. Проверить процедуру замены диска при его аварии (диск в U400F вышел из строя при черновом прогоне теста.) Удивительнее всего то, что после сброса СХД на заводские настройки этот диск снова заработал, как ни в чем не бывало. И совсем оригинально выглядит ссылка в web-интерфейсе, которая появляется только при неисправном диске. По неумолимой логике жанра она должна уводить на RMA процедуру, а уводит в пустоту...

11. Проверить процедуру замены резервных батарей (BBU). Об этом можно написать отдельную статью, т.к. стратегия управления кэшированием в Unity при авариях с BBU выше всяких похвал. Кеш обоих контроллеров действительно работает при единственной исправной батарее.

Особая благодарность за предоставленные образцы техники и поддержку компаниям OCS и Питерскому центру разработки EMC:
https://russia.emc.com/coe/index.htm

PPS

Для тех, кто мужественно дочитал статью до этого места:

Wabi-Sabi…

Проверяем, как работает защита MMC кэша (это одна из тех HI-End “Multi-Core Everything” функций, что достались Unity в наследство от VNX). В состоянии с полностью заряженными BBU, СХД была обесточена на 8 часов. Включение системы потребовало вмешательства со стороны оператора. С легкой руки какого-то электрика провести тест «помогла» авария с питанием во всем здании. СХД к этому моменту была уже сконфигурирована для основного теста, а UPS после аварии ночью продержал питание нагрузочного стенда около 20 мин, после чего СХД была обесточена аварийно в составе всего вычислительного комплекса, вместе с генератором нагрузки. В сухом остатке – service hint (MCC cache was not recovered) приводит нас к документу https://community.emc.com/docs/DOC-24317 и описанию функциональности “Multi-Core Everything” https://www.penguinpunk.net/blog/emc-next-generation-vnx-mcx/

Завораживающая красота трех десятков лет непрерывной гонки за первенство на ¼ мили…

PPPS

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

PPPPS

Причина перекоса в показателях производительности контроллеров (сконфигурированных и нагруженных абсолютно симметрично) выяснена:

zombie perl процесс на контроллере spa утилизировал его на 30% в состоянии отсутствия нагрузки.

Перезагрузка контроллера помогла:

PPPPPS

Обновление прошивок SP под нагрузкой:

You have received this message because an event that has occurred on your Unity (CKM00162403783/192.168.149.74) system requires your attention. The alert is:

A recommended system software (version 4.1.1.9138882) is now available for download.

Текущая версия ПО: 4.1.0.9058043