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.

Instruksi ini mengasumsikan instalasi OpenStack-Ansible menggunakan kontainer LXC, overlay VXLAN, dan driver Linuxbridge ml2.

Daftar Jaringan¶

HOST_NET (Physical Host Management dan Access ke Internet)
CONTAINER_NET (Jaringan kontainer LXC menggunakan Layanan Openstack)
OVERLAY_NET (jaringan hamparan VXLAN)

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

Memecahkan masalah lalu lintas host-to-host di CONTAINER_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
                                            ...

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

Alamat IP harus digunakan pada eth10 di dalam kontainer LXC yang diperlukan:

# ip address show dev eth10
67: eth10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 150...UP...
link/ether b1:b1:b1:b1:b1:02 brd ff:ff:ff:ff:ff:ff
inet 172.29.240.55/22 brd 172.29.243.255 scope global eth10
   valid_lft forever preferred_lft forever
   ...

br-vxlan harus berisi veth-pair end dari kontainer LXC yang diperlukan dan antarmuka fisik atau tagged-subinterface:

# brctl show br-vxlan
bridge name     bridge id          STP enabled  interfaces
br-vxlan        8000.ghijkl123456  no           bond1.100
                                                3333333_eth10

Memeriksa layanan¶

Anda dapat memeriksa status layanan OpenStack dengan mengakses setiap node pengontrol dan menjalankan service <SERVICE_NAME> status.

Lihat tautan berikut untuk informasi tambahan untuk memverifikasi layanan OpenStack:

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	# service glance-registry restart # service glance-api restart
Layanan Compute (node pengontrol)	# 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)
Layanan Compute (node komputasi)	# service nova-compute restart
Layanan Networking	# service neutron-server restart # service neutron-dhcp-agent restart # service neutron-l3-agent restart # service neutron-metadata-agent restart # service neutron-linuxbridge-agent restart
Layanan Networking (node komputasi)	# service neutron-linuxbridge-agent restart
Layanan Block Storage	# service cinder-api restart # service cinder-backup restart # service cinder-scheduler restart # service cinder-volume restart
Layanan Block Storage	# service manila-api restart # service manila-data restart # service manila-share restart # service manila-scheduler restart
Layanan Object Storage	# 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

Pemecahan kesulitan masalah konektivitas Instance¶

Bagian ini akan fokus pada pemecahan masalah komunikasi konektivitas instance umum (VM). Ini tidak mencakup jaringan apa pun yang terkait dengan konektivitas instance. Ini dengan asumsi instalasi OpenStack-Ansible menggunakan kontainer LXC, overlay VXLAN dan driver Linuxbridge ml2.

Data flow example

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



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

Pertanyaan pemecahan masalah awal untuk dijawab:¶

Komputasi node mana yang menjadi hosting VM yang dimaksud?
Antarmuka mana yang digunakan untuk lalu lintas jaringan penyedia?
Antarmuka mana yang digunakan untuk hamparan VXLAN?
Apakah masalah konektivitas ingress ke instance?
Apakah masalah konektivitas egress dari instance?
Apa alamat sumber lalu lintas?
Apa alamat tujuan lalu lintas?
Apakah ada router Neutron yang sedang dimainkan?
Node jaringan (kontainer) manakah yang dihosting oleh router?
Apa jenis jaringan penyewa?

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.
Periksa Neutron security-group-rules, pertimbangkan menambahkan izinkan aturan ICMP untuk pengujian.
Periksa apakah linux bridges berisi antarmuka yang tepat. pada komputasi dan node jaringan.
Periksa log agen DHCP Neutron.
Periksa syslogs.
Periksa Neutron linux bridge 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.

Apakah alamat IP instance mem-ping dari perangkat gateway (Neutron router namespace atau perangkat gateway lain)?

No:

Periksa log agen Neutron L3 (jika ada).
Periksanlog Neutron linuxbridge.
Periksa pemetaan antarmuka fisik.
Periksa port Neutron Router (jika ada).
Periksa apakah linux bridges berisi antarmuka yang tepat pada node komputasi dan jaringan.
Periksa Neutron security-group-rules, pertimbangkan menambahkan izinkan aturan ICMP untuk pengujian.

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.
Periksa Neutron security-group-rules, pertimbangkan untuk menambahkan aturan ICMP untuk pengujian.
Periksa asosiasi Neutron FloatingIP (jika ada).
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.

Jika VXLAN:

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 VXLAN VTEP dapat melakukan ping satu sama lain?

No:

Periksa antarmuka br-vxlan pada Compute dan eth10 di dalam kontainer agen jaringan Neutron.
Periksa pasangan veth antara kontainer dan jembatan linux pada host.
Periksa apakah linux bridges berisi antarmuka yang tepat pada node komputasi dan jaringan.

Yes:

Periksa file konfigurasi ml2 untuk IP VXLAN lokal dan pengaturan konfigurasi VXLAN lainnya.
Periksa metode pembelajaran VTEP (multicast atau l2population):
- Jika multicast, pastikan switch fisik aktif dan mendistribusikan lalu lintas multicast dengan benar.

Penting

Jangan teruskan sebelum titik akhir VXLAN memiliki jangkauan satu sama lain.

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.
Periksa Neutron security-group-rules, pertimbangkan menambahkan izinkan aturan ICMP untuk pengujian.
Periksa apakah linux bridges berisi antarmuka yang tepat pada node komputasi dan jaringan.
Periksa log agen DHCP Neutron.
Periksa syslogs.
Periksa Neutron linux bridge logs.
Periksa bahwa Bridge Forwarding Database (fdb) berisi entri yang tepat pada kontainer agen Neutron dan komputasi.

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.

Apakah alamat IP instance mem-ping dari perangkat gateway (Neutron router namespace atau perangkat gateway lain)?

No:

Periksa log agen Neutron L3 (jika ada).
Periksa Neutron linux bridge logs.
Periksa pemetaan antarmuka fisik.
Periksa port router Neutron (jika ada).
Periksa apakah linux bridges berisi antarmuka yang tepat pada node komputasi dan jaringan.
Periksa Neutron security-group-rules, pertimbangkan menambahkan izinkan aturan ICMP untuk pengujian.
Periksa bahwa Bridge Forwarding Database (fdb) berisi entri yang tepat pada kontainer agen Neutron dan komputasi.

Yes:

Baik! Instance dapat melakukan ping ke gateway yang dituju.
Periksa rute gateway atau host di subnet Neutron.
Periksa Neutron security-group-rules, pertimbangkan untuk menambahkan aturan ICMP untuk pengujian.
Periksa asosiasi Neutron FloatingIP (jika ada).
Periksa informasi gateway eksternal Router Neutron (jika ada).
Periksa rute hulu, NATs atau access-control-lists.

Diagnosis masalah layanan Image¶

glance-registry menangani operasi basis data untuk mengelola penyimpanan image indeks dan properti. glance-api menangani interaksi API dan penyimpanan image.

Untuk memecahkan masalah atau kesalahan dengan layanan Image, lihat /var/log/glance-api.log dan /var/log/glance-registry.log di dalam kontainer glance api.

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.

Untuk contoh dan informasi lebih lanjut, lihat Verify operation <https://docs.openstack.org/glance/latest/install/verify.html>_. dan Manage Images <https://docs.openstack.org/glance/latest/admin/manage-images.html>_

Isu RabbitMQ¶

Menganalisis antrian RabbitMQ¶

Menganalisis log layanan OpenStack dan log RabbitMQ¶

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.

Playbook yang gagal mungkin dilakukan selama 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¶

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

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

Memeriksa layanan¶

Memulai kembali layanan¶

Pemecahan kesulitan masalah konektivitas Instance¶

Pertanyaan pemecahan masalah awal untuk dijawab:¶

Diagnosis masalah layanan Image¶

Isu RabbitMQ¶

Menganalisis antrian RabbitMQ¶

Menganalisis log layanan OpenStack dan log RabbitMQ¶

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

Isu fakta cached Ansible¶

Memaksa regenerasi fakta yang di-cache¶

Playbook yang gagal mungkin dilakukan selama upgrade¶

Isu jaringan kontainer¶

Penamaan antarmuka yang dapat diprediksi¶

Tinjau lalu lintas jaringan kontainer¶

Memulihkan inventaris dari backup¶

openstack-ansible

Page Contents