[ English | русский | Deutsch | 한국어 (대한민국) | English (United Kingdom) | Indonesia | español | français ]
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
...
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.
Layanan OpenStack |
Perintah |
---|---|
Layanan Image |
# 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 +-->
| +-------------+ +-------------+ |
+----------------+ | +-------------+
|physical network|++ +--->+| brq bridge |+--> Neutron DHCP/Router
+----------------+ | +-------------+
| +-------------+ +-------------+ |
+->"If VLAN"+->+ bond1 +--->+ br vlan +-->
+-------------+ +-------------+
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 interface
br-vxlan
pada node Compute dan NetworkPeriksa 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¶
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.
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>_
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.