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

Опубликовано: 18 Апреля, 2023

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

Введение

В предыдущей статье этой серии мы рассмотрели параметры дискового кэширования и способы их настройки как на хостах 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.

Производительность

Среднее время ответа диска

Обсуждение

Отлично

Менее 5 миллисекунд

Этот уровень производительности аналогичен выделенному диску SAS.

Хороший

Между 5 и 10 мс

Этот уровень производительности аналогичен выделенному диску SATA.

Удовлетворительно

Между 10 и 20 мс

Этот уровень производительности обычно неприемлем для рабочих нагрузок с интенсивным вводом-выводом, например, когда задействованы базы данных.

Плохо, требует внимания

Между 20 и 50 мс

Этот уровень производительности может привести к тому, что пользователи заметят, что приложение иногда «чувствует себя медленным».

Серьезное узкое место

Более 50 мс

Этот уровень производительности обычно вызывает жалобы пользователей.

Таблица 1: Связь уровня производительности приложения со временем ответа диска

Если среднее время ответа диска превышает 20 мс, вам следует провести мониторинг производительности вашей системы, чтобы попытаться определить причину проблемы. Счетчики производительности, которые обычно следует начинать собирать для мониторинга производительности дисков на хостах Hyper-V, следующие:

Логический диск(*)Сред. сек/чтение

Логический диск(*)Сред. сек/запись

Обычно лучше сосредоточиться на счетчиках логических дисков, а не на физических дисках, потому что приложения и службы, работающие в Windows Server, используют логические диски, представленные буквами дисков, тогда как фактический физический диск (LUN), представляемый операционной системе, может состоять из нескольких физических дисков. диски, организованные в дисковый массив.

Решение проблем с узким местом на диске

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

Следуйте рекомендациям вашего поставщика систем хранения

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

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

Используйте более быстрые диски в массиве хранения

Используя программное обеспечение поставщика системы хранения, вы должны контролировать нагрузку на массив хранения, чтобы определить, является ли средняя нагрузка неприемлемо высокой. Если вы обнаружите, что это так, то один очевидный шаг, который вы можете сделать, — это заменить любые более медленные диски более быстрыми дисками, например, дисками SAS 15 КБ. В общем, предпочтение всегда следует отдавать дискам SAS, а не дискам SATA, если вы хотите обеспечить оптимальную производительность массива хранения. Диски SAS 10k или 15k всегда предпочтительнее дисков SATA любой скорости.

Используйте RAID 10 вместо RAID 5

Традиционно RAID 5 (чередование с контролем четности) был наиболее популярным уровнем RAID, используемым для серверов. С другой стороны, RAID 10 (зеркалирование с чередованием) использует чередующийся массив дисков, которые зеркалируются на второй идентичный набор чередующихся дисков. RAID 10 обеспечивает наилучшую производительность чтения и записи среди всех уровней RAID, но только за счет того, что для заданного общего объема хранилища требуется в два раза больше дисков. Поэтому, если вы можете позволить себе выделить дополнительные ресурсы хранения для вашего хост-кластера, используйте RAID 10 для хранения, используемого вашими виртуальными машинами через Virtual Fibre Channel. В любом случае, как правило, не следует использовать RAID 5 или RAID 6 (RAID с двойной четностью) для хранения, используемого виртуализированными рабочими нагрузками, поскольку это неподходящее решение из-за произвольного доступа для записи. Однако из этого правила могут быть исключения, но единственный способ правильно их идентифицировать — это отслеживать производительность чтения/записи различных уровней RAID для вашего приложения, чтобы вы могли очевидно выбрать наиболее подходящий уровень RAID для вашего конкретного сценария.

Также убедитесь, что у вас есть столько наборов RAID, сколько узлов в вашем хост-кластере Hyper-V. Другими словами, наличие кластера хостов с четырьмя узлами означает, что у вас должно быть четыре набора RAID, сконфигурированных на вашем массиве хранения, т. е. по одному набору RAID на каждый хост.

Проверьте конфигурацию контроллера хранилища

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

Кроме того, если вы не включили кэширование записи на своем контроллере хранилища, вы можете сделать это, так как это может увеличить пропускную способность ввода-вывода на 20% или более в зависимости от вашей рабочей нагрузки и типа реализованного вами уровня RAID. Конечно, есть и другие соображения, связанные с кэшированием записи, см. часть 1 этой серии, чтобы узнать больше об этом.

Вывод

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

Есть вопросы о Hyper-V?

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

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