Управление инфраструктурой кластера с помощью Ansible

Пояснение

Для управления не виртуальной инфраструктурой кластера, для Ansible существует роль infra, входящая в состав oVirt Ansible Collection.

С помощью данной роли можно управлять следующими сущностями кластера:

  • центрами данных

  • пулами MAC-адресов

  • кластерами и профилями кластеров

  • хостами

  • сетями

  • доменами хранения

  • пользователями и правами

  • внешними провайдерами

Также для управления инфраструктурой кластера можно управлять с помощью модулей Ansible коллекции ovirt.ovirt.

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

1. Использование роли

Инфраструктура, которая необходима в качестве результата, при использовании роли, в Playbook описывается в качестве переменных, которые далее передаются роли. Все переменные можно посмотреть в инструкции README.md, которая находится в каталоге с ролью.

Обязательными являются переменные, необходимые для авторизации в zVirt:

vars:
  engine_fqdn: ovirt-engine.example.com
  engine_user: ansible@internal
  engine_password: 123456
  engine_cafile: /etc/pki/ovirt-engine/ca.pem

2. Управление кластером

В кластере можно настроить свойства кластера, в том числе Memory Ballooning, тип CPU, политики оптимизации памяти, политики миграции и так далее. С помощью роли можно задать 1 из 2 преднастроенных профилей кластера: production и development.

Различия профилей представлены ниже

Production
| Parameter                         | Value              |
|-----------------------------------|--------------------|
| ballooning                        | false              |
| ksm                               | false              |
| host_reason                       | true               |
| vm_reason                         | true               |
| memory_policy                     | disabled           |
| migration_policy                  | suspend_workload   |
| scheduling_policy                 | evenly_distributed |
| ha_reservation                    | true               |
| fence_enabled                     | true               |
| fence_skip_if_connectivity_broken | true               |
| fence_skip_if_sd_active           | true               |

Development
| Parameter        | Value         |
|------------------|---------------|
| ballooning       | true          |
| ksm              | true          |
| host_reason      | false         |
| vm_reason        | false         |
| memory_policy    | server        |
| migration_policy | post_copy     |

Переменные для управления кластером необходимо указывать в виде списка, в котором перечислены кластеры и их параметры:

vars:
  clusters:
    - name: Cluster1
      cpu_type: Inter Conroe Family
      profile: production
    - name: Cluster2
      state: present
      cpu_type: AMD Opteron G3
      ballooning: true
      memory_policy: server

3. Управление хостами

Переменные для хостов можно перечислить в отдельном файле, либо через список hosts.

Если хосты перечислены в отдельном файле, в Playbook это можно указать так:

vars:
  hosts_var_name: ovirt_hosts

Либо можно перечислить в виде переменных в самом Playbook:

vars:
  hosts:
    - name: Host1
      address: 1.2.3.4
      cluster: Default
      password: 12345
      hosted_engine: deploy         # Хост будет подготовлен для размещения HE
    - name: Host2
      address: 1.2.3.5
      cluster: production
      password: 12345
      state: present                # Хост будет добавлен в кластер, значение present используется по умолчанию
      hosted_engine: undeploy       # Хост будет перенастроен таким образом, чтобы Hosted Engine мог быть размещён на данном хосте
    - name: Host3
      address: 1.2.3.6
      cluster: development
      password: 12345
      state: absent                 # Хост будет удалён из кластера

Список хостов в отдельном файле перечисляется также, как в Playbook и должен иметь такой же вид.

4. Управление доменами хранения

Для управления доменами хранения, перечислите их в списке storages

vars:
  storages:
    nfs_storage:
      master: true                  # Указывает мастер домен, при добавлении нескольких доменов сразу,
                                    # параметр master укажет какой необходимо добавить первым
      state: present
      nfs:
        address: 10.11.12.13
        path: /path/to/storage
    iscsi_storage:
      state: present
      iscsi:
        target: iqn.2023-04.zvirt.ru:storage
        port: 3260
        address: 10.11.12.14
        username: user
        password: password
        lun_id: LUN ID
    export_storage:
      domain_function: export
      nfs:
        address: 10.11.12.15
        path: /path/to/storage-export
    iso_storage:
      domain_function: iso
      nfs:
        address: 10.11.12.16
        path: /path/to/storage-iso

5. Управление сетями

Управления сетями можно разделить на управление логическими сетями кластера и управление сетями хостов.

# Логические сети
vars:
  logical_networks:
    - name: mynetwork
      clusters:
        - name: Default
          assigned: yes
          required: no
          display: no
          migration: yes
          gluster: no
# Сети хостов
  host_networks:
    - name: host1
      check: true
      save: true
      bond:
        name: bond0
        mode: 2
        interfaces:
          - eth2
          - eth3
      networks:
        - name: mynetwork
          boot_protocol: dhcp

Параметр check и save соответствуют флажкам Проверить соединение между хостом и Engine и Проверить соединение между хостом и Engine, описание которых можно посмотреть в настройке сетей хоста.

6. Управление пользователями

Управление пользователями, группами и правами имеет следующий вид:

vars:
 users:
  - name: first.user
    authz_name: internal-authz
    password: 123456
    valid_to: "2018-01-01 00:00:00Z"
  - name: second.user
    authz_name: internal-authz
    password: 123456
    valid_to: "2018-01-01 00:00:00Z"
  - name: third.user
    authz_name: internal-authz
    state: absent                             # Удаление пользователя
 user_groups:
  - name: admins
    authz_name: internal-authz
    users:
     - first.user
     - second.user
 permissions:
  - state: present
    user_name: first.user
    authz_name: internal-authz
    role: SuperUser
    object_type: cluster
    object_name: production
  - state: present
    group_name: admins
    authz_name: internal-authz
    role: UserVmManager
    object_type: cluster
    object_name: development