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

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

С вами как всегда на связи Григорий, прожжённый Kaspersky Certified Systems Engineer, или просто любитель поковырять ИБ-продукты как только можно и не нужно :-)

Трепещущая сердечко ситуация

В организации, деятельность которой завязана на ИТ-автоматизации было множество подразделений и филиалов по РФ, суммарно более 5 тысяч сотрудников, у большинства корпоративные рабочие станции и/или ноутбуки.

Основной датацентр размещён в столице (Москва), где развернуты все инфраструктурные сервисы.

По соображениям безопасности, и с соображениями о дальнейшем росте отдела ИБ (и как следствие, увеличении используемых средств защиты) - были выделены отдельные сервера виртуализации под контур средств защиты информации.

После развёртывания инсталляции Kaspersky Security Center - проблема пришла откуда не ждали, а именно при установке KES и агентов на рабочие станции в сетях филиалов, через задание удалённой установки программ.

Утилизация всех ядер CPU маршрутизатора достигла предела, VPN-каналы от всех филиалов к инфраструктуре существенно деградировали, вызвав шквал негодования в сторону головного ИТ-отдела от пользователей.

При разборе полётов оказалось, что фактически агенты администрирования совершили некое подобие DDoS-атаки в отношении маршрутизатора, запустив оверкап по Rx-пакетам для KSC далеко в стратосферу.

Произведём некоторый математический расчёт, который раскроет нам глаза на то, почему же так произошло:
- Опираясь на официальную документацию (https://support.kaspersky.ru/ksc/15.1/159734?page=help), расход трафика при совместной установке Kaspersky Endpoint Security для Windows с агентом администрирования выглядит следующим образом:

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

Но опытные администраторы KSC знают, что задачи удалённой установки, по умолчанию, имеют лимит в 5 одновременных загрузок пакетов с сервера администрирования:

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

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

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

Архитектурные изменения

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

Немного подкорректировав её - мы уже можем немного улучшить ситуацию:

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

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

Типовые решения

1. Развёртывание иерархии серверов администрирования по филиалам (сетевое взаимодействие сводится только к нагрузке на сетевое оборудование внутри филиалов, и редкое взаимодействие с главным сервером администрирования в Москве: https://support.kaspersky.ru/ksc/15.1/92242);

2. Увеличение рандомизированной задержки для старта задач:

   

3. Ограничение утилизации трафика в сети в KSC:

   

4. Увеличение интервала синхронизации агентов администрирования с KSC:

   

5. Точечное применение задач удалённой установки (не делайте её сразу на все управляемые устройства, а по отделам или филиалам, поочерёдно).

Наилучшим вариантом будет, если на всех устройствах по умолчанию будут установлены необходимые пакеты агента администрирования и Kaspersky Endpoint Security (старые-любимые золотые образы и темплейты ВМ), и делом KSC будет лишь автоматическая выдача лицензий, но реальность полна разочарований :)

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

Всем бобра, побольше сладостей, поменьше гадостей!