Lokasi:
Srengseng Sawah, Jagakarsa Jakarta Selatan
Migrasi server tanpa downtime membutuhkan audit aplikasi, sinkronisasi data bertahap, pengujian server tujuan, rollback plan, dan proses cutover yang terjadwal. Untuk virtual machine tertentu, perpindahan bahkan dapat dilakukan melalui live migration tanpa gangguan yang terasa oleh pengguna. Namun, migrasi aplikasi fisik, database, atau file server biasanya tetap membutuhkan periode cutover singkat agar perubahan data tidak terjadi pada dua server secara bersamaan.
Karena itu, istilah tanpa downtime sebaiknya dipahami sebagai upaya menjaga layanan tetap tersedia atau menekan gangguan hingga seminimal mungkin. Hasil akhirnya bergantung pada jenis workload, platform virtualisasi, kemampuan aplikasi, koneksi jaringan, kapasitas storage, dan metode migrasi yang digunakan.
Microsoft Hyper-V menyediakan live migration untuk memindahkan virtual machine yang masih berjalan dari satu host ke host lain tanpa downtime yang terlihat. Sementara itu, Storage Migration Service dapat menginventarisasi file dan konfigurasi, mentransfer data, lalu memindahkan identitas jaringan server lama ke server baru agar pengguna tidak perlu mengubah path atau link akses.
Migrasi server umumnya dilakukan ketika infrastruktur lama sudah tidak mampu mendukung kebutuhan bisnis. Performa aplikasi mulai menurun, kapasitas storage menipis, atau perangkat tidak lagi memperoleh dukungan vendor.
Beberapa alasan perusahaan perlu memindahkan server antara lain:
Migrasi juga dapat dilakukan sebagai bagian dari konsolidasi. Sebagai contoh, lima server fisik dengan pemakaian rendah dapat dipindahkan menjadi beberapa virtual machine pada dua atau tiga host virtualisasi.
Perusahaan juga dapat melakukan migrasi untuk mengganti file server lama. Storage Migration Service dari Microsoft dirancang untuk menginventarisasi server serta data, memindahkan file, file share, dan konfigurasi keamanan, lalu secara opsional memindahkan identitas server sumber ke perangkat tujuan.
Namun, migrasi tidak sebaiknya menunggu sampai perangkat benar-benar rusak. Server yang masih aktif tetapi tidak stabil dapat meningkatkan risiko kegagalan saat proses penyalinan data.
Waktu terbaik melakukan migrasi adalah ketika perusahaan masih memiliki kontrol terhadap server sumber, backup masih berfungsi, dan aplikasi masih dapat diuji sebelum perangkat lama dinonaktifkan.
Kesalahan migrasi sering terjadi karena tim hanya menyalin file dan aplikasi utama, tetapi melupakan dependensi yang dibutuhkan sistem.
Sebelum proses dimulai, buat inventaris lengkap yang mencakup:
Audit perlu dilakukan bersama pemilik aplikasi. Tim infrastruktur mungkin mengetahui server dan sistem operasinya, tetapi belum tentu mengetahui seluruh proses bisnis yang bergantung pada aplikasi tersebut.
Sebagai contoh, server ERP mungkin terhubung dengan database, sistem absensi, email, printer, aplikasi pajak, dan server file. Jika hanya ERP serta database yang dipindahkan, sebagian proses dapat tetap gagal setelah cutover.
Dokumentasikan pula service account yang digunakan. Banyak aplikasi berjalan menggunakan akun domain atau akun lokal tertentu. Password yang tidak diketahui atau hak akses yang tidak disiapkan pada server tujuan dapat membuat service gagal dijalankan.
Untuk database, catat:
Selain itu, periksa kompatibilitas software dengan sistem operasi tujuan. Aplikasi lama mungkin belum mendukung versi Windows Server, Linux, database, atau hypervisor terbaru.
Audit sebaiknya menghasilkan dokumen dependency map. Dari dokumen tersebut, tim dapat melihat urutan migrasi. Database mungkin harus disiapkan lebih dahulu sebelum application server, sedangkan DNS dan akses pengguna baru diubah setelah pengujian selesai.
Metode migrasi perlu disesuaikan dengan bentuk server sumber dan tujuan.
Physical to virtual atau P2V adalah proses mengubah server fisik menjadi virtual machine. Sistem operasi, aplikasi, konfigurasi, dan data dari perangkat lama dikonversi agar dapat dijalankan pada hypervisor.
P2V cocok ketika perusahaan ingin:
Proxmox menyediakan panduan migrasi dari berbagai sumber menuju Proxmox VE, termasuk teknik P2V untuk mengubah mesin fisik menjadi VM.
Namun, hasil P2V perlu dibersihkan. Driver hardware lama, software monitoring vendor, network adapter tersembunyi, dan utility RAID mungkin masih berada dalam sistem operasi hasil konversi.
Perusahaan juga perlu memastikan lisensi sistem operasi dan aplikasi tetap valid setelah dipindahkan ke hardware virtual.
Virtual-to-virtual atau V2V digunakan ketika virtual machine dipindahkan dari satu hypervisor ke hypervisor lain, misalnya dari VMware ke Proxmox atau dari platform lama ke Hyper-V.
Proses V2V dapat mencakup:
Jika VM dipindahkan di antara host dalam platform yang sama, perusahaan dapat menggunakan live migration apabila persyaratan hardware, jaringan, authentication, dan kompatibilitas terpenuhi.
Hyper-V memungkinkan VM yang sedang berjalan dipindahkan antarsistem tanpa downtime yang terlihat, termasuk perpindahan storage dalam skenario tertentu. Namun, perbedaan versi prosesor, konfigurasi authentication, network, dan hardware dapat menyebabkan migrasi gagal jika tidak diuji terlebih dahulu.
Untuk Proxmox, shared storage memungkinkan live migration karena seluruh node telah memiliki akses ke disk VM yang sama. Jika storage tidak dibagi, disk perlu ikut ditransfer melalui jaringan sehingga durasi dan bebannya lebih besar.
Tidak semua server sebaiknya dikonversi langsung. Server yang sudah penuh masalah, menggunakan sistem operasi sangat lama, atau memiliki konfigurasi tidak terdokumentasi terkadang lebih aman dibangun ulang.
Pada metode ini, perusahaan menyiapkan server baru, menginstal aplikasi, memindahkan konfigurasi, lalu mengimpor data.
Metode tersebut membutuhkan lebih banyak pekerjaan, tetapi menghasilkan sistem yang lebih bersih dan mudah dipelihara.
Menyalin seluruh data hanya pada malam cutover dapat membuat proses migrasi berlangsung sangat lama. Semakin besar kapasitas data, semakin besar risiko waktu maintenance melewati jadwal.
Pendekatan yang lebih aman adalah melakukan sinkronisasi bertahap.
Tahap pertama adalah initial copy. Seluruh data dari server sumber disalin ke server tujuan saat sistem masih digunakan. Proses ini dapat berlangsung beberapa jam atau hari tanpa harus menghentikan operasional.
Setelah initial copy selesai, lakukan incremental synchronization. Pada tahap ini, hanya file atau data yang berubah sejak proses sebelumnya yang disalin kembali.
Menjelang cutover, perusahaan melakukan final synchronization. Akses tulis pada sistem sumber dapat dibatasi sementara agar tidak ada perubahan baru yang tertinggal.
Alur sederhananya adalah:
Untuk database, sinkronisasi dapat menggunakan metode yang didukung oleh database tersebut, seperti backup dan restore, log shipping, replication, database mirroring, atau availability group.
Jangan menyalin file database secara sembarangan ketika service masih aktif. Data dapat berada dalam kondisi tidak konsisten dan gagal digunakan setelah dipindahkan.
Pada file server Windows, Storage Migration Service menggunakan proses inventory, transfer, dan optional cutover. Data tetap berada pada server lama setelah transfer. Ketika cutover dilakukan, server tujuan dapat mengambil identitas server lama agar pengguna tetap mengakses nama dan path yang sama.
Perhatikan pula bandwidth. Menyalin 10 TB melalui jaringan 1GbE membutuhkan waktu yang jauh lebih lama daripada jaringan 10GbE. Aktivitas migrasi juga dapat mengganggu pengguna jika seluruh bandwidth dipakai untuk transfer.
Tim dapat menjadwalkan initial copy di luar jam sibuk, membatasi throughput, atau menggunakan jalur jaringan khusus untuk migrasi.
Server tujuan harus diuji sebelum digunakan oleh seluruh pengguna. Jangan menjadikan hari cutover sebagai waktu pertama aplikasi dijalankan pada lingkungan baru.
Testing dapat dilakukan melalui beberapa tahap.
Pastikan server tujuan memiliki:
Uji setiap fungsi bisnis penting, bukan hanya memastikan aplikasi dapat dibuka.
Contohnya:
Libatkan key user dari setiap divisi. Tim IT mungkin menyatakan aplikasi berjalan, tetapi pengguna bisnis dapat menemukan menu, laporan, atau proses tertentu yang belum berfungsi.
Bandingkan performa server lama dan baru. Ukur waktu login, pembukaan aplikasi, query database, transfer file, dan penggunaan CPU serta RAM.
Server baru dapat memiliki spesifikasi tinggi, tetapi tetap lambat jika storage, jaringan, atau konfigurasi database tidak tepat.
Rollback plan menentukan langkah yang dilakukan apabila migrasi gagal.
Dokumen rollback sebaiknya mencantumkan:
Server sumber sebaiknya tidak langsung dihapus atau diformat setelah cutover. Pertahankan perangkat tersebut dalam kondisi aman selama masa stabilisasi.
Namun, akses pengguna ke server lama perlu dibatasi agar data tidak terbagi antara dua sistem.
Backup penuh juga harus tersedia sebelum migrasi. Rollback tidak boleh hanya bergantung pada kondisi server lama karena perangkat tersebut tetap dapat mengalami kerusakan.
Cutover adalah tahap ketika layanan resmi dialihkan dari server lama ke server baru.
Proses ini perlu dilakukan pada waktu dengan aktivitas pengguna rendah. Walaupun targetnya tanpa downtime, tetap sediakan maintenance window agar tim memiliki ruang menghadapi masalah yang tidak terduga.
Sebelum cutover dimulai, lakukan pemeriksaan terakhir:
Setelah itu, cutover dapat dilakukan melalui langkah berikut:
Pada file server Windows, cutover Storage Migration Service dapat memindahkan identitas jaringan server sumber ke tujuan. Prosesnya melibatkan perubahan nama, IP, keanggotaan domain, dan identitas Active Directory. Server sumber tetap menyimpan file, tetapi dibuat tidak tersedia bagi pengguna dan aplikasi.
Karena cutover tersebut dapat melibatkan restart dan replikasi DNS atau Active Directory, perusahaan tetap perlu menyediakan periode maintenance. “Tanpa downtime” bukan berarti tidak ada tahapan perpindahan sama sekali.
Pada VM yang mendukung live migration, gangguan dapat ditekan hingga tidak terlihat oleh pengguna. Microsoft menyatakan Hyper-V live migration dapat memindahkan VM aktif tanpa noticeable downtime.
Namun, live migration tidak menyelesaikan semua jenis perpindahan. Migrasi database, perubahan alamat aplikasi, upgrade sistem operasi, atau pergantian platform dapat tetap membutuhkan restart.
Untuk mengurangi risiko, lakukan cutover bertahap jika memungkinkan. Pindahkan aplikasi nonkritis terlebih dahulu, lalu gunakan hasilnya untuk memperbaiki SOP sebelum memigrasikan sistem utama.
Migrasi belum selesai hanya karena pengguna sudah dapat login. Tim perlu melakukan pemeriksaan selama masa stabilisasi.
Gunakan checklist berikut:
1. Periksa layanan utama
Pastikan seluruh service berjalan dan menggunakan akun yang benar. Periksa pula scheduled task, job database, backup agent, antivirus, monitoring, dan integrasi email.
2. Periksa akses pengguna
Uji permission folder, file share, aplikasi, printer, VPN, dan akses cabang. Pastikan pengguna tidak memperoleh hak akses berlebihan atau kehilangan akses yang sebelumnya dimiliki.
3. Pantau performa
Monitor CPU, RAM, storage latency, disk queue, network throughput, dan log error. Perhatikan pola pada jam sibuk, bukan hanya beberapa menit setelah cutover.
4. Pastikan backup server baru berjalan
Buat backup setelah migrasi dan lakukan restore test. Jangan menganggap konfigurasi backup lama otomatis berpindah ke server baru.
5. Periksa lisensi
Pastikan aktivasi sistem operasi, database, aplikasi, CAL, dan subscription masih sesuai setelah perubahan perangkat atau virtualisasi.
6. Perbarui dokumentasi
Perbarui diagram jaringan, IP address, hostname, kredensial operasional, konfigurasi storage, SOP, dan daftar kontak vendor.
7. Pantau server lama
Server lama dapat dipertahankan dalam kondisi mati atau terisolasi selama periode tertentu. Jangan biarkan pengguna mengaksesnya karena data dapat kembali terpisah.
8. Tentukan waktu decommission
Setelah server baru stabil dan masa rollback berakhir, lakukan penghapusan data server lama dengan prosedur yang aman. Cabut perangkat dari domain, monitoring, backup job, DNS, dan sistem inventaris.
9. Lakukan evaluasi
Catat masalah selama migrasi, durasi downtime, hasil pengujian, dan tindakan perbaikan. Informasi tersebut akan membantu proyek migrasi berikutnya.
Migrasi server tanpa downtime membutuhkan lebih dari sekadar menyalin file ke perangkat baru. Perusahaan perlu mengaudit aplikasi dan dependency, menentukan metode P2V atau V2V, melakukan sinkronisasi bertahap, menguji sistem tujuan, serta menyiapkan rollback plan.
Untuk VM pada platform yang mendukung live migration, perpindahan dapat dilakukan tanpa gangguan yang terlihat. Namun, aplikasi fisik, database, dan file server biasanya tetap memerlukan cutover window singkat.
Keberhasilan migrasi ditentukan oleh persiapan, dokumentasi, pengujian, komunikasi pengguna, dan kemampuan mengembalikan layanan ketika terjadi masalah.
@sparta.enterprise6 🚀 Sparta Enterprise Goes to Google! Langkah besar menuju masa depan digital — Sparta Enterprise kini berkolaborasi dan terhubung lebih dalam dengan ekosistem Google. Dari inovasi cloud, keamanan data, hingga transformasi bisnis digital — kami terus berkembang untuk memberikan layanan terbaik. 📍Stay tuned, ini baru permulaan. 🔥 SPARTA x GOOGLE! 🔥 Sparta Enterprise resmi menjejakkan langkah ke ranah teknologi global! Dengan semangat “Berani, Cepat, Tangguh” kami hadir di Google untuk memperluas dampak, memperkuat inovasi, dan membuka peluang kolaborasi teknologi tanpa batas! ➡️ Follow perjalanan digital kami! ✳️ Tagline Branding Singkat: “Sparta Enterprise Goes Global with Google.” “Melangkah Lebih Jauh. Lebih Besar. Bersama Google.” “Next Level Begins: Sparta Meets Google.” #SpartaEnterprise #GoesToGoogle #DigitalTransformation #KolaborasiDigital #GoogleCloud #TechForFuture #InovasiTanpaBatas #EnterpriseLevel #TransformasiDigital #SpartaXGoogle #BanggaLokalMendunia ♬ suara asli – PT SPARTA COMPUTINDO TEKNOLOGI – PT PUSAT SERVER INDONESIA
Tim Sparta Server Indonesia dapat membantu mengevaluasi kebutuhan hardware, virtualisasi, storage, jaringan, instalasi, serta tahapan perpindahannya. Gunakan formulir Get in Touch pada halaman Contact untuk mengirimkan gambaran proyek dan jadwal migrasi.
Koordinasi teknis juga dapat dihubungi melalui:
Email: sales@spartaserverindonesia.com
WhatsApp: +62 878-2224-1000
Alamat kantor: Jl. Raya Lenteng Agung Barat Nomor 8, RT 02/RW 04, Srengseng Sawah, Jagakarsa, Jakarta Selatan, DKI Jakarta
Website: spartaserverindonesia.com
Bisa untuk workload tertentu, seperti live migration VM pada platform yang mendukungnya. Namun, migrasi aplikasi, database, atau file server sering tetap membutuhkan cutover singkat.
P2V memindahkan server fisik menjadi virtual machine. V2V memindahkan atau mengonversi VM dari satu host atau platform virtualisasi ke platform lain.
Server lama dapat dihentikan setelah cutover, tetapi sebaiknya belum langsung dihapus. Pertahankan sebagai bagian dari rollback plan selama masa stabilisasi dengan akses pengguna yang dibatasi.
Sinkronisasi bertahap mengurangi jumlah data yang harus dipindahkan saat cutover. Initial copy dilakukan lebih awal, sedangkan final sync hanya menyalin perubahan terbaru.
Durasi bergantung pada kapasitas data, kecepatan jaringan, kompleksitas aplikasi, metode migrasi, dan kebutuhan testing. Proses persiapan dapat berlangsung beberapa hari atau minggu, meskipun cutover hanya membutuhkan waktu singkat.
Solusi Server Lengkap untuk Beragam Kebutuhan Bisnis & Teknologi
Copyright 2025 spartaserverindonesia.com. All Rights Reserved.