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

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

Не включайте дополнительные репозитории, кроме тех, которые предоставляются разработчиком ПО «zVirt Max».

1. Хост виртуализации

Все процессоры должны поддерживать расширения Intel® 64 или AMD64 CPU, а также расширения аппаратной виртуализации AMD-V™ или Intel VT®. Также требуется поддержка флага No eXecute (NX). Виртуализация должна быть включена в BIOS. Проверьте, что ваш процессор имеет необходимые расширения и что они включены, выполнив следующую команду:

grep -E 'svm|vmx' /proc/cpuinfo | grep nx

Все хосты в кластере должны иметь одинаковый тип процессора. Процессоры Intel и AMD не могут сосуществовать в рамках одного кластере.

Хостам требуется хранилище для хранения конфигурации, журналов, дампов ядра и для использования в качестве пространства подкачки. Хранилище может быть локальным или сетевым. Хост может загружаться с одним, несколькими или всеми выделенными по умолчанию разделами в сетевом хранилище. Загрузка из сетевого хранилища может привести к зависанию при отключении сети. Добавление конфигурационного файла multipath может помочь решить проблему потери сетевого соединения. Если гипервизор загружается с сетевого хранилища и теряет связь, файлы становятся доступными только для чтения до восстановления сетевого подключения. Использование сетевого хранилища может привести к снижению производительности.

Если вы планируете использовать перераспределение памяти, добавьте достаточно места для подкачки, чтобы обеспечить виртуальную память для всех виртуальных машин. Хосты должны иметь как минимум один сетевой интерфейс с минимальной пропускной способностью 1 Гбит/с. Каждый хост должен иметь два сетевых интерфейса, причем один из них должен быть выделен для поддержки интенсивной сетевой нагрузки, такой как миграция виртуальных машин.

2. Центр данных

Каждый центр данных должен иметь как минимум один домен хранения данных. Также рекомендуется иметь один домен хранения ISO для каждого центра данных. Если планируете хранить iso-образы в домене хранения данных – используйте отдельный домен данных с типом NFS.

Домен хранения может состоять либо из блочных устройств (iSCSI или Fibre Channel), либо из файловой системы. Домены ISO и Экспорт поддерживают только файловые типы хранения. Домен ISO поддерживает локальное хранение при использовании в локальном центре хранения данных.

3. NFS

ПО «zVirt Max» поддерживает NFS версий 3 и 4. Для производственных рабочих нагрузок требуется сервер NFS корпоративного уровня, если NFS не используется только в качестве домена хранения ISO. Когда корпоративная NFS развернута на 10 Гбит/с, разделена с помощью VLAN, а отдельные службы настроены на использование определенных портов, она является одновременно быстрой и безопасной.

При расширении NFS хранилища ПО «zVirt Max» сразу же распознает изменение размера хранилища данных. Никакой дополнительной настройки на хостах или внутри ПО «zVirt Max» не требуется. Это дает NFS небольшое преимущество перед блочным хранилищем с точки зрения масштабирования и эксплуатации.

4. iSCSI

Для производственных рабочих нагрузок требуется сервер iSCSI корпоративного уровня. Если корпоративный iSCSI развернут на 10 Гбит/с, разделен на виртуальные локальные сети и использует аутентификацию CHAP, он является одновременно быстрым и безопасным. iSCSI также может использовать многоканальность (multipathing) для повышения высокой доступности.

ПО «zVirt Max» поддерживает 1500 логических томов на блочный домен хранения. Разрешается использовать не более 300 LUN.

5. Fibre Channel

Fibre Channel является одновременно быстрым и безопасным, и его следует использовать, если он уже используется в целевом центре обработки данных. Его преимущество заключается в низкой нагрузке на процессор по сравнению с iSCSI и NFS. Fibre Channel также может использовать многоканальность (multipathing) для повышения высокой доступности.

Чтобы использовать Fibre Channel over Ethernet (FCoE) в ПО «zVirt Max», необходимо включить ключ fcoe в менеджере управления виртуализации и установить пакет vdsm-hook-fcoe на хосты.

6. POSIX-совместимые файловые системы

Другие POSIX-совместимые файловые системы могут использоваться в качестве доменов хранения в ПО «zVirt Max», если они являются кластерными файловыми системами и поддерживают разреженные (тонкие) файлы и прямой ввод-вывод. Файловая система Common Internet File System (CIFS), например, не поддерживает прямой ввод/вывод, что делает ее несовместимой с ПО «zVirt Max».

7. Локальное хранилище

Локальное хранилище создается на отдельном хосте, используя собственные ресурсы. Когда вы настраиваете хост на использование локального хранилища, он автоматически добавляется в новый центр данных и кластер, в который не могут быть использованы другими хостами. Виртуальные машины, созданные в кластере с одним хостом, не могут быть перемещены, использовать "Высокую доступность" или использовать политики планирования в кластере.

Для хостов виртуализации локальное хранилище всегда должно быть определено в файловой системе, отдельной от / (root). Используйте отдельный логический том или диск.

8. Сети

Для ПО «zVirt Max» требуется, чтобы IPv6 оставался включенным на физической или виртуальной машине, на которой запущен менеджер управления. Не отключайте IPv6 на ВМ HostedEngine, даже если в вашей сети его не используют.

Менеджер управления не создает сервер DNS или NTP, поэтому сетевому экрану не нужно иметь открытые порты для входящего трафика.

По умолчанию система виртуализации ПО «zVirt Max» разрешает исходящий трафик к DNS и NTP на любой адрес назначения. Если вы запрещаете исходящий трафик, определите исключения для запросов, отправляемых на серверы DNS и NTP.

Менеджер управления виртуализации и все хосты должны иметь определенное доменное имя (FQDN), а также прямое и обратное разрешение имен.

Запуск службы DNS в виртуальной машине в среде виртуализации не рекомендуется. Все службы DNS, используемые виртуализацией, должны быть размещены за её пределами. Рекомендуется использовать DNS вместо файла /etc/hosts для разрешения имен. Каждый хост в кластере должен иметь возможность подключаться к устройствам ограждения всех остальных хостов в кластере. Если хосты кластера получают ошибку (сетевая ошибка, ошибка хранилища и т.д.) и не могут функционировать как хосты, они должны иметь возможность подключения к другим хостам в центре данных.

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

Логические сети могут использовать физические устройства, такие как сетевые карты, или логические устройства, такие как bond. Объединение портов обеспечивает повышенную отказоустойчивость, поскольку все сетевые порты в объединении должны выйти из строя, чтобы сам bond вышел из строя. Только режимы объединения 1, 2, 3 и 4 могут использоваться для сетей виртуальных машин. Режимы 0, 5 и 6 не предназначены для сети виртуальных машин. Система виртуализации по умолчанию использует режим 4.

Режимы объединения:

Режим 0 (round-robin) - передача пакетов через сетевые интерфейсы в последовательном порядке. Пакеты передаются в цикле, который начинается с первого доступного сетевого интерфейса на хосте и заканчивается последним доступным сетевым интерфейсом на хосте. Все последующие циклы начинаются с первой доступной карты сетевого интерфейса. Режим 0 обеспечивает отказоустойчивость и распределяет нагрузку между всеми сетевыми интерфейсными картами в связке. Однако режим 0 не может использоваться в сочетании с bridge и поэтому не совместим с логическими сетями виртуальных машин.
Режим 1 (active-backup) - переводит все сетевые интерфейсы в резервное состояние, в то время как один сетевой интерфейс остается активным. В случае отказа активного сетевого интерфейса один из резервных интерфейсов заменяет сбойный интерфейс в качестве единственного активного сетевого интерфейса в бонде. MAC-адрес соединения в режиме 1 виден только на одном порту, чтобы предотвратить путаницу, которая может возникнуть, если MAC-адрес соединения изменится на MAC-адрес активной сетевой интерфейсной карты. Режим 1 обеспечивает отказоустойчивость и поддерживается в ПО «zVirt Max».
Режим 2 (XOR) - выбирает сетевой интерфейс, через который будут передаваться пакеты, на основе результата операции XOR над MAC-адресами источника и назначения по модулю количества сетевых интерфейсов. Этот расчет гарантирует, что для каждого используемого MAC-адреса назначения будет выбрана одна и та же карта сетевого интерфейса. Режим 2 обеспечивает отказоустойчивость и балансировку нагрузки и поддерживается в ПО «zVirt Max».
Режим 3 (broadcast) - передает все пакеты всем сетевым интерфейсам. Режим 3 обеспечивает отказоустойчивость и поддерживается в ПО «zVirt Max».
Режим 4 (IEEE 802.3ad) - создает группы агрегации, в которых интерфейсы имеют одинаковые настройки скорости и дуплекса. Режим 4 использует все сетевые интерфейсы в активной группе агрегации в соответствии со спецификацией IEEE 802.3ad и поддерживается в ПО «zVirt Max».
Режим 5 (adaptive transmit load balancing) - обеспечивает распределение исходящего трафика с учетом нагрузки на каждый сетевой интерфейс в связке и то, что текущий сетевой интерфейс получает весь входящий трафик. Если сетевой интерфейс, назначенный для приема трафика, выходит из строя, роль приема входящего трафика возлагается на другой сетевой интерфейс. Режим 5 нельзя использовать в сочетании с bridge, поэтому он не совместим с логическими сетями виртуальных машин.
Режим 6 (adaptive load balancing) - объединяет режим 5 (adaptive transmit load balancing) с балансировкой нагрузки при приеме для трафика IPv4 без каких-либо специальных требований к коммутатору. Для балансировки принимаемой нагрузки используется согласование ARP. Режим 6 нельзя использовать в сочетании с bridge, поэтому он не совместим с логическими сетями виртуальных машин.

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

8.1. Ограничения на количество логических сетей в ПО «zVirt Max»

Количество логических сетей, подключенных к хосту, ограничено количеством доступных физических сетевых устройств в сочетании с максимальным количеством виртуальных локальных сетей (VLAN), которое составляет 4096.

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

Количество логических сетей в центре данных ограничено только количеством содержащихся в нем кластеров в сочетании с количеством логических сетей, разрешенных для каждого кластера. Будьте особенно внимательны при изменении свойств сети управления (ovirtmgmt). Неправильные изменения свойств сети ovirtmgmt могут привести к тому, что хосты станут недоступны.

8.2. Сервера каталогов

Во время установки менеджер управления по умолчанию создает пользователя admin в домене internal. Эта учетная запись предназначена для использования при первоначальной настройке среды и для устранения неполадок. Вы можете создать дополнительных пользователей во внутреннем домене с помощью ovirt-aaa-jdbc-tool или на портале администрирования.

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

Поддерживается подключение более одного сервера каталогов.

Для взаимодействия со средой виртуализации поддерживаются следующие серверы каталогов:

389ds;
389ds RFC-2307 Schema;
Active Directory;
IBM Security Directory Server;
IBM Security Directory Server RFC-2307 Schema;
IPA;
Novell eDirectory RFC-2307 Schema;
OpenLDAP RFC-2307 Schema;
OpenLDAP Standard Schema;
Oracle Unified Directory RFC-2307 Schema;
RFC-2307 Schema (Generic);
RHDS;
RHDS RFC-2307 Schema;
iPlanet.

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

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

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

Не рекомендуется запускать службы или сервисы (например, NTP, DNS, DHCP и др.), от которых зависит менеджер управления, внутри виртуальных машин в той же среде виртуализации. Если это делается, необходимо тщательно спланировать это, чтобы минимизировать время простоя, если виртуальная машина, содержащая службу или сервис, выйдет из строя.

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

Вы можете автоматизировать развертывание хостов и виртуальных машин с помощью PXE, Kickstart, Satellite, CloudForms, Ansible или их комбинации. Развертывание в режиме HostedEngine с помощью PXE не поддерживается. Используйте протокол сетевого времени (NTP) на всех хостах и виртуальных машинах в системе виртуализации для синхронизации времени. Аутентификация и сертификаты особенно чувствительны к разнице во времени.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Устройства 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 на объединенных интерфейсах (bond): bondnumber.VLAN_ID (например, bond0.50, bond1.128).

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

Используйте объединение сетей (bonding). Teaming не поддерживается в системе виртуализации и приведет к ошибкам, если хост используется для развертывания в режиме HostedEngine или добавлен в менеджер управления виртуализации. Используйте рекомендуемые режимы объединения:

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

Не отключайте сервис firewalld (межсетевой экран).

8.8. Рекомендации по развертывания в режиме HostedEngine

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

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

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

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

После развертывания менеджера управления виртуализации запрещено изменять системные параметры ВМ HostedEngine.