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

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

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

 • 

Иногда возникают ситуации, когда требуется работать с базой данных 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/

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

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

  1. Если это возможно, выполнить резервную копию данных на текущей 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
  2. Классифицировать проблему, выполнив в консоли всех ячеек с базой данных команду:

    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-шары).

  1. Если через деплой из 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
  2. Если нужно вернуть существующую ноду, но она не подключается, например из-за того, что опережает 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. Вот тут будет самое интересное.

  1. Единственный поддерживаемый способ – это удаление прежней 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
  2. Есть и не поддерживаемый способ:
    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:

  1. Удаляем потерянные 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>
  2. Удаляем потерянные ноды из интерфейса vCD;
  3. Удаляем каталоги потерянных нод с 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
  4. Удаляем ноды из параметра synchronous_standby_names = '' в файле /var/vmware/vpostgres/current/pgdata/postgresql.conf, если они там остались (у меня при тестировании их не было).
  5. Перечитываем конфиг:

    systemctl reload vpostgres.service
  6. БД должна перейти в режим read-write.

Отказ standby и primary:

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

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

  1. Жмем promote для оставшейся standby.
  2. Удаляем потерянные ноды из 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>
  3. Исправляем IP-адрес primary БД в файлах:

    /opt/vmware/vcloud-director/etc/responses.properties
    /opt/vmware/vcloud-director/etc/global.properties
    /opt/vmware/vcloud-director/data/transfer/responses.properties
  4. Останавливаем vpostgres на отказавших primary и standby:

    systemctl stop vpostgres.service
  5. Удаляем данные на отказавших primary и standby:

    mv /var/vmware/vpostgres/current/pgdata /root/
  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 clone
  7. Если не работает и вылетает с ошибкой timeout, то используем IP с другого интерфейса.
  8. Запускаем сервис vpostgres:

    systemctl start vpostgres.service
  9. Добавляем ноду в кластер:

    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-именем.

  1. Promote оставшейся standby.
  2. Удаляем потерянные 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>
  3. Удаляем потерянные ноды из интерфейса vCD.
  4. Удаляем каталоги потерянных нод с 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
  5. Исправляем IP-адреса БД в файлах:

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

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

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

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

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

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

Заглядываем в гости к нашим техническим специалистам.

DataLine

Основные рекомендации про то, как мигрировать базу данных 1С с MS SQL на PostgreSQL в одной статье.

DataLine
DataLine