Как восстановить NSX Edge и перенести его настройки через API
В этой статье расскажу, как работать через API с NSX Edge. Это решение от VMware выполняет для виртуального дата-центра функции маршрутизации, Firewall, NAT, DHCP, VPN и другие. Благодаря возможностям работы через API отправка запросов к Edge становится удобнее и нагляднее, чем в командной строке.
Описанный здесь способ также решает некоторые проблемы обращения к Edge через vCloud Director. При работе через API у нас есть возможность работать с Edge напрямую через NSX или через vCloud Director, а также с помощью API обращаться к БД vCloud Director. Покажу оба варианта.
Вот наиболее интересные сценарии, когда нам пригодится использование API:
Миграция Edge в другой NSX-менеджер.
Восстановление Edge или части его настроек. Например, если после миграции из одного дата-центра в другой мы также переносим настройки файрвола, VPN, балансировщика нагрузки и т. п.
Резервное копирование настроек. Например, если мы хотим сохранить конфигурацию Edge в формате XML и при необходимости вернуться к ней.
В описании я использую NSX-V 6.4.6 и vCloud Director 10.2, однако статья актуальна и для других версий ПО. Для всех экспериментов пользовался документацией по API отсюда.
Готовим инструмент для работы с API
Для работы с API вы можете использовать любой удобный продукт. В моем примере будем работать через Postman: чаще всего его применяют для тестирования различных API и отправки запросов на сервер. Сами специалисты VMware нередко используют его для работы с API, так что можно считать это косвенной рекомендацией вендора.
Сразу напомню самые распространенные типы запросов:
GET — получение информации из инфраструктуры, не выполняет изменения.
POST — чаще всего создание нового объекта или добавление конфигурации к существующему.
PUT — обновление текущего объекта, старые данные объекта затираются.
DELETE — удаление объекта.
Чтобы запросы работали корректно, настроим Postman для работы с NSX-менеджером, который управляет всеми объектами Edge.
Открываем Postman и настраиваем авторизацию. Выбираем тип Basic Auth, указываем логин и пароль от админской учетной записи.
Настраиваем заголовки. Указываем Content-Type: application/xml
Пробуем вывести список Edge командой GET https://nsx-fqdn/api/4.0/edges (где nsx-fqdn — это IP-адрес или FQDN NSX-менеджера).
Получили 200 ОК, значит, все в порядке: авторизация, заголовки и другие параметры указаны верно.
Вывод этого запроса покажет длинный список Edge и базовую информацию по каждому из них. Посмотрим, как это использовать в нужном нам сценарии.
Восстанавливаем Edge целиком или его отдельные настройки
Возьмем пример, где актуальны все три сценария использования API.
Итак, у нас есть 2 NSX-менеджера, один из которых мы восстановили в изолированную сеть из бэкапа недельной давности, как описано здесь.
Обозначим оригинальный NSX-менеджер как nsx-fqdn-1, а восстановленный NSX-manager как nsx-fqdn-2. Предположим, по какой-то причине объект edge-8 был удален, и нам необходимо его восстановить.
Для начала сформируем запрос на получение конфига этого Edge из восстановленного NSX. Авторизация и заголовки у нас уже настроены, необходимо только указать в запросе нужный FQDN NSX-менеджера.
GET https://nsx-fqdn-2/api/4.0/edges/edge-8
Получаем вот такую конфигурацию. Часть конфигурации изменил, чтобы избежать утечки данных.
Конфиг целиком.edge-8 8 deployed 88ed64d3-516d-4932-a262-9987e9779f1e vse-test-delete-edge (877a6842-8a67-4dad-87cf-81e155c45763) vse-f8b2ccec-ef9b-464f-8bab-eb67e27f15c3 true false info vnic0 esxternal-ip esxternal-ip 255.255.255.192 26 1500 uplink true 0 dvportgroup-731 internet false true vnic1 10.0.0.1 255.255.255.0 24 1500 internal true 1 virtualwire-380 dvs.VCDVStest-1-5ca1ab95-ded5-4af5-bf90-96eaa70e5512 false true vnic2 1500 internal false 2 false true vnic3 1500 internal false 3 false true vnic4 1500 internal false 4 false true vnic5 1500 internal false 5 false true vnic6 1500 internal false 6 false true vnic7 1500 internal false 7 false true vnic8 1500 internal false 8 false true vnic9 1500 internal false 9 false true compact 0 500615b5-3f65-146a-1d5c-0dce84fc60ea vm-4274 resgroup-53 System vDC (c8a308dd-2509-48ad-ab8e-54e93938394d) datastore-1 DATASTORE host-18 ESXi-host group-v453 Service VMs vse-f8b2ccec-ef9b-464f-8bab-eb67e27f15c3-0 vse-test-delete-edge (877a6842-8a67-4dad-87cf-81e155c45763)-0 true -1 64 -1 256 edge-8 resgroup-53 System vDC (c8a308dd-2509-48ad-ab8e-54e93938394d) true datastore-1 DATASTORE true host-18 ESXi-host true group-v453 Service VMs true true false admin *************************************************************************** NOTICE TO USERS This computer system is the private property of its owner, whether individual, corporate or government. It is for authorized use only. Users (authorized or unauthorized) have no explicit or implicit expectation of privacy. Any or all uses of this system and all files on this system may be intercepted, monitored, recorded, copied, audited, inspected, and disclosed to your employer, to authorized site, government, and law enforcement personnel, as well as authorized officials of government agencies, both domestic and foreign. By using this system, the user consents to such interception, monitoring, recording, copying, auditing, inspection, and disclosure at the discretion of such personnel or officials. Unauthorized or improper use of this system may result in civil and criminal penalties and administrative or disciplinary action, as appropriate. By continuing to use this system you indicate your awareness of and consent to these terms and conditions of use. LOG OFF IMMEDIATELY if you do not agree to the conditions stated in this warning. **************************************************************************** 99999 3 true 196609 196609 false true esxternal-ip user snat 0 10.0.0.0/24 any any any any any 196610 196610 false true 10.0.0.3 user dnat 0 esxternal-ip any tcp 443 8443 any 2 false true notice 2 false 16 any view-0 vsm-default-view true any any false false info 2 false udp 2 false true notice false false false false false 0 10 true false VMware VMware jpg /api/4.0/edges/edge-8/sslvpn/config/layout/images/portallogo 56A2D4 996600 000000 999999 FFFFFF FFFFFF F5F5F5 1 3 false 15 false info false 3 true false false info 0 1500 external-ip 1 false 51 nssa none 0 normal none false true false 2 false 6 20 300 5666 false info 6 true false false false true true false 30 21600 30 60 10 10 120 false false false true true true deny false 131076 131076 firewall internal_high true false firewall accept false vse 131077 131077 test user true false accept false vnic-index-1 icmp any 131075 131075 default rule for ingress traffic default_policy true false default rule for ingress traffic deny 2 false false false monitor-1 tcp 5 15 3 default_tcp_monitor monitor-2 http 5 15 3 GET / default_http_monitor monitor-3 https 5 15 3 GET / default_https_monitor false info 2 false true warning ****** 2 false 2 false false info true high gatewayServices false false Теперь на основе полученной конфигурации в виде XML создадим новый Edge. Для этого:
Удаляем из него данную часть
edge-8 8 deployed Меняем
Если мы хотим восстановиться в другое место, меняем теги расположения
и другие.
С помощью тега
и , например: admin Test123!test123! Удаляем из раздела NAT теги ruleId, ruleTag, ruleType, например:
196609 196609 user
С помощью итоговой XML выполняем команду на создание нового Edge. Для этого вставим в поле Body всю XML, укажем тип raw XML и отправим запрос.
POST https://nsx-fqdn-1/api/4.0/edges/
Edge восстановлен под именем edge-9.
Теперь отдельно восстановим настройки.
Разберемся с ситуацией, когда нам нужно отдельно добавить правила NAT. Для начала нужно понять, в каком формате Edge формирует эти правила. Можно посмотреть в общем конфиге по тегу
. Но чтобы долго не искать, получим NAT-правила отдельным запросом: GET https://nsx-fqdn-1/api/4.0/edges/edge-9/nat/config
Добавим правила NAT с помощью POST-запроса. Для этого сначала удалим теги ruleId, ruleTag, ruleType, в нашем случае:
196609 196609 user И отправляем POST https://nsx-fqdn-1/api/4.0/edges/edge-9/nat/config/rules
Пример NAT-правила:
dnat 0 esxternal_ip 192.168.1.9 false true udp 80 80 Важно учесть, что правила NAT через POST-запрос не перезаписываются, а добавляются заново.
Вот что будет, если выполнить запрос дважды:
Аналогично можно выполнить операции и с настройками по другим сервисам (firewall, vpn, load balancer и другие). На будущее мы можем сохранить настройки в виде XML и хранить этот файл в качестве резервной копии.
Используем API вместе с vCloud Director. В нашем сценарии мы случайно удалили нужный нам Edge и затем восстановили его из резервной копии через API. Если Edge использовался vCloud Director«ом, но был удален через NSX-менеджер, то сам объект edge-8 удалится из vCenter, а ссылка на него останется. После восстановления наш Edge получил новый id, о котором vCloud Director еще не знает. При попытке обратиться к сервисам через vCloud Director всплывет белый экран. Чтобы исправить это, внесем исправления в БД vCloud Director для изменения id c edge-8 на edge-9.
Отправим запрос для таблицы gateway, чтобы узнать id:
select * from gateway where name like 'test-delete-edge%'
Получим:
-- id=' 877a6842–8a67–4dad-87cf-81e155c45763 ' --name=' test-delete-edge' --backing-ref='edge-8'
Проверяем, в каких таблицах есть упоминание об этом Edge:
select * from global_search ('edge-8')
Проверяем, что выбрали нужный Edge:
select * from gateway where id = '877a6842–8a67–4dad-87cf-81e155c45763'
Обновляем id Edge и убеждаемся, что он изменен.
update gateway set backing_ref = 'edge-9' where id = '877a6842–8a67–4dad-87cf-81e155c45763'
Проверим Edge со стороны vCloud Director.
Теперь сервисы отображаются корректно.
Перенесем сервисы из одного Edge в другой
Иногда с Edge требуется работать напрямую через vCloud Director, но и здесь Postman может пригодиться. Рассмотрим сценарий переноса сервисов через API vCloud Director с сохранением адресации:
Открываем Postman.
Настраиваем авторизацию:
Autorization: Basic Auth — administrator@system
Затем выполняем GET https://vCD-fqdn/api/versions
Проверяем, отработал ли запрос и смотрим на версии api.
Добавляем заголовок с этой версией:
Accept application/*+xml; version=35.0
Теперь перейдем на авторизацию по токену. Сначала получим токен с помощью запроса POST https://vCD-fqdn/api/sessions
Берем отсюда: X-VMWARE-VCLOUD-ACCESS-TOKEN.
Поменяем тип авторизации на Bearer Token и вставим значение X-VMWARE-VCLOUD-ACCESS-TOKEN.
Выполняем запрос GET https://vCD-fqdn/api/admin, чтобы убедиться, что авторизация по токену работает.
Открываем Powershell и выполняем connect-ciserver vCD-fqdn
Далее: Get-OrgVdc OrgVDCName| Get-EdgeGateway EdgeName
Копируем ссылку после Href.
Href: https://vCD-fqdn/api/admin/edgeGateway/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Возвращаемся в Postman и получаем исходный конфиг с помощью этой ссылки:
GET https://vCD-fqdn/api/admin/edgeGateway/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Создаем тело запроса на основе полученной конфигурации. Для этого берем такую «шапку»:
…и дальше копируем то, что было между тегами Например:
false true allow false true SNAT true 196609 10.0.0.0/24 external-ip false true false Если на Edge меняются портгруппы, необходимо в теге
заменить сети из старого Edge на сети из нового Edge, куда переносим сервисы: Добавим новую конфигурацию POST-запросом. Для этого вставим полученную XML в Body в формате raw для пустого Edge. Добавляем заголовок content-type application/vnd.vmware.admin.edgeGatewayServiceConfiguration+xml
В сам запрос вставляем ссылку на нужный Edge, добавив к url /action/configureServices, например:
POST https://vCD-fqdn/api/admin/edgeGateway/XXXX/action/configureServices
Конфигурация перенесена.
Этим же способом можно автоматизировать процесс сбора конфигурации. Так можно собирать XML для каждого Edge с помощью скриптов, опрашивающих api. Еще одна отдельная тема — открытие доступа к БД vCloud Director, а также некоторые операции с БД. Если интересно узнать об этом подробнее, пишите, расскажу отдельно.
