Рекомендации

Конфигурация, описанная в этом разделе, не является обязательной, но может повысить стабильность или производительность вашего развертывания.

1. Общие рекомендации

  • Сразу после завершения развертывания создайте полную резервную копию и храните ее в отдельном месте. После этого регулярно создавайте резервные копии. Подробности см. в Руководстве по резервному копированию и восстановлению Менеджера управления.

  • Избегайте запуска любой службы, от которой зависит развертывание (например, DNS), в качестве виртуальной машины в той же среде. Если вам необходимо запустить требуемую службу в том же развертывании, тщательно спланируйте развертывание, чтобы свести к минимуму время простоя виртуальной машины, на которой запущена требуемая служба.

  • Убедитесь, что гиперконвергентные хосты обладают достаточной энтропией. Сбои могут происходить, если значение в файле /proc/sys/kernel/random/entropy_avail меньше 200. Чтобы увеличить энтропию, установите пакет rng-tools.

  • Документируйте свою среду, чтобы все, кто с ней работает, знали о ее текущем состоянии и необходимых процедурах.

2. Рекомендации по безопасности

  • Не отключайте никакие функции безопасности (такие как HTTPS, SELinux и брандмауэр) на хостах или виртуальных машинах.

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

  • Ограничьте доступ к хостам и создайте отдельные учетные записи. Не используйте одну учётную запись с правами root на всех хостах виртуализации.

  • Не создавайте на хостах недоверенных пользователей.

  • Избегайте установки дополнительных пакетов, таких как анализаторы, компиляторы и другие компоненты, которые повышают риск безопасности.

3. Рекомендации по хостам

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

  • Настройте устройства ограждения во время развертывания. Устройства ограждения необходимы для обеспечения высокой доступности.

  • Используйте отдельные аппаратные коммутаторы для ограждения трафика. Если мониторинг и ограждение проходят через один коммутатор, этот коммутатор становится единой точкой отказа для обеспечения высокой доступности.

  • Конфигурация хостов в гиперконвергентном кластере должна быть максимально схожей. Наиболее важно обеспечить идентичность:

    • Технологий доступа к накопителям.

    • Объемы накопителей.

    • Скорость чтения/записи накопителей.

4. Рекомендации по работе с сетью

  • Объединяйте сетевые интерфейсы, особенно на продуктивных хостах. Объединение улучшает общую доступность, а также пропускную способность сети.

  • Стабильная сетевая инфраструктура использующая DNS и DHCP.

  • Если объединения сетевых интерфейсов (bonding) будут использоваться совместно с другим сетевым трафиком, необходимо обеспечить надлежащее качество обслуживания (QoS) для хранилища и другого сетевого трафика.

  • Для оптимальной производительности и упрощения поиска и устранения неисправностей используйте виртуальные локальные сети для разделения различных типов трафика и оптимального использования сетей 10 GbE или 40 GbE.

  • Если базовые коммутаторы поддерживают jumbo frames, установите MTU на максимальный размер (например, 9000), который поддерживают базовые коммутаторы. Эта настройка обеспечивает оптимальную пропускную способность, более высокую пропускную способность и меньшее использование ЦП для большинства приложений. MTU по умолчанию определяется минимальным размером, поддерживаемым базовыми коммутаторами. Если у вас включен LLDP, вы можете увидеть MTU, поддерживаемый хостом, в подсказках сетевой карты в окне Установка сетей хоста.

    Если вы измените параметры MTU сети, вы должны распространить эти изменения на работающие виртуальные машины в сети: "Горячее" отключение и повторное подключение vNIC каждой виртуальной машины, которая должна применить настройки MTU, или перезапуск виртуальных машин. В противном случае эти интерфейсы выйдут из строя при миграции виртуальной машины на другой хост.

  • Сети 1 GbE следует использовать только для трафика управления. Используйте 10 GbE или 40 GbE для виртуальных машин и хранилищ на базе Ethernet.

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

4.1. Рекомендации по настройке сетей хоста

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

  • Если ваша сетевая инфраструктура сложная, вам может потребоваться настроить сеть хоста вручную перед добавлением хоста в среду виртуализации.

  • Настроить сеть можно с помощью Cockpit. В качестве альтернативы можно использовать nmtui или nmcli.

  • Если сеть не требуется для развертывания в режиме Hosted Engine или для добавления хоста в менеджер управления, настройте сеть на Портале администрирования после добавления хоста в менеджер управления.

  • Используйте следующие соглашения об именовании:

    • Устройства VLAN: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD

    • Интерфейсы VLAN: physical_device.VLAN_ID (например, eth0.23, eth1.128, enp3s0.50).

    • Интерфейсы bond: bondnumber (например, bond0, bond1).

    • VLAN на объединенных интерфейсах: bondnumber.VLAN_ID (например, bond0.50, bond1.128).

  • Используйте объединение сетей (bonding). Teaming не поддерживается в zVirt и приведет к ошибкам.

  • Используйте рекомендуемые режимы объединения:

    • Режим 0 (round-robin) - передача пакетов через сетевые интерфейсы в последовательном порядке. Пакеты передаются в цикле, который начинается с первого доступного сетевого интерфейса на хосте и заканчивается последним доступным сетевым интерфейсом на хосте. Все последующие циклы начинаются с первой доступной карты сетевого интерфейса. Режим 0 обеспечивает отказоустойчивость и распределяет нагрузку между всеми сетевыми интерфейсными картами в связке. Обратите внимание, что режим 0 не может использоваться в сочетании с bridge и поэтому не совместим с логическими сетями виртуальных машин.

    • Режим 1 (active-backup) - переводит все сетевые интерфейсы в резервное состояние, в то время как один сетевой интерфейс остается активным. В случае отказа активного сетевого интерфейса один из резервных интерфейсов заменяет сбойный интерфейс в качестве единственного активного сетевого интерфейса в бонде. MAC-адрес соединения в режиме 1 виден только на одном порту, чтобы предотвратить путаницу, которая может возникнуть, если MAC-адрес соединения изменится на MAC-адрес активной сетевой интерфейсной карты. Режим 1 обеспечивает отказоустойчивость и поддерживается в zVirt.

    • Режим 2 (XOR) - выбирает сетевой интерфейс, через который будут передаваться пакеты, на основе результата операции XOR над MAC-адресами источника и назначения по модулю количества сетевых интерфейсов. Этот расчет гарантирует, что для каждого используемого MAC-адреса назначения будет выбрана одна и та же карта сетевого интерфейса. Режим 2 обеспечивает отказоустойчивость и балансировку нагрузки и поддерживается в zVirt.

    • Режим 3 (broadcast) - передает все пакеты всем сетевым интерфейсам. Режим 3 обеспечивает отказоустойчивость и поддерживается в zVirt.

    • Режим 4 (IEEE 802.3ad) - создает группы агрегации, в которых интерфейсы имеют одинаковые настройки скорости и дуплекса. Режим 4 использует все сетевые интерфейсы в активной группе агрегации в соответствии со спецификацией IEEE 802.3ad и поддерживается в zVirt.

    • Режим 5 (adaptive transmit load balancing) - обеспечивает распределение исходящего трафика с учетом нагрузки на каждый сетевой интерфейс в связке и то, что текущий сетевой интерфейс получает весь входящий трафик. Если сетевой интерфейс, назначенный для приема трафика, выходит из строя, роль приема входящего трафика возлагается на другой сетевой интерфейс. Режим 5 нельзя использовать в сочетании с bridge, поэтому он не совместим с логическими сетями виртуальных машин.

    • Режим 6 (adaptive load balancing) - объединяет режим 5 (adaptive transmit load balancing) с балансировкой нагрузки при приеме для трафика IPv4 без каких-либо специальных требований к коммутатору. Для балансировки принимаемой нагрузки используется согласование ARP. Режим 6 нельзя использовать в сочетании с bridge, поэтому он не совместим с логическими сетями виртуальных машин.

  • Если сеть ovirtmgmt не используется виртуальными машинами, сеть может использовать любой поддерживаемый режим объединения.

  • Если сеть ovirtmgmt используется виртуальными машинами, сеть должна использовать режимы объединения 1, 2, 3 или 4.

  • По умолчанию в zVirt используется режим объединения 4 Dynamic Link Aggregation. Если ваш коммутатор не поддерживает протокол Link Aggregation Control Protocol (LACP), используйте режим 1 Active-Backup.

Пример 1. Настройка VLAN на физической сетевой карте (в примере используется nmcli, но вы можете использовать любой инструмент)
nmcli connection add type vlan con-name vlan50 ifname eth0.50 dev eth0 id 50
nmcli con mod vlan50 +ipv4.dns 8.8.8.8 +ipv4.addresses 123.123.0.1/24 +ivp4.gateway 123.123.0.254
Пример 2. Настройка VLAN поверх бонда (в примере используется nmcli, но вы можете использовать любой инструмент)
nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=100" ipv4.method disabled ipv6.method ignore
nmcli connection add type ethernet con-name eth0 ifname eth0 master bond0 slave-type bond
nmcli connection add type ethernet con-name eth1 ifname eth1 master bond0 slave-type bond
nmcli connection add type vlan con-name vlan50 ifname bond0.50 dev bond0 id 50
nmcli con mod vlan50 +ipv4.dns 8.8.8.8 +ipv4.addresses 123.123.0.1/24 +ivp4.gateway 123.123.0.254
Не отключайте сервис firewalld (межсетевой экран).

5. Рекомендации по развертыванию в режиме Hosted Engine

  • Создайте отдельный центр данных и кластер для ВМ HostedEngine и других служб уровня инфраструктуры, если ваша инфраструктура может позволить это. Хотя виртуальная машина с менеджером управления может работать на хостах в обычном кластере, отделение от остальных виртуальных машин помогает упростить план резервного копирования и управление производительностью, доступностью и безопасностью.

  • Домен хранения, предназначенный для ВМ HostedEngine, создается во время развертывания. Не используйте этот домен хранения для других виртуальных машин.

  • Если ожидается большая нагрузка на хранилище, разделите сети миграции, управления и хранения, чтобы уменьшить влияние на работоспособность ВМ HostedEngine.

  • Все хосты способные поддерживать работу ВМ HostedEngine должны иметь одинаковое семейство процессоров, чтобы виртуальная машина могла безопасно мигрировать между ними. Если вы планируете создание кластера с хостами, имеющими различные семейства процессоров, необходимо начинать установку с самого раннего семейства.

  • Если ВМ HostedEngine выключается или нуждается в миграции, на хосте должно быть достаточно памяти, чтобы виртуальная машина могла перезапуститься или мигрировать на него.