Механизмы обеспечения надежности

Механизмы обеспечения надежности

Миграция и режим обслуживания

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

• Балансировка нагрузки — перемещение виртуальных машин между узлами позволяет равномерно распределять нагрузку на серверы, обеспечивая использование ресурсов наилучшим образом.
• Перевод узла в режим обслуживания — виртуальные машины могут быть перемещены с узлов, которые нужно вывести из эксплуатации для выполнения планового обслуживания или обновления программного обеспечения.
• Обновление «прошивки» виртуальных машин — миграция позволяет обновить «прошивку» виртуальных машин, не прерывая их работу.

Настройка параллелизма живой миграции

Живая миграция проходит две фазы, влияющие на пропускную способность:

1. Подготовка — планирование целевого пода и подключение его устройств, вплоть до состояния TargetReady. Память ещё не передаётся.
2. Sync — память виртуальной машины копируется на целевой узел по сети. Именно эта фаза потребляет пропускную способность.

Параллелизм ограничен тремя независимыми лимитами; каждый считается на узел и по умолчанию равен 1. Они задаются через аннотации ModuleConfig virtualization:

Миграция начинает передавать память, только когда свободен sync-слот на её узле-источнике и входящий слот на её целевом узле. До этого она остаётся подготовленной и запаркованной в состоянии TargetReady, а её VirtualMachineOperation остаётся в фазе Pending:

• ожидание sync-слота на узле-источнике — причина WaitingForSyncSlot;
• ожидание входящего слота на целевом узле — сообщение Target node has no free inbound migration slots.

Ускорение вывода узла в обслуживание. Когда все лимиты равны 1, вывод узла мигрирует виртуальные машины строго по одной: подготовить одну, передать её, затем начать следующую. Увеличение только пула подготовки превращает вывод узла в конвейер — следующие виртуальные машины готовят свои целевые поды, пока текущая передаёт память, и каждая начинает передачу сразу после завершения предыдущей. Поскольку sync-пулы остаются равными 1, одновременно на узле идёт не более одной передачи памяти, поэтому дополнительная конкуренция за сеть не возникает.

Ниже приведён пример конвейерного вывода узла с сериализованной передачей памяти:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: virtualization
  annotations:
    # Готовить до 3 миграций параллельно на узле-источнике.
    virtualization.deckhouse.io/parallel-outbound-migrations-per-node: "3"
    # Передавать память по одной миграции за раз с узла.
    virtualization.deckhouse.io/parallel-sync-migrations-per-node: "1"
    # Передавать память по одной миграции за раз на узел.
    virtualization.deckhouse.io/parallel-inbound-migrations-per-node: "1"

Чтобы полностью отключить sync-лимитер (тогда параллелизм ограничивается только пулом подготовки и собственными лимитами KubeVirt), установите соответствующую аннотацию в disabled:

virtualization.deckhouse.io/sync-migration-limit: "disabled"
virtualization.deckhouse.io/inbound-migration-limit: "disabled"

Запуск миграции произвольной машины

Далее будет рассмотрен пример миграции выбранной виртуальной машины.

1. Перед запуском миграции проверьте текущий статус виртуальной машины:

   d8 k get vm
   

   Пример вывода:

   NAME                                   PHASE     NODE           IPADDRESS     AGE
   linux-vm                              Running   virtlab-pt-1   10.66.10.14   79m
   

   Мы видим, что на данный момент ВМ запущена на узле virtlab-pt-1.

2. Для осуществления миграции виртуальной машины с одного узла на другой, с учетом требований к размещению виртуальной машины используется ресурс VirtualMachineOperations (vmop) с типом Evict. Создайте данный ресурс, следуя примеру:

   d8 k create -f - <<EOF
   apiVersion: virtualization.deckhouse.io/v1alpha2
   kind: VirtualMachineOperation
   metadata:
     generateName: evict-linux-vm-
   spec:
     # Имя виртуальной машины.
     virtualMachineName: linux-vm
     # Операция для миграции.
     type: Evict
   EOF
   

3. Сразу после создания ресурса vmop выполните команду:

   d8 k get vm -w
   

   Пример вывода:

   NAME                                   PHASE       NODE           IPADDRESS     AGE
   linux-vm                              Running     virtlab-pt-1   10.66.10.14   79m
   linux-vm                              Migrating   virtlab-pt-1   10.66.10.14   79m
   linux-vm                              Migrating   virtlab-pt-1   10.66.10.14   79m
   linux-vm                              Running     virtlab-pt-2   10.66.10.14   79m
   

4. Если необходимо прервать миграцию, удалите соответствующий ресурс vmop, пока он находится в фазе Pending или InProgress.

Как запустить миграцию ВМ в веб-интерфейсе:

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

Выделенная сеть для миграции

По умолчанию трафик живой миграции идёт по основной сети узла и конкурирует за полосу пропускания с пользовательскими нагрузками. Его можно направить через выделенный VLAN, предоставляемый модулем sdn.

Необходимые условия:

• включён модуль sdn;
• ресурс SystemNetwork создан и находится в состоянии Ready.

Чтобы включить возможность, задайте spec.settings.liveMigration.network в ресурсе ModuleConfig virtualization: укажите type: SystemNetwork и имя подготовленного SystemNetwork в поле systemNetwork.name. После настройки каждая миграция виртуальных машин в кластере выполняется по VLAN указанного SystemNetwork.

spec:
  settings:
    liveMigration:
      network:
        type: SystemNetwork
        systemNetwork:
          name: migration-net

Чтобы вернуть трафик миграции на основную сеть узла, удалите блок network (по умолчанию, если он не задан, используется сеть узла).

Режим обслуживания

При выполнении работ на узлах с запущенными виртуальными машинами существует риск нарушения их работоспособности. Чтобы этого избежать, узел можно перевести в режим обслуживания и мигрировать виртуальные машины на другие свободные узлы.

Для этого выполните следующую команду:

d8 k drain <nodename> --ignore-daemonsets --delete-emptydir-data

где <nodename> — узел, на котором предполагается выполнить работы и который должен быть освобождён от всех ресурсов (в том числе от системных).

Если необходимо вытеснить с узла только виртуальные машины, выполните следующую команду:

d8 k drain <nodename> --pod-selector vm.kubevirt.internal.virtualization.deckhouse.io/name --delete-emptydir-data

После выполнения команды d8 k drain узел перейдёт в режим обслуживания, и виртуальные машины на нём запускаться не смогут.

Чтобы вывести его из режима обслуживания, остановите выполнение команды drain (Ctrl+C), затем выполните:

d8 k uncordon <nodename>

Как выполнить операцию в веб-интерфейсе:

• Перейдите на вкладку «Система», далее в раздел «Узлы» → «Узлы всех групп».
• Из списка выберите нужный узел и нажмите кнопку «Сделать Cordon + Drain».
• Чтобы вывести его из режима обслуживания, нажмите кнопку «Uncordon».

Перебалансировка ВМ

Платформа позволяет автоматически управлять размещением работающих виртуальных машин в кластере. Чтобы включить эту функцию, активируйте модуль descheduler.

Для перебалансировки используется механизм живой миграции виртуальных машин между узлами кластера.

После активации модуля система самостоятельно следит за распределением виртуальных машин и поддерживает оптимальную загрузку узлов. Основные возможности модуля:

• Балансировка нагрузки — система отслеживает, сколько процессора зарезервировано на каждом узле. Если на каком-либо узле резервируется более 80% процессорных ресурсов, часть виртуальных машин будет автоматически перенесена на менее загруженные узлы. Это помогает избежать перегрузки и обеспечивает стабильную работу ВМ.
• Корректное размещение — система контролирует, соответствует ли текущий узел обязательным требованиям запросов виртуальной машины, а также правилам по их относительному расположению. Например, если правила не допускают размещения определённых ВМ на одном узле, модуль автоматически перенесёт их на подходящий сервер.

ColdStandby

ColdStandby обеспечивает механизм восстановления работы виртуальной машины после сбоя на узле, на котором она была запущена.

Для работы данного механизма необходимо выполнить следующие требования:

• Для политики запуска виртуальной машины (.spec.runPolicy) должно быть установлено одно из следующих значений: AlwaysOnUnlessStoppedManually, AlwaysOn;
• На узлах, где запущены виртуальные машины, должен быть включён механизм Fencing.

Рассмотрим как это работает на примере:

1. Кластер состоит из трех узлов: master, workerA и workerB. На worker-узлах включён механизм Fencing. Виртуальная машина linux-vm запущена на узле workerA.
2. На узле workerA возникает проблема (выключилось питание, пропала сеть, и т. д.).
3. Контроллер проверяет доступность узлов и обнаруживает, что workerA недоступен.
4. Контроллер удаляет узел workerA из кластера.
5. Виртуальная машина linux-vm запускается на другом подходящем узле (workerB).

Дополнительные ресурсы

• Кастомные ресурсы модуля node-manager
• Документация модуля sdn
• Кастомные ресурсы модуля virtualization