Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 2)
- Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 3)
- Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 5)
- Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 6)
- Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 7)
В первой статье этой серии я объяснил, что максимальное увеличение плотности виртуальной машины — это что-то вроде палки о двух концах. С одной стороны, достижение максимально возможной плотности виртуальных машин приносит дивиденды, когда речь идет об инвестициях в серверное оборудование. Проще говоря, организации не придется приобретать столько хост-серверов, если они будут максимально эффективно использовать уже имеющиеся. Однако, с другой стороны, существует тонкая грань между использованием творческих методов для достижения максимальной практической плотности виртуальных машин на хост и размещением такого количества виртуальных машин на хост-сервере, что производительность начинает страдать, а виртуальные машины и основные функции виртуализации начинают ломаться.. Хитрость заключается в том, чтобы эффективно использовать ресурсы вашего хост-сервера, но не перегружать аппаратное обеспечение.
Ключом к достижению этого хрупкого баланса является постоянный учет конкуренции за ресурсы. Любой физический сервер (независимо от того, выступает ли он в качестве узла виртуализации или нет) содержит конечное количество аппаратных ресурсов. Сервер имеет только определенное количество ядер процессора. Памяти на сервере ровно столько. Дело в том, что любой физический сервер, каким бы мощным он ни был, имеет свои ограничения.
Когда физический сервер действует как узел виртуализации, физические ресурсы сервера совместно используются всеми виртуальными машинами, работающими на сервере, гипервизором и операционной системой узла (если она существует). Все эти компоненты конкурируют за аппаратные ресурсы. Именно эта конкуренция за аппаратные ресурсы известна как конкуренция за ресурсы.
Конечно, это поднимает вопрос о том, как аппаратные ресурсы распределяются между виртуальными машинами, гипервизором и основной операционной системой. Некоторые ресурсы распределяются таким образом, что позволяет виртуальной машине фактически владеть назначенными ей ресурсами. Например, физический сетевой адаптер можно напрямую назначить конкретной виртуальной машине с помощью выделенного виртуального коммутатора.
Конкуренция за ресурсы не является прямой проблемой для аппаратных ресурсов, которые напрямую назначены конкретной виртуальной машине. В конце концов, если аппаратный ресурс выделен для конкретной виртуальной машины, то этот ресурс, по сути, зарезервирован специально для этой виртуальной машины. Другие виртуальные машины, работающие на узле, даже не пытаются использовать зарезервированные ресурсы, поскольку гипервизор обеспечивает резервирование ресурсов.
Если вы внимательно посмотрите на формулировку, которую я использовал в первом предложении предыдущего абзаца, вы заметите, что я сказал, что «конфликт за ресурсы не является прямой проблемой для аппаратных ресурсов, которые напрямую назначены конкретной виртуальной машине». Под этим утверждением я подразумевал, что даже если виртуальные машины не конкурируют активно за ресурсы, конкуренция происходит по-другому.
Предположим, например, что вы должны назначить физический сетевой адаптер для конкретной виртуальной машины. Другие виртуальные машины, работающие на хост-сервере, не будут пытаться использовать сетевой адаптер, поскольку он зарезервирован для использования конкретной виртуальной машиной. Однако оставшиеся виртуальные машины потенциально могут пострадать от последствий, которые могут возникнуть в случае конфликта ресурсов. Это может произойти, если оставшиеся виртуальные машины не получают достаточной пропускной способности сети, частично из-за того, что часть доступной пропускной способности заблокирована для исключительного использования одной конкретной виртуальной машиной.
Имейте в виду, что я не говорю, что вы никогда не должны выделять оборудование непосредственно для конкретной виртуальной машины. С другой стороны. Существует ряд ситуаций, которые требуют эксклюзивного назначения ресурсов по соображениям производительности или безопасности. Я говорю о том, что распределение ресурсов — это компромисс. Если вы зарезервируете определенные ресурсы для использования с одной конкретной виртуальной машиной, эти ресурсы будут недоступны для использования где-либо еще. Таким образом, прямое назначение ресурсов должно выполняться таким образом, чтобы каждая виртуальная машина получала необходимые ей ресурсы, но не выделяла лишние ресурсы виртуальной машине и не лишала другие виртуальные машины необходимых им ресурсов.
Хотя некоторые типы ресурсов могут быть зарезервированы для использования конкретной виртуальной машиной, другие ресурсы являются общими. Точные методы, используемые гипервизором для распределения использования общих ресурсов, сложны и выходят далеко за рамки этой серии статей. Однако процесс часто сводится к очередям. Когда виртуальной машине требуется доступ к общему ресурсу, она отправляет запрос гипервизору, который ставит запрос в очередь. Гипервизор использует внутренний алгоритм для определения того, как должны обрабатываться запросы в очереди, тем самым контролируя использование аппаратных ресурсов виртуальной машины.
Ранее в этой статье я говорил, что распределение аппаратных ресурсов — это тонкий баланс. Ресурсы в идеале должны распределяться таким образом, чтобы обеспечить максимально возможную плотность виртуальных машин, но без проблем, связанных с чрезмерным использованием ресурсов. Перегрузка ресурсов происходит, когда запросы на использование оборудования ставятся в очередь быстрее, чем запросы могут быть выполнены. В этот момент конкуренция за ресурсы начинает влиять на общую производительность системы.
Конечно, вся эта информация поднимает вопрос о том, как можно эффективно использовать имеющиеся аппаратные ресурсы, но не переборщить. Некоторые администраторы пытаются решить эту проблему, оценивая требования к оборудованию каждой виртуальной машины, а затем сопоставляя эти требования с возможностями физического оборудования.
В целом этот подход работает, но есть два фактора, которые легко случайно упустить из виду. Я кратко описал первый из этих факторов в своей предыдущей статье. Проблема в том, что потребление ресурсов виртуальной машиной не является линейным. Как и в случае с физическим сервером, в определенные часы дня бывают скачки спроса. Например, для виртуализированного контроллера домена обычно наблюдается всплеск нагрузки, когда все входят в систему утром или когда все возвращаются с обеда. Виртуальный сервер, для которого были выделены минимальные аппаратные ресурсы, может быть плохо приспособлен для работы с такими всплесками спроса. Позже в этой серии статей я еще расскажу о всплесках спроса.
Другое соображение, которое легко упустить из виду, заключается в том, что вы не можете выделить 100% физических аппаратных ресурсов сервера виртуальным машинам. Гипервизору также нужны аппаратные ресурсы для выполнения своей работы.
Hyper-V не позволит вам назначать ресурсы гипервизору напрямую, поэтому вам просто нужно помнить, что нельзя использовать часть доступных ресурсов (тем самым делая их доступными для использования гипервизором). Как правило, я рекомендую зарезервировать два физических ядра ЦП и 2 ГБ памяти для использования гипервизором и операционной системой хоста. Гипервизор может работать с меньшим количеством ресурсов, но вы должны быть осторожны, чтобы не обсчитать гипервизор, потому что это может негативно повлиять на каждую виртуальную машину, работающую на хосте.
Вывод
Вся концепция максимизации плотности вашей виртуальной машины сводится к отслеживанию конкуренции за ресурсы. В части 3 этой серии статей я продолжу обсуждение, показав вам некоторые методы выполнения назначений аппаратных ресурсов.
- Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 3)
- Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 5)
- Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 6)
- Максимальное увеличение плотности виртуальных машин в Hyper-V (часть 7)