В статье рассматриваются рекомендации, которые могут помочь вам в оптимизации и устранении неполадок производительности систем хранения данных на Hyper-V. Если вы хотите прочитать первую часть этой статьи, перейдите по ссылке.n
Введение
В предыдущей части статьи мы рассмотрели настройки кэширования диска и как оно должно быть настроено на хостах Hyper-V и виртуальных серверах, работающих на этих хостах. В настоящей статье мы рассмотрим зависимость производительности Hyper-V сервера от базовой подсистемы хранения. В частности, мы будем исследовать кластерные хост-серверы Hyper-V, как оптимизировать и устранять проблемы в работе этих систем за счет рационального выбора оборудования для хранения и как настроить подсистему хранения на этих хост-серверах. Поскольку это довольно обширная тема, которая в значительной степени зависит от вашего выбора поставщика оборудования, в этой статье мы сосредоточимся на исследовании лишь нескольких ключевых аспектах этого предмета.n
Выявление «узких мест» в хранении данных
Для сценария, который мы рассмотрим, давайте предположим, что у нас есть 4-х узловой Windows Server 2012 R2 Hyper-V хост-кластер с CSV, на котором размещается десяток виртуальных машин, работающих в качестве интерфейсных веб-серверов для «тяжелых» веб-приложений. Также давайте предположим, что эти виртуальные машины используют функцию Virtual Fibre Channel в Windows Server 2012 R2 Hyper-V, которая позволяет подключаться к Fibre Channel SAN внутри виртуальной машины с помощью Fibre Channel адаптеров главной шины (HBA) на хост-узлах кластера. Пользователи вашего веб-приложения жалуются на медленную работу приложения. Но понятие «медленный» с точки зрения конечного пользователя является довольно субъективным, так что же может быть более точным способом измерения производительности приложений? Одним из показателей, на который вы могли бы посмотреть, это время отклика диска, то есть, среднее время отклика томов CSV вашего узла кластера. В следующей таблице приведена связь уровня производительности приложений с временем ответа диска.n
| Производительность | Среднее время ответа диска | Комментарий |
| Очень хорошо | <5 мс | Уровень аналогичен уровню, предусмотренному для диска SAS |
| Хорошо | 5-10 мс | Уровень аналогичен уровню, предусмотренному для диска SATA |
| Удовлетворительно | 10-20 мс | Этот уровень, как правило, не приемлем для ввода / вывода данных при интенсивных рабочих нагрузках, таких как работа базы данных |
| Слабо, требует внимания | 20-50 мс | Этот уровень производительности может привести к тому, что пользователю может показаться, что приложение работает «медленно» |
| Серьезная проблема | >50 мс | Этот уровень производительности однозначно приведет к жалобам со стороны пользователя |
n Таблица 1: Связь уровня производительности приложений со временем ответа дискаnnЕсли среднее время ответа на диске составляет более 20 мс, то вам нужно провести тесты производительности вашей системы, чтобы попытаться определить причину проблемы. Вот счетчики, при помощи которых вам следует собирать данные для мониторинга производительности дисков на вашем Hyper-V сервере: \Logical Disk(*)\Avg. sec/Read \Logical Disk(*)\Avg. sec/Write Обычно, лучше всего сосредоточиться на счетчиках логических дисков вместо счетчиков физических дисков, так как приложения и службы, работающие на Windows Server, используют логические диски, представленные в виде букв дисков, тогда как реальный физический диск (LUN) может состоять из нескольких физических дисков, расположенных в дисковом массиве.n
Устранение «узких мест» в работе с дисками
После того, как вы определили, что ваш кластерный Hyper-V хост испытывает проблемы с производительностью из-за так называемых «узких мест» хранения, предусмотрен ряд шагов, которые вы можете предпринять. Описанные в данном разделе шаги не являются панацеей, но довольно часто могут помочь, когда приложение работает медленнее, чем хотелось бы.n
Следуйте рекомендациям вашего поставщика серверного оборудования
Как только вы определили, что проблема производительности вашего Hyper-V сервера именно в способе хранения данных, то вам стоит проверить имеет ли ваш поставщик оборудования документы с описанием лучших практик разрешения подобных проблем. Поставщики систем хранения данных часто создают такую документацию на основе общепринятых шаблонов ввода-вывода для различных видов рабочих нагрузок. Если вы можете сопоставить документацию поставщика с типом загрузки вашего собственного приложения, работающего на кластерном Hyper-V сервере, то вам нужно убедиться, что вы придерживаетесь рекомендаций в этой документации. Следуя рекомендациям вашего поставщика, вы можете обнаружить, что вы решили или, по крайней мере, смягчили вашу проблему производительности. С другой стороны, вы можете обнаружить лишь минимальные улучшения или их полное отсутствие. Это объясняется тем, что профилирование в «лабораторных» условиях иногда не очень точно отражает проблемы серверов в реальном мире, где пользователи ведут себя непредсказуемо и многоуровневые приложения могут вести себя сложнее, чем «лабораторные» образцы производителя.n
Используйте более быстрые диски в массиве хранения
Используя программное обеспечение вашего поставщика, вам следует контролировать нагрузку на массив хранения данных, чтобы увидеть, является ли ваша средняя нагрузка запредельно высокой. Если вы обнаружите, что это так, то очевидно вам нужно заменить ваши «медленные» диски на более «быстрые», например, SAS 15k. В целом, предпочтение всегда следует отдавать дискам SAS, если вы хотите обеспечить оптимальную производительность вашего массива хранения данных.n
Используйте массив RAID 10 вместо RAID 5
Традиционно, RAID 5 является наиболее популярным массивом для серверов. RAID 10 с другой стороны, использует массив дисков, которые зеркально «отражаются» на второй идентичный набор дисков. RAID 10 обеспечивает лучшую производительность чтения и записи любого уровня RAID, но только за счет необходимости в два раза большего количества дисков для такого же количества данных. Так что, если вы за надежность, высокую производительность и можете себе позволить двойные расходы на хранение данных, используйте RAID 10 и Virtual Channel Fiber. В любом случае, вы, как правило, должны использовать либо RAID 5, либо RAID 6 (двойной четности) для хранения данных, используемых виртуальными серверами, поскольку их параллельное использование может привести к проблеме случайного доступа к записи данных. Могут быть исключения из этого правила, но единственный способ, чтобы правильно их идентифицировать – это мониторинг производительности ввода-вывода различных уровней RAID для вашего приложения, так что вы можете экспериментально выбрать наиболее подходящий уровень RAID для вашего конкретного сценария. Убедитесь также, что в вашем распоряжении столько же наборов RAID, сколько узлов в сервере Hyper-V. Другими словами, четыре узла означает, что вы должны иметь четыре набора RAID, настроенных на вашем массиве хранения т.е. один набор RAID на каждый хост.n
Проверьте конфигурацию контроллера хранилища данных
Убедитесь, что встроенное программное обеспечение контроллера обновлено до последней версии поставщика, чтобы обеспечить оптимальную производительность вашего массива хранения данных. Если ваш контроллер чрезмерно подгружает процессор, то ваши диски в массиве хранения данных вероятно слишком медленные. Тут только один выход – диски SAS, как уже упоминалось выше.nnТакже, если вы не включили кэширование записи на вашем контроллере вам стоит это сделать, потому что это также может увеличить скорость операций ввода-вывода на 20% или даже больше — в зависимости от рабочей нагрузки и типа RAID, который вы установили. Конечно, есть и другие моменты, связанные кэшированием записи, но об этом вы можете почитать в части 1 этой статьи.n
Установка и настройка систем виртуализации, мониторинг и оптимизация наша компания предоставляет услуги по внедрению и поддержке виртуализации, подробности в контактах.