Standar Penamaan Infrastruktur & Workload#

0. Ringkasan Perubahan dari Dua Dokumen Sumber#

Dokumen ini menggabungkan dua sumber yang selama ini berdiri sendiri:

Keputusan penggabungan yang perlu di-approve (rasional ada di section terkait):

1. Tujuan#

Menetapkan aturan penamaan tunggal untuk seluruh objek infrastruktur dan workload agar:

• Identitas, kepemilikan entitas, lokasi, environment, dan keanggotaan cluster terbaca langsung dari nama — tanpa perlu membuka CMDB saat menangani insiden
• Tidak terjadi tabrakan nama saat cluster, site, atau entitas baru ditambahkan
• Nama tetap valid untuk DNS, NetBIOS, dan device-mapper, serta konsisten di monitoring, firewall rule, dan dokumen audit
• Aturan tidak berubah saat teknologi atau arsitektur berubah

2. Prinsip Dasar#

1. Nama menyatakan identitas dan lokasi, bukan atribut yang berubah. Status fisik/virtual, arsitektur (HCI vs 3-tier), fungsi bisnis, dan kapasitas disimpan sebagai kolom di IP Plan/CMDB — tidak di-hardcode ke dalam nama. VM bisa di-P2V, cluster 3-tier bisa jadi HCI, fungsi cluster bisa bergeser.

2. Satu token, satu arti. Tidak boleh ada dua token yang menyatakan hal sama (hci + ntnx + cluster dalam satu nama).

3. Konsisten lintas platform. Pola yang sama berlaku untuk Nutanix, Proxmox, Incus, dan Kubernetes.

4. DNS-safe. Hanya huruf kecil, angka, dan hyphen. Tanpa underscore, tanpa titik, tanpa spasi. Token yang di dokumen lama ditulis kapital (T1, C01, TRIM) ditulis huruf kecil di nama objek.

5. Suffix di belakang sequence. -01-ipmi, bukan -ipmi-01 — agar seluruh record milik satu node berurutan saat di-sort.

6. Entitas pemilik ada di depan. Infrastruktur dipakai bersama oleh lebih dari satu badan hukum (TRIM dan TRAM). Prefix company menjaga pemisahan itu tetap terbaca di log, firewall rule, dan tagihan — dan mempertahankan kompatibilitas dengan ribuan nama yang sudah terpasang hari ini.

3. Struktur Nama#

Urutan segmen selalu sama di semua pola: company → class → environment → site → identitas.

Catatan K2. Beberapa nama lama memakai urutan site → env (trim-vm-t1-stg-aml-smart). Urutan yang benar adalah env → site (trim-vm-stg-t1-aml-smart), karena environment adalah pemisah paling kasar dan paling sering dijadikan filter/ACL. Sorting nama akan mengelompokkan environment dulu, baru lokasi.

3.1 Objek level node (fisik & infrastruktur)#

<company>-<class>-<env>-<site>-<platform><cluster-seq>-<node-seq>[-<suffix>]

Contoh: trim-phcs-prd-t1-ntnx01-03-ipmi

3.2 Objek level cluster#

<company>-cl-<env>-<site>-<platform><cluster-seq>[-<suffix>]

Contoh: trim-cl-prd-t1-ntnx01-vip

Prefix cl- bersifat netral terhadap arsitektur — berlaku untuk HCI maupun 3-tier.

3.3 Objek workload (VM / container aplikasi)#

<company>-<class>-<env>-<site>-<app>[-<sub>][-<seq>]

Contoh: trim-vm-prd-t1-payment-gw, trim-vm-stg-t1-aml-smart, trim-vm-prd-t1-nats-trima-01

Ini adalah format lama trim-vm-{Environment}-{Data_Center_Codes}-{Name_Server} yang dipertahankan apa adanya — hanya {Name_Server} yang sekarang punya aturan turunan di §8.

4. Kamus Token#

4.1 Company (prefix wajib)#

4.2 Class#

4.3 Environment#

shr dipakai untuk objek yang melayani semua environment sekaligus — host cluster, NTP master, image template. Salah kaprah yang harus dihindari: host shr boleh menjalankan VM prd; environment host tidak menular ke workload di atasnya.

4.4 Site#

Data center & cloud:

Branch:

Site code wajib ada di semua nama. Tanpa itu, nama di DC dan DRC akan identik. Ruang kode tidak bertabrakan karena huruf awal berbeda: t* = DC, g* = cloud, b* = kantor pusat, c* = cabang.

Tentang tx (K6). Token ini sudah dipakai di lapangan (trim-vm-shr-tx-template-win2022) tetapi tidak pernah didaftarkan. Diresmikan sebatas untuk template dan image — objek yang identitasnya tidak boleh terikat lokasi karena akan di-copy ke site lain. Instance hasil clone wajib memakai site code sebenarnya.

4.5 Platform#

4.6 Suffix#

4.7 Hardware Code — Dipensiunkan dari Nama (K3)#

Dokumen lama memakai token comp (Computes Server), stor (Storages Server), nas (Storages NAS), dan hci (HCI Nutanix / Proxmox CEPH) di dalam nama.

Empat token ini tidak lagi dipakai di nama objek. Alasannya:

1. hci melanggar Prinsip 1 — arsitektur bisa berubah. Cluster 3-tier yang di-upgrade jadi HCI akan menyisakan nama yang berbohong, dan rename cluster produksi bukan operasi murah (§13).
2. hci juga melanggar Prinsip 2 — informasinya sudah dibawa token platform. ntnx sudah pasti HCI; pve + CEPH sudah pasti HCI. Menulis keduanya adalah duplikasi yang cepat atau lambat jadi tidak sinkron.
3. comp vs stor bukan atribut identitas melainkan peran, dan peran adalah kolom yang bisa di-query, bukan string yang perlu di-parse. Node compute yang dipasangi disk lokal jadi storage tidak boleh perlu di-rename.
4. nas sudah tercakup class sto.

Nilainya tetap disimpan — sebagai kolom Hardware Role di IP Plan/CMDB dengan nilai: COMPUTE, STORAGE, NAS, HCI, NETWORK.

Pemetaan:

5. Kamus Kind / Function#

Nilai yang diizinkan pada kolom Kind Function di IP Plan:

Catatan penting:

• VIP dan DSIP adalah dua objek berbeda dengan IP berbeda. VIP untuk akses Prism, DSIP untuk iSCSI. Jangan tertukar — kesalahan ini menurun ke firewall rule.
• CLUSTER tidak memiliki IP tersendiri. Field Cluster External IP di Prism adalah VIP. Isi kolom IP dengan -.
• Gunakan DSIP, bukan DISP. DISP bukan istilah Nutanix.

6. Kolom Wajib di IP Plan / CMDB#

Karena banyak atribut sengaja dikeluarkan dari nama, kolom berikut menjadi wajib:

Kolom Label berisi hostname node induk — kunci pengelompokan agar seluruh record satu node (host, IPMI, CVM, backplane) bisa ditarik dengan satu filter meski prefix-nya berbeda.

7. Contoh Lengkap — Cluster Nutanix#

Cluster: trim-cl-prd-t1-ntnx01 · Site T1 (Bittera) · Production · 4 node

Nama terpanjang: 31 karakter — aman terhadap batas label DNS 63 karakter (§11.1).

8. Contoh — Platform Lain#

8.1 Proxmox VE (3-tier, shared storage)#

trim-cl-prd-t1-pve01                CLUSTER
trim-phcs-prd-t1-pve01-01 … -04     PVE
trim-phcs-prd-t1-pve01-01-ipmi      IPMI/OOB

Objek tambahan yang wajib didaftarkan:

8.2 Incus#

trim-cl-shr-t1-inc01                CLUSTER
trim-phcs-shr-t1-inc01-01 … -04     INCUS
trim-phcs-shr-t1-inc01-01-ipmi      IPMI/OOB

Tidak ada CVM. Objek storage didaftarkan terpisah:

Dua portal didaftarkan sebagai baris terpisah agar keberadaan dua path multipath terlihat eksplisit dan terjaga. Jika saat ini hanya ada satu path (mis. storage HA active/passive dengan satu floating IP), baris kedua tetap didaftarkan dengan status not-implemented — supaya kekurangan redundansi terlihat di dokumen, bukan hanya di kepala orang yang memasangnya.

Objek internal Incus (bukan hostname, tapi tetap perlu konsisten):

Nama pool dan project ikut masuk ke nama device-mapper. Jangan panjangkan tanpa perlu — lihat §11.3.

8.3 Kubernetes#

trim-cl-prd-t1-k8s01                CLUSTER
trim-vm-prd-t1-k8s01-cp01           control plane
trim-vm-prd-t1-k8s01-w01            worker
trim-cl-prd-t1-k8s01-vip            API server VIP

9. Penamaan Workload#

9.1 Pola#

<company>-<class>-<env>-<site>-<app>[-<sub>][-<seq>]

Contoh yang sah:

9.2 Yang tidak boleh masuk nama workload#

• Nama vendor atau nama PIC (-altros, -pakhadi) — orang dan vendor berganti, VM tidak
• Nomor tiket (-devops5249) — tiket ada di kolom CMDB
• Ukuran atau spesifikasi (-16gb, -8vcpu) — berubah saat resize
• Kata server, vm, new, test, temp, old, backup sebagai penanda status
• Tanggal

9.3 VM Windows domain-joined (K7)#

Ini konflik nyata dan perlu diperlakukan eksplisit: prefix trim-vm-prd-t1- saja sudah 15 karakter, yaitu seluruh jatah NetBIOS. Artinya tidak ada nama workload sesuai standar ini yang muat sebagai computer name Windows.

Aturannya:

1. Nama objek di hypervisor (Incus instance / Nutanix VM name) memakai pola penuh §9.1.

2. Computer name di dalam OS Windows memakai pola pendek:

   <env>-<site>-<app><seq>

   Contoh: prd-t1-h2hprm01 (15 karakter), stg-t1-mssqls21 (15 karakter).

3. Keduanya wajib dicatat di CMDB: kolom Hostname untuk nama panjang, kolom OS Hostname untuk nama pendek.

4. DNS: A record dibuat untuk kedua nama, menunjuk IP yang sama (§10).

VM Linux tidak terkena batasan ini — hostname OS mengikuti nama panjang apa adanya.

10. DNS#

• Semua objek mendapat A record dengan nama formal sesuai standar ini
• VM Windows domain-joined mendapat A record tambahan untuk nama pendek NetBIOS-nya (biasanya didaftarkan otomatis oleh AD — verifikasi, jangan asumsikan)
• Untuk endpoint yang sering diakses manusia, tambahkan CNAME yang mudah diingat:

prism-t1.trimegah.co.id   CNAME   trim-cl-prd-t1-ntnx01-vip
incus-t1.trimegah.co.id   CNAME   trim-phcs-shr-t1-inc01-01

A record tetap formal untuk keperluan audit; CNAME untuk pemakaian sehari-hari.

• Reverse (PTR) record wajib dibuat untuk seluruh IP host, CVM, dan IPMI.

11. Aturan Alokasi IP#

1. VIP dan DSIP wajib berada di subnet yang sama dengan CVM eth0. Tidak boleh di subnet terpisah.
2. Backplane wajib subnet + VLAN sendiri, L2 only — tanpa SVI, tanpa gateway, tanpa routing. Isi kolom Gateway dengan none.
3. IPMI wajib subnet + VLAN terpisah dari management. Akses dibatasi hanya dari jump host / PAW. Gateway OOB harus dilayani perangkat fisik yang independen dari cluster — jika tidak, akses OOB hilang tepat saat cluster down.
4. Setiap cluster mendapat blok subnet sendiri. Cluster kedua tidak melanjutkan nomor di subnet cluster pertama — agar ACL dan log dapat membedakan cluster, dan ruang ekspansi tiap cluster tetap utuh.
5. Sisakan ruang ekspansi minimal 6 alamat per blok (host, CVM) untuk penambahan node.

Contoh alokasi dua cluster di site yang sama:

12. Batasan Teknis#

12.1 Batas umum#

Verifikasi penerimaan nama cluster oleh platform sebelum diterapkan:

ncli cluster edit-params new-name=<nama>

12.2 Nama instance di Incus dengan storage lvmcluster#

Batas yang paling mudah dilanggar dan paling tidak terduga bukan DNS, melainkan device-mapper (DM_NAME_LEN = 128, praktis 127 karakter usable).

Incus menyusun nama LV sebagai gabungan pool + project + instance + snapshot, lalu device-mapper melakukan escaping - → --. Karena Incus sudah melakukan escaping sekali, setiap hyphen di nama instance muncul sebagai 4 karakter di nama DM.

Bentuk nyata yang gagal di lingkungan kita:

vg--qnap--hdd--01-virtual--machines_Templates_trim----vm----shr----tx----template----win2022--trim----vm----shr----tx----template----win2022.block

→ lvchange --activate sy gagal exit 5, “Name too long. Failed to set device name”.

Rumus anggaran (asumsi VG vg-qnap-hdd-01 dan project Templates):

46 + (L + 3h) + 2 + (S + 3hs) + 6  ≤  127

dengan L/h = panjang & jumlah hyphen nama instance, S/hs = panjang & jumlah hyphen nama snapshot. Konstanta 46 berubah bila nama VG, pool, atau project berubah.

Aturan praktis yang diambil dari rumus di atas:

Penyebab kegagalan di contoh di atas bukan nama instance-nya, melainkan nama snapshot yang dibuat sama persis dengan nama instance — dua kali 46 karakter. Snapshot dinamai snap01, pre-patch (tanpa hyphen: prepatch), atau tanggal 20260803, bukan diulang dari nama instance.

12.3 Ringkasan batas efektif per platform#

13. Migrasi dari Konvensi Lama (K8)#

Nama produksi yang sudah berjalan tidak di-rename massal. Rename menyentuh sertifikat TLS, konfigurasi monitoring, Protection Domain di sisi DR, referensi di support case, dan — untuk Incus — nama LV di storage pool.

Yang dilakukan:

1. Setiap objek yang tidak sesuai didaftarkan di CMDB dengan Status = grandfathered dan kolom Target Name berisi nama sesuai standar ini.
2. Rename hanya dilakukan pada momen yang sudah menyentuh objek itu: rebuild, migrasi cluster, upgrade besar, atau decommission-and-replace.
3. Objek baru wajib sesuai standar ini sejak hari approval.

Pemetaan objek existing:

14. Aturan Perubahan#

• Nama tidak boleh diubah setelah objek masuk produksi tanpa change request.
• Penambahan token baru ke kamus (§4 dan §5) memerlukan pembaruan dokumen ini beserta versinya.
• Penambahan site code atau company code baru memerlukan approval IT Manager, karena berdampak ke ACL, DNS zone, dan struktur IP plan.
• Setiap cluster baru wajib didaftarkan di IP Plan sebelum imaging dimulai.
• Setiap VM/container baru wajib didaftarkan di CMDB sebelum di-launch.

15. Checklist Verifikasi Sebelum Deploy#

Infrastruktur:

• Semua hostname mengikuti pola §3
• Prefix company (trim/tram) ada di setiap nama
• Site code ada di setiap nama, huruf kecil
• Urutan segmen env → site (bukan site → env)
• Nomor cluster (ntnx01, pve01, inc01) ada di nama node
• Tidak ada token redundan (hci + ntnx, cl + cluster, computes + inc)
• Kolom Kind sesuai kamus §5, kolom Hardware Role terisi
• VIP dan DSIP tidak tertukar, dan keduanya punya IP
• Baris CLUSTER tidak memiliki IP
• Blok backplane sudah didaftarkan dengan gateway none
• Kolom Label terisi hostname node induk untuk seluruh record turunan
• Subnet cluster tidak tumpang tindih dengan cluster lain
• A record dan PTR sudah dibuat

Workload:

• Nama tidak memuat vendor, PIC, tiket, spesifikasi, atau tanggal
• Nomor urut (-01) ada bila instance akan lebih dari satu
• VM Windows: OS Hostname pendek ≤ 15 karakter sudah ditentukan dan dicatat
• Incus lvmcluster: nama instance ≤ 32 karakter & ≤ 6 hyphen
• Incus: rencana nama snapshot ≤ 12 karakter tanpa hyphen
• Sudah terdaftar di CMDB sebelum launch

16. Persetujuan#

Riwayat Revisi#