Представители VK предоставляют вам:

• Ссылку на скачивание дистрибутива Почты.
• Лицензионный ключ.
• Комплект документации.

Также вам потребуется:

• Набор DNS-записей: A, CNAME, MX, SPF, TXT, NS — см. DNS-записи.
• DKIM-подпись с селекторами для каждого домена (или несколько DKIM с разными селекторами для одного домена).
• Доступ к серверам по SSH с правами администратора (вход по ключу или по паролю).
• Сертификаты SSL для каждого CNAME или Wildcard-сертификат для домена — см. Как работать с Wildcard-сертификатами.
• Доступ к портам — см. Протоколы и порты.
• Процессоры с поддержкой необходимого набора инструкций — см. CPU.
• Локальная сеть — см. Сеть.
• Отключенный файл подкачки (swap).
• Утилита tar и утилита для распаковки zip-архивов, например 7zip или unzip.
• Active Directory или другая служба каталогов, работающая по протоколу LDAP.

Некоторые компоненты инфраструктуры не входят в состав поставки и обеспечиваются силами заказчика:

• Балансировщик входящего трафика — распределяет входящие соединения между серверами инсталляции. Пример настройки приведен в документе Как распределять нагрузку с помощью HAProxy.
• DNS-сервер — требуемые записи перечислены в разделе DNS-записи.
• Служба каталогов — Active Directory или другая, работающая по протоколу LDAP.
• Сервер синхронизации системного времени (NTP) — см. Требования к синхронизации системного времени.
• Сертификаты SSL для каждого CNAME или Wildcard-сертификат для домена — см. Как работать с Wildcard-сертификатами.
• Корпоративный антивирус, если он используется в инфраструктуре заказчика, — см. Как правильно настроить антивирус.

• Astra Linux SE Орел — версия 1.7.5+, версия ядра — 5.15.
• Astra Linux SE Орел — версия 1.8, версия ядра — 6.1.
• РЕД ОС — версия 7.3.5, версия ядра — 6.1.
• РЕД ОС — версия 7.3с (сертифицированная), версия ядра — 6.1.
• РЕД ОС — версия 8, версия ядра — 6.6 или 6.12.

Архитектура системы — x86_64.

Обновлять операционную систему можно только на поддерживаемую версию и только после консультации с представителем VK. Список поддерживаемых ОС может быть уточнен в рамках работ по индивидуальному проекту.

Версия Docker Engine — 20.10.2023.

Для Astra Linux SE Орел требуется уровень защищенности 0-Базовый и отключенный режим мандатного контроля целостности. Проверить:

 
sudo set-fs-ilev status -vcat /etc/astra_license

Поддерживаемые версии десктопных операционных систем и веб-браузеров приведены в документе Поддерживаемые версии веб-браузеров и ОС.

Совместимость мобильного приложения Суперапп VK WorkSpace с мобильными операционными системами:

Поддерживаются мобильные почтовые приложения соответствующей ОС, работающие по протоколам IMAP/S и SMTP/S.

• Требования к отказоустойчивости решения приведены в документе Обеспечение отказоустойчивости VK WorkSpace.
• Требования к катастрофоустойчивости решения приведены в документе Обеспечение катастрофоустойчивости VK WorkSpace.

• Используйте процессоры Intel(R) Xeon(R) Gold 6338 2.2GHz и новее. Допускается использовать эквивалентные модели по количеству ядер и производительности.
• CPU должен поддерживать следующие инструкции: 3DNow, ADX, AES, AVX, AVX2, BMI, BMI2, CMOV, MMX, MODE64, NOT64BITMODE, NOVLX, PCLMUL, SHA, SSE1, SSE2, SSE41, SSE42, SSSE3 и XOP.

Проверить набор флагов процессора:

 
lscpu

В выводе должны присутствовать флаги sse2, avx, avx2, bmi.

Если вы используете системы виртуализации для развертывания серверов VK WorkSpace необходимо учитывать особенности выделения ресурсов:

vCPU

Запрещено допускать переподписку. Суммарные vCPU на хосте не должны превышать количество физических ядер, выделенных всем виртуальным машинам. При этом не рекомендуется считать Hyper-Threading полноценными ядрами.

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

RAM

Запрещено назначать суммарную vRAM выше физической RAM хоста.

Механизмы экономии памяти

Запрещено включать механизмы ballooning и сжатия памяти.

swap

Запрещено использовать swap — как на гипервизоре, так и внутри виртуальных машин.

Резервирования ресурсов виртуальных машин

Устанавливайте всю выделенную память и процессоры в резерв для виртуальных машин системы.

Диски и бэкапы

• Не используйте тонкие диски (диски типа Thin) — диски с отложенным выделением пространства на СХД.
• Виртуальные диски для следующих разделов должны быть разнесены по разным физическим устройствам:
  • ОС.
  • Файлы.
  • Журналы.
  • Данные.
• Резервное копирование и снапшоты должны выполняться в периоды минимальной нагрузки.

Поддерживаются 2 варианта размещения хранилищ:

• Внешняя СХД: SAN, FC, iSCSI и подобные.
• Встроенные диски (DAS). Локальные диски сервера, включая JBOD.

Общие требования к размещению:

• Под компоненты Почты необходимо выделить отдельные LUN/разделы/диски.
• По возможности не размещайте другие системы на тех же разделах/пулах СХД. Следует избегать влияния нагрузки сторонних систем на Почту.
• Выделите отдельные LUN/разделы/диски для:
  • Файлов ОС.
  • Системных журналов.
  • Данных сервисов системы.
• Не используйте тонкие диски (thin provisioned disks) — диски с отложенным выделением пространства, как на уровне СХД, так и на уровне виртуализации.

• Для ETCD используйте отдельные LUN на быстрых дисках. Требование по задержке: p99 latency I/O ≤ 10 мс при 10 000 IOPS
• Серверы БД (PostgreSQL, Tarantool) разместите на обычных дисках. При этом каждый экземпляр БД размещайте на отдельном LUN, разделе или диске. Даже табличные пространства баз данных рекомендуется определять на разные разделы.
• Сервисы хранения (zepto, mescalito) разместите на обычных дисках. Допускается размещение на медленных дисках только при кратном увеличении количества сервисов и дисков, чтобы компенсировать низкую производительность. При размещении учитывайте объем данных и интенсивность использования.
• Для файловых хранилищ можно использовать медленные диски.

Тип диска на уровне виртуализации или СХД должен быть fat provisioning, а не thin provisioning: весь выделенный объем должен быть заранее зарезервирован и гарантированно доступен.

Минимальные требования к SSD-дискам:

Точные показатели определяются при анализе запланированного профиля нагрузки. Промышленных решений с показателями 800 000 – 1 000 000 IOPS достаточно.

Тип диска на уровне виртуализации или СХД должен быть fat provisioning, а не thin provisioning.

Минимальные требования к локальным HDD-дискам:

Точные показатели определяются при анализе запланированного профиля нагрузки. Промышленных решений на базе SAS 15 000 rpm с кэшем 128 Мб достаточно.

Локальные HDD-диски можно подключать только к некоторым компонентам Почты. Такие компоненты помечены в веб-интерфейсе установщика.

Проверка совместимости с другими типами СХД осуществляется индивидуально. Обратитесь к представителям VK за консультацией.

Минимальные требования к разделам. Эти значения проверяет InfraKit перед установкой:

Если планируется установка Почты и Мессенджера, то минимальный размер точки /tmp увеличивается до 90 Гб.

Требования к производительности разделов — не менее 1000 IOPS на чтение и 500 IOPS на запись (замер длительностью 10 секунд). Производительность проверяется для разделов /, /boot, /home, /var/log, /var/lib/docker и /opt.

В зависимости от количества пользователей может быть увеличен объем памяти раздела /opt/mailOnPremise/dockerVolumes.

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

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

На разделах дисков необходимо создать файловую систему. Мы рекомендуем ext4, также поддерживается xfs.

Пример команды для создания файловой системы ext4:

 
mkfs.ext4 <путь к устройству>

• Локальная сеть: 10 GbE.

• Требование по задержке: RTT/latency ≤ 10 мс (в пределах локального контура/ЦОД/между ЦОД).

• Пропускная способность каналов для пользовательского доступа рассчитывается исходя из количества пользователей и профиля активности. Ориентировочное значение: 5 МБ/с на пользователя.

• Пропускная способность для серверных компонентов кластера — не ниже 10 Гбит/с.

• Пропускная способность для клиентских подключений определяется экспериментально на уровне протокола IMAP и веб-интерфейса, исходя из приемлемой для пользователя скорости.

• SMTP, ESMTP — протоколы отправки почтовых сообщений (порт 2525/465).
• IMAP — протокол получения почтовых сообщений (порт 143/993).
• POP3 — протокол получения почтовых сообщений (порт 110/995).
• HTTPS для доступа к веб-интерфейсу почты с использованием TLS.
• CalDAV для синхронизации календаря.
• CardDAV для синхронизации и управления контактами.
• WebDAV для работы с Диском.
• Kerberos или NTLM — протокол взаимодействия с Active Directory клиента.
• IP in IP — протокол туннелирования IP.

Чтобы обеспечить безопасность Почты, на ваших серверах должны быть доступны только необходимые порты. Для доступа к веб-интерфейсу: 80 (http), 443 (https). Для отправки и получения почты: 2525 (smtp), 25 (mx), 110 (pop3), 995 (pop3s), 143 (imap), 465 (smtps), 993 (imaps). Вы должны сами определить, с каких IP-адресов будут доступны порты.

• Порты для пользователей: 25, 80, 143, 443, 465, 993, 1025. При кластерной установке дополнительно нужен порт 2525.
• Административные порты: 22, 8888*, 5555. При установке на одну машину дополнительно нужен порт 50051.

Порт 8888 используется сервисом deployer (установщик). Рекомендуется применять следующие наложенные средства защиты:

• Отдельный mTLS прокси-сервер с обязательной проверкой клиентских сертификатов. Управление ключами происходит посредством PKI заказчика.
• Использование (меж)сетевых экранов как на операционной системе сервера установщика, так и на активном сетевом оборудовании.
• Прокси-сервера для аутентификации и авторизации посредством простого пароля, Kerberos или доменного пароля.

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

Для защиты сетевых соединений между серверами, виртуальными машинами и контейнерами почтовой системы используется ПО WireGuard.

Для работы Почты вам нужны:

• MX-запись (рекомендуемый приоритет — 10), которая обязательно ведет на mxs.<домен для почты>
• Набор A- или CNAME-записей.

Выберите поддомен, на котором будут доступны пользовательский и административный интерфейсы VK WorkSpace. Например, если домен вашей организации — onprem.ru, а выбранный поддомен — mail.onprem.ru, то интерфейсы будут доступны по адресам:

• https://e.mail.onprem.ru — Почта VK WorkSpace.
• https://biz.mail.onprem.ru — панель администратора.

Домен для облачных хранилищ должен быть того же уровня, что и основной домен для сервисов. То есть если основной домен третьего уровня, то и домен для хранилищ будет третьего уровня, если основной четвертого — то и домен для хранилищ четвертого, и так далее. В нашем примере это mail-st.onprem.ru.

Все остальные перечисленные ниже домены будут поддоменами этих двух доменов.

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

Для почты:

Как создается домен: account (субдомен из таблицы) + mail.onprem.ru (основной домен из примера, который вы замените своим) = account.mail.onprem.ru.

Для хранилищ:

Как создается домен: tmpatt (субдомен из таблицы) + mail-st.onprem.ru (основной домен из примера, который вы замените своим) = tmpatt.mail-st.onprem.ru.

Один wildcard-сертификат охватывает только один уровень поддоменов. Это означает, что wildcard-сертификат выпущенный для domain.ru будет действительным для всех его субдоменов третьего уровня, но не будет работать для четвертого. Соответственно если необходима защита поддоменов четвертого и далее уровней нужно получить отдельный wildcard-сертификат для родительского домена каждого из них. Например, домен для почты mail.onprem.ru, а домен для хранилища mail-st.onprem.ru, тогда в сертификат необходимо добавить шесть доменов:

• *.mail.onprem.ru
• *.e.mail.onprem.ru
• *.cloud.mail.onprem.ru
• *.calendartouch.mail.onprem.ru
• *.calendarx.mail.onprem.ru
• *.mail-st.onprem.ru

Поддерживаемые операционные системы для установки Почты:

• Astra Linux SE Орел — версия 1.7.5+, версия ядра — 5.15.
• Astra Linux SE Орел — версия 1.8, версия ядра — 6.1.
• РЕД ОС — версия 7.3.5, версия ядра — 6.1.
• РЕД ОС — версия 7.3с (сертифицированная), версия ядра — 6.1.
• РЕД ОС — версия 8, версия ядра — 6.6 или 6.12.

Архитектура системы — x86_64.

Отключите файл подкачки swap.

Отключите службу аудита auditd — включенный аудит может создавать значительную нагрузку на серверы.

Разнесите разделы ниже по разным точкам монтирования:

• /boot;
• /;
• /home;
• /var/log;
• /var/lib/docker;
• /opt;
• /tmp.

1. Создайте файл /etc/sysctl.d/98-vkworkspace.conf с настройками sysctl:

    
   kernel.pid_max=4194304net.ipv4.tcp_tw_reuse=1net.netfilter.nf_conntrack_tcp_timeout_time_wait=3net.netfilter.nf_conntrack_tcp_timeout_fin_wait=5net.ipv6.conf.all.disable_ipv6=1net.ipv6.conf.default.disable_ipv6=1net.ipv6.conf.lo.disable_ipv6=1net.netfilter.nf_conntrack_max=4194304net.ipv4.tcp_syncookies=1net.ipv4.ip_forward=1

2. Создайте файл /etc/security/limits.d/98-vkworkspace-limits.conf с настройками лимитов:

    
   *    hard nofile 1048576*    soft nofile 131072*    hard nproc  257053*    soft nproc  131072root hard nofile 1048576root soft nofile 262144root hard nproc  514106root soft nproc  262144

   Дополнительные настройки для сертифицированной РЕД ОС 7.3
   Дополнительные настройки для Astra Linux 1.8

3. Примените изменения:

    
   sysctl -p /etc/sysctl.d/98-vkworkspace.confsysctl --system

   Или перезагрузите операционную систему.

На каждом сервере проверьте текущее состояние SELinux:

 
sestatus

Параметр SELinux status должен иметь значение disabled. Если выводится другое значение:

1. Откройте для редактирования файл /etc/selinux/config.
2. Измените значение параметра SELINUX на disabled.
3. Перезагрузите операционную систему.
4. Повторно проверьте состояние SELinux с помощью команды sestatus.
5. Параметр SELinux status должен иметь значение disabled. SELinux будет отключен.

В файле /etc/ssh/sshd_config разрешите перенаправление по протоколу TCP:

 
AllowTcpForwarding yes

Опцию можно открыть только для группы пользователей deployer:

 
AllowTcpForwarding noMatch Group workspace-deployers    AllowTcpForwarding local

Чтобы создать группу выполните:

 
sudo groupadd workspace-deployerssudo usermod -aG workspace-deployers deployer

Параметр MaxSessions по умолчанию равен 10 — уменьшать его нельзя.

На уровне ОС не должно быть запретов на создание IP forward. Проверить можно с помощью команды:

 
cat /proc/sys/net/ipv4/ip_forward

Если параметр неактивен, задайте параметр ядра net.ipv4.ip_forward=1.

Выполните шаги из инструкции Как настроить ротацию логов в journald.

На всех машинах проверьте антивирусное решение и выполните следующие настройки:

• Добавьте в исключения:
  • /opt/mailOnPremise — данные приложений, логи, БД, хранилища. Нельзя детализировать файлы и подкаталоги, нужно добавить весь каталог /opt/mailOnPremise в исключения.
  • /home/deployer/ — данные для инсталлятора, установка обновлений.
  • Диски для хранилища.
  • /var/lib/docker/.
• Отключите проверку контейнеров: ScanContainers: No, ContainerNameMask: *.
• Не настраивайте firewall на следующие сетевые интерфейсы:
  • cali*
  • docker*
  • wireguard*
  • tun*
• Добавьте в исключения публичные порты из раздела Протоколы и порты.
• Если вы используете KESL, то на серверах для сервисов контейнеризации отключите задачи по защите от веб-угроз и защите от сетевых угроз.

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

InfraKit — это инструмент для автоматической проверки состояния серверов, сетевой связности и доступности сервисов перед установкой программного обеспечения (режим install) и после нее (режим post_install).

Начиная с версии 26.1 используйте InfraKit для проверок серверов, где запущен VK WorkSpace. Файлы InfraKit расположены на гипервизоре monitoring:

• Запускаемый файл — /home/deployer/configs/infrakit/infrakit-bin
• Файл конфигурации — /home/deployer/configs/infrakit/project-spec.yaml

Логика проверок описывается в YAML-файле (обычно project-specific.yml). Файл содержит описание классов проверок, список хостов и общие настройки выполнения.

1. Deploy-нода (установщик) — это узел, с которого запускается InfraKit. Он управляет процессом, подключается к целевым хостам по SSH и собирает результаты.
2. Агенты — установщик копирует бинарный файл InfraKit на целевые хосты и запускает его в режиме --agent. Агенты выполняют проверки локально и отправляют результаты обратно на установщик через HTTP API.

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

 
classes:  all:    os:      distribution: "redos"    sudo:      passwordless: true

Ключевое слово extends строит иерархию требований. Это избавляет от дублирования и показывает специализацию серверов.

Пример явного наследования:

 
classes:  # Базовый набор характеристик для любого сервера  base-node:    os:      distribution: "centos"      min_version: "7.9"    cpu:      min_cores: 2    memory:      total: "4Gb"  # Специализация: сервер базы данных  db-server:    hosts: ["10.0.0.10", "10.0.0.11"]    extends: ["base-node"] # Наследует все из base-node    storage:      - mount_point: "/var/lib/postgresql"        min_free: "100Gb"  # Специализация: API шлюз  api-gateway:    hosts: ["10.0.0.20"]    extends: ["base-node"]    ports:      - protocol: "tcp"        ports: [80, 443]

Поле hosts поддерживает два способа описания целевых узлов:

1. Простой формат (список строк) — используется массив IP-адресов или доменных имен. В этом случае для подключения применяются настройки по умолчанию, заданные через флаги командной строки (--infrakit.ssh.user, --infrakit.ssh.key) или в файле конфигурации.

    
   hosts: ["10.0.0.1", "10.0.0.2", "app-server.local"]

2. Расширенный формат (список объектов) — позволяет гибко переопределить параметры подключения для конкретных серверов.

    
   hosts:  - ip: "10.0.0.5"                        # IP-адрес или доменное имя хоста    ssh_user: "deploy"                    # Имя пользователя    ssh_key: "/home/infrakit/.ssh/id_rsa" # Путь к приватному SSH-ключу    ssh_key_pass: "my_secure_pass"        # Пароль для расшифровки ключа  - ip: "db-node-01"    ssh_user: "root"

В YAML-файле проекта можно задать глобальные настройки выполнения проверок, отчетности и логирования. Эти параметры указываются в корневом объекте execution.

 
execution:  performance:    max_check_duration: 30s    # Максимальное время выполнения одной проверки    parallel_hosts: 10         # Количество хостов, опрашиваемых параллельно    retry_count: 3             # Количество повторных попыток при сбоях сети    retry_delay: 5s            # Задержка между повторными попытками  output:    format: "text"             # Формат отчета: text, json, csv    language: "eng"            # Язык отчета: en/eng или ru    output_file: "output.txt"  # Путь для сохранения финального отчета    color_enabled: true        # Включить цвета в терминале (для text)    detailed_recommendations: true # Выводить советы по исправлению ошибок  logging:    level: "info"              # Уровень логирования: debug, info, warn, error    file: "/tmp/infrakit.log"  # Файл для записи логов работы

• format — определяет вид итогового отчета. Поддерживаются text (для чтения человеком), json (для парсинга системами) и csv (для таблиц).
• language — язык, на котором будут написаны сообщения об ошибках и рекомендации. Доступны английский (en, eng) и русский (ru).
• output_file — если указан путь к файлу, итоговый отчет будет записан в него. Если поле пустое, отчет выводится в стандартный поток вывода после завершения всех проверок.

• file — если указан путь к лог-файлу, все сообщения о процессе работы (подключения, запуск агентов, промежуточные статусы) будут писаться в этот файл.

Помимо флагов командной строки, параметры InfraKit можно задать в файле конфигурации. Использование ключа -c позволяет компактно передать все настройки SSH, сетевые адреса и параметры логирования.

 
easygo:  http:    stat:      response_code: false      response_size: false      time: false  timings:    stat: true    log: false  stat:    enable_log: false    enable_graphite: false    graphite:      addr: "127.0.0.1:2004"      prefix: "infrakit"      network_type: "tcp"infrakit:  bind: "0.0.0.0:5555"  url: "http://192.168.100.5:5555"  log:    syslog: false  ssh:    user: "cloud-user"    key: "/home/cloud-user/.ssh/id_rsa"

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

• Объединение (Merge) — если для одного и того же хоста заданы проверки в разных классах, InfraKit объединит их в один общий список задач для этого узла.
• Уникальность — дубликаты проверок одного типа (например, два требования к объему RAM) фильтруются, чтобы избежать повторного выполнения.

Если вы хотите запустить проверки на узле, с которого ведется установка, укажите его IP-адрес в параметре --infrakit.url при запуске. Добавьте этот IP в список hosts нужного класса в файле спецификации (YAML).

InfraKit автоматически определит, что IP хоста совпадает с его собственным, и выполнит проверки локально, без использования SSH. В интерфейсе такие проверки будут помечены как (deployer).

По умолчанию InfraKit отображает индикаторы выполнения (Progress Bars) для каждого хоста. Это позволяет наглядно отслеживать количество успешно выполненных и проваленных проверок в реальном времени.

Если вы хотите видеть детальный лог выполнения каждой проверки вместо графических индикаторов, используйте флаг --show-details

При этом вывод будет текстовым, что удобно для отладки или запуска в системах CI/CD, где интерактивный терминал недоступен.

1. Чтение конфигурации — программа парсит YAML, разрешает зависимости классов и формирует список задач для каждого хоста.
2. Проверка уникальности — проверяется, что хосты не указаны одновременно как по IP, так и по Hostname.
3. Инъекция (Injection) — установщик подключается по SSH к каждому узлу, проверяет наличие sudo без пароля и копирует бинарный файл InfraKit.
4. Запуск Агентов — на удаленных хостах запускается процесс infrakit --agent.
5. Выполнение — агенты выполняют проверки (CPU, Disk, Net и т.д.) и рапортуют о статусе.
6. Сбор отчетов — установщик консолидирует данные и формирует финальный отчет в заданном формате (Text, JSON или CSV).

• SSH-права — убедитесь, что пользователю, указанному в --infrakit.ssh.user, разрешен запуск sudo без ввода пароля (NOPASSWD). Это критическое требование для работы агента.
• Сетевые порты — если вы проверяете сетевую связность (connectivity) или скорость (iperf), InfraKit автоматически поднимает временные «эхо-серверы» на целевых портах. Убедитесь, что эти порты не заняты другими процессами и открыты в Firewall.
• IP / Hostname — рекомендуется использовать единообразный способ именования хостов во всем файле. Использование одного и того же сервера по IP в одном месте и по Hostname в другом может привести к конфликтам.

1. Откройте файл /home/deployer/configs/infrakit/project-spec.yaml. Впишите в него IP-адреса соответствующих гипервизоров.

2. Обеспечьте возможность открытия SSH-сессии с гипервизора monitoring на остальные гипервизоры. Используйте SSH-ключ для пользователя deployer.

3. Запустите InfraKit от имени пользователя deployer командой:

    
   /home/deployer/configs/infrakit/infrakit-bin --project-specific /home/deployer/configs/infrakit/project-spec.yaml --infrakit.bind 0.0.0.0:5555 --infrakit.url 100.70.178.76

   Аргументом для параметра infrakit.url должен быть внешний адрес гипервизора, на котором происходит запуск --infrakit.url 100.70.178.76

4. Результат проверок будет записан в файл, путь к которому указан в секции execution.output.output_file конфигурационного файла:

    
   execution:  output:    output_file: <путь_к_файлу>

   Пример результата:

    
   {  "total_hosts": 3,  "total_checks": 80,  "hosts": [    {      "host": "100.70.177.139",      "checks": [        {          "check_name": "cpu cores",          "description": "Количество ядер ЦПУ: Текущее 2 сокетов, 16 ядер (16 потоков) | Ожидается 8 ядер (0 потоков)",           "status": "Успех"        },...