Автор: Дамиан Игби
Недавно я предварительно ознакомил вас со своим докладом на тему пространств имен в Neutron, подготовленным для саммита OpenStack в Гонконге. Один из авторов комментариев увидел видео с моим выступлением и попросил нас разместить здесь презентацию. В данном посте я покажу вам, как:
1. Правильно определить пространство имен.
2. Осуществить общую диагностику в установленном пространстве имен.
Кроме того, в конце поста представлена презентация с моим выступлением.
Итак, перейдем прямо к делу. Если вы запускаете сразу два сервиса L3 + DHCP на одном узле, чтобы исключить конфликт маршрутов, нужно активировать пространства имен:
Use_namespaces=True
Для отключения пространств имен убедитесь в том, что в файле neutron.conf, используемом neutron-сервером, задана следующая настройка:
allow_overlapping_ips=False
А также в том, что файлы dhcp_agent.ini и l3_agent.ini содержат:
use_namespaces=False
Как реализованы пространства имен в Neutron и как их распознать? Для начала необходимо констатировать два весьма важных факта:
1.У каждого l2-agent/частной сети есть ассоциированное пространство имен DHCP.
2.У каждого l3-agent/маршрутизатора есть ассоциированное пространство имен маршрутизатора.
OK, но как же именуются пространства имен? В начале имени сетевого пространства имен идет dhcp- с последующим ID сети. По аналогии в начале имени пространства имен маршрутизатора идет qrouter- с последующим ID маршрутизатора. Например:
stack@vmnet-mn:~$ sudo ip netns list
qdhcp-eb2367bd-6e43-4de7-a0ab-d58ebf6e7dc0
qrouter-4adef4a5-1122-49b8-9da2-3cbf803c44dd
Представленный выше список пространств имен характерен для простой сети, состоящей из одной частной сети и одного маршрутизатора. Для большего понимания на Рис. 1 приведена иллюстрация подобной простой сети.
Рисунок 1. Иллюстрация простой сети с маршрутизатором и пространствами имен DHCP
Рис. 1 показывает, как построена арендованная сеть, состоящая из маршрутизатора и пространств имен DHCP. В целях иллюстрации в сеть включена одна виртуальная машина (VM1). По мере построения сетей для каждого арендатора будут создаваться аналогичные сетевые топологии. Из рис.1 можно сделать следующие наблюдения:
•Сеть дата-центра является внешней сетью, через которую пакеты поступают в Интернет.
•Маршрутизатор с IP-адресом 10.0.0.1 соединяет арендованную сеть с сетью дата-центра. У него есть ассоциированное пространство имен маршрутизатора, которое позволяет изолировать таблицы маршрутизации одного арендатора от любого другого арендатора при развертывании OpenStack.
•Мост обозначает арендованную сеть с IP-адресом 10.0.0.0/24. К DHCP-серверу (в данном случае процессу dnsmasq) присоединена частная сеть, и у него есть ассоциированный IP-адрес (10 .0.0.2) точно так же, как физический сервер подключается к сети. Обратите внимание на то, что маршрутизатору обычно назначается первый IP-адрес, DHCP-серверу – следующий IP-адрес, а виртуальным машинам – оставшиеся в пуле IP-адреса. Аналогично у DHCP-сервера есть ассоциированное пространство имен DHCP, которое позволяет распределять IP-адреса и осуществлять передачу всего трафика внутри данной арендованной сети.
Поиск и исправление ошибок в пространстве имен Neutron
Без надлежащего понимания сетевых пространств имен как фундаментального понятия в построении сети OpenStack, поиск и корректирование неисправностей в сети сродни поискам иголки в стоге сена. Представьте небольшую реализацию OpenStack примерно с 1000 арендаторов, при этом каждый арендатор сети Neutron включает в себя, как минимум, один маршрутизатор и одну частную сеть. Общее число создаваемых пространств имен будет равно, как минимум, 2000, поскольку каждый арендованный маршрутизатор является пространством имен, а у каждой сети будет ассоциированное пространство имен DHCP (т.е. два пространства имен на каждого арендатора, как показано на рис. 1). При таком сценарии, допустим, у какого-либо арендатора возникли проблемы с распределением DHCP, позволяющим инстансу показывать присвоенные IP-адреса, просмотр которых осуществляется через панель управления OpenStack Dashboard, но вы не можете подключиться к инстансу по протоколу SSH и при просмотре через систему удаленного доступа VNC видите, что у сетевого интерфейса нет IP-адреса.
Для решения данной проблемы нужно проверить различные компоненты топологии арендованной сети, представленной на рис. 1, главным образом, агент DHCP. Первым логичным шагом является определение пространства имен арендатора. При этом мы увидим, насколько этот процесс отличается от исправления неисправностей при развертывании традиционной физической сети. Здесь, не понимая, как работает пространство имен в Neutron, администратор окончательно запутается и не сможет продолжить поиск неисправностей при помощи логических процедур.
Итак, шаги по поиску и исправлению ошибок следующие:
1.Правильно определить пространство имен.
2.Осуществить общую диагностику в установленном пространстве имен.
Создадим две арендованных сети для иллюстрации выявления и устранения ошибок в пространствах имен.
Рисунок 2. Сеть для арендатора A
Рисунок 3. Сеть для арендатора B
Шаг 1: Определение пространства имен
На приведенных выше схемах сеть для арендатора A имеет две частных сети и один маршрутизатор; сеть для арендатора B – также две сети и один маршрутизатор. Рассмотрим эти сети. Обратите внимание на то, что в многомодовой конфигурации, включающей узел контроллера, сетевой узел и вычислительные узлы, команды пространства имен будут выполняться из сетевого узла.
stack@vmnet-mn:~$ sudo ip netns list
[sudo] password for stack:
qdhcp-eb2367bd-6e43-4de7-a0ab-d58ebf6e7dc0
qdhcp-9f7ec6fd-ec9a-4b1b-b854-a9832f190922
qrouter-4587f8d0-08a7-434a-aaeb-74e68a50c48d
qdhcp-f5a69443-bf3f-4f9a-b3e2-5625e70514b4
qrouter-4adef4a5-1122-49b8-9da2-3cbf803c44dd
qdhcp-e0fe9037-790a-4c6b-9bf4-4b06f0cfcf5c
Мы видим список из шести пространств имен двух арендованных сетей (три пространства имен на каждого арендатора).
OK, но как узнать, какое пространство имен принадлежит какому арендатору, ведь имена арендаторов в пространствах имен не обозначены? Это можно сделать двумя способами.
Во-первых, стоит отметить, что, как правило, только у администратора облака есть доступ к сетевому узлу, поэтому только администратор может запускать команды пространства имен на сетевом узле. Одним из способов определения пространства имен администратором облака является установление источника файла учетных данных пользователя, относящегося к данному арендатору. После этого все команды с neutron будут выполняться под этим пользователем и будут показаны только компоненты арендованной сети, к которой этот пользователь принадлежит. Проиллюстрируем это следующим образом.
1.Определите источник файла с учетными данными, владельцем которого является пользователь арендатора A.
2.Выполните следующие команды:
stack@vmnet-mn:~$ neutron router-list
+--------------------------------------+-----------------+--------------------------------------------------------+
| id | name | external_gateway_info |
+--------------------------------------+-----------------+--------------------------------------------------------+
| 4adef4a5-1122-49b8-9da2-3cbf803c44dd | router_proj_one | {«network_id»: «ea00b8c3-7063-4780-ad73-ef0b47518f10»} |
+--------------------------------------+-----------------+--------------------------------------------------------+
Из списка видно, что у арендатора A имеется один маршрутизатор с идентификатором 4adef4a5-1122-49b8-9da2-3cbf803c44dd
Найдя данный ID в команде ip netns выше, мы можем легко определить, что пространство имен маршрутизатора qrouter-4adef4a5-1122-49b8-9da2-3cbf803c44dd принадлежит арендатору A.
Для пространства имен DHCP:
stack@vmnet-mn:~$ neutron net-list
+--------------------------------------+--------------+-----------------------------------------------------+
| id | name | subnets |
+--------------------------------------+--------------+-----------------------------------------------------+
| e0fe9037-790a-4c6b-9bf4-4b06f0cfcf5c | net_proj_one | f02b6df4-11af-411d-b41e-e4ce66d5510d 10.10.1.0/24 |
| ea00b8c3-7063-4780-ad73-ef0b47518f10 | ext_net | 4f7c6c9e-28d8-43b3-b7d4-276920216b31 |
| f5a69443-bf3f-4f9a-b3e2-5625e70514b4 | net2 | f6cd4df6-b37f-4615-94f6-8abcab38ef99 192.168.0.0/24 |
+--------------------------------------+--------------+-----------------------------------------------------+
Кроме того, по данному списку можно определить две частные сети с идентификаторами 0fe9037-790a-4c6b-9bf4-4b06f0cfcf5c и f5a69443-bf3f-4f9a-b3e2-5625e70514b4.
Проверив команду из списка ip netns выше, мы также можем установить следующие пространства имен DHCP: qdhcp-e0fe9037-790a-4c6b-9bf4-4b06f0cfcf5c и qdhcp-f5a69443-bf3f-4f9a-b3e2-5625e70514b4
Описанные выше процедуры являются эффективными и наиболее простыми, если администратор облака знает имя пользователя/пароль арендатора, но это не всегда так. Поэтому другой способ, при помощи которого администратор облака может определить пространство имен арендатора, – спросить у пользователя ID сети или имя сети. Пользователь арендованной сети может легко узнать эту информацию в панели управления OpenStack Dashboard проекта Horizon. Зная либо имя, либо ID, администратор облака может осуществить поиск и устранение неисправностей следующим образом:
1.Отследите учетные данные администратора. Зная их, администратор облака будет иметь доступ ко всем пространствам имен арендованной сети.
2.Составьте список пространств имен и выберите пространство имен арендатора.
stack@vmnet-mn:~$ ip netns list | grep 9f7ec6fd-ec9a-4b1b-b854-a9832f190922
qdhcp-9f7ec6fd-ec9a-4b1b-b854-a9832f190922
Шаг 2: Поиск и исправление ошибок в пространстве имен
Теперь, когда мы выяснили пространство имен арендатора, мы можем приступить к устранению ошибок в нем.
Для начала проверим IP-адрес.
stack@vmnet-mn:~$ sudo ip netns exec qdhcp-9f7ec6fd-ec9a-4b1b-b854-a9832f190922 ifconfig
[sudo] password for stack:
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:16 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1344 (1.3 KB) TX bytes:1344 (1.3 KB)
tap43cb2c73-40 Link encap:Ethernet HWaddr fa:16:3e:e6:1b:24
inet addr:10.1.0.3 Bcast:10.1.0.255 Mask:255.255.255.0
inet6 addr: fe80::f816:3eff:fee6:1b24/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:965 errors:0 dropped:0 overruns:0 frame:0
TX packets:561 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:178396 (178.3 KB) TX bytes:93900 (93.9 KB)
Затем выполним ping интерфейса:
stack@vmnet-mn:~$ sudo ip netns exec qdhcp-9f7ec6fd-ec9a-4b1b-b854-a9832f190922 ping –c 3 10.1.0.3
PING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.
64 bytes from 10.1.0.3: icmp_req=1 ttl=64 time=0.081 ms
64 bytes from 10.1.0.3: icmp_req=2 ttl=64 time=0.035 ms
64 bytes from 10.1.0.3: icmp_req=3 ttl=64 time=0.055 ms
Описанные выше шаги помогли нам установить соответствующее пространство имен и проверить корректность доступного (т.е. запущенного и работающего) IP-адреса. Дальнейшие шаги по выявлению и устранению неисправностей могут включать следующее:
•Проверьте, работает ли процесс dnsmasq, подключенный к подсети, для DHCP:
stack@vmnet-mn:~$ ps –aux | grep dhcp
По результатам приведенной выше команды определите, что процесс в выбранной сети (например, 10.0.0.0) работает, иначе процесс dnsmasq, подключенный к этой сети, может быть не запущен.
•Убедитесь, что брандмауэр не блокирует передачу данных в/из подсети.
Выводы
Перед тем, как подвести итоги, обратим внимание на следующее:
•При создании маршрутизатора или сети не происходит немедленного создания пространств имен. Для сети пространства имен DHCP создаются только тогда, когда подключается VM, а для маршрутизатора пространство имен создается при установке шлюза. Это означает, что до создания пространств имен должна иметь место какая-либо активность.
•При удалении маршрутизатора или сети ассоциированные с ними пространства имен не удаляются. Их нужно удалить вручную.
Точно так же, как сетевые пространства имен крайне важны для построения сети OpenStack, важно и их понимание администратором облака OpenStack. Мы рассмотрели реализацию сетевых пространств имен в OpenStack с учетом того, какими данными нужно обладать администратору облака OpenStack при решении проблем с арендованной сетью OpenStack.
Теперь, при желании, вы можете ознакомиться с презентацией на данную тему.
Neutron Network Namespaces and IPtables--A Technical Deep Dive from Mirantis
Оригинал статьи на английском языке
Автор: Mirantis_OpenStack
