17 June 2016

QoS в системах хранения Dell Compellent

Тринити corporate blog
Типичная проблема, которая может произойти с практически любой системой хранения — «проседание» производительности при аномальной активности на одном из логических дисков. Как следствие, из-за одного «соседа», страдают все потребители ресурсов и падение производительности может привести к весьма печальным последствиям. Всплески активности могут быть обусловлены как полезной (с прикладной точки зрения) периодической нагрузкой (например генерация отчетов), так и случайной ошибкой, допущенной разработчиками на тестовом хранилище. Для небольших инфраструктур, где СХД внедрялась по принципу одна система — одна задача, это конечно не так страшно. Однако сейчас речь как правило идет о консолидации самых различных сервисов. Активное применение виртуализации только усиливает этот тренд. Решение этой проблеме есть и уже много лет известно — управление уровнем сервиса (QoS), с помощью которого можно устанавливать приоритеты для разных типов нагрузки. Всего несколько лет назад технология была доступна как правило только для «больших» СХД в виде отдельного продукта (лицензии), то сейчас уже все больше и больше систем хранения получают возможность управлять QoS даже в системах начального уровня и зачастую «даром». Вот и для систем Dell Compellent с выходом Storage Center OS версии 7 также появилась возможность управлять настройками QoS. Обновление до SC OS 7 пока доступно только для СХД серии SC9000, но уже скоро можно будет использовать новую версию и на других системах линейки Compellent.
image

При включении контроля QoS в DSM, становится доступной настройка предельного значения латентности. При достижении этого показателя система начнёт пытаться «принять меры» для улучшения ситуации. Обычно базовых настроек достаточно, чтобы защититься от периодических всплесков нагрузки на отдельных томах. Поэтому всегда стоит сначала попытаться подстроить системные параметры и, только если это не помогает, переходить к тонкому «тюнингу». Целевое значение латентности не нужно брать «с потолка» — в DSM можно увидеть накопленную статистику IO Usage и уже на ее основе задавать настройки QoS. Это довольно важно, так как при слишком высоких значениях латентности мы можем столкнуться с ситуацией, когда на прикладном уровне задержки уже оказывают негативное влияние, а технология QoS не работает из-за того, что система уверена, что пока все хорошо. Слишком низкое значение латентности окажется недостижимым без принудительного снижения нагрузки, что также отрицательно скажется на производительности.

В конфигурациях с дисками различного типа (SSD + HDD) следует с особой осторожностью относиться к выбору граничного значения задержек — латентность SSD и обычных дисков отличается очень сильно и «общесистемные» настройки могут приводить к снижению производительности томов на SSD, хотя первопричина окажется в чрезмерной активности томов, расположенных на HDD.

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

Важный параметр, настраиваемый в рамках управления QoS это относительный приоритет тома. Он устанавливает, кто и в какой пропорции будет «урезан» при достижении общесистемных ограничений. Кроме базовых значений (Low — 50, Medium — 100 и High — 200) можно устанавливать и произвольные приоритеты (от 1 до 1000).
image
Приоритезация работает довольно просто — каждый том получает соответствующий приоритету процент от очереди ввода-вывода. Рассмотрим это на примере: у нас есть 5 томов с настройками 50, 100, 100, 200 и 550. В тот момент, когда латентность системы превысит заданное ограничение, СХД будет пытаться снижать нагрузку и выделит нашим томам такие доли в очереди ввода-вывода:
image
Но если какой-то из томов в настоящее время не нагружен и не использует отведенную ему долю, то его производительность снижаться не будет, а свободные ресурсы распределятся по «нуждающимися» томам. Такой подход позволяет полностью задействовать ресурсы системы хранения, обеспечивая максимальную производительность.

Когда и приоритезация уже не спасает, пора переходить к управлению ограничениями на число операций ввода-вывода (IOPS) и пропускную способностью (MB/sec) для отдельных томов.
image
При этом, наряду с индивидуальными профилями, можно настраивать и групповые. Это дает возможность накладывать ограничения на определенных потребителей (программные комплексы). На рисунке приведен пример, когда отдельным томам выделяется лимит в 1000 и 2000 IOPS, а для группы томов в бэкап пуле выделяется групповое ограничение на 500 МБ/сек. Эти 500 МБ/сек будут распределяться между всеми тремя томами в группе в любом соотношении. Но максимальная пропускная способность не будет превышать установленные рамки. Это удобно, так как можно контролировать нагрузку на систему с точки зрения предоставляемых в пользование ресурсов.

Реализация QoS в SC основана на принудительном внесении задержек между операциями ввода-вывода, когда потребление ресурсов становится выше заданных лимитов. Хотя в настройках можно задавать предельную полосу пропускания, но фактически речь всегда идет об ограничении именно числа операций ввода-вывода — СХД сама рассчитывает предельные значения IOPS, исходя из используемого размера блока.

Так как Dell Compellent имеет SDK для управления через PowerShell, то наблюдение за нагрузкой и управление QoS можно автоматизировать и интегрировать в уже используемые системы мониторинга и контроля. Последняя публично доступная версия SDK еще не содержит необходимых для этого команд, но будем надеяться, что обновление не за горами.

Возможность управлять QoS является серьезным шагом вперед и может определить выбор заказчика в пользу Compellent в ряде проектов. Новые возможности SC7 этим не ограничиваются и в ближайшее время мы расскажем о других преимуществах.

На youtube можно посмотреть ролик, демонстрирующий управление QoS в SC9000: youtu.be/1o18zTs9qdo

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

Другие статьи Тринити можно найти в блоге и хабе Тринити. Подписывайтесь!
Tags:Тринитиtrinitydelldell compellentSC9000СХДQoS
Hubs: Тринити corporate blog
0
1k 1
Leave a comment
Top of the last 24 hours