Перед тем, как вы приступите к построению инфраструктуры на основе современных средств виртуализации и введением этой структуры в эксплуатацию, вам нужно будет позаботиться о наиболее эффективном распределении системных ресурсов для обеспечения максимальной производительности сервера. В данном материале мы дадим несколько практических рекомендаций по оптимизации системы со стороны виртуальной машины и хоста.
Так как каждый сервер, на котором хостится виртуальная машина, как правило, работает на пике нагрузок, показатель производительности серверов данного типа является определяющим критерием для всей системы. Потенциальными местами к расширению возможностей в данном случае можно считать:
Сетевую подсистему;
Дисковую подсистему;
Процессорное время;
Память.
Рассмотрим, как можно выявить «узкое» с точки зрение производительности место и как решить проблему с ресурсами.
Процессорная часть – это сердце любого компьютера, а потому многое зависит от того, насколько правильно он выбран в контексте виртуализации. Более того, процессор считается одной из наиболее дорогих частей любых компьютеров, а потому выбор слишком высоких процессорных мощностей может быть либо невозможным, либо необоснованным с финансовой точки зрения.
Помимо расходов на приобретение стоит учитывать затраты на охлаждение и электропитание. В этом контексте важно ответить на 3 ключевых вопроса:
Сколько процессорных ядер может понадобиться?
Сколько всего процессоров необходимо поставить?
Каковы их скоростные параметры?
Только после ответа на эти вопросы, целесообразно двигаться дальше в плане оптимизации производительных ресурсов системы. Причем, здесь все не так просто, как может показаться.
С другой стороны системная производительность в общем и целом может быть более зависимой даже не от самих процессоров. К примеру, СУБД. В отдельных случаях процессорные требования могут быть не такими высокими, а вот дисковую систему придется задействовать по полной. При этом если в такой СУБД достаточно активно применяется аналитика, включая OLAP и бизнес-логика, то требования к памяти и процессору могут стать на порядок выше, чем требования к дисковым подсистемам.
Для определения того, насколько слабым звеном является процессор в данном вопросе при условии построения виртуализации, необходимо понять степень его загруженности. Для этого используются различные системные утилиты, включая такую привычную для многих сисадминов WTM. Но в силу особой архитектуры Hyper-V Task Manager может показать лишь загрузку процессора в рамках хостовых ОС.
При этом виртуалки учитываться и вовсе не будет, так как хостовые ОС, равно как и прочие виртуалки, работают в рамках изолированных разделов. В этом случае потребуется использовать Perfmon-оснастку. В ней присутствует большое количество счетчиков по Hyper-V. В этом вопросе наиболее интересными из них являются такие как:
% Total Run Time Hyper-V (Virtual Processor) – счетчик, отображающий степень загрузки виртуальных процессоров. Здесь может быть задана суммарная загрузка для каждой запущенной виртуальной машины, а также выбран отдельный виртуальный процессор от конкретной виртуалки.
% Total Run Time Hyper-V (Root Processor Virtual) – при помощи такого счетчика отображается загрузка выбранных процессоров логического типа, которые имеют задачи, не связанные непосредственным образом с Hyper-V.
При помощи этих двух счетчиков можно получить реальную картину загрузки хостовых процессоров. Значения отображены в процентах. Чем они более приближены к отметке 100%, тем выше нагрузка на процессор, соответственно. Таким образом, можно задуматься о приобретении дополнительных новых, более высоких по мощности вариантов.
При недостаточно памяти система использует файл подкачки, что снижает производительность по экспоненте. В Hyper-V имеется возможность выделять больше памяти, чем имеется в системе (memory overcommit). Не будем давать оценку тому, насколько это хорошо или плохо в рамках данного материала, а рассмотрим несколько факторов, с которыми связан выбор требуемого количества памяти:
Сколько будет запущено виртуалок, и какое количество памяти им может потребоваться? В данном случае подход к выбору примерно тот же, что и в случае с обыкновенными серверами. Однако память виртуальных машин может быть выделена в более гибком виде, например, не стандартные 1024 Мб, а 800 Мб.
Как на счет памяти для хостовой ОС? В данном случае рекомендованное количество освобождаемой памяти равно 512 Мб – все это потребуется, как самой ОС, так и гипервизору. В хостовых системах могут выполняться другие задачи, кроме виртуализации.
Сценарии LiveMigration и прочие виртуальные машины. При планировании инфраструктуры на основе отказоустойчивых кластеров, на каждом хосте должны быть предусмотрены дополнительные объемы памяти. Если их будет недостаточно, чтобы запустить перемещаемые виртуальные машины, они не смогут запуститься на хосте. Отсюда следует сразу выделить неприкасаемые запасы памяти в размере 50-100% от требуемого объема в целом.
Достаточно сложно понять, сколько именно дискового пространства может потребоваться виртуальной машины для стабильной и комфортной работы. Именно по этой причине наблюдается достаточно много ситуаций, в которых свободного дискового пространства либо критически не хватает, либо в простое его остается слишком много. Кроме объема не менее важным параметром является быстродействие дисковых подсистем.
При проектировании подсистем для хранения данных виртуальных машин следует обязательно учитывать следующие аспекты:
Контроллерное оборудование – разрядность шины для контроллеров дисков могут иметь различные объемы кэш-памяти, разрядность и быстродействие. Кроме того существуют, как полусофтовые, так и аппаратные контроллеры – быстродействие системы в первую очередь зависит от типа выбранного контроллера.
Тип дисковых накопителей – кроме объема у жестких дисков есть и много других параметров, о которых всегда стоит помнить. К ним относится скорость вращения шпинделя, тип интерфейса, объем кэшируемой памяти и т.п.
Число задействованных дисковых накопителей и тип RAID-массивов. Иной раз для повышения производительности в рамках виртуализации лучше использовать не один объемный диск, а несколько небольших накопителей, объединенных в RAID-массивы (RAID 1 – «зеркалирование», RAID 4 и RAID 5 – «чередование с контролем четности», RAID 6 –RAID DP, двойная четность, и гибрид RAID 0 и RAID 1 – RAID 10).
Намного реже такие подсистемы требуют расширения в отличие от жесткого диска, памяти и процессоров, однако и о них не стоит забывать. В данном случае также есть ряд вопросов, на которые стоит ответить, прежде чем организовать виртуальный хостинг под Hyper-V:
Каковы параметры сетевой пропускной способности?
Сколько ВМ будут запускаться в одновременном режиме, и какую нагрузку они будут создавать?
Имеется ли у сервера аппаратное средство для удаленного управления, которое не зависит от установленных ОС (это может быть Dell DRAC или HP iLO, например)?
В зависимости от того, какими будут ответы на эти вопросы, последуют определенные сценарии настройки сетевых подсистем. К примеру мы имеет один сервер с четырьмя сетевыми интерфейсами и тремя запущенными виртуальными машинами. При этом отсутствует Out-of-band-management-контроллер. Таким образом, если случаются непредвиденные проблемы, придется отправляться в серверную, которая может находиться на другом конце города.
Если речь идет об установке Windows Server, то она может быть реализована в двух режимах: ServerCore и Full. Говоря о работе гипервизора, с этой точки зрения такие режимы практически ничем друг от друга не отличаются. Тем не менее ServerCore может показаться сложнее на первый взгляд, в частности для малоопытных сисадминов. Но все же рекомендуется использовать этот режим. В сравнении с полной установкой он имеет такие преимущества, как:
Меньшее количество обновлений;
Меньшая процессорная нагрузка и нагрузка на память в родительских партициях;
Меньшая площадь для потенциальных атак злоумышленников.
Многое в данном случае при необходимости повысить производительность самих ВМ зависит от приложений, которые в них выполняются. Microsoft разработала рекомендации для каждого такого приложения, включая IIS, SQL Server, Exchange и т.п. Для ПО сторонних вендоров также имеются подобные «best practices».
В инсталляционном пакете Windows Server содержатся интеграционные сервисы, а потому не требуется дополнительная установка таких сервисов на подобные системы. Благодаря сервисам интеграции можно использовать синтетические устройства, отличающиеся более высокой производительностью, в сравнении с эмулируемыми устройствами.
В состав установочных пакетов входит набор драйверов (IDE-контроллер, Сетевой адаптер, SCSI-контроллер, мышь и видео), а также интеграционных сервисов (Data Exchange, Time Synchronization, Operating System Shutdown, Online Backup и Heartbeat).
Чтобы установить интеграционные сервисы в Windows необходимо перейти в раздел: Action – Integration Services Setup. В данном случае к виртуальным машинам будет автоматически подмонтирован образ ISO, включающий в себя установочный файл, после чего запустится процесс установки.
Компоненты интеграции для Linux-систем не включены в дистрибутивы Win Server, а потому потребуется их загрузка с официального сайта Microsoft.
