Руководство по вопросам разработки структуры виртуализации

  • Статья

 

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

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

Структура виртуализации

Рис. 1.Пример структуры виртуализации

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

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

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

Хотя этот документ и может помочь вам спроектировать управляемую структуру виртуализации, в нем не рассматриваются вопросы, связанные с эксплуатацией структуры виртуализации и управлением ею с помощью определенного продукта, такого как Microsoft System Center 2012 или System Center 2012 R2. Подробности см. в статье System Center 2012 в библиотеке TechNet.

Это руководство поможет вам спроектировать структуру виртуализации с помощью Windows Server 2012 R2 и Windows Server 2012 и оборудования, независимого от поставщика. Некоторые возможности, рассматриваемые в этом документе, уникальны для Windows Server 2012 R2, на что указывается отдельно.

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

Дополнительные ресурсы

Перед проектированием структуры виртуализации может быть полезна информация в следующих документах:

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

Отзывы: чтобы предоставить отзыв об этом документе, отправьте сообщение на адрес virtua@microsoft.com.

Обзор рекомендаций по проектированию

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

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

Шаг 1. Определение требований виртуальных машин к ресурсам

Шаг 2. Планирование конфигурации виртуальных машин

Шаг 3. Планирование групп узлов серверов виртуализации

Шаг 4. Планирование узлов серверов виртуализации

Шаг 5. Планирование особенностей архитектуры структуры виртуализации

Шаг 6. Планирование начальных характеристик

Шаг 1. Определение требований виртуальных машин к ресурсам

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

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

Примерами таких структур виртуализации могут служить структуры, предлагаемые поставщиками общедоступных облачных сред, например Microsoft Azure (Azure). Подробности см. в статье Размеры виртуальных машин и облачных служб для Azure.

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

  • Если вы решите перенести некоторые локальные виртуальные машины в общедоступное облако, то сделать это будет легче, если конфигурации этих виртуальных машин сходны с предлагаемыми поставщиком облачной среды.

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

Задача 1. Определение требований рабочих нагрузок к ресурсам

Каждая рабочая нагрузка предъявляет определенные требования к указанным ниже ресурсам. В первую очередь нужно ответить на приведенные ниже вопросы для каждой из рабочих нагрузок.

  • Процессор: Какое быстродействие, архитектура (Intel или AMD) и число процессоров требуется?

  • Сеть: Какова требуемая пропускная способность сети в гигабитах в секунду (Гбит/с) для входящего и исходящего трафика? Какова максимальная задержка сети для надлежащего выполнения рабочей нагрузки?

  • Хранилище: Сколько гигабайт (ГБ) хранилища требуется для файлов приложений и операционной системы рабочей нагрузки? Сколько ГБ хранилища требуется для данных рабочей нагрузки? Какова требуемая скорость ввода-вывода хранилища (в операциях в секунду) для рабочей нагрузки?

  • Память: Какой объем памяти в гигабайтах (ГБ) требуется рабочей нагрузке? Поддерживает ли рабочая нагрузка архитектуру NUMA?

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

  • Являются ли требования к ресурсам минимальными или рекомендуемыми?

  • Каковы пиковые и средние требования к каждому из компонентов оборудования (из расчета в час, день, неделю, месяц и год)?

  • Какова допустимая длительность простоя в месяц (в минутах) для рабочей нагрузки и ее данных. При ее определении примите во внимание указанные ниже факторы.

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

    • Рабочие и нерабочие часы. Например, если никто не будет использовать рабочую нагрузку в период с 21:00 до 6:00, но с 6:00 до 21:00 она должна быть максимально доступна и допустимое время простоя в этот период не должно превышать десяти минут в месяц, это требование необходимо зафиксировать.

  • Каков допустимый объем потерь данных в случае непредвиденного сбоя виртуальной инфраструктуры? Он выражается в минутах, так как стратегии репликации виртуальных инфраструктур обычно строятся на основе временных показателей. Хотя зачастую ставится требование полного отсутствия потерь данных, учтите, что его выполнение обычно связано с высокими финансовыми затратами, а также, возможно, снижением производительности.

  • Должны ли файлы и данные рабочей нагрузки шифроваться на диске и должны ли ее данные шифроваться при передаче между виртуальными машинами и конечными пользователями.

Определить перечисленные выше требования к ресурсам можно указанными ниже способами.

Option

Преимущества

Недостатки

Оценка использования ресурсов вручную и его регистрация в журнале

Возможность составления отчетов по любым показателям

Может потребовать значительных ручных усилий

Использование набора средств Microsoft Assessment and Planning Toolkit для автоматической оценки и регистрации использования ресурсов в журнале

  • Создает различные отчеты об использовании ресурсов

  • Не требует установки агента в рабочей нагрузке

Отчеты могут содержать, а могут и не содержать всех необходимых данных

Примечание. Если вы решили определить требования к ресурсам вручную, то можете скачать таблицы к руководству по вопросам разработки структуры виртуализации и ввести данные на листе "Workload resource req." (Требования рабочих нагрузок к ресурсам). В данном руководстве приводятся ссылки на определенные листы в этом документе.

Задача 2. Определение характеристик рабочих нагрузок

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

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

  • Рабочие нагрузки с учетом состояния: записывают уникальные данные на локальный жесткий диск после первоначальной подготовки и присвоения уникальных имен компьютеров и сетевых адресов. Они также могут записывать уникальные данные в отдельное хранилище, например базу данных. Рабочие нагрузки с учетом состояния, как правило, требуют более сложных стратегий подготовки и масштабирования, чем нагрузки без учета состояния. Стратегии обеспечения высокой доступности для рабочих нагрузок с учетом состояния могут требовать общего состояния с другими виртуальными машинами. Примером рабочей нагрузки с учетом состояния является ядро СУБД SQL Server.

  • Общие с учетом состояния: рабочие нагрузки с учетом состояния, требующие некоторого общего состояния с другими виртуальными машинами. Для обеспечения высокой доступности такие рабочие нагрузки часто используют отказоустойчивую кластеризацию в Windows Server, которая требует доступа к общему хранилищу. Примером общей рабочей нагрузки с учетом состояния является Microsoft System Center Virtual Machine Manager.

  • Прочие: рабочие нагрузки, которые могут не выполняться в структуре виртуализации или выполняться неоптимальным образом. Для них характерны указанные ниже требования.

    • Доступ к физическим периферийным устройствам. Примером может быть рабочая нагрузка телефонии, которая связывается с сетевым адаптером телефонии на физическом узле.

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

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

Примечание. Вы можете определить характеристики рабочих нагрузок на листе Settings (Параметры), а затем выбрать подходящую характеристику для каждой рабочей нагрузки на листе Workload resource req. (Требования рабочих нагрузок к ресурсам).

Шаг 2. Планирование конфигурации виртуальных машин

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

Задача 1. Определение конфигурации вычислительных ресурсов

В рамках это задачи вы определите объем памяти и характеристики процессоров для каждой виртуальной машины.

Задача 1а. Определение поколения виртуальных машин

В Windows Server 2012 R2 появились виртуальные машины второго поколения. Они поддерживают оборудование и функции виртуализации, которые не поддерживаются виртуальными машинами первого поколения. Важно сразу правильно определить требования, так как после создания виртуальной машины ее тип изменить нельзя.

Виртуальные машины второго поколения предоставляют следующие новые функциональные возможности:

  • PXE-загрузка с помощью стандартного сетевого адаптера;

  • загрузка с виртуального жесткого диска SCSI;

  • загрузка с виртуального DVD-диска SCSI;

  • безопасная загрузка (включена по умолчанию);

  • поддержка встроенного ПО UEFI.

Виртуальные машины второго поколения поддерживают следующие операционные системы:

  • Windows Server 2012 R2

  • Windows Server 2012

  • 64-разрядные версии Windows 8.1.

  • 64-разрядные версии Windows 8.

  • Некоторые версии Linux. Список дистрибутивов и версий, которые поддерживают виртуальные машины второго поколения, см. в статье Виртуальные машины Linux в Hyper-V.

В таблице ниже перечислены преимущества и недостатки виртуальных машин первого и второго поколений.

Option

Преимущества

Недостатки

Поколение 1

  • Поддержка всех операционных систем, поддерживаемых Hyper-V

  • Совместимость с виртуальными машинами Azure

  • Поддержка предыдущих версий Hyper-V

Нет доступа к новым функциональным возможностям виртуальных машин

Поколение 2

  • Поддержка новых функциональных возможностей

  • Небольшое улучшение в плане скорости загрузки виртуальных машин и установки ОС

  • Использование устройств SCSI или стандартного сетевого адаптера для загрузки виртуальной машины

  • Предотвращение несанкционированного выполнения встроенного ПО, операционных систем или драйверов UEFI при включении безопасной загрузки

  • Ограниченная поддержка операционных систем

  • Несовместимость с виртуальными машинами Azure

  • Нет поддержки RemoteFX

  • Нет поддержки виртуального гибкого диска

Внимание! Виртуальные машины Linux второго поколения не поддерживают безопасную загрузку. Если вы создаете виртуальную машину и намереваетесь установить Linux, то вам необходимо отключить безопасную загрузку в параметрах виртуальной машины.

Дополнительные сведения:

Обзор виртуальных машин второго поколения

Задача 1б. Определение памяти

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

Статическая или динамическая память

Статическая память — это объем памяти, выделенный виртуальной машине. Он выделяется при запуске виртуальной машины и не изменяется в процессе ее работы. Весь объем памяти назначается виртуальной машине при запуске, а память, которая не используется виртуальной машиной, недоступна другим виртуальным машинам. Если на узле недостаточно памяти для виртуальной машины в момент ее запуска, то она не будет запущена.

Статическая память хорошо подходит для рабочих нагрузок с интенсивным использованием памяти или с собственными системами управления памятью, например SQL Server. Производительность таких рабочих нагрузок будет выше со статической памятью.

Примечание. Параметра для включения статической памяти нет. Статическая память включается, если отключен параметр динамической памяти.

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

Если при использовании статической памяти виртуальной машине выделяется 10 ГБ памяти, но она использует только 3 ГБ, то остальные 7 ГБ недоступны другим виртуальным машинам. Если для виртуальной машины включена динамическая память, то она использует только необходимый объем памяти, но не меньше заданного минимального размера ОЗУ. Это позволяет высвободить больше памяти для других виртуальных машин.

В таблице ниже перечислены преимущества и недостатки статической и динамической памяти.

Option

Преимущества

Недостатки

Статическая память

  • Виртуальным машинам постоянно доступен заданный объем памяти

  • Более высокая производительность

  • Можно использовать с виртуальной архитектурой NUMA

  • Память, которая не используется виртуальной машиной, нельзя предоставить другой виртуальной машине.

  • Виртуальные машины не запускаются, если памяти недостаточно.

Динамическая память

  • Повышение плотности виртуальных машин при бездействии или низкой нагрузке

  • Возможность выделения неиспользуемой памяти другим виртуальным машинам

  • Намеченный объем выделяемой памяти может оказаться превышен.

  • Управление выделением памяти связано с дополнительными накладными расходами.

  • Несовместимость с виртуальной архитектурой NUMA.

  • Несовместимость с рабочими нагрузками, реализующими собственные диспетчеры памяти.

Ниже перечислены параметры конфигурации памяти.

  • ОЗУ для запуска: объем памяти, необходимый для запуска виртуальной машины. Это значение должно быть достаточным для запуска операционной системы на виртуальной машине, но при этом максимально низким для оптимального использования памяти и, возможно, более высокой степени консолидации.

  • Минимальный объем ОЗУ: минимальный объем памяти, который следует выделить виртуальной машине после ее запуска. Это значение можно установить в диапазоне от 32 МБ до максимального значения параметра "ОЗУ для запуска". Этот параметр доступен, только если включена динамическая память.

  • Максимальный объем ОЗУ: максимальный объем памяти, который разрешено использовать данной виртуальной машине. Это значение можно установить в диапазоне от значения параметра "ОЗУ для запуска" до 1 ТБ. Однако виртуальная машина не может использовать больше памяти, чем поддерживается ее операционной системой. Например, если вы зададите 64 ГБ для виртуальной машины, в которой выполняется операционная система, поддерживающая максимум 32 ГБ, то виртуальная машина не сможет использовать более 32 ГБ. Этот параметр доступен, только если включена динамическая память.

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

Примечания.

  • Динамическую память и виртуальную архитектуру NUMA нельзя использовать одновременно. Виртуальная машина, для которой включена динамическая память, имеет только один виртуальный узел NUMA и ей не предоставляется топология NUMA вне зависимости от параметров виртуальной архитектуры NUMA.

  • Во время установки или обновления операционной системы виртуальной машины ей доступен объем памяти, определяемый параметром "ОЗУ для запуска". Даже если для виртуальной машины настроена динамическая память, она использует только тот объем памяти, который указан в параметре "ОЗУ для запуска". Убедитесь в том, что значение "ОЗУ для запуска" соответствует требованиям к минимальному размеру памяти для операционной системы во время процедур установки или обновления.

  • Операционная система, выполняющаяся в виртуальной машине, должна поддерживать динамическую память.

  • Сложные приложения баз данных, например SQL Server или Exchange Server, реализуют собственные диспетчеры памяти. Чтобы определить, совместима ли рабочая нагрузка с динамической памятью, обратитесь к документации по ней.

Дополнительные сведения:

Обзор динамической памяти

Задача 1в. Определение характеристик процессоров

Для настройки виртуальных машин необходимо определить указанные ниже параметры конфигурации.

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

  • Примите решение в отношении контроля ресурсов для каждой виртуальной машины. Установив пределы, можно гарантировать, что ни одна виртуальная машина не сможет монополизировать процессорные ресурсы узла виртуализации.

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

Примечание. Виртуальную архитектуру NUMA и динамическую память нельзя использовать одновременно. Если вы пытаетесь решить, следует ли использовать динамическую память или NUMA, ответьте на приведенные ниже вопросы. Если ответ на оба из них утвердительный, то включите виртуальную архитектуру NUMA и не включайте динамическую память.

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

  2. Будет ли виртуальная машина потреблять больше ресурсов, процессоров или памяти, чем доступно в одном физическом узле NUMA?

Задача 1г. Определение поддерживаемых операционных систем

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

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

Лицензирование

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

В Windows Server 2012 R2 появилась функция автоматической активации виртуальной машины (AVMA). Она привязывает активацию виртуальной машины к лицензированному серверу виртуализации и активирует виртуальную машину при запуске. Это избавляет от необходимости вводить сведения о лицензии и активировать каждую виртуальную машину по отдельности.

Для использования AVMA необходимо, чтобы узел работал под управлением Windows Server 2012 R2 Datacenter, а в виртуальной машине была установлена ОС Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Standard или Windows Server 2012 R2 Essentials.

Примечание. Функцию AVMA нужно настроить на каждом узле, развернутом в структуре виртуализации.

Дополнительные сведения:

Автоматическая активация виртуальной машины

Задача 1д. Определение соглашения об именовании виртуальных машин

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

Задача 2. Определение конфигурации сети

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

Виртуальные машины первого поколения могут иметь не более 12 сетевых адаптеров — 4 традиционных и 8 виртуальных. Виртуальные машины второго поколения не поддерживают традиционные сетевые адаптеры, поэтому максимальное число адаптеров равно 8.

Задача 2а. Определение типов сетевого трафика

Каждая виртуальная машина будет отправлять и получать различные типы данных, например:

  • данные приложений;

  • резервные копии данных;

  • данные взаимодействия с клиентскими компьютерами, серверами или службами;

  • данные взаимодействия внутри кластера, если рабочая нагрузка входит в отказоустойчивый кластер гостевых виртуальных машин;

  • Поддержка

  • Хранилище

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

Задача 2б. Определение производительности для сетевого трафика

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

Стратегия

Преимущества

Недостатки

Разделение типов трафика по физическим сетевым адаптерам

Каждый адаптер используется только для определенного типа трафика

  • Для каждого типа сетевого трафика на узле необходимо установить отдельный физический сетевой адаптер.

  • Для каждой сети, требующей высокой доступности, необходимо дополнительное оборудование.

  • Плохая масштабируемость при большом количестве сетей.

Управление пропускной способностью Hyper-V (качество обслуживания Hyper-V)

  • Обеспечивает качество обслуживания для трафика в виртуальных сетях

  • Устанавливает минимальную и максимальную пропускную способность для потока трафика, который определяется номером порта виртуального коммутатора Hyper-V.

  • Возможность настройки минимальной и максимальной пропускной способности для каждого порта виртуального коммутатора Hyper-V с помощью командлетов PowerShell или инструментария управления Windows (WMI).

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

  • Дополняет политику качества обслуживания для физической сети.

  • Программное и аппаратное качество обслуживания не следует использовать одновременно в одном сетевом адаптере.

  • Необходимо тщательно спланировать политики качества обслуживания для сети и Hyper-V, чтобы они не переопределяли друг друга.

  • После установки режима качества обслуживания для виртуального коммутатора изменить его нельзя.

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

  • Перенос блокируется, если абсолютные значения, настроенные для виртуальной машины, не соблюдаются.

SR-IOV

  • Обеспечивает самую низкую задержку сети для виртуальной машины

  • Обеспечивает самую высокую скорость сетевых операций ввода-вывода для виртуальной машины

  • Уменьшает потребность в ресурсах ЦП для виртуальных сетей

  • В узле и каждой виртуальной машине, которой назначена виртуальная функция, требуется сетевой адаптер с поддержкой SR-IOV и соответствующий драйвер.

  • Виртуальные сетевые адаптеры с поддержкой SR-IOV не могут входить в группу сетевых карт узла.

  • Для обеспечения высокой доступности сети в узле необходимо установить два или несколько сетевых адаптеров SR-IOV, а в виртуальной машине необходимо настроить объединение сетевых карт.

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

  • Настройка списков управления доступом для порта виртуального коммутатора, а также настройка качества обслуживания Hyper-V, охранника маршрутизаторов и охранника DHCP предотвращает использование SR-IOV.

  • SR-IOV не поддерживается для виртуальных машин, выполняющихся в Azure.

Виртуальное масштабирование на стороне приема

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

  • Совместимость со следующими функциями:

    • объединение сетевых карт.

    • Динамическая миграция

    • NVGRE

  • Для виртуального масштабирования на стороне приема необходимо, чтобы физический сетевой адаптер поддерживал очередь виртуальной машины (VMQ), которая должна быть включена на узле.

  • Несовместимо с виртуальным сетевым адаптером с поддержкой SR-IOV.

  • Виртуальные машины должны работать под управлением Windows Server 2012 R2 или Windows 8.1.

  • По умолчанию отключено, если адаптер VMQ имеет пропускную способность менее 10 Гбит/с.

Кадры крупного размера

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

  • Обычно используются при обмене данными с хранилищем, но могут использоваться при любом обмене данными.

  • Сокращают накладные расходы в виртуальных машинах, сетевом оборудовании и и на конечном сервере, на который отправляются данные.

  • Настроены для обмена данными в центре обработки данных, где вы можете контролировать параметры максимального передаваемого блока данных (MTU) для любых переходов.

  • Немного снижают вероятность обнаружения ошибок.

  • Каждое сетевое устройство, входящее в путь, должно поддерживать кадры крупного размера, и для него должно быть настроено то же или более высокое значение MTU. Для сквозной проверки значений MTU используйте команду Ping.

  • Если один из переходов не поддерживает кадры крупного размера или имеет меньшее значение MTU, пакеты будут теряться.

Задача 2в. Определение доступности для сетевого трафика

Объединение сетевых карт, известное также под названием балансировки нагрузки и обеспечения отказоустойчивости (LBFO), позволяет группировать несколько сетевых адаптеров в целях агрегирования пропускной способности и обеспечения отказоустойчивости при передаче трафика. Это позволяет избежать потери связи при отказе сетевого компонента. Объединение сетевых карт обычно настраивается на узле. При создании виртуального коммутатора он привязывается к группе сетевых адаптеров.

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

Примечание. Технология SR-IOV несовместима с объединением сетевых карт. Подробности об SR-IOV см. в разделе Задача 2б. Определение производительности для сетевого трафика.

Дополнительные сведения:

Обзор объединения сетевых карт

Задача 2г. Определение параметров безопасности для сетевого трафика

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

Стратегия

Преимущества

Недостатки

Разделение по сетевым адаптерам

Отделение трафика определенного типа от трафика других типов

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

IPsec с разгрузкой задач IPsec

  • Поддержка разгрузки IPsec для шифрования сетевого трафика, отправляемого на виртуальные машины на основе Hyper-V и получаемого от них

  • Шифрование трафика во время передачи через сеть

  • Сложность настройки

  • Устранение неполадок может усложниться, так как трафик, отправляемый на узлы и в виртуальные машины и получаемый от них, нельзя открыть

  • Повышение загрузки процессоров, если физические сетевые адаптеры в узле не поддерживают разгрузку IPsec

Разметка виртуальной ЛС

  • Число виртуальных ЛС ограничено 4094

  • Коммутаторы, узлы и виртуальные машины требуют настройки

  • Неправильные изменения параметров конфигурации виртуальных ЛС могут привести к проблемам сети на уровне отдельных серверов или всей системы

Виртуализация сети Hyper-V

  • Обеспечивает гибкое размещение рабочих нагрузок, включая изоляцию сети и повторное использование IP-адресов без виртуальных ЛС.

  • Упрощает перенос рабочих нагрузок в облако.

  • Поддерживает динамическую миграцию между подсетями без необходимости добавления нового IP-адреса на новом сервере.

  • Обеспечивает мультитенантные решения сетевого взаимодействия.

  • Упрощает проектирование сетей и оптимизирует использование ресурсов серверов и сетей. Недостаточная гибкость виртуальных ЛС, в которых размещение виртуальных машин зависит от инфраструктуры физической сети, обычно приводит к избыточному выделению ресурсов и недостаточной степени их использования.

  • Для управления виртуализацией сети Hyper-V требуется System Center 2012 R2 Virtual Machine Manager или стороннее решение.

  • Для обеспечения обмена данными за пределами виртуальной сети требуется шлюз виртуализации сети Hyper-V.

Охранник DHCP

  • Блокирует отправку предложений DHCP виртуальной машиной по виртуальной сети.

  • Настраивается для каждого виртуального сетевого адаптера.

  • Не запрещает получение адреса от DHCP-сервера виртуальной машиной.

Минимальное влияние на производительность.

Охранник маршрутизаторов

  • Блокирует следующие пакеты:

    • ICMPv4 тип 5 (сообщение перенаправления);

    • ICMPv4 тип 9 (объявление маршрутизатора);

    • ICMPv6 тип 134 (объявление маршрутизатора);

    • ICMPv6 тип 137 (сообщение перенаправления).

  • Настраивается для каждого виртуального сетевого адаптера.

Минимальное влияние на производительность.

Проектное решение — вы можете скачать таблицы к руководству по вопросам разработки структуры виртуализации и изменить приведенные для примера данные на листе "Virtual machine configs." (Конфигурации виртуальных машин), чтобы зафиксировать решения, принятые при выполнении всех предыдущих задач этого шага. При принятии дальнейших проектных решений введите данные на других листах, на которые приводятся ссылки в этом руководстве.

Задача 2д. Определение виртуальных сетевых адаптеров

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

Виртуальный сетевой адаптер подключается к виртуальному коммутатору. Существует три типа виртуальных коммутаторов:

  • внешний виртуальный коммутатор;

  • внутренний виртуальный коммутатор;

  • частный виртуальный коммутатор.

Внешний виртуальный коммутатор предоставляет виртуальной машине доступ к физической сети через сетевой адаптер, связанный с виртуальным коммутатором, к которому он подключен. Физический сетевой адаптер на узле можно связать только с одним внешним коммутатором.

Виртуальные машины первого поколения могут иметь не более 12 сетевых адаптеров — 4 традиционных и 8 виртуальных. Виртуальные машины второго поколения не поддерживают традиционные сетевые адаптеры, поэтому максимальное поддерживаемое число адаптеров равно 8. Виртуальному сетевому адаптеру может быть назначен один идентификатор виртуальной ЛС, если только для него не настроен магистральный режим.

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

Примечание. Если виртуальной машине требуется доступ к сетям, число которых превышает число доступных адаптеров, вы можете включить магистральный режим виртуальной ЛС для сетевого адаптера виртуальной машины с помощью командлета Windows PowerShell Set-VMNetworkAdapterVlan.

Задача 2е. Определение стратегии назначения IP-адресов

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

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

Дополнительные сведения:

Обзор протокола DHCP

Охранник DHCP

Общие сведения об управлении IP-адресами (IPAM)

Задача 3. Определение конфигурации хранилища

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

Задача 3а. Определение типов данных

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

Тип данных

Место хранения данных

Файлы операционной системы

В файле виртуального жесткого диска, который сохраняется в узле виртуализации. Вопросы, касающиеся хранения узла виртуализации, рассматриваются далее в разделе "Шаг 4. Планирование узлов серверов виртуализации" ниже.

Файл подкачки Windows

Часто хранится в том же месте, что и файлы операционной системы.

Программные файлы приложений

Часто хранится в том же месте, что и файлы операционной системы.

Данные конфигурации приложений

Часто хранится в том же месте, что и файлы операционной системы.

Данные приложений

Часто хранятся отдельно от файлов приложений и операционной системы. Например, в случае с приложением базы данных файлы базы данных часто хранятся в эффективном сетевом хранилище с высокой доступностью отдельно от места хранения файлов ОС и приложений.

Кластерные общие тома (CSV) и диск-свидетель (необходимый для кластеризации гостевых виртуальных машин)

Часто хранятся отдельно от файлов приложений и операционной системы.

  • Кластеризованные приложения сохраняют данные в хранилище CSV, где они доступны всем узлам кластера.

  • Диск-свидетель — это диск в системе хранения данных кластера, который предназначен для хранения копии базы данных конфигурации кластера. Отказоустойчивый кластер имеет диск-свидетель, только если он настроен в конфигурации кворума.

Файлы аварийного дампа

Часто хранятся в том же месте, что и файлы операционной системы.

Задача 3б. Определение типов хранилищ

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

Тип хранилища

Особенности

Виртуальный диск IDE

Виртуальные машины первого поколения:

  • 2 контроллера IDE, каждый из которых поддерживает до 2 устройств IDE (всего 4 устройства IDE);

  • загрузочный диск должен быть подключен к одному из устройств IDE как виртуальный жесткий диск или физический диск.

Виртуальные машины второго поколения не поддерживают устройства IDE.

Виртуальный диск SCSI

  • Поддерживаются 4 виртуальных контроллера SCSI, каждый из которых поддерживает до 64 устройств (всего поддерживается 256 устройств SCSI).

  • Так как виртуальные машины второго поколения поддерживают только диски SCSI, они поддерживают загрузочные диски SCSI.

Инициатор iSCSI в виртуальной машине

  • Воспользуйтесь преимуществами хранилища на основе сетей SAN, не устанавливая адаптеры Fibre Channel на узле.

  • Нельзя использовать для загрузочного диска.

  • Используйте политики качества обслуживания в сети для обеспечения надлежащей пропускной способности для хранилища и другого сетевого трафика.

  • Несовместим с репликой Hyper-V. При использовании внутреннего сервера хранилища SAN используйте параметры репликации SAN, предоставленные поставщиком хранилища.

Виртуальный адаптер Fibre Channel

  • Требует одного или нескольких адаптеров шины Fibre Channel или конвергентных сетевых адаптеров Fibre Channel over Ethernet (FCoE) на каждом узле, на котором будут размещаться виртуальные машины с виртуальными адаптерами Fibre Channel.

  • Драйверы адаптеров шины и FCoE должны поддерживать виртуальные адаптеры Fibre Channel.

  • Сеть SAN с поддержкой NPIV.

  • Для поддержки динамической миграции требуется дополнительная настройка. Подробности о динамической миграции и виртуальном адаптере Fibre Channel см. в статье Обзор виртуального адаптера Fibre Channel для Hyper-V.

  • Несовместим с репликой Hyper-V. При использовании хранилища SAN применяйте параметры репликации SAN, предоставленные поставщиком хранилища.

  • Виртуальная машина может иметь до четырех виртуальных портов.

  • Номера LUN виртуальных адаптеров Fibre Channel нельзя использовать в качестве загрузочного носителя для виртуальной машины.

SMB 3.0

Доступ к файлам, хранящимся в общих ресурсах Server Message Block (SMB) 3.0, из виртуальной машины.

Задача 3в. Определение формата и типа виртуального жесткого диска

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

Формат диска

Преимущества

Недостатки

VHD

  • Поддерживается всеми версиями Hyper-V

  • Поддерживается локальными средами и Azure

  • Максимальная емкость хранения составляет 2 040 ГБ.

  • Максимальный размер виртуального жесткого диска, поддерживаемый Azure, составляет 1 ТБ.

  • Не поддерживается виртуальными машинами второго поколения.

VHDX

  • Максимальная емкость хранения составляет 64 терабайта (ТБ).

  • Защита от повреждения данных при сбое питания.

  • Улучшенное выравнивание формата виртуального жесткого диска и хорошая производительность на дисках с большими секторами.

  • Виртуальный диск с логическими секторами размером 4 КБ, обеспечивающий более высокую производительность при использовании приложениями и рабочими нагрузками, рассчитанными на такие секторы.

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

  • В настоящее время не поддерживается виртуальными машинами Azure.

  • Нельзя использовать с версиями Hyper-V, более ранними чем Windows Server 2012.

Общий диск VHDX

Используется в качестве общего хранилища для кластеров гостевых виртуальных машин.

  • На узле Hyper-V требуется ОС Windows Server 2012 R2.

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

  • Следующие функции и компоненты несовместимы с общим диском VHDX:

    • реплика Hyper-V;

    • изменение размера виртуального жесткого диска в то время, как выполняется хотя бы одна из настроенных виртуальных машин;

    • Динамическая миграция хранилища

    • резервное копирование VSS на уровне узла; резервное копирование на уровне гостя следует выполнять теми же способами, которые вы использовали бы для кластера, выполняющегося на физических серверах;

    • контрольные точки виртуальной машины;

    • качество обслуживания хранилища.

Далее выберите тип диска из списка вариантов, приведенных в таблице ниже.

Тип диска

Преимущества

Недостатки

Фиксированный

  • Менее подвержен фрагментации, чем диски других типов.

  • Более низкая загрузка ЦП по сравнению с дисками других типов.

  • После создания VHD-файла можно меньше беспокоиться о доступном месте на диске, чем при использовании дисков других типов.

  • Поддерживается локальными средами и Azure

  • При создании виртуального жесткого диска должно быть доступно все пространство, даже если виртуальная машина не использует его полностью.

  • Если пространства недостаточно, создать виртуальный жесткий диск не удастся.

  • Неиспользуемое пространство виртуального жесткого диска нельзя предоставить другим виртуальным жестким дискам.

Динамический

Используется не все предоставленное пространство, а лишь необходимое.

  • В настоящее время не поддерживается Azure, хотя динамические диски можно преобразовать в фиксированные.

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

  • Файл виртуального жесткого диска подвержен фрагментации.

  • Загрузка ЦП при выполнении операций чтения и записи немного выше, чем при использовании фиксированного диска.

Разностный

Используемое место на диске может быть меньше, если несколько разностных дисков имеют один родительский.

  • В настоящее время не поддерживается Azure.

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

  • Немного более высокая загрузка ЦП при выполнении операций чтения и записи для рабочих нагрузок с высокой интенсивностью ввода-вывода.

При выборе типа и формата виртуального жесткого диска примите во внимание указанные ниже факторы.

  • С форматом VHDX можно использовать динамический диск, так как он обеспечивает устойчивость и экономию места благодаря выделению пространства только при необходимости.

  • Фиксированный диск можно использовать вне зависимости от формата, если активный мониторинг хранилища на томе размещения не ведется. Таким образом обеспечивается наличие достаточного места при расширении файла VHD во время выполнения.

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

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

Задача 3г. Определение типа хранилища для каждого типа данных

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

Задача 4. Определение стратегии доступности виртуальных машин

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

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

  • Без учета состояния

  • С учетом состояния

  • Общий доступ с учетом состояния

Без учета состояния

Option

Особенности

Динамическая миграция виртуальных машин на уровне узла

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

  • Если хранилище виртуальных машин недоступно для одного из узлов, во время динамической миграции его необходимо перенести.

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

Кластеры с балансировкой нагрузки (на основе балансировки сетевой нагрузки Windows)

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

  • Балансировка сетевой нагрузки (NLB) настраивается в виртуальных машинах администратором виртуальных машин.

  • Для балансировки сетевой нагрузки требуется назначить сетевым адаптерам статические IP-адреса. Назначение адресов с помощью DHCP не поддерживается.

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

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

  • Все виртуальные машины, входящие в кластер NLB, должны относиться к одной подсети.

  • Чтобы обеспечить доступность рабочей нагрузки (даже в случае сбоя узла), администратор структуры виртуальных машин должен сделать так, чтобы виртуальные машины выполнялись на разных узлах.

Кластеры с балансировкой нагрузки (на основе устройства балансировки нагрузки)

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

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

  • Дополнительную информацию можно найти в документации к устройству, предоставленной его поставщиком.

С учетом состояния

Option

Особенности

Кластер Hyper-V

  • Требует настройки отказоустойчивого кластера.

  • У всех узлов кластера должно быть общее хранилище файлов CSV. Это может быть хранилище SAN или общий файловый ресурс SMB 3.0.

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

  • В случае неустранимого сбоя узла выполнявшиеся на нем виртуальные машины можно запустить на других узлах кластера. Можно настроить автоматический запуск критически важных виртуальных машин. Это позволит сократить длительность простоя при неустранимом сбое узла.

  • Кластерное обновление позволяет применять исправления к узлам, не прерывая работу виртуальных машин.

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

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

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

Общий доступ с учетом состояния

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

Option

Особенности

Кластеризация гостевых систем виртуальных машин

  • Требуется общее хранилище, доступное двум или нескольким виртуальным машинам одновременно. Поддерживаемые типы подключений:

    • iSCSI

    • виртуальный адаптер Fibre Channel;

    • общий диск VHDX.

  • Настройте запрет близости виртуальных машин, чтобы предотвратить выполнение обеих виртуальных машин на одном узле кластера.

  • Кластеризация гостевых систем виртуальных машин не поддерживается Azure.

  • Следующие функции и компоненты несовместимы с общим диском VHDX:

    • реплика Hyper-V;

    • изменение размера виртуального жесткого диска в то время, как выполняется хотя бы одна из настроенных виртуальных машин;

    • Динамическая миграция хранилища

    • резервное копирование VSS на уровне узла; резервное копирование на уровне гостя следует выполнять теми же способами, которые вы использовали бы для кластера, выполняющегося на физических серверах;

    • контрольные точки виртуальной машины;

    • качество обслуживания хранилища.

Дополнительные сведения:

Развертывание гостевого кластера с помощью общего виртуального жесткого диска

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

Аварийное восстановление

Как быстро в случае аварии вы можете восстановить выполнение рабочих нагрузок и обслуживание клиентов? В ряде случаев это необходимо сделать всего за несколько минут.

Для обеспечения репликации актуальных данных с допустимым уровнем потерь вследствие задержек требуется репликация из главных центров обработки данных в центры аварийного восстановления. Благодаря выполнению рабочих нагрузок в виртуальных машинах можно реплицировать виртуальные жесткие диски и файлы конфигурации виртуальных машин с основного сайта на сайт реплики.

В таблице ниже сравниваются различные варианты аварийного восстановления.

Option

Особенности

Реплика Hyper-V

  • Низкая стоимость; не нужно дублировать оборудование узлов и хранилища на сайтах аварийного восстановления.

  • Для управления репликацией и виртуальными машинами используются одни и те же средства.

  • Интервалы репликации настраиваются в соответствии с требованиями к потере данных.

  • Для сайта реплики можно настроить другие IP-адреса.

  • Минимальное воздействие на сетевую инфраструктуру.

  • Не поддерживается для виртуальных машин, для которых настроены физические диски (также называемые транзитными), виртуальное хранилище Fibre Channel или общие виртуальные жесткие диски.

  • Реплику Hyper-V не следует использовать в качестве замены хранилищу резервных копий данных и системе извлечения данных.

  • При настройке дополнительных точек восстановления на сайте реплики потребуется увеличить хранилище.

  • Объем потерь данных определяется интервалом репликации.

  • Если для виртуальной машины с частыми изменениями настраивается короткий интервал репликации, на сайте реплики требуется больший объем хранилища.

Резервное копирование

  • Для полного резервного копирования виртуальной машины используйте решение, поддерживаемое Hyper-V, например System Center Data Protection Manager.

  • Потери данных зависят от возраста последней резервной копии.

  • Резервное копирование виртуальных машин, для которых настроен общий файл VHDX, нельзя выполнять на уровне узла. Установите агент резервного копирования в виртуальной машине и выполняйте резервное копирование данных из нее.

Примечания.

  • Для централизованного управления репликацией и ее автоматизации при использовании System Center 2012 R2 Virtual Machine Manager необходимо применять службу Microsoft Azure Site Recovery.

  • Для репликации виртуальных машин в Azure используйте службу Microsoft Azure Site Recovery. Функция репликации виртуальных машин в Azure в настоящее время находится в режиме предварительной версии.

Дополнительные сведения:

Microsoft Azure Site Recovery

Внимание!

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

  • Рабочая нагрузка может иметь встроенное решение для аварийного восстановления, например группы доступности AlwaysOn в SQL Server. Чтобы проверить, поддерживается ли реплика Hyper-V рабочей нагрузкой, обратитесь к документации по рабочей нагрузке.

Дополнительные сведения:

Реплика Hyper-V

System Center Data Protection Manager

Задача 5. Определение типов виртуальных машин

Для поддержки рабочих нагрузок в среде можно создать виртуальные машины с уникальными требованиями к ресурсам. Аналогичный подход можно применить в отношении поставщиков общедоступных служб размещения виртуальных машин (также называемых поставщиками инфраструктуры как услуги (IaaS)).

Описание конфигураций виртуальных машин, предлагаемых службами инфраструктуры Microsoft Azure, можно найти в статье Размеры виртуальных машин и облачных служб для Azure. На момент написания настоящего документа служба поддерживала 13 конфигураций виртуальных машин, каждая из которых характеризуется особым сочетанием процессоров, памяти, хранилища и показателей скорости ввода-вывода.

Проектное решение — решения, принимаемые при выполнении различных задач этого этапа, можно вводить на листе "Virtual machine configs" (Конфигурации виртуальных машин).

Шаг 3. Планирование групп узлов серверов виртуализации

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

Задача 1. Определение физических расположений

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

Задача 2. Определение типов групп узлов

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

  • характеристики рабочих нагрузок;

  • требования к ресурсам;

  • требования к качеству обслуживания.

На рисунке ниже показана организация, в которой созданы пять групп узлов в двух расположениях.

Группа узлов

Рис. 2.Пример групп узлов

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

Группа узлов

Причины создания

Рабочая нагрузка без учета и с учетом состояния

  • Эти характеристики рабочих нагрузок наиболее распространены в организации, поэтому этот тип групп узлов имеется в обоих расположениях.

  • Эти рабочие нагрузки имеют схожие требования к производительности и уровню обслуживания.

Рабочие нагрузки с учетом и без учета состояния в бухгалтерском отделе

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

Общие рабочие группы с учетом состояния

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

Рабочие нагрузки с учетом состояния и интенсивным вводом-выводом

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

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

Совет. Чем более стандартизированным является оборудование серверов в пределах группы узлов, тем легче будет масштабировать и обслуживать группу в будущем. Если вы решили стандартизировать оборудование в пределах группы узлов, вы можете добавить описание стандартной конфигурации на листе "Host groups" (Группы узлов) в таблицах к руководству по вопросам разработки структуры виртуализации. Подробности о вопросах, связанных с физическим оборудованием, см в разделе Шаг 4. Планирование узлов серверов виртуализации.

Имейте в виду, что в настоящее время большинство поставщиков общедоступных облачных сред, размещающих виртуальные машины:

  • размещают только виртуальные машины, не требующие общего состояния;

  • часто предлагают всем клиентам только один набор показателей качества обслуживания;

  • не предлагают клиентам выделенное оборудование.

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

Задача 3. Определение необходимости в кластеризации членов группы узлов

В прошлом отказоустойчивая кластеризация в Windows Server использовалась только для повышения доступности серверов, однако в дальнейшем ее функциональные возможности значительно расширились. Информация, приведенная в таблице ниже, поможет вам решить, требуется ли кластеризовать члены группы узлов.

Option

Преимущества

Недостатки

Члены группы узлов входят в отказоустойчивый кластер

  • В случае сбоя узла размещенные в нем виртуальные машины автоматически запускаются на сохранивших работоспособность узлах.

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

  • Кластерное обновление позволяет легко обновлять узлы кластера, не прерывая работу виртуальных машин.

  • Для включения в кластер узлы требуют особой настройки.

  • Узлы должны входить в домен Active Directory.

  • Отказоустойчивая кластеризация предъявляет дополнительные требования к сетевым возможностям и хранилищу.

Члены группы узлов не входят в отказоустойчивый кластер

  • Узлы не требуют особой настройки, связанной с включением в кластер.

  • Узлы не должны входить в домен Active Directory.

  • Дополнительные сетевые возможности и хранилище не требуются.

При сбое узла выполнявшиеся на нем виртуальные машины необходимо вручную (или с помощью каких-либо средств автоматизации) перенести в сохранивший работоспособность узел и перезапустить.

Проектное решение — решения, принимаемые при выполнении различных задач этого этапа, можно вводить на листе "Settings" (Параметры).

Шаг 4. Планирование узлов серверов виртуализации

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

Cloud Platform System

Корпорация Майкрософт воплощает все свои знания и опыт эксплуатации нескольких крупнейших центов обработки данных и облачных служб в интегрированной и полностью проверенной конвергированной системе. Система Cloud Platform System (CPS) сочетает в себе набор признанного программного обеспечения Майкрософт — Windows Server 2012 R2, System Center 2012 R2 и Пакет Windows Azure — и оборудование Dell для серверов, хранилища и сетевой инфраструктуры облака. Представляя собой масштабируемую основу вашего облака, CPS сокращает время разработки и вывода на рынок, а также обеспечивает согласованную процедуру работы с облаком.

CPS предоставляет мультитенантную облачную среду на основе самообслуживания для решений типа "платформа как услуга" и виртуальных машин Windows и Linux, а также включает в себя оптимизированные пакеты развертывания для приложений Майкрософт, таких как SQL Server, SharePoint и Exchange. Встроенная интеграция уменьшает риск и уровень сложности, а также сокращает длительность развертывания с нескольких месяцев до нескольких дней. Упрощенный процесс поддержки и автоматизация типичных задач, связанных с инфраструктурой, также помогают высвободить ИТ-ресурсы и сконцентрироваться на инновациях.

Подробности см. на сайте Cloud Platform System.

Fast Track

Вместо разработки собственной конфигурации оборудования (и программного обеспечения) вы можете приобрести готовые конфигурации от различных партнеров по программе Microsoft Private Cloud Fast Track.

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

Программа Fast Track предлагает клиентам гибкие и разнообразные решения на базе технологий партнеров-поставщиков оборудования. Она предполагает использование базовых возможностей операционной системы Windows Server, технологии Hyper-V и Microsoft System Center для предоставления стандартных блоков, с помощью которых можно создавать инфраструктуру частного облака, предлагаемую в виде услуги.

Дополнительные сведения:

Сайт Microsoft Private Cloud Fast Track

Задача 1. Определение конфигурации вычислительных ресурсов

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

Примечание. Для обеспечения полной поддержки решения все приобретаемое оборудование должно иметь эмблему "Certified for Windows Server" для используемой версии Windows Server.

Эмблема "Certified for Windows Server" свидетельствует о том, что серверная система отвечает высочайшим техническим требованиям Майкрософт к безопасности, надежности и управляемости. В сочетании с другими сертифицированными устройствами и драйверами она поддерживает роли, компоненты и интерфейсы для облачных и корпоративных рабочих нагрузок, а также критически важных бизнес-приложений.

Новейший список оборудования с эмблемой "Certified for Windows Server" можно найти в каталоге Windows Server.

Задача 1а. Определение характеристик процессоров

Hyper-V предоставляет логические процессоры каждой активной виртуальной машине в виде одного или нескольких виртуальных процессоров. Повысить эффективность выполнения можно с помощью процессоров, поддерживающих технологии преобразования адресов второго уровня (SLAT), такие как EPT или NPT. Hyper-V в Windows Server 2012 R2 поддерживает до 320 логических процессоров.

Замечания:

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

  • Рабочим нагрузкам, интенсивно использующим ЦП, следует назначить два или более виртуальных процессора. Виртуальной машине можно назначить до 64 виртуальных процессоров. Число виртуальных процессоров, распознаваемое виртуальной машиной, зависит от ее операционной системы. Например, ОС Windows Server 2008 с пакетом обновления 2 (SP2) распознает только четыре виртуальных процессора.

Дополнительные сведения:

Обзор Hyper-V

Настройка производительности серверов Hyper-V

Задача 1б. Определение памяти

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

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

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

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

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

Подробности о динамической памяти см. в разделе Задача 1б. Определение памяти, в котором описывается, как определить память для виртуальной машины.

Дополнительные сведения:

Обзор динамической памяти

Обзор виртуальной архитектуры NUMA

Задача 1в. Определение выпуска операционной системы Windows Server

Наборы функций в Windows Server Standard и Windows Server Datacenter абсолютно одинаковы. Windows Server Datacenter предоставляет неограниченное количество виртуальных машин. В Windows Server Standard число виртуальных машин ограничено двумя.

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

Для использования AVMA необходимо, чтобы операционной системой на виртуальной машине была Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Standard или Windows Server 2012 R2 Essentials. В таблице ниже сравниваются выпуски ОС.

Выпуск

Преимущества

Недостатки

Standard

  • Включает в себя все функции Windows Server.

  • Подходит для сред без виртуализации или со слабой виртуализацией.

Число виртуальных машин ограничено двумя.

Datacenter

  • Включает в себя все функции Windows Server.

  • Число виртуальных машин не ограничено.

  • Подходит для частных облачных сред с высоким уровнем виртуализации.

Выше стоимость.

Hyper-V можно установить, выбрав вариант "Установка основных серверных компонентов" в Windows Server. Этот вариант сокращает требования к свободному пространству на диске, уменьшает поле для потенциальных атак и, самое главное, снижает требования к обслуживанию. При его выборе управление сервером осуществляется с помощью командной строки, Windows PowerShell или удаленными методами.

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

Microsoft Hyper-V Server

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

Решение Hyper-V Server может быть интегрировано в существующую ИТ-среду клиента с использованием имеющихся процессов подготовки и управления, а также средств поддержки. Оно поддерживает те же возможности оборудования, что и соответствующие выпуски Windows Server, и полностью интегрируется с технологиями Microsoft System Center и Windows, такими как Центр обновления Windows, Active Directory и отказоустойчивая кластеризация.

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

Дополнительные сведения:

Автоматическая активация виртуальных машин

Microsoft Hyper-V Server

Удаленное управление Hyper-V Server

Задача 2. Определение конфигурации сети

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

  • обеспечения качества обслуживания сети;

  • обеспечение избыточности сети;

  • изоляция трафика между сетями.

Задача 2а. Определение типов сетевого трафика

При развертывании кластера Hyper-V необходимо спланировать несколько типов сетевого трафика. В таблице ниже приводятся общие сведения о них.

Тип трафика

Описание

Управление

  • Обеспечивает взаимодействие между сервером Hyper-V и основными функциями инфраструктуры.

  • Служит для управления операционной системой сервера ВМ и виртуальными машинами Hyper-V.

Кластер и общие тома кластера

  • Служит для взаимодействия между узлами кластера, например подтверждения соединения кластера и перенаправления между общими томами кластера (CSV).

  • Используется, только если технология Hyper-V развернута с применением отказоустойчивой кластеризации.

Динамическая миграция

Используется для динамической миграции виртуальных машин и динамической миграции без общих ресурсов.

Хранилище

Используется для трафика SMB или iSCSI.

Реплика

Используется для передачи трафика репликации виртуальных машин с помощью реплики Hyper-V.

Трафик виртуальной машины (клиента)

  • Используется для подключения виртуальной машины.

  • Обычно требует подключения к внешней сети для обслуживания клиентских запросов.

Примечание. Список типов трафика виртуальных машин см. в разделе Шаг 2. Планирование конфигурации виртуальных машин.

Резервное копирование

Используется для резервного копирования файлов виртуальных жестких дисков.

Задача 2б. Определение производительности для сетевого трафика

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

Качество обслуживания на основе политик

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

Сетевое оборудование становится быстрее. Не так давно передовыми считались сетевые адаптеры со скоростью 1 Гбит/с. Сейчас на серверах все чаще встречаются адаптеры со скоростью 10 Гбит/с, а цены на поддержку инфраструктуры с такой скоростью становятся все более доступными.

Два объединенных сетевых адаптера со скоростью 10 Гбит/с обеспечивают большую пропускную способность, чем два счетверенных адаптера со скоростью 1 Гбит/с. Кроме того они занимают меньше портов коммутатора и упрощают кабельное подключение. В условиях, когда объединенные сетевые адаптеры со скоростью 10 Гбит/с используются для передачи все более разнообразных типов сетевого трафика, качество обслуживания на основе политик позволяет управлять сетевым трафиком для удовлетворения потребностей инфраструктуры виртуализации.

Качество обслуживания на основе политик дает возможность регулировать пропускную способность сети в соответствии с типом приложений, пользователями и компьютерами. Политики качества обслуживания позволяют выполнять требования к обслуживанию рабочей нагрузки или приложения путем измерения пропускной способности сети, отслеживания изменений состояния сети (например, используемой или доступной пропускной способности) и определения приоритетов (или регулирования) сетевого трафика.

Помимо возможности установки максимальной пропускной способности, политики качества обслуживания в Windows Server 2012 R2 предоставляют новую функцию управления пропускной способностью: задание ее минимального значения. В отличие от максимальной пропускной способности, минимальная задает нижний предел. Таким образом типу трафика гарантированно выделяется определенная пропускная способность. Вы можете одновременно установить и минимальный, и максимальный пределы пропускной способности.

Преимущества

Недостатки

  • Управляется групповой политикой.

  • Легко применяется к виртуальным ЛС для установки нужных параметров пропускной способности, когда несколько виртуальных ЛС работают через один сетевой адаптер или посредством объединения сетевых карт.

  • Качество обслуживания на основе политик можно применять к трафику IPsec.

  • Не обеспечивает управление пропускной способностью для трафика, использующего виртуальный коммутатор.

  • Узлы Hyper-V должны быть присоединены к домену.

  • Политики качества обслуживания на основе программного обеспечения и оборудования нельзя использовать одновременно.

Дополнительные сведения:

Обзор качества обслуживания (QoS)

Качество обслуживания на основе политик

Data Center Bridging

Мост для центра обработки данных (DCB) обеспечивает распределение пропускной способности на основе оборудования конкретным видам трафика и повышает надежность передачи Ethernet с помощью управления потоками на основе приоритета. DCB рекомендуется при использовании FCoE и iSCSI.

Преимущества

Недостатки

  • Поддержка Microsoft iSCSI

  • Поддержка FCoE

  • Необходимы инвестиции в оборудование, включая следующие компоненты:

    • адаптеры Ethernet с поддержкой DCB;

    • аппаратные коммутаторы с поддержкой DCB.

  • Сложность развертывания и управления

  • Не обеспечивает управление пропускной способностью для трафика виртуального коммутатора

  • Политики качества обслуживания на основе программного обеспечения и политики DCB нельзя использовать одновременно.

Дополнительные сведения:

Обзор моста для центра обработки данных (DCB)

SMB Direct

SMB Direct (SMB с удаленным доступом к памяти (RDMA)) — это протокол хранения данных в Windows Server 2012 R2. Он обеспечивает прямую передачу данных из памяти в память между сервером и хранилищем. Он минимально загружает ЦП и использует стандартные сетевые адаптеры с поддержкой RDMA. Таким образом обеспечивается крайне быстрый ответ на сетевые запросы. В результате по времени ответа удаленное файловое хранилища не уступает непосредственно подключенному блочному хранилищу.

Преимущества

Недостатки

  • Увеличение пропускной способности: полностью использует пропускную способность высокоскоростных сетей, в которых сетевые адаптеры координируют передачу больших объемов данных со скоростью линии.

  • Низкая задержка: обеспечивает крайне быстрый ответ на сетевые запросы. В результате удаленное файловое хранилище работает так же быстро, как непосредственно подключенное блочное хранилище.

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

  • Чтобы ускорить динамическую миграцию, можно настроить для нее использование протокола SMB Direct.

  • Включен по умолчанию на узле.

  • Клиент SMB автоматически обнаруживает и использует несколько сетевых подключений, если настроена соответствующая конфигурация.

  • Настройте систему управления пропускной способностью SMB, чтобы задать пределы для динамической миграции, виртуальных машин и трафика хранилища по умолчанию.

  • Функция SMB Multichannel не требует адаптеров с поддержкой RDMA.

  • Сетевые адаптеры с поддержкой RDMA несовместимы с объединением сетевых карт.

  • Для обеспечения высокой доступности необходимо развернуть два или несколько сетевых адаптеров RDMA на каждом узле.

  • Поддерживаемые сетевые адаптеры в настоящее время ограничены следующими типами:

    • iWARP;

    • Infiniband;

    • RoCE.

  • Функция RDMA с RoCE требует DCB для управления потоками.
Объединение полученных сегментов

Объединение полученных сегментов (RSC) уменьшает загрузку ЦП при обработке входящего сетевого трафика благодаря переносу задач с ЦП на сетевой адаптер с поддержкой RSC.

Преимущества

Недостатки

  • Повышает масштабируемость серверов, сокращая накладные расходы, связанные с обработкой больших объемов входящего сетевого трафика.

  • Сокращает число тактов ЦП, требуемых для операций сетевого хранилища и динамической миграции.

  • Требуется сетевой адаптер с поддержкой RSC.

  • Не обеспечивает существенного улучшения в случае с рабочими нагрузками с высокой интенсивностью операций отправки.

  • Несовместим с трафиком, шифруемым по протоколу IPsec.

  • Применяется к трафику узла. Для применения RSC к трафику виртуальной машины она должна работать под управлением ОС Windows Server 2012 R2 и для нее должен быть настроен сетевой адаптер SR-IOV.

  • Не включается по умолчанию на серверах, обновляемых до Windows Server 2012 R2.
Масштабирование на стороне приема

Масштабирование на стороне приема (RSS) позволяет сетевым адаптерам распределять нагрузку, связанную с обработкой сетевого трафика в режиме ядра, между несколькими ядрами процессора в компьютерах с многоядерными ЦП. Распределенная обработка позволяет поддерживать более высокую нагрузку сетевого трафика, чем при использовании одного ядра. Для этого функция RSS распределяет нагрузку, связанную с обработкой сетевого трафика, между несколькими процессорами и осуществляет активную балансировку нагрузки для трафика, передача которого завершается по протоколу TCP.

Преимущества

Недостатки

  • Распределяет прерывания мониторинга между несколькими процессорами, поэтому теперь одному процессору не требуется обрабатывать все прерывания ввода-вывода, что было обычной ситуацией в предыдущих версиях Windows Server.

  • Работает с объединением сетевых карт.

  • Работает с трафиком UDP.

  • Требуется сетевой адаптер с поддержкой RSS.

  • Отключается, если виртуальный сетевой адаптер связан с виртуальным коммутатором. Для сетевых адаптеров, связанных с виртуальным коммутатором, вместо RSS используется VMQ.
SR-IOV

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

Подробности об SR-IOV см. в разделе Задача 2б. Определение производительности для сетевого трафика выше.

Задача 2в. Определение стратегии обеспечения высокой доступности сети и агрегирования пропускной способности

Объединение сетевых карт, известное также под названием балансировки нагрузки и обеспечения отказоустойчивости (LBFO), позволяет группировать несколько сетевых адаптеров в целях агрегирования пропускной способности и обеспечения отказоустойчивости при передаче трафика. Это позволяет избежать потери связи при отказе сетевого компонента.

Эта функция предоставлялась поставщиками сетевых адаптеров. Объединение сетевых карт, появившееся в Windows Server 2012, теперь входит в состав функций операционной системы Windows Server.

Объединение сетевых карт совместимо со всеми сетевыми возможностями Windows Server 2012 R2, кроме следующих трех:

  • SR-IOV;

  • RDMA;

  • Проверка подлинности 802.1X.

Если говорить о масштабируемости, в Windows Server 2012 R2 в одну группу можно включить от 1 до 32 сетевых адаптеров. На одном узле можно создать неограниченное число групп.

Дополнительные сведения:

Обзор объединения сетевых карт

Виртуальная академия Майкрософт: объединение сетевых карт в Windows Server 2012

Командлеты объединения сетевых карт (NetLBFO) в Windows PowerShell

Развертывание объединения сетевых карт (LBFO) Windows Server 2012 R2 и управление им

Конвергентный центр обработки данных с хранилищем файлового сервера

Задача 2г. Определение стратегии изоляции и защиты сетевого трафика

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

Стратегия

Преимущества

Недостатки

Шифрование (IPsec)

Трафик защищается при передаче по проводам.

  • Снижение производительности при шифровании и расшифровке трафика.

  • Сложность настройки, управления и устранения неполадок.

  • Неправильное изменение конфигурации IPsec может привести к перерывам в работе сети или неправильному шифрованию трафика.

Отдельные физические сети.

Сеть отделена физически.

  • На узле необходимо установить дополнительные сетевые адаптеры.

  • Если сеть требует высокой доступности, для нее необходимо два или более сетевых адаптеров.

Виртуальная локальная сеть

  • Изоляция трафика с помощью назначенного идентификатора виртуальной ЛС

  • Поддержка протокола VTP

  • Поддержка частных виртуальных ЛС

  • Уже используется многими корпоративными клиентами

  • Число виртуальных ЛС ограничено 4 094; большинство коммутаторов поддерживают только 1 000 виртуальных ЛС

  • Требует дополнительной настройки сетевого оборудования и управления им

  • Виртуальные ЛС не могут охватывать несколько подсетей Ethernet, что ограничивает число узлов в отдельной виртуальной ЛС и размещение виртуальных машин в соответствии с физическим расположением.

Задача 2д. Определение виртуальных сетевых адаптеров

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

Задача 2е. Определение виртуальных коммутаторов

Чтобы подключить виртуальную машину к сети, вам нужно подключить сетевой адаптер к виртуальному коммутатору Hyper-V.

В Hyper-V можно создать виртуальные коммутаторы трех типов:

  • Внешний виртуальный коммутатор

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

    Внимание! Физический сетевой адаптер одновременно может быть привязан только к одному виртуальному коммутатору.

  • Внутренний виртуальный коммутатор

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

  • Частный виртуальный коммутатор

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

    Примечание. Частные и внутренние виртуальные коммутаторы не используют возможности аппаратного ускорения, которые доступны виртуальным машинам, подключенным к внешнему виртуальному коммутатору.

Проектное решение — решения, принимаемые при выполнении различных задач этого этапа, можно вводить на листе "Virtualization hosts" (Узлы виртуализации).

Совет. Виртуальные коммутаторы на разных узлах, подключающиеся к одной сети, должны иметь одинаковые имена. Это позволяет избежать путаницы при определении виртуального коммутатора, к которому должна подключаться виртуальная машина, и упрощает перенос виртуальной машины с одного узла на другой. Командлет Windows PowerShell Move-VM завершится сбоем, если на целевом узле не будет найден виртуальный коммутатор с тем же именем.

Задача 3. Определение конфигурации хранилища

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

Задача 3а. Определение типов данных

Ниже приведены примеры типов данных, которые необходимо учесть при определении требований к хранилищу.

Тип данных

Место хранения данных

Файлы операционной системы сервера виртуальных машин

Обычно на локальном жестком диске

Файл подкачки узла и аварийные дампы в Windows

Обычно локальный жесткий диск

Общее состояние отказоустойчивого кластера

Общее сетевое хранилище или общий том кластера

Файлы виртуальных жестких дисков и файл конфигурации виртуальных машин

Обычно общее сетевое хранилище или общий том кластера

Далее в этом шаге рассматривается хранилище, необходимое для виртуальных машин.

Задача 3б. Варианты хранилищ

Для хранения файлов конфигурации виртуальных машин и виртуальных жестких дисков доступны приведенные ниже варианты.

Вариант 1. Непосредственно подключенное хранилище

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

Преимущества

Недостатки

  • Не требуется сеть хранения данных.

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

  • Может быть внутренним хранилищем или внешним дисковым модулем, включая JBOD.

  • Используя модуль JBOD с технологией дисковых пространств, можно объединить все физические диски в пул носителей, а затем создать один или несколько виртуальных дисков (называемых дисковыми пространствами) на основе свободного пространства в пуле.

  • Модули JBOD обычно стоят меньше и часто являются более гибкими и простыми в управлении, чем модули RAID, так как для управления хранилищем они используют операционные системы Windows или Windows Server, а не выделенные адаптеры RAID.

  • Число серверов, которые можно подключить к внешнему дисковому модулю, ограничено.

  • Только внешнее общее хранилище, например хранилище SAS с дисковыми пространствами, поддерживает отказоустойчивую кластеризацию.
Вариант 2. Запоминающее устройство, подключаемое к сети

Запоминающие устройства, подключаемые к сети, обеспечивают подключение хранилища к сети, в которой они доступны посредством общих файловых ресурсов. В отличие от непосредственно подключенных хранилищ, они не подключаются к компьютеру напрямую.

Запоминающие устройства, подключаемые к сети, поддерживают подключения Ethernet и обычно позволяют администратору управлять дисковым пространством, устанавливать дисковые квоты, обеспечивать безопасность и использовать технологии контрольных точек. Запоминающие устройства, подключаемые к сети, поддерживают множество протоколов. В их число входят файловые системы, подключаемые к сети, CIFS и SMB.

Преимущества

Недостатки

  • Проще в настройке, чем хранилище SAN, и требует меньше специального оборудования для хранения.

  • Plug and Play

  • Может использовать существующую сеть Ethernet.

  • Запоминающее устройство, подключаемое к сети, должно поддерживать SMB 3.0; протокол CIFS не поддерживается.

  • Не подключается напрямую к серверам узлов, которые обращаются к хранилищу.

  • Медленнее по сравнению с другими вариантами.

  • Для оптимальной производительности обычно требуется выделенная сеть.

  • Ограниченные возможности управления и функциональные возможности.

  • Hyper-V поддерживает запоминающие устройства, подключаемые к сети, которые поддерживают SMB 3.0; протоколы SMB 2.0 и CIFS не поддерживаются.

  • Может поддерживать или не поддерживать RDMA.
Вариант 3. Сеть хранения данных

Сеть хранения данных (SAN) — это специальная сеть, которая обеспечивает общий доступ к хранилищу. Сеть SAN состоит из запоминающего устройства, связующей сетевой инфраструктуры (коммутаторов, адаптеров шины и кабелей) и серверов, подключающихся к сети. Устройства SAN обеспечивают быстрый непрерывный доступ к большим объемам данных. Механизм взаимодействия и передачи данных для конкретного развертывания обычно называется структурой хранилища.

Для SAN используется отдельная сеть, которая обычно недоступна другим устройствам через локальную сеть. Сетью SAN можно управлять с помощью протокола SMI-S, SNMP или собственного протокола управления.

Сеть SAN не обеспечивает файловый уровень абстракции, позволяя выполнять операции только на уровне блоков. К самым распространенным протоколам SAN относятся iSCSI, Fiber Channel и Fiber Channel over Ethernet (FCoE). Протокол SMI-S или собственный протокол управления может предоставлять дополнительные возможности, такие как разделение дисков на зоны, сопоставление дисков, маскировка LUN и устранение сбоев.

Преимущества

Недостатки

  • Для SAN используется отдельная сеть, поэтому влияние на сеть передачи данных невелико.

  • Обеспечивает быстрый непрерывный доступ к большим объемам данных.

  • Обычно предоставляет дополнительные функции, такие как защита и репликация данных.

  • Возможен общий доступ со стороны различных групп.

  • Поддерживает виртуальный адаптер Fibre Channel для прямого доступа к номерам LUN запоминающих устройств.

  • Поддерживает кластеризацию гостевых систем.

  • Виртуальные машины, которым требуется доступ к томам данных объемом более 64 ТБ, могут использовать виртуальный адаптер Fibre Channel для прямого доступа к номерам LUN.

  • Высокая стоимость.

  • Для развертывания, управления и обслуживания необходимы специальные навыки.

  • На каждом узле необходимо установить сетевые драйверы адаптеров шины или FCoE.

  • Миграция кластера Hyper-V требует дополнительного планирования и небольшого простоя.

  • Для управления пропускной способностью для трафика FCoE требуется политика качества обслуживания на основе оборудования, использующая мост для центра обработки данных.

  • Трафик FCoE не поддерживает маршрутизацию.
Вариант 4. Общие файловые ресурсы SMB 3.0

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

Преимущества

Недостатки

  • Возможность использования существующих сетей и протоколов.

  • SMB Multichannel обеспечивает агрегирование пропускной способности сети и отказоустойчивость, если между сервером Hyper-V и общим файловым ресурсом SMB 3.0 имеется несколько путей.

  • Используя модуль JBOD с технологией дисковых пространств, можно объединить все физические диски в пул носителей, а затем создать один или несколько виртуальных дисков (называемых дисковыми пространствами) на основе свободного пространства в пуле.

  • SMB Multichannel можно использовать для переноса виртуальных машин.

  • Дешевле, чем развертывание сетей SAN.

  • Гибкая настройка хранилища на файловом сервере с ОС Windows Server.

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

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

  • Горизонтально масштабируемый файловый сервер поддерживает общий диск VHDX.

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

  • Поддержка шифрования трафика SMB с минимальным снижением производительности.

  • Экономия пространства на диске благодаря дедупликации данных в развертываниях VDI.

  • Для развертывания, управления и обслуживания не требуются специальные навыки.

  • Скорость ввода-вывода ниже, чем в развертываниях SAN.

  • Дедупликация данных не поддерживается для файлов работающих виртуальных машин, кроме развертываний VDI.

SMB Direct

SMB Direct является встроенной функцией общих файловых ресурсов SMB. Для обеспечения доступа к хранилищу с максимальной скоростью и низкой задержкой SMB Direct требует сетевые адаптеры и коммутаторы, поддерживающие RDMA. SMB Direct позволяет удаленным файловым серверам работать так же, как локальное и непосредственно подключенное хранилище. Помимо преимуществ SMB, SMB Direct имеет перечисленные ниже преимущества и недостатки.

Преимущества

Недостатки

  • Работает с высокой скоростью и низкой задержкой, в минимальной степени потребляя ресурсы ЦП.

  • Обеспечивает производительность и устойчивость хранилища на основе горизонтально масштабируемого файлового сервера на уровне традиционной сети SAN благодаря решениям Майкрософт для хранения данных и недорогому общему хранилищу с непосредственным подключением.

  • Обеспечивает максимальную скорость динамической миграции и миграции хранилища.

  • Не поддерживает объединение сетевых карт.

  • Для обеспечения избыточности подключения к хранилищу требуются два или несколько сетевых адаптеров с поддержкой RDMA.

Масштабируемый файловый сервер

Рис. 3.Пример горизонтально масштабируемого файлового сервера, использующего конвергентную сеть с RDMA

Дополнительные сведения:

Предоставление экономичного хранилища для рабочих нагрузок Hyper-V с помощью Windows Server

Конвергентный центр обработки данных с хранилищем файлового сервера

Развертывание Hyper-V по SMB

Осуществление более 1 миллиона операций ввода-вывода в секунду из виртуальных машин Hyper-V в кластере горизонтально масштабируемого файлового сервера с помощью Windows Server 2012 R2

Задача 3в. Определение типов архитектуры физических дисков

Тип архитектуры физических дисков, выбранный для хранилища, влияет на производительность решения для хранения данных. Подробности о типах дисков см. в разделе 7.1 статьи Архитектура семейства продуктов "инфраструктура как услуга".

Задача 3г. Определение типа сети хранилища

Используемые типы контроллеров хранилища или контроллеров сети хранилища зависят от варианта хранилища, выбранного для каждой группы узлов. Подробнее см. в разделе Задача 3б. Варианты хранилищ.

Задача 3д. Определение типа хранилища для каждого типа данных

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

Проектное решение — решения, принимаемые при выполнении этой задачи, можно вводить на листе "Virtualization hosts" (Узлы виртуализации).

Дополнительные сведения:

Конфигурации сетей для Hyper-V по SMB в Windows Server 2012 и Windows Server 2012 R2

Плакат с архитектурой компонентов Windows Server 2012 Hyper-V и сопутствующая справочная информация

Обзор технологий хранения

Задача 4. Определение единиц масштабирования для узлов серверов виртуализации

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

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

Единица масштабирования узла

Рис. 4.Пример единицы масштабирования узла серверов виртуализации

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

Проектное решение — если вы решили использовать единицы масштабирования узла сервера виртуализации, то вы можете определить требуемое для них оборудование на листе "Host scale units" (Единицы масштабирования узла).

Совет. Вы можете приобрести предварительно настроенные единицы масштабирования у различных партнеров Майкрософт по разработке оборудования в рамках программы Microsoft Private Cloud Fast Track.

Задача 5. Определение стратегии доступности для узлов серверов виртуализации

Недоступность узлов серверов виртуализации может быть вызвана плановыми процедурами (например, обслуживанием) или незапланированными происшествиями. Ниже описываются стратегии, которые можно применять в обоих случаях.

Запланировано

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

Незапланированные ситуации

Стратегия в этом сценарии зависит от характеристик рабочих нагрузок, размещенных на узле.

  • Для общих рабочих нагрузок с учетом состояния используйте отказоустойчивую кластеризацию в виртуальных машинах.

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

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

Если вы применяете отказоустойчивую кластеризацию в Windows Server с Hyper-V, решите, следует ли использовать функции, перечисленные в таблице ниже. Чтобы узнать больше о каждой функции, щелкните гиперссылку.

Функция

Особенности

Мониторинг приложений Hyper-V

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

Параметры приоритета виртуальных машин

  • Установите приоритет виртуальной машины в соответствии с рабочей нагрузкой. Высокодоступным виртуальным машинам (также известным как кластеризованные виртуальные машины) можно назначить следующие приоритеты:

    • Высокий

    • Средний (по умолчанию)

    • Низкая

    • Не применять автозапуск

  • Кластерные роли с более высоким приоритетом запускаются и размещаются на узлах раньше, чем роли с более низким приоритетом.

  • Если задан приоритет "Не применять автозапуск", роль не включается автоматически после сбоя, благодаря чему ресурсы остаются доступны для запуска других ролей.

Запрет близости виртуальных машин

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

Примечание. Параметры запрета близости настраиваются с помощью Windows PowerShell.

Автоматический сток узлов

  • Кластер автоматически выполняет сток узла (переносит выполняющиеся на нем кластерные роли на другой узел) перед его переводом в режим обслуживания или внесением других изменений в узел.

  • После завершения обслуживания роли возвращаются на исходный узел.

  • Администраторы могут выполнить сток узла одним действием в диспетчере отказоустойчивости кластеров или с помощью командлета Windows PowerShell Suspend-ClusterNode. Можно указать целевой узел для перемещаемых кластерных ролей.

  • При кластерном обновлении также применяется сток узлов для автоматического применения обновлений ПО к узлам кластера.

Кластерное обновление

  • Кластерное обновление позволяет обновлять узлы кластера, не прерывая работу виртуальных машин, запущенных в кластере.

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

Вытеснение виртуальных машин в соответствии с приоритетом

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

  • Вытеснение начинается с виртуальной машины с самым низким приоритетом и продолжается в порядке увеличения приоритета.

  • Вытесненные виртуальные машины перезапускаются через некоторое время в порядке приоритета.

Примечание. Кластеры Hyper-V могут содержать не более 64 узлов и 8 000 виртуальных машин.

Шаг 5. Планирование особенностей архитектуры структуры виртуализации

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

Задача 1. Определение доменов обслуживания

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

Примечание. Эта концепция относится к физическим компонентам сети и хранилища.

Задача 2. Определение физических доменов сбоя

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

Примечание. Эта концепция относится к физическим компонентам сети и хранилища.

Рассмотрите пример на рисунке ниже. На нем показан набор групп узлов в центре обработки данных, на который наложены домены обслуживания и физические домены сбоя.

Домен сбоя

Рис. 5.Пример определения доменов обслуживания и физических доменов сбоя

В этом примере каждая стойка серверов определена как отдельный физический домен сбоя, имеющий свой номер. Связано это с тем, что каждая стойка содержит сетевой коммутатор вверху и ИБП внизу. Работа всех серверов в стойке зависит от этих двух компонентов. Если откажет один их них, откажут и все серверы в стойке.

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

На рис. 5 каждый домен обслуживания (они обозначены MD 1–5) обведен цветной пунктирной линией. Обратите внимание, что каждый сервер в кластере виртуальных машин с балансировкой нагрузки размещен в узле серверов виртуализации, входящем в отдельный домен обслуживания и отдельный физический домен сбоя.

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

Проектное решение — решения, принимаемые при выполнении задач 1 и 2, можно вводить на листе "Settings" (Параметры).

Задача 3. Определение резервной мощности

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

Неисправные серверы

Рис. 6.Неисправные серверы

На рис. 6 узлы серверов виртуализации отказали в перечисленных ниже группах узлов, доменах обслуживания и физических доменах сбоя.

Группа узлов

Физический домен сбоя

Домен обслуживания

2

2

3

3

3

2

4

4

2

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

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

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

Подробности о расчете резервной мощности см. в разделе Резервная мощность в статье "Эталонная архитектура платформы облачных служб — принципы, понятия и шаблоны".

Шаг 6. Планирование начальных характеристик

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

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

Администратору структуры может быть необходимо разработать соглашение об уровне обслуживания (SLA), в котором описываются показатели качества обслуживания для структуры. Для планирования использования структуры администраторы виртуальных машин должны быть ознакомлены с этим соглашением.

Соглашение, скорее всего, будет включать в себя по крайней мере показатель доступности, но может содержать и другие показатели. Чтобы получить представление о базовых показателях SLA для структуры виртуализации, вы можете изучить соглашения, предлагаемые поставщиками общедоступных облачных служб, такими как Microsoft Azure. В случае с размещением виртуальных машин соглашение SLA гарантирует, что когда клиент развертывает два или несколько экземпляров виртуальной машины для выполнения одной рабочей нагрузки в разных доменах сбоя и обновления (называемых в этом документе доменами обслуживания), по крайней мере одна из этих виртуальных машин будет доступна в течение 99,95 % времени.

Полное описание соглашения SLA Azure см. на странице Соглашения об уровне обслуживания. В идеале показатели вашей структуры виртуализации должны быть не ниже показателей поставщиков общедоступных облачных служб.

Задача 2. Определение начальных затрат на размещение хранилища и виртуальных машин

Спроектировав структуру, вы также сможете рассчитать следующие значения:

  • затраты на оборудование, помещения, электропитание и охлаждение структуры;

  • емкость размещения структуры.

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

Чтобы получить представление о базовых затратах на виртуальные машины и хранилище, вы можете изучить стоимость размещения у поставщиков общедоступных облачных служб, таких как Microsoft Azure. Подробности см. на странице Сведения о расценках на виртуальные машины.

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

Дальнейшие действия

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

Microsoft System Center 2012 предоставляет исчерпывающий набор возможностей по подготовке, мониторингу и обслуживанию структуры виртуализации. Чтобы узнать больше об использовании System Center для управления структурой, обратитесь к следующим ресурсам:

Библиотека технической документации System Center

Руководство по архитектуре управления структурой