Устранение неполадок сети

Отсоединение плавающих IP вручную.

Иногда экземпляр завершается, но плавающий IP не был правильно отсоединен от этого экземпляра. Поскольку база данных находится в несогласованном состоянии, обычные инструменты для отсоединения IP не работают. Чтобы это исправить, необходимо вручную обновить базу данных.

Сначала найдите UUID экземпляра выполнив запрос:
mysql> select uuid from instances where hostname = 'hostname';


Далее, найдите запись фиксированного IP для этого UUID:
mysql> select * from fixed_ips where instance_uuid = '<uuid>';


Теперь вы можете получить соответствующую запись плавающего IP:
mysql> select * from floating_ips where fixed_ip_id = '<fixed_ip_id>';


И, наконец, вы можете отсоединить плавающий IP:
mysql> update floating_ips set fixed_ip_id = NULL, host = NULL where fixed_ip_id = '<fixed_ip_id>';


При необходимости также можно освободить IP из пула пользователя:
mysql> update floating_ips set project_id = NULL where fixed_ip_id = '<fixed_ip_id>';


Отладка проблем DHCP

Одна из распространенных проблем сети заключается в том, что экземпляр успешно стартует, но не доступен, потому что не удается получить IP-адрес от dnsmasq, который является сервером DHCP, запускаемым службой nova-network.

Самый простой способ выяснить, что эта проблема связана с вашим экземпляром, заключается в просмотре вывода консоли вашего экземпляра. Если отказал DHCP, вы можете получить журнал консоли, выполнив:
$ nova console-log <instance name or uuid>

Если ваш экземпляр не получил IP через DHCP, в консоли должны появиться какие-то сообщения. Например, для образа Cirros вы увидите вывод, выглядящий следующим образом:
udhcpc (v1.17.2) started
Sending discover...
Sending discover...
Sending discover...
No lease, forking to background
starting DHCP forEthernet interface eth0 [ [1;32mOK[0;39m ]
cloud-setup: checking http://169.254.169.254/2009-04-04/meta-data/instance-id
wget: can't connect to remote host (169.254.169.254): Network is unreachable


После того, как вы установите, что экземпляр загрузился правильно, задача состоит в том, чтобы выяснить, где происходит отказ.

Проблема DHCP может быть вызвана некорректно работающим процессом dnsmasq. Во-первых, выполните отладку, проверив журналы и перезагрузите процессы dnsmasq только для этого проекта (владельца, tenant). В режиме VLAN существует по процессу dnsmasq для каждого владельца. После перезагрузки целевых процессов dnsmasq, самый простой способ исключить причины dnsmasq, состоит в том, чтобы уничтожить все dnsmasq процессы на машине, и перезапустить nova-network. В крайнем случае, выполните это с правами root:
# killall dnsmasq # restart nova-network


Существует openstack-nova-network в RHEL/CentOS/Fedora, но novanetwork на Ubuntu/Debian.

Спустя несколько минут после того, как nova-network будет запущена повторно, вы должны увидеть новое выполнение процессов dnsmasq:
# ps aux | grep dnsmasq
nobody 3735 0.0 0.0 27540 1044 ? S 15:40 0:00 /usr/sbin/dnsmasq --strict-order
--bind-interfaces --conf-file=
     --domain=novalocal --pid-file=/var/lib/nova/networks/nova-br100.pid --listen-address=192.168.100.1
   --except-interface=lo --dhcp-range=set:'novanetwork',192.168.100.2,static,120s --dhcp-lease-max=256
       --dhcp-hostsfile=/var/lib/nova/networks/nova-br100.conf --dhcpscript=/usr/bin/nova-dhcpbridge --leasefile-ro
root 3736 0.0 0.0 27512 444 ? S 15:40 0:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces --conf-file=
     --domain=novalocal --pid-file=/var/lib/nova/networks/nova-br100.pid --listen-address=192.168.100.1
   --except-interface=lo --dhcp-range=set:'novanetwork',192.168.100.2,static,120s --dhcp-lease-max=256
       --dhcp-hostsfile=/var/lib/nova/networks/nova-br100.conf --dhcpscript=/usr/bin/nova-dhcpbridge --leasefile-ro


Если ваши экземпляры все еще не в состоянии получить IP-адреса, следующая задача заключается в проверке того, видны ли запросы DHCP dnsmasq из экземпляра. На машине, на которой выполняется процесс dnsmasq и которая является хоcтом Compute при работе в режиме мульти-хостов, найдите /var/log/syslog, чтобы увидеть вывод dnsmasq. Если dnsmasq видит запросы правильно и раздает IP, результат выглядит так:
Feb 27 22:01:36 mynode dnsmasq-dhcp[2438]: DHCPDISCOVER(br100) fa:16:3e:56:0b:6f
Feb 27 22:01:36 mynode dnsmasq-dhcp[2438]: DHCPOFFER(br100) 192.168.100.3 fa:16:3e:56:0b:6f
Feb 27 22:01:36 mynode dnsmasq-dhcp[2438]: DHCPREQUEST(br100) 192.168.100.3 fa:16:3e:56:0b:6f
Feb 27 22:01:36 mynode dnsmasq-dhcp[2438]: DHCPACK(br100) 192.168.100.3 fa:16:3e:56:0b:6f test


Если вы не видите DHCPDISCOVER, существует проблема с получением пакетов от экземпляра к машине с запущенным dnsmasq. Если вы видите все приводимые выше выводы, а экземплярам до сих пор не удалось получить IP-адреса, то пакеты доходят от экземпляра к хосту с запущенным dnsmasq, но они не в состоянии выполнить обратный путь.

Если вы видите любое другое сообщения, например:
Feb 27 22:01:36 mynode dnsmasq-dhcp[25435]: DHCPDISCOVER(br100) fa:16:3e:78:44:84 no address available


Это может быть проблема, вызванная Dnsmasq и / или nova-network. (Для предыдущего примера, если бы случилась проблема, что dnsmasq не имеет больше IP-адресов для выдачи, поскольку больше нет фиксированных IP-адресов в базе данных в вычислительной среде OpenStack).

Если есть подозрительные сообщения журнала dnsmasq, взгляните на аргументы командной строки для процессов dnsmasq чтобы убедиться, что они выглядят правильно.
$ ps aux | grep dnsmasq


Вывод результатов выглядит примерно следующим образом:
108 1695 0.0 0.0 25972 1000 ? S Feb26 0:00 /usr/sbin/dnsmasq -u libvirt-dnsmasq --strict-order --bind-interfaces    --pid-file=/var/run/libvirt/network/default.pid --conf-file= --exceptinterface lo --listen-address 192.168.122.1  --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override nobody 2438 0.0 0.0 27540 1096 ? S Feb26 0:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces --conf-file=  --domain=novalocal --pid-file=/var/lib/nova/networks/nova-br100.pid --listenaddress=192.168.100.1 --except-interface=lo --dhcp-range=set:'novanetwork',192.168.100.2,static,120s --dhcp-lease-max=256 --dhcp-hostsfile=/var/lib/nova/networks/nova-br100.conf --dhcp-script=/usr/bin/ nova-dhcpbridge --leasefile-ro root 2439 0.0 0.0 27512 472 ? S Feb26 0:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces --conf-file=  --domain=novalocal --pid-file=/var/lib/nova/networks/nova-br100.pid --listenaddress=192.168.100.1 --except-interface=lo --dhcp-range=set:'novanetwork',192.168.100.2,static,120s --dhcp-lease-max=256 --dhcp-hostsfile=/var/lib/nova/networks/nova-br100.conf --dhcp-script=/usr/bin/ nova-dhcpbridge --leasefile-ro


Если проблема не кажется связанной с самим dnsmasq, в данном месте используйте tcpdump в интерфейсах для определения места, в котором теряются пакеты.

DHCP трафик использует UDP. Клиент отправляет пакеты из порта 68 в порт 67 на сервере. Попробуйте загрузить новый экземпляр, а затем систематически прослушивать сетевой адаптер, пока вы не идентифицируете тот, который не видит трафик. Чтобы использовать tcpdump для прослушивания портов 67 и 68 на br100, вы могли бы выполнить:
# tcpdump -i br100 -n port 67 or port 68


Вы должны выполнять проверку готовности к работе интерфейсов, например, с помощью команд, подобных "ip a" и "brctl show" для того, чтобы убедиться, что интерфейсы действительно работают и настроены таким образом, что вы полагаете, что они существуют.

Проблемы отладки DNS

Если вы в состоянии пробросить ssh к экземпляру, но получение приглашения занимает очень много времени (порядка минуты), то, возможно, у вас проблемы с DNS. Причина проблемы с DNS может быть вызвана тем, что сервер ssh не осуществляет обратный DNS поиск IP-адреса, с которого вы подключаетесь. Если поиск DNS не работает на вашем экземпляре, то вы должны ожидать выполнение тайм-аута обратного просмотра DNS для выполнения процесса авторизации ssh.

При отладке проблем DNS, начните с удостоверения того, что хост, на котором работает процесс dnsmasq для этого экземпляра способен правильно разрешать адреса. Если хост не может разрешать адреса, тогда и экземпляры не смогут выполнять это.

Быстрый способ проверить, работает ли DNS заключается в разрешении имени хоста внутри вашего экземпляра с использованием команды host. Если DNS работает, вы должны увидеть:
$ host openstack.org
openstack.org has address 174.143.194.225
openstack.org mail is handled by 10 mx1.emailsrvr.com.
openstack.org mail is handled by 20 mx2.emailsrvr.com.


Если вы работаете с образом Cirros, он не имеет установленной программы "host", в этом случае вы можете использовать ping, чтобы попытаться получить доступ к машине по имени хоста и чтобы убедиться в способности разрешать имена. Если DNS работает, первая строка ping будет:
$ ping openstack.org
PING openstack.org (174.143.194.225): 56 data bytes


Если экземпляр не может разрешить имя хоста, у вас имеется проблема с DNS. Например:
$ ping openstack.org
ping: bad address 'openstack.org'


В облаке OpenStack, процесс dnsmasq выступает в качестве DNS- сервера для экземпляров в дополнение к работе в качестве DHCP-сервера. Некорректно работающий процесс dnsmasq может быть источником проблем, связанных с DNS внутри экземпляра. Как уже упоминалось в предыдущем разделе, самый простой способ исключения плохого поведения процесса dnsmasq, заключается в уничтожении (kill) всех dnsmasq процессов на машине, и перезапуске nova-network. Однако следует помнить, что эта команда влияет на все работающие на данном узле экземпляры, в том числе на процессы владельцев (tenant), которые не испытывают данной проблемы. В крайнем случае, выполните с правами root:
# killall dnsmasq # restart nova-network


После того, как dnsmasq снова стартует, убедитесь что DNS работает.

Если перезапуск процесса dnsmasq не решил проблему, вам, возможно, потребуется использовать tcpdump для просмотра пакетов, чтобы проследить, где они теряются. Сервер DNS прослушивает UDP порт 53. Вы должны увидеть запрос DNS в мосте (например, br100) вашего вычислительного узла. Если вы запустили прослушивание tcpdump на вычислительном узле:
# tcpdump -i br100 -n -v udp port 53 tcpdump: listening on br100, link-type EN10MB (Ethernet), capture size 65535 bytes


Тогда, если вы прокинете ssh в экземпляр и попытаетесь выполнить ping openstack.org, вы должны увидеть нечто вроде:
16:36:18.807518 IP (tos 0x0, ttl 64, id 56057, offset 0, flags [DF], proto UDP (17), length 59)
192.168.100.4.54244 > 192.168.100.1.53: 2+ A? openstack.org. (31)
16:36:18.808285 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 75)
192.168.100.1.53 > 192.168.100.4.54244: 2 1/0/0 openstack.org. A 174.143.194.225 (47)


Глава 11	Оглавление	Глава 13
Перевод: Copyright © 2014  . All rights reserved. Ссылки обязательны (Refs and links are obligatory).		http://www.mdl.ru