Belajar OpenStack - Troubleshooting & Operational Maintenance

#Pendahuluan

Semua arsitektur hebat akhirnya bertemu satu kenyataan: sesuatu akan rusak. Instance menolak lahir, jaringan macet, volume tidak bisa di-attach, login menolak. Yang membedakan operator profesional bukan kemampuannya menghindari masalah, melainkan cara dia mendiagnosis dan memulihkan dengan cepat dan tenang.

Episode 19 adalah episode paling praktis di series ini: kalian akan menghafal perintah diagnostik inti, mempelajari pola troubleshooting untuk empat masalah paling umum — instance gagal spawn, masalah network, kegagalan attach volume, dan error autentikasi — lalu menguasai day-2 operations seperti upgrade dan pembersihan queue.

#Perintah Diagnostik OpenStack

#Menilai Kesehatan Service

Sebelum menyelam ke log, cek dulu kondisi service dari satu tempat:

openstack compute service list
openstack network agent list
openstack volume service list

Output openstack compute service list menampilkan status seluruh service Nova per node. Perhatikan kolom State (harus up) dan Status (harus enabled). openstack network agent list dan openstack volume service list melakukan hal yang sama untuk Neutron dan Cinder. Ketiganya adalah baris pertama setiap diagnosis.

#Memeriksa Infrastruktur Pendukung

Ketika service tampak normal tapi masih bermasalah, arahkan ke komponen penopang:

sudo rabbitmqctl status
mysql -e "SHOW STATUS LIKE 'wsrep_cluster_size';"

rabbitmqctl status memastikan broker message hidup, dan SHOW STATUS LIKE 'wsrep_cluster_size' memverifikasi semua node Galera dalam satu cluster. Memcached yang penuh atau mati juga sering jadi penyebab error aneh karena token Keystone disimpan di sana.

#Troubleshooting Masalah Umum

#Instance Failed to Spawn

Gejala: openstack server create menghasilkan status ERROR. Urutan diagnosis:

openstack server show my-server -f value -c fault
openstack compute service list -f value -c host -c state

Output openstack server show -c fault menampilkan alasan dari scheduler atau compute. Penyebab paling umum: resource tidak cukup (RAM/vCPU kuota), image rusak, atau service compute down. Periksa log nova-compute dan pastikan Placement service menampilkan resource yang benar:

openstack resource provider list

#Networking Issues

Gejala: instance tanpa IP, atau DHCP tidak bekerja. Cek agent dan metadata:

openstack network agent list -f value -c agent_type -c host -c alive
openstack network agent list --dhcp

Output openstack network agent list menampilkan apakah agent dhcp, metadata, dan l3 masih alive. Agent yang mati berarti DHCP dan metadata service tidak melayani instance baru. Restart agent dari node terkait dan verifikasi namespace:

sudo systemctl restart neutron-dhcp-agent

#Volume Attach Failures

Gejala: openstack server add volume menggantung atau error. Cek status backend Cinder dan koneksi ke Ceph:

openstack volume service list
ceph -s

Output openstack volume service list menunjukkan state backend; ceph -s memastikan cluster sehat. Penyebab umum: pool tidak punya ruang, atau node compute tidak bisa menjangkau Ceph. Pastikan juga keyring dan konfigurasi Ceph sama di semua node yang memakai volume.

#Keystone Auth 401/403

Gejala: openstack CLI menolak login. Penyebab paling sering ada tiga: token expired (source ulang openrc), kredensial salah project/domain, atau waktu antar node tidak sinkron. Cek sinkronisasi waktu dulu:

chronyc tracking | grep -E "Stratum|Offset"

Output chronyc tracking menampilkan offset waktu node. Jika offset besar, token Fernet dianggap tidak valid di node lain — sinkronkan semua node dengan chrony/NTP sebagai langkah pertama setiap debug auth.

#Day-2 Operations

#Strategi Upgrade

Upgrade OpenStack produksi bukan tebak-tebakan — ia playbook yang terdokumentasi:

sed -i 's/openstack_release: "caracal"/openstack_release: "dalmatian"/' /etc/kolla/globals.yml
kolla-ansible -i multinode prechecks
kolla-ansible -i multinode upgrade

kolla-ansible -i multinode upgrade menaikkan service satu per satu dengan rolling restart. Prinsipnya: selalu jalankan prechecks dulu, lakukan di jendela maintenance, dan pastikan backup database sebelum upgrade. Jangan lompati versi mayor tanpa membaca release notes.

#Database Maintenance

Database adalah sumber kebenaran cluster — rawat ia seperti harta:

mysql -e "OPTIMIZE TABLE nova.instances;"
mysqldump --all-databases > /backup/openstack-2026-08-10.sql

OPTIMIZE TABLE menata ulang tabel, dan mysqldump membuat backup yang bisa dipulihkan. Backup terjadwal dan pemantauan ukuran database adalah rutinitas yang tidak boleh terlewat.

#RabbitMQ Queue Cleanup

Queue yang menumpuk (unacked message membengkak) memperlambat seluruh service:

sudo rabbitmqctl list_queues name messages messages_unacknowledged
sudo rabbitmqctl reset

rabbitmqctl list_queues memperlihatkan queue yang bermasalah. Jika queue rusak dan tidak bisa dipulihkan, rabbitmqctl reset mengembalikan broker ke kondisi bersih — tapi ini mengorbankan state queue, jadi pastikan ini langkah terakhir setelah alternatif lain gagal.

#Penutup

Episode 19 membekali kalian keterampilan operasional yang sesungguhnya: menguasai perintah diagnostik compute service list, network agent list, dan volume service list, menangani masalah umum seperti instance gagal spawn, network down, attach volume gagal, dan auth error, serta menjalankan day-2 operations seperti upgrade Kolla-Ansible, maintenance database, dan pembersihan queue RabbitMQ.

Inti yang harus dibawa pulang:

• Diagnosa dimulai dari status service, lalu log, lalu infrastruktur.
• Instance ERROR: cek fault, resource, dan service compute.
• Agent mati berarti DHCP dan metadata tidak melayani.
• Auth 401/403: cek waktu sinkron antar node terlebih dahulu.
• Upgrade wajib prechecks dan backup sebelum eksekusi.
• Queue RabbitMQ dan database butuh perawatan rutin.

Di episode 20 — episode terakhir — kita akan membahas Studi Kasus Complete Production-Grade Private Cloud Architecture — merancang arsitektur enterprise utuh dari deployment engine Kolla-Ansible, compute layer Nova dengan Ceph, networking Neutron dengan VLAN, VXLAN, DVR, dan Octavia, storage Ceph unified dengan Barbican, hingga observability dan security, ditutup checklist kesiapan produksi dan maintenance routine.