Belajar OpenStack - Octavia (Load Balancer as a Service / LBaaS)

#Pendahuluan

Satu instance yang melayani semua traffic adalah titik kegagalan tunggal — dan batas skalabilitas. Saat aplikasi kalian mulai ramai, jawabannya bukan instance yang lebih besar, melainkan lebih banyak instance di belakang satu pintu masuk. Pintu masuk yang mendistribusikan traffic itulah load balancer, dan di OpenStack ia disediakan oleh Octavia.

Episode 13 membahas Octavia dari konsep hingga konfigurasi lengkap: apa itu load balancing dan mengapa penting, arsitektur Amphora yang berbasis VM, serta praktik membuat load balancer, listener, pool, member, dan health monitor dengan algoritma yang bisa dipilih.

#Konsep Load Balancer di OpenStack

#Mendistribusikan Traffic Secara Otomatis

Load balancer menerima traffic dari pengguna, lalu mendistribusikannya ke beberapa backend (instance) secara otomatis. Manfaat utamanya dua: skalabilitas — menambah instance berarti menambah kapasitas — dan ketahanan — jika satu backend mati, traffic dialihkan ke backend lain yang sehat.

Client → Load Balancer (floating IP publik)
                   ↓
         Instance A ← health monitor
         Instance B ← health monitor
         Instance C ← health monitor

Mekanisme yang menjaga backend tetap sehat adalah health monitor — pemeriksaan berkala yang menyingkirkan backend yang gagal menjawab.

#Hierarki Objek Octavia

Octavia mengorganisir konfigurasi dalam hierarki yang baku:

• Load Balancer: unit utama dengan IP virtual.
• Listener: port/protokol yang didengarkan, misalnya HTTP/80.
• Pool: kumpulan backend yang menerima traffic.
• Member: instance di dalam pool.
• Health Monitor: pemeriksaan kesehatan pool.

Semua objek ini dibuat berurutan — pahami hierarkinya dan konfigurasi menjadi mudah.

#Arsitektur Octavia

#Amphora: VM Load Balancer

Octavia mengimplementasikan load balancer sebagai Amphora — instance VM khusus yang menjalankan perangkat lunak load balancing (HAProxy). Setiap load balancer yang kalian buat berarti satu VM Amphora yang di-spawn, dikonfigurasi, dan dikelola Octavia secara otomatis.

openstack loadbalancer list
openstack loadbalancer amphora list

Output openstack loadbalancer amphora list menampilkan VM Amphora yang menopang load balancer kalian. Karena Amphora adalah VM, failover-nya otomatis — jika satu amphora gagal, Octavia membuat penggantinya.

#Arsitektur Control Plane

Octavia terdiri dari controller yang menangani API dan API worker, plus amphorae yang menangani data plane. Controller menerjemahkan API menjadi konfigurasi, worker menulis konfigurasi ke amphora via ssh, dan traffic lalu mengalir melewati amphora tanpa melibatkan controller. Pemisahan ini menjaga data plane tetap cepat meskipun control plane sibuk.

#Konfigurasi Octavia LBaaS

#Membuat Load Balancer dan Listener

openstack loadbalancer create --name lb-web --vip-subnet-id subnet-aplikasi
openstack loadbalancer listener create --protocol HTTP --protocol-port 80 lb-web
openstack loadbalancer list -c name -c provisioning_status

openstack loadbalancer create membutuhkan subnet untuk VIP (virtual IP). Proses provisioning memakan waktu karena Octavia harus membuat VM Amphora — tunggu sampai provisioning_status menjadi ACTIVE sebelum melanjutkan.

#Membuat Pool dan Member

openstack loadbalancer pool create --name pool-web --protocol HTTP \
  --lb-algorithm ROUND_ROBIN --listener web-listener
openstack loadbalancer member create --address 192.168.100.50 \
  --protocol-port 80 pool-web
openstack loadbalancer member create --address 192.168.100.51 \
  --protocol-port 80 pool-web

Perintah openstack loadbalancer member create menambahkan dua instance backend ke pool. Pilihan algoritma:

--lb-algorithm ROUND_ROBIN mendistribusikan request bergiliran — cocok untuk workload yang seragam. Untuk koneksi yang berlangsung lama, LEAST_CONNECTIONS lebih bijak.

#Membuat Health Monitor

Tanpa health monitor, load balancer akan tetap mengirim traffic ke backend yang mati. Tambahkan:

openstack loadbalancer healthmonitor create --delay 5 --timeout 4 \
  --max-retries 3 --type HTTP --url-path /health pool-web

openstack loadbalancer healthmonitor create memeriksa /health setiap 5 detik; setelah 3 kegagalan beruntun, member dikeluarkan dari pool sampai sehat kembali. Pola ini wajib di produksi — tanpa health monitor, LB hanya membagi-bagi kegagalan.

#Menghubungkan Floating IP ke Load Balancer

Untuk akses publik, associate floating IP ke VIP load balancer:

openstack floating ip create public
openstack loadbalancer set --name lb-web
openstack floating ip set <ip-id> --port lb-web-vip-port

Setelah openstack floating ip set, pengguna bisa mengakses aplikasi melalui floating IP, dan traffic didistribusikan ke kedua member dengan health check otomatis.

#Penutup

Episode 13 memberi kalian kemampuan load balancing produksi: memahami peran load balancer dalam skalabilitas dan ketahanan, arsitektur Amphora berbasis VM yang dikelola Octavia, serta konfigurasi lengkap load balancer, listener, pool, member, dan health monitor dengan algoritma round robin, least connections, dan source IP.

Inti yang harus dibawa pulang:

• Load balancer mendistribusikan traffic dan menyingkirkan backend gagal.
• Octavia memakai VM Amphora yang di-spawn dan dikelola otomatis.
• Hierarki: load balancer → listener → pool → member.
• Health monitor wajib agar backend yang mati otomatis dikeluarkan.
• Algoritma: round robin, least connections, source IP.
• Floating IP di VIP membuka load balancer ke publik.

Di episode 14 selanjutnya kita akan membahas Production Deployment dengan Kolla-Ansible — mengapa DevStack tidak cocok untuk produksi, pengenalan Kolla-Ansible yang mengemas setiap service ke dalam Docker dan diorkestrasi Ansible, topologi all-in-one versus multi-node, serta proses deployment dari globals.yml, inventory, hingga kolla-ansible deploy.