[ English | Indonesia | русский ]
Устранение неполадок¶
Эта глава предназначена для помощи в устранении неполадок и решении операционных проблем в развертывании OpenStack-Ansible.
Сеть¶
Этот раздел посвящен устранению неисправностей, связанных с обменом данными между хостами, необходимыми для правильной работы плоскости управления OpenStack.
Здесь не рассматриваются сетевые возможности, связанные с подключением инстансов.
В данных инструкциях предполагается установка OpenStack-Ansible с использованием контейнеров LXC, overlay сети VXLAN для ML2/OVS и overlay сети Geneve для драйверов ML2/OVN.
Список сетей¶
HOST_NET(управление физическими хостами и доступом в Интернет)MANAGEMENT_NET(сеть контейнеров LXC, используемая службами OpenStack)OVERLAY_NET(overlay сеть VXLAN для OVS, overlay сеть Geneve для 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
...
Устранение проблем с трафиком между хостами в 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
...
Вы также можете использовать команду ip для отображения bridge:
# 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
...
Проверка служб¶
Вы можете проверить состояние службы OpenStack, открыв каждый управляющий узел и выполнив команду systemctl status <SERVICE_NAME>.
Дополнительные сведения о проверке служб OpenStack см. по следующим ссылкам:
Некоторые полезные команды для управления LXC см. Справочник по командной строке.
Перезапуск служб¶
Перезапустите службы 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
|
Сетевая служба (управляющий узел, для 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
|
Сетевая служба (управляющий узел, для OVN) |
# systemctl restart neutron-server
# systemctl restart neutron-ovn-maintenance-worker
# systemctl restart neutron-periodic-workers
|
Сетевая служба (вычислительный узел, для 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
|
Устранение проблем с подключением инстансов¶
В этом разделе мы рассмотрим устранение общих неполадок подключения инстансов. Сетевые компоненты, связанные с подключением инстансов, здесь не рассматриваются. Предполагается установка OpenStack-Ansible с использованием контейнеров LXC, overlay сети VXLAN для драйвера ML2/OVS и overlay сети Geneve для драйвера ML2/OVN.
Пример потока данных (для 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 +-->
+-------------+ +-------------+
Пример потока данных (для OVN)
COMPUTE NODE
+-------------+ +-------------+
+->"If Geneve"+->+ *br-vxlan +--->+ bond0.#00 +---+
| +-------------+ +-------------+ |
+-------------+ | +-----------------+
Instance +---> | br-int |++ +-->| physical network|
+-------------+ | +-----------------+
| +-------------+ +-------------+ |
+->"If VLAN"+->+ br-vlan +--->+ bond1 +-----+
+-------------+ +-------------+
Предварительные вопросы по устранению неполадок, на которые необходимо ответить:¶
На каком вычислительном узле размещается рассматриваемый инстанс?
Какой интерфейс используется для сетевого трафика провайдера?
Какой интерфейс используется overlay сети VXLAN (Geneve)?
Есть ли проблемы с подключением к инстансу?
Есть ли проблемы с подключением с инстанса?
Каков адрес источника трафика?
Каков адрес назначения трафика?
Работает ли маршрутизатор 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 содержат правильные интерфейсы на вычислительных и сетевых узлах.
Проверьте
security-group-rules, рассмотрите возможность добавления правила ICMP для тестирования. При использовании OVN проверьте дополнительно:Проверьте ovn-controller на всех узлах.
Убедитесь, что ovn-northd активен и базы данных работают без ошибок.
Убедитесь, что ovn-metadata-agent активен.
Просмотрите логи ovn-controller, ovn-northd.
- Да:
Отлично! Инстанс может пинговать предполагаемый шлюз. Проблема может быть связана со шлюзом или с сетью провайдера.
Проверьте «шлюз» или маршруты хоста в подсети Neutron.
Проверьте правила группы безопасности, рассмотрите возможность добавления правила ICMP для тестирования.
Проверьте привязки плавающего IP (если применимо).
Проверьте информацию о внешнем шлюзе маршрутизатора Neutron (если применимо).
Проверьте вышестоящие маршруты, NAT или списки контроля доступа.
Важно
Не продолжайте, пока инстанс не установит связь со своим шлюзом.
Если VXLAN (Geneve):
Показывает ли физический интерфейс подключение и все ли VLAN правильно проброшены транком через физическую сеть?
- Нет:
Проверьте кабель, соединение, конфигурацию физического порта коммутатора, конфигурацию интерфейса/агреграции и общую конфигурацию сети. См. общую документацию по устранению неполадок в сети.
- Да:
Хорошо!
Продолжайте!
Важно
Не продолжайте работу, пока физическая сеть не будет правильно настроена.
Могут ли адреса VTEP VXLAN (Geneve) отправлять друг другу пинги?
- Нет:
Проверьте интерфейс
br-vxlanна вычислительных и сетевых узлах.Проверьте пары veth между контейнерами и мостами Linux на хосте.
Проверьте, что мосты OVS содержат правильные интерфейсы на вычислительных и сетевых узлах.
- Да:
Проверьте файл конфигурации ml2 на наличие локального IP-адреса VXLAN (Geneve) и других параметров конфигурации VXLAN (Geneve).
- Проверьте метод обучения VTEP (multicas или l2population):
В случае multicast, убедитесь, что физические коммутаторы правильно разрешают и распределяют multicast трафик.
Важно
Не продолжайте работу, пока эндпойнты VXLAN (Geneve) не станут доступны друг другу.
Пингуется ли IP-адрес инстанса из пространства имен DHCP сети или других инстансов в той же сети?
- Нет:
Проверьте логи консоли Nova, чтобы узнать, получал ли инстанс свой IP-адрес изначально.
Проверьте правила группы безопасности, подумайте о добавлении правила разрешения ICMP для тестирования.
Проверьте, что мосты OVS содержат правильные интерфейсы на вычислительных и сетевых узлах.
Проверьте журналы агента DHCP Neutron.
Проверьте системные журналы.
Проверьте журналы агента Neutron Open vSwitch.
Проверьте, что база данных Bridge Forwarding Database (fdb) содержит правильные записи как для вычислительного контейнера, так и для контейнера агента Neutron (
ovs-appctl fdb/show br-int).
- Да:
Хорошо! Это означает, что инстанс получил свой IP-адрес и может обращаться к ресурсам локальной сети.
Важно
Не продолжайте, пока инстанс не получит IP-адрес и не сможет обращаться к ресурсам локальной сети.
Пингуется ли IP-адрес инстанса с шлюза (пространство имен Neutron Router или другого шлюза)?
- Нет:
Проверьте журналы L3 агента (если применимо).
Проверьте журналы агента Neutron Open vSwitch.
Проверьте сопоставление физических интерфейсов.
Проверьте порты маршрутизатора Neutron (если применимо).
Проверьте, что мосты OVS содержат правильные интерфейсы на вычислительных и сетевых узлах.
Проверьте правила группы безопасности, подумайте о добавлении правила разрешения ICMP для тестирования.
Убедитесь, что база данных Bridge Forwarding Database (fdb) содержит необходимые записи как для вычислительного узла, так и для контейнера агента Neutron (
ovs-appctl fdb/show br-int). При использовании OVN проверьте дополнительно:Проверьте ovn-controller на всех узлах.
Убедитесь, что ovn-northd активен и базы данных работают без ошибок.
Убедитесь, что ovn-metadata-agent активен.
Просмотрите логи ovn-controller, ovn-northd.
- Да:
Отлично! Инстанс может пинговать предполагаемый шлюз.
Проверьте маршруты шлюза или хоста в подсети Neutron.
Проверьте правила группы безопасности, рассмотрите возможность добавления правила ICMP для тестирования.
Проверьте привязки плавающего IP Neutron (если применимо).
Проверьте информацию о внешнем шлюзе маршрутизатора Neutron (если применимо).
Проверьте вышестоящие маршруты, NAT или
списки контроля доступа.
Диагностика проблем, связанных с службой образов¶
glance-api управляет взаимодействием с API и хранилищем образов.
Чтобы устранить проблемы или ошибки в работе службы образов, обратитесь к /var/log/glance-api.log внутри контейнера glance api.
Вы также можете выполнять следующие действия, которые могут генерировать журналы для идентификации проблем:
Загрузите образ, чтобы убедиться, что он может быть прочитан из хранилища.
Загрузите образ, чтобы проверить, регистрируется ли он и записывается ли в хранилище образов.
Выполните команду
openstack image list, чтобы убедиться, что API и реестр работают.
Пример и дополнительную информацию см. в разделах Проверки и Управления образами.
Проблемы с кэшированными фактами 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 будет восстановлен до предыдущей версии.
