Перейти к содержанию

Правила размещения виртуальных машин

Sharx Base поддерживает гибкие правила выбора узлов при создании ВМ. Основные способы:

  • указание конкретного узла nodeName;
  • использование меток узлов nodeSelector;
  • совместное размещение affinity, раздельное совмещение antiAffinity и предпочтительное размещение colocation;
  • учет ограничений taints и допусков tolerations.

Важно

Создавайте ВМ с помощью файлов YAML, так как часто возникают ошибки при внесении данных

Выбор узла по идентификатору nodeName

В YAML-файле создания ВМ в разделе data задайте параметр nodeName — идентификатор узла, на который нужно спланировать ресурс

nodeName: <uuid_node_where_place_vms>

ВМ будет размещена на узле с указанным идентификатором.

Использование меток узлов nodeSelector

Примечание

Подробная информация о метках приведена в статье Работа с метками

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

Метка по умолчанию

По умолчанию каждый узел уже имеет метку base, которую можно применить в разделе nodeSelector.

Пример определения nodeSelector на основе метки base

nodeSelector:
  key: base

В данном случае ВМ будет размещена на менее загруженном узле виртуального кластера.

Пример файла с заданным nodeSelector с меткой по умолчанию:

Метки пользователя

При вводе пользовательских меток ВМ будет размещена на узле, содержащем все метки.

Чтобы ввести правило выбора узла на основе меток, выполните следующие действия:

  1. Просмотрите список меток, отданных во ВЦОД 

    scheduler labels ns show [--filter <FILTER>]

    где filter — фильтрация меток. Возможные значения:

    • a — all, все метки;
    • i — ignored, игнорируемые метки;
    • u — unignored, все метки, кроме игнорируемых.

    Внимание

    Пользователи могут видеть метки только ВЦОД, в котором они находятся.
    При попытке запроса информации о других ВЦОД будет выдаваться ошибка.
    Исключение — ВЦОД управления

  2. В YAML-файл создания ВМ в раздел spec добавьте параметр nodeSelector 

    nodeSelector:
  disktype: ssd
  vcluster: test

ВМ будет размещена на узле, содержащем метки disktype=ssd и vcluster=test.

nodeAffinity, vmAffinity и colocation

Планировщик Scheduler позволяет управлять размещением виртуальных машин в кластере с помощью правил совместного affinity, раздельного antiAffinity и предпочтительного colocation размещения. Эти правила задаются в YAML-файлах создания ВМ и включают:

  • nodeAffinity — ограничение по меткам узлов.
  • vmAffinity, antiAffinity — совместное или раздельное размещение ВМ
  • colocation — совместное размещение связанных компонентов. Позволяет задавать более сложные условия выбора узлов с операторами и весами.

Общие типы стратегий планирования

Для nodeAffinity и vmAffinity применяются две стратегии:

Стратегия Описание
requiredDuringSchedulingIgnoredDuringExecution Жесткое правило. Если ни один узел не соответствует, ВМ не будет размещена
preferredDuringSchedulingIgnoredDuringExecution Мягкое правило. Если узлы не найдены, ВМ будет размещена на более подходящих узлах

nodeAffinity

Правило nodeAffinity позволяет ограничить, на каких узлах может выполняться виртуальная машина. nodeAffinity — аналог nodeSelector, но более гибкий за счет применения стратегий.

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

Для селекторов меток узлов nodeAffinity поддерживает операторы:

  • In — значение присутствует;
  • NotIn — значение отсутсвует;
  • Exist — ключ существует;
  • DoesNotExist — ключ отсутствует.

Например, можно указать

...
matchExpressions: 
  - key: disktype 
    operator: In 
    values:
      - ssd
...

и выбор будет выполняться только среди узлов с меткой disktype=ssd.

Пример описания nodeAffinity из YAML-файла 
 ...
     affinity:
       nodeAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
           nodeSelectorTerms:
             - matchExpressions:
               - key: az-name
                 operator: NotIn
                 values:
                   - az1
               - key: stage
                 operator: DoesNotExist

               - key: disktype
                 operator: In
                 values:
                   - ssd

             - matchExpressions:
               - key: vcluster
                 operator: In
                 values:
                   - test
                   - test2

         preferredDuringSchedulingIgnoredDuringExecution:
           - weight: 100
             preference:
               matchExpressions:
                 - key: az-name
                   operator: In
                   values:
                     - az2

                 - key: vcluster
                   operator: In
                   values:
                     - test

                 - key: vcluster
                   operator: Exist

           - weight: 70
             preference:
               matchExpressions:
                 - key: security
                   operator: In
                   values:
                     - hi_secure

           - weight: 10
             preference:
               matchExpressions:
                 - key: vcluster
                   operator: In
                   values:
                     - test
 ...

где возможные значения operator:

  • In — значение присутствует;
  • NotIn — значение отсутсвует;
  • Exist — ключ существует;
  • DoesNotExist — ключ отсутствует.

vmAffinity, antiAffinity, colocation

Правила vmAffinity, antiAffinity и colocation позволяют учитывать расположение других ВМ при планировании:

  • совместное размещение ВМ vmAffinity;
  • раздельное размещение ВМ antiAffinity;
  • размещение ВМ с учетом уже размещенных ресурсов colocation.

Типы стратегий описаны в разделе выше.

Совместное размещение vmAffinity

vmAffinity определяет, что ВМ должна размещаться на том же узле, что и другие ВМ с нужными метками.

Пример применения правила представлен в файле YAML. Выберите файл в зависимости от типа хранилища.

scheduler_request_colocation_libvirt.yaml

в файле возможные значения operator:

  • In — значение присутствует;
  • NotIn — значение отсутствует;
  • Exist — ключ существует;
  • DoesNotExist — ключ отсутствует.

scheduler_request_colocation_sp.yaml

в файле возможные значения operator:

  • In — значение присутствует;
  • NotIn — значение отсутствует;
  • Exist — ключ существует;
  • DoesNotExist — ключ отсутствует.

Разберем, как сработает планировщик на основе данного примера.

  1. nodeSelector 

    nodeSelector:  
  key: base      
  disktype: ssd
  vcluster: test2

    Это правило жестко ограничивает выбор узлов. Узел должен иметь все перечисленные метки: key=base, disktype=ssd и vcluster=test2.
    Если ни один узел в кластере не соответствует этим условиям, ВМ не будет размещена.

  2. vmAffinity 

    vmAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
  - labelSelector:
      matchExpressions:
        - key: role
          operator: NotIn
          values:
            - web-db2

    Жесткое правило. ВМ не может быть размещена на том же узле, где уже есть другие ВМ с меткой role=web-db2.

    Далее

    preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
  vmAffinityTerm:
    labelSelector:
      matchExpressions:
        - key: authtor
          operator: In
          values:
            - dev

    Мягкое предпочтение. ВМ желательно размещать рядом с другими ВМ, у которых метка authtor=dev. Если таких ВМ нет, это правило не мешает размещению.

  3. Вывод

    Учитывая правила, ВМ будет размещена следующим образом:

    • планировщик сначала жестко отфильтрует узлы по nodeSelector. Узел должен иметь метки key=base и disktype=ssd, и vcluster=test2;
    • затем он исключит узлы, где есть ВМ с меткой role=web-db2;
    • среди оставшихся предпочтет те, где уже размещены ВМ с authtor=dev;
    • если ни один узел не соответствует всем жестким условиям, ВМ не будет размещена.

Раздельное размещение ВМ antiAffinity

vmAntiAffinity запрещает размещать ВМ вместе с другими ВМ с указанной меткой.

В примере ниже ВМ не будет размещена на узле, где есть ВМ с метками authtor=dev или role=web-db2.

...
affinity:

      vmAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
                - key: authtor
                  operator: In
                  values:
                    - dev
                - key: role
                  operator: In
                  values:
                    - web-db2
...

Предпочтительное размещение рядом colocation

Пример предпочтительного размещения

apiVersion: v1
kind: api
metadata:
  plugin:
    scheduler:
      request: add
spec:
  vcluster: "имя виртуального кластера"
  kind: vm
  name: "уникальное имя виртуальной машины"
  labels: "role=analytics,env=dev"
  descr: "описание виртуальной машины"
  data:

    affinity:

      vmAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            vmAffinityTerm:
              labelSelector:        
                matchExpressions:
                  - key: env
                    operator: In
                    values:
                      - dev
                  - key: role
                    operator: In
                    values:
                      - analytics

    nodeSelector:
      key: base 
      disktype: ssd
      vcluster: test
    vms:
      - name: "уникальное имя виртуальной машины"
        descr: "Разместить рядом с другими analytics"
        vnc_passwd: "пароль для доступа по VNC"
        storage:
          sp:
            uuid: "идентификатор тома"
        networks: ["имя сети, которая подключается к ВМ"] 
        vram: "объем виртуальной памяти"
        vcpu: "количество выделяемых виртуальных процессоров"
Поведение планировщика:

  • ВМ желательно разместить рядом с другими ВМ с env=dev и role=analytics.

  • Если таких ВМ рядом нет, данная ВМ все равно будет размещена.

Ограничения taints и допуски tolerations

Ограничения taints и допуски tolerations — механизмы управления размещением виртуальных машин на узлах кластера.

Ограничения taints — это метки, применяемые к узлам, которые предотвращают размещение ВМ без необходимых разрешений.
taints должны быть предварительно добавлены в узлы Администратором ВЦОД. Подробнее см. статью Настроить метки виртуального кластера.

Допуски tolerations — параметры ВМ, разрешающие размещение на узлах с ограничениями. Учитывают начение taints и оператор operator. Значения оператора описаны ниже.

Как использовать ограничения taints и допуски tolerations

  1. Просмотрите список меток, отданных во ВЦОД 

    scheduler labels ns show [--filter <FILTER>]

    где filter — фильтрация меток. Возможные значения:

    • a — all, все метки;
    • i — ignored, игнорируемые метки;
    • u — unignored, все метки, кроме игнорируемых.

    Внимание

    Пользователи могут видеть метки только ВЦОД, в котором они находятся.
    При попытке запроса информации о других ВЦОД будет выдаваться ошибка.
    Исключение — ВЦОД управления

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

    описания `tolerations` из YAML-файла создания ресурсов
    ...
spec:

  tolerations:
    - key: test1
      operator: Equal
      value: test1
      effect: NoSchedule

    - key: test2
      operator: Exists
      effect: NoSchedule

    - key: test4
      operator: Equal
      value: test4
      effect: NoExecute
...

    где возможные значения operator:

    • Exists — требует точного совпадения ключа и значения;
    • Equal — требует наличия ограничения с указанным ключом, независимо от значения.

Поведение планировщика:

  1. Допуск для test1=Equal:test1:NoSchedule позволяет размещение ВМ на узлах, имеющих ограничение test1=test1:NoSchedule.

  2. Допуск для test2=Exists:NoScheduleпозволяет размещение ВМ на узлах с любым значением ограничения test2:NoSchedule.

  3. Допуск для test4=Equal:test4:NoExecuteпозволяет ВМ оставаться оставаться на узле, имеющем ограничение test4=test4:NoExecute, предотвращая ее принудительную остановку.

Термины и определения содержатся в статьях: