SEKSI-01 — Identifikasi Resource dan Rencana Awal¶
Ringkasan Eksekutif¶
Dokumen ini merancang penerapan OneKE (platform Kubernetes bawaan OpenNebula) di lingkungan
HyperCX 10.9.2 by Virtalus (cloud.ums.ac.id, zona UMS-ID-HCX1, group group_UMS) —
terpisah dari cluster OpenNebula lab lokal yang dibahas di Bab I–IX. Stack aplikasi
(HAProxy/Ingress, Redis, MySQL Galera Cluster) berjalan sebagai container/pod di atas OneKE.
Migrasi dilakukan bertahap (rolling): platform baru disiapkan & diuji berdampingan dengan VM hosting lama yang tetap berjalan, baru VM lama dinonaktifkan setelah penggantinya terbukti stabil — sehingga tidak perlu tambahan kuota dan tidak menimbulkan downtime pada layanan aktif.
Perubahan dari Rancangan Sebelumnya¶
| Aspek | Rancangan Awal | Revisi Saat Ini |
|---|---|---|
| Platform dasar | VM konvensional, tanpa Kubernetes | OneKE (Fase 1, Opsi D) |
| Basis data | MySQL Cluster NDB (node manajemen terpisah) | MySQL Galera Cluster (3 node setara, multi-master) |
| Tahapan migrasi | Fase 2 (HA Penuh + Longhorn) terpisah dari Fase 3 (migrasi VM) | Digabung jadi satu rencana rolling — tanpa tambahan kuota oneadmin |
| Storage | Belum dirinci | Alokasi SSD/HDD terperinci per komponen |
Platform: OneKE Fase 1 (Opsi D)¶
| Metrik | Nilai |
|---|---|
| Total vCPU (VNF+Master+Worker) | 9 |
| Total Memory | 44 GB |
| vCPU sisa kuota bebas | 9,75 |
| vCPU riil untuk pod aplikasi | ~5,4 |
Skema Opsi D: 1 VNF (1 vCPU/4GB), 1 master non-HA (2 vCPU/8GB), dan 4 worker custom (masing-masing 1,5 vCPU/8GB) — total 9 vCPU/44GB, seluruhnya berada dalam sisa kuota bebas (9,75 vCPU/102GB). Pool worker awal untuk pod adalah 6 vCPU/32GB, dengan kapasitas riil ~5–5,4 vCPU dan ~27–29GB setelah reservasi sistem Kubernetes.
Rancangan Arsitektur Container¶
Trafik dari jaringan publik diterima VNF/Gateway OneKE, diteruskan ke pod HAProxy/Ingress yang mendistribusikan trafik ke lapisan aplikasi. Aplikasi memanfaatkan pod Redis untuk cache, dan mengirim query database melalui pod ProxySQL yang meneruskannya ke salah satu dari 3 node MySQL Galera yang saling melakukan replikasi sinkron multi-master.
VNF / Gateway OneKE — HAProxy · DNS · NAT · Router (1 vCPU/4GB)
└─ Master (non-HA) — 2 vCPU / 8 GB
└─ Worker-1..4 — masing-masing 1,5 vCPU / 8 GB
pod: HAProxy/Ingress · Redis · ProxySQL · MySQL Galera (3 node)
Storage persisten dikelola Longhorn · 2 StorageClass (SSD / HDD) · replikasi 2×
| Tier | Alokasi | Peruntukan | Estimasi Awal |
|---|---|---|---|
| Datastore SSD | Sisa 2 TB (plafon pemakaian 1 TB) | MySQL Galera / DB — IOPS tinggi | ~300–350 GB terpakai awal |
| Datastore HDD | Sisa 3,8 TB (plafon pemakaian 2 TB) | Data aplikasi umum / arsip / backup | ~400–800 GB logis (3–4 layanan) |
Komponen dan Fungsi (Fase 1)¶
| Komponen | Fungsi | Replica | Request | Limit |
|---|---|---|---|---|
| HAProxy / Ingress Controller | Load balancer & entry point trafik aplikasi | 1 | 0,5 vCPU / 512MB | 1 vCPU / 1GB |
| Redis (Cache) | Cache standalone via Helm chart | 1 | 0,5 vCPU / 1GB | 1 vCPU / 2GB |
| ProxySQL (Query Router) | Router query di depan Galera — sembunyikan topologi cluster dari aplikasi, arahkan ke node sehat | 1 | 0,5 vCPU / 512MB | 1 vCPU / 1GB |
| MySQL Galera Cluster | 3 node setara (multi-master), replikasi sinkron, tanpa node manajemen terpisah, PVC persisten tier SSD | 3 | 0,5 vCPU / 1GB per node | 1 vCPU / 2GB per node |
Kondisi VM Hosting Saat Ini¶
| VM Hosting | Alokasi | Pemakaian Riil | Keterangan |
|---|---|---|---|
| Hosting-Farmasi | 512 GB | ~3,4 GB | Thin-provisioned, footprint kecil |
| Hosting-FEB | 512 GB | ~3,6 GB | Thin-provisioned, footprint kecil |
| Hosting FAI | — | — | Masih berukuran uji (footprint kecil) |
Jejak data riil per layanan saat ini masih kecil (beberapa GB) — sizing PVC awal dapat dimulai konservatif dan ditingkatkan seiring pertumbuhan data.
Rencana Migrasi Bertahap (Rolling)¶
Migrasi dijalankan tanpa downtime dan tanpa tambahan kuota, dengan menjalankan platform baru berdampingan dengan VM lama sampai terbukti stabil:
- Deploy OneKE & Stack Container — Deploy OneKE (Opsi D) dan stack container (HAProxy/Ingress, Redis, ProxySQL, MySQL Galera) pada worker, verifikasi kesehatan pod dan konektivitas internal.
- Muat & Sinkronkan Data — Muat salinan data dari layanan lama ke cluster Galera, sinkronkan, dan uji fungsional aplikasi terhadap endpoint baru secara paralel.
- Alihkan Trafik Bertahap — Alihkan trafik per layanan secara bertahap melalui VNF/Ingress; pantau performa dan konsistensi data.
- Nonaktifkan VM Lama — Setelah layanan baru terbukti stabil, nonaktifkan VM hosting lama dan bebaskan sumber dayanya.
Prinsip Rollback
Selama VM lama belum dinonaktifkan, pengalihan trafik dapat dikembalikan seketika ke VM lama bila ditemukan masalah, sehingga risiko migrasi rendah.
Storage Persisten (Revisi)¶
Storage persisten dikelola Longhorn di atas OneKE dengan pemisahan dua kelas (StorageClass) berbasis tier fisik: SSD untuk beban ber-IOPS tinggi dan HDD untuk data kapasitas.
Tier SSD — plafon 1 TB (sisa 2 TB)
| Komponen | Estimasi |
|---|---|
| MySQL Galera (3 node) | ~50 GB/node logis → ~150 GB |
| + replikasi Longhorn (2×) | ~300 GB fisik |
| + Redis (bila persisten) | ~10–20 GB |
| Total awal | ~300–350 GB |
Tier HDD — plafon 2 TB (sisa 3,8 TB)
| Komponen | Estimasi |
|---|---|
| Data aplikasi umum (3–4 layanan) | 100–200 GB/layanan |
| Total logis | ~400–800 GB |
| + cadangan backup/snapshot | — |
| Total (dgn replikasi) | Dalam plafon 2 TB |
Catatan fase migrasi
Selama migrasi rolling, PVC baru dialokasikan dari plafon di atas tanpa mengganggu VM lama. Pembebasan kapasitas VM lama (setelah dinonaktifkan) menjadi cadangan tambahan di luar plafon perencanaan ini.
Ringkasan total: perencanaan awal menargetkan ≤350 GB pada SSD dan ≤2 TB pada HDD, keduanya berada dalam sisa kapasitas fisik (SSD 2 TB, HDD 3,8 TB), dengan margin aman untuk pertumbuhan.
Rekomendasi dan Catatan Risiko¶
- Pantau ketat kesehatan cluster Galera (split-brain, quorum), kapasitas worker pool, performa, dan integrasi dengan Redis/MySQL Galera.
- Komunikasi dengan pihak fakultas terkait jadwal pengalihan trafik tetap disarankan meski migrasi dirancang tanpa downtime.
- Pastikan konfigurasi StorageClass Longhorn mengarahkan volume database (MySQL Galera) ke datastore SSD dan volume aplikasi umum ke datastore HDD, agar pemisahan kelas storage berjalan sesuai rancangan dan tidak tercampur secara default.
Dokumen internal Cloud UMS — dibuat untuk keperluan perencanaan. Diadaptasi dari studi pendahuluan rancangan OneKE. Sumber: sispada.ums.id/reports/oneke/