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

Главная
Как дружить с БД VMware Cloud Director

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

27.10.2022 12:56

storied 5 600 Источник

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

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

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

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

Восстанавливается включением 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=<failed-standby-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 <primary_database_IP> -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 <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.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=<failed-primary-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 <primary_database_IP> -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 <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.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>
```
1.2. Удаляем потерянные ноды из интерфейса vCD;

1.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
```
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=<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>
```
  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 <primary_database_IP> -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 <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.
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=<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>
```
  1.3. Удаляем потерянные ноды из интерфейса vCD.
  
  1.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
```
  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 можно удалить.

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

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

Восстанавливаем режим обработки отказов БД с Indeterminate на Manual/Automatic по инструкции.

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

Комментарии (5)

Alternativ
27.10.2022 15:08
#24856654
Отлично структурировано и всё в одном месте. Многим поможет. От себя могу добавить пару штук.
1. Сети я удаляю чуть изящнее:
SELECT * --DELETE FROM public.logical_network where link_lnet_id = ( SELECT id FROM public.logical_network where name like 'DELETE%' )
но бывает дублируются идентификаторы, тогда ручками по-порядку...

2 Искать по имени проще через global_search от сапорта, но искать зависимости по ID как по мне удобнее через grep дампа базы, например:
$ pg_dump --data-only --inserts -U postgres vcloud > vcloud.tmp $ cat vcloud.tmp | grep -v public.audit_trail | grep -v public.activity_partition | grep -v public.jobs | grep '<id>'
как бонус будет возможность быстро восстановиться т.к. вывод будет в формате INSERT INTO...
1. Пару раз была ситуация, когда залипала VM (vApp). В зависимости от того, что за сущность, ищем ее в таблице vapp_vm, vm или vm_container и меняем статус на RESOLVED, например:
  UPDATE [vmw-db01].[dbo].[vapp_vm] SET [creation_status] = 'RESOLVED' WHERE [name] like 'vm_name%'
1. storied Автор
  27.10.2022 15:12
  #24856670
  да у нас накопилось десяток разных кейсов по работе с БД, отобразил лишь несколько, чтобы показать лишь, что кейсы бывают разные. Статья и так слишком объемная, а примеров в интернете на самые распространенные кейсы хватает.

Speccyfan
27.10.2022 17:20
#24857208
Извините, что придираюсь, но продукт называется VMware vCloud Director
1. storied Автор
  27.10.2022 20:45
  #24857902
  Уже нет.
1. storied Автор
  27.10.2022 22:00
  #24858104
  +1
  Since April 2020, vCloud Director for Service Providers changed its product name to VMware Cloud Director.

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

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

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

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

Открываем firewall

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

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

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

Чистим inventory

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

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

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

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

3. Тюнинг БД

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

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

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

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

Отказ standby и primary:

Потеря standby и primary

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

Комментарии (5)

Alternativ

storied Автор

Speccyfan

storied Автор

storied Автор