Как дружить с БД VMware Cloud Director27.10.2022 15:16

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

Как предлагает это делать вендор, описано тут.

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

Сразу отмечу, что подключаться надо именно к 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. 

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

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@:/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;"

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

1. https://docs.vmware.com/en/VMware-Cloud-Director/10.3/VMware-Cloud-Director-Install-Configure-Upgrade-Guide/GUID-B242C866–5547–4CB7–95AC-552FE25CDEBA.html 

2. https://docs.vmware.com/en/VMware-Cloud-Director/10.3/vcd_103_install.pdf (стр. 40)

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

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

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

• откат на состояние снапшота, где primary изменена на другую ноду;

• перезагрузка cell, когда Failover mode выставлен Automatic;

• выполнение каких-либо работ на cell, связанных с БД и прочее.

Официальную документацию, как следует действовать в данной ситуации, смотрите тут.

Если вы не хотите по каким-либо причинам разворачивать новую ячейку, то можно воспользоваться unsupport-методами, описанными Tomas Fojta в статье.

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

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

1.   Если это возможно, выполнить резервную копию данных на текущей primary по инструкции.

 2.   Классифицировать проблему, выполнив в консоли всех ячеек с базой данных команду:

sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf cluster show

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

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

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

   1.1. Если через деплой из ova:  

   1.1.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=

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

   1.1.3. Разворачиваем новую ноду по инструкции.

   1.2. Если нужно вернуть существующую ноду, но она не подключается, например из-за того, что опережает primary node вследствие клонирования или восстановления из РК, то есть как минимум два пути: сделать ее primary node или инициализировать по новой с отстающей primary node.

   1.2.1. Останавливаем сервис БД на standby:

   systemctl stop vpostgres.service

   1.2.2 Перемещаем данные на standby (перед перемещением убедимся, что хватит места):

   mv /var/vmware/vpostgres/current/pgdata /root

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

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

   1.2.4 Запускаем сервис БД:

   systemctl start vpostgres.service

   1.2.5 При необходимости регистрируем standby на primary (регистрация может не потребоваться, если stanby не удалялся из конфигурации primary):

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

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

• ведет к отказу интерфейса vCD;

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

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

   1.1. Единственный поддерживаемый способ — это удаление прежней primary-ноды и деплой новой standby-ноды из ova.

   1.1.1. Удаляем потерянную ноду из postgres:

   sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf primary unregister --node-id=

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

   1.1.3. Деплоим новую ноду по инструкции: https://docs.vmware.com/en/vCloud-Director/9.7/com.vmware.vcloud.install.doc/GUID-8278404A-4C98–47FF-98EE-911EBC4C654D.html

   1.2. Есть и не поддерживаемый способ: https://fojta.wordpress.com/2019/05/23/vcloud-director-9–7-appliance-tips/

   1.2.1. Останавливаем vpostgres на прежней primary (на той, что с восклицательным знаком!):

   systemctl stop vpostgres.service

   1.2.2. Удаляем данные на прежней primary (на той, что с восклицательным знаком!):

   mv /var/vmware/vpostgres/current/pgdata /root

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

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

   1.2.4 Если не работает и вылетает с ошибкой timeout, то используем IP с другого интерфейса.

   1.2.5 Запускаем сервис vpostgres:

   systemctl start vpostgres.service

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

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

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

• ведет к недоступности интерфейса vCloud Director из-за перехода primary-ноды в read only;

• требует восстановления потерянных нод или деплоя новой ноды из ova с новым DNS-именем;

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

   1.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=
   sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf standby unregister --node-id=

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

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

   mv /opt/vmware/vcloud-director/data/transfer/appliance-nodes/node- /backup/location
   mv /opt/vmware/vcloud-director/data/transfer/appliance-nodes/node- /backup/location

   1.4. Удаляем ноды из параметра synchronous_standby_names = '' в файле /var/vmware/vpostgres/current/pgdata/postgresql.conf, если они там остались (у меня при тестировании их не было).

   1.5. Перечитываем конфиг:

   systemctl reload vpostgres.service

   1.6. БД должна перейти в режим read-write.

Отказ standby и primary:

• ведет к недоступности интерфейса vCloud Director из-за перехода standby-ноды в read only;

• оставшуюся standby можно поднять до primary, выполнив promote, но она останется в read only.

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

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

     1.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=
     sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf standby unregister --node-id=

     1.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

     1.4. Останавливаем vpostgres на отказавших primary и standby:

     systemctl stop vpostgres.service

     1.5. Удаляем данные на отказавших primary и standby:

     mv /var/vmware/vpostgres/current/pgdata /root/

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

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

     1.7. Если не работает и вылетает с ошибкой timeout, то используем IP с другого интерфейса.

     1.8. Запускаем сервис vpostgres:

     systemctl start vpostgres.service

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

     sudo -i -u postgres /opt/vmware/vpostgres/current/bin/repmgr -h  -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.

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

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

     1.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=
     sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf standby unregister --node-id=

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

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

     mv /opt/vmware/vcloud-director/data/transfer/appliance-nodes/node- /backup/location
     mv /opt/vmware/vcloud-director/data/transfer/appliance-nodes/node- /backup/location

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

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

     1.6. Регистрируем имя новой ноды на DNS-сервере.

     1.7. Deploy новой временной standby с новым DNS-именем, для того чтобы вывести кластер из режима «только чтение» по инструкции:

     1.8. Deploy новой standby со старыми DNS-именами по инструкции.

     1.9. После восстановления прежней HA группы временную standby можно удалить.

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

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

То есть выполняем 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}"

Проверить 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.

© Habrahabr.ru