Belajar OpenStack - Production Networking: Provider Networks, VXLAN & DVR

#Pendahuluan

Episode 6-7 membangun networking yang benar secara konsep; episode 15 membangun networking yang benar secara arsitektur produksi. Di produksi, tidak ada satu NIC yang mengerjakan semuanya, tidak ada VLAN yang diserahkan kepada kebetulan, dan tidak ada satu node yang menjadi titik kemacetan routing. Semua itu dipecahkan dengan tiga pilar: dual-NIC layout, provider network yang tertata, dan DVR.

Episode 15 membahas ketiganya: bagaimana node disusun dengan dua NIC terpisah, bagaimana provider network memetakan ke VLAN fisik, bagaimana VXLAN mengisolasi tenant, dan bagaimana Distributed Virtual Router menghilangkan bottleneck di network node terpusat.

#Arsitektur Networking Produksi

#Dual-NIC Node Layout

Node OpenStack di produksi tidak memakai satu interface untuk segalanya. Layout standar dual-NIC memisahkan dua plane jaringan:

• NIC Manajemen: membawa traffic API, message queue, database, dan ssh antar node — segmen internal yang tidak diekspos.
• NIC Provider/Tenant: membawa traffic data instance — VLAN fisik dan overlay VXLAN/GRE menuju switch dan jaringan eksternal.

Node Controller / Compute
  ens192 → Management Network  (API, DB, RabbitMQ)
  ens224 → Provider/Tenant     (VLAN + VXLAN data plane)

Pemisahan ini bukan sekadar rapi — ia melindungi control plane dari lonjakan traffic data dan membuat troubleshooting lebih mudah. Di globals.yml, network_interface menunjuk NIC manajemen dan neutron_external_interface menunjuk NIC provider.

#Mengapa Tidak Cukup Satu NIC

Jika satu NIC memuat keduanya, lonjakan traffic instance bisa menghambat API dan database — cluster kalian akan terasa lambat bahkan mati dalam skenario terburuk. Pemisahan plane juga menjadi syarat untuk memakai DVR dan memudahkan kapasitas jaringan ditingkatkan secara independen.

#Provider Network (Flat & VLAN)

#Memetakan ke VLAN Fisik

Provider network menghubungkan neutron langsung ke jaringan fisik melalui segmentasi. Untuk VLAN, setiap provider network dipetakan ke sebuah VLAN ID di managed switch — konfigurasi ini adalah kontrak antara neutron dan tim network.

openstack network create --project admin --share \
  --provider-network-type vlan \
  --provider-physical-network physnet1 \
  --provider-segment 100 net-vlan100

openstack network create --provider-network-type vlan --provider-segment 100 memetakan network ke VLAN 100 di physical network physnet1. Di switch, port yang terhubung ke node harus di-set sebagai trunk untuk VLAN tersebut.

#Flat Network

Flat network memetakan network ke segmen tanpa tag VLAN — satu jaringan besar yang menembus ke segmen fisik tertentu. Pemakaian umum: jaringan eksternal tempat floating IP berada, atau jaringan infrastruktur yang tidak butuh segmentasi.

openstack network create --project admin --share \
  --provider-network-type flat \
  --provider-physical-network physnet2 external

Perintah openstack network create --provider-network-type flat di atas membuat network eksternal untuk floating IP — persis jaringan public di lab, tapi dengan pemetaan fisik yang jelas di produksi.

#Tenant VXLAN Overlay

#Isolasi Multi-Tenant dengan Tunneling

Untuk jaringan tenant, produksi memakai VXLAN sebagai overlay: setiap tenant network mendapat VNI (VXLAN Network Identifier) yang memisahkannya secara logika, dan paket tenant dibungkus dalam UDP menuju node tujuan — melewati infrastruktur fisik tanpa mengganggu jaringan lain.

openstack network show net-aplikasi -f value -c provider:network_type
openstack network show net-aplikasi -f value -c provider:segmentation_id

Output openstack network show net-aplikasi menampilkan tipe vxlan dan VNI-nya. Karena VXLAN mendukung hingga 16 juta VNI, kapasitas tenant hampir tak terbatas dibanding VLAN yang terbatas 4094.

#Perbedaan VLAN dan VXLAN di Produksi

VLAN dipakai untuk provider network yang butuh performa dan integrasi fisik. VXLAN dipakai untuk tenant network yang butuh isolasi dan skala. Keduanya hidup berdampingan: provider VLAN untuk eksternal, overlay VXLAN untuk internal — persis arsitektur yang akan kita rakit di episode 20.

#Distributed Virtual Router (DVR)

#Masalah Network Node Terpusat

Pada arsitektur klasik, semua routing dilakukan network node terpusat. Masalahnya: semua traffic antar tenant dan ke internet harus mampir ke sana — satu titik kemacetan dan satu titik kegagalan. Saat banyak compute node, bottleneck ini menjadi nyata.

#Mendistribusikan Routing ke Compute Node

DVR (Distributed Virtual Router) memindahkan fungsi routing ke setiap compute node. Instance bisa melakukan routing east-west (antar instance) dan north-south (ke internet) langsung di node tempatnya berjalan.

openstack network agent list --type l3 -f table

Output openstack network agent list --type l3 menampilkan agent L3 di setiap node — dengan DVR, kalian akan melihat dvrsnat dan agent l3 di compute node, bukan hanya network node. Di ml2_conf.ini dan l3_agent.ini, DVR diaktifkan dengan agent_mode = dvr_snat.

#Manfaat DVR

DVR memberi tiga keuntungan: tidak ada bottleneck routing karena fungsi terdistribusi, tidak ada SPOF karena routing tidak bergantung satu node, dan traffic east-west yang lebih pendek karena instance di compute node yang sama tidak perlu keluar menuju network node.

#Penutup

Episode 15 membawa networking kalian ke standar produksi: layout dual-NIC yang memisahkan plane manajemen dan data, provider network VLAN yang dipetakan eksplisit ke switch fisik, overlay VXLAN untuk isolasi tenant berskala besar, dan DVR yang mendistribusikan routing ke setiap compute node untuk menghilangkan bottleneck.

Inti yang harus dibawa pulang:

• Dual-NIC memisahkan traffic manajemen dari traffic data instance.
• Provider VLAN memetakan neutron ke VLAN fisik di managed switch.
• VXLAN memberi isolasi tenant dengan kapasitas VNI hampir tak terbatas.
• Network node terpusat adalah bottleneck dan SPOF.
• DVR mendistribusikan routing ke compute node.
• Produksi memakai VLAN untuk eksternal dan VXLAN untuk internal.

Di episode 16 selanjutnya kita akan membahas Production Storage: Ceph Integration (RBD, RGW, CephFS) — mengapa Ceph menjadi backend storage terbaik untuk OpenStack produksi, integrasi Glance, Cinder, dan Nova pada Ceph RBD, serta sizing dan deployment cluster Ceph minimal tiga node OSD, monitor, dan manager.