[ English | Indonesia | русский ]

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

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

Сеть¶

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

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

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

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

HOST_NET (управление физическими хостами и доступом в Интернет)
MANAGEMENT_NET (LXC container network used OpenStack Services)
OVERLAY_NET (VXLAN overlay network for OVS, Geneve overlay network for OVN)

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

# 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
...

Troubleshooting host-to-host traffic on MANAGEMENT_NET¶

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

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

IP-адрес должен быть применен к 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-адрес должен быть применен к eth1 внутри контейнера LXC:

# 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
                                            ...

You can also use ip command to display bridges:

# ip link show master br-mgmt

12: bond0.100@bond0: ... master br-mgmt state UP mode DEFAULT group default qlen 1000
....
51: 11111111_eth1_eth1@if3: ... master br-mgmt state UP mode DEFAULT group default qlen 1000
....

Устранение проблем с трафиком между хостами в 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
   ...

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

You can check the status of an OpenStack service by accessing every controller node and running the systemctl status <SERVICE_NAME>.

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

Some useful commands to manage LXC see Справочник по командной строке.

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

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

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

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

Устранение проблем с подключением инстансов¶

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

Data flow example (for OVS)

COMPUTE NODE
                                               +-------------+    +-------------+
                               +->"If VXLAN"+->+  *br vxlan  +--->+  bond0.#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    +-->
                                  +-------------+    +-------------+

Data flow example (for OVN)

   COMPUTE NODE
                                                +-------------+    +-------------+
                               +->"If Geneve"+->+  *br-vxlan  +--->+  bond0.#00  +---+
                               |                +-------------+    +-------------+   |
                +-------------+                                                      |   +-----------------+
Instance +--->  |   br-int    |++                                                    +-->| physical network|
                +-------------+                                                      |   +-----------------+
                               |              +-------------+    +-------------+     |
                               +->"If VLAN"+->+   br-vlan   +--->+    bond1    +-----+
                                              +-------------+    +-------------+

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

Which compute node is hosting the instance in question?
Какой интерфейс используется для сетевого трафика провайдера?
Which interface is used for VXLAN (Geneve) overlay?
Есть ли проблемы с подключением к инстансу?
Есть ли проблемы с подключением с инстанса?
Каков адрес источника трафика?
Каков адрес назначения трафика?
Работает ли маршрутизатор Neutron?
На каком сетевом узле (контейнере) размещен маршрутизатор?
Какой тип сети проекта?

Если VLAN:

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

Нет:

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

Да:

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

Важно

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

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

Нет:

Проверьте журналы консоли nova, чтобы узнать, получал ли инстанс свой IP-адрес изначально.
Проверьте правила группы безопасности, подумайте о добавлении правила разрешения ICMP для тестирования.
Проверьте, что мосты OVS содержат правильные интерфейсы на вычислительных и сетевых узлах.
Проверьте журналы агента DHCP Neutron.
Проверьте системные журналы.
Проверьте журналы агента Neutron Open vSwitch.

Да:

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

Важно

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

Пингуется ли IP-адрес инстанса с шлюза (пространство имен Neutron Router или другого шлюза)?

Нет:

Проверьте журналы L3 агента (если применимо).
Проверьте журналы Neutron Open vSwitch.
Проверьте сопоставление физических интерфейсов.
Проверьте порты маршрутизатора Neutron (если применимо).
Проверьте, что мосты OVS содержат правильные интерфейсы на вычислительных и сетевых узлах.
Check security-group-rules, consider adding allow ICMP rule for testing. In case of using OVN check additionally:
Check ovn-controller on all nodes.
Verify ovn-northd is running and DBs are healthy.
Ensure ovn-metadata-agent is active.
Review logs for ovn-controller, ovn-northd.

Да:

Отлично! Инстанс может пинговать предполагаемый шлюз. Проблема может быть связана со шлюзом или с сетью провайдера.
Проверьте «шлюз» или маршруты хоста в подсети Neutron.
Проверьте правила группы безопасности, рассмотрите возможность добавления правила ICMP для тестирования.
Проверьте привязки плавающего IP (если применимо).
Проверьте информацию о внешнем шлюзе маршрутизатора Neutron (если применимо).
Проверьте вышестоящие маршруты, NAT или списки контроля доступа.

Важно

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

If VXLAN (Geneve):

Нет:

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

Да:

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

Важно

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

Are VXLAN (Geneve) VTEP addresses able to ping each other?

Нет:

Check br-vxlan interface on Compute and Network nodes.
Проверьте пары veth между контейнерами и мостами Linux на хосте.
Проверьте, что мосты OVS содержат правильные интерфейсы на вычислительных и сетевых узлах.

Да:

Check ml2 config file for local VXLAN (Geneve) IP and other VXLAN (Geneve) configuration settings.
Проверьте метод обучения VTEP (multicas или l2population):
- В случае multicast, убедитесь, что физические коммутаторы правильно разрешают и распределяют multicast трафик.

Важно

Do not continue until VXLAN (Geneve) endpoints have reachability to each other.

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

Нет:

Проверьте логи консоли Nova, чтобы узнать, получал ли инстанс свой IP-адрес изначально.
Проверьте правила группы безопасности, подумайте о добавлении правила разрешения ICMP для тестирования.
Проверьте, что мосты OVS содержат правильные интерфейсы на вычислительных и сетевых узлах.
Проверьте журналы агента DHCP Neutron.
Проверьте системные журналы.
Проверьте журналы агента Neutron Open vSwitch.
Check that Bridge Forwarding Database (fdb) contains the proper entries on both the compute and Neutron agent container (ovs-appctl fdb/show br-int).

Да:

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

Важно

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

Пингуется ли IP-адрес инстанса с шлюза (пространство имен Neutron Router или другого шлюза)?

Нет:

Проверьте журналы L3 агента (если применимо).
Проверьте журналы агента Neutron Open vSwitch.
Проверьте сопоставление физических интерфейсов.
Проверьте порты маршрутизатора Neutron (если применимо).
Проверьте, что мосты OVS содержат правильные интерфейсы на вычислительных и сетевых узлах.
Проверьте правила группы безопасности, подумайте о добавлении правила разрешения ICMP для тестирования.
Check that Bridge Forwarding Database (fdb) contains the proper entries on both the compute and Neutron agent container (ovs-appctl fdb/show br-int). In case of using OVN check additionally:
Check ovn-controller on all nodes.
Verify ovn-northd is running and DBs are healthy.
Ensure ovn-metadata-agent is active.
Review logs for ovn-controller, ovn-northd.

Да:

Отлично! Инстанс может пинговать предполагаемый шлюз.
Проверьте маршруты шлюза или хоста в подсети Neutron.
Проверьте правила группы безопасности, рассмотрите возможность добавления правила ICMP для тестирования.
Проверьте привязки плавающего IP Neutron (если применимо).
Проверьте информацию о внешнем шлюзе маршрутизатора Neutron (если применимо).
Проверьте вышестоящие маршруты, NAT или списки контроля доступа.

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

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

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

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

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

For an example and more information, see Verify operation and Manage Images.

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

Пакеты ядра Ubuntu новее версии 3.13 содержат изменение в названии модуля с nf_conntrack на br_netfilter. После обновления ядра запустите плейбук openstack-hosts-setup.yml на этих хостах. Дополнительную информацию см. в статье Ошибка OSA 157996.

Проблемы с кэшированными фактами Ansible¶

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

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

Для повышения производительности, особенно в больших развертываниях, можно кэшировать факты и информацию о хосте.

OpenStack-Ansible включает кэширование фактов по умолчанию. Факты кэшируются в JSON-файлах в /etc/openstack_deploy/ansible_facts.

Кэширование фактов можно отключить, выполнив команду export ANSIBLE_CACHE_PLUGIN=memory. Чтобы установить эту переменную на постоянной основе, задайте ее в файле /usr/local/bin/openstack-ansible.rc. Для получения более подробной информации обратитесь к документации Ansible по fact caching.

Принудительное пересоздание кэшированных фактов¶

Кэшированные факты могут быть некорректными, если хост получает обновление ядра или новые сетевые интерфейсы. Новые мосты также нарушают кэшированные факты.

Это может привести к неожиданным ошибкам при запуске плейбуков и потребовать пересоздания кэшированных фактов.

Выполните следующую команду, чтобы удалить все текущие кэшированные факты для всех хостов:

# rm /etc/openstack_deploy/ansible_facts/*

Новые факты будут собраны и занесены в кэш при следующем запуске плейбука.

Чтобы очистить факты для отдельного хоста, найдите его файл в файле /etc/openstack_deploy/ansible_facts/ и удалите его. Каждый хост имеет JSON-файл, названный по имени хоста. Факты для этого хоста будут восстановлены при следующем запуске плейбука.

Неудачные выполнения плейбуков 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¶

Troubleshooting host-to-host traffic on MANAGEMENT_NET¶

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

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

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

Устранение проблем с подключением инстансов¶

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

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

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

Проблемы с кэшированными фактами Ansible¶

Принудительное пересоздание кэшированных фактов¶

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

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

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

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

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

openstack-ansible 31.1.0.dev269

Page Contents