Я начинаю развертывать oVirt в одной из своих работ, и у меня много вопросов о том, как всем управлять, когда вы начинаете его использовать.
Сначала я опишу свою настройку. У меня три машины, два сервера ProLiant DL360e Gen8 и один общий компьютер. Все они имеют 1 ТБ дискового пространства, доступного для ОС, и имеют одинаковую схему разделов. Следующий этот учебник и это вторая часть, Мне удалось настроить три машины следующим образом:
Кластеризованное хранилище с gluster и CTDB, экспортирующее четыре тома: движок, ISO, данные и мета. Мета используется для поддержания согласованности между кластером, механизм используется для хранения данных размещенного механизма oVirt, данные используются для хранения образов виртуальных машин, а ISO - для хранения образов iso для подготовки виртуальных машин ОС.
На обоих серверах ProLiant установлен размещенный движок.
При такой настройке я искал возможность продолжать работу виртуальных машин даже при неработающем одном из ProLiants. Поэтому мне пришлось настроить третью машину для хранения, чтобы не потерять кворум в экспортируемых томах Gluster, если один из ProLiants выйдет из строя.
Вроде все нормально работает. Итак, позвольте мне задать несколько вопросов:
Наконец, прошу прощения за мой плохой английский! Это не мой родной язык!
Заранее всем спасибо !!!
резервное копирование двигателя выполняется с помощью сценария, метко названного engine-backup
. Резервное копирование виртуальных машин сложнее, есть встроенный API [1], но он будет эффективен только в том случае, если вы используете ОС хоста, поддерживающую libvirt blockcommit, то есть последнюю версию Fedora или EL7.1. В противном случае вы можете сделать резервную копию виртуальных машин старым изощренным способом, используя резервные копии внутри агента или остановив их для создания резервной копии, если время простоя не критично.
Я бы связал все 4 сетевые карты, используя режим 4, если коммутатор может это поддерживать, и разделил бы сеть на управляющую VLAN, сеть виртуальных машин, сеть отображения и сеть хранения. Если вы ожидаете, что нагрузка на хранилище будет мешать, возможно, разделите это на две связи, одну для хранилища, а другую для виртуальных машин, дисплея и управления.
Один за раз. Когда вы нажимаете кнопку «Обслуживание», все виртуальные машины с хоста будут перенесены, поэтому хост можно отключить. Подключения к хранилищу во время технического обслуживания также отключаются.
Что бы ни рекомендовал поставщик ИБП, это не имеет ничего общего с oVirt. По сути, процедура предварительного выключения будет состоять в том, чтобы сначала отключить все виртуальные машины (поэтому ИБП может захотеть запустить сценарий API, который вызовет завершение работы на всех виртуальных машинах), а затем перевести все хосты на обслуживание, чтобы их можно было полностью завершить. Когда все хосты находятся на техобслуживании, можно безопасно отключать
Не неправильно и не правильно. В более старых версиях были некоторые жесткие зависимости, которые могли сломаться, если вы удалили материал по умолчанию. Использование значений по умолчанию не было проблемой. Поскольку все же лучше иметь все правильно названные, рекомендуется создать свой собственный DC и кластеры. Чтобы переместить хост между кластерами, переведите его на обслуживание, отредактируйте и измените привязку кластера. Активируйте хост - и он в новом кластере.
Добро пожаловать в чудесный мир oVirt :)
[1] http://www.ovirt.org/Features/Backup-Restore_API_Integration