Собрание заметок об информационных технологиях
В этой части для демонстрации возможностей масштабирования oVirt 4.0 мы рассмотрим пример ещё одного варианта добавления нового хоста в кластер oVirt в конфигурации Hosted Engine с последующей настройкой простейшего варианта балансировки нагрузки между хостами виртуализации в кластере с помощью функционала Scheduling Policy. Читать далее...
В недалёком прошлом, после проведения апгрейда процессоров на серверах HP ProLiant G5 высвободилось несколько ранее используемых процессоров Intel Xeon семейства 5000, которые были бережно уложены "ушкапчик" с мыслью "а что же мне теперь с ними делать". В ту пору у меня закралась идея сборки мощной рабочей станции с использованием серверного процессора Xeon, однако до практики это дело так и не дошло, так как по началу я не смог определиться с выбором материнской платы под родной для Xeon 5K сокет LGA-771, а потом и вовсе забыл про это. Но недавно один мой коллега подкинул ссылку на интересный топик Good news for the LGA775 ! now 771 is available to convert to 775 motherboard, почитав который, я снова вспомнил про старые Xeon-ы. С большим удивлением для себя нашёл ещё один, на этот раз уже русскоязычный ресурс ideafix.name, где, из статьи Материнские платы Gigabyte и Socket 771 CPU microcode, узнал о том, что имеющаяся в моём распоряжении десктопная материнская плата GIGABYTE G41-Combo (Rev.2 FB) на сокете LGA-775 способна работать с процессорами Xeon 5K. Это вдохновило меня на практический эксперимент.
Учитывая то обстоятельство, что oVirt постоянно развивается и каждое очередное обновление помимо расширения функционала имеет ряд исправлений обнаруженных ранее ошибок, имеет смысл задуматься об установке этих обновлений, особенно если они устраняют проблемы, с которыми вам пришлось столкнуться. В первой части данной серии заметок мы рассматривали процедуру развёртывания oVirt Hosted Engine на примере версии 4.0.1. На протяжении того времени, как были написаны последующие заметки серии, вышло пару обновлений oVirt внутри 4 версии, и на данный момент актуальная версия - 4.0.3. В этой заметке мы рассмотрим практический пример обновления oVirt Hosted Engine до текущей актуальной версии.
Продолжая тему возможностей обеспечения высокой доступности (High Availability) в oVirt 4.0 нельзя упустить из виду такой функционал, как поддержка виртуальных устройств Watchdog. В этой заметке мы рассмотрим практический пример настройки Watchdog-устройства в виртуальной машине с гостевой ОС Ubuntu Linux 16.04 LTS.
В этой заметке мы рассмотрим некоторые базовые приёмы работы с oVirt 4.0 в конфигурации Hosted Engine, то есть основные действия, которые может потребоваться выполнить администратору после развёртывания oVirt. Чтобы начать работу с oVirt, нужно хотя бы на базовом уровне понимать значение компонент инфраструктуры этого продукта. Довольно простым и доступным языком описал основные компоненты oVirt Александр Руденко в своём блоге: oVirt часть 4. Настройка инфраструктуры. Рекомендую к предварительному прочтению.
После развёртывания oVirt Engine, при попытке подключения к веб-порталам oVirt мы каждый раз будем получать предупреждение системы безопасности веб-браузера о том, что веб-узел имеет сертификат, которому нет доверия. Это происходит из-за того, что на веб-узле oVirt используется сертификат выданный локальным Центром сертификации (ЦС), который был развёрнут в ходе установки oVirt Engine. Для того, чтобы избавиться от этих предупреждений, а также для того чтобы веб-браузер корректно работал со всеми функциями, доступными на веб-порталах oVirt, нам потребуется сделать так, чтобы веб-браузер доверял SSL сертификату веб-сервера oVirt. Решить этот вопрос можно двумя способами.
С этой записи я начну серию заметок о развёртывании и базовой настройке свободно распространяемой системы виртуализации oVirt версии 4.0 в конфигурации Hosted Engine с учётом тех граблей, по которым мне удалось походить. Но для начала пару слов о том, каким образом я пришёл к решению о необходимости развёртывания такого продукта, как oVirt.
На серверах имеющих несколько сетевых интерфейсов каждый отдельно взятый интерфейс можно использовать под какую-то выделенную задачу, например отдельный интерфейс под трафик управления хостом и отдельный интерфейс под трафик периодического резервного копирования. Может возникнуть мысль о том, что такая конфигурация имеет свои плюсы, например, позволяет максимально жёстко разграничить утилизацию интерфейсов под особенности разных задач. Но на этом плюсы, пожалуй, и заканчиваются. Ибо при таком подходе может получиться так, что один интерфейс будет постоянно чем-то чрезмерно нагружен, а другой интерфейс будет периодически полностью простаивать. К тому же, в такой схеме каждый из физических интерфейсов будет выступать как конкретная сущность, при выходе из строя которой будет происходить остановка того или иного сетевого сервиса, жёстко связанного с этой сущностью. C точки зрения повышения доступности и балансировки нагрузки, более эффективными методом использования нескольких сетевых интерфейсов сервера является объединение этих интерфейсов в логические сущности с использованием технологий Network Bonding и Network Teaming.
В этой заметке на конкретном примере мы рассмотрим то, как с помощью технологии Network Bonding в ОС CentOS Linux 7.2 можно организовать объединение физических сетевых интерфейсов сервера в логический сетевой интерфейс (bond), а уже поверх него создать виртуальные сетевые интерфейсы под разные задачи и сетевые службы с изоляцией по разным VLAN. Агрегирование каналов между коммутатором и сервером будет выполняться с помощью протокола Link Aggregation Control Protocol (LACP) регламентированного документом IEEE 802.3ad. Использование LACP, с одной стороны, обеспечит высокую доступность агрегированного канала, так как выход из строя любого из линков между сервером и коммутатором не приведёт к потери доступности сетевых сервисов сервера, и с другой стороны, обеспечит равномерную балансировку нагрузки между физическими сетевыми интерфейсами сервера. Настройка в нашем примере будет выполняться как на стороне коммутатора (на примере коммутатора Cisco Catalyst WS-C3560G), так и на стороне Linux-сервера с двумя сетевыми интерфейсами (на примере сервера HP ProLiant DL360 G5 с контроллерами Broadcom NetXtreme II BCM5708/HP NC373i)
С этой заметки я начну цикл записей о развёртывании операционной системы CentOS Linux release 7.2.1511 на аппаратной платформе HP ProLiant DL360 G5. Постараюсь максимально подробно описать все особенности и подводные камни, с которыми я столкнусь на этом пути. В этой заметке будет рассмотрен пример первоначальной базовой подготовки сервера к установке ОС с последующей процедурой установки CentOS Linux. Пост-установочные процедуры по обновлению драйверов устройств и установке утилит управления HP будут рассмотрены в дальнейших отдельных заметках.
После установки некоторых обновлений касающихся работы Hyper-V на некоторых хостах виртуализации в журнале роли Hyper-V можно обнаружить ошибку с кодом 19510, фиксирующуюся каждые 5 минут:
Log Name: Microsoft-Windows-Hyper-V-VMMS-Admin Source: Microsoft-Windows-Hyper-V-VMMS Date: 11.02.2016 10:18:32 Event ID: 19510 Level: Error User: SYSTEM Computer: KOM-AD01-VM10.holding.com Description: The Integration Services Setup Disk image could not be updated: The process cannot access the file because it is being used by another process. (0x80070020).
Насколько помню, у нас были ошибки при попытке листинга объектов через PS, поэтому мы и проводили восстановление через WindowsVirtualization.V2.mof
Прошу уточнить, в случае, если запрос к списку и состоянию ВМ выдается без ошибок, то надо ли выполнять восстановление пространства…
RSS - Записи
Последние комментарии