Советы по оптимизации Hyper-V (часть 3): глубина очереди хранилища

• Советы по оптимизации Hyper-V (часть 5)

В предыдущих статьях этой серии мы начали с изучения параметров кэширования дисков и того, как их следует настраивать как на хостах Hyper-V, так и на виртуальных машинах, работающих на этих хостах. Затем мы перешли к изучению зависимости производительности Hyper-V от базовой подсистемы хранения кластерных хостов Hyper-V, а также способов оптимизации производительности и устранения неполадок в этих системах посредством разумного выбора оборудования для хранения. Мы также начали обсуждать, как вы можете настроить подсистему хранения на кластерных хостах, но эта тема, естественно, сильно зависит от вашего выбора поставщика оборудования для хранения. В этой статье мы продолжаем предыдущее обсуждение, исследуя проблему глубины очереди хранения и ее потенциальное влияние на производительность хостов Hyper-V и виртуальных машин, работающих на этих хостах, что, конечно же, влияет на производительность рабочих нагрузок и приложений. работает на этих виртуальных машинах.

Просмотр сценария

Мы продолжим наше обсуждение, основываясь на сценарии, который мы изложили в предыдущей статье этой серии, а именно, хост-кластере Windows Server 2012 R2 Hyper-V с четырьмя узлами и хранилищем CSV, в котором размещается дюжина виртуальных машин, работающих в качестве интерфейсных. веб-серверы для крупномасштабного веб-приложения. Наши виртуальные машины также используют функцию Virtual Fibre Channel в Windows Server 2012 R2 Hyper-V, которая позволяет подключаться к хранилищу SAN Fibre Channel из виртуальной машины через адаптеры главной шины Fibre Channel (HBA) на узлах хост-кластера. В предыдущей статье мы обсуждали использование времени ответа диска, то есть среднего времени отклика томов CSV хост-кластера, как способ измерения производительности веб-приложений, размещенных на нашем хост-кластере Hyper-V. Затем мы предположили, что если измеренная производительность приложения ниже определенного порога (мы выбрали 20 мс в качестве разумного предела), то администратор хост-кластера должен предпринять какие-то корректирующие действия, чтобы устранить узкое место в системе хранения и попробуйте повысить производительность приложения. Мы определили пять примеров возможных рекомендаций:
• Следуйте рекомендациям поставщиков систем хранения данных.
• Используйте более быстрые диски в массиве хранения
• Используйте RAID 10 вместо RAID 5.
• Убедитесь, что прошивка контроллера хранилища обновлена.
• Включите кэширование записи на контроллере хранилища (но некоторые соображения по этому поводу см. в первой части этой серии).

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

Глубина очереди

Массивы хранения, такие как Fibre Channel SAN (сети хранения данных), часто используются в настоящее время в качестве системы хранения для хост-кластеров Hyper-V. В типичном примере массив хранения подключается к одному или нескольким коммутаторам SAN для формирования сети SAN. Коммутаторы SAN предоставляют порты SAN (также называемые портами коммутатора или портами фабрики), где хосты (т. е. серверы) могут подключаться к фабрике SAN через адаптеры главной шины (HBA), установленные на серверах. Подробное объяснение того, как работают технологии SAN, см. в серии статей Брайена М. Поузи под названием «Ускоренный курс по организации сетей хранения данных» на сайте WindowsNetworking.com.
Одним из настраиваемых параметров адаптера главной шины (также чаще называемого контроллером хранилища) является глубина очереди. Этот параметр указывает количество запросов ввода-вывода, которые контроллер хранения может ставить в очередь для обработки. Глубина очереди на HBA определяется для каждого LUN (номер логического устройства). Если очередь на контроллере хранилища заполнится, контроллер отклонит и отменит дальнейшие запросы к хранилищу (чтение или запись). Затем хост (т. е. приложение, работающее на хосте) должен попытаться снова отправить запрос ввода-вывода через короткое время.
Когда вы настраиваете глубину очереди на хосте (т. е. на HBA в ваших хостах Hyper-V), вы должны стараться следовать этим общим рекомендациям:

Настройте параметр глубины очереди одинаково на всех хостах в вашем кластере, чтобы гарантировать, что хосты имеют равный доступ к пулу хранения в вашей SAN.
• Глубина очереди HBA должна быть больше или равна количеству шпинделей, к которым подключается хост (для массива хранения на основе жестких дисков).
• Как правило, чем больше кластер хостов (и чем больше в нем запущено виртуальных машин), тем выше должна быть глубина очереди.
• Однако обычно существует уровень, выше которого увеличение глубины очереди не приводит к дальнейшему повышению производительности ввода-вывода и фактически может начать приводить к обратным результатам, особенно для определенных рабочих нагрузок, таких как SQL Server.
• Не допускайте превышения глубины очереди на хостах (т.е. на HBA) глубины очереди, настроенной для портов SAN, к которым подключены HBA.
Однако это только основные рекомендации; в реальном мире, где у вас может быть несколько виртуальных машин, работающих на каждом хосте, и несколько карт HBA на каждом хосте, все может стать немного сложнее.

Определение оптимальной глубины очереди

Как правило, выбор оптимальной глубины очереди для HBA на кластеризованных узлах Hyper-V в среде SAN лучше всего решать, сверяясь с документацией поставщика SAN, поскольку карты HBA обычно предоставляются одним и тем же поставщиком. В качестве примера (хотя и взятого из мира VMware, а не Microsoft) один эксперт рекомендует следующую формулу для определения глубины очереди в сценарии, когда у вас есть несколько хостов ESXi, использующих хранилище SAN:
Port-QD = ESXi Host 1 (P * QD * L) + ESXi Host 2 (P * QD * L) ….. + ESXi Host n (P * QD * L)
Здесь Port-QD представляет глубину очереди целевого порта, P представляет количество путей хоста, подключенных к целевому порту массива, L представляет количество LUN, представленных хосту через целевой порт массива, а QD равняется глубине очереди LUN на целевом порту массива. хозяин. Вы можете прочитать полную статью здесь.

Есть ли у Microsoft аналогичная формула для расчета глубины очереди в кластерных средах узлов Hyper-V? К сожалению, нет — они в основном просто оставляют это на усмотрение поставщика хранилища (SAN). В качестве примера этого у Hitachi есть документ в формате PDF под названием «Передовые практики для Microsoft SQL Server на виртуальной машине Hitachi Universal Storage Platform», в котором говорится следующее о настройках глубины очереди HBA:

«Установка слишком низкой глубины очереди может искусственно ограничивать производительность приложения, а слишком большая может привести к небольшому сокращению операций ввода-вывода. Правильная настройка глубины очереди позволяет контроллерам системы хранения Hitachi оптимизировать несколько операций ввода-вывода для физического диска. Это может значительно улучшить ввод-вывод и сократить время отклика».
Затем они предоставляют следующую формулу для расчета глубины очереди:
2048 ÷ общее количество LU, представленных через интерфейсный порт = глубина очереди HBA на хост
Однако коллега, который на самом деле проверил это для кластерной хост-среды Hyper-V, на которой работает SQL Server, обнаружил, что, хотя формула рекомендовала использовать глубину очереди 128, протестированная производительность была на самом деле лучше при использовании глубины очереди 64. Итак, другими словами, подобные формулы следует рассматривать как рекомендации для начала настройки длины очереди, а не как жесткие и быстрые правила.

Копать глубже

Давайте углубимся в мое предыдущее заявление о том, что существует уровень, выше которого увеличение глубины очереди HBA не приводит к дальнейшему повышению производительности ввода-вывода и может фактически нанести ущерб производительности приложений, работающих на вашем хост-кластере. Дело в том, что если устройства хранения в вашем массиве работают медленно, то увеличение глубины очереди на самом деле только удлиняет, а не ускоряет канал ввода-вывода хранилища. Другими словами, если ваше приложение медленно отвечает или время ожидания истекло из-за узкого места в хранилище, проблема, скорее всего, не в настройке длины очереди, а в медленных устройствах хранения (или неоптимальной конфигурации RAID). Кроме того, увеличение глубины очереди на стороне хоста (кластера) без учета конфигурации на стороне хранилища (SAN) может привести к перегрузке массива хранения до такой степени, что производительность начнет снижаться.

Таким образом, если вы отслеживаете длину очереди на своих HBA и видите, что очереди заполняются, у вас может возникнуть соблазн увеличить глубину очереди на коммутаторах SAN, чтобы обработать больше запросов ввода-вывода от HBA на хостах. Но хотя это может привести к меньшему накоплению в ваших очередях HBA, вы можете фактически увидеть снижение производительности приложений, потому что ввод-вывод теперь может зависать в контроллерах хранилища.

Нижняя линия

Суть здесь в том, что независимо от того, что вы делаете с точки зрения настройки глубины очереди, будь то на стороне HBA или на стороне SAN, вам нужно проверять эффект каждый раз, когда вы вносите изменение. Это также означает, что каждый раз, когда вы добавляете дополнительный хост, или другой HBA к хосту, или более быстрые диски в массиве, вам нужно вернуться и начать все сначала и протестировать производительность вашей среды. Таким образом, лучший подход, помимо следования общим рекомендациям, перечисленным выше, и попытки разобраться с рекомендациями поставщика хранилища, вероятно, состоит в том, чтобы начать с настроек глубины очереди по умолчанию и вносить изменения по одному, чтобы увидеть, улучшается или ухудшается производительность вашего приложения.. И действительно, вам нужно беспокоиться о настройке глубины очереди только в том случае, если вы видите тревожное время отклика диска, превышающее пару секунд. В противном случае производительность вашего приложения, вероятно, достаточно высока, чтобы обеспечить «достаточно хорошее» удовлетворение для большинства заказчиков и клиентов, так зачем тратить свое время и энергию, пытаясь выжать еще одну секунду из времени отклика? Лучше заниматься более насущными вопросами, такими как обеспечение безопасности учетных данных и финансовых записей ваших клиентов, решение проблем соблюдения конфиденциальности на национальном уровне для различных сегментов клиентов и так далее.

Вывод

Мы рассмотрим некоторые другие советы по повышению производительности хранилища в средах Hyper-V в следующих статьях этой серии.

Есть вопросы о Hyper-V?
Если у вас есть какие-либо вопросы о платформе виртуализации Microsoft Hyper-V, лучше всего задать их на форуме Hyper-V в Microsoft TechNet. Если вы не получите оттуда необходимую вам помощь, вы можете попробовать отправить свой вопрос нам по адресу [email protected], чтобы мы могли опубликовать его в разделе «Спросите наших читателей» нашего еженедельного информационного бюллетеня WServerNews, и мы посмотрим, будет ли какой-либо из почти 100 000 ИТ-специалистов, подписавшихся на нашу рассылку, могут предложить вам какие-либо предложения.

• Советы по оптимизации Hyper-V (часть 5)