Perubahan Konfigurasi (Rekomendasi oneadmin)

A.1 — Ringkasan

Service final "K8S" (Service ID 4) berstatus RUNNING, dideploy 6 Juli 2026 pukul 00:13–00:19 (durasi ±5,5 menit, tanpa error pada log). Proses instantiate akhir dilakukan/dibantu langsung oleh oneadmin, sehingga sejumlah parameter berbeda dari rencana Opsi D dan dari form yang telah disiapkan sebelumnya pada dokumen oneke-prod-fase1.

A.2 — Tabel Perbandingan: Rencana Awal vs Konfigurasi Aktual

Parameter Rencana Awal Aktual (oneadmin)
Enable Traefik NO YES
MetalLB IP range 10.0.0.200 – 10.0.0.250 10.0.0.100 – 10.0.0.250
Enable WireGuard NO YES (5 peer, subnet 169.254.33.0/24, port 51820)
Storage role cardinality 0 (Longhorn di worker) 3 (storage node khusus)
Worker cardinality 4 4 (sama)
Disk tambahan di worker (SSD/HDD manual) Direncanakan Tidak ada — worker hanya disk OS 25GB
Disk data di storage node — vdb 10GB per node (default appliance)*

*Lihat catatan update di bagian bawah — kapasitas ini sudah berubah, lihat Errata.

A.3 — Spesifikasi Final Tiap Role

Role Jumlah VM vCPU/VM RAM/VM Disk IP
vnf 1 (VM 22) 1 4 GB 25GB (OS) 103.226.174.229 (eth0, publik) / 10.0.0.1 (eth1, gateway privat)
master 1 (VM 23) 2 8 GB 25GB (OS) 10.0.0.2
worker 4 (VM 24-27) 2 8 GB 25GB (OS) — tanpa disk tambahan 10.0.0.3 – 10.0.0.6
storage 3 (VM 28-30) 2 3 GB 25GB (OS) + 10GB (vdb, data Longhorn)* 10.0.0.7 – 10.0.0.9

Total realisasi: 17 vCPU / 53 GB (naik dari target rencana 9 vCPU / 44 GB, karena tambahan 3 VM storage khusus).

A.4 — Diagram Topologi Jaringan (Realisasi)

Internet
  │
  ▼
Public Network · VLAN 603 · 103.226.174.0/24 (bridge br1)
  │
  ▼
VNF / Gateway (VM 22) — eth0: 103.226.174.229 · eth1: 10.0.0.1
  HAProxy · DNS · NAT · Router · WireGuard (5 peer)
  │
  ▼
Private Network oneke_private_vnet · VLAN 604 · 10.0.0.0/24 (bridge onebr2)
  │
  ├─ Master (VM 23) — 10.0.0.2 · 2vCPU/8GB
  ├─ Worker ×4 (VM 24-27) — 10.0.0.3–.6 · 2vCPU/8GB masing-masing
  └─ Storage ×3 (VM 28-30) — 10.0.0.7–.9 · 2vCPU/3GB + vdb

Note

Storage cardinality semula direncanakan 0 (pola Longhorn-on-worker); realisasi oneadmin memakai 3 storage node khusus.

A.5 — Dampak terhadap Rencana Storage (lihat update di Errata)

Karena pola "storage-on-worker" tidak dipakai, kapasitas Longhorn saat pemeriksaan awal (6 Juli) hanya sekitar 3 × 10GB raw (~30GB), jauh di bawah target awal (~1TB tier SSD + ~2TB tier HDD). Disk 10GB per storage node adalah ukuran default appliance OneKE.

Pertanyaan terbuka saat itu: apakah alokasi 10GB per storage node ini bersifat sementara/uji coba, atau memang final untuk Fase-1; dan apakah masih diperlukan penambahan disk SSD/HDD sesuai rencana awal.

Update 8 Juli 2026

Disk vdb pada ketiga storage node sudah diperbesar menjadi 120GB/node (~360GB raw, ~120GB usable dengan replikasi 3×). Kekhawatiran kapasitas pada laporan 6 Juli ini sudah teratasi. Detail lengkap di Errata & Rekonsiliasi.

A.6 — Pembersihan VM Tidak Terkait OneKE & Laporan Kapasitas (17 Juli 2026)

Empat VM yang berjalan di cluster HyperCX yang sama namun tidak terhubung ke Service OneKE diidentifikasi dan dihapus (dieksekusi Admin via Sunstone, dibantu Claude Chrome plugin) untuk membebaskan kuota grup group_UMS. Sebelum eksekusi, setiap VM diverifikasi satu per satu (nama, IP) untuk memastikan tidak tertukar dengan node cluster OneKE yang kebetulan memakai angka serupa (mis. "VM8" vs node oneke-ip-10-0-0-8) — lihat proses verifikasi di Laporan Kerja.

VM ID Nama Keterangan
VM5 Debian 13 Test VM uji coba, tidak terhubung ke OneKE
VM6 Hosting-FEB VM hosting terpisah, tidak terhubung ke OneKE
VM8 vr-Gateway-0 VM virtual router, jaringan Public/Client Network (bukan jaringan privat OneKE)
VM9 Hosting-Farmasi VM hosting terpisah, tidak terhubung ke OneKE

Verifikasi pasca-penghapusan — cluster OneKE tidak terdampak

Service K8S tetap RUNNING, seluruh role (master 1, worker 4, storage 3, vnf 1) tetap RUNNING dengan cardinality yang sama seperti A.3. Jaringan privat oneke_private_vnet: 9/9 lease VM (ID 22-30) utuh, tidak ada gangguan. Total VM di sistem HyperCX turun dari 13 menjadi 9 (0 pending, 0 failed) — mengonfirmasi keempat VM yang dihapus memang di luar cluster OneKE.

Kuota Resource Tersisa (Group: group_UMS)

Resource Terpakai Kuota Persentase Sisa
CPU 8.75 16 54% 7.25
Memory 53 GB 128 GB 41% 75 GB

Rincian Konsumsi per Role

Role CPU/node (kuota) Memory/node Jumlah node Total CPU Total Memory
master 0.5 8 GB 1 0.5 8 GB
worker 0.5 8 GB 4 2.0 32 GB
storage 2.0 3 GB 3 6.0 9 GB
vnf 0.25 4 GB 1 0.25 4 GB

Kenapa angka CPU berbeda dari tabel A.3?

A.3 mencatat VCPU (jumlah core virtual yang diekspos ke guest — 2 vCPU/master, dst., total 17). Tabel di atas mencatat parameter CPU kuota OpenNebula (kapasitas host yang dijamin/direservasi, satuan berbeda dari VCPU). Keduanya sah, sekadar mengukur hal berbeda — bukan kontradiksi.

Kapasitas Jaringan

Jaringan Leases Terpakai Total Sisa
oneke_private_vnet 9 254 245 (longgar)
Public Network 5 16 11 (terbatas)
Client Network 1 200 199 (longgar)

Rekomendasi Ekspansi (Belum Dieksekusi)

  • Worker — paling efisien ditambah (0.5 CPU + 8GB/node kuota). Disarankan bertahap +4 node (biaya ~2 CPU + 32GB) untuk menjaga buffer kuota.
  • Master — saat ini hanya 1 node (belum HA). Disarankan menambah 2 node menjadi 3 (ganjil, quorum etcd), biaya ~1 CPU + 16GB.
  • VNF — saat ini 1 node. Bisa ditambah 1 lagi untuk redundansi load balancer, biaya kecil (~0.25 CPU + 4GB), namun perlu 1 IP publik tambahan (stok Public Network terbatas, sisa 11).
  • Storage — mahal secara CPU (2 CPU/node kuota). Disarankan hanya ditambah jika kapasitas disk benar-benar dibutuhkan, maksimal +1 node dulu.
  • Estimasi total jika semua rekomendasi di atas dijalankan (kecuali storage): tambahan ~3.25 CPU dan ~52GB memory kuota, menyisakan buffer aman ~4 CPU dan ~23GB memory.

Belum dieksekusi

Rekomendasi ekspansi di atas murni analisis kapasitas — tidak ada perubahan konfigurasi/resource yang dijalankan terhadap sistem HyperCX/OneKE per tanggal laporan.

Update 17 Juli 2026 — seluruh rekomendasi ekspansi telah dieksekusi

Lihat A.8 — Eksekusi Rekomendasi Ekspansi di bawah untuk rincian pelaksanaan dan status akhir.

A.7 — Rekomendasi Tindak Lanjut (per 6 Juli)

  • Verifikasi kapasitas storage aktual mencukupi kebutuhan Fase-1 (Galera + Redis + data aplikasi), atau ajukan penambahan disk. ✅ Selesai — lihat update A.5 di atas.
  • Verifikasi kubectl get nodes menunjukkan 1 master + 4 worker + 3 storage berstatus Ready.
  • Cek StorageClass Longhorn dan tag disk yang tersedia (karena tidak ada lagi pemisahan SSD/HDD eksplisit di sisi OpenNebula).
  • Tinjau kembali kebutuhan WireGuard tetap aktif; nonaktifkan jika tidak dipakai untuk mengurangi permukaan serangan.
  • Simpan token RKE2 dan kubeconfig (yang sudah diambil dari VM master) di lokasi aman terpisah — tidak disertakan dalam dokumen ini.

A.8 — Eksekusi Rekomendasi Ekspansi (17 Juli 2026)

Seluruh item pada A.6 — Rekomendasi Ekspansi dieksekusi pada tanggal yang sama (17 Juli 2026), oleh Admin via Sunstone (HyperCX-10.9.2, OpenNebula EE, zone UMS-ID-HCX1), dibantu Claude Chrome plugin. Setiap langkah dikonfirmasi langsung oleh Admin per tahap sebelum dijalankan.

State Awal → Akhir

Role Cardinality Awal Cardinality Akhir Perubahan
worker 4 8 +4
storage 3 4 +1
master 1 3 +2
vnf 1 2 +1

Rincian Tindakan

  • Worker (4 → 8): VM baru worker_4–7 (VM 31–34), IP 10.0.0.10–.13. Kuota ~2 CPU + 32 GB.
  • VNF (1 → 2): VM baru vnf_1 (VM 35), IP publik 103.226.174.225. Kuota ~0.25 CPU + 4 GB — redundansi load balancer. ⚠️ VRRP (layer IP) sudah aktif & teruji, tapi HAProxy belum reliable ikut failover — DNS tetap di IP statis, lihat detail di Remote Access B.11.
  • Master (1 → 3): VM baru master_1 (VM 36, 10.0.0.15) dan master_2 (VM 37, 10.0.0.16), untuk quorum etcd (HA control plane). Kuota ~1 CPU + 16 GB. Terverifikasi LCM RUNNING dengan konteks ONEAPP_K8S_* benar.
  • Storage (3 → 4): VM baru storage_3 (VM 38, 10.0.0.17). Kuota ~2 CPU + 3 GB. Disk: vda 25GB (OS) + vdb 10GB (Longhorn data). Terverifikasi LCM RUNNING dengan konteks OneKE benar.

Total tambahan kuota: ~5,25 CPU + ~55 GB memory. Service K8S terkonfirmasi tetap RUNNING pasca-eskalasi, seluruh role sesuai cardinality target di atas.

Disk vdb storage_3 (VM 38) belum seragam — masih 10GB, bukan 120GB

Scaling OneFlow membuat node storage baru dari template role asli (vdb 10GB default appliance), tidak mewarisi pembesaran disk manual ke 120GB yang sudah dilakukan pada tiga storage node lama (lihat Update 8 Juli dan Errata). Tindak lanjut: jika storage_3 dimaksudkan menambah kapasitas Longhorn, vdb VM 38 perlu diperbesar manual ke 120GB agar seragam dengan node lain; jika hanya untuk redundansi/replika, evaluasi apakah 10GB memadai.

Update 17 Juli 2026 (lanjutan) — disk longhorn-uploads (vdc) sudah menyusul ke storage_3

Node storage_3 (VM 38, 10.0.0.17) ternyata sudah memiliki disk tambahan vdc (503GB) ter-attach dari OpenNebula (mengikuti pola Penambahan Storage Uploads yang sebelumnya hanya berjalan di 3 node lama), namun belum diformat. Dieksekusi: format ext4 label longhorn-uploads, mount /var/lib/longhorn-uploads + entry /etc/fstab (defaults,nofail), lalu didaftarkan ke Longhorn Node CR sebagai disk uploads-disk (tag uploads) — persis pola 3 node lama. Hasil: Ready & Schedulable, ~503GB tersedia, otomatis ikut StorageClass longhorn-uploads yang sudah ada (diskSelector uploads), tanpa perlu ubah StorageClass. Detail lengkap di Penambahan Storage Uploads §Update.

Catatan: disk vdb (data Longhorn utama) storage_3 saat verifikasi ini tercatat 75GB — sudah diperbesar dari 10GB awal, namun masih belum 120GB seperti 3 node lama. Peringatan di atas soal parity vdb karenanya sebagian teratasi; vdc/longhorn-uploads sudah 100% setara.

Verifikasi Lanjutan (di luar scope Sunstone)

  • kubectl get nodes: pastikan 8 worker + 3 master + 4 storage = Ready.
  • Master HA: verifikasi kesehatan quorum etcd (etcdctl endpoint health).
  • VNF HA: verifikasi konfigurasi load balancer/VIP (HAProxy/keepalived).
  • Longhorn: cek StorageClass & kapasitas usable setelah node storage ke-4 join; perbesar vdb VM 38 bila perlu (lihat peringatan di atas). ✅ vdc/uploads-disk selesai — lihat update di atas; vdb 120GB masih tertunda.
  • Pantau kuota group group_UMS pasca-ekspansi.

Dokumen internal Cloud UMS — dibuat otomatis sebagai catatan lanjutan pasca-instantiasi Service OneKE (Service ID 4, "K8S"). Universitas Muhammadiyah Surakarta — 2026. Sumber: sispada.ums.id/reports/oneke/