Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 1)
- Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 5)
- Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 6)
- Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 7)
Введение
Когда виртуализация серверов впервые стала применяться на практике, ее часто рекламировали как решение, которое поможет снизить затраты на оборудование за счет консолидации. Теперь, когда технология виртуализации серверов созрела, становится очевидным, что у виртуализации серверов есть много дополнительных преимуществ, но консолидация оборудования остается одним из основных преимуществ. На самом деле, некоторые организации приняли виртуализацию серверов как способ максимизировать отдачу от своих инвестиций в оборудование.
Если организация занимается виртуализацией серверов с заявленной целью получить максимальную отдачу от своего серверного оборудования, то имеет смысл рассмотреть способы максимального увеличения количества виртуальных машин, работающих на каждом хост-сервере. Эту практику часто называют максимизацией плотности виртуальных машин.
Несколько слов предостережения
Существует ряд различных методов повышения плотности виртуальных машин хост-сервера. Однако, прежде чем я начну обсуждать эти методы, мне нужно уделить некоторое время обсуждению некоторых потенциальных проблем, с которыми вы можете столкнуться при этом.
Чтобы максимизировать плотность виртуальных машин на хосте, вам нужно будет сделать две вещи. Во-первых, вы должны минимизировать аппаратные ресурсы, выделяемые каждой виртуальной машине. Во-вторых, вам, как правило, придется распределять некоторые ресурсы (например, ядра ЦП) между большим количеством виртуальных машин. Делая это, вы должны помнить, что существует компромисс между плотностью виртуальной машины и производительностью виртуальной машины. Проще говоря, нельзя ожидать, что виртуальная машина будет работать хорошо, если она не будет обеспечена адекватными аппаратными ресурсами. В крайних случаях виртуальная машина с недостаточным аппаратным обеспечением может стать нестабильной.
Еще одна проблема, которую необходимо учитывать перед увеличением плотности виртуальных машин, заключается в том, что потребление ресурсов виртуальных машин не является линейным. Виртуальная машина, которой было назначено ровно столько ресурсов, сколько нужно для выполнения обычных операций, может быть не в состоянии справиться с пиковыми нагрузками. Такие всплески могут быть вызваны увеличением активности пользователей, фоновыми процессами операционной системы или даже рутинными задачами обслуживания, такими как резервное копирование или сканирование вредоносных программ. Дело в том, что бывают случаи, когда виртуальным машинам потребуются дополнительные ресурсы, и у вас должен быть план предоставления необходимых ресурсов.
Другим критически важным соображением является то, как плотность виртуальных машин влияет на отказоустойчивость. Большинство производственных развертываний Hyper-V работают как часть отказоустойчивого кластера Windows. Без кластеризации сбой одного хост-сервера приведет к серьезному сбою, поскольку все виртуальные машины, работающие на отказавшем хосте, также перестанут работать.
Есть две вещи, которые вам нужно иметь в виду в отношении отказоустойчивой кластеризации. Во-первых, каждый узел кластера должен иметь достаточный объем доступных аппаратных ресурсов, чтобы он мог функционировать как часть кластера. Отказоустойчивый кластер не требует больших ресурсов, но члены кластера должны иметь возможность своевременно отправлять, получать и обрабатывать пульсирующий трафик.
Еще одна вещь, которую вы должны иметь в виду при создании отказоустойчивых кластеров, заключается в том, что узлы кластера должны иметь достаточно ресурсов, чтобы обеспечить отказоустойчивость. Да, ЦП, память и сетевые ресурсы используются во время процесса перехода, который происходит как часть отработки отказа, и вы должны убедиться, что эти ресурсы доступны, но это еще не все.
Представьте, что у вас есть отказоустойчивый кластер, состоящий из трех хостов Hyper-V, и что на всех трех хостах работает максимальное количество виртуальных машин, которое аппаратное обеспечение может комфортно поддерживать. Теперь представьте, что один из хост-серверов выходит из строя. Когда это происходит, предполагается, что виртуальные машины, работавшие на отказавшем узле, автоматически переносятся в режиме реального времени на оставшиеся узлы кластера. Однако если на оставшихся узлах уже запущены все виртуальные машины, с которыми они могут работать, виртуальные машины не могут быть перенесены в реальном времени, поскольку им некуда деваться. Между прочим, этот важный момент подводит меня к уроку номер один по максимизации плотности виртуальных машин — приоритизации виртуальных машин.
Приоритизация виртуальных машин
Как я объяснял в предыдущем разделе, вы не можете полностью максимизировать количество виртуальных машин, работающих на каждом узле в кластере, потому что, если вы это сделаете, аварийное переключение виртуальных машин станет невозможным. Однако в Windows Server 2012/Hyper-V 3.0 Microsoft представила новую функцию, называемую приоритезацией виртуальных машин. Приоритизация виртуальных машин не решает полностью проблему перегруженных узлов кластера, но в некоторых ситуациях помогает.
Основная идея заключается в том, что в большинстве организаций одни виртуальные машины важнее других. Например, критически важный сервер приложений можно рассматривать как очень важную виртуальную машину. И наоборот, избыточный контроллер домена может быть примером виртуальной машины, имеющей минимальное значение. Приоритизация виртуальных машин работает путем отключения виртуальных машин с низким приоритетом (при необходимости), чтобы виртуальные машины с высоким приоритетом могли продолжать работать.
Хотя это может показаться нелогичным, расстановка приоритетов виртуальных серверов на самом деле не является функцией уровня Hyper-V. Вместо этого она обрабатывается службой отказоустойчивой кластеризации. Вы можете установить приоритет для виртуальной машины, открыв Диспетчер серверов, а затем выбрав команду Диспетчер отказоустойчивого кластера в меню Инструменты. Когда откроется диспетчер отказоустойчивого кластера, выберите контейнер «Роли», а затем щелкните правой кнопкой мыши виртуальную машину, приоритет запуска которой вы хотите изменить. Затем выберите команду «Изменить приоритет запуска» в появившемся контекстном меню. Теперь вы можете назначить приоритет виртуальной машине.
Вывод
Как видите, существует ряд вопросов, которые необходимо обязательно принять во внимание, прежде чем пытаться втиснуть максимально возможную плотность виртуальных машин на хост Hyper-V. Это не означает, что вы не должны пытаться максимизировать отдачу от ваших инвестиций в оборудование, но вы должны быть осторожны при этом. Существует очень тонкая грань между максимально эффективным использованием физических аппаратных ресурсов и настолько тонким растяжением этих ресурсов, что все начинает ломаться.
Один из способов уменьшить последствия использования ресурсов по сравнению с обязательствами — установить приоритеты для ваших виртуальных машин. Поступая таким образом, вы фактически даете Hyper-V разрешение на отключение виртуальных машин с низким приоритетом (при необходимости) в ситуации отработки отказа, чтобы виртуальные машины с более высоким приоритетом могли продолжать работать.
Конечно, приоритезация виртуальных машин — далеко не единственный метод, который можно использовать для достижения максимально возможной (или максимально возможной) плотности виртуальных машин. Есть много других методов и лучших практик, которые я буду обсуждать в этой серии статей.
- Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 5)
- Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 6)
- Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 7)