Определение размещения гостевой ОС (часть 2)

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

Шаг третий: установите пороговые значения производительности

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

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

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

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

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

Проблема в том, что большую часть времени нагрузка, которую виртуальная машина возлагает на ЦП, не остается постоянной. Если вы когда-либо проводили мониторинг производительности на невиртуализированном сервере Windows, то знаете, что даже когда машина работает в режиме ожидания, существуют колебания в загрузке ЦП. Время от времени загрузка ЦП достигает 100%, но иногда она снижается до 0%.

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

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

Шаг четвертый: жонглируйте

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

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

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

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

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

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

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

Вывод

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

Определение размещения гостевой ОС (часть 1)