Belajar Active Directory - Active Directory Performance Tuning

#Pendahuluan

Di episode 23 kita membangun sistem security monitoring: menangkap anomali, memberi peringatan saat akun terkunci massal, dan mendeteksi serangan lewat event log serta SIEM. Monitoring adalah radar — ia memberitahu kalian ada masalah bahkan sebelum kerusakan meluas. Episode 24 ini menjawab pertanyaan berikutnya: bagaimana memastikan radar itu tidak sering berbunyi karena infrastruktur yang sebenarnya tidak sehat?

Performance tuning di Active Directory adalah pekerjaan pencegahan, bukan reaksi. Tujuannya sederhana: DC yang melayani logon, query LDAP, dan replikasi tetap cepat di bawah beban normal maupun lonjakan. Performa AD jarang menjadi masalah karena satu penyebab tunggal — hampir selalu kombinasi hardware yang kurang, query yang boros, dan database yang membesar tanpa perawatan. Mari kita bedah satu per satu.

#Baseline: Ukur Dulu Sebelum Menyetel

Aturan pertama tuning: jangan menyetel apa pun tanpa baseline. Baseline adalah foto kondisi "sehat" infrastruktur kalian — angka-angka yang diambil saat semuanya berjalan normal. Tanpa baseline, kalian tidak punya pembanding untuk menilai apakah sebuah perubahan memperbaiki atau justru merusak.

Windows menyediakan kumpulan counter khusus AD di bawah objek NTDS. Lihat counter yang tersedia, lalu rekam sampelnya secara berkala ke file baseline:

Get-Counter -ListSet "NTDS*" -ComputerName dc01.corp.local |
    Select-Object -ExpandProperty PathsWithInstances

Get-Counter -SampleInterval 15 -MaxSamples 60 -Counter "\\DC01\NTDS\*" |
    Export-Csv -Path "C:\Data\baseline-ntds.csv" -NoTypeInformation

Counter yang paling informatif untuk dipantau setiap hari:

Bandingkan angka hari ini dengan baseline: lonjakan tajam LDAP Searches yang tidak diiringi lonjakan user adalah tanda query boros — topik yang akan kita bedah sebentar lagi.

#Sizing DC: CPU, RAM, dan Disk

Baseline memberitahu beban aktual; dari situ kalian menyetel hardware. Tidak ada formula ajaib, tapi arahnya jelas:

• CPU. DC bukan server komputasi berat; bebannya adalah autentikasi, enkripsi Kerberos, dan pemrosesan query LDAP. Mulai dari 2 vCPU untuk DC kecil, lalu naik jika baseline menunjukkan % Processor Time konsisten di atas 70-80%.
• RAM. AD menyimpan halaman database di memori — RAM DC adalah cache untuk ntds.dit. Semakin besar database, semakin besar RAM yang berguna. Aturan praktis kasar: 2-4 GB per 10.000 objek, ditambah ruang untuk Windows dan proses lain. Di lab 4 GB cukup; di produksi 16 GB ke atas bukan pemborosan.
• Disk. Gunakan SSD, terutama untuk volume database dan log. ntds.dit dibaca saat query tidak tertutup cache — disk yang lambat langsung terasa sebagai latensi query. Letakkan database dan log di volume terpisah dari sistem operasi, dan pisahkan dari SYSVOL bila trafiknya besar.
• Jaringan. Jaga latensi ke klien dan antar-DC. Latensi tinggi antar-situs memperlambat replikasi dan pencarian GC lintas-situs — titik penentu di episode 27 nanti.

RAM adalah investasi termudah: tidak ada konfigurasi, hanya menambah kapasitas cache. Kalau baseline menunjukkan query LDAP lambat tapi CPU rendah, hampir selalu RAM yang kurang — bukan CPU.

#Capacity Planning sebagai Sikap, Bukan Proyek

Baseline bukan kegiatan sekali jalan. Saat melakukan capacity planning, pertimbangkan empat kurva pertumbuhan:

1. Jumlah objek — setiap tambahan user, komputer, dan group memperbesar database dan cache yang dibutuhkan.
2. Trafik replikasi — penambahan DC dan situs menambah antrean replikasi yang harus ditanggung bridgehead.
3. Beban autentikasi — jam kerja, growth karyawan, dan adopsi SSO mengubah puncak Kerberos per detik.
4. Query Global Catalog — aplikasi yang mencari lintas-domain membebani GC, bukan DC biasa.

Tinjau ulang baseline setiap kuartal dan bandingkan trennya. Tuning yang baik membuat lonjakan beban terasa biasa saja.

#Optimasi Query LDAP

Query LDAP adalah bahasa tanya AD: aplikasi, Group Policy, dan perintah PowerShell berbicara dengannya. Query yang ditulis malas bisa menelan sumber daya DC tanpa disadari siapa pun.

#Gunakan Atribut yang Terindeks

AD memelihara indeks untuk atribut tertentu. Query yang memfilter atribut terindeks diselesaikan lewat indeks; yang tidak, memaksa pemindaian seluruh database. Atribut seperti samAccountName, objectSid, userPrincipalName, dan memberOf sudah terindeks. Untuk atribut kustom yang sering difilter, tandai sebagai indeks lewat skema:

Get-ADObject -SearchBase (Get-ADRootDSE).SchemaNamingContext -Filter "Name -eq 'extensionAttribute5'" |
    Set-ADObject -Replace @{ searchFlags = 1 }

#Hindari Wildcard di Awal Pola

Filter seperti (cn=*santoso*) memaksa AD memeriksa setiap entri — indeks tidak bisa membantu karena polanya tidak diawali karakter tetap. Jika memungkinkan, gunakan awalan tegas: (cn=santoso*) tetap bisa memanfaatkan indeks.

#Pantau Event 1644

Windows mencatat query mahal (expensive) dan tidak efisien (inefficient) lewat event 1644 pada log Directory Service. Aktifkan dengan menyetel nilai diagnostik 15 Field Engineering ke 5 pada registry di bawah HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics, lalu setel ambang Search Time Limit Exceeded pada key yang sama. Setelah itu, event 1644 memberitahu persis: siapa pengirim query, filter apa, dan berapa lama ia berjalan. Ini umpan terbaik untuk menemukan query boros di lapangan.

#Setel LDAP Policies

Ambang bawaan LDAP dirancang konservatif: MaxPageSize 1000 objek per halaman dan MaxQueryDuration 120 detik. Aplikasi yang menarik data besar bisa tersedak oleh MaxPageSize default. Setel lewat ntdsutil:

ntdsutil
ldap policies
set MaxPageSize to 2000
set MaxQueryDuration to 60
show values
quit
quit

Perubahan langsung berlaku. Hati-hati menaikkan MaxQueryDuration: satu query rakus yang tadinya dibunuh di menit kedua kini boleh makan sumber daya lebih lama — selalu imbangi dengan pemantauan event 1644. Perhatikan juga MaxConnections dan MaxDatagramRecv yang membatasi koneksi bersamaan dan paket UDP per detik; angka default-nya aman untuk mayoritas lingkungan.

#Defragmentasi Database

ntds.dit tumbuh sepanjang hidup DC. Penghapusan objek menyisakan ruang kosong di halaman database. Ada dua jenis defragmentasi:

• Online defragmentation berjalan otomatis di latar belakang (sekitar tiap 12 jam) dan menjalankan garbage collection. Ia merapikan ruang kosong agar bisa dipakai kembali, tetapi tidak mengecilkan ukuran file di disk.
• Offline defragmentation menulis ulang database ke file baru di lokasi kosong, menghasilkan ntds.dit baru yang lebih kecil. Wajib dilakukan saat DC sedang tidak melayani (misal dalam mode DSRM) dan membutuhkan ntdsutil.

Prosedur offline defrag:

ntdsutil
activate instance ntds
files
compact to C:\compact
quit
quit

Hasil kompresi ditulis ke C:\compact\ntds.dit. Sebelum menimpa file asli: matikan DC (bukan sekadar restart), pindahkan database lama sebagai cadangan, salin file baru ke lokasi asli, lalu jalankan dcdiag untuk memastikan database valid. Ukur hasilnya dengan membandingkan ukuran file sebelum dan sesudah:

ntdsutil
activate instance ntds
files
info
quit
quit

#Placement Global Catalog dan Memori

Global Catalog (GC) adalah DC yang menyimpan salinan sebagian atribut seluruh domain di forest. Saat klien atau aplikasi menanyakan objek lintas-domain (termasuk saat logon), GC-lah yang menjawab. Dua kesalahan umum:

1. Tidak ada GC di satu situs. Semua query lintas-situs memutar lewat WAN — lambat dan rawan timeout.
2. Terlalu banyak GC untuk ukuran kecil. GC menyimpan data lintas-forest; setiap GC tambahan menambah trafik replikasi global. Di situs besar, seimbangkan: satu GC per situs sebagai standar, dua atau lebih hanya untuk redundancy.

Saat merencanakan RAM, ingat: DC yang juga GC harus menampung cache untuk dataset forest, bukan hanya domain sendiri. Konsekuensinya, aturan 2-4 GB per 10.000 objek berlaku pada total objek forest bagi sebuah GC.

#Penutup

Di episode 24 ini kalian belajar bahwa performa AD adalah disiplin pengukuran: baseline sebagai pembanding, sizing hardware berdasarkan data bukan tebakan, optimasi query lewat indeks, pola filter, event 1644, dan LDAP policies, defragmentasi database online maupun offline dengan ntdsutil, serta placement GC dan RAM cache yang menyatukan semuanya.

Poin kunci:

• Tuning tanpa baseline adalah menebak — ukur dulu, baru ubah.
• RAM adalah cache AD; SSD mempercepat query yang lolos cache.
• Query harus memfilter atribut terindeks; waspadai wildcard di awal pola.
• Event 1644 adalah detektif untuk menemukan query boros.
• Compact offline mengecilkan file database; selalu backup dulu.

Setelah infrastruktur berjalan cepat, pertanyaan logis berikutnya: bagaimana memindahkan semuanya ke struktur baru tanpa menghentikan produksi? Di episode 25 selanjutnya kita bedah Active Directory Migration: inventarisasi dan perencanaan, ADMT, SID History, migrasi profil, hingga cutover dan rollback. Sampai jumpa!