20 ответов в этой теме

[Jumbo Frame]

Имеется пул виртуалок c Win10 и 13-м агентом (версия сервера в подписи). Начали изучать график нагрузки и нашли повторяющиеся пики (до 80-100%) с интервалом в 30/60 минут. Предположение, что в это время происходит обновление баз, подтвердилось - после смены интервала обновления на 2 часа пики пришли в соответствие. 

 

Есть ли способы снизить нагрузку на процессор при обновлении?

 

[Afalin]

Есть – пользоваться лёгким агентом. Если там действительно много виртуалок на каждом хосте.

Кстати а на сетевом и дисковом I/O всплески ощущаются?

[Jumbo Frame]

На хостах - от 50 до 100 виртуалок. Лёгкий агент - это виртуальный агент имеется в виду?

[Afalin]

Да, он. Само собой, не без ознакомления с мурзилкой.

[Kirill Polubelov]

Лёгкий агент - это виртуальный агент имеется в виду?

Ага.

50-100, это приличная нагрузка на disk i/o должна быть.

[Jumbo Frame]

Ок. 

1. Если у нас на виртуалках уже стоит полный клиент с прямым подключением к серверу ESS (с Guard и офисным контролем), то переключение в режим лёгкого (при наличии сканирующего сервера) выполняется просто галкой "Использовать сканирующий сервер"?

2. У нас кластер proxmox из нескольких нод. На каждой ноде нужно заводить свой сканирующий сервер и явно прописывать его адрес в настройках? Если машина мигрирует с одной ноды на другую - проверка файлов на ней прекращается?

[Afalin]

1. Если у нас на виртуалках уже стоит полный клиент с прямым подключением к серверу ESS (с Guard и офисным контролем), то переключение в режим лёгкого (при наличии сканирующего сервера) выполняется просто галкой "Использовать сканирующий сервер"?

Да, при условии, что агент успешно подключится к скан-серверу.

 

2. У нас кластер proxmox из нескольких нод. На каждой ноде нужно заводить свой сканирующий сервер и явно прописывать его адрес в настройках? Если машина мигрирует с одной ноды на другую - проверка файлов на ней прекращается?

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

Миграция там горячая? Если да, то всё зависит от того, как сетевые соединения переживают эту миграцию.

[Jumbo Frame]

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

 

Вот тут поподробнее. Сеть общая /16, хотя сегментированная. Как это сделать без конфликта адресов?

[Afalin]

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

 

Вот тут поподробнее. Сеть общая /16, хотя сегментированная. Как это сделать без конфликта адресов?

Не знаю за proxmox, но в общем случае ожидается виртуальная сеть внутри VM. Без походов в физическую сеть.

Во имя производительности, во-первых, и во имя подключения именно к скан-серверу на своём хосте, т.е. во имя производительности, во-вторых.

Соответственно, нужно либо скан-серверам на всех хостах дать один и тот же IP, либо хотя бы виртуальную сеть на всех хостах поднять на одном и том же пространстве адресов – чтобы можно было скан-сервер найти там по одному и тому же броадкаст-адресу.

Возможно, есть ещё какие-то более или менее красивые решения.

[Afalin]

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

[Jumbo Frame]

Хорошо, зайдём ещё с другой стороны. А можно разнести время обновления станций? Чтобы они не в одно время обновлялись, когда новые базы появились, а с рандомным разбросом по времени, например, в интервале получаса?

[maxic]

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

[Afalin]

Хорошо, зайдём ещё с другой стороны. А можно разнести время обновления станций? Чтобы они не в одно время обновлялись, когда новые базы появились, а с рандомным разбросом по времени, например, в интервале получаса?

Да можно, конечно. Ограничения обновлений в помощь, там с точностью до 15 минут можно задать, кому когда можно обновляться и с какой скоростью обновления качать.

Но решение это унылое, на мой вкус: слишком много ручной работы требует либо скриптовой магии.

[Roman Rashevskiy]

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

В то время как у некоторых более других вендоров из коробки реализована интеграция между ЦУ и средами виртуализации как раз таки для решения этой задачи.

[Afalin]

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

Что характерно, этот вариант предложен в разделе "если всё это невозможно". Да и магии там нет.

 

В то время как у некоторых более других вендоров из коробки реализована интеграция между ЦУ и средами виртуализации как раз таки для решения этой задачи.

Там есть интересные нюансы. Например, некоторые более другие вендоры имеют доступ к некоторым закрытым API, доступ к которым могут получить не только лишь все.

Хотя да, некоторые вещи технически реализуемы и без тех API, на других костылях.

[Roman Rashevskiy]

Справедливости ради API доступны всем авторизованным технологическим партнерам.

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

[Afalin]

Справедливости ради API доступны всем авторизованным технологическим партнерам.

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

Кому открытый, а кому и нет.

[Roman Rashevskiy]

Что характерно, этот вариант предложен в разделе "если всё это невозможно".

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

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

 

Кому открытый, а кому и нет.

Ну тогда можно сразу и рассказать в чем же оказалась "собака зарыта".

[Afalin]

Что характерно, этот вариант предложен в разделе "если всё это невозможно".

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

Да, если читать написанное только до середины.
Недостатки решения не в этом.

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

"Общая адресация" – это вообще о чём? Я что-то не горю желанием додумывать то, чего тут не сказано.

 

Ну тогда можно сразу и рассказать в чем же оказалась "собака зарыта".

Сферическая в вакууме собака в абстрактных средах виртуализации?

[Jumbo Frame]

Хорошо, а каков сам принцип функционирования виртуального агента? Он все проверяемые файлы по сети передаёт на анализ скансерверу?

Если виртуалка на одной ноде, а скансервер - на другой, то всё будет работать, только медленнее?

Если скансерверов много, адреса у них разные, а поиск выполняется по udp://:18008, то какой раньше ответит - к тому агент и подключится?

Каковы требования к скансерверу, который будет обслуживать 100 виртуалок? (ядра, память, диск, канал)