Требования к инфраструктуре Почты VK WorkSpace

Хранилища

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

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

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

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

Какие диски использовать для сервисов

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

Сеть

Локальная сеть: 10 GbE.
Требование по задержке: RTT/latency ≤ 10 мс (в пределах локального контура/ЦОД/между ЦОД).
Пропускная способность каналов для пользовательского доступа рассчитывается исходя из количества пользователей и профиля активности. Ориентировочное значение: 5 МБ/с на пользователя.

CPU

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

Виртуализация

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

vCPU

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

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

RAM

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

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

Не включайте механизмы ballooning и сжатия памяти.

swap

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

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

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

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

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

Требования к настройкам операционной системы

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

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.
MosOS Arbat — версия 15.5, версия ядра — 5.14.

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

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

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

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

Пример настройки параметров ОС

Важно

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

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

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

Создайте файл /etc/security/limits.d/98-vkworkspace-limits.conf с настройками лимитов:
```
*    hard nofile 1048576
*    soft nofile 131072
*    hard nproc  257053
*    soft nproc  131072
root hard nofile 1048576
root soft nofile 262144
root hard nproc  514106
root soft nproc  262144
```
Дополнительные настройки для сертифицированной РЕД ОС 7.3

Файл /etc/sysctl.d/98-vkworkspace.conf с настройками sysctl для сертифицированной РЕД ОС 7.3 будет отличаться:
```
kernel.pid_max=4194304
net.ipv4.tcp_tw_reuse=1
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1
net.ipv4.tcp_syncookies = 1
```
До установки Почты VK WorkSpace:
1. Внесите изменение в конфигурации /etc/systemd/system.conf:
```
DefaultLimitNOFILE=524288:524288
```
2. Установите следующие пакеты из репозитория РЕД ОС 7.3, поставляемого с операционной системой:
  - docker-ce-cli-20.10.24-1.el7.x86_64
  - docker-ce-rootless-extras-20.10.24-1.el7.x86_64
  - docker-ce-20.10.24-1.el7.x86_64
  - docker-ce-20.10.24-1.el7.i686
  - docker-compose-2.29.2-1.el7.x86_64
  - docker-compose-switch-1.0.5-1.el7.x86_64
  Установить пакеты можно с помощью команды:
```
yum install docker-ce-cli-20.10.24-1.el7.x86_64 docker-ce-rootless-extras-20.10.24-1.el7.x86_64 docker-ce-20.10.24-1.el7.x86_64 docker-ce-20.10.24-1.el7.i686 docker-compose-2.29.2-1.el7.x86_64 docker-compose-switch-1.0.5-1.el7.x86_64
```
Дополнительные настройки для MosOS Arbat

Установите docker 20.x и docker-compose из репозитория MosOS:
```
zypper install -y docker docker-compose bind-utils ncat
```
Дополнительные настройки для Astra Linux 1.8

До установки Почты VK WorkSpace:
1. В файле /etc/default/grub, в строку параметра GRUB_CMDLINE_LINUX_DEFAULT добавьте parsec.execstack=1:
```
GRUB_CMDLINE_LINUX_DEFAULT="parsec.mac=0 quiet net.ifnames=0 parsec.execstack=1
```
2. Выполните команду sudo update-grub.
3. Перезагрузите машину.

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

sysctl -p /etc/sysctl.d/98-vkworkspace.conf
sysctl -p /etc/security/limits.d/98-vkworkspace-limits.conf
sysctl --system

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

Требования к синхронизации системного времени

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

Опциональные проверки инфраструктуры

InfraKit

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)

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

Архитектура «Клиент-Агент»

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

Флаги командной строки

Флаг	Описание
`--project-specific <file.yml>`	Обязательный. Путь к файлу спецификации проекта
`-c <config.yml>`	Путь к основному файлу конфигурации InfraKit. Пример файла конфигурации
`--infrakit.url <url>`	Адрес установщика, например `http://10.0.0.1:5555`. Сюда обращаются агенты
`--infrakit.bind <addr:port>`	Адрес и порт, на которых слушает установщик. По умолчанию `0.0.0.0:5555`
`--infrakit.log syslog`	Запись логов в syslog
`--infrakit.ssh.user`	Пользователь для SSH-подключения
`--infrakit.ssh.key`	Путь к приватному SSH-ключу
`--infrakit.ssh.key_pass`	Пароль для расшифровки SSH-ключа
`--mode <install/post_install>`	Режим работы: `install` (перед установкой) или `post_install` (после установки)
`--agent`	Запуск InfraKit в режиме агента на удалённом хосте
`--daemon`	Режим демона. Не завершает работу после проверок, обрабатывает HTTP-запросы
`--log-level <debug/info/warn/error>`	Уровень логирования: `debug`, `info`, `warn`, `error`
`--show-details`	Показ детального лога выполнения (без прогресс-бара)
`--render-only`	Показ итогового плана проверок (с учётом наследований) и выход
`--render-hosts`	Показ списка всех хостов и выход
`--render-output <file>`	Сохранение результата рендеринга в файл. Если не указано — в лог

Особенности настройки YAML

Служебный класс (`all`)

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

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

Наследование классов (`extends`)

Ключевое слово 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 поддерживает два способа описания целевых узлов:

Простой формат (список строк) — используется массив IP-адресов или доменных имен. В этом случае для подключения применяются настройки по умолчанию, заданные через флаги командной строки (--infrakit.ssh.user, --infrakit.ssh.key) или в файле конфигурации.
```
hosts: ["10.0.0.1", "10.0.0.2", "app-server.local"]
```
Расширенный формат (список объектов) — позволяет гибко переопределить параметры подключения для конкретных серверов.

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"

Примечание

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

Настройка выполнения (`execution`)

В 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"  # Файл для записи логов работы

Параметры вывода (`output`)

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

Логирование (`logging`)

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

Внимание

Если файл лога не указан, логи будут выводиться в реальном времени в консоль (stdout/stderr).

Настройка через файл конфигурации

Помимо флагов командной строки, параметры 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, где интерактивный терминал недоступен.

Жизненный цикл выполнения

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

Тонкости и рекомендации

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

Пример запуска InfraKit

Откройте файл /home/deployer/configs/infrakit/project-spec.yaml. Впишите в него IP-адреса соответствующих гипервизоров.
Обеспечьте возможность открытия SSH-сессии с гипервизора monitoring на остальные гипервизоры. Используйте SSH-ключ для пользователя deployer.
Запустите 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

Результат проверок будет записан в файл, путь к которому указан в секции 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": "Успех"
        },
...