Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 7)

• Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 5)
• Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 6)

На протяжении всей этой серии статей я говорил о способах увеличения количества виртуальных машин, которые можно разместить на сервере Hyper-V. В этой статье я хочу завершить обсуждение, рассказав о новой функции Hyper-V в Windows Server 2012 R2.

Новая функция, о которой я говорю, называется Quality of Service Management (ранее известной как Storage QOS). Эта функция, которую вы можете видеть на рис. A, позволяет указать минимальный порядок максимального количества операций ввода-вывода в секунду для каждого виртуального жесткого диска. Я кратко коснулся этой функции в части 3 этой серии статей, но хочу вернуться к ней более подробно.

Рисунок A. Функция управления качеством обслуживания позволяет регулировать потребление операций ввода-вывода в секунду для каждого виртуального жесткого диска.

Как видите, эта функция относительно проста в использовании. Если вы обеспокоены тем, что виртуальный жесткий диск не получает достаточно дискового ввода-вывода, вы можете установить минимальный уровень IOPS. С другой стороны, если на виртуальном жестком диске размещается приложение с очень интенсивным вводом-выводом, вы можете захотеть заполнить поле Максимальное количество операций ввода-вывода в секунду, чтобы ограничить общее количество операций ввода-вывода в секунду, которое может потреблять виртуальный жесткий диск.

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

Хотя функция управления качеством обслуживания является новой для Windows Server 2012 R2, концепция качества обслуживания хранилища не уникальна для Microsoft. Ряд различных поставщиков систем хранения данных начинают включать в свои продукты функции QOS для хранения данных. Создается впечатление, что индустрия хранения данных убеждена в том, что регулирование хранилища на основе QoS станет следующей важной задачей для управления IOPS хранилища.

Хотя QOS хранилища, безусловно, может иметь свое место, оно, скорее всего, даст наибольшую выгоду в сочетании с другими функциями производительности хранилища. Позвольте мне уточнить.

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

Но вот где проблема пропускной способности поднимает свою уродливую голову. Представьте на мгновение, что для доставки достаточного объема дискового ввода-вывода в базу данных требуется двадцать дисковых шпинделей. Теперь предположим, что каждый из этих дисков имеет скромный размер в 1 ТБ. Если для простоты убрать из картины все накладные расходы, это будет означать, что для базы данных было выделено 20 ТБ дискового пространства. Так что же произойдет, если для базы данных потребуется всего 1 ТБ дискового пространства? Остальные 19 ТБ были потрачены впустую только для обеспечения адекватной производительности.

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

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

Имея это в виду, мы вернулись к исходному парадоксу хранения. Как предоставить виртуальному жесткому диску необходимое количество операций ввода-вывода в секунду, не тратя при этом слишком много места на физическом диске?

Если подходить к проблеме исключительно с точки зрения Windows, то лучшим решением может быть объединение двух отдельных технологий, присутствующих в Windows Server 2012 R2. Первой из этих технологий, очевидно, является управление качеством обслуживания.

Даже если у вас есть виртуальный жесткий диск, содержащий приложение с высокой нагрузкой, спрос на дисковый ввод-вывод, вероятно, не будет одинаковым во все времена. Будут пики и спады спроса. В этом случае вы можете использовать управление качеством обслуживания, чтобы гарантировать, что всем виртуальным жестким дискам, которые совместно используют физическое хранилище, гарантировано определенное минимальное количество дисковых операций ввода-вывода. Таким образом, если виртуальный жесткий диск с высоким спросом получает экстремальный всплеск использования, он не будет подавлять ввод-вывод другого диска. Помните, что когда дело доходит до запросов ввода-вывода, Windows обычно обрабатывает запросы в порядке очереди с помощью дисковой очереди. Функция управления качеством обслуживания по существу резервирует позиции в дисковой очереди, когда требуются минимальные уровни дискового ввода-вывода.

Другая новая функция Windows Server 2012 R2, которая может пригодиться в подобных ситуациях, — это многоуровневое хранилище. Основная идея этой функции заключается в том, что дисковые пространства Windows позволят вам создавать виртуальные жесткие диски, которые размещают часто используемые дисковые блоки на высокоскоростном уровне хранения, состоящем из хранилища SSD. Однако уровень хранения также содержит кэш обратной записи, который используется для поглощения всплесков операций записи. Этот кэш может помочь виртуальным машинам продолжать работать хорошо даже при больших нагрузках ввода-вывода. Это может сделать более практичным использование общего пула хранения для постоянно растущего числа виртуальных машин.

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

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

Вывод

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

• Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 5)
• Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 6)