Рекомендации по планированию инфраструктуры

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

Сразу после завершения развертывания создайте полную резервную копию и сохраните ее в отдельном месте. После этого регулярно создавайте резервные копии.
Избегайте запуска любой службы, от которой зависит менеджер управления, в качестве виртуальной машины в той же среде виртуализации. Если так делается, необходимо тщательно спланировать это, чтобы минимизировать время простоя, если виртуальная машина, содержащая эту службу, выйдет из строя.
Убедитесь, что хост или виртуальная машина, на котором будет производится развертывание менеджера управления, имеет достаточную энтропию. Значения ниже 200 могут привести к сбою при развертывании менеджера. Чтобы проверить значение энтропии, выполните команду cat /proc/sys/kernel/random/entropy_avail. Чтобы увеличить энтропию, установите пакет rng-tools.
Вы можете автоматизировать развертывание хостов и виртуальных машин с помощью PXE, Kickstart, CloudForms, Ansible или их комбинации. Обратите внимание, что установка в архитектуре Hosted engine с помощью PXE не поддерживается.
Используйте протокол сетевого времени (NTP) на всех хостах и виртуальных машинах в среде для синхронизации времени. Аутентификация и сертификаты особенно чувствительны к разнице во времени.

В zVirt поддерживается только сервер chrony.
Документируйте всё, чтобы все, кто работает с окружением, знали о его текущем состоянии и необходимых процессах.

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

Не отключайте функции безопасности (такие как HTTPS, SELinux и межсетевой экран) на хостах или виртуальных машинах.
Создайте индивидуальные учетные записи администраторов, вместо того чтобы допускать использование одной учетной записи администратора несколькими сотрудниками. Это также полезно для отслеживания действий.
Ограничьте доступ к хостам и создайте отдельные учетные записи. Не используйте одну учётную запись с правами root на всех хостах виртуализации.
На хостах виртуализации должны использоваться только пакеты и службы, необходимые для виртуализации, производительности, безопасности и мониторинга. Хосты не должны иметь дополнительных пакетов, таких как анализаторы, компиляторы или других компонентов, которые добавляют риск для безопасности и стабильности.

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

Объединяйте сетевые интерфейсы, особенно на продуктивных хостах. Объединение улучшает общую доступность, а также пропускную способность сети.
Стабильная сетевая инфраструктура использующая 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. Рекомендации по хостам

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

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 выключается или нуждается в миграции, на хосте должно быть достаточно памяти, чтобы виртуальная машина могла перезапуститься или мигрировать на него.

6. Рекомендации по переподписке

6.1. Переподписка vCPU (Overcommitting vCPU)

Гипервизор KVM поддерживает переподписку vCPU. Переподписка vCPU подразумевает назначение виртуальным машинам большего количества виртуальных процессоров, чем доступно физически на хосте.

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

Чрезмерная переподписка может негативно сказываться на производительности. Если работающие виртуальные машины одновременно будут использовать все выделенные ресурсы, возникнет конкуренция за физические ядра, что приведет к задержкам и снижению производительности. Поэтому перед применением переподписки стоит тщательно оценить рабочую нагрузку и учесть возможные риски.

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

При использовании виртуальных машин с поддержкой симметричной многопроцессорной обработки (SMP) возникает дополнительная нагрузка на процессор. Переподписка CPU увеличивает эту нагрузку, так как использование тайм-слотов для распределения ресурсов между гостевыми ОС замедляет межпроцессорное взаимодействие внутри каждой гостевой ОС. Эта дополнительная нагрузка возрастает с увеличением числа vCPU у гостевых машин или повышением коэффициента переподписки.

Переподписка vCPU будет более эффективной, когда на одном хосте размещать несколько ВМ с небольшим количеством vCPU на каждую, по сравнению с общим числом физических ядер хоста. Гипервизор KVM способен безопасно поддерживать работу гостевых машин с нагрузкой менее 100% при соотношении 5 vCPU к одному физическому ядру на одном хосте (коэффициент переподписки 5:1). Гипервизор будет равномерно распределять нагрузку, переключаясь между виртуальными машинами.

Не стоит размещать больше 10 vCPU на каждое физическое ядро (коэффициент переподписки 10:1).

В средах с переподпиской снижается стабильность приложений, которые используют 100% доступной памяти или ресурсов процессора. Не используйте переподписку памяти или vCPU в продуктивной среде без проведения тестирования, так как коэффициент переподписки vCPU и количество SMP зависят от типа рабочей нагрузки.

6.2. Переподписка памяти (Overcommitting memory)

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

Для использования переподписки памяти стоит выделять достаточное пространство подкачки на хосте для размещения всех виртуальных машин и достаточный объем памяти для процессов хоста. Операционная система хоста требует минимум 4 ГБ памяти плюс 4 ГБ пространства подкачки.

Переподписка не работает со всеми виртуальными машинами, но может быть эффективна при запуске нескольких идентичных ВМ с KSM.

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

Виртуальная машина будет работать медленнее при частом использовании подкачки. Помимо этого, переподписка может привести к исчерпанию памяти (OOM), что вызовет остановку важных системных процессов ядром Linux. Перед использованием переподписки стоит провести тестирование.

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