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

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

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

Сеть¶

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

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

Эти инструкции предполагают установку OpenStack-Ansible с использованием контейнеров LXC, VXLAN и драйвера ML2/OVS.

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

HOST_NET (управление физическими хостами и доступом в Интернет)
CONTAINER_NET (сеть контейнеров LXC, используемая службами OpenStack)
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-адрес должен быть применен к 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
                                            ...

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

Служба идентификации (keystone)
Сервис образов (glance)
Вычислительная служба (nova)
Сетевая служба (neutron)
Служба блочного хранилища <https://docs.openstack.org/cinder/latest/install/cinder-verify.html>`_
Служба объектного хранилища (swift) <https://docs.openstack.org/swift/latest/install/verify.html>`_

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

Перезапустите службы 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
Shared Filesystems service	# 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

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

В этом разделе рассматривается устранение неисправностей связи между инстансами (ВМ) общего характера. Здесь не рассматриваются сетевые проблемы, связанные с подключением инстансов. Предполагается, что установка OpenStack-Ansible выполняется с использованием контейнеров LXC, VXLAN и драйвера ML2/OVS.

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

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    +-->
                                  +-------------+    +-------------+

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

На каком вычислительном узле находится рассматриваемая ВМ?
Какой интерфейс используется для сетевого трафика провайдера?
Какой интерфейс используется для VXLAN?
Есть ли проблемы с подключением к инстансу?
Есть ли проблемы с подключением с инстанса?
Каков адрес источника трафика?
Каков адрес назначения трафика?
Работает ли маршрутизатор Neutron?
На каком сетевом узле (контейнере) размещен маршрутизатор?
Какой тип сети проекта?

Если VLAN:

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

Нет:

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

Да:

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

Важно

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

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

Нет:

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

Да:

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

Важно

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

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

Нет:

Проверьте журналы L3 агента (если применимо).
Проверьте журналы Neutron Open vSwitch.
Проверьте сопоставление физических интерфейсов.
Проверьте порты маршрутизатора Neutron (если применимо).
Проверьте, что мосты OVS содержат правильные интерфейсы на вычислительных и сетевых узлах.
Проверьте ``security-group-rules`, подумайте о добавлении правила разрешения ICMP для тестирования.

Да:

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

Важно

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

Если VXLAN:

Нет:

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

Да:

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

Важно

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

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

Нет:

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

Да:

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

Важно

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

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

Нет:

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

Да:

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

Важно

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

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

Нет:

Проверьте журналы L3 агента (если применимо).
Проверьте журналы агента Neutron Open vSwitch.
Проверьте сопоставление физических интерфейсов.
Проверьте порты маршрутизатора Neutron (если применимо).
Проверьте, что мосты OVS содержат правильные интерфейсы на вычислительных и сетевых узлах.
Проверьте ``security-group-rules`, подумайте о добавлении правила разрешения ICMP для тестирования.
Убедитесь, что fdb таблица содержит нужные записи как на вычислительном, так и на сетевом контейнере агента Neutron.

Да:

Отлично! Инстанс может пинговать предполагаемый шлюз.
Проверьте маршруты шлюза или хоста в подсети Neutron.
Проверьте ``security-group-rules`, рассмотрите возможность добавления правила 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¶

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

openstack-ansible 31.1.0.dev50

Page Contents