Собрание заметок об информационных технологиях
Продолжая тему возможностей обеспечения высокой доступности (High Availability) в oVirt 4.0 нельзя упустить из виду такой функционал, как поддержка виртуальных устройств Watchdog. В этой заметке мы рассмотрим практический пример настройки Watchdog-устройства в виртуальной машине с гостевой ОС Ubuntu Linux 16.04 LTS.
В это части мы рассмотрим механизмы Fencing, с помощью которых повышается уровень доступности как самих хостов виртуализации, так и выполняемых на этих хостах виртуальных машин в oVirt 4.0. Подробно о принципах и последовательности работы механизмов Fencing в oVirt можно почитать в документе Automatic Fencing. Здесь же мы поговорим об этих механизмах обзорно и рассмотрим несколько практических примеров.
В этой заметке мы рассмотрим некоторые базовые приёмы работы с 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.
Это заметка из разряда "Для Linux-новичков". При очередном развёртывании CentOS Linux 7.2 на физический сервер столкнулся с проблемой невозможности запуска программы установки ОС, получая ошибку:
Failed to scan disk [имя устройства]
For some reason we were unable to locate a disklabel on a disk that the kernel is reporting patitions on…
В рамках подготовки небольшой инфраструктуры под виртуализацию на базе Linux потребовалось организовать сервер под NFS-шары, которые в последствии планируется использовать под задачу резервного копирования виртуальных машин и прочие полезные цели. Для того, чтобы организовать дисковую ёмкость для NFS-сервера на базе CentOS Linux 7.2, было решено сдуть пыль с пары дисковых полок HP MSA 20, которые давно уже "вялились" на складе, и организовать их прямое подключение к SCSI U320 RAID-контроллеру HP Smart Array 6400. У этого устаревшего контроллера имеется одно не очень приятное ограничение – он не умеет создавать RAID-массивы размером больше 2TB. Чтобы данное ограничение не мешало нам в организации нужного нам объёма дискового пространства, было решено воспользоваться функционалом mdadm (multiple disks admin) для организации программного RAID. В этой заметке мы и рассмотрим пример создания программного дискового массива уровня RAID6 с помощью mdadm в CentOS Linux 7.2.
Ранее я рассматривал пример развёртывания набора утилит HP System Management Tools на сервере HP ProLiant DL360 G5 с CentOS Linux 7.2. В составе этого набора упоминалась и утилита HPE Smart Storage Administrator (SSA), позволяющая управлять контроллерами семейства HP Smart Array. Однако если с помощью SSA мы захотим управлять устаревшими контроллерами Smart Array, то можно столкнуться с фактом того, что SSA не увидит эти контроллеры. Например в моём случае, установленный в сервер SCSI U320 контроллер HP Smart Array 6400 попросту не отображается в интерфейсе SSA.
В такой ситуации поможет установка старой утилиты HP Array Configuration Utility (ACU). Последний раз эта утилита была обновлена в 2013 году и на текущий момент она имеет версию 9.40.12.0. Вообще, чтобы найти ссылки на актуальные версии SSA, ACU и других утилит управления и диагностики контроллеров HP Smart Array для разных операционных систем, можно воспользоваться статьей: HPE Smart Array Controllers - Array Configuration, Diagnostic, Storage Administrator and SmartSSD Wear Gauge Utility.
Мелкие и средние компании зачастую пренебрегают таким компонентом IT инфраструктуры, как мониторинг разных узлов локальной сети. При возникновении проблем в таких компаниях может проходить достаточно много времени, пока инженеры поймут, что происходит в их IT инфраструктуре, что, само по себе, очень критично для бизнеса. Имплементация и правильная настройка системы мониторинга облегчает жизнь IT специалиста на порядок, но стоит заметить, что на начальном этапе сбора и анализа информации в системе мониторинга увеличивается количество рабочих часов. Почему? Всплывают те ошибки, которые вы могли не замечать или просто игнорировали в течении долгого периода времени. При этои рынок программного обеспечения предлагает целый ряд продуктов, так или иначе связанных с мониторингом. В ряде широко используемых продуктов присутствуют такие, как Microsoft System Center Operations Manager (SCOM), Nagios, Zabbix, Cacti и т.д.
На серверах имеющих несколько сетевых интерфейсов каждый отдельно взятый интерфейс можно использовать под какую-то выделенную задачу, например отдельный интерфейс под трафик управления хостом и отдельный интерфейс под трафик периодического резервного копирования. Может возникнуть мысль о том, что такая конфигурация имеет свои плюсы, например, позволяет максимально жёстко разграничить утилизацию интерфейсов под особенности разных задач. Но на этом плюсы, пожалуй, и заканчиваются. Ибо при таком подходе может получиться так, что один интерфейс будет постоянно чем-то чрезмерно нагружен, а другой интерфейс будет периодически полностью простаивать. К тому же, в такой схеме каждый из физических интерфейсов будет выступать как конкретная сущность, при выходе из строя которой будет происходить остановка того или иного сетевого сервиса, жёстко связанного с этой сущностью. 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)
в SPP 2016.10.0 добавил файл биоса rmp от линукса, загружаюсь с iso, на step 3 пишет что прошито все ок…
Еще раз спасибо. Буду пробовать внедрять.
RSS - Записи
Последние комментарии