• Обновление oVirt Hosted Engine 4.0.6 до версии 4.1.0

    Ранее мы уже рассматривали пример обновления oVirt Hosted Engine между релизами в рамках версии 4.0, который в своей основе применим и к данному обновлению. Однако в случае обновления версии oVirt 4.0.6 на 4.1.0 имеются некоторые свои особенности, которые я постараюсь описать на практическом примере с имеющейся у меня инфраструктурой oVirt.

    Читать далее…

  • Высоко-доступный балансировщик ZEVENET Load Balancer Community Edition 3.10.1 на базе виртуальных машин oVirt c 64-битной ОС Debian GNU/Linux 8.6

    В Марте этого года было объявлено о доступности Zen Load Balancer Community Edition 3.10, где была добавлена поддержка Debian Jessie, удалена поддержка профилей GSLB и TCP (вместо этого предлагается использовать L4xNAT), исправлены некоторые ошибки. Полный список изменений можно посмотреть в Changelog. Однако не узрев для себя существенных изменений, мы решили не связываться с обновлением ранее описанного форка ZenLB, адаптированного под 64-битную OC Ubuntu Server 14.04.

    Читать далее…

  • Развёртывание и настройка oVirt 4.0. Часть 7. Расширение кластера и балансировка нагрузки

    imageВ этой части для демонстрации возможностей масштабирования oVirt 4.0 мы рассмотрим пример ещё одного варианта добавления нового хоста в кластер oVirt в конфигурации Hosted Engine с последующей настройкой простейшего варианта балансировки нагрузки между хостами виртуализации в кластере с помощью функционала Scheduling Policy.

    Читать далее…

  • Развёртывание и настройка oVirt 4.0. Часть 6. Обновление Hosted Engine

    imageУчитывая то обстоятельство, что oVirt постоянно развивается и каждое очередное обновление помимо расширения функционала имеет ряд исправлений обнаруженных ранее ошибок, имеет смысл задуматься об установке этих обновлений, особенно если они устраняют проблемы, с которыми вам пришлось столкнуться. В первой части данной серии заметок мы рассматривали процедуру развёртывания oVirt Hosted Engine на примере версии 4.0.1. На протяжении того времени, как были написаны последующие заметки серии, вышло пару обновлений oVirt внутри 4 версии, и на данный момент актуальная версия — 4.0.3. В этой заметке мы рассмотрим практический пример обновления oVirt Hosted Engine до текущей актуальной версии.

    Читать далее…

  • Развёртывание и настройка oVirt 4.0. Часть 5. Watchdog как средство повышения доступности гостевых систем виртуальных машин

    imageПродолжая тему возможностей обеспечения высокой доступности (High Availability) в oVirt 4.0 нельзя упустить из виду такой функционал, как поддержка виртуальных устройств Watchdog. В этой заметке мы рассмотрим практический пример настройки Watchdog-устройства в виртуальной машине с гостевой ОС Ubuntu Linux 16.04 LTS.

    Читать далее…

  • Развёртывание и настройка oVirt 4.0. Часть 4. Fencing как средство повышения доступности хостов и виртуальных машин

    В это части мы рассмотрим механизмы Fencing, с помощью которых повышается уровень доступности как самих хостов виртуализации, так и выполняемых на этих хостах виртуальных машин в oVirt 4.0. Подробно о принципах и последовательности работы механизмов Fencing в oVirt можно почитать в документе Automatic Fencing. Здесь же мы поговорим об этих механизмах обзорно и рассмотрим несколько практических примеров.

    Читать далее…

  • Развёртывание и настройка oVirt 4.0. Часть 3. Базовые операции в oVirt

    imageВ этой заметке мы рассмотрим некоторые базовые приёмы работы с oVirt 4.0 в конфигурации Hosted Engine, то есть основные действия, которые может потребоваться выполнить администратору после развёртывания oVirt. Чтобы начать работу с oVirt, нужно хотя бы на базовом уровне понимать значение компонент инфраструктуры этого продукта. Довольно простым и доступным языком описал основные компоненты oVirt Александр Руденко в своём блоге: oVirt часть 4. Настройка инфраструктуры. Рекомендую к предварительному прочтению. 

    Читать далее…

  • Настройка Network Bonding с LACP между CentOS Linux 7.2 и коммутатором Cisco 3560G

    imageНа серверах имеющих несколько сетевых интерфейсов каждый отдельно взятый интерфейс можно использовать под какую-то выделенную задачу, например отдельный интерфейс под трафик управления хостом и отдельный интерфейс под трафик периодического резервного копирования. Может возникнуть мысль о том, что такая конфигурация имеет свои плюсы, например, позволяет максимально жёстко разграничить утилизацию интерфейсов под особенности разных задач. Но на этом плюсы, пожалуй, и заканчиваются. Ибо при таком подходе может получиться так, что один интерфейс будет постоянно чем-то чрезмерно нагружен, а другой интерфейс будет периодически полностью простаивать. К тому же, в такой схеме каждый из физических интерфейсов будет выступать как конкретная сущность, при выходе из строя которой будет происходить остановка того или иного сетевого сервиса, жёстко связанного с этой сущностью. 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)

    Читать далее…

  • Unified Communications User Community (UC²). Встреча №13: Exchange 2013/2016 Transport High Availability и Net4UC2 Сетевая инфраструктура для объединенных коммуникаций

    26 апреля 2016 (во вторник) с 18-00 до 21-00 состоится очередное 13-ое мероприятие сообщества UC² по адресу г. Москва, ул. Лесная, дом 9, Технологический центр Microsoft (MTC). Тем, кто не сможет присутствовать лично, будет доступна ссылка на онлайн участие после регистрации (см. ниже).

    Читать далее…

  • Высоко-доступный балансировщик Zen Load Balancer (ZenLB) Community Edition на базе 64-битной ОС Ubuntu Server 14.04

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

    Читать далее…