С 1991 года на компьютерном рынке России
e-mail

т.: 676 0965, 676 0396
Москва, Сосинская ул. 43,
м. Волгоградский проспект
Руководство по эксплуатации OpenStack

ГЛАВА 12


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

Пользуйтесь переводом существенно переработанной и дополенной 2й редакции (12-дек-2014),
находящейся теперь и в режиме постоянно обновляемой документации
(последняя пока доступна только на англ.яз.).

К сожалению, поиск и устранение неисправностей сети может быть очень сложной и запутанной процедурой. Вопросы с сетью могут вызывать проблемы в различных местах облака. Использование процедуры логического устранения неполадок может уменьшить беспорядок и более быстро изолировать именно то место, где есть проблема сети. Цель данной главы- предоставить вам информацию, которая необходима для ваших решений.

Использование "ip a" для проверки состояний интерфейса

Используйте следующую команду на вычислительных узлах и узлах, с работающими nova-network, чтобы увидеть информацию об интерфейсах, включая информацию об IP-адресах, VLAN и работают ли ваши интерфейсы.
# ip a

Если вы испытываете любой вид проблем с сетью, одна хорошая начальная здравая проверка заключается в том, чтобы убедиться, что ваши интерфейсы работают. Например:
$ ip a | grep state
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br100 state UP qlen 1000
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
6: br100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP

Вы можете спокойно игнорировать состояние virbr0, который является мостом (bridge) по умолчанию созданным libvirt и не используемым OpenStack.

Сетевой трафик в облаке

Если вы вошли в систему экземпляра и выполняете ping на внешний хост, например google.com, пакет для ping выполняет следующий маршрут:

  1. Экземпляр генерирует пакет и помещает его в виртуальную сетевую плату (virtual NIC) внутри экземпляра, например, такую, как, eth0.
  2. Пакет передается виртуальной сетевой плате вычислительного хоста, например, vnet1. Вы можете узнать какой именно сетевой адаптер (vnet NIC) используется, просмотрев файл /etc/libvirt/qemu/instance-xxxxxxxx.xml.
  3. Из vnet NIC пакет передается в мост вычислительного узла, например br100. Если у вас выполняется FlatDHCPManager, на вычислительном узле присутствует один мост. Если у вас выполняется VlanManager, по одному мосту существует для каждой VLAN. Чтобы посмотреть какой мост будет использовать пакет, выполните команду:
    $ brctl show
    Найдите vnet NIC. Вы также можете воспользоваться nova.conf и найти параметр flat_interface_bridge.
  4. Пакетые перемещается в главную сетевую плату вычислительного узла. Вы также можете увидеть эту сетевую плату на выходе brctl, или вы можете найти ее с помощью ссылки на параметр flat_interface в nova.conf.
  5. После того, как пакет попадает в этот сетевой адаптер, он передается в шлюз по умолчанию для данного вычислительного узла. Наиболее вероятно, что пакет теперь находится вне вашего контроля в данной точке. Диаграмма изображает внешний шлюз. Тем не менее, в конфигурации по умолчанию с мульти- хостами, хост вычислительного узла является шлюзом.

Чтобы увидеть путь ответа ping-а, измените направление.

Из рассмотренного пути вы можете увидеть, что один пакет проходит через четыре различных сетевых адаптера. Если возникает проблема с любой из этих сетевых плат, возникает проблема с сетью.

Поиск неисправностей в пути

Используйте команду ping, чтобы быстро найти где существует отказ в сетевом пути. В экземпляре вначале убедитесь, можете ли вы проверить связь (ping) с внешним хостом, например, google.com. Если да, то вообще не должно быть проблемы с сетью.

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

Если ping на IP адрес вычислительного узла не выполняется, проблема между экземпляром и вычислительным узлом. Она может заключаться и в мосте, соединяющем основную сетевую плату вычислительного узла и vnet NIC экземпляра.

И последний тест заключается в запуске второго экземпляра и проверке того, что оба экземпляра могут осуществлять ping друг к другу. Если да, то проблема может быть связана с брандмауэром (firewall) на данном вычислительном узле.

tcpdump

Один замечательный, хотя и чересчур глубокий, способ устранения неполадок сети заключается в использовании tcpdump. Рекомендуется использовать tcpdump в различных точках сетевого пути, чтобы скоррелировать где может быть проблема. Если вы предпочитаете работать с графическим интерфейсом (GUI), либо напрямую или с использованием перехвата tcpdump попробуйте в обоих случаях Wireshark (http://www.wireshark.org/)

Например, выполните следующую команду:
tcpdump -i any -n -v 'icmp[icmptype] = icmp-echoreply or icmp[icmptype] = icmp-echo'

Выполните ее из командной строки в следующих областях:

  1. На внешнем сервере за пределами облака.
  2. На вычислительном узле.
  3. В экземпляре, запущенном на вычислительном узле.

В нашем примере эти местоположения имеют следующие IP-адреса:
        Экземпляр
        10.0.2.24
        203.0.113.30
        Вычислительный узел
        10.0.0.42
        203.0.113.34
        Внешний сервер
        1.2.3.4

Затем откройте новую оболочку на экземпляре и потом выполните ping к внешнему хосту, на котором работает tcpdump. Если сетевой путь к внешнему серверу и обратно полностью работоспособен, вы видите нечто вроде следующего:
На внешнем сервере:
12:51:42.020227 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto ICMP (1), length 84)  203.0.113.30 > 1.2.3.4: ICMP echo request, id 24895, seq 1, length 64 12:51:42.020255 IP (tos 0x0, ttl 64, id 8137, offset 0, flags [none], proto ICMP (1), length 84)  1.2.3.4 > 203.0.113.30: ICMP echo reply, id 24895, seq 1, length 64

В экземпляре:
12:51:42.020974 IP (tos 0x0, ttl 61, id 8137, offset 0, flags [none], proto ICMP (1), length 84)
1.2.3.4 > 10.0.2.24: ICMP echo reply, id 24895, seq 1, length 64

Здесь внешний сервер получил ping-запрос и послал ping-ответ. На вычислительном узле вы можете увидеть, что и сам ping и ping ответ успешно выполнены.

Вы также должны увидеть дублированные пакеты на вычислительном узле, как показано выше, потому что tcpdump захватывает пакет как в мосте, так и на исходящем интерфейсе.

iptables

Nova автоматически управляет iptables, в том числе пересылкой пакетов к экземпляру и от него на вычислительном узле, переадресацию (forwarding) трафика плавающих IP и управление правилами безопасности группы.

Выполните следующую команду, чтобы посмотреть текущую конфигурацию iptables:
# iptables-save

СоветЕсли вы измените конфигурацию, она вернется в следующий раз, когда вы перезагрузите nova-network. Вы должны использовать OpenStack для управления iptables.

Настройка сети в базе данных

База данных nova содержит несколько таблиц с сетевой информацией:

  • fixed_ips: содержит все возможные IP-адреса для подсети (подсетей) добавленных в nova. Эта таблица связана с таблицей экземпляров посредством столбца (Прим. пер.: более правильно сточки зрения баз данных: атрибута, поля) fixed_ips.instance_uuid.
  • floating_ips: содержит все плавающие IP-адрес, которые был добавлены в nova. Эта таблица связана с таблицей fixed_ips посредством столбца(Прим. пер.: более правильно с точки зрения баз данных: атрибута, поля) floating_ips.fixed_ip_id.
  • экземпляры: не совсем характерна для сети, но она содержит информацию об экземпляре, который использует fixed_ip и не обязательные floating_ip.

    Отсоединение плавающих 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

    TipСуществует 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