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

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

Шаг первый: определите возможности каждого хоста

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

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

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

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

Шаг второй: определите потребности каждого виртуального сервера

Следующим шагом в процессе размещения виртуального сервера является определение требований к ресурсам каждой виртуальной машины. Вообще говоря, я рекомендую относиться к виртуальной машине так же, как к физической машине. Предположим, например, что вы собираетесь развернуть сервер приложений, и издатель приложения заявил, что рекомендует двухъядерный процессор, 2 ГБ оперативной памяти и 100 ГБ свободного места на жестком диске. Издатель приложения, вероятно, предполагает, что приложение будет выполняться на физическом сервере. Тем не менее, по моему опыту, различные требования к оборудованию применяются одинаково, даже если приложение будет запускаться на виртуальной машине.

В приведенном выше примере я не утверждаю, что пока хост-сервер имеет двухъядерный процессор, 2 ГБ ОЗУ и 100 ГБ места на жестком диске, вы сможете запускать приложение на виртуальной машине. Я имею в виду, что если вы можете выделить эти конкретные ресурсы для виртуальной машины таким образом, чтобы предотвратить использование этих ресурсов другими виртуальными машинами, работающими на хост-сервере, то приложение, вероятно, будет работать нормально.

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

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

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

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

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

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

Вывод

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