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

Penyelesaian masalah¶

Bab ini dimaksudkan untuk membantu memecahkan masalah dan menyelesaikan masalah operasional dalam penerapan OpenStack-Ansible.

Jaringan¶

Bagian ini berfokus pada pemecahan masalah komunikasi host-ke-host umum yang diperlukan agar bidang kontrol (control plane) OpenStack berfungsi dengan baik.

Ini tidak mencakup jaringan apa pun yang terkait dengan konektivitas instance.

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

Daftar Jaringan¶

HOST_NET (Physical Host Management dan Access ke Internet)
MANAGEMENT_NET (LXC container network used OpenStack Services)
OVERLAY_NET (VXLAN overlay network for OVS, Geneve overlay network for OVN)

Utilitas dan perintah jaringan yang berguna:

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

Memecahkan masalah lalu lintas host-to-host di HOST_NET¶

Lakukan pemeriksaan berikut:

Periksa konektivitas fisik host ke jaringan fisik
Periksa ikatan antarmuka (jika ada)
Periksa konfigurasi VLAN dan semua trunking yang diperlukan ke edge port pada switch fisik
Periksa konfigurasi VLAN dan semua trunking yang diperlukan untuk menghubungkan (uplink) port pada switch fisik (jika ada)
Periksa apakah host berada dalam subnet IP yang sama atau miliki routing yang tepat di antara mereka
Periksa tidak ada iptables yang diterapkan pada host yang akan menolak lalu lintas (traffic)

Alamat IP harus diterapkan pada antarmuka fisik (physical interface), antarmuka ikatan (bond interface), sub-antarmuka yang ditandai (tagged sub-interface), atau dalam beberapa kasus pada antarmuka jembatan (bridge interface):

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

Lakukan pemeriksaan berikut:

Periksa konektivitas fisik host ke jaringan fisik
Periksa ikatan antarmuka (jika ada)
Periksa konfigurasi VLAN dan semua trunking yang diperlukan ke edge port pada switch fisik
Periksa konfigurasi VLAN dan semua trunking yang diperlukan untuk menghubungkan (uplink) port pada switch fisik (jika ada)
Pastikan host berada di subnet yang sama atau memiliki routing yang tepat di antara mereka
Periksa tidak ada iptables yang diterapkan pada host yang akan menolak lalu lintas (traffic)
Periksa untuk memverifikasi bahwa antarmuka fisik ada di jembatan (bridge)
Periksa untuk memverifikasi bahwa veth-pair end dari kontainer ada di br-mgmt

Alamat IP harus digunakan ke 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
...

Alamat IP harus digunakan pada eth1 di dalam kontainer 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 harus berisi veth-pair end dari semua kontainer dan antarmuka fisik atau tagged-subinterface:

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

Memecahkan masalah lalu lintas host-to-host pada OVERLAY_NET¶

Lakukan pemeriksaan berikut:

Periksa konektivitas fisik host ke jaringan fisik
Periksa ikatan antarmuka (jika ada)
Periksa konfigurasi VLAN dan semua trunking yang diperlukan ke edge port pada switch fisik
Periksa konfigurasi VLAN dan semua trunking yang diperlukan untuk menghubungkan (uplink) port pada switch fisik (jika ada)
Pastikan host berada di subnet yang sama atau memiliki routing yang tepat di antara mereka
Periksa tidak ada iptables yang diterapkan pada host yang akan menolak lalu lintas (traffic)
Periksa untuk memverifikasi bahwa antarmuka fisik ada di jembatan (bridge)
Periksa untuk memverifikasi bahwa veth-pair end dari kontainer ada di br-vxlan

Alamat IP harus digunakan ke 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
   ...

Memeriksa layanan¶

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

Lihat tautan berikut untuk informasi tambahan untuk memverifikasi layanan OpenStack:

Some useful commands to manage LXC see Command Line Reference (referensi baris perintah).

Memulai kembali layanan¶

Mulai ulang (restart) layanan OpenStack Anda dengan mengakses setiap node pengontrol. Beberapa layanan OpenStack akan membutuhkan restart dari node lain di lingkungan Anda.

Tabel berikut mencantumkan perintah untuk memulai kembali (restart) layanan OpenStack.

Mulai ulang (restart) layanan OpenStack¶
Layanan OpenStack	Perintah
Layanan Image	# systemctl restart glance-api
Layanan Compute (node pengontrol)	# 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)
Layanan Compute (node komputasi)	# 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
Layanan Networking (node komputasi)	# 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
Layanan Block Storage	# systemctl restart cinder-api # systemctl restart cinder-backup # systemctl restart cinder-scheduler # systemctl restart cinder-volume
Shared Filesystems service	# systemctl restart manila-api # systemctl restart manila-data # systemctl restart manila-share # systemctl restart manila-scheduler
Layanan Object Storage	# 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

Troubleshooting instance connectivity issues¶

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

Pertanyaan pemecahan masalah awal untuk dijawab:¶

Which compute node is hosting the instance in question?
Antarmuka mana yang digunakan untuk lalu lintas jaringan penyedia?
Which interface is used for VXLAN (Geneve) overlay?
Is there connectivity issue ingress to the instance?
Is there connectivity issue egress from the instance?
Apa alamat sumber lalu lintas?
Apa alamat tujuan lalu lintas?
Is there a Neutron Router in play?
Node jaringan (kontainer) manakah yang dihosting oleh router?
What is the project network type?

If VLAN:

Apakah antarmuka fisik menunjukkan tautan dan semua VLAN dengan benar di-trunk di jaringan fisik?

No:

Periksa kabel, seating, konfigurasi switchport fisik, konfigurasi interface/bonding, dan konfigurasi jaringan umum. Lihat dokumentasi pemecahan masalah jaringan umum.

Yes:

Good!
Continue!

Penting

Jangan melanjutkan sebelum jaringan fisik dikonfigurasi dengan benar.

Apakah alamat IP instance ping dari namespace DHCP jaringan atau instance lain dalam jaringan yang sama?

No:

Periksa nova console logs untuk melihat apakah instance pernah menerima alamat IP-nya pada awalnya.
Check security-group-rules, consider adding allow ICMP rule for testing.
Check that OVS bridges contain the proper interfaces on compute and network nodes.
Periksa log agen DHCP Neutron.
Periksa syslogs.
Check Neutron Open vSwitch agent logs.

Yes:

Baik! Ini menunjukkan bahwa instance menerima alamat IP-nya dan dapat mencapai sumber daya jaringan lokal.
Continue!

Penting

Jangan melanjutkan sampai instance memiliki alamat IP dan dapat mencapai sumber daya jaringan lokal seperti DHCP.

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

No:

Periksa log agen Neutron L3 (jika ada).
Check Neutron Open vSwitch logs.
Periksa pemetaan antarmuka fisik.
Periksa port router Neutron (jika ada).
Check that OVS bridges contain the proper interfaces on compute and network nodes.
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.

Yes:

Baik! Instance dapat melakukan ping ke gateway yang dituju. Masalahnya mungkin berada di utara gateway (north of the gateway) atau terkait dengan jaringan penyedia.
Periksa "gateway" atau host me-rute pada subnet Neutron.
Check security-group-rules, consider adding ICMP rule for testing.
Check Floating IP associations (if applicable).
Periksa informasi gateway eksternal Router Neutron (jika ada).
Periksa rute hulu, NAT atau access-control-lists.

Penting

Jangan melanjutkan sampai instance dapat mencapai gateway-nya.

If VXLAN (Geneve):

Apakah antarmuka fisik menunjukkan tautan dan semua VLAN dengan benar di-trunk di jaringan fisik?

No:

Periksa kabel, seating, konfigurasi switchport fisik, konfigurasi interface/bonding, dan konfigurasi jaringan umum. Lihat dokumentasi pemecahan masalah jaringan umum.

Yes:

Good!
Continue!

Penting

Jangan melanjutkan sebelum jaringan fisik dikonfigurasi dengan benar.

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

No:

Check br-vxlan interface on Compute and Network nodes.
Check veth pairs between containers and Linux bridges on the host.
Check that OVS bridges contain the proper interfaces on compute and network nodes.

Yes:

Check ml2 config file for local VXLAN (Geneve) IP and other VXLAN (Geneve) configuration settings.
Periksa metode pembelajaran VTEP (multicast atau l2population):
- Jika multicast, pastikan switch fisik aktif dan mendistribusikan lalu lintas multicast dengan benar.

Penting

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

Apakah alamat IP instance ping dari namespace DHCP jaringan atau instance lain dalam jaringan yang sama?

No:

Periksa log konsol Nova untuk melihat apakah instance pernah menerima alamat IP pada awalnya.
Check security-group-rules, consider adding allow ICMP rule for testing.
Check that OVS bridges contain the proper interfaces on compute and network nodes.
Periksa log agen DHCP Neutron.
Periksa syslogs.
Check Neutron Open vSwitch agent logs.
Check that Bridge Forwarding Database (fdb) contains the proper entries on both the compute and Neutron agent container (ovs-appctl fdb/show br-int).

Yes:

Baik! Ini menunjukkan bahwa instance menerima alamat IP-nya dan dapat mencapai sumber daya jaringan lokal.

Penting

Jangan melanjutkan sebelum instance memiliki alamat IP dan dapat mencapai sumber daya jaringan lokal.

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

No:

Periksa log agen Neutron L3 (jika ada).
Check Neutron Open vSwitch agent logs.
Periksa pemetaan antarmuka fisik.
Periksa port router Neutron (jika ada).
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 (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.

Yes:

Baik! Instance dapat melakukan ping ke gateway yang dituju.
Periksa rute gateway atau host di subnet Neutron.
Check security-group-rules, consider adding ICMP rule for testing.
Check Neutron Floating IP associations (if applicable).
Periksa informasi gateway eksternal Router Neutron (jika ada).
Periksa rute hulu, NATs atau access-control-lists.

Diagnosis masalah layanan Image¶

The glance-api menangani interaksi API dan penyimpanan image.

Untuk memecahkan masalah atau error dengan layanan Image, lihat /var/log/glance-api.log di dalam glance api container.

Anda juga dapat melakukan aktivitas berikut yang dapat menghasilkan log untuk membantu masalah identitas:

Unduh image untuk memastikan bahwa image dapat dibaca dari store (penyimpanan).
Unggah image untuk menguji apakah image tersebut terdaftar dan ditulis ke penyimpanan image.
Jalankan perintah openstack image list untuk memastikan bahwa API dan registri berfungsi.

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

Pengerasan (hardening) keamanan gagal setelah upgrade kernel host dari versi 3.13¶

Paket kernel Ubuntu yang lebih baru dari versi 3.13 berisi perubahan dalam penamaan modul dari nf_conntrack menjadi br_netfilter. Setelah memutakhirkan kernel, jalankan playbook openstack-hosts-setup.yml terhadap host tersebut. Untuk informasi lebih lanjut, lihat OSA bug 157996.

Isu fakta cached Ansible¶

Pada awal menjalankan playbook, informasi tentang setiap host dikumpulkan, seperti:

Distribusi Linux
Versi kernel
Antarmuka jaringan

Untuk meningkatkan kinerja, khususnya dalam penyebaran besar, Anda dapat menyimpan fakta dan informasi host.

OpenStack-Ansible memungkinkan caching fakta secara default. Fakta di-cache dalam file JSON di dalam /etc/openstack_deploy/ansible_facts.

Caching fakta dapat dinonaktifkan dengan menjalankan export ANSIBLE_CACHE_PLUGIN = memory. Untuk mengatur ini secara permanen, setel variabel ini di /usr/local/bin/openstack-ansible.rc. Lihat dokumentasi Ansible di fact caching untuk detail lebih lanjut.

Memaksa regenerasi fakta yang di-cache¶

Fakta yang di-cache mungkin salah jika host menerima upgrade kernel atau antarmuka jaringan baru. Jembatan yang baru dibuat dapat juga mengacaukan fakta cache.

Ini dapat menyebabkan kesalahan yang tidak terduga saat menjalankan playbooks, dan membutuhkan fakta cache untuk diregenerasi.

Jalankan perintah berikut untuk menghapus semua fakta yang di-cache saat ini untuk semua host:

# rm /etc/openstack_deploy/ansible_facts/*

Fakta baru akan dikumpulkan dan di-cache selama menjalankan playbook berikutnya.

Untuk menghapus fakta dari satu host, temukan file-nya di dalam /etc/openstack_deploy/ansible_facts/ dan hapus. Setiap host memiliki file JSON yang dinamai dengan nama hostnya. Fakta untuk host itu akan dibuat kembali pada menjalankan playbook berikutnya.

Failed Ansible playbooks during an upgrade¶

Isu jaringan kontainer¶

Semua kontainer LXC pada host memiliki setidaknya dua antarmuka Ethernet virtual:

eth0 dalam kontainer terhubung ke` lxcbr0` pada host
eth1 dalam kontainer terhubung ke br-mgmt pada host

Catatan

Beberapa kontainer, seperti cinder, glance, neutron_agents, dan swift_proxy memiliki lebih dari dua antarmuka untuk mendukung fungsinya.

Penamaan antarmuka yang dapat diprediksi¶

Pada host, semua perangkat Ethernet virtual diberi nama berdasarkan kontainer mereka serta nama antarmuka di dalam kontainer:

${CONTAINER_UNIQUE_ID}_${NETWORK_DEVICE_NAME}

Sebagai contoh, build all-in-one (AIO) mungkin menyediakan kontainer utilitas yang disebut aio1_utility_container-d13b7132. Kontainer itu akan memiliki dua antarmuka jaringan: d13b7132_eth0 dan d13b7132_eth1.

Pilihan lain adalah menggunakan alat LXC untuk mengambil informasi tentang kontainer utilitas. Sebagai contoh:

# 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

Baris Link: akan menampilkan antarmuka jaringan yang terpasang pada kontainer utilitas.

Tinjau lalu lintas jaringan kontainer¶

Untuk membuang lalu lintas di jembatan br-mgmt, gunakan tcpdump untuk melihat semua komunikasi antara berbagai kontainer. Untuk mempersempit fokus, jalankan tcpdump hanya pada antarmuka jaringan kontainer yang diinginkan.

Memulihkan inventaris dari backup¶

OpenStack-Ansible mengelola arsip inventaris yang berjalan. Jika perubahan telah dimasukkan ke dalam sistem yang telah merusak inventaris atau sebaliknya telah menyebabkan masalah yang tidak terduga, inventaris dapat dikembalikan ke versi awal. File backup /etc/openstack_deploy/backup_openstack_inventory.tar berisi serangkaian inventaris timestamp yang dapat dipulihkan sesuai kebutuhan.

Contoh proses pengembalian inventaris.

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

Pada penyelesaian operasi ini inventaris akan dikembalikan ke versi sebelumnya.

Penyelesaian masalah

Penyelesaian masalah¶

Jaringan¶

Daftar Jaringan¶

Memecahkan masalah lalu lintas host-to-host di HOST_NET¶

Troubleshooting host-to-host traffic on MANAGEMENT_NET¶

Memecahkan masalah lalu lintas host-to-host pada OVERLAY_NET¶

Memeriksa layanan¶

Memulai kembali layanan¶

Troubleshooting instance connectivity issues¶

Pertanyaan pemecahan masalah awal untuk dijawab:¶

Diagnosis masalah layanan Image¶

Pengerasan (hardening) keamanan gagal setelah upgrade kernel host dari versi 3.13¶

Isu fakta cached Ansible¶

Memaksa regenerasi fakta yang di-cache¶

Failed Ansible playbooks during an upgrade¶

Isu jaringan kontainer¶

Penamaan antarmuka yang dapat diprediksi¶

Tinjau lalu lintas jaringan kontainer¶

Memulihkan inventaris dari backup¶

openstack-ansible 31.1.0.dev269

Page Contents