Lokasi:
Srengseng Sawah, Jagakarsa Jakarta Selatan
Active-active vs active-passive merupakan dua arsitektur yang umum digunakan untuk membangun high availability pada server perusahaan. Active-active menjalankan dua atau lebih node secara aktif dan membagi workload di antara node tersebut. Sementara itu, active-passive menggunakan satu node utama untuk melayani workload dan menyediakan node cadangan yang akan mengambil alih ketika server utama mengalami gangguan.
Jika perusahaan membutuhkan pemanfaatan resource tinggi, distribusi trafik, dan downtime seminimal mungkin, active-active dapat menjadi pilihan. Active-passive lebih cocok ketika perusahaan menginginkan konfigurasi failover yang relatif sederhana dan tidak membutuhkan seluruh server aktif melayani trafik secara bersamaan.
Namun, active-active tidak otomatis lebih baik. Infrastruktur tersebut membutuhkan sinkronisasi data, load balancer, kontrol terhadap split brain, dan desain aplikasi yang mendukung penggunaan beberapa node. Microsoft juga menjelaskan bahwa active-active dapat menghasilkan RTO sangat rendah karena semua deployment sudah aktif melayani trafik, tetapi membutuhkan replikasi data dan infrastruktur yang mampu menangani perpindahan beban ketika salah satu lokasi gagal.
Satu server dapat menjadi single point of failure ketika seluruh layanan perusahaan hanya bergantung pada perangkat tersebut. Jika server berhenti, tidak ada perangkat lain yang dapat langsung mengambil alih workload.
Sebagai contoh, sebuah perusahaan menempatkan ERP, database, dan aplikasi internal pada satu server fisik. Ketika motherboard, power supply, sistem operasi, atau storage mengalami gangguan, seluruh layanan tersebut dapat berhenti sekaligus.
Gangguan server dapat terjadi akibat berbagai faktor, seperti:
RAID dan dual power supply dapat mengurangi risiko kegagalan komponen tertentu, tetapi belum menghilangkan single point of failure pada tingkat server. Motherboard atau sistem operasi masih dapat mengalami gangguan.
Untuk aplikasi bisnis penting, perusahaan dapat menggunakan beberapa node yang membentuk cluster. Ketika satu node bermasalah, workload dipindahkan atau tetap dilayani oleh node lainnya.
Microsoft Windows Server Failover Clustering, misalnya, dirancang agar node dalam cluster bekerja bersama untuk menjaga ketersediaan workload ketika terjadi kegagalan hardware atau software.
Konsep high availability tidak berarti sistem tidak pernah mengalami gangguan. Tujuannya adalah mengurangi dampak kegagalan dan memperpendek durasi downtime.
Perusahaan juga perlu membedakan antara high availability dan disaster recovery.
High availability biasanya berfokus pada menjaga layanan ketika satu komponen atau node gagal. Disaster recovery berfokus pada pemulihan ketika terjadi gangguan yang lebih luas, misalnya seluruh data center tidak tersedia.
Karena itu, cluster dua server dalam satu ruang belum tentu melindungi perusahaan dari kebakaran, banjir, atau gangguan listrik pada seluruh lokasi.
Dalam arsitektur active-active, dua atau lebih node berada dalam kondisi aktif dan dapat melayani workload pada saat bersamaan.
Misalnya, perusahaan memiliki dua application server:
Server A aktif menerima trafik
Server B aktif menerima trafik
Load balancer mendistribusikan permintaan pengguna ke kedua server. Pembagian dapat menggunakan metode round robin, least connection, weighted distribution, atau health based routing.
Microsoft menjelaskan bahwa pada deployment active-active, dua atau lebih lokasi atau instance aktif melayani production load secara bersamaan. Ketika salah satu gagal, trafik dialihkan ke instance yang masih sehat.
Keuntungan utama active-active adalah resource pada seluruh node dapat digunakan ketika kondisi normal. Perusahaan tidak memiliki satu server mahal yang hanya menunggu sebagai cadangan.
Sebagai contoh:
| Kondisi | Server A | Server B |
| Normal | 50% workload | 50% workload |
| Server A gagal | Offline | 100% workload |
| Server B gagal | 100% workload | Offline |
Agar skenario tersebut bekerja, server yang tersisa harus memiliki kapasitas yang cukup untuk menerima beban tambahan ketika node lain gagal.
Jika dua server masing-masing sudah beroperasi pada penggunaan CPU 90 persen saat kondisi normal, kehilangan satu node dapat menyebabkan server lainnya tidak mampu menerima seluruh workload.
Karena itu, active-active tetap membutuhkan capacity planning.
Beberapa keuntungan active-active antara lain:
Arsitektur ini sering digunakan pada web application, API, portal pelanggan, load-balanced application server, DNS, Kubernetes, hingga database tertentu yang memang mendukung multinode aktif.
Microsoft menilai active-active sangat sesuai ketika aplikasi mampu menerima request dari beberapa lokasi tanpa ketergantungan state yang spesifik dan ketika perusahaan membutuhkan RTO serendah mungkin.
Namun, kompleksitas meningkat ketika aplikasi bersifat stateful.
Jika pengguna login melalui Server A dan permintaan berikutnya masuk ke Server B, state session harus tersedia pada kedua server atau disimpan pada sistem terpisah seperti database, Redis, atau distributed cache.
Database juga memerlukan teknologi khusus agar beberapa node dapat membaca atau menulis data tanpa menghasilkan konflik.
Pada active-passive, hanya satu node yang secara aktif menjalankan workload utama. Node kedua berada dalam kondisi standby dan siap mengambil alih apabila node pertama mengalami gangguan.
Contohnya:
Server A Active
Server B Passive / Standby
Saat Server A gagal, cluster mendeteksi kondisi tersebut kemudian memindahkan layanan ke Server B.
Setelah failover:
Server A Offline
Server B Active
AWS menjelaskan active-passive sebagai arsitektur di mana satu site aktif melayani trafik, sedangkan site pasif digunakan untuk recovery dan baru melayani workload ketika failover dijalankan.
Node passive dapat memiliki beberapa kondisi.
Server cadangan tersedia tetapi aplikasi belum aktif. Proses failover membutuhkan waktu lebih lama karena service perlu dijalankan dan data mungkin perlu dipulihkan.
Server cadangan sudah hidup dan memiliki aplikasi serta data yang terus diperbarui, tetapi belum aktif melayani pengguna.
Server cadangan selalu siap dan memiliki data yang sangat dekat dengan server utama. Failover dapat dilakukan dalam waktu lebih singkat.
Active-passive sering digunakan untuk workload yang lebih sulit dijalankan secara aktif pada dua node sekaligus.
Contohnya antara lain:
Keuntungan active-passive adalah desain aplikasi relatif lebih sederhana karena hanya satu node yang memiliki peran aktif.
Namun, server passive tidak memberikan kontribusi penuh terhadap workload sehari-hari. Perusahaan tetap membeli CPU, RAM, storage, dan lisensi tertentu untuk perangkat yang sebagian besar waktunya hanya menunggu.
Node passive juga perlu diuji secara rutin. Server cadangan yang jarang digunakan dapat mengalami konfigurasi yang tertinggal, update berbeda, atau masalah lain yang baru diketahui ketika failover benar-benar diperlukan.
Active-active biasanya menawarkan pemanfaatan resource yang lebih baik, sedangkan active-passive menawarkan desain yang relatif lebih sederhana.
Berikut perbandingan umumnya:
| Aspek | Active-Active | Active-Passive |
| Node aktif | Semua node | Satu node utama |
| Pemanfaatan resource | Tinggi | Node cadangan lebih banyak idle |
| Distribusi trafik | Ya | Tidak pada kondisi normal |
| Failover | Biasanya sangat cepat | Membutuhkan perpindahan service |
| Load balancer | Umumnya diperlukan | Tergantung arsitektur |
| Sinkronisasi data | Lebih kompleks | Relatif lebih sederhana |
| Skalabilitas | Tinggi | Lebih terbatas |
| Biaya | Dapat lebih tinggi | Umumnya lebih sederhana |
| Pengelolaan | Lebih kompleks | Relatif mudah |
| Cocok untuk | Web, API, aplikasi scalable | ERP, database tertentu, aplikasi legacy |
Active-active memungkinkan workload dibagi ke beberapa server. Jika satu node tidak mampu menangani trafik, perusahaan dapat menambah node baru.
Sebagai contoh, perusahaan memiliki empat application server. Load balancer dapat membagi permintaan ke seluruh node sehingga masing-masing hanya menangani sebagian trafik.
Strategi ini sangat cocok untuk aplikasi stateless dan microservices.
Namun, performa tidak otomatis meningkat dua kali hanya karena jumlah server bertambah. Database, storage, session handling, jaringan, dan load balancer tetap dapat menjadi bottleneck.
Pada active-passive, seluruh workload normal ditangani server utama. Karena itu, node aktif harus mampu menjalankan 100 persen kebutuhan aplikasi.
Server passive biasanya dibuat dengan spesifikasi sama atau mendekati server utama agar mampu mengambil alih workload.
Keuntungannya, desain performa lebih mudah diprediksi. Namun, perusahaan membayar resource cadangan yang tidak digunakan penuh ketika kondisi normal.
Microsoft menyebut active-active membutuhkan kedua lingkungan memiliki infrastruktur yang setara, replikasi data berkelanjutan, load balancing, serta pengujian skenario perpindahan trafik. Active-passive memiliki alur yang lebih sederhana, tetapi konfigurasi standby tetap harus selalu dipastikan siap digunakan.
Karena itu, perusahaan perlu mempertimbangkan kemampuan tim IT. Infrastruktur sangat kompleks tanpa monitoring dan SOP yang memadai justru dapat meningkatkan risiko kesalahan.
Load balancer memiliki peran penting pada active-active karena pengguna harus diarahkan ke node yang sehat dan tersedia.
Load balancer menerima koneksi dari pengguna, kemudian meneruskannya ke beberapa backend server.
Contohnya:
User → Load Balancer → Server A / Server B / Server C
Load balancer menjalankan health check untuk mengetahui kondisi setiap server. Jika Server B tidak merespons, trafik hanya dikirim ke Server A dan C.
Microsoft menjelaskan bahwa active-active multi-region membutuhkan global load balancer dan health probe agar trafik dapat dialihkan ketika endpoint mengalami kegagalan.
Perusahaan perlu memastikan load balancer sendiri tidak menjadi single point of failure. Karena itu, load balancer juga dapat dibuat redundant atau menggunakan layanan yang memang memiliki high availability.
Tidak selalu.
Beberapa cluster menggunakan virtual IP. Ketika node utama gagal, virtual IP berpindah ke node cadangan. Pengguna tetap menggunakan alamat yang sama sehingga tidak perlu mengetahui server mana yang sedang aktif.
Pada arsitektur lain, load balancer tetap digunakan untuk memonitor active node dan memindahkan koneksi ketika health check gagal.
Shared storage memungkinkan beberapa server mengakses kumpulan data yang sama.
Beberapa teknologi yang dapat digunakan meliputi:
Pada virtualisasi, shared storage memungkinkan VM dijalankan pada host berbeda tanpa perlu menyalin seluruh disk terlebih dahulu.
Namun, shared storage dapat menjadi single point of failure jika hanya tersedia melalui satu controller, satu switch, atau satu storage device.
Untuk high availability, storage perlu mempertimbangkan:
Tidak semua active-active membutuhkan shared storage. Web server stateless, misalnya, dapat menggunakan local disk dan mengambil data dari database atau object storage terpisah.
Arsitektur harus mengikuti karakter aplikasi, bukan memaksakan shared storage pada semua cluster.
Salah satu risiko terbesar pada cluster adalah split-brain.
Split-brain terjadi ketika dua bagian cluster kehilangan komunikasi tetapi masing-masing menganggap dirinya masih berhak menjalankan workload.
Bayangkan dua database server:
Server A ← koneksi cluster putus → Server B
Jika keduanya tetap aktif dan sama-sama menerima penulisan, data pada Server A dan Server B dapat berubah secara terpisah.
Ketika koneksi pulih, sistem memiliki dua versi data berbeda. Kondisi ini dapat menyebabkan konflik dan kerusakan data.
Microsoft menjelaskan bahwa quorum pada Windows Server Failover Clustering dirancang untuk mencegah split-brain. Cluster umumnya membutuhkan lebih dari setengah jumlah vote agar tetap beroperasi. Jika quorum hilang, bagian cluster yang tidak memiliki mayoritas akan menghentikan operasi.
Pada cluster dua node, witness dapat digunakan sebagai vote tambahan.
Jenis witness dapat berupa:
Witness tidak menyimpan data aplikasi utama. Fungsinya membantu menentukan bagian cluster mana yang berhak tetap aktif jika node kehilangan komunikasi.
Platform cluster lain menggunakan mekanisme fencing atau STONITH untuk memastikan node yang dianggap gagal benar-benar tidak lagi dapat mengakses resource.
Tujuannya sama: mencegah dua node menulis data secara bersamaan.
Failover juga dapat gagal akibat:
Karena itu, perusahaan tidak cukup hanya mengaktifkan fitur high availability. Failover perlu diuji secara berkala.
Microsoft menekankan perlunya validasi health probe, rerouting traffic, kapasitas node yang tersisa, dan perilaku sistem ketika terjadi network partition.
Pengujian dapat dilakukan dengan mematikan node secara terkontrol, menghentikan aplikasi, memutus jalur jaringan, atau mensimulasikan kegagalan storage. Tim kemudian mengukur apakah RTO yang ditargetkan benar-benar tercapai.
Pemilihan active-active atau active-passive sebaiknya mengikuti karakter aplikasi.
Web server merupakan kandidat ideal untuk active-active jika aplikasinya stateless.
Contohnya:
Ketika satu node gagal, pengguna tetap dilayani oleh dua node lainnya. Infrastruktur juga dapat ditambah secara horizontal saat trafik meningkat.
ERP sering lebih cocok menggunakan active-passive, terutama jika aplikasinya tidak dirancang untuk beberapa application server aktif atau database multi-writer.
Server utama menjalankan aplikasi dan database, sedangkan server cadangan memiliki replika yang siap mengambil alih.
Namun, setiap ERP berbeda. Vendor software perlu dikonsultasikan sebelum menentukan cluster.
Database membutuhkan perhatian khusus karena data harus konsisten.
Beberapa database mendukung arsitektur active-active melalui clustering atau replication tertentu. Namun, sistem multi writer memiliki kompleksitas lebih tinggi karena harus menangani konflik transaksi, locking, replication lag, dan konsistensi.
Untuk database yang tidak dirancang multi-writer, active-passive biasanya lebih aman.
File server dapat menggunakan active-passive cluster dengan shared storage. Jika node utama gagal, role file server berpindah ke node lainnya.
Untuk kebutuhan scale-out tertentu, teknologi distributed file system atau scale-out file server dapat digunakan, tetapi arsitekturnya berbeda dari file server konvensional.
Cluster virtualisasi seperti Hyper-V, Proxmox, dan VMware umumnya memiliki beberapa host aktif. VM didistribusikan ke berbagai node ketika kondisi normal.
Jika satu host gagal, VM dapat dijalankan kembali pada host lain.
Dalam konteks compute, model ini dapat terlihat active-active karena semua host aktif menjalankan workload berbeda. Namun, sebuah VM tertentu biasanya hanya aktif pada satu host pada satu waktu kecuali aplikasinya sendiri memiliki clustering.
Portal pelanggan, aplikasi mobile backend, API, dan e-commerce cocok menggunakan active-active jika arsitekturnya mendukung horizontal scaling.
Microsoft bahkan merekomendasikan pola active-active untuk aplikasi stateless lintas region ketika targetnya adalah RTO rendah dan kedua lokasi dapat aktif melayani trafik.
Sebagai panduan awal:
| Workload | Rekomendasi Awal |
| Website dan API stateless | Active-active |
| Portal pelanggan | Active-active |
| Load-balanced application server | Active-active |
| ERP tradisional | Active-passive |
| Database single-writer | Active-passive |
| Database multi-node yang mendukung | Active-active dapat dipertimbangkan |
| File server | Active-passive atau solusi scale-out khusus |
| Virtualization host | Multi-node active cluster |
| Aplikasi legacy | Active-passive lebih sederhana |
Pemilihan akhir tetap harus mengikuti kemampuan aplikasi, dukungan vendor, pola transaksi, serta target RPO dan RTO.
Active-active cocok ketika perusahaan membutuhkan distribusi trafik, pemanfaatan seluruh node, skalabilitas tinggi, dan downtime seminimal mungkin. Namun, arsitektur ini membutuhkan load balancing, sinkronisasi data, kapasitas cadangan, dan pengelolaan cluster yang lebih kompleks.
Active-passive lebih sederhana karena hanya satu node aktif pada kondisi normal. Model ini cocok untuk ERP, database single-writer, file server, dan aplikasi yang belum dirancang untuk berjalan pada beberapa node secara bersamaan.
Keduanya tetap membutuhkan monitoring, quorum atau fencing, backup, serta pengujian failover. High availability juga tidak menggantikan disaster recovery karena beberapa node dalam satu lokasi masih dapat terdampak oleh kegagalan data center yang sama.
View this post on Instagram
Sebelum menentukan active-active atau active-passive, perusahaan dapat memetakan aplikasi kritis, target downtime, kebutuhan storage, topologi jaringan, serta jumlah node yang tersedia. Sparta Server Indonesia menyediakan solusi server, storage, networking, instalasi, maintenance, dan konsultasi infrastruktur untuk kebutuhan perusahaan.
Untuk pembahasan arsitektur high availability, gunakan formulir Get in Touch di halaman resmi Contact Sparta Server Indonesia dengan menyertakan jumlah server, aplikasi yang digunakan, serta target failover.
Alternatifnya, spesifikasi awal dapat dikirim ke 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
Active-active menjalankan beberapa node secara aktif dan membagi workload. Active-passive menggunakan satu node utama, sedangkan node lainnya menunggu untuk mengambil alih ketika terjadi kegagalan.
Tidak. Active-active lebih kompleks dan hanya optimal jika aplikasi mendukung distribusi workload serta sinkronisasi data. Untuk aplikasi tertentu, active-passive lebih sederhana dan aman.
Umumnya ya, terutama untuk aplikasi web dan API. Load balancer mendistribusikan trafik serta menghentikan pengiriman request ke node yang tidak sehat.
Split-brain terjadi ketika bagian cluster kehilangan komunikasi tetapi lebih dari satu bagian menganggap dirinya aktif. Kondisi ini dapat menyebabkan konflik atau kerusakan data. Quorum dan fencing digunakan untuk mencegahnya.
Tidak. High availability menjaga layanan tetap tersedia ketika komponen gagal. Data yang terhapus, rusak, atau terkena ransomware dapat ikut tersinkronisasi ke node lain. Backup terpisah tetap diperlukan.
Solusi Server Lengkap untuk Beragam Kebutuhan Bisnis & Teknologi
Copyright 2025 spartaserverindonesia.com. All Rights Reserved.