Установка и добавление нового кластера Ceph

VK Private Cloud позволяет использовать одновременно несколько кластеров Ceph. Обычно их развертывание происходит во время установки Платформы, но можно добавить новый кластер и в уже работающую Платформу.

1. Подготовьте серверы в соответствии с документом Руководство по установке, раздел Подготовка к установке.
2. Установите обновление системных пакетов.
3. Убедитесь, что серверы соответствуют приведенным ниже требованиям.

Сети должны быть разделены на:

• cephexternal (фронтенд) — внешняя сеть для доступа к данным кластера Ceph, например по RBD, RGW, CephFS. К этой сети подключаются компоненты Платформы.

  Требования:

  • высокая пропускная способность;
  • низкая задержка;
  • доступность для клиентов.

• cephinternal (бэкенд) — сеть для внутренней коммуникации между OSD, репликации данных, восстановления после сбоев и ребалансировки.

  Требования:

  • максимальная пропускная способность;
  • изоляция от сети cephexternal;
  • крайне низкая задержка.

  Трафик, связанный с репликацией между OSD, может быть очень интенсивным, поэтому важно, чтобы сеть соответствовала требованиям.

Для cephexternal и cephinternal рекомендуется использовать MTU 9000 (jumbo frames), так как Ceph генерирует много мелких сообщений, например heartbeats и метаданные, а также передает большие объемы данных. Увеличение MTU снижает нагрузку на CPU, связанную с обработкой сетевых пакетов, и повышает общую пропускную способность.

• Задержка (latency) должна быть минимальной, особенно для внутренней сети кластера.

• Пропускная способность (throughput) всех сетевых соединений должна быть как минимум 10 Гбит/с. Рекомендуемая пропускная способность для внутренней сети — 25 Гбит/с, 40 Гбит/с или выше.

• Чем больше буфер на коммутаторах, тем лучше. Это поможет справиться с всплесками трафика во время репликации.

• Используйте сетевые карты (NIC) с поддержкой 10 Гбит/с и выше.

• Рекомендуется использовать по две сетевые карты на сервер: одна для публичной сети, вторая для кластерной.

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

• Monitors (MON) — 6789. Используется для связи с клиентами и между мониторами.

• Managers (MGR) — 9283. Используется для метрик и дашборда, если он включен.

• Object Storage Daemons (OSD) — 6800–7300. Этот диапазон портов используется для взаимодействия между OSD (репликация, восстановление) и для подключений компонентов Платформы. Каждый OSD использует несколько портов в этом диапазоне.

• Metadata Server (MDS) — 6800–7300. Аналогично OSD, эти порты используются для внутренней коммуникации.

Лучшая практика — полностью открыть трафик между всеми узлами кластера Ceph в рамках указанных диапазонов портов.

Ceph спроектирован как отказоустойчивая система, но инфраструктура также должна это поддерживать.

Требования к отказоустойчивости на уровне серверов:

• Минимальный кластер должен состоять из 3 серверов (узлов) для обеспечения отказоустойчивости.
• Рекомендуемый размер кластера для production-сред — не менее 5 серверов. При правильной настройке пулов размещения отказ двух узлов не приведет к потере данных.
• Распределение ролей: MON, MGR и MDS должны быть разнесены по разным физическим серверам, чтобы отказ одного узла не приводил к потере критических сервисов.

Требования к отказоустойчивости на уровне стойки:

• Ceph позволяет определить домен отказа (failure domain). Примеры: host, rack, row и datacenter.
• Рекомендуется настроить пулы размещения так, чтобы реплики одного объекта размещались в разных доменах отказа. Например, если у вас 3 стойки, настройте домен отказа rack. Это гарантирует, что отказ всей стойки, например из-за проблем с питанием или коммутатором, не приведет к потере данных.
• Равномерно распределяйте диски по серверам. Не создавайте в одном кластере серверы с 50 OSD и с 5 OSD.

Подробнее о настройке политики размещения данных (CRUSH placement policy) — в документе Руководство по проектированию в разделе Основные принципы проектирования новой инсталляции → Размещение данных при проектировании SDS Ceph.

• К CPU требования умеренные, но растут с количеством OSD и клиентов. OSD используют ресурсы CPU для работы с сетью и репликацией.
• Требования к памяти (RAM): примерно 2–4 ГБ на OSD. Эта величина получена эмпирическим путем. Больший объем памяти улучшает кеширование и повышает производительность.
• Для хранения данных можно использовать:
  • HDD для большей емкости.
  • SSD или NVMe для большей производительности.
• Для операционной системы и ПО Ceph рекомендуется использовать отдельные диски SSD или HDD.

Ниже приведен упрощенный пример расчета. Полная методика расчета доступного объема для Ceph — в документе Руководство по проектированию в разделе Основные принципы проектирования новой инсталляции → Расчет доступного объема для Ceph.

Сырая емкость (raw capacity) — суммарный объем всех дисков в кластере, предназначенных для хранения данных, т.е. объем всех OSD.

Пример расчета сырой емкости:

$10\ узлов \times 10\ HDD \times 8\ ТБ = 800\ ТБ$

Доступный объем зависит от двух факторов:

1. Фактор репликации (replication factor) определяет количество копий каждого объекта. По умолчанию Ceph хранит 3 копии.

   Формула расчета:

   $Сырая\ емкость \div Фактор\ репликации = Емкость\ после\ репликации$

   Пример расчета при значении фактора репликации 3:

   $800\ ТБ \div 3 \approx 266\ ТБ$

2. Резерв под использование (overhead) — необходимый запас для ребалансировки данных. Кластер Ceph нельзя заполнять на 100%. При добавлении или выходе OSD из строя Ceph перемещает данные. Если свободного места нет, процесс ребалансировки невозможен, из-за чего работа кластера может быть нарушена.

   Рекомендуемый запас — 10–20% от емкости после репликации. Нижняя граница соответствует значению по умолчанию параметра osd_backfillfull_ratio (0,9) — порогу заполнения OSD, выше которого Ceph не переносит на него данные при восстановлении или ребалансировке. Резерв должен также покрывать отказ целого домена отказа (например, узла): в небольшом кластере отказ одного узла вычитает заметно больше 20% емкости. Для точного учета отказов используйте методику расчета из документа Руководство по проектированию — раздел Расчет количества дисков на отказ.

Доступный объем — реальный объем дискового пространства, доступный для пользователей.

Формула расчета доступного объема:

$Доступный\ объем = (Сырая\ емкость \div Фактор\ репликации) \times (1 - Резерв)$

Пример расчета для кластера с 5 узлами, в каждом из которых 12 дисков по 8 ТБ, и фактором репликации 3:

• $Сырая\ емкость = 5 \times 12 \times 8\ ТБ = 480\ ТБ$
• $Емкость\ после\ репликации = 480\ ТБ \div 3 = 160\ ТБ$
• $Резерв\ в\ размере\ 15\% = 160\ ТБ \times 0,15 = 24\ ТБ$
• $Итоговый\ доступный\ объем = 160\ ТБ - 24\ ТБ = 136\ ТБ$

Итого из фактического объема дискового пространства, равного 480 ТБ, пользователям доступно 136 ТБ.

Заполните параметры Inventory, необходимые для развертывания кластера с помощью Ansible:

1. Подключитесь к деплой-ноде по SSH (подробнее — в разделе Подключение к деплой-ноде).

2. В файле vkcloud/vkcloud.yml в группу vkcloud_ceph_osd добавьте вложенные группы, описывающие узлы нового кластера Ceph. В примере ниже — vkcloud_ceph<НОМЕР_КЛАСТЕРА>_mon и vkcloud_ceph<НОМЕР_КЛАСТЕРА>_osd. Должна получиться структура вида:

    
   ...        vkcloud_ceph_osd:          children:            vkcloud_ceph<НОМЕР_КЛАСТЕРА>_mon:              vars:                cluster: ceph<НОМЕР_КЛАСТЕРА>              hosts:                <НОВЫЙ_УЗЕЛ_1>: null                <НОВЫЙ_УЗЕЛ_2>: null                <НОВЫЙ_УЗЕЛ_3>: null            vkcloud_ceph<НОМЕР_КЛАСТЕРА>_osd:              vars:                compute_role: ceph-osd                cluster: ceph<НОМЕР_КЛАСТЕРА>                ceph_mgr_restful_enable: true                ceph_mgr_zabbix_enable: false              hosts:                <НОВЫЙ_УЗЕЛ_1>:                  ceph_mon: true                  ceph_mgr: true                  ceph_mds: true                  mon_deploy: first                <НОВЫЙ_УЗЕЛ_2>:                  ceph_mon: true                  ceph_mgr: true                  ceph_mds: true                <НОВЫЙ_УЗЕЛ_3>:                  ceph_mon: true                  ceph_mgr: true                  ceph_mds: true...

   Здесь:

   • <НОМЕР_КЛАСТЕРА> — номер нового кластера Ceph. Номер должен быть уникальным в рамках инсталляции и продолжать уже принятую схему нумерации кластеров.
   • <НОВЫЙ_УЗЕЛ_1>, <НОВЫЙ_УЗЕЛ_2>, <НОВЫЙ_УЗЕЛ_3> — имена новых узлов кластера Ceph. Имена должны быть уникальными в рамках инсталляции и соответствовать уже принятой схеме именования узлов.
   • ceph_mon: true — включить сервис ceph_mon.
   • ceph_mgr: true — включить сервис ceph_mgr.
   • ceph_mds: true — включить сервис ceph_mds.
   • mon_deploy: first — указатель узла, на котором будет происходить установка Ceph с нуля (bootstrap).
   • ceph_mgr_restful_enable: true — включить модуль restful в сервисе ceph_mgr, через который zabbix-agent2 собирает метрики кластера для мониторинга.
   • ceph_mgr_zabbix_enable: false — отключить устаревший модуль zabbix сервиса ceph_mgr, который отправляет метрики в Zabbix напрямую.

3. В файле vkcloud/group_vars/vkcloud_ceph_osd/vars.yml заполните параметры нового кластера Ceph. В словаре clusters_ceph добавьте новый ключ с названием кластера, перечислите пулы, которые нужно создать при его развертывании, укажите параметры авторизации клиентов и прочие параметры в соответствии с приведенным ниже примером.

   Ceph-кластер использует следующие пулы:

   • cinder-volumes — используется для хранения дисков (volume) сервиса Cinder. Cinder создает блочные устройства (диски), управляет ими и подключает их к виртуальным машинам.

   • manila-volumes — используется для хранения файловых хранилищ сервиса Manila. Manila предоставляет сервис совместного доступа к файлам.

   • vms — используется для хранения эфемерных дисков виртуальных машин, то есть дисков, которые существуют, пока существует сама виртуальная машина. Обычно это корневые диски, создаваемые Nova, и config_drive.

     Пул vms также хранит загрузочные диски виртуальных машин, которые обслуживают файловые хранилища сервиса Manila. config_drive по умолчанию включен для всех виртуальных машин во внешних сетях и для служебных виртуальных машин сервисов Trove, Magnum и Octavia.

     Сервис Nova использует только один пул vms — тот, который задан в /etc/nova/nova.conf.

   Пример параметров нового кластера:

    
   clusters_ceph:...  ceph<НОМЕР_КЛАСТЕРА>:    ceph_osd_pools:      - name: cinder-volumes        application: rbd        pg_num: 128        pgp_num: 128      - name: vms        application: rbd        pg_num: 64        pgp_num: 64      - name: manila-volumes        application: rbd        pg_num: 128        pgp_num: 128    ceph_osd_clients:      - name: monitoring        key: '{{ vault_ceph_monitoring_key }}'        caps:          mon:            - profile rbd          osd:            - profile rbd pool=cinder-volumes            - profile rbd pool=vms            - profile rbd pool=manila-volumes      - name: cinder        key: '{{ vault_ceph["ceph<НОМЕР_КЛАСТЕРА>"].vault_ceph_client_key }}'        caps:          mon:            - profile rbd          osd:            - profile rbd pool=cinder-volumes            - profile rbd pool=vms            - profile rbd pool=manila-volumes      - name: ceph<НОМЕР_КЛАСТЕРА>        key: '{{ vault_ceph["ceph<НОМЕР_КЛАСТЕРА>"].vault_ceph_client_key }}'        caps:          mon:            - profile rbd          osd:            - profile rbd pool=cinder-volumes            - profile rbd pool=vms            - profile rbd pool=manila-volumes      - name: manila<НОМЕР_КЛАСТЕРА>        key: '{{ vault_ceph["ceph<НОМЕР_КЛАСТЕРА>"].vault_ceph_client_manila }}'        caps:          mon:            - profile rbd          osd:            - profile rbd pool=manila-volumes    ceph_params:      mon_id: 1      ceph_auth_allow_insecure_global_id_reclaim: false      ceph_public_networks: "<ВНЕШНЯЯ_СЕТЬ>"      ceph_cluster_networks: "<ВНУТРЕННЯЯ_СЕТЬ>"      ceph_osd_l2_only: true      ceph_osd_part_type: lvm      ceph_osd_use_hostname_as_monid: true      ceph_osd_initial_weight: 0.15      ceph_replicated_type: rack      az: '{{ availability_zones["az1"] | upper }}'      compute_role: ceph-osd      cluster: ceph<НОМЕР_КЛАСТЕРА>

   Здесь:

   • <НОМЕР_КЛАСТЕРА> — номер нового кластера Ceph. Номер должен быть уникальным в рамках инсталляции и продолжать уже принятую схему нумерации кластеров.

   • <ВНЕШНЯЯ_СЕТЬ> — адрес внешней сети кластера в формате CIDR.

   • <ВНУТРЕННЯЯ_СЕТЬ> — внутренняя сеть кластера в формате CIDR.

   • ceph_replicated_type — тип бакетов в Ceph, на уровне которых будет распределяться репликация данных. Поддерживаемые типы: host и rack.

   • pg_num — общее количество групп размещения (PG) пула. Определяет, на сколько частей распределяются объекты пула по OSD-узлам кластера.

   • pgp_num — количество групп размещения, которые учитываются алгоритмом CRUSH при реальном распределении данных пула по OSD. Обычно равно значению pg_num.

     Подробнее о том, как вычислить значения параметров pg_num и pgp_num, — в документе Руководство по проектированию в разделе Основные принципы проектирования новой инсталляции → Расчет количества групп размещения (PG) Ceph.

   • vault_ceph_monitoring_key — ключ клиента monitoring. Общий для всех кластеров Ceph, задается один раз и не привязан к конкретному кластеру.

4. В файле vkcloud/group_vars/vkcloud/vault.yml в переменной vault_ceph заполните параметры key — параметры авторизации клиентов:

    
   ...vault_ceph:  ceph<НОМЕР_КЛАСТЕРА>:    vault_ceph_client_key: <КЛЮЧ_ДОСТУПА>    vault_ceph_client_manila: <КЛЮЧ_ДОСТУПА>    vault_ceph_admin_key: <КЛЮЧ_ДОСТУПА>    vault_ceph_osd_bootstrap: <КЛЮЧ_ДОСТУПА>    vault_nova_compute_images_ceph_pass: <ID>    vault_manila_rbd_secret_uuid: <ID>    vault_ceph_cluster_fsid: <ID>    vault_ceph_mgr_restful_key: <ID>...

   Здесь:

   • <НОМЕР_КЛАСТЕРА> — номер нового кластера Ceph. Номер должен быть уникальным в рамках инсталляции и продолжать уже принятую схему нумерации кластеров.

   • <КЛЮЧ_ДОСТУПА> — ключи, которые нужно сгенерировать. Это можно сделать на узле Ceph, где есть утилита ceph-authtool, с помощью команды:

      
     $ ceph-authtool --gen-print-key

   • <ID> — идентификаторы, которые нужно сгенерировать. Это можно сделать с помощью утилиты uuidgen.

5. В файле vkcloud/group_vars/vkcloud/vars.yml заполните параметры нового кластера Ceph. Добавьте описание карты CRUSH в словарь ceph_clusters:

    
   ...ceph_clusters:...  ceph<НОМЕР_КЛАСТЕРА>:    rack_<НОМЕР_СТОЙКИ_1>:      - <НОВЫЙ_УЗЕЛ_1>    rack_<НОМЕР_СТОЙКИ_2>:      - <НОВЫЙ_УЗЕЛ_2>    rack_<НОМЕР_СТОЙКИ_3>:      - <НОВЫЙ_УЗЕЛ_3>...

   Здесь:

   • <НОМЕР_КЛАСТЕРА> — номер нового кластера Ceph. Номер должен быть уникальным в рамках инсталляции и продолжать уже принятую схему нумерации кластеров.
   • rack_<НОМЕР_СТОЙКИ_1>, rack_<НОМЕР_СТОЙКИ_2> и т.д. — названия стоек для размещения узлов кластера Ceph (Ceph-бакет с типом rack). Нумерация должна быть уникальной в рамках инсталляции и продолжать уже принятую схему именования существующих стоек.
   • <НОВЫЙ_УЗЕЛ_1>, <НОВЫЙ_УЗЕЛ_2>, <НОВЫЙ_УЗЕЛ_3> — имена новых узлов кластера Ceph. Имена должны быть уникальными в рамках инсталляции и соответствовать уже принятой схеме именования узлов.

6. В файле vkcloud/hosts.yml заполните параметры новых узлов Ceph и добавьте их в соответствующие существующие и новые группы.

   Пример структуры:

    
   ...hosts:...  <НОВЫЙ_УЗЕЛ_1>:    management_ip: <IP_MANAGEMENT>    mon_address: <IP_CEPHEXTERNAL>  <НОВЫЙ_УЗЕЛ_2>:    management_ip: <IP_MANAGEMENT>    mon_address: <IP_CEPHEXTERNAL>  <НОВЫЙ_УЗЕЛ_3>:    management_ip: <IP_MANAGEMENT>    mon_address: <IP_CEPHEXTERNAL>...groups:......  ceph:    - <СУЩЕСТВУЮЩИЙ_УЗЕЛ_1>    ...    - <СУЩЕСТВУЮЩИЙ_УЗЕЛ_N>    - <НОВЫЙ_УЗЕЛ_1>    - <НОВЫЙ_УЗЕЛ_2>    - <НОВЫЙ_УЗЕЛ_3>  ceph<НОМЕР_КЛАСТЕРА>:    - <НОВЫЙ_УЗЕЛ_1>    - <НОВЫЙ_УЗЕЛ_2>    - <НОВЫЙ_УЗЕЛ_3>  ceph<НОМЕР_КЛАСТЕРА>_mon:    - <НОВЫЙ_УЗЕЛ_1>    - <НОВЫЙ_УЗЕЛ_2>    - <НОВЫЙ_УЗЕЛ_3>...

   Здесь:

   • <НОМЕР_КЛАСТЕРА> — номер нового кластера Ceph. Номер должен быть уникальным в рамках инсталляции и продолжать уже принятую схему нумерации кластеров.
   • <IP_MANAGEMENT> — IP-адрес соответствующего узла из сети Management.
   • <IP_CEPHEXTERNAL> — IP-адрес соответствующего узла из сети cephexternal.
   • <НОВЫЙ_УЗЕЛ_1>, <НОВЫЙ_УЗЕЛ_2>, <НОВЫЙ_УЗЕЛ_3> — имена новых узлов кластера Ceph. Имена должны быть уникальными в рамках инсталляции и соответствовать принятой схеме именования узлов.
   • <СУЩЕСТВУЮЩИЙ_УЗЕЛ_1> и <СУЩЕСТВУЮЩИЙ_УЗЕЛ_N> — имена существующих узлов Ceph в остальных кластерах инсталляции.

7. В файле vkcloud/group_vars/vkcloud/zabbix.yml заполните параметры нового Ceph-кластера в словарях zabbix_ceph_clusters и zabbix_groups_map_tmp.

   Пример структуры:

    
   ...zabbix_ceph_clusters:...  - name: ceph<НОМЕР_КЛАСТЕРА>    zabbix_agent2: true    ceph_dc: '{{ consul_dc }}'...zabbix_groups_map_tmp:...ceph<НОМЕР_КЛАСТЕРА> MON nodes:  meta:    - ceph<НОМЕР_КЛАСТЕРА>-mon  templates:    - Ceph mon template    - Linux by Zabbix agentceph<НОМЕР_КЛАСТЕРА> OSD nodes:  meta:    - ceph<НОМЕР_КЛАСТЕРА>-osd  templates: []...

   Здесь <НОМЕР_КЛАСТЕРА> — номер нового кластера Ceph. Номер должен быть уникальным в рамках инсталляции и продолжать уже принятую схему нумерации кластеров.

8. В файле vkcloud/group_vars/vkcloud/ceph.yml заполните словарь ceph, ключи cluster_info и keyrings в соответствии с примером ниже. От заполняемых параметров зависит, какие компоненты Платформы могут обращаться к новому кластеру Ceph.

   Пример заполнения файла ceph.yml:

    
   ceph:  cluster_info:...    - name: ceph<НОМЕР_КЛАСТЕРА>      user: ceph<НОМЕР_КЛАСТЕРА>      compute: true      storage_type: ssd      az: '{{ availability_zones["az1"] | upper }}'      fsid: '{{ vault_ceph["ceph<НОМЕР_КЛАСТЕРА>"].vault_ceph_cluster_fsid }}'      rbd_cluster_name: ceph<НОМЕР_КЛАСТЕРА>      rbd_secret_uuid: '{{ vault_ceph["ceph<НОМЕР_КЛАСТЕРА>"].vault_nova_compute_images_ceph_pass }}'      monitors:        - name: <НОВЫЙ_УЗЕЛ_1>          mon_address: <АДРЕС_MON>        - name: <НОВЫЙ_УЗЕЛ_2>          mon_address: <АДРЕС_MON>        - name: <НОВЫЙ_УЗЕЛ_3>          mon_address: <АДРЕС_MON>    - name: manila<НОМЕР_КЛАСТЕРА>      user: manila<НОМЕР_КЛАСТЕРА>      compute: true      storage_type: ssd      az: '{{ availability_zones["az1"] | upper }}'      fsid: '{{ vault_ceph["ceph<НОМЕР_КЛАСТЕРА>"].vault_ceph_cluster_fsid }}'      rbd_cluster_name: manila<НОМЕР_КЛАСТЕРА>      rbd_secret_uuid: '{{ vault_ceph["ceph<НОМЕР_КЛАСТЕРА>"].vault_manila_rbd_secret_uuid }}'      monitors:        - name: <НОВЫЙ_УЗЕЛ_1>          mon_address: <АДРЕС_MON>        - name: <НОВЫЙ_УЗЕЛ_2>          mon_address: <АДРЕС_MON>        - name: <НОВЫЙ_УЗЕЛ_3>          mon_address: <АДРЕС_MON>  keyrings:    client:...      ceph<НОМЕР_КЛАСТЕРА>:        name: ceph<НОМЕР_КЛАСТЕРА>        az: '{{ availability_zones["az1"] | upper }}'        key: '{{ vault_ceph["ceph<НОМЕР_КЛАСТЕРА>"].vault_ceph_client_key }}'        uuid: '{{ vault_ceph["ceph<НОМЕР_КЛАСТЕРА>"].vault_nova_compute_images_ceph_pass }}'      manila<НОМЕР_КЛАСТЕРА>:        name: manila<НОМЕР_КЛАСТЕРА>        az: '{{ availability_zones["az1"] | upper }}'        key: '{{ vault_ceph["ceph<НОМЕР_КЛАСТЕРА>"].vault_ceph_client_manila }}'        uuid: '{{ vault_ceph["ceph<НОМЕР_КЛАСТЕРА>"].vault_manila_rbd_secret_uuid }}'    bootstrap_osd:...      ceph<НОМЕР_КЛАСТЕРА>: '{{ vault_ceph["ceph<НОМЕР_КЛАСТЕРА>"].vault_ceph_osd_bootstrap | default('''') }}'    admin:...      ceph<НОМЕР_КЛАСТЕРА>: '{{ vault_ceph["ceph<НОМЕР_КЛАСТЕРА>"].vault_ceph_admin_key }}'

   Здесь:

   • <НОМЕР_КЛАСТЕРА> — номер нового кластера Ceph. Номер должен быть уникальным в рамках инсталляции и продолжать уже принятую схему нумерации кластеров.
   • <АДРЕС_MON> — адрес сервера с функцией MON из сети cephexternal.
   • storage_type — тип дисков, который используется в Ceph. Возможные значения: ssd или hdd.

1. Перейдите в директорию /opt/vkcloud/inventory/vkcloud:

    
   $ cd /opt/vkcloud/inventory/vkcloud

2. Запустите плейбуки для подготовки к развертыванию кластера. Для установки только на новые узлы запуск выполняется с ключом --limit или переменной -e limit=. Способ ограничения узлов зависит от плейбука.

   1. Запустите плейбук pred-deploy.yml:

       
      # ../ansible-openstack/tools/box.sh deploy -b ../ansible-openstack -i vkcloud.yml --playbook pred-deploy.yml -s base --limit <НОВЫЙ_УЗЕЛ_1>,<НОВЫЙ_УЗЕЛ_2>,<НОВЫЙ_УЗЕЛ_3>,localhost

      Для этого плейбука параметр localhost обязателен.

   2. Запустите плейбук common.yml:

       
      # ../ansible-openstack/tools/box.sh deploy -b ../ansible-openstack -i vkcloud.yml --playbook common.yml -s base -e limit=<НОВЫЙ_УЗЕЛ_1>,<НОВЫЙ_УЗЕЛ_2>,<НОВЫЙ_УЗЕЛ_3>

   После выполнения плейбуков узлы будут готовы к дальнейшей установке кластера Ceph.

3. Запустите плейбук ceph-containers.yml для развертывания кластера Ceph:

    
   # ../ansible-openstack/tools/box.sh deploy -b ../ansible-openstack -i vkcloud.yml --playbook ceph-containers.yml -s ceph --disks-autoconfigure --limit <НОВЫЙ_УЗЕЛ_1>,<НОВЫЙ_УЗЕЛ_2>,<НОВЫЙ_УЗЕЛ_3>

   После выполнения плейбука:

   • будет развернут описанный параметрами кластер Ceph;
   • будут инициализированы ключи для доступа клиентов;
   • будут размечены диски;
   • будут созданы OSD.

4. Для настройки мониторинга на новых узлах повторно запустите плейбук common.yml, указав деплой-группу main:

    
   # ../ansible-openstack/tools/box.sh deploy -b ../ansible-openstack -i vkcloud.yml --playbook common.yml -s main -e limit=<НОВЫЙ_УЗЕЛ_1>,<НОВЫЙ_УЗЕЛ_2>,<НОВЫЙ_УЗЕЛ_3>

   Подробнее о деплой-группах — в документе Руководство по установке в разделе Приложения → Описание скрипта установки.

Чтобы убедиться в работоспособности кластера, подключитесь к одному из узлов с ролью MON и выполните шаги:

1. Проверьте состояние кластера:

    
   $ ceph health detail

   Убедитесь, что кластер находится в состоянии HEALTH_OK.

2. Проверьте состав и конфигурацию кластера, а также доступные ресурсы:

   1. Просмотрите деревья OSD и CRUSH:

       
      $ ceph osd tree

   2. Запросите объем используемого дискового пространства:

       
      $ ceph df

   3. Узнайте количество групп размещения (placement groups):

       
      $ ceph osd pool ls detail

Параметры подключения компонентов Платформы к кластеру Ceph описываются в Inventory-файле:

 
vkcloud/group_vars/vkcloud_cinder/vars.yml

Убедитесь, что новый кластер Ceph находится в состоянии HEALTH_OK, и подключите к нему компоненты Платформы:

1. Заполните словарь volume_backends в соответствии с примером ниже:

    
   ...volume_backends:...  - name: ceph<НОМЕР_КЛАСТЕРА>    volume_driver: ceph    description: AZ={{ availability_zones["az1"] | upper }}, cluster=ceph<НОМЕР_КЛАСТЕРА>    cluster_name: ceph<НОМЕР_КЛАСТЕРА>    backend_name: ceph    rbd_pool: cinder-volumes    rbd_user: ceph<НОМЕР_КЛАСТЕРА>    image_cache: true    goodness_function: 0    storage_availability_zone: '{{ availability_zones["az1"] | upper }}'    placement: '{{ availability_zones["az1"] | upper }}'    clustered: true  - name: manila<НОМЕР_КЛАСТЕРА>    volume_driver: ceph    description: AZ=nova, cluster=ceph<НОМЕР_КЛАСТЕРА>    cluster_name: manila<НОМЕР_КЛАСТЕРА>    backend_name: manila    rbd_pool: manila-volumes    rbd_user: manila<НОМЕР_КЛАСТЕРА>    image_cache: true    goodness_function: 0    storage_availability_zone: nova    placement: '{{ availability_zones["az1"] | upper }}'    clustered: true...

   Здесь backend_name должен совпадать с volume_type существующего кластера Ceph.

2. Создайте резервные копии директорий /etc/ceph и /etc/cinder на управляющих и вычислительных узлах на случай, если в Inventory была допущена ошибка.

3. После заполнения параметров запустите плейбуки соответствующих компонентов, которые нужно подключить к новому кластеру. Обычно новый кластер подключается для компонентов Cinder, Nova и Zabbix. Плейбук можно запустить сначала с параметром --limit, указав нужные узлы, на которые будут применены изменения.

   Пример для Cinder, Nova и Zabbix:

   1. Перейдите в директорию /opt/vkcloud/inventory/vkcloud:

       
      $ cd /opt/vkcloud/inventory/vkcloud

   2. Запустите плейбук для Cinder:

       
      # ../ansible-openstack/tools/box.sh deploy -b ../ansible-openstack -i vkcloud.yml --playbook cinder-volume-deploy.yml -s core

      Пример запуска с ключом --limit:

       
      # ../ansible-openstack/tools/box.sh deploy -b ../ansible-openstack -i vkcloud.yml --playbook cinder-volume-deploy.yml -s core --limit <УПРАВЛЯЮЩИЙ_УЗЕЛ_1>,<УПРАВЛЯЮЩИЙ_УЗЕЛ_2>

      Здесь <УПРАВЛЯЮЩИЙ_УЗЕЛ_1>, <УПРАВЛЯЮЩИЙ_УЗЕЛ_2> — имена управляющих узлов, на которых нужно применить изменения конфигурации Cinder.

   3. Запустите плейбук для Nova:

       
      # ../ansible-openstack/tools/box.sh deploy -b ../ansible-openstack -i vkcloud.yml --playbook compute-deploy.yml -s core

      Пример запуска с ключом --limit:

       
      # ../ansible-openstack/tools/box.sh deploy -b ../ansible-openstack -i vkcloud.yml --playbook compute-deploy.yml -s core --limit <ВЫЧИСЛИТЕЛЬНЫЙ_УЗЕЛ_1>,<ВЫЧИСЛИТЕЛЬНЫЙ_УЗЕЛ_2>

      Здесь <ВЫЧИСЛИТЕЛЬНЫЙ_УЗЕЛ_1>, <ВЫЧИСЛИТЕЛЬНЫЙ_УЗЕЛ_2> — имена вычислительных узлов, на которых нужно применить изменения конфигурации Nova.

   4. Запустите плейбук для добавления нового кластера в мониторинг Zabbix:

       
      # ../ansible-openstack/tools/box.sh deploy -b ../ansible-openstack -i vkcloud.yml --playbook zabbix_configure_resources.yml -s main

      Пример запуска с ключом --limit:

       
      # ../ansible-openstack/tools/box.sh deploy -b ../ansible-openstack -i vkcloud.yml --playbook zabbix_configure_resources.yml -s main --limit <НОВЫЙ_УЗЕЛ_1>,<НОВЫЙ_УЗЕЛ_2>,<НОВЫЙ_УЗЕЛ_3>

      Здесь <НОВЫЙ_УЗЕЛ_1>, <НОВЫЙ_УЗЕЛ_2>, <НОВЫЙ_УЗЕЛ_3> — имена новых узлов кластера Ceph, которые нужно зарегистрировать в мониторинге Zabbix.