[ English | Deutsch | Indonesia | русский | English (United Kingdom) ]

Масштабирование вашего окружения¶

Это черновик страницы масштабирования окружения для предлагаемого руководства по эксплуатации OpenStack-Ansible.

Добавление нового хоста инфраструктуры¶

Хотя рекомендуется использовать три хоста инфраструктуры, если в среде потребуются дополнительные хосты, можно создать дополнительные узлы.

Предупреждение

Убедитесь, что вы сделали резервную копию текущего окружения OpenStack перед добавлением новых узлов. См. Резервное копирование и восстановление вашего облака для получения дополнительной информации.

Add the node to the infra_hosts stanza of the /etc/openstack_deploy/openstack_user_config.yml:
```
infra_hosts:
[...]
  infra<node-ID>:
    ip: 10.17.136.32
```
Change to playbook folder on the deployment host:
```
# cd /opt/openstack-ansible
```

To prepare new hosts and deploy containers on them run setup-hosts.yml: playbook with the limit argument.

# openstack-ansible openstack.osa.setup_hosts --limit localhost,infra<node-ID>,infra<node-ID>-host_containers

In case you’re relying on /etc/hosts content, you should also update it for all hosts:

# openstack-ansible openstack.osa.openstack_hosts_setup -e openstack_hosts_group=all --tags openstack_hosts-file

Next we need to expand Galera/RabbitMQ clusters, which is done during setup-infrastructure.yml. So we will run this playbook without limits:
Предупреждение

Make sure that containers from new infra host does not appear in inventory as first one for groups galera_all, rabbitmq_all and repo_all. You can verify that with ad-hoc commands:
```
# ansible -m debug -a "var=groups['galera_all'][0]" localhost
# ansible -m debug -a "var=groups['rabbitmq_all'][0]" localhost
# ansible -m debug -a "var=groups['repo_all'][0]" localhost
```
```
# openstack-ansible openstack.osa.setup_infrastructure -e galera_force_bootstrap=true
```
После того, как инфраструктурные плейбуки завершили работу, очередь за развертыванием служб OpenStack. Большинство служб можно запускать с ограничениями, но некоторые, например keystone, — нет. Поэтому мы запускаем плейбук keystone отдельно от всех остальных:
```
# openstack-ansible openstack.osa.keystone
# openstack-ansible openstack.osa.setup_openstack --limit '!keystone_all',localhost,infra<node-ID>,infra<node-ID>-host_containers
```

Тестирование новых узлов инфраструктуры¶

После создания нового узла infra проверьте, что узел работает правильно, запустив новый инстанс. Убедитесь, что новый узел может ответить на тест сетевого соединения с помощью команды ping. Войдите в свою систему мониторинга и убедитесь, что мониторы возвращают зеленый сигнал для нового узла.

Добавить вычислительный хост¶

Для добавления вычислительного узла в рабочий кластер используйте следующую процедуру.

Configure the host as a target host. See the target hosts configuration section of the deploy guide for more information.
Отредактируйте файл /etc/openstack_deploy/openstack_user_config.yml и добавьте хост в `` compute_hosts` `.

При необходимости также измените `` usd_ips``.
Если кластер использует службу телеметрии/измерения (ceilometer), отредактируйте файл /etc/openstack_deploy/conf.d/ceilometer.yml и добавьте хост в `` stering-compute_hosts``.
Запустите следующие команды, чтобы добавить хост. Замените `` new_host_name`` на имя нового хоста.
```
# cd /opt/openstack-ansible/playbooks
# openstack-ansible openstack.osa.setup_hosts --limit localhost,NEW_HOST_NAME
# openstack-ansible openstack.osa.openstack_hosts_setup -e openstack_hosts_group=nova_compute --tags openstack_hosts-file
# openstack-ansible openstack.osa.setup_openstack --limit localhost,NEW_HOST_NAME
```
В качестве альтернативы вы можете попробовать использовать новый скрипт развертывания вычислительных узлов /opt/openstack-ansible/scripts/add-compute.sh.

Вы можете дополнить этот сценарий дополнительными задачами, которые будут выполняться до или сразу после ролей OpenStack-Asble. Для этого вы должны установить переменные окружения `` pre_osa_tasks`` или `` post_osa_tasks`` с пьесами для запуска с полуколоном:
```
# export POST_OSA_TASKS="/opt/custom/setup.yml --limit HOST_NAME;/opt/custom/tasks.yml --tags deploy"
# /opt/openstack-ansible/scripts/add-compute.sh HOST_NAME,HOST_NAME_2
```

Проверьте новые вычислительные узлы¶

After creating a new node, test that the node runs correctly by launching an instance on the new node:

$ openstack server create --image IMAGE --flavor m1.tiny \
--key-name KEY --availability-zone ZONE:HOST:NODE \
--nic net-id=UUID SERVER

Убедитесь, что новый инстанс может ответить на тест на сетевое соединение через команду: `` ping`. Войдите в систему мониторинга и убедитесь, что мониторы возвращают зеленый сигнал для нового узла.

Удалить вычислительный хост¶

Репозиторий OpenStack-Ansible Operator Tooling содержит руководство по удалению вычислительного узла из окружения OpenStack-Ansible. Чтобы удалить вычислительный узел, выполните следующую процедуру.

Примечание

В этом руководстве описано, как полностью удалить вычислительный узел из окружения OpenStack-Ansible. Выполняйте эти шаги с осторожностью, так как после их завершения вычислительный узел больше не будет работать. В данном руководстве предполагается, что все данные и инстансы были перенесены должным образом.

Disable all OpenStack services running on the compute node. This can include, but is not limited to, the nova-compute service and the neutron agent service:

Примечание

Ensure this step is performed first.
```
# Run these commands on the compute node to be removed
# systemctl stop nova-compute
# systemctl stop neutron-openvswitch-agent
```
Клонируйте репозиторий openstack-ansible-ops на ваш хост развертывания:
```
$ git clone https://opendev.org/openstack/openstack-ansible-ops \
  /opt/openstack-ansible-ops
```
Запустите плейбук Ansible remove_compute_node.yml с установленной пользовательской переменной host_to_be_removed:
```
$ cd /opt/openstack-ansible-ops/ansible_tools/playbooks
openstack-ansible remove_compute_node.yml \
-e host_to_be_removed="<name-of-compute-host>"
```
После завершения работы плейбука удалите вычислительный узел из конфигурационного файла OpenStack-Ansible в файле /etc/openstack_deploy/openstack_user_config.yml.

Recover a compute host failure¶

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

Примечание

Если общее хранилище не используется, перед выполнением следующей процедуры можно скопировать данные из каталога /var/lib/nova/instances на отказавшем вычислительном узле ${FAILED_NODE} на другой узел ${RECEIVING_NODE}. Обратите внимание, что этот метод не поддерживается.

Повторно запустите все инстансы на отказавшем узле.
Invoke the MariaDB command line tool.
Генерирует список UUID инстансов, размещенных на отказавшем узле:
```
mysql> select uuid from instances where host = '${FAILED_NODE}' and deleted = 0;
```

Set instances on the failed node to be hosted on a different node:

mysql> update instances set host ='${RECEIVING_NODE}' where host = '${FAILED_NODE}' \
and deleted = 0;

Перезагрузите каждый инстанс на отказавшем узле, указанном в предыдущем запросе, чтобы перегенерировать XML-файлы:
```
# nova reboot —hard $INSTANCE_UUID
```

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

mysql> select nova.instances.uuid as instance_uuid, cinder.volumes.id \
as voume_uuid, cinder.volumes.status, cinder.volumes.attach_status, \
cinder.volumes.mountpoint, cinder.volumes,display_name from \
cinder.volumes inner join nova.instances on cinder.volumes.instance_uuid=nova.instances.uuid \
where nova.instances.host = '${FAILED_NODE}';

Если строки найдены, отсоедините и снова присоедините диски, используя значения, указанные в предыдущем запросе:
```
# nova volume-detach $INSTANCE_UUID $VOLUME_UUID && \
# nova volume-attach $INSTANCE_UUID $VOLUME_UUID $VOLUME_MOUNTPOINT
```
Rebuild or replace the failed node as described in add-compute-host.

Замена вышедшего из строя оборудования¶

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

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

На каком типе узла я заменяю оборудование?
Можно ли заменить оборудование без отключения хоста? Например, один диск в RAID-10.
If the host DOES have to be brought down for the hardware replacement, how should the resources on that host be handled?

Если на вычислительном хосте (nova) произошел сбой диска в RAID-10, можно заменить сбойный диск, не отключая питание хоста. С другой стороны, если отказала оперативная память, придется отключить питание хоста. Наличие плана по управлению подобными событиями является важной частью поддержки окружения OpenStack.

For a Compute host, shut down the instance on the host before it goes down. For a Block Storage (cinder) host using non-redundant storage, shut down any instances with volumes attached that require that mount point. Unmount the drive within your operating system and re-mount the drive once the Block Storage host is back online.

Выключение вычислительного узла¶

Если вычислительный узел необходимо выключить:

Отключите бинарный файл nova-compute:

# nova service-disable --reason "Hardware replacement" HOSTNAME nova-compute

Список всех запущенных инстансов на вычислительном узле:

# nova list --all-t --host <compute_name> | awk '/ACTIVE/ {print $2}' > \
/home/user/running_instances && for i in `cat /home/user/running_instances`; do nova stop $i ; done

Используйте SSH для подключения к вычислительному узлу.
Убедитесь, что все инстансы выключены:
```
# virsh list --all
```
Выключите вычислительный узел:
```
# shutdown -h now
```
Как только вычислительный узел вернется в сеть, убедитесь, что все работает, и запустите инстансы на нем. Например:
```
# cat /home/user/running_instances
# do nova start $instance
  done
```
Включите службу nova-compute в окружении:
```
# nova service-enable HOSTNAME nova-compute
```

Выключение узла блочного хранилища¶

Если узел блочного хранилища LVM должен быть выключен:

Отключите службу cinder-volume:

# cinder service-list --host CINDER SERVICE NAME INCLUDING @BACKEND
# cinder service-disable CINDER SERVICE NAME INCLUDING @BACKEND \
cinder-volume --reason 'RAM maintenance'

List all instances with Block Storage volumes attached:

# mariadb cinder -BNe 'select instance_uuid from volumes where deleted=0 '\
'and host like "%<cinder host>%"' | tee /home/user/running_instances

Shut down the instances:

# cat /home/user/running_instances | xargs -n1 nova stop

Убедитесь, что инстансы выключены:

# cat /home/user/running_instances | xargs -n1 nova show | fgrep vm_state

Выключите узел блочного хранилища:
```
# shutdown -h now
```
Замените вышедшее из строя оборудование и проверьте работоспособность нового.

Включите службу cinder-volume:

# cinder service-enable CINDER SERVICE NAME INCLUDING @BACKEND cinder-volume

Убедитесь, что службы на хосте снова подключены к окружению:
```
# cinder service-list --host CINDER SERVICE NAME INCLUDING @BACKEND
```

Запустите инстансы и убедитесь, что все инстансы запущены:

# cat /home/user/running_instances | xargs -n1 nova start
# cat /home/user/running_instances | xargs -n1 nova show | fgrep vm_state

Удаление контейнеров¶

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

# openstack-ansible openstack.osa.containers_lxc_destroy --limit localhost,<container name|container group>
Примечание

Вам будет задано два вопроса:

Вы уверены, что хотите удалить контейнеры LXC? Вы уверены, что хотите удалить данные контейнеров LXC?

The first will just remove the container but leave the data in the bind mounts and logs. The second will remove the data in the bind mounts and logs too.