Требования к серверу для кластера

Кластер — совокупность серверов, расположенных в единой локации. Отличительными чертами таких серверов (узлов кластера) являются расположение и высокая скорость передачи данных между ними. В статье указаны требования к узлам кластера. 

Гомогенность узлов

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

Платформа не поддерживает работу кластеров, в которых совместно используются узлы с ОС на основе Red Hat (AlmaLinux) и ОС на основе Debian (Astra Linux).

Поддержка виртуализации

Узел кластера KVM должен поддерживать виртуализацию на уровне процессора. Чтобы проверить наличие поддержки для процессоров Intel и AMD, введите команду:

grep -P 'vmx|svm' /proc/cpuinfo

Если вывод команды не пустой, то процессор поддерживает виртуализацию.

Чтобы использовать виртуализацию, убедитесь, что она включена в BIOS сервера.

Аппаратные требования

Узлом кластера должен быть физический сервер со следующими характеристиками:

Материнская плата

Рекомендуем использовать серверную материнскую плату. Узел кластера с материнской платой для настольного ПК может работать некорректно.

В случае возникновения проблем с производительностью дисковой подсистемы рекомендуем включить в настройках BIOS режим энергопотребления c максимальной производительностью.

Процессор

Поддерживаются процессоры Intel и AMD с архитектурой x86_64. Процессоры с архитектурой ARM не поддерживаются.

Диск и хранилища

При разбивке диска выделите максимально возможный объём под корневую директорию (/).

Перед добавлением узла в существующий кластер настройте на сервере все хранилища, используемые в кластере. Для кластеров LXD требуется настройка ZFS-хранилища. Подробнее см. в статье LXD.

Программные требования

Операционная система

Требования к операционной системе (ОС) зависят от типа виртуализации и сетевых настроек кластера:

Минорные версии ОС и версии ядра ОС на узлах кластера могут различаться.

Используйте немодифицированную ОС в минимальной редакции: без сторонних репозиториев и установленных дополнительных сервисов.

Чтобы обеспечить гомогенность системного ПО, рекомендуется периодически обновлять ОС на узлах кластера.

AlmaLinux

Для AlmaLinux версий ниже 8.8-3.el8 перед добавлением узла кластера выполните инструкции из статьи базы знаний Ошибка проверки GPG-ключа репозиториев Almalinux.

Astra Linux

• Чтобы подготовить узел кластера с ОС Astra Linux, выполните инструкции из статьи Подготовка сервера с ОС Astra Linux.
• Обновление с ОС Astra Linux 1.7.1, 1.7.2 до 1.7.3 не поддерживается.

CentOS

Программное обеспечение

Для корректной работы узла кластера не изменяйте стандартное приветствие командной строки в файле .bashrc.

Чтобы платформа могла подключиться к узлу кластера, на узле должны быть установлены пакеты ПО dmidecode и python3. Если это ПО не входит в состав ОС, установите его вручную.

Отключение службы SELinux

Служба SELinux используется в качестве дополнительного средства безопасности ОС. Рекомендуем отключить службу SELinux, так как она замедляет работу платформы и может помешать её корректной установке.

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

Чтобы отключить SELinux:

1. Проверьте статус службы: 

   sestatus

2. Если ответ содержит enforcing или permissive:

   1. В файле /etc/selinux/config установите для параметра SELINUX значение disabled: 

      sed -i s/^SELINUX=.*$/SELINUX=disabled/ /etc/selinux/config

   2. Перезагрузите сервер.

Обновление ОС

После обновления ОС на узле кластера перезапустите сервис libvirt:

systemctl restart libvirtd

Системное время

Перед подключением узла системное время должно быть синхронизировано с NTP-сервером. Для этого настройте синхронизацию с помощью ПО:

• chrony — для ОС AlmaLinux;
• ntp — для ОС Astra Linux.

Для серверов в дата-центре OVH

При установке ОС через панель управления OVH включите опцию Install original kernel. Для корректной работы серверов кластера используйте оригинальное ядро ОС.

Сетевые настройки

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

• у каждого сервера должно быть уникальное имя хоста (hostname);
• в кластерах с типом настроек "Коммутация" и "Маршрутизация" в открытом информационном контуре сервер должен иметь доступ в интернет. Это необходимо для загрузки шаблонов ОС и пакетов ПО из внешних источников;
• IP-адрес должен находиться на физическом интерфейсе сервера или во VLAN;
• IP-адрес должен быть статическим и задан через конфигурационный файл сетевого интерфейса (без использования DHCP);
• если в кластере с типом настроек "Коммутация" для ВМ выделяются IPv6-адреса, один из адресов IPv6-сети должен быть присвоен интерфейсу узла;
• шлюз по умолчанию должен быть доступен для проверки утилитой ping;
• имена сетевых интерфейсов не должны содержать букв, отличных от латинских.

Требования к узлам кластера с двумя сетевыми интерфейсами см. в статье Основная и дополнительная сеть.

Если сервер находится в дата-центре Hetzner, не рекомендуем использовать функцию vSwitch. Эта функция ограничивает общее количество MAC-адресов, используемых физическими и виртуальными интерфейсами сервера, до 32.

auto bond0
iface bond0 inet manual
bond-mode 1
bond-miimon 100
bond-slaves eth0 eth1

auto bond0.5
iface bond0.5 inet static 
address 192.168.181.69/26
gateway 192.168.181.65

auto bond0
iface bond0 inet manual
    bond-mode 1
    bond-miimon 100
    bond-slaves eth0 eth1

auto bond0.5
iface bond0.5 inet manual 
    vlan-raw-device bond0

auto vmbr0
iface vmbr0 inet static
    address 192.168.181.69/26
    gateway 192.168.181.65
    bridge_ports bond0.5
    bridge_stp off

DEVICE="bond0.4"
VLAN="yes"
ONBOOT="yes"
BOOTPROTO="none"
IPADDR=10.3.0.62
PREFIX=24
NETMASK=255.255.255.0
GATEWAY=10.3.0.1
DNS1=8.8.8.8
DNS2=8.8.4.4

DEVICE="bond0"
TYPE="Bond"
BONDING_MASTER="yes"
ONBOOT="yes"
BOOTPROTO="none"
BONDING_OPTS="mode=active-backup"

TYPE=Ethernet
DEVICE=enp1s0f0
UUID=b47d0044-55ca-40d2-be0c-3d4a65a9985d
ONBOOT=yes
DEFROUTE=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
NAME="System enp1s0f0"
SLAVE=yes
MASTER=bond0

DEVICE="bond0.4"
VLAN="yes"
ONBOOT="yes"
BOOTPROTO="none"
BRIDGE="vmbr0"

DEVICE="vmbr0"
TYPE="Bridge"
ONBOOT="yes"
BOOTPROTO="none"
STP="no"
IPV6INIT="no"
IPADDR=10.3.0.62
PREFIX=24
NETMASK=255.255.255.0
GATEWAY=10.3.0.1
DNS1=8.8.8.8
DNS2=8.8.4.4

Файл /etc/hosts

Убедитесь, что в файле /etc/hosts есть запись для сервера в формате:

<IP-адрес сервера> <hostname сервера>

Файл /etc/resolv.conf

Убедитесь, что в файле /etc/resolv.conf есть записи вида:

nameserver <IP-адрес DNS-сервера>

Если в качестве DNS-сервера указан IP-адрес локальной службы systemd-resolved — 127.0.0.53, то проверьте, что в файле /etc/systemd/resolved.conf указаны адреса DNS-серверов:

DNS=<список_серверов>

Настройки входящих подключений

KVM-виртуализация

Разрешите входящие подключения на порты:

• 22/tcp — сервис SSH;
• 179/tcp, 4789/udp — виртуальные сети (VxLAN);
• 5900-6900/tcp — QEMU VNC, SPICE. Если доступ осуществляется только через сервер с VMmanager, диапазон портов должен быть открыт для сети, объединяющей узлы кластера;
• 16514/tcp — сервис управления виртуальными машинами libvirt;
• 49152-49215/tcp — сервисы миграции libvirt.

LXD-виртуализация

Разрешите входящие подключения на порты:

• 22/tcp — сервис SSH;
• 179/tcp, 4789/udp — виртуальные сети (VxLAN);
• 8443/tcp — сервис управления LXD-контейнерами.

Закрытый информационный контур

Чтобы подготовить сервер для закрытого контура, выполните инструкции из статьи Установка в закрытом информационном контуре.