Калькулятор масштабирования

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

Расчеты для компонента Sensor

Эти расчеты применимы также при развертывании приложения на виртуальной платформе.

При расчете аппаратных требований к компоненту Sensor требуется учитывать, что максимальный объем обрабатываемого трафика составляет 10 Гбит/с. Для обработки трафика максимального объема можно использовать как один Sensor, установленный на отдельном сервере, так и несколько Sensor, установленных на отдельных серверах, которые подключены к одному Central Node. Суммарный объем передаваемого трафика от всех Sensor, подключенных к одному серверу Central Node, не должен превышать 10 Гбит/с.

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

Вы можете использовать сервер Sensor в качестве прокси-сервера при обмене данными между рабочими станциями с Endpoint Agent и Central Node, чтобы упростить настройку сетевых правил. Например, если рабочие станции с Endpoint Agent находятся в отдельном сегменте сети, то будет достаточно настроить соединение между серверами Central Node и Sensor.

При использовании Sensor в качестве прокси-сервера при обмене данными между компонентами Endpoint Agent и компонентом Central Node учитывайте следующие ограничения:

• Максимальное количество рабочих станций с компонентом Endpoint Agent, подключенных к одному компоненту Central Node, составляет 15 000 шт.
• Максимально допустимые потери пакетов, пересылаемых между серверами Sensor и Central Node, составляют 10% при задержке отправки пакетов до 100 мс.

Требуемая пропускная способность канала связи между серверами Central Node и Sensor зависит от объема обрабатываемого трафика и определяется по следующей формуле:

10% от трафика на SPAN-порте при обычной нагрузке или 20% от трафика на SPAN-порте при пиковой нагрузке + почтовый трафик + трафик по протоколу ICAP + требования к каналу связи между Central Node и Endpoint Agent

Аппаратные требования к серверу Sensor

Компонент Sensor может быть интегрирован с IT-инфраструктурой организации следующими способами:

• получение зеркалированного трафика от сетевых устройств со SPAN-портов;
• подключение к почтовому серверу по протоколу POP3;
• подключение к почтовому серверу по протоколу SMTP;
• получение трафика от прокси-сервера по протоколу ICAP.

Аппаратные требования к серверу Sensor приведены в таблице ниже. Расчеты приведены для случая, когда Sensor обрабатывает сообщения электронной почты и зеркалированный трафик со SPAN-портов. Если Sensor используется в качестве прокси-сервера при обмене данными между рабочим станциями с Endpoint Agent и Central Node, следует также учитывать требования к каналам связи.

Аппаратные требования к серверу Sensor в зависимости от объема обрабатываемого трафика со SPAN-портов

Центральный процессор должен поддерживать набор инструкций BMI2, AVX и AVX2.

Если вы хотите обрабатывать только сообщения электронной почты и не обрабатывать зеркалированный трафик со SPAN-портов, мы рекомендуем использовать Sensor, установленный на одном сервере с Central Node. Подробнее об аппаратных требованиях см. в разделе Расчеты для компонента Central Node → Аппаратные требования к серверу Central Node и Sensor.

Если один сервер Sensor обрабатывает трафик по нескольким протоколам, то для расчета конфигурации сервера необходимо учитывать, что при настроенной интеграции с почтовым сервером или почтовым сенсором необходимо выключить обработку трафика по протоколу SMTP.

Требования к дисковому пространству на сервере Sensor

Рекомендуется использовать дисковый массив RAID 1. Общий объем дискового пространства должен составлять не менее 500 ГБ.

Аппаратные требования к Sensor при использовании сохранения сырого сетевого трафика

Если вы используете функционал сохранения сырого сетевого трафика, вам необходимо дополнительно увеличить следующие аппаратные характеристики сервера Sensor:

• 0,5 CPU для каждого 1 Гбит/c сетевого трафика.
• 6 ГБ оперативной памяти, если скорость сетевого трафика менее 2 Гбит/с или 12 ГБ оперативной памяти, если скорость сетевого трафика 2 Гбит/с и более.
• Установить отдельное дисковое хранилище в виде пула RAID-массива или DAS с максимальной пропускной способностью, определяемой по формуле:

  <пропускная способность дискового хранилища> = 3 * <максимальный объем записываемого трафика>

• Емкость дискового хранилища определяется от желаемого времени хранения и максимального объема сохраняемого трафика с учетом фильтров. По примерным расчетам, для хранения записанного трафика максимальным объемом 10 Гбит/с в течении 7 дней, необходимо дисковое хранилище емкостью 750 ТиБ.

Расчеты для компонента Central Node

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

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

• Установить параметры High Latency Sensitivity.
• Зарезервировать всю оперативную память.
• Зарезервировать всю частоту процессора.

Аппаратные требования к серверу с компонентами Central Node и Sensor

Аппаратные требования к серверу, на котором установлены компоненты Central Node и Sensor, зависят от следующих условий:

• объем обрабатываемого трафика;

  Объем обрабатываемого расшифрованного трафика для расчета нагрузки на сервер определяется по следующей формуле:

  <объем расшифрованного трафика, передаваемого приложением ArtX TLSProxy 1.9.1> = 5 * <объем незашифрованного трафика>

  Объем обрабатываемого на ICAP-сервере трафика для расчета нагрузки на сервер определяется по следующей формуле:

  <объем трафика, обрабатываемого на ICAP-сервере> = 5 * <объем трафика, который не обрабатывается на ICAP-сервере>

• количество обрабатываемых сообщений электронной почты в секунду;
• количество хостов с компонентом Endpoint Agent.

  Компонент Endpoint Agent может быть установлен на рабочую станцию, терминальный сервер, файловый сервер или в сетевое хранилище (NAS).

  Совместимость версий приложений, которыми представлен компонент Endpoint Agent, c версиями Kaspersky Anti Targeted Attack Platform см. в следующих разделах справки: Kaspersky Endpoint Agent для Windows, Kaspersky Endpoint Security для Windows, Kaspersky Endpoint Security для Linux, Kaspersky Endpoint Security для Mac.

  Приложение Kaspersky Endpoint Agent для Windows также может быть установлено на сервер SCADA.

  Эффективное количество хостов с компонентом Endpoint Agent для расчета нагрузки на сервер определяется по следующей формуле:

  K = A+3*B+20*C

  где

  • "K" – эффективное количество хостов с компонентом Endpoint Agent.
  • "A" – количество рабочих станций и пользователей терминальных серверов под управлением операционной системы Windows с установленным компонентом Endpoint Agent.
  • "B" – количество рабочих станций и пользователей терминальных серверов под управлением операционной системы Linux или macOS с установленным компонентом Endpoint Agent.
  • "C" – количество серверов.

При объеме обрабатываемого трафика более 1 Гбит/с необходимо устанавливать компоненты Central Node и Sensor на отдельных серверах.

Аппаратные требования к серверу с компонентом Central Node в зависимости от используемой функциональности представлены в таблице ниже.

Для работы Kaspersky Anti Targeted Attack Platform на базе операционной системы Astra Linux вам необходимо настроить приложение.

Аппаратные требования к серверу с компонентом Central Node при использовании функциональности KEDR

Аппаратные требования к серверу с компонентом Central Node при использовании функциональности КАТА и KEDR

Аппаратные требования к серверу с компонентом Central Node при использовании функциональности КАТА

Kaspersky Anti Targeted Attack Platform не поддерживает работу с программным RAID-массивом.

Центральный процессор должен поддерживать набор инструкций BMI2.

Требования к дисковому пространству на сервере Central Node

На сервере с компонентом Central Node должно быть не менее 2000 ГБ свободного пространства на первой дисковой подсистеме и не менее 2400 ГБ на второй дисковой подсистеме. Объем требуемого пространства на второй дисковой подсистеме зависит от желаемой политики хранения данных и может быть вычислен по следующей формуле:

150 ГБ + <количество хостов с Kaspersky Endpoint Agent или Kaspersky Endpoint Security для Windows>/15000 * (400 ГБ + 240 ГБ * <срок, за который требуется хранить данные, в днях>)/0.65, но не более 12 ТБ.

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

Если вы установили компонент Central Node и Sensor не в виде отказоустойчивого кластера, вам необходимо рассчитать объем на диске для параметров База событий, ГБ и Хранилище, ГБ по следующей формуле:

A = F - R, ГБ.

где

• А – объем, используемый для базы событий и Хранилища.
• F – объем жесткого диска, на котором установлен компонент Central Node.
• R – зарезервированное количество свободного пространства (ГБ), соответствующее количеству подключенных хостов с компонентом Endpoint Agent, приведенное в таблице ниже.

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

Зарезервированное количество свободного пространства в зависимости от количества хостов с компонентом Endpoint Agent

Если вы настроили интеграцию для проверки объектов внешней системы с помощью REST API, вам необходимо увеличить аппаратные характеристики сервера Central Node. Дополнительные аппаратные требования приведены в таблице ниже.

Дополнительные аппаратные требования к серверу с компонентом Central Node при наличии интегрированных внешних систем

Если вы настроили интеграцию для отправки событий во внешнюю систему с помощью REST API, вам необходимо увеличить аппаратные характеристики сервера Central Node на 1 логическое ядро и 6 ГБ оперативной памяти.

Если вы используете функциональность сохранения сетевого трафика, вам необходимо увеличить аппаратные характеристики сервера Cental Node. Подробнее об аппаратных требованиях см. в разделе Расчеты для компонента Sensor → Аппаратные требования к Sensor при использовании сохранения сырого сетевого трафика.

Требования к серверу PCN в режиме распределенного решения

Если вы используете режим распределенного решения, при расчете аппаратных требований необходимо учитывать, что аппаратные требования к серверу PCN на 10% выше для минимального объема оперативной памяти и для минимального количества логических ядер, чем к серверу с компонентом Central Node. Аппаратные требования к серверу с компонентом Central Node указаны в таблицах Аппаратные требования к серверу с компонентом Central Node при использовании функциональности KEDR, Аппаратные требования к серверу с компонентом Central Node при использовании функциональности KATA+KEDR, Аппаратные требования к серверу с компонентом Central Node при использовании функциональности KATA (см. выше).

Вы можете подключить к одному серверу PCN до 30 серверов SCN.

Требования к каналам связи

Необходимо обеспечить пропускную способность канала связи между сервером с компонентом Central Node и каждым сегментом сети в зависимости от количества хостов с компонентом Endpoint Agent в сегменте. Пропускная способность в зависимости от количества хостов с компонентом Endpoint Agent приведена в таблице ниже.

Пропускная способность канала связи в зависимости от количества хостов с компонентом Endpoint Agent

Минимальные требования к каналу связи между серверами PCN и SCN в режиме распределенного решения приведены в таблице ниже.

Минимальные требования к каналу связи между серверами PCN и SCN

Аппаратные требования к серверам кластера Central Node

Кластер должен включать минимум 4 сервера: 2 сервера хранения и 2 обрабатывающих сервера. При подключении до 15 000 хостов с компонентом Endpoint Agent, вам нужно минимум 2 сервера хранения и 2 обрабатывающих сервера. При подключении от 15 000 до 30 000 хостов с компонентом Endpoint Agent вам требуется не менее 2 серверов хранения и 3 обрабатывающих серверов.

Каждый сервер кластера должен иметь два сетевых адаптера для настройки кластерной и внешней подсети. Кластерная подсеть должна функционировать со скоростью 10 Гбит/с.

Для кластерной подсети также должны выполняться следующие требования:

• В кластерную подсеть должны входить только серверы кластера и сетевые коммутаторы.
• Кластерная подсеть должна быть изолированной.
• Серверы кластера должны находиться в одном L1- или L2-сегменте. Для этого вы можете подключить все серверы кластера к одному коммутатору или использовать программное туннелирование. Например, L2TPv3 или Overlay Transport Virtualization (OTV).
• Значение сетевой задержки ("network latency") должно удовлетворять требованию "single digit latency", то есть в миллисекундах значение должно быть менее 10.

Аппаратные требования к серверам кластера при использовании функциональности KEDR приведены в таблице ниже.

Аппаратные требования к обрабатывающим серверам при использовании функциональности KEDR

Аппаратные требования к серверам хранения при использовании функциональности KEDR

Рекомендуется использовать для двух дисковых подсистем диски одинакового объема. Для второй дисковой подсистемы используются диски, не объединенные в RAID-массив.

Требования к скорости дисковых подсистем аналогичны требованиям, указанным в таблице Аппаратные требования к серверу с компонентом Central Node при использовании функциональности KEDR (см. выше).

Расчеты для компонента Sandbox

Аппаратные требования к серверу с компонентом Sandbox зависят от типа и объема обрабатываемого трафика и от допустимого времени проверки объекта.

По умолчанию допустимое время проверки объекта составляет 1 час. Для уменьшения этого времени требуется более мощный сервер или большее количество серверов с компонентом Sandbox.

Рекомендуется рассчитывать конфигурацию компонента Sandbox следующим образом:

1. Установите компоненты Central Node и Sensor на одном сервере и компонент Sandbox на другом сервере для пилотирования приложения.

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

2. Запустите скрипт для записи данных, выполнив команды:

   sudo kata-run.sh kata-collect --output-dir path-to-folder

   --output-dir <путь к директории>

   Когда скрипт завершит работу, в указанную директорию будет помещен архив collect.tar.gz.

3. Передайте этот архив для анализа сотрудникам "Лаборатории Касперского".

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

Работа компонента Sandbox не поддерживается на процессорах AMD.

Аппаратные требования к серверу с компонентом Sandbox

Расчет количества серверов с компонентом Sandbox при использовании преднастроенных образов операционных систем приведен в таблице ниже.

Аппаратные требования к компоненту Sandbox при использовании преднастроенных образов операционных систем

Если вы хотите установить компонент Sandbox на виртуальный сервер, для получения аналогичной физическому серверу производительности вам понадобится в 3–4 раза больше серверов.

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

<количество файлов, которое будет поступать на обработку согласно пользовательским правилам Sandbox, в час> * <количество пользовательских образов операционных систем> / 1000

Расчет количества виртуальных серверов с компонентом Sandbox, необходимых при использовании пользовательских образов операционных систем, выполняется по следующей формуле:

<количество файлов, которое будет поступать на обработку согласно пользовательским правилам Sandbox, в час> * <количество пользовательских образов операционных систем> / 280

Оценка количества серверов Sandbox приведена для серверов следующей конфигурации:

• При установке компонента Sandbox на физический сервер:
  • 2 процессора Intel Xeon 8 Core (HT) с частотой 2,6 ГГц или выше.
  • 80 ГБ оперативной памяти.
  • 2 HDD объемом 300 ГБ каждый, объединенные в массив RAID 1.
• При установке компонента Sandbox на виртуальную машину VMware ESXi:
  • Процессор Intel Xeon 15 Core (HT) с частотой 2,1 ГГц или выше.
  • 32 ГБ оперативной памяти.
  • HDD объемом 300 ГБ.

    На виртуальной машине:

    1. Разрешена вложенная виртуализация.
    2. Установлены параметры High Latency Sensitivity.
    3. Зарезервирована вся оперативная память.
    4. Зарезервирована вся частота процессора.

  При установке компонента Sandbox на виртуальную машину VMware ESXi нужно установить ограничение для количества одновременно запускаемых виртуальных машин – 12.

  Если вы планируете использовать пользовательские образы операционных систем, рекомендуется увеличить объем дискового пространства до 600 ГБ и больше.

Расчеты для компонента Central Node, развернутого на платформе виртуализации KVM

Для развертывания компонента Central Node в виртуальной инфраструктуре должен быть установлен гипервизор KVM на базе операционной системы Debian GNU/Linux 12 с использованием эмулятора QEMU version 8.0.2.

При развертывании компонента Central Node в виртуальной инфраструктуре вам нужно учитывать следующие ограничения:

• Возможна установка только приложения с установочными файлами операционной системы Ubuntu.
• Возможна установка только неотказоустойчивой версии приложения.
• Возможно использование только компонента Sensor, развернутого на одном сервере с компонентом Central Node.
• Возможно подключение только компонента Sandbox, развернутого вне платформы виртуализации KVM на физическом сервере или на другой поддерживаемой платформе виртуализации.
• Для каждого сервера Central Node, развернутого в виртуальной инфраструктуре, необходимо использовать отдельный сетевой интерфейс для получения зеркалированного SPAN-трафика.
• Невозможно использование API для получения внешними системами информации об обнаружениях приложения и API для получения внешними системами информации о событиях приложения.
• Не гарантируется поддержка KVM-виртуализаций, используемых в облачных решениях.
• В настройках виртуальной машины необходимо установить значение host для параметра type в настройках CPU и значение VMware vmxnet3 для параметра model в настройках сетевой карты.

Аппаратные требования к серверу Central Node в зависимости от используемой функциональности представлены в таблице ниже.

Аппаратные требования к серверу Central Node при использовании функциональности KEDR

Аппаратные требования к серверу Central Node при использовании функциональности KATA и KEDR

В начало