Расширение тома до replica 3

В данном руководстве описывается процесс расширения тома GlusterFS, состоящего из одного брика, до replica 3.

Создание дополнительных записей имен серверов

На каждый из дополнительных серверов кластера и на ВМ HOSTVM Manager добавить в файлы /etc/hosts записи следующего вида:

192.168.120.10    glusternode1    glusternode1.localdomain
192.168.120.11    glusternode2    glusternode2.localdomain
192.168.120.12    glusternode3    glusternode3.localdomain
  • glusternode1-3 имя нод GlusterFS (второе имя для серверов и их IP-адреса на выделенных под Gluster интерфейсах).

  • Опционально можно прописать все имена на DNS-сервере.

Создание бриков на хостах

Разметка дискового пространства:

Допустим, что под новый брик мы хотим выделить 120 ГБ.

Для размещения используем рейд-массив дисков, представленный в виде устройства /dev/sdX.

На каждом из серверов создадим logical volume:

pvcreate /dev/sdxY
vgcreate datavg /dev/sdxY
lvcreate -L 120G -n datastore_lv datavg
mkfs.xfs /dev/mapper/datavg-datastore_lv
mkdir -p /data/gluster/datastore 
  • datavg – имя новой вольюм группы;

  • datastore_lv – имя вольюма в составе вольюм группы datavg.

  • /data/gluster/datastore - точка монтирования

После того, как созданы том и файловая система, следующий шаг – создать запись в /etc/fstab:

И примонтировать том:

На каждом из серверов создать директории под брики и запустить службу glusterd:

Открываем требуемые порты на каждом сервере:

Инициализация хранилища replica 3

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

В примере команды выполняются с glusternode1.

Добавим ноды GlusterFS в зону видимости друг друга:

Добавляем дополнительный брик к тому datastore командой:

Аналогично добавляем еще один брик:

Либо одной длинной командой:

Проверяем статус тома:

Дополнительные настройки при расширении хранилища, содержащего HOSTVM Manager

Перед расширением тома, содержащего управляющую машину, переведите кластер в global maintenance:

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

Создайте резервную копию конфигурации управляющей машины:

Сохраните файл резервной копии на хост/ПК.

Выключите управляющую машину:

На хосте добавьте следующую строку в файл /etc/ovirt-hosted-engine/hosted-engine.conf:

Дополнительно выполните команды:

где:

[he_local] – задает значение в локальном экземпляре файла /etc/ovirt-hosted-engine/hosted-engine.conf на локальном хосте, чтобы только этот хост использовал новые значения. Чтобы включить новое значение, перезапустите службы ovirt-ha-agent и ovirt-ha-broker.

[he_shared] - задает значение в файле /etc/ovirt-hosted-engine/hosted-engine.conf в shared storage, чтобы все хосты, развернутые после изменения конфигурации, использовали эти значения. Чтобы включить новое значение на хосте, повторно разверните этот хост.

Убедитесь, что параметр добавился корректно:

Если эта опция применена, то при сбое первого сервера volfile серверы, указанные в опции backup-volfile-servers, используются в качестве серверов volfile для монтирования клиента до тех пор, пока монтирование не завершится успешно.

Перезагрузите хост, содержащий управляющую машину.

Включите упраляющую машину:

Убедитесь, что виртуальная машина запустилась:

Выведите кластер из режима обслуживания:

Last updated

Was this helpful?