Конечно, каждая из используемых программ, обеспечивающих multipathing, по разному влияет на производительность доступа к данным на различных дисковых массивах. Но я, как человек пристрастный, хотел бы более подробно остановиться на некоторых моментах работы только одной связки продуктов - EMC Clariion - PowerPath.
Напомню, что в Clariion при создании LUN (этот процесс называется binding) обязательно необходимо назначить контроллер-владелец (owner SP), который будет управлять этим томом. Дисковые массивы Clariion работают в режиме активный/пассивный (Active-Passive). Все пути, доступные через owner SP, являются активными. Передача данных происходит только по ним. Остальные пути пассивны. PowerPath регулярно проверяет их работоспособность, но данных не передает.
Между несколькими active путями к одному LUN работает балансировка нагрузки. При работе с массивами Clariion поддерживаются только политики, описанные в таблице. Хочу обратить внимание, что политики (за исключением default) устанавливаются индивидуально для каждой LUN.
Политика | Требуется лицензия | Описание load-balancing |
Clariion Optimize (co) | да | По умолчанию. Оптимизирована под работу с Clariion. Оптимальный путь выбирается на основе reply time SCSI команды inquiry, которая посылаются в канал каждые 30сек. |
Least I/O (li) | да | Выбор пути осуществляется на основе количества I/O запросов в очередях. Данные посылаются в порт HBA, имеющей наименьшее количество необработанных запросов, независимо от объема данных, находящихся в каждой из очередей. Иногда используется с большими OLTP СУБД. |
Least Blocks (lb) | да | Выбор пути осуществляется на основе суммарного количества блоков во всех I/O запросах, стоящих в очередях. Данные посылаются в порт HBA, имеющей наименьший объем данных в каждой из очередей, независимо от количества запросов. Иногда используется с большими warehouse СУБД. |
Round Robin (rr) | да | I/O запросы последовательно "по кругу" посылаются по всем активным путям. Редко используется для одновременной загрузки всех активных путей. |
Request (re) | да (Base) | Нагрузка не балансируется. |
Basic Failover (be) | нет | Нагрузка не балансируется. |
При выходе из строя одного из активных путей, передача продолжается по оставшимся. В случае, если LUN не доступна ни по одному из active paths, PowerPath инициирует процесс передачи управления LUN другой SP, который называется trespassing. До полного завершения этот процесс обычно требует нескольких секунд.
При анализе производительности дискового массива обязательно стоит обратить внимание на trespassed LUNs. Большое количество таких томов может привести к заметному дисбалансу нагрузки между контроллерами SP.
Драйвер PowerPath располагаются между SCSI драйвером и файловой системой. Поэтому все данные, идущие от сервера к дисковому массиву, обязательно проходят через PowerPath. На основании политик load-balancing и path failover он определяет оптимальный путь и передает данные драйверу соответствующего HBA. В случае неполадок в выбранном канале передачи, PowerPath получает извещение и выбирает другой путь, при необходимости делая LUN trespass. Только после того, как данные доставлены, PowerPath рапортует приложению об успешном выполнении операции.
PowerPath пропускает сквозь себя весь поток данных, поэтому он может полностью мониторить состояние и производительность всех путей. При включенной опции path_latency_monitor можно следить за текущими и максимальными задержками передачи данных. Установка пороговых значений латентности путей (path_latency_threshold) позволяет получать сообщения в лог-файлах о недопустимо высоких значениях задержек.
С версии FLARE 26 поддерживается режим работы ALUA (Asymmetric Logical Unit Access). При работе ALUA все пути считаются активными. Запросы к LUN через owner SP происходит так же, как и в обычном режиме. Такие пути называются оптимальными (optimized paths). Для того, чтобы разобраться какие из активных путей являются optimized, PowerPath использует SCSI-3 команды REPORT_TARGET PORT_GROUPS.
Передача данных по другим путям (non-optimized paths) требует дополнительных ресурсов обоих SP. Ведь за управление LUN отвечает owner SP и только он может записать или считать данные с дисков. Поэтому все запросы, полученные через non-optimized пути, обязательно перенаправляются owner SP через интерфейс CMI (Clariion Messaging Interface). Необходимость передачи подтверждения успешного выполнения I/O операции по пути, по которому запрос был получен, дополнительно нагружает CMI.
Без использования PowerPath, операции ввода-вывода балансируются между всеми путями (может зависеть от ОС и используемого multipathing ПО). К сожалению, такая балансировка может привести к обратному эффекту и наоборот ухудшить общую производительность дискового массива. Дополнительные накладные расходы на передачу данных между SPs при большом количестве дисков и LUNs могут снизить Throughput на 10-20%, а Bandwidth на 50%. Поэтому PowerPath осуществляет балансировку нагрузки только между optimized путями.
Использование ALUA позволяет более эффективно обрабатывать сбои. В случае возникновения проблем в Back-end, PowerPath не должен выполнять достаточно стрессовую процедуру LUN trespass. Внутренний драйвер Lower-redirector автоматически перенаправит запросы с owner SP на другой контроллер и далее по исправной FC-петле к дискам. Более того, даже родное ПО Clariion (SnapView, MetaLUN, LUN Migration, NQM и т. д.) не сможет обнаружить этот сбой.
В случае сбоя во всех optimized путях, PowerPath должен определить, является ли это следствием сбоя в каналах или по причине выхода из строя owner SP. Для этого по работоспособным путям к owner SP посылается специальный проприетарный запрос. Если причина только в каналах, то PowerPath переключит поток данных на работоспособные non-optimized пути. Функционал ALUA в этом случае позволит исключить задержку по передаче управления другому SP. Драйвер Upper-redirector перенаправит ввод-вывод на owner SP. Выход из строя всего owner SP, конечно, потребует LUN trespass.
Power Path дает возможность устанавливать приоритеты (device priority) доступа к наиболее требовательным к производительности LUNs. По умолчанию, все доступные тома имеют минимальный приоритет 0. Для данных наиболее важных приложений можно установить максимальный priority 10. При помощи неких проприетарных механизмов Power Path гарантирует пропорциональное перераспределение суммарной пропускной способности при балансировке нагрузки между всеми путями к owner SP.
Данную опцию можно настроить при любой установленной политике. Но действительно работать она будет только при использовании политика Clariion optimize.
Для того, чтобы уменьшить зависимость производительности ввода-вывода наиболее важных приложений от другой I/O активности, Power Path позволяет формировать группы каналов (channel groups). Пути, являющиеся членами одной из channel groups, выделяются для определенных LUNs. После настройки, такие зарезервированные пути перестают быть доступными для передачи данных других томов. Добавление и удаление путей из группы можно производить динамически. В каждой из channel groups должно быть не менее 2 путей.
Для обеспечения отказоустойчивости, LUN должен входить в две группы каналов: активную (active) и резервную (standby).Конечно, активная группа для одних LUNs может выступать в качестве резервной для других. При выходе из строя всех путей активной channel group, поток данных будет направляться через резервную группу.
Кстати, вершувшись к политикам балансировки нагрузки. Несколько месяцев назад я поспрашивал о том как это работает у ребят из питерской команды разработчиков Powerpath. Подробностей они, конечно, выдавать не стали, но общую картинку обрисовали. Могу сказать, что все оказалось намного проще и эффективнее, чем я это себе теоретически представлял раньше... :)
Все примерно понятно. Как смотрится это все с точки зрения MirrorView/S ? В принципе возможна схема когда пути разные - на разные Кларионы, LUN - мироренный. Или как по другому решается аналогичная задача ?
ОтветитьУдалитьНет, так не работает, ведь ID томов с разных массивов получаются разные.
ОтветитьУдалитьЗадача решается использованием Volume Manager
http://hengooru.blogspot.com/2009/12/plaids.html