Как дружить с БД VMware Cloud Director

Делимся опытом настройки базы данных на примере версии Cloud Director 10.х.

27 октября • Николай Королев

Иногда возникают ситуации, когда требуется работать с базой данных VMware Cloud Director не только с поддержкой инженеров вендора, но и самостоятельно: могут залипнуть объекты, невозможно переконфигурировать ВМ, не получается удалить или создать какие-либо объекты, необходимо перенастроить БД, восстановить работу PostgreSQL HA Cluster и т. д.

Хочу поделиться опытом настройки и работы со встроенной БД на примере версии Cloud Director 10.х.

Главное примечание: все действия с БД вы выполняете на свой страх и риск, поэтому не забывайте про необходимость резервного копирования.

Настраиваем подключение к БД

Чтобы зайти в БД, нужно подключиться к ssh на cell напрямую и выполнить команду:

sudo -u postgres /opt/vmware/vpostgres/current/bin/psql -d vcloud -U postgres

Я предпочитаю подключаться к БД с помощью pgAdmin, поэтому остановлюсь на этом варианте подробнее.

Как предлагает это делать вендор, описано тут:
https://docs.vmware.com/en/VMware-Cloud-Director/10.0/com.vmware.vcloud.install.doc/GUID-3A3BB3A9-F6F3-47BA-A785-2B99882A692B.html

Мягко говоря, не слишком подробно, поэтому я распишу подключение по шагам.

Сразу отмечу, что подключаться надо именно к primary cell, так как на secondary не будут отрабатываться запросы delete, update и т. д.

Разрешаем доступ к БД vcloud

Подключаемся по ssh на cell.

Затем создаем файл remote.conf:

vi /opt/vmware/appliance/etc/pg_hba.d/remote.conf

со следующим содержимым:

# TYPE DATABASE USER ADDRESS METHOD
host DB_name DB_user network/prefix md5

где DB_name – имя БД (в нашем случае vcloud), DB_user – по умолчанию vcloud, network/prefix – сеть, откуда можно подключиться к БД.

Пример:

# TYPE DATABASE USER ADDRESS METHOD
host vcloud vcloud 10.0.0.0/24 md5
host vcloud vcloud 192.168.0.15/32 md5

Как только закончили редактировать файл remote.conf, данные с файла автоматически добавятся в конец файла /var/vmware/vpostgres/10/pgdata/pg_hba.conf. Однако иногда этого не происходит. Тогда можно добавить данные строки самостоятельно и перечитать конфиг:

sudo -i -u postgres /opt/vmware/vpostgres/current/bin/psql -c 'SELECT pg_reload_conf();'

либо

sudo -u postgres /opt/vmware/vpostgres/current/bin/psql -d vcloud -U postgres
SELECT pg_reload_conf();
\q

Создаем пользователя

Если требуется создать пользователя для работы с БД стороннему приложению (мониторинг, биллинг и т. д.), то можно поступить следующим образом:

sudo -u postgres /opt/vmware/vpostgres/current/bin/psql -d vcloud -U postgres
create role "test-user" login password 'PASS!';
GRANT CONNECT ON DATABASE "vcloud" TO "test-user";
GRANT USAGE ON SCHEMA public TO "test-user";
GRANT SELECT ON ALL TABLES IN SCHEMA public TO "test-user"

Созданный пользователь не будет иметь права на редактирование БД. Не забываем добавить разрешение в БД для данного пользователя в файле remote.conf:

host vcloud test-user 192.168.100.10/32 md5

Открываем firewall

У Cloud Director два интерфейса: eth0 и eth1. Маршрут по умолчанию идет через eth0, а БД открыта в iptables только для eth1. Поэтому для доступа к БД со стороны сокета PostgreSQL нужно или открывать iptables на порт 5432 для eth0, или делать постоянный маршрут. Еще вариант: делать SNAT на шлюзе сети eth1 для трафика, пришедшего с места подключения к БД.

Чтобы открыть iptables, нужно отредактировать файл /etc/systemd/scripts/ip4save-vmw, добавив до COMMIT строки:

-A INPUT -s network/prefix -p tcp -m state --state NEW -m tcp --dport 5432 -j ACCEPT

Пример:

-A INPUT -s 192.168.0.15/32 -p tcp -m state --state NEW -m tcp --dport 5432 -j ACCEPT

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

iptables-restore < /etc/systemd/scripts/ip4save-vmw

Как настроить доступ к БД, узнали, теперь посмотрим, в каких случаях он нам может потребоваться.

1. Доступ к БД для поддержки вендора

По ssh можно работать с БД, но это не так удобно, как с использованием pgAdmin или любого аналогичного решения. Какой бы вариант вы ни выбрали, все необходимое в такой ситуации вам подскажет вендор.

2. Исправление записей БД самостоятельно

Проблемы, которые можно решить помощью БД, весьма разнообразны. Многие этого не подозревают, поэтому я приведу несколько примеров.

Ищем нужное значение в таблицах: функция глобального поиска

Для начала создадим функцию глобального поиска БД global_search, которой нет в БД «из коробки», но которая может понадобиться нам в дальнейшем.

Подключаемся к БД и выполняем SQL-запрос:

Посмотреть код

CREATE OR REPLACE FUNCTION global_search(
search_term text,
param_tables text[] default '{}',
param_schemas text[] default '{public}',
progress text default null -- 'tables','hits','all'
)
RETURNS table(schemaname text, tablename text, columnname text, rowctid tid)
AS $$
declare
query text;
hit boolean;
begin
FOR schemaname,tablename IN
SELECT table_schema, table_name
FROM information_schema.tables t
WHERE (t.table_name=ANY(param_tables) OR param_tables='{}')
AND t.table_schema=ANY(param_schemas)
AND t.table_type='BASE TABLE'
LOOP
IF (progress in ('tables','all')) THEN
raise info '%', format('Searching globally in table: %I.%I',
schemaname, tablename);
END IF;
query := format('SELECT ctid FROM %I.%I AS t WHERE strpos(cast(t.* as text), %L) > 0',
schemaname,
tablename,
search_term);
FOR rowctid IN EXECUTE query
LOOP
FOR columnname IN
SELECT column_name
FROM information_schema.columns
WHERE table_name=tablename
AND table_schema=schemaname
LOOP
query := format('SELECT true FROM %I.%I WHERE cast(%I as text)=%L AND ctid=%L',
schemaname, tablename, columnname, search_term, rowctid);
EXECUTE query INTO hit;
IF hit THEN
IF (progress in ('hits', 'all')) THEN
raise info '%', format('Found in %I.%I.%I at ctid %s',
schemaname, tablename, columnname, rowctid);
END IF;
RETURN NEXT;
END IF;
END LOOP; -- for columnname
END LOOP; -- for rowctid
END LOOP; -- for table
END;
$$ language plpgsql;

Запускаем функцию global_search:

SELECT * FROM global_search ('searchWord');

Поскольку поиск ведется по всей БД, он может идти долго. В ответ будет возвращена информация о местонахождении записи. Если при вызове данной функции вы получите ошибку, то либо вы подключились к secondary node, либо БД повреждена.

Давайте рассмотрим несколько простых примеров исправления проблем через БД. До выполнения работ обязательно создавайте бэкапы.

Чистим inventory

Выключаем службы cell:

/opt/vmware/vcloud-director/bin/cell-management-tool cell -i `cat /var/run/vmware-vcd-cell.pid` -shutdown

Подключившись к БД, выполняем SQL-запрос:

select 'delete from ' || table_name || ';' from INFORMATION_SCHEMA.TABLES where table_name like '%_inv' and TABLE_TYPE = 'BASE TABLE';

К полученному результату добавляем строку:

delete from property_map;

Нужно переместить ccr_ наверх и выполнить получившийся SQL-запрос

Пример:

Посмотреть код

delete from ccr_drs_host_group_host_inv;
delete from ccr_drs_host_group_inv;
delete from ccr_drs_rule_inv;
delete from ccr_drs_vm_group_inv;
delete from ccr_drs_vm_group_vm_inv;
delete from ccr_drs_vm_host_rule_inv;
delete from cluster_compute_resource_inv;
delete from compute_resource_inv;
delete from custom_field_manager_inv;
delete from datacenter_inv;
delete from datacenter_network_inv;
delete from datastore_inv;
delete from datastore_profile_inv;
delete from drs_rule_vm_inv;
delete from dv_portgroup_inv;
delete from dv_switch_inv;
delete from folder_inv;
delete from managed_server_datastore_inv;
delete from managed_server_inv;
delete from managed_server_network_inv;
delete from network_inv;
delete from opaque_network_inv;
delete from resource_pool_inv;
delete from storage_pod_inv;
delete from storage_profile_inv;
delete from task_inv;
delete from vm_dstore_metrics_inv;
delete from vm_inv;
delete from property_map;
После этого запускаем службы:
service vmware-vcd start

Удаляем сеть из vApp

Привожу упрощенный пример, когда сеть надо удалить из всех vApp, а не из конкретной:

select * from logical_network where name= 'delete-test-network';

В данном случае имеем всего 2 записи, scope_type=3 – это сеть, подключенная к vApp.

Так как нам надо полностью избавиться от сети, то выполняем следующие SQL-запросы:

select * from logical_network where name= ''delete-test-network'' and scope_type=3;
--update logical_network set rnet_id=null where name= ''delete-test-network'' and scope_type=3;

Теперь в GUI можно удалить данную сеть из vApp, а затем из организации.

Ищем объекты, которые занимают определенную Storage Policy

Когда вы пытаетесь удалить политику, которая, на ваш взгляд, не используется, и получаете ошибку «Storage policy "SATA" cannot be deleted since it is currently in use», можно попробовать узнать, кто же ее использует:

select * from public.ui_org_vdc_storage_class_view where sclass_name = 'storage_policy_name' and vdc_name = 'OrgVDC_name';

Запоминаем sclass_lr_id и используем его в следующем SQL-запросе:

Посмотреть код

select * from
(
SELECT *
--ldisk_storage_class_join.storage_class_id AS storage_class_lr_id,
-- COALESCE(sum(logical_disk.size_bytes::numeric / 1048576.0), 0::numeric) AS storage_used_mb,
-- 0 AS storage_overhead_mb
FROM logical_disk
LEFT JOIN ldisk_storage_class_join ON logical_disk.id = ldisk_storage_class_join.logical_disk_id
LEFT JOIN ldisk_fo_join ON logical_disk.id = ldisk_fo_join.logical_disk_id
LEFT JOIN disk ON disk.id = ldisk_fo_join.fo_id
LEFT JOIN ( SELECT vm_disk.disk_id
FROM vm_disk
GROUP BY vm_disk.disk_id) vdisk ON vdisk.disk_id = ldisk_fo_join.fo_id
WHERE (logical_disk.logical_disk_type::text = ANY (ARRAY['CDROM'::bpchar::character varying, 'FLOPPY'::bpchar::character varying]::text[])) OR logical_disk.logical_disk_type::bpchar = 'DISK'::bpchar AND (vdisk.disk_id IS NULL OR disk.sharing_type::text = 'DISK_SHARING'::text OR disk.sharing_type::text = 'CONTROLLER_SHARING'::text)
-- GROUP BY ldisk_storage_class_join.storage_class_id
) as hui
where hui.storage_class_id= sclass_lr_id

Получаем объекты в OrgVDC, которые расположены на данной политике.

Устраняем проблемы с Refresh storage policy

select * from lock_handle;
-- delete from lock_handle;

select * from lock_intent;
-- delete from lock_intent;

select * from storage_profile_inv;
-- delete from storage_profile_inv;

Удаляем сбойные задания из организации

Иногда они появляются в ответе api-запроса при запросе конфигурации OrgVDC:

select * from org_prov_vdc where name like '%test-orgvcd%'

записываем id организации

select * from activity where state_handle in (select job_id from jobs where object_id = 'id' and status = '3')
--delete from jobs where object_id = 'id' and status = '3'

3. Тюнинг БД

Иногда, с ростом инфраструктуры или в связи с обновлением, требуется изменить размер appliance, после чего для оптимальной работы VMware Cloud Director требуется внести изменения в работу БД.

Если хотите более детально углубиться в требования, стоит почитать документ VMware Validated Design for Cloud Providers: Scale and Performance Guidelines для вашей версии Cloud Director.

Рассмотрим тюнинг на примере VMware Cloud Director 10.3: https://cloudsolutions.vmware.com/content/dam/digitalmarketing/microsites/en/images/cloud-solutions/pdfs/VVD_for_Cloud_Providers_Scale_and_Performance-VCD_10.3.pdf

Проверяем текущие настройки БД:

sudo -u postgres /opt/vmware/vpostgres/current/bin/psql -d vcloud -U postgres
show all;

Эталонные значения:

shared_buffers = 0.25 * (total RAM – 4 GB)
effective_cache_size = 0.75 * (total RAM – 4 GB)
work_mem = '8MB';"
maintenance_work_mem = '1GB';"
max_worker_processes = количество ядер на cell, но не меньше 8.

Меняем на нужные, например:

sudo -i -u postgres
psql -c "ALTER SYSTEM set shared_buffers = '7GB';"
psql -c "ALTER SYSTEM set effective_cache_size = '21GB';"
psql -c "ALTER SYSTEM set work_mem = '8MB';"
psql -c "ALTER SYSTEM set max_worker_processes = '24';"
psql -c "ALTER SYSTEM set maintenance_work_mem = '1GB';"

Копируем postgresql.auto.conf из primary node на standby node:

scp /var/vmware/vpostgres/current/pgdata/postgresql.auto.conf postgres@<standby-node-address>:/var/vmware/vpostgres/current/pgdata/

Запускаем службу vpostgres:

systemctl restart vpostgres

Для удаления ручных настроек используем команды ниже:

psql -c "ALTER SYSTEM reset shared_buffers;"
psql -c "ALTER SYSTEM reset effective_cache_size;"
psql -c "ALTER SYSTEM reset max_worker_processes;"

Официальная документация на данную тему:

4. Обслуживание БД при восстановлении работы HA кластера

Начиная c vCD 9.7 поддерживается схема из трех нод vCD с отказоустойчивой внутренней БД. Это привносит некоторые нюансы при работе с нодами vCD.

Аварийные ситуации в работе БД могут возникнуть по таким причинам:

откат на состояние снапшота, где primary изменена на другую ноду;
перезагрузка cell, когда Failover mode выставлен Automatic;
выполнение каких-либо работ на cell, связанных с БД и прочее.

Официальную документацию, как следует действовать в данной ситуации, смотрите тут:
https://docs.vmware.com/en/VMware-Cloud-Director/10.4/VMware-Cloud-Director-Install-Configure-Upgrade-Guide/GUID-BC8B408B-C024-4011-9107-B0238E190D9E.html

Если вы не хотите по каким-либо причинам разворачивать новую ячейку, то можно воспользоваться unsupport-методами, описанными Tomas Fojta в статье: https://fojta.wordpress.com/2019/05/23/vcloud-director-9-7-appliance-tips/

Статья актуальна и для более новых версий. Далее будут выжимки из его статьи и официальной документации.

Итак, если возникла аварийная ситуация, то требуется:

Если это возможно, выполнить резервную копию данных на текущей primary по инструкции:
https://docs.vmware.com/en/VMware-Cloud-Director/10.3/VMware-Cloud-Director-Install-Configure-Upgrade-Guide/GUID-9562FBC9-4537-4FE6-B1CC-005C232A556D.html
Классифицировать проблему, выполнив в консоли всех ячеек с базой данных команду:
```
sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf cluster show
```

По итогам вывода необходимо выполнить один из сценариев, описанных ниже.

Если произошел отказ одной standby-ноды:

на работоспособность vCD не влияет;
блокирует смену primary без --force.

Восстанавливается включением standby или деплоем новой ячейки из ova (новая ячейка берет всю необходимую информацию из параметров при деплое и с NFS-шары).

Если через деплой из ova:
1. Удаляем потерянную ноду из postgres.
```
sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf cluster show
sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf standby unregister --node-id=<failed-standby-node-id>
```
2. Удаляем потерянную ноду из интерфейса vCD.
3. Деплоим новую ноду по инcтрукции:
  https://docs.vmware.com/en/vCloud-Director/9.7/com.vmware.vcloud.install.doc/GUID-8278404A-4C98-47FF-98EE-911EBC4C654D.html
Если нужно вернуть существующую ноду, но она не подключается, например из-за того, что опережает primary node вследствии клонирования или восстановления из РК, то есть как минимум два пути: сделать ее primary node или инициализировать по новой с отстающей primary node.
1. Останавливаем сервис БД на standby:
```
systemctl stop vpostgres.service
```
2. Перемещаем данные на standby (перед перемещением убедимся, что хватит места):
```
mv /var/vmware/vpostgres/current/pgdata /root
```
3. Клонируем данные с primary:
```
sudo -i -u postgres /opt/vmware/vpostgres/current/bin/repmgr -h <primary_database_IP> -U repmgr -d repmgr -f /opt/vmware/vpostgres/current/etc/repmgr.conf standby clone
```
4. Запускаем сервис БД:
```
systemctl start vpostgres.service
```
5. При необходимости регистрируем standby на primary (регистрация может не потребоваться, если stanby не удалялся из конфигурации primary):
```
sudo -i -u postgres /opt/vmware/vpostgres/current/bin/repmgr -h <primary_database_IP> -U repmgr -d repmgr -f /opt/vmware/vpostgres/current/etc/repmgr.conf standby register --force
```

Отказ primary-ноды:

ведет к отказу интерфейса vCD;
требует ручного переключения primary-ноды через веб-интерфейс той ноды, которая становится главной http://fqdn:5480 -> promote;

Включение старой primary-ноды ведет к ситуации с двумя primary: рабочая отмечена звездочкой *, выходившая из строя восклицательным знаком “!” или тире “–” с подписью failed, и ее нужно сделать standby. Вот тут будет самое интересное.

Единственный поддерживаемый способ – это удаление прежней primary-ноды и деплой новой standby-ноды из ova.
1. Удаляем потерянную ноду из postgres:
```
sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf primary unregister --node-id=<failed-primary-node-id>
```
2. Удаляем потерянную ноду из интерфейса vCD.
3. Деплоим новую ноду по инструкции:
  https://docs.vmware.com/en/vCloud-Director/9.7/com.vmware.vcloud.install.doc/GUID-8278404A-4C98-47FF-98EE-911EBC4C654D.html
Есть и не поддерживаемый способ:
https://fojta.wordpress.com/2019/05/23/vcloud-director-9-7-appliance-tips/
1. Останавливаем vpostgres на прежней primary (на той, что с восклицательным знаком!):
```
systemctl stop vpostgres.service
```
2. Удаляем данные на прежней primary (на той, что с восклицательным знаком!):
```
mv /var/vmware/vpostgres/current/pgdata /root
```
3. Клонируем данные:
```
sudo -i -u postgres /opt/vmware/vpostgres/current/bin/repmgr -h <primary_database_IP> -U repmgr -d repmgr -f /opt/vmware/vpostgres/current/etc/repmgr.conf standby clone
```
4. Если не работает и вылетает с ошибкой timeout, то используем IP с другого интерфейса.
5. Запускаем сервис vpostgres:
```
systemctl start vpostgres.service
```
6. Добавляем ноду в кластер:
```
sudo -i -u postgres /opt/vmware/vpostgres/current/bin/repmgr -h <primary_database_IP> -U repmgr -d repmgr -f /opt/vmware/vpostgres/current/etc/repmgr.conf standby register --force
```

Потеря двух standby-нод:

ведет к недоступности интерфейса vCloud Director из-за перехода primary-ноды в read only;
требует восстановления потерянных нод или деплоя новой ноды из ova с новым DNS-именем;

Есть не поддерживаемый способ, который заключается в переводе оставшейся primary из HA группы в standalone:

Удаляем потерянные standby:

sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf cluster show
sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf standby unregister --node-id=<failed-standby-id1>
sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf standby unregister --node-id=<failed-standby-id2>

Удаляем потерянные ноды из интерфейса vCD;

Удаляем каталоги потерянных нод с NFS-шары:

mv /opt/vmware/vcloud-director/data/transfer/appliance-nodes/node-<UUID1> /backup/location
mv /opt/vmware/vcloud-director/data/transfer/appliance-nodes/node-<UUID2> /backup/location

Удаляем ноды из параметра synchronous_standby_names = '' в файле /var/vmware/vpostgres/current/pgdata/postgresql.conf, если они там остались (у меня при тестировании их не было).
Перечитываем конфиг:
```
systemctl reload vpostgres.service
```
БД должна перейти в режим read-write.

Отказ standby и primary:

ведет к недоступности интерфейса vCloud Director из-за перехода standby-ноды в read only;
оставшуюся standby можно поднять до primary, выполнив promote, но она останется в read only.

До promote требуется восстановление потерянных нод, после promote – вычистка NFS-шары и конфигов от старой primary и деплоя новой standby-ноды из ova с новым DNS-именем;

Жмем promote для оставшейся standby.

Удаляем потерянные ноды из postgres:

sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf cluster show
sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf primary unregister --node-id=<failed-primary-id>
sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf standby unregister --node-id=<failed-standby-id>

Исправляем IP-адрес primary БД в файлах:

/opt/vmware/vcloud-director/etc/responses.properties
/opt/vmware/vcloud-director/etc/global.properties
/opt/vmware/vcloud-director/data/transfer/responses.properties

Останавливаем vpostgres на отказавших primary и standby:
```
systemctl stop vpostgres.service
```
Удаляем данные на отказавших primary и standby:
```
mv /var/vmware/vpostgres/current/pgdata /root/
```

Клонируем данные:

sudo -i -u postgres /opt/vmware/vpostgres/current/bin/repmgr -h <primary_database_IP> -U repmgr -d repmgr -f /opt/vmware/vpostgres/current/etc/repmgr.conf standby clone

Если не работает и вылетает с ошибкой timeout, то используем IP с другого интерфейса.
Запускаем сервис vpostgres:
```
systemctl start vpostgres.service
```

Добавляем ноду в кластер:

sudo -i -u postgres /opt/vmware/vpostgres/current/bin/repmgr -h <primary_database_IP> -U repmgr -d repmgr -f /opt/vmware/vpostgres/current/etc/repmgr.conf standby register --force

Потеря standby и primary

ведет к недоступности интерфейса vCloud Director из-за перехода standby node в read only;
оставшуюся standby node можно поднять до primary, выполнив promote, но она останется в read only.

До promote требуется восстановление потерянных нод, после promote нужна чистка NFS-шары и конфигов от старой primary и деплой новой standby-ноды из ova с новым DNS-именем.

Promote оставшейся standby.

Удаляем потерянные standby и primary из postgres и NFS:

sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf cluster show
sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf primary unregister --node-id=<failed-primary-id>
sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf standby unregister --node-id=<failed-standby-id>

Удаляем потерянные ноды из интерфейса vCD.

Удаляем каталоги потерянных нод с NFS-шары:

mv /opt/vmware/vcloud-director/data/transfer/appliance-nodes/node-<UUID1> /backup/location
mv /opt/vmware/vcloud-director/data/transfer/appliance-nodes/node-<UUID2> /backup/location

Исправляем IP-адреса БД в файлах:

/opt/vmware/vcloud-director/etc/responses.properties
/opt/vmware/vcloud-director/etc/global.properties
/opt/vmware/vcloud-director/data/transfer/responses.properties

Регистрируем имя новой ноды на DNS-сервере.
Deploy новой временной standby с новым DNS-именем, для того чтобы вывести кластер из режима "только чтение" по инструкции:
https://docs.vmware.com/en/vCloud-Director/9.7/com.vmware.vcloud.install.doc/GUID-8278404A-4C98-47FF-98EE-911EBC4C654D.html
Deploy новой standby со старыми DNS-именами по инструкции:
https://docs.vmware.com/en/vCloud-Director/9.7/com.vmware.vcloud.install.doc/GUID-8278404A-4C98-47FF-98EE-911EBC4C654D.html
После восстановления прежней HA группы временную standby можно удалить.

Завершающий шаг

После восстановления работоспособности БД:

Восстанавливаем режим обработки отказов БД с Indeterminate на Manual/Automatic по инструкции:
https://docs.vmware.com/en/VMware-Cloud-Director/10.3/VMware-Cloud-Director-Install-Configure-Upgrade-Guide/GUID-5DFEF587-29C0-46D4-89D8-8725EBFAEF19.html

То есть выполняем API-запрос:
```
POST https://vcd-cell-fqdn:5480/api/1.0.0/nodes/failover/{desired-mode}
Authorization: Basic
{desired-mode} - automatic/manual
```
Либо через curl:
```
curl -X POST -H "Accept: application/json" -H "Authorization: Basic [[basicHash]]" "https://localhost/api/1.0.0/nodes/failover/{desired-mode}"
```
Проверяем результат по инструкции:
https://docs.vmware.com/en/VMware-Cloud-Director/10.3/VMware-Cloud-Director-Install-Configure-Upgrade-Guide/GUID-E1B642AB-95CF-4B34-BAB1-8576A6E53C6A.html#GUID-E1B642AB-95CF-4B34-BAB1-8576A6E53C6A

Проверить Failover mode можно как в GUI апплаенса (https://vcd-cell-fqdn:5480), так и через API-запрос:
```
GET https://vcd-cell-fqdn:5480/api/1.0.0/nodes
Authorization: Basic
```
Либо через curl:
```
curl -X GET -H "Accept: application/json" -H "Authorization: Basic [[basicHash]]" "https://localhost/api/1.0.0/nodes"
```

На этом пока все. Желаем вам удачи в эксплуатации БД VMware Cloud Director.

Расскажите друзьям и коллегам о статье

Последние статьи

Упрощаем мониторинг заданий в Veeam Backup and Replication

Как мы создали мощный инструмент для мониторинга процессов в системе резервного копирования на основе Grafana.

16 августа 2023 Андрей Александров

Новая точка на карте ЦОДов Москвы

Фотоэкскурсия по первой очереди дата-центра в Медведково.

23 марта 2023 Алексей Приезжев

Как найти проблему с производительностью ВМ на VMware ESXi

Рассказываем, как проверять ресурсы ВМ на ошибки и даем ключевые метрики, на которые можно опираться.

17 января 2023 DataLine

Как дружить с БД VMware Cloud Director

Настраиваем подключение к БД

Разрешаем доступ к БД vcloud

Создаем пользователя

Открываем firewall

1. Доступ к БД для поддержки вендора

2. Исправление записей БД самостоятельно

Ищем нужное значение в таблицах: функция глобального поиска

Посмотреть код

Чистим inventory

Посмотреть код

Удаляем сеть из vApp

Ищем объекты, которые занимают определенную Storage Policy

Посмотреть код

Устраняем проблемы с Refresh storage policy

Удаляем сбойные задания из организации

3. Тюнинг БД

4. Обслуживание БД при восстановлении работы HA кластера

Если произошел отказ одной standby-ноды:

Отказ primary-ноды:

Потеря двух standby-нод:

Отказ standby и primary:

Потеря standby и primary

Завершающий шаг

Расскажите друзьям и коллегам о статье

Подписка

Последние статьи