Руководство по установке

1. Архитектура

Внимательно прочтите данное руководство перед установкой Программного обеспечения «Защищенная среда виртуализации zVirt Max» (далее – ПО «zVirt Max»), это позволит сократить время развертывания и избежать ошибок.

1.1. Ключевые компоненты ПО «zVirt Max»

Ключевые компоненты ПО «zVirt Max» описаны в таблице 1.

Таблица 1. Ключевые компоненты ПО «zVirt Max»
Имя компонента	Описание
Хост виртуализации	Физический сервер с установленной ОС и ПО «zVirt Max», использующий технологию виртуализации KVM. Предоставляет вычислительные ресурсы для запуска виртуальных машин.
Виртуальная машина (ВМ)	Программная среда, эмулирующая аппаратное обеспечение платформы x86-64.
Менеджер управления	Менеджер управления – ПО «zVirt Max», управляющее физическими хостами виртуализации, доменами данных, кластерами, виртуальными машинами и предоставляющее администратору интерфейс управления. Менеджер управления устанавливается в режиме Hosted Engine, как сервис внутри виртуальной машины.
Домен хранения данных (хранилище)	Служба хранения используется для хранения данных, связанных с виртуальными машинами.

1.2. Архитектура ПО «zVirt Max»

1.2.1. Режим Hosted Engine

В базовой установке zVirt MAX используется СУБД Jatoba, поставляемая с лицензией на 4 ядра (4 виртуальных ЦП). Минимальная (базовая) установка менеджера управления реализована в виде виртуальной машины.

ПО «zVirt Max» разворачивается в режиме Hosted Engine, при котором менеджер управления работает внутри ВМ, запущенной на хостах, управляемых этой службой управления. ВМ и менеджер управления создаются и настраиваются при первоначальной установке кластера.

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

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

Минимальная настройка включает в себя:

Одна виртуальная машина с Менеджером управления, размещенная на хостах с ролью HostedEngine.
Один (или два хоста для режима высокой доступности ВМ HostedEngine) хост.
Внешняя система хранения данных (СХД) или локальное хранилище для размещения домена хранения данных (хранилища). Хранилище должно быть доступно всем хостам виртуализации.

Рисунок 1. Архитектура ПО «zVirt Max» в режиме Hosted Engine

1.2.2. Режим Standalone

В базовой установке zVirt MAX используется СУБД Jatoba, поставляемая с лицензией на 4 ядра (4 виртуальных ЦП). При установке в режиме Standalone потребуется приобрести дополнительные лицензии на требуемое число ядер (виртуальных ЦП).

ПО «zVirt Max» может разворачиваться в режиме Standalone. Режим Standalone проще в развертывании и управлении, но требует дополнительного физического хоста. В исключительных случаях возможно использование хоста с менеджером управления в качестве гипервизора.

Минимальная установка менеджера в архитектуре Standalone включает в себя:

Один хост для менеджера управления - Standalone-хост.

Обычно менеджер управления развертывается на физическом хосте. Менеджер управления возможно развернуть и на виртуальной машине, если эта виртуальная машина размещена в отдельной среде виртуализации. Менеджер управления должен работать под управлением сертифицированной Ред ОС версии 7.3.
Один хост-гипервизор (для обеспечения высокой доступности виртуальных машин рекомендуется добавить в среду как минимум два хоста).
Внешняя система хранения данных (СХД) или локальное хранилище для размещения домена хранения данных (хранилища). Хранилище должно быть доступно всем хостам виртуализации.

Рисунок 2. Архитектура ПО «zVirt Max» в режиме Standalone

2. Системные требования

2.1. Требования к оборудованию

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

Таблица 2. Требования к оборудованию
Ресурс	Минимальная конфигурация	Рекомендуемая конфигурация
Процессор	Двухъядерный процессор x86-64 с поддержкой VT-x/AMD-V	Четырехъядерный процессор или несколько двухъядерных процессоров
Память	4 ГБ	32 ГБ
Жесткий диск	94 ГБ	1 ТБ
Сетевой интерфейс	1 сетевой интерфейс (NIC) 1 Гбит / с.	2 сетевых интерфейса (NIC) 10 Гбит/с

2.1.1. Требования к процессору

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

Проверить, какие расширения процессора доступны на системе, можно следующей командой:

grep flags /proc/cpuinfo|head -n1|grep -Eo '(vmx|svm|nx)'

Таблица 3. Поддерживаемые процессоры
Intel	AMD
Nehalem	G1
Westmere	G2
SandyBridge	G3
IvyBridge	G4
Haswell	G5
Broadwell	EPYC
Skylake Client
Skylake Server
Cascadelake Server

2.1.2. Требования к оперативной памяти

Минимальный необходимый объем оперативной памяти составляет 4 ГБ. Максимальный поддерживаемый объем ОЗУ на хосте ПО «zVirt Max» составляет 12 ТБ.

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

2.1.3. Требования к хранилищу

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

Минимальные требования к хранению описаны в этом разделе.

Минимальные требования и рекомендуемая схема разбиения хранилища:

/ (root) - 55 ГиБ;
/home - 1 ГиБ;
/tmp - 1 ГиБ;
/boot - 1 ГиБ;
/var - 15 ГиБ;
/var/crash - 10 ГиБ;
/var/log - 8 ГиБ;
/var/log/audit - 2 ГиБ;
.swap - 1 ГиБ.

Минимальный общий объём - 94 ГиБ.

2.1.4. Требования к сети

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

Не отключайте IPv6 на хостах виртуализации и/или ВМ HostedEngine, даже если он не используется в вашей сети.

2.1.5. Требования к межсетевому экрану менеджера управления

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

Сценарий установки автоматически настроит firewalld во время развертывания, но перезапишет старую конфигурацию, если вы используете iptables. Если вы хотите использовать iptables и оставить существующую конфигурацию, вы должны настроить его самостоятельно. Описанная здесь конфигурация межсетевого экрана предполагает конфигурацию по умолчанию.

Таблица 4. Требования к межсетевому экрану менеджера управления
Порт	Протокол	Источник	Место назначения	Предназначение	Шифрование
-	ICMP	Хосты виртуализации	Менеджер управления	Необязательный. Может помочь в диагностике.	Нет
22	TCP	Система (ы), используемая для обслуживания двигателя, включая конфигурацию бэкенда и обновление программного обеспечения.	Менеджер управления	Безопасный доступ к Shell (SSH).	Да
				Необязательный.
2222	TCP	Клиенты, получающие доступ к консолям виртуальных машин.	Менеджер управления	Доступ через Secure Shell (SSH) для подключения к консолям виртуальной машины.	Да
80, 443	TCP	Клиенты портала администрирования	Менеджер управления	Предоставляет HTTP (порт 80, не зашифрованный) и HTTPS (порт 443, зашифрованный) доступ к Engine. HTTP перенаправляет соединения на HTTPS.	Да
		Клиенты пользовательского портала
		Хосты виртуализации
		REST API клиенты
6100	TCP	Клиенты портала администрирования	Менеджер управления	Предоставляет доступ через прокси-сервер websocket для веб-консольного клиента noVNC, когда прокси-сервер websocket работает на Engine. Однако, если прокси-сервер websocket работает на другом хосте, этот порт не используется.	Нет
		Клиенты пользовательского портала
7410	UDP	Хосты виртуализации	Менеджер управления	Если Kdump включен на хостах, откройте этот порт для приемника fence_kdump на Engine. Fence_kdump не предоставляет способ шифрования соединения. Тем не менее, вы можете вручную настроить этот порт для блокировки доступа от хостов, которые не имеют права.	Нет
54323	TCP	Клиенты портала администрирования	Менеджер управления (прокси-сервер ImageIO)	Требуется для связи с ImageIO Proxy	Да
6642	TCP	Хосты виртуализации	Открытая виртуальная сеть (OVN)	Требуется для подключения к базе данных Open Virtual Network (OVN)	Да
9696	TCP	Клиенты провайдера внешней сети для OVN	Внешний сетевой провайдер для OVN	OpenStack Networking API	Да, с конфигурацией, генерируемой настройкой менеджера управления.
35357	TCP	Клиенты провайдера внешней сети для OVN	Внешний сетевой провайдер для OVN	OpenStack Identity API	Да, с конфигурацией, генерируемой настройкой менеджера управления.
53	TCP, UDP	Менеджер управления	DNS	DNS-запросы поиска от портов выше 1023 к порту 53 и ответы. Открыты по умолчанию.	Нет
123	UDP	Менеджер управления	NTP-сервер	NTP-запросы от портов выше 1023 к порту 123 и ответы. Открыты по умолчанию.	Нет

2.1.6. Требования к межсетевому экрану хоста виртуализации

Хостам виртуализации необходимо, чтобы номера портов, перечисленные в таблице 5 были открыты, чтобы пропускать сетевой трафик через межсетевой экран системы.

Таблица 5. Требования к межсетевому экрану хоста виртуализации
Порт	Протокол	Источник	Место назначения	Назначение	Шифрование
22	TCP	Менеджер управления	Хосты виртуализации	Безопасный доступ к Shell (SSH).	Да
				Необязательный.
2223	TCP	Менеджер управления	Хосты виртуализации	Доступ через Secure Shell (SSH) для подключения к последовательным консолям виртуальной машины.	Да

161	UDP	Хосты виртуализации	Менеджер управления	Простой протокол управления сетью (SNMP). Требуется только в том случае, если вы хотите, чтобы прерывания Simple Network Management Protocol отправлялись с хоста одному или нескольким внешним SNMP-менеджерам.	Нет
				Необязательный.
111	TCP	Сервер хранения NFS	Хосты виртуализации	NFS соединения.	Нет
				Необязательный.
5900 - 6923	TCP	Клиенты портала администрирования	Хосты виртуализации	Удаленный доступ к гостевой консоли через VNC и SPICE. Эти порты должны быть открыты для облегчения доступа клиентов к виртуальным машинам.	Да (необязательно)
		Клиенты пользовательского портала
5989	TCP, UDP	Менеджер объектов общей информационной модели (CIMOM)	Хосты виртуализации	Используется менеджерами объектов общей информационной модели (CIMOM) для мониторинга виртуальных машин, работающих на хосте. Требуется только в том случае, если вы хотите использовать CIMOM для мониторинга виртуальных машин в вашей среде виртуализации.	Нет
				Необязательный.
16514	TCP	Хосты виртуализации	Хосты виртуализации	Миграция виртуальной машины с использованием libvirt.	Да

49152 - 49215	TCP	Хосты виртуализации	Хосты виртуализации	Миграция и ограждение виртуальной машины с использованием VDSM. Эти порты должны быть открыты для облегчения как автоматической, так и ручной миграции виртуальных машин.	Да

54321	TCP	Менеджер управления	Хосты виртуализации	Связь VDSM с Engine и другими узлами виртуализации.	Да
		Хосты виртуализации

54322	TCP	Менеджер управления (прокси-сервер ImageIO)	Хосты виртуализации	Требуется для связи с демоном ImageIO.	Да

6081	UDP	Хосты виртуализации	Хосты виртуализации	Требуется, когда в качестве сетевого поставщика используется открытая виртуальная сеть (OVN), чтобы OVN мог создавать туннели между хостами.	Нет

53	TCP, UDP	Хосты виртуализации	DNS	DNS-запросы поиска от портов выше 1023 к порту 53 и ответы. Этот порт обязателен и открыт по умолчанию.	Нет

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

Чтобы отключить автоматическую настройку межсетевого экрана при добавлении нового хоста, снимите флажок «Автоматически настраивать межсетевой экран хоста» в разделе «Дополнительные параметры».

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

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

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

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

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

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

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

3.3. NFS

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

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

3.4. iSCSI

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

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

3.5. Fibre Channel

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

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

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

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

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

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

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

3.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 должно поддерживаться на уровне коммутатора.

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

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

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

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

3.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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.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 (межсетевой экран).

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

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

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

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

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

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

4. Подготовка к установке

4.1. Подготовка хранилища

Требуется хотя бы один домен хранения данных, используемый для развертывания ВМ HostedEngine, объёмом не менее 94 ГиБ. Это хранилище необходимо подготовить перед установкой.

После установки рекомендуется добавить отдельный (отдельные) домены хранения данных для хранения дисков ВМ.

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

Поддерживаются следующие протоколы:

NFS
ISCSI
Fibre Channel (FCP)

При использовании протокола iSCSI, домен хранения HostedEngine должен использовать выделенный iSCSI target. Любые дополнительные домены хранения должны использовать отдельные iSCSI target.

В случае появления следующей ошибки во время установки: [ERROR ] Error: Fault reason is "Operation Failed". Fault detail is "[Physical device initialization failed. Please check that the device is empty and accessible by the host.]". HTTP response code is 400.

Выполнить инициализацию системы хранения при помощи команды:

dd if=/dev/zero of=/dev/mapper/LUN++_++ID bs=1M count=200 oflag=direct

где /dev/mapper/LUN_ID - путь до LUN

4.1.1. Подготовка хранилища NFS

Следующие шаги универсальны для семейства Unix-подобных операционных систем на базе ядра Linux. Для уточнения конкретных шагов обратитесь к официальному руководству ОС.

Создать служебных пользователей и группы:

groupadd sanlock -g 179

groupadd kvm -g 36

useradd sanlock -u 179 -g 179 -G kvm

useradd vdsm -u 36 -g 36 -G sanlock

Создать каталог (должно быть доступно более 55 Гб свободного места):
```
mkdir –p /storage/he
```

Установить права доступа:

chown 36:36 /storage/he

chmod 0775 /storage/he

Опубликовать папку, прописав ее в конфигурационном файле NFS-сервера:

echo "/storage/he *(rw,anonuid=36,anongid=36)" >> /etc/exports
echo "/storage/he *(rw,anonuid=36,anongid=36)" >> /etc/exports

Убедиться в правильности задания параметров доступа:
```
cat /etc/exports
```

Запустить необходимые сервисы:

systemctl enable nfs-server

systemctl enable rpcbind

systemctl enable nfs-blkmap

systemctl restart nfs-server

systemctl restart rpcbind

systemctl restart nfs-blkmap

Установка необходимых служб осуществляются с помощью команды:

dnf install -y --allowerasing nfs-utils

При необходимости установить и запустить firewalld с помощью команд:
```
dnf install -y --allowerasing firewalld

systemctl enable firewalld --now
```
Создать правила межсетевого экрана для обеспечения доступности хранилища для других хостов:
```
firewall-cmd --permanent --add-service=nfs

firewall-cmd --permanent --add-service=mountd

firewall-cmd --permanent --add-service=rpc-bind

firewall-cmd --reload
```

4.1.2. Подготовка хранилища iSCSI

ПО «zVirt Max» поддерживает хранилище iSCSI, которое представляет собой домен хранения, созданный из группы томов, состоящей из LUN. Группы томов и LUN не могут быть одновременно подключены к нескольким доменам хранения.

Если вы используете блочное хранилище и намереваетесь развернуть виртуальные машины на необработанных устройствах или прямых логических устройствах и управлять ими с помощью диспетчера логических томов, необходимо создать фильтр, чтобы скрыть гостевые логические тома. Это предотвратит активацию гостевых логических томов при загрузке хоста, что может привести к устареванию логических томов и повреждению данных. Справочная информация по созданию фильтра LVM доступна в файле /etc/lvm/lvm.conf.

В настоящее время ПО «zVirt Max» не поддерживает хранилище с размером блока 4K. Вы должны сконфигурировать хранилище блоков в устаревшем режиме (512b block).

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

Чтобы предотвратить эту ситуацию, рекомендуется добавить в корневую файловую систему SAN файл конфигурации с multipath для загрузочного LUN, чтобы обеспечить его постановку в очередь при наличии соединения:

cat /etc/multipath/conf.d/host.conf

multipaths {
    multipath {
        wwid LUN_ID
        no_path_retry queue
    }

4.1.3. Подготовка FCP-хранилища

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

В настоящее время ПО «zVirt Max» не поддерживает хранилище с размером блока 4K. Вы должны сконфигурировать хранилище блоков в устаревшем режиме (512b block). Если ваш хост загружается из хранилища SAN и теряет связь с хранилищем, файловые системы хранилища становятся доступными только для чтения и остаются в этом состоянии после восстановления соединения.

cat /etc/multipath/conf.d/host.conf

multipaths {
    multipath {
        wwid LUN_ID
        no_path_retry queue
    }

5. Установка

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

Безопасная установка ПО «zVirt Max» включает в себя проверку поставленного компакт-диска с дистрибутивом и эксплуатационной документацией на соответствие контрольным суммам, указанными в формуляре. Основными контрольными характеристиками являются контрольная сумма информации, записанной на носителях, подсчитанная по файлам. Контрольные суммы рассчитаны с использованием программы фиксации и контроля исходного состояния ФИКС-Unix, версии 1.0. (сборка для RHEL 6.5 amd64), алгоритм "Уровень 3". Установка, ввод в эксплуатацию и эксплуатация ПО «zVirt Max» должны производиться в соответствии с указаниями в формуляре и эксплуатационных документах на ПО «zVirt Max».

5.2. Описание процесса установки

Начальная установка ПО «zVirt Max» включает в себя следующие шаги:

Подготовка хранилища (Подготовка хранилища) для домена хранения HostedEngine и для стандартных доменов хранения. Вы можете использовать один из следующих типов хранения:
- NFS;
- ISCSI;
- Fibre Channel (FCP).
Установка хоста виртуализации (Установка хоста виртуализации). Этот хост станет первым хостом с размещенным на нем менеджером управления.
Установка менеджера управления ПО «zVirt Max» (Установка менеджера управления ПО «zVirt Max»).

5.3. Подготовка хранилища

Подготовка описана в разделе Подготовка хранилища.

5.4. Установка хоста виртуализации

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

Загрузите сертифицированную версию Ред ОС 7.3 и запишите ISO-образ Ред ОС на USB, CD или DVD (Подготовка USB-накопителя).
Включите сервер, на котором вы устанавливаете ОС, загрузившись с подготовленного установочного носителя согласно документации по установке Ред ОС.
Рекомендованная установка Ред ОС для ПО «zVirt Max» - Сервер минимальный.

Рисунок 3. Установка Ред ОС - Сервер минимальный

При указании пароля пользователя root, необходимо разрешить вход пользователя root с паролем через SSH.

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

Рисунок 4. Установка Ред ОС - указание пароля

Разбиение диска необходимо производить в ручном режиме выбрав пункт «По-своему» согласно Требованиям к хранилищу.

Рисунок 5. Установка Ред ОС – конфигурация устройств хранения
После успешной установки операционной системы, настройте репозиторий.

5.5. Настройка репозитория

Доступ к репозиториям необходимо настроить на всех хостах, которые планируется использовать в среде «zVirt Max».

Репозитории могут быть настроены вручную и автоматически с помощью скрипта.

5.5.1. Автоматическое создание репозитория

Процедура

Скачайте ISO-образ ПО «zVirt Max».
Скачайте скрипт create_repo.sh в директорию с ранее скаченным ISO-образом ПО «zVirt Max».
Разрешите выполнение скрипта:
```
chmod +x create_repo.sh
```
Отключите репозитории Ред ОС:
```
dnf config-manager --disable base, kernels6, updates
```
Выполните скрипт создания репозитория:
```
./create_repo.sh
```
Проверьте правильность подключения репозитория. Следующие команды должны отработать без ошибок, состояние репозитория должно быть в статусе «включено»:
```
dnf repolist all
```

5.5.1.1. Создание репозитория вручную

Процедура

Скачайте ISO-образ ПО «zVirt Max».
Создайте дополнительные каталоги;
```
mkdir /mnt/main
mkdir /mnt/extras
```

Выполните монтирование загруженных ISO-образов репозиториев;

mount -o loop /root/zvirt_max_certified_XXXXXXXXXXXX.iso /mnt/main
mount -o loop /root/zvirt_max_certified_extras_XXXXXXXXXXXX.iso /mnt/extras

Создайте каталоги и символьные ссылки на offline-репозитории;

mkdir -p /var/zvirt-repo/extras
mkdir -p /var/zvirt-repo/main
ln -s /mnt/main /var/zvirt-repo/main
ln -s /mnt/extras /var/zvirt-repo/extras

Создайте конфигурационный файл репозитория;
```
touch /etc/yum.repos.d/offline_zvirt.repo
```

Приведите файл репозитория к следующему виду;

[zvirt_main]
name=zvirt 3.1.2 certified main
baseurl=file:///var/zvirt-repo/main/main
gpgcheck=0
enabled=1

[zvirt_extras]
name=zvirt 3.1.2 certified extras
baseurl=file:///var/zvirt-repo/extras/extras
gpgcheck=0
enabled=1

Проверьте правильность подключения репозитория. Следующие команды должны отработать без ошибок, состояние репозитория должно быть в статусе «включено»:
```
dnf repolist all
```
Отключите репозитории Ред ОС:
```
dnf config-manager --disable base, kernels6, updates
```

5.6. Установка менеджера управления ПО «zVirt Max»

5.6.1. Установка в режиме Hosted Engine c помощью командной строки

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

Заполните для себя по аналогии таблицу.

Таблица 6. Выбор имен для развертывания
Объект	FQDN	IP адрес
Менеджер управления	zvirtvm.rockitsoft.local	172.25.1.186
Хост 1	host1.rockitsoft.local	172.25.1.181
Хост 2	host2.rockitsoft.local	172.25.1.182
Хост 3	host3.rockitsoft.local	172.25.1.183

После установки имя HostedEngine будет являться именем виртуальной машины с менеджером управления и адресом веб-интерфейса управления. Задаваемый адрес должен быть свободен.

В случае невозможности использования внешнего DNS добавьте в файл /etc/hosts IP-адреса и FQDN хоста виртуализации и разворачиваемого менеджера управления.

Установите пакеты ovirt-engine-appliance и zvirt-hosted-engine:

dnf install -y --allowerasing ovirt-engine-appliance
dnf install -y --allowerasing zvirt-hosted-engine

Перезагрузите хост
```
reboot
```
После перезагрузки подключитесь к хосту и откройте сессию запустив терминальный мультиплексор tmux командой:
```
tmux
```
Выполните команду:
```
touch /etc/sysconfig/libvirtd
```
Запустите процесс установки:
```
hosted-engine --deploy
```

Следуйте сообщениям в консоли:

Подтвердите готовность установить Engine на данный хост.

[ INFO ] Stage: Initializing
[ INFO ] Stage: Environment setup
          During customization use CTRL-D to abort.
          Continuing will configure this host for serving as hypervisor and will create a local VM with a running engine.
          The locally running engine will be used to configure a new storage domain and create a VM there.
          At the end the disk of the local VM will be moved to the shared storage.
          Are you sure you want to continue? (Yes, No) [Yes]: Enter

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

        It has been detected that this program is executed through an SSH connection without using screen.
          Continuing with the installation may lead to broken installation if the network connection fails.
          It is highly recommended to abort the installation and run it inside a screen session using command "screen".
          Do you want to continue anyway? (Yes, No) [No]: Yes

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

          Configuration files: []
          Log file: /var/log/zvirt-hosted-engine-setup/zvirt-hosted-engine-setup-20200319163815-bm0sa2.log

После получения сообщения Pause execution until /tmp/ansible.tqw0zglp_he_setup_lock is removed процесс установки Hosted Engine перейдёт в режим ожидания для установки и активации БД Jatoba.

Для установки БД Jatoba необходимо:
- Подключиться по протоколу SSH к хосту, на котором выполняется установка менеджера управления;
- В файле /etc/hosts узнать временный адрес ВМ-менеджера управления;
- Подключиться по протоколу SSH к ВМ-менеджера управления;
- Установить и активировать БД. Порядок установки и активации БД Jatoba описан в Инструкции по установке СУБД Jatoba.
После установки БД Jatoba удалите указанный файл в окне установки и и следуйте сообщениям в консоли:
- Введите или подтвердите адрес шлюза
  --== STORAGE CONFIGURATION ==-- --== HOST NETWORK CONFIGURATION ==-- Please indicate the gateway IP address [172.25.1.254]: Enter
- Укажите сетевой интерфейс, который будет использоваться для создания сетевого моста для ВМ.
  Please indicate a nic to set ovirt mgmt bridge on: (eth0) [eth0]: Enter
- Укажите, каким образом будет выполняться проверка сети.
  Please specify which way the network connectivity should be checked (ping, dns, tcp, none) [dns]: Enter
  
  Используйте только dns.
- Укажите название создаваемого центра данных или подтвердите имя по умолчанию (Default).
  --== VM CONFIGURATION ==-- Please enter the name of the datacenter where you want to deploy this hosted-engine host. [Default]: Enter
- Укажите название создаваемого кластера или подтвердите имя по умолчанию (Default).
  Please enter the name of the cluster where you want to deploy this hosted-engine host. [Default]: Enter
- Здесь указывается путь к ova файлу, в стандартном сценарии строку нужно оставить пустой.
  If you want to deploy with a custom engine appliance image, please specify the path to the OVA archive you would like to use (leave it empty to skip, the setup will use ovirt-engine-appliance rpm installing it if missing): Enter
- Укажите количество vCPU, выделенных для ВМ с сервером управления.

          Please specify the number of virtual CPUs for the VM (Defaults to appliance OVF value): [4]: Enter

Укажите количество оперативной памяти, выделенной для ВМ с сервером управления.
```
          Please specify the memory size of the VM in MB (Defaults to maximum available): [4759]: Enter
```

Введите имя для ВМ Engine.

[ INFO ] Detecting host timezone.
          Please provide the FQDN you would like to use for the engine.
          Note: This will be the FQDN of the engine VM you are now going to launch,
          it should not point to the base host or to any other existing machine.
          Engine VM FQDN: []: zvirtvm.rockitsoft.local

Введите домен, в котором будет находиться сервер управления.

          Please provide the domain name you would like to use for the engine appliance.
          Engine VM domain: [rockitsoft.local] Enter

Введите пароль для пользователя root ВМ Engine.

          Enter root password that will be used for the engine appliance: Password

Подтвердите пароль.

          Confirm appliance root password: Password

Введите открытый ключ ssh для пользователя root, который будет использоваться для ВМ с сервером управления.

          You may provide an SSH public key, that will be added by the deployment script to the authorized_keys file of the root user in the engine appliance.
          This should allow you password less login to the engine machine
after deployment.
          If you provide no key, authorized_keys will not be touched.
          SSH public key []: Enter

Хотите ли вы включить доступ по ssh для пользователя root.

[WARNING] Skipping appliance root ssh public key
          Do you want to enable ssh access for the root user (yes, no, without-password) [yes]: Enter

Хотите ли вы применить профиль безопасности OpenSCAP.

          Do you want to apply a default OpenSCAP security profile (Yes, No) [No]: Enter

Подтвердите сгенерированный maс адрес для ВM или введите свой.

          You may specify a unicast MAC address for the VM or accept a randomly generated default [00:16:3e:24:4d:60]: Enter

Используйте статическую конфигурацию сети ВМ Engine.

          How should the engine VM network be configured (DHCP, Static)[DHCP]? Static

Введите IP адрес ВМ Engine.

          Please enter the IP address to be used for the engine VM []: 172.25.1.186

Подтвердите или введите адрес DNS сервера.

[ INFO ] The engine VM will be configured to use 172.25.1.186/24
          Please provide a comma-separated list (max 3) of IP addresses of domain name servers for the engine VM
          Engine VM DNS (leave it empty to skip) [172.25.1.1]: Enter

Добавить ли запись о хосте в файл hosts на ВМ Engine?

          Add lines for the appliance itself and for this host to /etc/hosts on the engine VM?
          Note: ensuring that this host could resolve the engine VM hostname is still up to you
          (Yes, No)[No] Yes

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

                                --== HOSTED ENGINE CONFIGURATION ==--

          Please provide the name of the SMTP server through which we will send notifications [localhost]: Enter

Введите порт для SMTP сервера.

          Please provide the TCP port number of the SMTP server [25]: Enter

Введите e-mail адрес, откуда будут отсылаться уведомления.

          Please provide the email address from which notifications will be sent [root@localhost]: Enter

Введите список адресов e-mail через запятую, которые будут получать уведомления.
```
          Please provide a comma-separated list of email addresses which will get notifications [root@localhost]: Enter
```
Введите пароль для пользователя admin на сервере управления.
```
          Enter engine admin password: Password
```

Подтвердите пароль.

          Confirm engine admin password: Password

Укажите имя хоста в сети управления.

[ INFO ] Stage: Setup validation
          Please provide the hostname of this host on the management network [host1.rockitsoft.local]: Enter

Введите тип хранилища, которое вы хотите использовать для размещения ВМ с сервером управления.
```
          Please specify the storage you would like to use (iscsi, fc, nfs)[nfs]: Enter
```

Укажите версию протокола nfs, если это необходимо.

          Please specify the nfs version you would like to use (auto, v3, v4, v4_1)[auto]: Enter

Укажите правильный путь к сетевому ресурсу.

          Please specify the full shared storage connection path to use (example: host:/path): storage.rockitsoft.local:/storage/he

При необходимости укажите дополнительные параметры монтирования.

          If needed, specify additional mount options for the connection to the hosted-engine storage domain (example: rsize=32768,wsize=32768) []:Enter

Укажите другой размер диска для ВМ HostedEngine, если это необходимо.

         Please specify the size of the VM disk in GiB: [51]: Enter
         ....
         [ INFO ] Creating Storage Domain

После успешного разворачивания сервера виртуализации будет выведено сообщение:
```
[ INFO ] Hosted Engine successfully deployed
```

5.6.2. Установка в режиме Standalone

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

Для успешной установки ПО «zVirt Max» необходим доступ к репозиториям Ред ОС. При отсутствии доступа к общедоступным репозиториям, необходимо заранее подготовить локальный репозиторий сертифицированной РедОС. Создание локального репозитория производится согласно инструкции РедОС.

Заполните для себя по аналогии таблицу.

Таблица 7. Выбор имен для развертывания
Объект	FQDN	IP адрес
Менеджер управления	zvirtvm.rockitsoft.local	172.25.1.186
Хост 1	host1.rockitsoft.local	172.25.1.181
Хост 2	host2.rockitsoft.local	172.25.1.182
Хост 3	host3.rockitsoft.local	172.25.1.183

Установите пакет zvirt-standalone.
```
dnf install -y --allowerasing zvirt-standalone
```
Запустите процесс установки:
```
# engine-setup
```

Следуйте сообщениям в консоли:

Настройка интеграции с Cinderlib.

              --== PRODUCT OPTIONS ==--

    Configure Cinderlib integration (Currently in tech preview) (Yes, No) [No]:

Подтвердите, что на данном хосте будет развернут менеджер управления.
```
    Configure Engine on this host (Yes, No) [Yes]:
```

Подтвердите, что необходимо выполнить настройку сетевого провайдера ovirt-provider-ovn.

    Configuring ovirt-provider-ovn also sets the Default cluster's default network provider to ovirt-provider-ovn.
    Non-Default clusters may be configured with an OVN after installation.
    Configure ovirt-provider-ovn (Yes, No) [Yes]:

Подтвердите, что необходимо выполнить на данном хосте настройку WebSocket Proxy.
```
    Configure WebSocket Proxy on this host (Yes, No) [Yes]:
```
Подтвердите установку Data Warehouse на данном хосте.
```
    Configure Data Warehouse on this host (Yes, No) [Yes]:
```
Подтвердите настройку прокси-сервера для консолей ВМ.
```
    Configure VM Console Proxy on this host (Yes, No) [Yes]:
```
Подтвердите настройку сервера мониторинга Grafana на данном хосте.
```
    Configure Grafana on this host (Yes, No) [Yes]: Enter
```

Подтвердите полное доменное имя данного хоста.

              --== PACKAGES ==--
              --== NETWORK CONFIGURATION ==--

Host fully qualified DNS name of this server [host1.rockitsoft.local]:

Согласитесь с автоматической настройкой сетевого экрана.

    Setup can automatically configure the firewall on this system.
  Note: automatic configuration of the firewall may overwrite current settings.
    Do you want Setup to configure the firewall? (Yes, No) [Yes]:

Подтвердите установку базы данных Data Warehouse на данном хосте.

              --== DATABASE CONFIGURATION ==--

    Where is the DWH database located? (Local, Remote) [Local]:

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

    Setup can configure the local postgresql server automatically for the DWH to run. This may conflict with existing applications.
    Would you like Setup to automatically configure postgresql and create DWH database, or prefer to perform that manually? (Automatic, Manual) [Automatic]:

Подтвердите расположение базы данных Engine на данном хосте.
```
    Where is the Engine database located? (Local, Remote) [Local]:
```

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

    Setup can configure the local postgresql server automatically for the engine to run. This may conflict with existing applications.
    Would you like Setup to automatically configure postgresql and create Engine database, or prefer to perform that manually? (Automatic, Manual) [Automatic]:

Установите пароль администратора.

              --== OVIRT ENGINE CONFIGURATION ==--
    Engine admin password:

Подтвердите установленный пароль.
```
    Confirm engine admin password:
```
Выберите режим Both.
```
    Application mode (Virt, Gluster, Both) [Both]:
```
Служба Gluster в zVirt Max 1.1 не поддерживается.
Согласитесь с использованием учётных данных по умолчанию для сетевого провайдера.
```
    Use default credentials (admin@internal) for ovirt-provider-ovn (Yes, No) [Yes]:
```

По умолчанию не стирать данные после удаления SAN хранилищ.

                --== STORAGE CONFIGURATION ==--

  Default SAN wipe after delete (Yes, No) [No]:

Укажите название организации для сертификата.

              --== PKI CONFIGURATION ==--

  Organization name for certificate [rockitsoft.local]:

Согласитесь на установку веб-страницы системы виртуализации по умолчанию на веб-сервере.

--== APACHE CONFIGURATION ==--

Setup can configure the default page of the web server to present the application home page. This may conflict with existing applications.
Do you wish to set the application as the default page of the web server? (Yes, No) [Yes]:

Согласитесь с автоматической настройкой SSL на apache.

Setup can configure apache to use SSL using a certificate issued from the internal CA.
Do you wish Setup to configure that, or prefer to perform that manually? (Automatic, Manual) [Automatic]:

Выберите режим Basic.

            --== SYSTEM CONFIGURATION ==--
            --== MISC CONFIGURATION ==--

    Please choose Data Warehouse sampling scale:
      (1) Basic
      (2) Full
      (1, 2) [1]:

Подтвердите, что пароль администратора менеджера управления будет использоваться в качестве начального пароля администратора Grafana.
```
    Use Engine admin password as initial Grafana admin password (Yes, No) [Yes]:
```
Просмотрите предварительную конфигурацию установки и подтвердите её.
```
              --== CONFIGURATION PREVIEW ==--
    Please confirm installation settings (OK, Cancel) [OK]:
```
Сообщение после успешного разворачивания сервера виртуализации.
```
[ INFO ] Execution of setup completed successfully
```

6. После установки

6.1. Проверка работоспособности

Зайдите в веб-интерфейс по адресу, который вы задали для ВМ HostedEngine, например, http://zvirtvm.rockitsoft.local/ → Портал администрирования → Введите имя пользователя admin и пароль заданный при установке системы.

Откроется веб-интерфейс управления ПО «zVirt Max», как показано на рисунке ниже.

Рисунок 6. Веб-интерфейс управления ПО «zVirt Max»

6.2. Добавление хостов

Перед добавлением нового хоста в кластер, необходимо:

Подключить локальные репозитории согласно инструкции Настройка репозитория.
Подключиться к консоли хоста и выполнить команду:
```
touch /etc/sysconfig/libvirtd
```

Добавьте все физические серверы в кластер, через Ресурсы → Хосты → Новый.

Для обеспечения доступности менеджера управления в архитектуре Hosted Engine в случае выхода из строя первого хоста, при добавлении дополнительных хостов выберите Да на вкладке Hosted Engine:

Рисунок 7. Окно «Новый хост»

Дополнительную информацию по работе с системой смотрите в Руководстве администратора.

6.3. Добавление хранилища

ПО «zVirt Max» использует централизованную систему хранения для образов дисков виртуальных машин, файлов ISO и снимков. Сеть хранения данных может быть реализована с использованием:

Сетевая файловая система (NFS).
Другие POSIX-совместимые файловые системы.
Протокол iSCSI.
Локальное хранилище подключено непосредственно к хостам виртуализации.
Протокол Fibre Channel (FCP).
Параллельная NFS (pNFS).

Чтобы добавить новый домен хранения перейдите «Хранилище» → «Новый домен» и добавьте домены хранения:

Домен данные.
ISO-домен.
Экспорт-домен.

ISO-домен и Экспорт-домен поддерживают только локальное хранилище или NFS.

Дополнительную информацию по работе с системой смотрите в Руководстве администратора.

7. Сбор и предоставление логов

В случае необходимости предоставления логов технической службе технической поддержки, выполнить следующие действия:

Авторизоваться на сервере под пользователем root.
Выполнить архивацию логов: tar zcf /root/logs.tar.gz /var/log.
Настроить межсетевой экран: firewall-cmd --add-port=8000/tcp.
Запустить веб-сервер: python -m SimpleHTTPServer.
С любого компьютера, находящегося в той же сети что и сервер, обратиться по адресу, например, http://172.25.1.232:8000.
Скачать файл logs.tar.gz.
Предоставить файл logs.tar.gz службе технической поддержки.

8. Техническая поддержка

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

Базовая техническая поддержка обеспечивается предприятием-изготовителем. Срок базовой технической поддержки определяется сроком действия сертификата соответствия ФСТЭК России и может быть продлен по окончании срока действия сертификата соответствия.

Базовая техническая поддержка и иные виды технической поддержки (расширения сервисов технической поддержки) предоставляются предприятием-изготовителем в соответствии с действующими политиками и правилами оказания технической поддержки продуктов предприятия-изготовителя.

Техническая поддержка ПО «zVirt Max» осуществляется предприятием-изготовителем по адресу/телефону/электронной почте: 119048, г. Москва, ул. Доватора, д. 4/7 / +7(499) 490-49-68 / cert@rockitsoft.ru. Об окончании производства и базовой технической поддержки ПО «zVirt Max» предприятие-изготовитель информирует потребителей и ФСТЭК России не позднее, чем за 1 год до окончания производства и поддержки следующими способами:

публикацией соответствующей информации на сайте предприятия-изготовителя.

9. Инструкция по установке СУБД Jatoba 4.5.2

Данная инструкция предназначена для версии Jatoba 4.5.2.

Установку СУБД «Jatoba» возможно провести несколькими способами:

В базовой установке zVirt Max используется СУБД Jatoba, поставляемая с лицензией на 4 ядра (4 виртуальных ЦП). Минимальная (базовая) установка менеджера управления реализована только в виде виртуальной машины.

установка из локального репозитория (CDROM) – производится из файлов, записанных на компакт-диск или скопированных с него;
установка из удаленного репозитория производится с удаленного сервера производителя http://repo.gaz-is.ru ;

Установка СУБД «Jatoba» на ОС GNU/Linux происходит в несколько этапов:

настройка репозитория СУБД;
установка основных пакетов;
инициализация директории данных СУБД;
получение и установка лицензии;
запуск сервиса СУБД.

Концептуальная схема последовательности действий представлена на рисунке. Более подробное описание установки приведено ниже.

Рисунок 8. Последовательность действий при установке СУБД на ОС GNU/Linux

9.1. Установка СУБД «Jatoba» из локального репозитория

Для установки СУБД «Jatoba» необходимо выполнить следующую последовательность действий:

создать каталог /localrepo, выполнив команду:
```
mkdir /localrepo
```
в каталог /localrepo скопировать необходимые файлы для установки СУБД «Jatoba». Требуется скопировать полную структуру файлов и каталогов из дистрибутива. Также допускается установка с CD/DVD носителя напрямую. В этому случае, пользователю не требуется копировать файлы, а вместо /localrepo во всех шагах далее указывать соответствующий путь до носителя и директорию репозитория СУБД на носителе для соответствующей ОС.
проверить результат копирования всех файлов, перейдя в каталог /localrepo и выполнив команду ls –l.

Рисунок 9. Содержимое каталога localrepo
установить открытый ключ репозитория при помощи команды:
```
rpm --import /localrepo/RPM-GPG-KEY-Jatoba
```
создать файл с описанием локального репозитория в системе. Для РЕД ОС 7.2 и 7.3 Муром необходимо добавить следующее описание репозитория в файл /etc/yum.repos.d/jatoba-4.repo.
```
[jatoba-4]
name=Jatoba 4 Official Repository
baseurl=file:///localrepo
enabled=1
gpgcheck=0
gpgkey=file:///localrepo/RPM-GPG-KEY-Jatoba
```
обновить описания пакетов при помощи команды:
```
yum makecache
```

установить основные пакеты СУБД «Jatoba» при помощи команды:

dnf install -y gis-activator11-1.1.0-0.x86_64.rpm jatoba4-libs-4.5.2-1058.x86_64.rpm jatoba4-client-4.5.2-1058.x86_64.rpm jatoba4-server-4.5.2-1058.x86_64.rpm jatoba4-contrib-4.5.2-1058.x86_64.rpm

перейти в директорию расположения исполняемых файлов СУБД «Jatoba», выполнив команду:
```
cd /usr/jatoba-4/bin/
```
инициализировать каталог данных СУБД «Jatoba» при помощи команды:
```
./jatoba-setup initdb jatoba-4
```
пройти процедуру активации.

Имеется два варианта активации лицензии:
Онлайн-активация означает, что запрос на активацию, формирование и сохранение лицензии будет выполнено непосредственно с этого компьютера.
Офлайн-активация означает, что на данном компьютере будет выполнен только запрос активации (сгенерирован специальный файл запроса). Саму активацию необходимо будет выполнить на компьютере, имеющем доступ в сеть Internet.

Для выполнения онлайн-активации лицензии СУБД «Jatoba» необходимо выполнить последовательность действий, приведенную ниже.
- перейти в каталог /usr/jatoba-4/bin/ и запустить активатор командой:
  ./jactivator
- ввести лицензионный ключ;
- ввести адрес электронной почты администратора СУБД – на этот адрес будут приходить письма от системы лицензирования;
- на запрос способа активации указать «1»
  
  Рисунок 10. Окно активации лицензии
- при первоначальной установке СУБД «Jatoba» следует выбрать режим активации «Обычная активация», введя значение «1». При окончании срока действия лицензии следует выбрать режим активации «Реактивация», введя значение «2». Дальнейший порядок установки при реактивации лицензии идентичен нижеописанному.
- указать директорию сохранения файла лицензии. Файл лицензии необходимо сохранить в следующей директории:
  /usr/jatoba-4/bin/
  Офлайн-активация лицензии СУБД «Jatoba» аналогична онлайн-активации до шага «Выбор способа активации»:
- на запрос способа активации указать значение «2»
- ввести путь, куда будет сохранен промежуточный файл запроса лицензии
- в указанной директории будет сформирован файл request.dat, в котором записан запрос на активацию. Содержимое этого файла необходимо будет внести в специальную форму на сайте сервиса лицензирования.
- далее на ЭВМ с доступом в Интернет осуществить переход на адрес сервера активации по форме https://license.gaz-is.ru/offlineActivate/;
- в окне браузера отобразится страница центра офлайн-активации продуктов ООО «Газинформсервис»;
- скопировать содержимое файла request.dat в поле ввода офлайн-активации или загрузить его с помощью кнопки «Обзор».
- нажать кнопку «Активировать»
  
  Рисунок 11. Страница центра офлайн-активации продуктов ООО «Газинформсервис»
- откроется окно ввода ключа активации;
  
  Рисунок 12. Форма ввода ключа для активации продуктов ООО «Газинформсервис»
  
  На указанный в запросе адрес электронной почты, придет письмо с ключом активации.
  
  Рисунок 13. Пример содержимого письма с ключом активации
- ввести полученный ключ из письма в форму активации и нажать кнопку «Активировать»;
  
  Рисунок 14. Форма выпуска лицензии
- содержимое лицензии из формы необходимо скопировать в файл jatoba.cer в текстовом редакторе и разместить файл лицензии в директории установки /usr/jatoba4/bin/. Файл лицензии готов к установке на ЭВМ с офлайн-активацией. Установка лицензии в каталог данных выполняется при помощи команды:
  chown postgres:postgres /usr/jatoba-4/bin/jatoba.cer
  Для пользовательского контроля необходимо проверить права на файл лицензии, который должен быть доступен на чтение системному пользователю postgres, выполнив команду:
  ls -l jatoba.cer
  Рисунок 15. Результат выполнения команды ls

Перед запуском СУБД требуется проверить наличие лицензионных параметров в разделе «LICENSER OPTION AND PARAMETRS», в конце конфигурационного файла postgresql.conf располагающегося по пути:

/var/lib/jatoba/4/data/postgresql.conf

Рисунок 16. Содержимое файла postgresql.conf

В случае отсутствия параметров в конфигурационном файле /var/lib/jatoba/4/data/postgresql.conf необходимо их внести, как указано в таблице.

Таблица 8. Таблица значений конфигурационного файла
Наименование параметра	Наименование параметра (англ.)	Значение
Продукт	lic_product_name	Jatoba
Файл сертификата	lic_file_path	/usr/jatoba-4/bin/jatoba.cer
Сервер лицензирования	lic_server_addr	https://license.gaz-is.ru

Для загрузки СУБД «Jatoba» вместе с ОС необходимо запустить сервис; добавить его в список автозапуска при старте операционной системы, выполнив команды:

systemctl start jatoba-4
systemctl enable jatoba-4

9.2. Установка СУБД «JATOBA» из удаленного репозитория

Для установки СУБД «Jatoba» из удаленного репозитория требуется подключение к сети Internet. Установка из удаленного репозитория аналогична установке из локального репозитория за исключением шагов копирования файлов дистрибутива, установки открытого ключа и содержимого файла репозитория.

Для установки СУБД «Jatoba» необходимо выполнить следующую последовательность действий:

установить открытый ключ удаленного репозитория при помощи команды rpm. Ниже находятся ссылки на файл ключа для соответствующих ОС:
- для РЕД ОС 7.2: http://repo.gaz-is.ru/redos/7.2/x86_64/jatoba/4/stable
- для РЕД ОС 7.3 : http://repo.gaz-is.ru/redos/7.3/x86_64/jatoba/4/stable
  
  Например, для РЕД ОС 7.3 Муром команды добавления открытого ключа могут быть выполнены следующим образом:
  rpm --import http://repo.gaz-is.ru/redos/7.3/x86_64/jatoba/4/stable/RPM-GPG-KEY-Jatoba
создать файл с описанием удаленного репозитория в системе для РЕД ОС 7.3 Муром необходимо добавить следующее описание репозитория в файл /etc/yum.repos.d/jatoba-4.repo;
```
[jatoba-4]
name=Jatoba 4 Official Repository
baseurl=http://repo.gaz-is.ru/redos/7.2/x86_64/jatoba/4/stable
enabled=1 gpgcheck=0
gpgkey=http://repo.gaz-is.ru/redos/7.3/x86_64/jatoba/4/stable/RPM-GPG-KEY-Jatoba
```

Дальнейшая установка СУБД «Jatoba» аналогична, описанному в разделе Установка СУБД Jatoba из локального репозитория, c шага обновить описания пакетов при помощи команды.

10. Инструкция по установке СУБД Jatoba 4.13.2

Данная инструкция предназначена для версии Jatoba 4.13.2.

Установку СУБД «Jatoba» возможно провести несколькими способами:

установка из локального репозитория (CDROM) – производится из файлов, записанных на компакт-диск или скопированных с него;
установка из удаленного репозитория производится с удаленного сервера производителя http://repo.gaz-is.ru ;

Установка СУБД «Jatoba» на ОС GNU/Linux происходит в несколько этапов:

настройка репозитория СУБД;
настройка репозитория СУБД;
установка основных пакетов;
инициализация директории данных СУБД;
получение и установка лицензии;
запуск сервиса СУБД.

Рисунок 17. Последовательность действий при установке СУБД на ОС GNU/Linux

10.1. Установка СУБД «Jatoba» из локального репозитория

Для установки СУБД «Jatoba» необходимо выполнить следующую последовательность действий:

создать каталог /localrepo, выполнив команду:
```
mkdir /localrepo
```
в каталог /localrepo скопировать необходимые файлы для установки СУБД «Jatoba». Требуется скопировать полную структуру файлов и каталогов из дистрибутива. Также допускается установка с CD/DVD носителя напрямую. В этому случае, пользователю не требуется копировать файлы, а вместо /localrepo во всех шагах далее указывать соответствующий путь до носителя и директорию репозитория СУБД на носителе для соответствующей ОС.
проверить результат копирования всех файлов, перейдя в каталог /localrepo и выполнив команду ls –l.

Рисунок 18. Содержимое каталога localrepo
установить открытый ключ репозитория при помощи команды:
```
rpm --import /localrepo/RPM-GPG-KEY-Jatoba
```
создать файл с описанием локального репозитория в системе. Для РЕД ОС 7.2 и 7.3 Муром необходимо добавить следующее описание репозитория в файл /etc/yum.repos.d/jatoba-4.repo.
```
[jatoba-4]
name=Jatoba 4 Official Repository
baseurl=file:///localrepo
gpgcheck=0
gpgkey=file:///localrepo/RPM-GPG-KEY-Jatoba
```
обновить описания пакетов при помощи команды:
```
yum makecache
```

установить основные пакеты СУБД «Jatoba» при помощи команды:

dnf install /localrepo/packages/jatoba4-libs-4.13.2-53316.x86_64.rpm
dnf install /localrepo/packages/jatoba4-client-4.13.2-53316.x86_64.rpm
dnf install /localrepo/packages/jatoba4-server-4.13.2-53316.x86_64.rpm
dnf install /localrepo/packages/jatoba4-contrib-4.13.2-53316.x86_64.rpm

перейти в директорию расположения исполняемых файлов СУБД «Jatoba», выполнив команду:
```
cd /usr/jatoba-4/bin/
```
инициализировать каталог данных СУБД «Jatoba» при помощи команды:
```
./jatoba-setup initdb jatoba-4
```
пройти процедуру активации.

Имеется два варианта активации лицензии:
Онлайн-активация означает, что запрос на активацию, формирование и сохранение лицензии будет выполнено непосредственно с этого компьютера.
Офлайн-активация означает, что на данном компьютере будет выполнен только запрос активации (сгенерирован специальный файл запроса). Саму активацию необходимо будет выполнить на компьютере, имеющем доступ в сеть Internet.

Для выполнения онлайн-активации лицензии СУБД «Jatoba» необходимо выполнить последовательность действий, приведенную ниже.
- перейти в каталог /usr/jatoba-4/bin/ и запустить активатор командой:
  ./jactivator
- ввести лицензионный ключ;
- ввести адрес электронной почты администратора СУБД – на этот адрес будут приходить письма от системы лицензирования;
- на запрос способа активации указать «1»
  
  Рисунок 19. Окно активации лицензии
- при первоначальной установке СУБД «Jatoba» следует выбрать режим активации «Обычная активация», введя значение «1». При окончании срока действия лицензии следует выбрать режим активации «Реактивация», введя значение «2». Дальнейший порядок установки при реактивации лицензии идентичен нижеописанному.
- указать директорию сохранения файла лицензии. Файл лицензии необходимо сохранить в следующей директории:
  /usr/jatoba-4/bin/
  Офлайн-активация лицензии СУБД «Jatoba» аналогична онлайн-активации до шага «Выбор способа активации»:
- на запрос способа активации указать значение «2»
- ввести путь, куда будет сохранен промежуточный файл запроса лицензии
- в указанной директории будет сформирован файл request.dat, в котором записан запрос на активацию. Содержимое этого файла необходимо будет внести в специальную форму на сайте сервиса лицензирования.
- далее на ЭВМ с доступом в Интернет осуществить переход на адрес сервера активации по форме https://license.gaz-is.ru/offlineActivate/;
- в окне браузера отобразится страница центра офлайн-активации продуктов ООО «Газинформсервис»;
- скопировать содержимое файла request.dat в поле ввода офлайн-активации или загрузить его с помощью кнопки «Обзор».
- нажать кнопку «Активировать»
  
  Рисунок 20. Страница центра офлайн-активации продуктов ООО «Газинформсервис»
- откроется окно ввода ключа активации;
  
  Рисунок 21. Форма ввода ключа для активации продуктов ООО «Газинформсервис»
  
  На указанный в запросе адрес электронной почты, придет письмо с ключом активации.
  
  Рисунок 22. Пример содержимого письма с ключом активации
- ввести полученный ключ из письма в форму активации и нажать кнопку «Активировать»;
  
  Рисунок 23. Форма выпуска лицензии
- содержимое лицензии из формы необходимо скопировать в файл jatoba.cer в текстовом редакторе и разместить файл лицензии в директории установки /usr/jatoba4/bin/. Файл лицензии готов к установке на ЭВМ с офлайн-активацией. Установка лицензии в каталог данных выполняется при помощи команды:
  chown postgres:postgres /usr/jatoba-4/bin/jatoba.cer
  Для пользовательского контроля необходимо проверить права на файл лицензии, который должен быть доступен на чтение системному пользователю postgres, выполнив команду:
  ls -l jatoba.cer
  Рисунок 24. Результат выполнения команды ls

/var/lib/jatoba/4/data/postgresql.conf

Рисунок 25. Содержимое файла postgresql.conf

Таблица 9. Таблица значений конфигурационного файла
Наименование параметра	Наименование параметра (англ.)	Значение
Продукт	lic_product_name	Jatoba
Файл сертификата	lic_file_path	/usr/jatoba-4/bin/jatoba.cer
Сервер лицензирования	lic_server_addr	https://license.gaz-is.ru

systemctl start jatoba-4
systemctl enable jatoba-4

10.2. Установка СУБД «JATOBA» из удаленного репозитория

Для установки СУБД «Jatoba» необходимо выполнить следующую последовательность действий:

установить открытый ключ удаленного репозитория при помощи команды rpm. Ниже находятся ссылки на файл ключа для соответствующих ОС:
- для РЕД ОС 7.2: http://repo.gaz-is.ru/redos/7.2/x86_64/jatoba/4/stable
- для РЕД ОС 7.3 : http://repo.gaz-is.ru/redos/7.3/x86_64/jatoba/4/stable
  
  Например, для РЕД ОС 7.3 Муром команды добавления открытого ключа могут быть выполнены следующим образом:
  rpm --import http://repo.gaz-is.ru/redos/7.3/x86_64/jatoba/4/stable/RPM-GPG-KEY-Jatoba
создать файл с описанием удаленного репозитория в системе для РЕД ОС 7.3 Муром необходимо добавить следующее описание репозитория в файл /etc/yum.repos.d/jatoba-4.repo;
```
[jatoba-4]
name=Jatoba 4 Official Repository
baseurl=http://repo.gaz-is.ru/redos/7.2/x86_64/jatoba/4/stable
enabled=1
gpgcheck=0
gpgkey=http://repo.gaz-is.ru/redos/7.3/x86_64/jatoba/4/stable/RPM-GPG-KEY-Jatoba
```

Дальнейшая установка СУБД «Jatoba» аналогична, описанному в разделе Установка СУБД Jatoba из локального репозитория, с шага обновить описания пакетов при помощи команды.