Советы по оптимизации Hyper-V (часть 4)
- Советы по оптимизации Hyper-V (часть 2)
- Советы по оптимизации Hyper-V (часть 5)
В более ранних статьях этой серии мы рассмотрели несколько аспектов оптимизации Hyper-V, в том числе то, как следует настраивать параметры кэширования диска как на хостах Hyper-V, так и на виртуальных машинах, работающих на этих хостах; как производительность Hyper-V может зависеть от базовой подсистемы хранения кластерных хостов Hyper-V и как оптимизировать производительность этих систем и устранять неполадки с помощью разумного выбора оборудования для хранения данных; и как глубина очереди хранения может потенциально повлиять на производительность виртуализированных рабочих нагрузок, выполняемых на узлах Hyper-V. Когда мы рассмотрели последнюю тему, мы упомянули, что обычно существует уровень, выше которого увеличение глубины очереди не приводит к дальнейшему повышению производительности ввода-вывода и фактически может начать приводить к обратным результатам, особенно для определенных рабочих нагрузок, таких как Microsoft SQL Server.
В этой статье мы собираемся подробнее изучить, как можно оптимизировать производительность Hyper-V при размещении кластерных рабочих нагрузок SQL Server. Это важная тема, поскольку SQL Server некоторым образом отличается от других видов серверных рабочих нагрузок, и это может сделать виртуализацию SQL Server нетривиальной задачей по сравнению, скажем, с виртуализацией роли контроллера домена, файлового сервера или веб-сервера, особенно когда рабочая нагрузка SQL Server кластеризована.
Варианты хранения для виртуализации SQL Server
Начнем с рассмотрения различных вариантов хранения, доступных при виртуализации SQL Server для обеспечения высокой доступности в Hyper-V. По сути, у вас есть два способа решить эту проблему:
- Использование общего хранилища с отказоустойчивой кластеризацией
- Использование групп доступности SQL Server
Давайте кратко рассмотрим эти два разных подхода.
Использование отказоустойчивой кластеризации
Отказоустойчивая кластеризация — это стандартное решение Microsoft, обеспечивающее высокую доступность и масштабируемость для большинства рабочих нагрузок Windows Server. В Windows Server 2012 R2 реализован ряд значительных улучшений отказоустойчивой кластеризации, а процедура установки отказоустойчивого кластера SQL Server хорошо задокументирована в Microsoft TechNet. используется для быстрого создания лабораторной среды для тестирования и разработки, как описано в этом сообщении в его блоге The Admins Guide (TAG).
При установке SQL Server на экземпляры отказоустойчивого кластера в Windows Server 2012 R2 вы также можете выбрать один из двух различных подподходов, а именно Shared VHDX или Virtual Fibre Channel. Например, вы можете установить экземпляры отказоустойчивого кластера с общими виртуальными жесткими дисками (Shared VHDX) на масштабируемых файловых серверах Windows Server (SOFS) с использованием карт удаленного прямого доступа к памяти (RDMA). Общий VHDX — это функция, которая ранее была представлена в Windows Server 2012 и позволяет использовать файл виртуального жесткого диска (VHDX) в качестве общего хранилища для гостевого кластера, то есть отказоустойчивого кластера, созданного из виртуальных машин. Shard VHDX предназначен для защиты служб приложений, таких как SQL Server, которые работают на виртуальных машинах, и значительно упрощает развертывание отказоустойчивых кластеров, поскольку вы можете использовать общие ресурсы блока сообщений сервера (SMB) в качестве общего хранилища вместо необходимости использования iSCSI или FiberChannel. массивы хранения. Хорошее объяснение того, как Shared VHDX работает в Windows Server 2012, см. в объяснении Мэтью Уокера в блоге Ask Premier Field Engineering (AskPFE) на TechNet.
Другим способом установки SQL Server на экземпляры отказоустойчивого кластера может быть использование Virtual Fibre Channel и SAN. Virtual Fibre Channel позволяет напрямую подключать приложения, такие как SQL Server, работающие на виртуальных машинах, к хранилищу Fibre Channel в вашей сети. Это позволяет использовать существующие инвестиции в технологии SAN для поддержки рабочих нагрузок виртуализации с помощью Hyper-V. Руководство по проектированию Hyper-V Virtual Fibre Channel, доступное на сайте TechNet, является лучшим источником информации о том, как начать работу с Virtual Fibre Channel. В блоге Hyper-V Notes from the Field также есть полезное пошаговое руководство по настройке Virtual Fibre Channel.
Использование групп доступности
Помимо отказоустойчивой кластеризации, альтернативным подходом к обеспечению высокой доступности и масштабируемости для SQL Server является использование групп доступности Always On (или просто групп доступности). Эта функция была впервые представлена в SQL Server 2012, и они в основном представляют собой альтернативу зеркальному отображению ваших баз данных на уровне предприятия, чтобы обеспечить их постоянную доступность. MSDN — лучший источник информации, если вам нужен хороший обзор того, как работают группы доступности, и в этом видео на YouTube Эдвина Сармьенто с мероприятия Microsoft Canada TechDays есть полезное пошаговое руководство о том, как можно преобразовать зеркала базы данных в группы доступности.
Возможно, лучший подход
Лично я считаю, что подход Shared VHDX во многих отношениях является наиболее привлекательным, если вы хотите обеспечить высокую доступность для рабочих нагрузок SQL Server, работающих на Hyper-V. Мои причины для этого следующие:
- Когда вы используете Shared VHDX в качестве общего хранилища для ваших виртуализированных экземпляров отказоустойчивого кластера, вы не будете иметь никаких действий по администрированию хранилища в том, что касается гостя.
- Использование Shared VHDX также означает, что вам не нужно выполнять какую-либо настройку хранилища для каждой виртуальной машины в хост-системах Hyper-V.
Но самый привлекательный подход с точки зрения функций не всегда является лучшим подходом с точки зрения производительности. Например, несмотря на то, что Shared VHDX обеспечивает ряд преимуществ для отказоустойчивых кластеров виртуальных экземпляров SQL Server, в некоторых сценариях это может привести к перенаправлению ввода-вывода, что может повлиять на производительность. Например, один консультант по SQL Server сообщил мне, что он видел, как Shared VHDX, реализованный на общем томе кластера (CSV), приводит к некоторым значительным проблемам производительности, связанным с вводом-выводом, когда ввод-вывод перенаправляется, и поэтому он советует соблюдать осторожность при выполнении следующих действий. этот подход. Типы сценариев, в которых возникают такие проблемы с производительностью, как правило, связаны с использованием общего VHDX с локальным блочным хранилищем, например с массивом хранения Fibre Channel или iSCSI, что приводит к перенаправлению ввода-вывода.
Однако существуют обходные пути, которые могут быть реализованы для смягчения таких проблем с производительностью. Например, обеспечение достаточной пропускной способности внутрикластерной связи является одним из ключевых соображений, позволяющих гарантировать, что перенаправление ввода-вывода не повлияет неблагоприятно на производительность вашего виртуализированного кластера SQL Server. Это означает, например, использование сетевых адаптеров на 10 ГБ на ваших серверах вместо более дешевых сетевых адаптеров на 1 ГБ, которые лежат у вас в магазине. Или, что еще лучше, приобретите NICS с поддержкой RDMA, и все должно быть в порядке с точки зрения производительности. В упомянутом ранее сообщении в блоге Мэтью Уокера подробно рассматриваются некоторые из этих проблем перенаправления ввода-вывода, но обратите внимание, что Мэтью сосредоточен на использовании общего VHDX с сетями хранения данных на основе iSCSI, а не с сетями хранения данных Fibre Channel.
Также необходимо знать, что на производительность вашего отказоустойчивого кластера может повлиять не только скорость ваших сетевых адаптеров, но и остальная сетевая инфраструктура, которую вы используете для подключения узлов вашего кластера друг к другу, к общему хранилищу и к клиенты, использующие кластеризованные приложения. Плохо спроектированная кластерная сеть часто может препятствовать работе отказоустойчивого кластера на оптимальном уровне. По сути, если вы используете общий VHDX в такой настройке, вам необходимо убедиться, что межсоединения вашего отказоустойчивого кластера оптимизированы, выполнив такие действия, как:
- Использование RDMA-совместимых сетевых адаптеров емкостью 10 ГБ.
- Использование масштабирования на стороне приема (RSS), что означает, что ваши межсоединения не должны быть частью виртуального коммутатора.
- Настройка очередей RSS на максимально поддерживаемые значения.
- Настройте план электропитания на вашем хосте Hyper-V на высокую производительность.
- Отключение NetBIOS, если он не требуется.
Вы также можете попробовать настроить буферы приема и передачи на своих сетевых адаптерах, чтобы посмотреть, может ли это улучшить производительность. И вы можете попробовать использовать Jumbo Frames, хотя вердикт о том, может ли это помочь в этом конкретном сценарии, пока неизвестен.
Некоторые другие соображения
Но не только сеть может быть основным узким местом для производительности вашего кластера SQL Server. Вы можете использовать Shared VHDX с локальным блочным хранилищем в SAN и иметь надежную сетевую структуру, но тогда оказывается, что сама SAN становится узким местом. Это связано с тем, что сети хранения данных — это, по сути, устаревшая технология со сложным стеком, производительность которого зависит от скорости подачи их дисков, скорости подачи LUN, скорости порта контроллера хранилища и скорости порта коммутатора. Затем вам придется иметь дело также с хостами Hyper-V и скоростью их портов HBA, скоростью загрузки ЦП и скоростью упреждающего чтения кэша.
Еще один недостаток использования Shared VHDX заключается в том, что в его текущей реализации в Windows Server 2012 R2 он не полностью совместим с репликой Hyper-V, функцией Hyper-V, представленной в Windows Server 2012. Реплика Hyper-V обеспечивает встроенную репликацию. механизм асинхронной репликации виртуальных машин с основного сайта на дополнительный сайт. Таким образом, реплика Hyper-V может быть ценным дополнением к вашим стратегиям аварийного восстановления, но она не будет полностью совместима с общим VHDX до Windows Server 2016. Однако до тех пор Microsoft не поддерживает использование реплики Hyper-V с какой-либо формой гостевой кластеризации.. Но это проблема аварийного восстановления, а не производительности, и здесь мы сосредоточимся на оптимизации производительности Hyper-V для кластеров SQL Server.
Группы доступности, с другой стороны, являются собственным решением SQL Server для обеспечения высокой доступности, но у них также есть свои проблемы, связанные с производительностью. Например, всякий раз, когда вы внедряете группы доступности, вы можете ожидать, что вы будете использовать вдвое больше хранилища, а также генерировать вдвое больше операций ввода-вывода в секунду по сравнению с тем, чтобы не использовать эту функцию.
Заворачиваем…
Оптимизация производительности Hyper-V для такого сложного сценария, как кластерный SQL Server, — нетривиальная, но увлекательная тема для изучения. По этой теме пока доступно не так много полезных ресурсов, возможно, потому, что платформы Windows Server Hyper-V и SQL Server продолжают развиваться в сторону своих выпусков 2016 года. В результате мы можем вернуться к этой теме в ближайшем будущем.
Есть вопросы о Hyper-V?
Если у вас есть какие-либо вопросы о платформе виртуализации Microsoft Hyper-V, лучше всего задать их на форуме Hyper-V в Microsoft TechNet. Если вы не получите оттуда необходимую вам помощь, вы можете попробовать отправить свой вопрос нам по адресу [email protected], чтобы мы могли опубликовать его в разделе «Спросите наших читателей » нашего еженедельного информационного бюллетеня WServerNews, и мы посмотрим, будет ли какой-либо из почти 100 000 ИТ-специалистов, подписавшихся на нашу рассылку, могут предложить вам какие-либо предложения.
- Советы по оптимизации Hyper-V (часть 2)
- Советы по оптимизации Hyper-V (часть 5)