Хост hyper v

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Настраиваем сеть в Hyper-V.

Настраиваем сеть в Hyper-V.

• Автор: Уваров А.С.
• 21.01.2014

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

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

За настройку сетей в Hyper-V отвечает Диспетчер виртуальных коммутаторов, если мы откроем его, то увидим следующую картину:

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

Внешняя сеть

Самый распространенный тип сети, который позволяет виртуальным машинам взаимодействовать с внешними сетями и хостом. При ее создании необходимо выбрать один из физических сетевых адаптеров, через который данная виртуальная сеть будет соединяться с внешними сетями.

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

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

А в свойствах физического адаптера остался только Расширяемый виртуальный сетевой коммутатор в Hyper-V.

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

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

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

Внутренняя сеть

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

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

Внутренняя сеть c NAT

Данная возможность появилась начиная с Windows Server 2016, Hyper-V Server 2016 и Windows 10. Подробнее читайте в нашей статье: Настраиваем сеть NAT в Hyper-V

Частная сеть

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

Данный вид сетей может быть использован также в учебных и исследовательских целей, а также для создания изолированных участков сети, например DMZ.

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

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

Мониторинг CPU хоста Hyper-V

Мониторинг CPU хоста Hyper-V задача достаточно актуальная, особенно сейчас, в эпоху виртуализации всего и вся .

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

Если вам интересны счетчики производительности Windows, рекомендую обратиться к основной статье тематики — Счетчики производительности.

Мониторинг CPU хоста Hyper-V

Актуальные (2008-2016) на сегодняшний день серверные операционные системы Windows изобилуют счетчиками производительности — отдельные группы счетчиков есть как для каждой роли, так и для целых продуктов (например Exchange). Различные вариации счетчиков есть и для отдельных компонентов системы — например для мониторинга показателей CPU существуют целых две группы с разными наборами (Счетчики производительности процессора), при анализе которых, к тому же, всплывают и некоторые нюансы (Изменения счетчиков производительности CPU).

Во-первых, стандартные счетчики групп Процессор (Processor) и Сведения о процессоре (Processor Information) вам не помогут в принципе, потому что они отображают потребление ресурсов CPU только процессами корневой (хостовой) системой. То есть те ресурсы ЦП, которые потребляют гостевые операционные системы (проще говоря сами виртуалки), не будут отражены в показателях. Это действительно проблема, поскольку очень часто стоит элементарная задача узнать сколько ресурсов съедают все виртуалки враз.

Косвенно задача решается суммированием загрузки ЦП всех виртуалок в пересчете на то количество виртуальных процессоров, которые им выделены. Дело это, мягко говоря, неблагодарное.

Однако удобное решение есть. Для роли Hyper-V добавляются несколько новых групп счетчиков CPU:

• Hyper-V Hypervisor Logical Processor — Логический процессор низкоуровневой оболочки Hyper-V
• Hyper-V Hypervisor Root Virtual Processor — Корневой виртуальный процессор низкоуровневой оболочки Hyper-V
• Hyper-V Hypervisor Virtual Processor — Виртуальный процессор низкоуровневой оболочки Hyper-V

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

Hyper-V Hypervisor Logical Processor

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

Вот и получается, что для отслеживания реальной загрузки ЦП мы должны обращаться к показателям загрузки логических процессоров, но не к чему-либо другому. Конкретно для этого нам подойдет счетчик Hyper-V Hypervisor Logical Processor(_Total)% Total Run Time (зеленая линия):

Красная линия на графике — это счетчик Processor Information(_Total)% Processor Time. Как вы видите, его показания абсолютно бесполезны и не отражают реальной загрузки сервера. Будьте внимательны.

Hyper-V Hypervisor Root Virtual Processor

Переходим к полностью виртуальному представлению, ведь группа счетчиков Hyper-V Hypervisor Root Virtual Processor отвечает за мониторинг показателей производительности ЦП корневого раздела. Корневой раздел — это как раз та хостовая ОС, на которой вы и разворачиваете виртуальные машины.

Но почему бы не отслеживать производительность хоста через известные нам группы счетчиков Processor и Processor Information? В принципе можно, но все-таки правильнее это делать через Hyper-V Hypervisor Root Virtual Processor. Объясняю почему: суть гипервизора в том, что он предоставляет равноправный доступ к ресурсам как хостовому разделу, так и гостевым. То есть ресурсы для виртуальных машин выделяет не хостовый раздел, а именно гипервизор. Это хорошо видно на иллюстрации с официального ресурса 1 :

Такие вот тонкости.

Hyper-V Hypervisor Virtual Processor

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

Чтобы лучше было понятно дальнейший ход мыслей, хочу привести пример: имеем сервер с одним ЦП, у которого 8 потоков. На этом сервере крутятся 3 виртуальные машины и у каждой из них по 4 виртуальных процессора. Учитывая тот факт, что 1 виртуальный процессор = 1 ядру/потоку реального ЦП, то виртуалки по суммарной мощности вылезают в 1,5 раза из мощности ЦП хоста. Тем не менее, вы запросто можете назначить каждой виртуалке хоть 8 vCPU, чтобы общее количество виртуальных процессоров составило 24 штуки.

Я на своем домашнем Core i7 могу создать с десяток виртуалок, назначить каждой по несколько vCPU так, чтобы их общее количество явно выходило за пределы 8 потоков реального процессора и вот что получится:

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

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

Вывод

Каким же образом гипервизор распределяет нагрузку между ядрами? Есть несколько ключевых моментов:

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

2. Виртуальный процессор никоим образом не привязан к реальному физическому ядру. Из этого следует, что каждый виртуальный процессор может «размываться» по нескольким физическим ядрам, взяв от каждого какую-либо величину;

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

Серьезные проблемы у вас начнутся в том случае, если все виртуалки начнут отжирать максимально выделенную им процессорную мощность. По факту ЦП каждой ВМ будет нагружен на 10-15%, а хост ляжет с 95-98% загрузкой ЦП.

История из личного опыта: подобная ситуация у меня как-то была при тестировании виртуального сервера 1С+СУБД и терминального сервера. Все они располагались на одном и том же хосте виртуализации и им было выделено максимальное количество vCPU. Когда на терминалке запустили с десяток толстых клиентов 1С и сымитировали закрытие месяца, то терминалка показывала примерно 60% загрузки, 1С+СУБД всего лишь 40%, но хост лег наглухо — загрузка ЦП стремилась к 100%.

Вывод прост — не размещайте на одном хосте несколько требовательных к производительности виртуальных серверов, лучше разнесите их по разным хостам и разбавьте чем-то не ресурсоемким (например файловыми серверами или контроллерами домена).

По идее на серверах в продакшене нормой будет средняя загрузка не более 60%, но это уже совсем другая история.

Хост hyper v

Вопрос

Имеется выделенный сервер у хостера с одним сетевым интерфейсом который имеет статический IP

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

Ответы

На физ.уровне Вы дали ВМ доступ к Вашему адаптеру. Если провайдер выдаёт Вам только 1 белый IP, то логично предположить, что второй,третий и т.д. IP-адресов для Ваших ВМ нет подобных. Вам необходимо маршрутизировать пакеты от ВМ до узла, на котором есть доступ к интернету. Это совсем базовые вещи.

кабель провайдера — 1 шт.

внешний ИП — 1 шт.

на роутере вы настраиваете подключение по Static IP к провайдеру , а далее клиентам прописывается в качестве маршрута адрес роутера. Пакет на 0.0.0.0 будет идти на адрес роутера, а далее на провайдера.

Roman Levchenko, MCSA, MCITP, MCTS http://www.rlevchenko.com

• Предложено в качестве ответа Zaza Abramov 20 июля 2014 г. 18:49
• Помечено в качестве ответа Petko Krushev Microsoft contingent staff, Moderator 30 июля 2014 г. 6:18

Все зависит от того, что хотите получить.

По общему адаптеру подобно этому:

Roman Levchenko, MCSA, MCITP, MCTS http://www.rlevchenko.com

• Помечено в качестве ответа Petko Krushev Microsoft contingent staff, Moderator 30 июля 2014 г. 6:18

Если Вы, не хотите арендовать дополнительные адреса у провайдера, то посоветовал бы что-то типа pfsense

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

• Предложено в качестве ответа R.Levchenko MVP 20 июля 2014 г. 19:17
• Помечено в качестве ответа Petko Krushev Microsoft contingent staff, Moderator 30 июля 2014 г. 6:18

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

Итак как раздать интернет на виртуальные машины находящиеся на хосте у которого один сетевой интерфейс с белым IP выданным провайдером:

1. Создаем в Hyper-V в диспетчере виртуальных коммутаторов внешнюю сеть и указываем для нее реальный физический сетевой адаптер который имеет выход в интернет (в моем случае это уже было сделано) и помечаете » Allow management operating system to share this network adapter»
2. Для созданного виртуального адаптера, обычно имя типа (Hyper-V Virtual Ethernet Adapter) на закладке доступ, разрешаем другим пользователям сети использовать подключение к Интернет данного компьютера
3. Создаем в Hyper-V в диспетчере виртуальных коммутаторов внутреннюю сеть и эту сеть назначаем в настройках виртуальных машин как сетевой адаптер
4. В результате будет создана подсеть, в моем случае это 192.168.137/24 и виртуальным машинам буду назначены адреса из этой подсети и будет предоставлен доступ к интернет (для меня загадка почему ведь между виртуальными коммутаторами на хосте я не ставил мост, наверное расшаривание действует таким образом и для спецов по сетям это понятно, как я уже писал я в сетях не силен)

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

• используем нативные средства системы без сторонних решений
• простота настройки

Как напрямую скопировать файл с хоста Hyper-V в виртуальную машину

В обновленной роли Hyper-V, представленной в Windows Server 2012 R2 и Windows 8.1 появилась возможность прямого копирования файлов с хоста Hyper-V в виртуальную машину без использования сетевых интерфейсов. Этот функционал реализуется с помощью новой службы в гостевой ОС под названием Guest Services, входящей в состав интеграционных компонентов Hyper-V (Integration Services).

Итак, чтобы воспользоваться возможностью прямого копирования файлов в виртуальную машину с хостовой ОС Hyper-V, нужно в ВМ установить последнюю версию компонентов интеграции (Integration Services версии не ниже 6.3.9600.16384), и активировать на ней службу Guest Services.

Служба Guest Services позволяет осуществить копирование файлов между хостовым гипервизором (компьютером с ролью Hyper-V) и виртуальной машиной, запущенной на нем без использования сетевых компонентов. Процесс копирования осуществляется через высокоскоростную внутреннюю шину vmbus (Virtual Machine Bus), напрямую связывающую гипервизор и виртуальную машину. Благодаря этому администратор может скопировать внутрь виртуальной машины любой файл, причем абсодютно неважно в какой сети находится целевая виртуальная машина, подключена ли она вообще к виртуальному коммутатору, или находится в изолированной сети.

Служба Guest services для виртуальных машин по умолчанию отключена. Включить ее можно через GUI консоли Hyper-V в свойствах виртуальной машины (в разделе Integration Services ) или с помощью Powershell.

Проверить, включена ли служба Guest services для виртуальной машины, можно так:

В данном примере служба отключена: Guest Service Interface: False.

Чтобы включить службу, воспользуемся такой командой:

Внутри виртуальной машины должна быть запущена служба Hyper-V Guest Service, ее статус можно получить так:

После того, как служа интеграции Guest Service включена, можно с помощью специального командлета Copy-VMFile скопировать любой файл, расположенный на файловой системе сервера Hyper-V напрямую в виртуальную машину. Чтобы скопировать файл в уже существующую папку в гостевой ОС, выполним на сервере команду:

Если целевой путь в гостевой ОС не существует, команда вернет ошибку. Чтобы автоматически создать указанный путь на файловой системе гостевой ОС, воспользуемся аргументом -CreateFullPath

Отключить службу Guest Services можно так:

Итак, благодаря службе Guest Services администратор Hyper-V может напрямую скопировать любой файл внутрь гостевой ОС виртуальной машины.

Обеспечение производительности
сервера Hyper-V

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

Рост эффективности
и надежности виртуальной среды при помощи PRTG

i Virtualization is the process of creating a virtual version of something like computer hardware. It involves using specialized software to create a virtual or software-created version of a computing resource rather than the actual version of the same resource.
Read more

i Что такое сенсор?

В PRTG «сенсор» является виртуальной точкой измерения и обычно осуществляет мониторинг одного показателя вашей сети, например, трафик портов коммутаторов, загрузка ЦП сервера или свободное место на жестком диске. В среднем вам понадобится 5-10 сенсоров для одного устройства или один сенсор для порта коммутатора.

Виртуальная среда

Виртуальная среда – важная часть ИТ инфраструктуры – и требует особого внимания. Контроль за состоянием виртуальных сред необходим, чтобы поддерживать бесперебойную работу всей инфраструктуры. Решения для мониторинга ИТ-инфраструктуры в реальном времени от компании Paessler помогает обеспечить стабильность и надежность виртуальной среды. Инструмент мониторинга Hyper-V даст возможность использовать все преимущества виртуальной системы.

Преодоление рисков виртуализации с помощью сенсоров Hyper-V

Виртуализация дает множество преимуществ, например, эффективное распределение ресурсов, но в то же время не лишена недостатков.

Сильная нагрузка на виртуальную машину будет влиять на производительность «соседней» виртуальной системы расположенной на том же хосте. Ошибка в сетевом подключении или на хосте, сказывается на работе виртуальных серверов и может привести к остановке бизнес процессов. Инструменты мониторинга Hyper-V помогают обнаружить и решить проблемы, связанные с виртуальной системой.

Сенсоры PRTG для мониторинга Hyper-V

Гипервизоры, как Microsoft Hyper-V поддерживают работу компонентов виртуальных систем. Контролировать работу Hyper-V помогают сенсоры PRTG. Они накапливают и анализируют данные о состоянии виртуальных машин и хостов. Все результаты анализа отображаются в виде показателей работы Hyper-V на единой панели управления. Так вы получаете доступ к информации, необходимой для планирования, тестирования и мониторинга виртуальной среды. Когда показатели отклоняются от нормы, PRTG высылают оповещение.

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

PRTG поддерживает стабильную работу ИТ-инфраструктуры.

Краткий обзор инструмента PRTG для мониторинга Hyper-V

Обзор сенсора Hyper-V для мониторинга
хост сервера

Мониторинг почтового сервера с помощью PRTG

Мониторинг виртуального сервераVMware

Сенсоры PRTG собирают данные:

PRTG предлагает множество сенсоров для мониторинга Hyper-V, включая:

• Hyper-V Host Server Sensor отслеживает загруженность ЦПУ, состояние работоспособности системы, трафик хост сервера.
• Hyper-V Virtual Machine Sensor отслеживает загруженность ЦПУ, показатели операций чтения/записи на виртуальных машинах, запущенных на сервере Hyper-V.
• Hyper-V Virtual Storage Sensor: мониторинг показателей операций чтения/записи, ошибок устройств хранения, запущенных через хост Hyper-V.

Контроль состояния виртуальной инфраструктуры
– с рабочего места и удаленно

Программа PRTG устанавливается за несколько минут и совместима с большинством мобильных устройств.

PRTG контролирует для вас работу этих и многих других производителей и приложений

Мониторинг Hyper-V:
Десять преимуществ PRTG

Контроль перегрузки

PRTG помогает избегать перегрузок и отказов серверов виртуализации.

Безопасность

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

Оптимизация виртуальной инфраструктуры

Созданные PRTG отчеты наглядно представляют данные, которые можно использовать для планирования, тестирования и мониторинга виртуальной среды.

Оптимизация серверов VMware

Paessler – партнер VMware. PRTG предлагает эффективные инструменты для мониторинга виртуальных серверов VMware. Большой опыт работы с системами виртуализации, позволяет нам создавать эффективные инструменты и для мониторинга Hyper-V.

Обеспечение стабильности сети

Стабильность и надежность виртуальных сред достигается за счет комплексного мониторинга 24/7 в реальном времени.

Снижение числа прерываний рабочих процессов

PRTG определяет ресурсы, которые используются сетевыми соединениями и хост серверами. С помощью этого администраторы поддерживают доступность серверов и предупреждают снижение продуктивности.

Балансировка виртуальных машин

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

Защита критических ресурсов

PRTG ограничивает чрезмерное использование критических ресурсов. Сенсор обнаруживает хост серверы, которые не полностью загружены, свободное дисковое пространство в томе CSV и тем самым способствует распределению нагрузки.

Настраиваемые оповещения

Системные администраторы самостоятельно определяют пороговые значения для сенсоров PRTG. Как только пороговые значения достигнуты, PRTG высылает администратору оповещения. Способ оповещения, время и получатели настраиваются самостоятельно.

Быстрое обнаружение и устранение источников ошибок

Система мониторинга не только оповещает о возникновении проблемы, но и указывает на источник проблемы. PRTG упрощает поиск и устранение неисправностей в виртуальных средах.

«Нашим сетевым инженерам нравится возможность гибкой настройки PRTG.»

Джон Кралл, руководитель технического отдела, объединенный школьный округ Окленда, США

Лидирующее решение мониторинга по оценкам экспертов рынка.
Нам доверяют более 200 000 пользователей.

«Фантастическое решение для мониторинга сети и инфраструктуры, которое легко развернуть и еще проще использовать. Просто лучшее из доступных».

«Программное обеспечение абсолютно идеальное, поддержка выше всяких похвал. Отвечает всем потребностям и требованиям. Это обязательное решение, если вам нужен какой-либо вид мониторинга».

«Этот инструмент выделяется своей основной целью – быть единой службой управления инфраструктурой и мониторинга сети».

• Полная версия PRTG на 30 дней
• После 30 дней – бесплатная версия
• Для расширенной версии – коммерческая лицензия

Как работает решение PRTG для мониторинга Hyper-V

i Syslog stands for System Logging Protocol and is a standard protocol used to send system log or event messages to a specific server, called a syslog server. It is primarily used to collect various device logs from several different machines in a central location for monitoring and review. The protocol is enabled on most network equipment such as routers, switches, firewalls, and even some printers and scanners. In addition, syslog is available on Unix and Linux based systems and many web servers including Apache.
Read more

Перед началом проекта по виртуализации, оцените уровень загрузки ЦПУ, памяти и жесткого диска для тех программ, которые будут включены в вашу виртуальную инфраструктуру. Собрать необходимые данные для оценки возможной нагрузки на серверы вы можете через PRTG Network Monitor. Подобная оценка поможет предотвратить сбои и отказы системы.

Мониторинг виртуальных сред состоит из четырех элементов. Прежде всего – это контроль за состоянием компонентов оборудования сети с помощью сенсоров SNMP. Компоненты оборудования, как правило, оказывают заметное и продолжительное влияние на виртуальную инфраструктуру. Второе – это контроль аппаратного обеспечения хост-сервера Hyper-V, так как проблемы с виртуальными машинами часто лежат в том оборудовании, на котором эти машины запущены. И PRTG предоставляет сенсоры, разработанные специально для мониторинга оборудования хост сервера Hyper-V. Третье – контроль отдельных виртуальных машин на хост серверах с помощью сенсоров для монторинга виртуальной машины Hyper-V PRTG, которые доступны по умолчанию. Это позволит отследить показатели: загрузка ЦПУ, скорость чтения / записи и другие. Не обязательно контролировать каждую виртуальную машину; достаточно включить только те машины, которые наиболее важны для стабильной работы сети. Наконец – контроль операционных систем для критических устройств, который должен осуществляться напрямую, например, через WMI.

Установите свои собственные пороговые значения

Установите пороговые значения для сенсоров, чтобы определить тот уровень, когда потребуется ваше вмешательство в работу виртуальной системы. Вы можете ограничить максимальную допустимую загрузку системы 75%. И как только данный показатель будет достигнут, системный администратор автоматически получит предупреждение. Настроить систему оповещений вы можете самостоятельно. Выберете подходящий формат: пуш-уведомления, текстовые сообщения, email, syslog сообщения, SNMP traps. Можно настроить запуск внешних приложений или рингтона.

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