[ English | Deutsch | Indonesia | русский | English (United Kingdom) ]

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

Эта глава предназначена для помощи в устранении неполадок и решении операционных проблем в развертывании OpenStack-Ansible.

Сеть¶

Этот раздел посвящен устранению неисправностей, связанных с обменом данными между хостами, необходимыми для правильной работы плоскости управления OpenStack.

Здесь не рассматриваются сетевые возможности, связанные с подключением инстансов.

These instructions assume an OpenStack-Ansible installation using LXC containers, VXLAN overlay, and the ML2/OVS driver.

Список сетей¶

HOST_NET (Physical Host Management and Access to Internet)
CONTAINER_NET (LXC container network used OpenStack Services)
OVERLAY_NET (оверлейная сеть VXLAN)

Полезные сетевые утилиты и команды:

# ip link show [dev INTERFACE_NAME]
# arp -n [-i INTERFACE_NAME]
# ip [-4 | -6] address show [dev INTERFACE_NAME]
# ping <TARGET_IP_ADDRESS>
# tcpdump [-n -nn] < -i INTERFACE_NAME > [host SOURCE_IP_ADDRESS]
# brctl show [BRIDGE_ID]
# iptables -nL
# arping [-c NUMBER] [-d] <TARGET_IP_ADDRESS>

Устранение проблем с трафиком между хостами в HOST_NET¶

Выполните следующие проверки:

Проверьте физическое подключение хостов к физической сети
Проверьте агрегирование интерфейсов (если применимо)
Проверьте конфигурацию VLAN и все необходимые транковые соединения с пограничными портами на физическом коммутаторе.
Проверьте конфигурацию VLAN и все необходимые транковые соединения с uplink портами на физических коммутаторах (если применимо).
Убедитесь, что узлы находятся в одной IP-подсети или между ними установлена правильная маршрутизация
Убедитесь, что к хостам не применены iptables, которые запрещают трафик

IP-адреса должны быть применены к физическому интерфейсу, бондовому интерфейсу, тегированному субинтерфейсу или, в некоторых случаях, интерфейсу моста:

# ip address show dev bond0
14: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500..UP...
link/ether a0:a0:a0:a0:a0:01 brd ff:ff:ff:ff:ff:ff
inet 10.240.0.44/22 brd 10.240.3.255 scope global bond0
   valid_lft forever preferred_lft forever
...

Устранение проблем с трафиком между хостами на CONTAINER_NET¶

Выполните следующие проверки:

Проверьте физическое подключение хостов к физической сети
Проверьте агрегирование интерфейсов (если применимо)
Проверьте конфигурацию VLAN и все необходимые транковые соединения с пограничными портами на физическом коммутаторе.
Проверьте конфигурацию VLAN и все необходимые транковые соединения с uplink портами на физических коммутаторах (если применимо).
Убедитесь, что хосты находятся в одной подсети или между ними установлена правильная маршрутизация
Убедитесь, что к хостам не применены iptables, которые запрещают трафик
Проверьте, находится ли физический интерфейс в составе моста
Убедитесь, что конец veth-пары из контейнера находится в br-mgmt

IP address should be applied to br-mgmt:

# ip address show dev br-mgmt
18: br-mgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500...UP...
link/ether a0:a0:a0:a0:a0:01 brd ff:ff:ff:ff:ff:ff
inet 172.29.236.44/22 brd 172.29.239.255 scope global br-mgmt
   valid_lft forever preferred_lft forever
...

IP address should be applied to eth1 inside the LXC container:

# ip address show dev eth1
59: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500...UP...
link/ether b1:b1:b1:b1:b1:01 brd ff:ff:ff:ff:ff:ff
inet 172.29.236.55/22 brd 172.29.239.255 scope global eth1
   valid_lft forever preferred_lft forever
   ...

br-mgmt должен содержать концы veth-пары из всех контейнеров и физический интерфейс или тегированный субинтерфейс:

# brctl show br-mgmt
bridge name bridge id          STP enabled  interfaces
br-mgmt     8000.abcdef12345   no           11111111_eth1
                                            22222222_eth1
                                            ...
                                            bond0.100
                                            99999999_eth1
                                            ...

Устранение проблем с трафиком между хостами в OVERLAY_NET¶

Выполните следующие проверки:

Проверьте физическое подключение хостов к физической сети
Проверьте агрегирование интерфейсов (если применимо)
Проверьте конфигурацию VLAN и все необходимые транковые соединения с пограничными портами на физическом коммутаторе.
Проверьте конфигурацию VLAN и все необходимые транковые соединения с uplink портами на физических коммутаторах (если применимо).
Убедитесь, что хосты находятся в одной подсети или между ними установлена правильная маршрутизация
Убедитесь, что к хостам не применены iptables, которые запрещают трафик
Проверьте, находится ли физический интерфейс в мосту
Проверьте, что конец veth-пары из контейнера находится в br-vxlan

IP-адрес должен быть присвоен br-vxlan:

# ip address show dev br-vxlan
21: br-vxlan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500...UP...
link/ether a0:a0:a0:a0:a0:02 brd ff:ff:ff:ff:ff:ff
inet 172.29.240.44/22 brd 172.29.243.255 scope global br-vxlan
   valid_lft forever preferred_lft forever
   ...

Проверка служб¶

Вы можете проверить статус службы OpenStack, обратившись к каждому узлу контроллера и выполнив команду service <SERVICE_NAME> status.

Дополнительные сведения о проверке служб OpenStack см. по следующим ссылкам:

Перезапуск служб¶

Перезапустите службы OpenStack, обратившись к каждому узлу контроллера. Некоторые службы OpenStack потребуют перезапуска с других узлов в вашем окружении.

В следующей таблице перечислены команды для перезапуска службы OpenStack.

Перезапуск служб OpenStack¶
Служба OpenStack	Команды
Служба образов	# service glance-api restart
Вычислительная служба (управляющий узел)	# service nova-api-os-compute restart # service nova-consoleauth restart # service nova-scheduler restart # service nova-conductor restart # service nova-api-metadata restart # service nova-novncproxy restart (if using novnc) # service nova-spicehtml5proxy restart (if using spice)
Вычислительная служба (вычислительный узел)	# service nova-compute restart
Сетевая служба	# service neutron-server restart # service neutron-dhcp-agent restart # service neutron-l3-agent restart # service neutron-metadata-agent restart # service neutron-openvswitch-agent restart
Сетевая служба (вычислительный узел)	# service neutron-openvswitch-agent restart
Служба блочного хранилища	# service cinder-api restart # service cinder-backup restart # service cinder-scheduler restart # service cinder-volume restart
Служба блочного хранилища	# service manila-api restart # service manila-data restart # service manila-share restart # service manila-scheduler restart
Служба объектного хранилища	# service swift-account-auditor restart # service swift-account-server restart # service swift-account-reaper restart # service swift-account-replicator restart # service swift-container-auditor restart # service swift-container-server restart # service swift-container-reconciler restart # service swift-container-replicator restart # service swift-container-sync restart # service swift-container-updater restart # service swift-object-auditor restart # service swift-object-expirer restart # service swift-object-server restart # service swift-object-reconstructor restart # service swift-object-replicator restart # service swift-object-updater restart # service swift-proxy-server restart

Troubleshooting instance connectivity issues¶

This section will focus on troubleshooting general instance (VM) connectivity communication. This does not cover any networking related to instance connectivity. This is assuming a OpenStack-Ansible install using LXC containers, VXLAN overlay and the ML2/OVS driver.

Пример потока данных

COMPUTE NODE
                                               +-------------+    +-------------+
                               +->"If VXLAN"+->+  *br vxlan  +--->+  bond#.#00  +---+
                               |               +-------------+    +-------------+   |
                +-------------+                                                      |   +-----------------+
Instance +--->  | qbr bridge  |++                                                    +-->| physical network|
                +-------------+                                                      |   +-----------------+
                               |               +-------------+    +-------------+   |
                               +->"If  VLAN"+->+   br vlan   +--->+    bond1    +---+
                                               +-------------+    +-------------+



NETWORK NODE
                                  +-------------+    +-------------+
                  +->"If VXLAN"+->+  *bond#.#00 +--->+ *br vxlan   +-->
                  |               +-------------+    +-------------+  |
+----------------+                                                     |     +-------------+
|physical network|++                                                   +--->+|  qbr bridge |+--> Neutron DHCP/Router
+----------------+                                                     |     +-------------+
                  |               +-------------+    +-------------+  |
                  +->"If  VLAN"+->+   bond1     +--->+  br vlan    +-->
                                  +-------------+    +-------------+

Предварительные вопросы по устранению неполадок, на которые необходимо ответить:¶

На каком вычислительном узле находится рассматриваемая ВМ?
Какой интерфейс используется для сетевого трафика провайдера?
Which interface is used for VXLAN overlay?
Is there connectivity issue ingress to the instance?
Is there connectivity issue egress from the instance?
Каков адрес источника трафика?
Каков адрес назначения трафика?
Is there a Neutron Router in play?
На каком сетевом узле (контейнере) размещен маршрутизатор?
What is the project network type?

Если VLAN:

Показывает ли физический интерфейс подключение и все ли VLAN правильно проброшены транком через физическую сеть?

Нет:

Проверьте кабель, соединение, конфигурацию физического порта коммутатора, конфигурацию интерфейса/агреграции и общую конфигурацию сети. См. общую документацию по устранению неполадок в сети.

Да:

Хорошо!
Продолжайте!

Важно

Не продолжайте работу, пока физическая сеть не будет правильно настроена.

Пингуется ли IP-адрес инстанса из пространства имен DHCP сети или других инстансов в той же сети?

Нет:

Проверьте журналы консоли nova, чтобы узнать, получал ли инстанс свой IP-адрес изначально.
Check security-group-rules, consider adding allow ICMP rule for testing.
Check that OVS bridges contain the proper interfaces on compute and network nodes.
Проверьте журналы агента DHCP Neutron.
Проверьте системные журналы.
Check Neutron Open vSwitch agent logs.

Да:

Хорошо! Это означает, что инстанс получил свой IP-адрес и может обращаться к ресурсам локальной сети.
Продолжайте!

Важно

Не продолжайте, пока инстанс не получит IP-адрес и не сможет обращаться к ресурсам локальной сети, например DHCP.

Does the instance’s IP address ping from the gateway device (Neutron Router namespace or another gateway device)?

Нет:

Проверьте журналы L3 агента (если применимо).
Check Neutron Open vSwitch logs.
Проверьте сопоставление физических интерфейсов.
Проверьте порты маршрутизатора Neutron (если применимо).
Check that OVS bridges contain the proper interfaces on compute and network nodes.
Check security-group-rules, consider adding allow ICMP rule for testing.

Да:

Good! The instance can ping its intended gateway. The issue may be north of the gateway or related to the provider network.
Check «gateway» or host routes on the Neutron subnet.
Check security-group-rules, consider adding ICMP rule for testing.
Check Floating IP associations (if applicable).
Проверьте информацию о внешнем шлюзе маршрутизатора Neutron (если применимо).
Проверьте вышестоящие маршруты, NAT или списки контроля доступа.

Важно

Не продолжайте, пока инстанс не установит связь со своим шлюзом.

Если VXLAN:

Нет:

Проверьте кабель, соединение, конфигурацию физического порта коммутатора, конфигурацию интерфейса/агреграции и общую конфигурацию сети. См. общую документацию по устранению неполадок в сети.

Да:

Хорошо!
Продолжайте!

Важно

Не продолжайте работу, пока физическая сеть не будет правильно настроена.

Могут ли адреса VXLAN VTEP пинговать друг друга?

Нет:

Проверьте интерфейс br-vxlan на вычислительных и сетевых узлах
Check veth pairs between containers and Linux bridges on the host.
Check that OVS bridges contain the proper interfaces on compute and network nodes.

Да:

Проверьте файл конфигурации ml2 на наличие локального IP-адреса VXLAN и других параметров конфигурации VXLAN.
Проверьте метод обучения VTEP (multicas или l2population):
- В случае multicast, убедитесь, что физические коммутаторы правильно разрешают и распределяют multicast трафик.

Важно

Не продолжайте работу до тех пор, пока точки доступа VXLAN не будут доступны друг другу.

Пингуется ли IP-адрес инстанса из пространства имен DHCP сети или других инстансов в той же сети?

Нет:

Check Nova console logs to see if the instance ever received its IP address initially.
Check security-group-rules, consider adding allow ICMP rule for testing.
Check that OVS bridges contain the proper interfaces on compute and network nodes.
Проверьте журналы агента DHCP Neutron.
Проверьте системные журналы.
Check Neutron Open vSwitch agent logs.
Check that Bridge Forwarding Database (fdb) contains the proper entries on both the compute and Neutron agent container.

Да:

Хорошо! Это означает, что инстанс получил свой IP-адрес и может обращаться к ресурсам локальной сети.

Важно

Не продолжайте, пока инстанс не получит IP-адрес и не сможет обращаться к ресурсам локальной сети.

Does the instance’s IP address ping from the gateway device (Neutron Router namespace or another gateway device)?

Нет:

Проверьте журналы L3 агента (если применимо).
Check Neutron Open vSwitch agent logs.
Проверьте сопоставление физических интерфейсов.
Проверьте порты маршрутизатора Neutron (если применимо).
Check that OVS bridges contain the proper interfaces on compute and network nodes.
Check security-group-rules, consider adding allow ICMP rule for testing.
Check that Bridge Forwarding Database (fdb) contains the proper entries on both the compute and Neutron agent container.

Да:

Отлично! Инстанс может пинговать предполагаемый шлюз.
Проверьте маршруты шлюза или хоста в подсети Neutron.
Check security-group-rules, consider adding ICMP rule for testing.
Check Neutron Floating IP associations (if applicable).
Проверьте информацию о внешнем шлюзе маршрутизатора Neutron (если применимо).
Проверьте вышестоящие маршруты, NAT или списки контроля доступа.

Диагностика проблем, связанных с службой образов¶

glance-api управляет взаимодействием с API и хранилищем образов.

Чтобы устранить проблемы или ошибки в работе службы образов, обратитесь к /var/log/glance-api.log внутри контейнера glance api.

Вы также можете выполнять следующие действия, которые могут генерировать журналы для идентификации проблем:

Загрузите образ, чтобы убедиться, что он может быть прочитан из хранилища.
Загрузите образ, чтобы проверить, регистрируется ли он и записывается ли в хранилище образов.
Выполните команду openstack image list, чтобы убедиться, что API и реестр работают.

Для примера и дополнительной информации смотрите Проверка <https://docs.openstack.org/glance/latest/install/verify.html>_. и Управление образами <https://docs.openstack.org/glance/latest/admin/manage-images.html>_

Проблемы RabbitMQ¶

Анализ очередей RabbitMQ¶

Анализ журналов служб OpenStack и журналов RabbitMQ¶

Неудачное усиление безопасности после обновления ядра хоста с версии 3.13¶

Ubuntu kernel packages newer than version 3.13 contain a change in module naming from nf_conntrack to br_netfilter. After upgrading the kernel, run the openstack-hosts-setup.yml playbook against those hosts. For more information, see OSA bug 157996.

Cached Ansible facts issues¶

В начале выполнения плейбука собирается информация о каждом хосте, например:

Дистрибутив Linux
Версия ядра
Сетевые интерфейсы

To improve performance, particularly in large deployments, you can cache host facts and information.

OpenStack-Ansible enables fact caching by default. The facts are cached in JSON files within /etc/openstack_deploy/ansible_facts.

Fact caching can be disabled by running export ANSIBLE_CACHE_PLUGIN=memory. To set this permanently, set this variable in /usr/local/bin/openstack-ansible.rc. Refer to the Ansible documentation on fact caching for more details.

Forcing regeneration of cached facts¶

Cached facts may be incorrect if the host receives a kernel upgrade or new network interfaces. Newly created bridges also disrupt cache facts.

This can lead to unexpected errors while running playbooks, and require cached facts to be regenerated.

Run the following command to remove all currently cached facts for all hosts:

# rm /etc/openstack_deploy/ansible_facts/*

New facts will be gathered and cached during the next playbook run.

To clear facts for a single host, find its file within /etc/openstack_deploy/ansible_facts/ and remove it. Each host has a JSON file that is named after its hostname. The facts for that host will be regenerated on the next playbook run.

Неудачные выполнения плейбуков Ansible во время обновления¶

Проблемы работы сетей контейнеров¶

Все контейнеры LXC на хосте имеют не менее двух виртуальных интерфейсов Ethernet:

eth0 в контейнере подключается к lxcbr0 на хосте
eth1 в контейнере подключается к br-mgmt на хосте

Примечание

Некоторые контейнеры, такие как cinder, glance, neutron_agents и swift_proxy, имеют более двух интерфейсов для поддержки своих функций.

Предсказуемое именование интерфейсов¶

На хосте все виртуальные Ethernet-устройства именуются на основе их контейнера, а также имени интерфейса внутри контейнера:

${CONTAINER_UNIQUE_ID}_${NETWORK_DEVICE_NAME}

В качестве примера можно привести сборку «все в одном» (AIO) с контейнером утилит под названием aio1_utility_container-d13b7132. Этот контейнер будет иметь два сетевых интерфейса: d13b7132_eth0 и d13b7132_eth1.

Другим вариантом было бы использование инструментов LXC для получения информации о контейнере утилит. Например:

# lxc-info -n aio1_utility_container-d13b7132

Name:           aio1_utility_container-d13b7132
State:          RUNNING
PID:            8245
IP:             10.0.3.201
IP:             172.29.237.204
CPU use:        79.18 seconds
BlkIO use:      678.26 MiB
Memory use:     613.33 MiB
KMem use:       0 bytes
Link:           d13b7132_eth0
 TX bytes:      743.48 KiB
 RX bytes:      88.78 MiB
 Total bytes:   89.51 MiB
Link:           d13b7132_eth1
 TX bytes:      412.42 KiB
 RX bytes:      17.32 MiB
 Total bytes:   17.73 MiB

Строки Link: будут показывать сетевые интерфейсы, подключенные к контейнеру утилит.

Обзор сетевого трафика контейнеров¶

Чтобы просмотреть трафик на мосту br-mgmt, используйте tcpdump, чтобы увидеть все соединения между различными контейнерами. Чтобы сузить фокус, запустите tcpdump только на нужном сетевом интерфейсе контейнеров.

Восстановление inventory из резервной копии¶

OpenStack-Ansible поддерживает архив текущего inventory. Если в системе произойдет изменение, которое нарушит inventory или вызовет другую непредвиденную проблему, inventory может быть возвращена к более ранней версии. Файл резервной копии /etc/openstack_deploy/backup_openstack_inventory.tar содержит набор inventory с временными метками, которые могут быть восстановлены при необходимости.

Пример процесса восстановления inventory.

mkdir /tmp/inventory_restore
cp /etc/openstack_deploy/backup_openstack_inventory.tar /tmp/inventory_restore/backup_openstack_inventory.tar
cd /tmp/inventory_restore
tar xf backup_openstack_inventory.tar
# Identify the inventory you wish to restore as the running inventory
cp openstack_inventory.json-YYYYMMDD_SSSSSS.json /etc/openstack_deploy/openstack_inventory.json
cd -
rm -rf /tmp/inventory_restore

По завершении этой операции inventory будет восстановлен до предыдущей версии.

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

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

Сеть¶

Список сетей¶

Устранение проблем с трафиком между хостами в HOST_NET¶

Устранение проблем с трафиком между хостами на CONTAINER_NET¶

Устранение проблем с трафиком между хостами в OVERLAY_NET¶

Проверка служб¶

Перезапуск служб¶

Troubleshooting instance connectivity issues¶

Предварительные вопросы по устранению неполадок, на которые необходимо ответить:¶

Диагностика проблем, связанных с службой образов¶

Проблемы RabbitMQ¶

Анализ очередей RabbitMQ¶

Анализ журналов служб OpenStack и журналов RabbitMQ¶

Неудачное усиление безопасности после обновления ядра хоста с версии 3.13¶

Cached Ansible facts issues¶

Forcing regeneration of cached facts¶

Неудачные выполнения плейбуков Ansible во время обновления¶

Проблемы работы сетей контейнеров¶

Предсказуемое именование интерфейсов¶

Обзор сетевого трафика контейнеров¶

Восстановление inventory из резервной копии¶

openstack-ansible 31.0.0.0b2.dev132

Page Contents