Глава 9. Высокая доступность Proxmox

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

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

Для установки функциональности HA в Proxmox важно иметь все ваши виртуальные машины на совместно используемом хранилище. Крайне важно понимать, что HA Proxmox обрабатывает только узлы Proxmox и виртуальные машины в пределах кластера Proxmox. Такую функциональность HA не следует путать с избыточностью совместно используемых хранилищ, которую Proxmox может применять в своём развёртывании HA. Высокая доступность в совместно используемом хранилище просто так же важна, как и высокая доступность ВМ Proxmox. Совместно используемые хранилища сторонних производителей могут предоставлять свою собственную функциональность HA. Таким образом, и сам кластер Proxmox, и совместно используемое хранилище должны быть настроены для предоставления реальной среды с высокой доступностью.

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

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

В случае, когда по какой- либо причине узел становится недоступным, HA Proxmox ожидает 60 секунд прежде чем выполнится ограждение (fencing) отказавшего узла. Ограждение предотвращает службы кластера от возврата в рабочее состояние в этом месте. Затем HA перемещает эти ВМ на следующий доступный узел в их группе участников HA. В Proxmox VE 4.1, контейнеры LXC не могут выполнять миграцию в реальном времени. Поэтому HA остановит все контейнеры LXC, а затем переместит их на следующий доступный узел. Даже если узел с ВМ всё ещё включён, но потерял связь с сетевой средой, HA Proxmox попытается переместить все ВМ с этого узла на другой узел.

Однако, когда отказавший узел возвращается в рабочее состояние, HA не будет автоматически перемещать ВМ на первоначальный узел. Это необходимо выполнять вручную. Однако ВМ может быть перемещена вручную только если HA запрещён для такой ВМ. Поэтому мы вначале должны выключить HA, а затем переместить на первоначальный узел и включить HA на данной ВМ вновь. Как мы можем видеть, HA Proxmox любит выполнять всё управление по своему усмотрению, хотя и оставляя небольшие неприятности для выполнения определённых функций вручную. HA ориентирован на поддержание безотказной работы, которая является заданием, выполняемым им надлежащим образом. Далее в этой главе мы рассмотрим как настраивать HA для виртуальных машин.

Начиная c Proxmox 4.0 и для более поздних версий, функциональность высокой доступности была полностью перестроена начиная с основания, что сделало её более простой в настройке и применении. Существует несколько требований, которым должна отвечать среда перед настройкой HA Proxmox. Они таковы:

HA должна настраиваться в кластере, содержащем, как минимум, три узла, так как три узла и более могут достигать Кворума. Кворум является минимальным числом голосов, необходимых для работы кластера Proxmox. Это минимальное значение является общим числом голосов большинства из имеющихся узлов. Например, в кластере из трёх узлов Proxmox, для формирования Кворума требуется два узла Proxmox. Или, в кластере из восьми узлов для получения Кворума требуется пять узлов Proxmox. При наличии только двух узлов соотношение голосов остаётся 1:1, поэтому никакой Кворум не возможен.

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

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

В Proxmox VE 4.1 больше не требуется использование отдельного устройства ограждения (Fencing) для настройки HA Proxmox. Ограждение теперь применяет аппаратные средства обеспечения безопасности (watchdog) или же программные средства Linux для её отслеживания (softdog). Программные средства обеспечения безопасности (softdog) Linux являются программной версией традиционных систем отслеживания безопасности. Большинство BIOS {Прим. пер.: Firmware} современных серверов имеют функциональность отслеживания, однако она обычно отключена по умолчанию. В случае когда она включена, она перезагружает узлы сервера после определённого промежутка отсутствия активности. HA Proxmox всегда будет проверять имеется ли в наличии аппаратное отслеживание, а если его нет, она будет использовать программное отслеживание. Использование программного отслеживания (softdog) теперь делает возможным для HA реализацию встраивания виртуальной среды. Это полезно для установки виртуальных сред Proxmox с целью изучения и проверки HA Proxmox без воздействия изменений на ваши основные системы.

Перед тем как установить ограждение и HA Proxmox, мы должны убедиться что эти узлы могут загружаться немедленно после выполнения цикла включения или потери питания. Обычно, по умолчанию, эта функция запрещена. Следующий снимок экрана показывает эту функцию BIOS {Прим. пер.: Firmware}:

Все настройки HA Proxmox могут быть выполнены в GUI. Спасибо за это новой версии HA в Proxmox. Функциональность HA доступна при перемещении в Datacenter | HA. Это меню, в котором вы будете выполнять все связанные с HA настройки и управление. Следующий снимок экрана отображает интерфейс HA Proxmox:

Как мы можем увидеть из предыдущего снимка экрана, меню HA имеет четыре подменю.

Это меню отображает Status вашей настройки HA. В этом меню отсутствуют какие либо опции. Верно установленный кластер отобразит только одну строку элемента для жизнеспособного кворума. При добавлении новых узлов участников в настройку HA это меню отобразит рабочее состояние всех этих узлов, а также виртуальных машин, которые имеют включённой HA.

Это меню применяется для создания различных групп Proxmox для HA и управления ими. Наиболее характерным использованием групп являются некие программные решения или инфраструктура ВМ, которые должны всегда работать совместно для непрерывной функциональности в случае сбоя. Например, контроллер домена, файловый сервер и тому подобное. В этом меню мы можем создавать множество групп. Назначенные в определённую группу ВМ могут перемещаться только совместно с узлами участниками этой группы. Например, если у нас имеется шесть узлов, три из которых обладают всей полнотой ресурсов, достаточной для исполнения виртуального сервера базы данных, а другие три узла выполняют виртуальные рабочие столы или решения VDI. Мы можем создать две группы, для которых наши виртуальные серверы баз данных могут перемещаться только в пределах тех узлов, которые мы назначили для данной группы. Это гарантирует, что ВМ переместится на правильный узел, который будет способен исполнять такие ВМ. Нам необходима как минимум одна группа для включения HA для ВМ. Для открытия блока диалога создания группы просто кликните на Create в подменю Groups. Следующий снимок экрана отображает блок диалога для нашего примера группы с именем Pmx_2ndEd_HA:

Нимже следуют элементы, доступные в блоке диалога HA Group.

 

ID

Это текстовый блок, применяемый для ввода имени для вашей HA Group. Строка ID может быть набором из букв и цифр, а также символа подчёркивания _ в качестве специального символа.

 

Node

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

 

Restricted

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

 

Nofailback

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

Следующий снимок экрана отображает наше подменю Group с создаваемым нами примером группы:

Это меню, в котором вы включаете HA для виртуальной машины или контейнера. Кликните на Add для открытия блока диалога ресурсов данной ВМ. Это очень простой блок диалога в котором нам нужно только выбрать ВМ и группу HA, к которой будет относиться данная ВМ. Следующий снимок экрана отображает то, что мы добавляем наш пример ВМ #112 в новую группу HA, которую мы создали в предыдущем разделе:

Через блок диалога меню Resource мы можем также запретить HA для ВМ вместо удаления назначенных ресурсов. Это полезно когда мы хотим запретить данные ресурсы временно, причём в будущем мы снова сможем ими воспользоваться. Следующий снимок экрана отображает меню ресурсов с нашим примеров ВМ #112, назначенной в группу HA:

В Proxmox 4.1 не существует никакой функции для этого меню. Оно только информирует ограждающие устройства используемые HA Proxmox. Proxmox применяет аппаратное отслеживание безопасности или отслеживание Linux для ограждения. Следующий экранный снимок отображает интерфейс меню с закладками Fencing:

На данный момент иы создали группу HA Proxmox и добавили в неё ВМ, которыми будет управлять HA. Наша ВМ в настоящее время в узле pmx4-1 и готова к управлению со стороны HA Proxmox. Следующий снимок экрана отображает меню Status для HA:

Как мы можем увидеть из предыдущего снимка, меню Status отображает текущее состояние всей вашей функциональности HA. Для нашего примера кластера оно показывает следующую жизненно важную информацию:

Для того, чтобы убедиться, что HA действительно работает, мы отключим сетевое соединение для pm4-1 и понаблюдаем за окном Status на предмет изменений HA. Окно Status отображает изменение состояния нашей HA после прерывания сетвого соединения:

На предыдущем снимке экране мы можем увидеть, что pm4-1 больше не соединён с кластером и HA не получает никаких подтверждений от данного узла. По истечению 60 секунд, HA Proxmox предоставит следующий доступный в группе HA узел в качестве главного, как это отображается на снимке экрана внизу:

После того, как HA Proxmox предоставит новый ведущий узел для данной группы HA, она затем запустит ограждение для ресурсов ВМ для их подготовки к перемещению на другой узел. В процессе ограждения, все связанные с данной ВМ службы ограждаются, что означает, что даже если отказавший узел вернётся в строй на этом этапе, его ВМ не будет иметь возможность восстановить свою нормальную работу. Следующий снимок экрана отображает состояние данной ВМ в ограждённом состоянии:

После того, как ресурсы данной ВМ ограждены, на следующем этапе, данная ВИ полностью останавливается. Так как узел сам по себе отключён, эта ВМ не может выполнить миграцию в реальном времени, поскольку состояние оперативной памяти исполняемой ВМ не может быть получено с отключённого узла. Снимок экрана, приведённый ниже, отображает ресурсы такой ВМ в остановленном состоянии:

После того, как отслеживаемая ВМ остановлена, она перемещается на следующий свободный узел в группе HA и автоматически запускается. Снимок экрана ниже показывает, что данная ВМ теперь перемещена на узел pm4-2 и была запущена:

Также на предыдущем снимке мы можем увидеть, что хотя первый узел, pm4-1, т вернулся обратно во включённое состояние, после восстановления сетевого соединения, HA продолжает работу с ресурсами ВМ.ю перемещёнными на следующий доступный узел. Это происходит благодаря ограждению, которое не допускает исполнение одних и тех же ресурсов на множестве узлов в одно и то же время. Без наличия ограждения оба выбранных узла попытались бы запустить ВМ в процессе её перемещения.

По различным причинам, существует возможность что HA Proxmox будет производить некую ошибку в процессе автоматического перемещения ВМ. Наиболее часто возникающие ошибки могут происходить по причине неверной настройки совместно используемого хранилища. В нашем примере мы создали искусственную ошибку для хранилища Ceph при которой наш второй узел, pm4-2, не может выполнить чтение хранилища. Таким образом, для HA недоступен запуск данной ВМ, даже хотя она и переместила настройку такой ВМ на данный узел. Следующий снимок экрана отображает ошибку HA вызванную вашим хранилищем Ceph RBD:

В случае возникновения любой ошибки, HA Proxmox выполнит несколько попыток в соответствии с политиками restart и relocate для восстановления после возникновения ошибки. Если все попытки окажутся неудачными, HA Proxmox поместит ресурсы в ошибочное состояние и не будет выполнять для них никаких задач. По этой причине, даже после исправления и фиксации данной ошибки, HA не будет автоматически запускать эту ВМ. Мы будем должны вручную запустить данную ВМ, временно запрещённую HA для рассмотренного случая, а затем разрешить её после того как эта ВМ будет запущена. Это одна из непреднамеренных сторон эффектов включения HA Proxmox, которая может приводить к не ожидаемому поведению после любой возникающей ошибки.

Если данная ВМ переместится после отказа узла и затем повторно запустится на новом узле, это завершает весь процесс настройки HA Proxmox.

Хотя HA Proxmox и стал легче в настройке и управлении, она всё ещё является сложным разделом для освоения. При помощи использования основанных на программной основе средств отслеживания (watchdog) становится полностью возможными настройка, тестирование и изучение HA Proxmox в виртуальной среде перед её развёртыванием в промышленном кластере. Также существует эмулятор HA Proxmox, который мы можем применять для наблюдения за HA в действии без настройки кластера. Симулятор HA позволяет нам увидеть настройку HA в действии и наблюдать за тем как её состояние изменяется на различных этапах.

Симулятор высокой доступности Proxmox не поставляется с его дистрибутивом, что требует установки вручную. Одновременно с пакетом симулятора нам также понадобятся xorg и xuath, так как симулятору требуется переназначение X11, которое также называется пробрасыванием (forwarding) X11. Для установки данных пакетов мы можем воспользоваться следующими командами:

# apt-get install pve-ha-simulator

# apt-get install xorg

# apt-get install xauth
 	   

Мы можем получить доступ к симулятору как в операционной системе Linux, так и в Windows. Если мы регистрируемся из Linux, используйте стандартную команду SSH с параметром -Y, как это показано в следующей команде:

# ssh root@<pmx_node> -Y
 	   

Для Windows мы можем применить более современный терминал, например MobaXterm, который может быть загружен с http://mobaxterm.mobatek.net/.

После получения доступа к узлу Proxmox через Linux или Windows, нам нужно создать каталог, который будет применяться в качестве рабочего каталога для нашего симулятора. После того как каталог создан, мы можем выполнить симулятор, наведённый на наш рабочий каталог. Следующий снимок экрана демонстрирует нашу консоль SSH с созданным нами каталогом и симулятор, запущенный при помощи программы Mobaxterm:

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

Как мы можем видеть на предыдущем снимке экрана, симулятор предоставляет три узла HA с установленными двумя ВМ на каждом узле. Мы можем эмулировать отказ узла или сетевой среды при помощи кнопок Power и Network чтобы наблюдать за HA в действии. Перед тем как HA предпримет действия, мы должны включить HA для каждой из ВМ. Мы увидим, что по мере изменения различных состояний HA элементы настройки нашей HA также изменяются в реальном масштабе времени. Данный симулятор поможет в понимании HA Proxmox лучше чем на практике.

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

Исходя из внутренних свойств HA Proxmox, настоятельно рекомендуется проводить тестирование этих функций в их полном объёме перед тем как погрузиться в их реализацию в промышленном кластере. HA может ограничить взаимодействие пользователя в процессе некоторых операций. Необходимость в HA должна быть оценена и, если она используется, её следует полностью протестировать перед её реализацией в промышленном окружении. Также чрезвычайно важно надлежащим образом сгруппировать и установить размеры вашего решения высокой доступности. Если ваши узлы не смогут обрабатывать нагрузку виртуальных машин, которая необходима для HA, всё решение может оказаться под риском смешения проблем в случае возникновения отказа.

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