Apa itu failover dan failback?

Artikel ini memberikan gambaran umum tentang bagaimana failover dan failback beroperasi di lingkungan cloud. Namun, untuk memahami failover, Anda harus terlebih dahulu memahami redundansi dan replikasi. Untuk mempelajari tentang konsep tersebut sebelum melanjutkan artikel ini, lihat Redundansi, replikasi, dan pencadangan.

Alasan umum untuk mempertahankan salinan redundan dari aplikasi dan replika data adalah untuk dapat melakukan failover. Dengan failover, Anda dapat mengalihkan lalu lintas dan permintaan dari instance yang bermasalah ke instance yang sehat. Kemudian, setelah instans asli menjadi sehat lagi, Anda dapat melakukan failback untuk kembali ke konfigurasi asli.

Peran instans aktif dan pasif

Dalam konteks failover, instans dapat menjadi satu komponen, seperti database, atau kumpulan beberapa komponen yang membentuk penyebaran layanan di suatu wilayah. Dalam keseluruhan solusi, Anda mungkin melakukan failover pada bagian-bagian berbeda dari solusi tersebut dengan cara yang berbeda dan dalam situasi yang berbeda.

Komponen, atau kumpulan komponen yang dikonfigurasi untuk failover dan failback, memerlukan beberapa instans. Masing-masing instans tersebut mengasumsikan peran tertentu:

  • Instans utama atau aktif secara aktif melakukan pekerjaan, seperti melayani permintaan masuk dari klien. Biasanya ada satu instance utama pada suatu waktu.
  • Instans sekunder atau pasif tidak aktif, tetapi siap untuk dialihkan untuk menjadi yang utama jika diperlukan. Mungkin ada beberapa instans sekunder.

Ada beberapa cara untuk mengonfigurasi instans pasif. Setiap cara melibatkan kompromi antara waktu pemulihan dan faktor lain, seperti biaya dan kompleksitas operasional.

  • Siaga langsung, yang dirancang untuk siap menerima lalu lintas produksi kapan saja.
  • Siaga hangat, yang dirancang agar hampir siap untuk menerima lalu lintas produksi, tetapi itu mungkin memerlukan beberapa perubahan konfigurasi atau operasi penskalakan untuk diselesaikan sebelum mereka dapat menerima lalu lintas.
  • Pilot cahaya siaga, yang sebagian disebarkan dalam konfigurasi minimal, dan memerlukan persiapan yang signifikan untuk diselesaikan sebelum mereka dapat menerima lalu lintas produksi.
  • Siaga dingin, yang mungkin tidak disebarkan sama sekali, dan mengandalkan komponen yang akan disebarkan sebelum mereka dapat menerima lalu lintas produksi.

Petunjuk / Saran

Beberapa solusi dibuat untuk menggunakan pendekatan aktif-aktif , yang berarti beberapa instans semuanya melayani permintaan. Sistem aktif-aktif tidak memerlukan failover, karena semua instans secara aktif melayani permintaan setiap saat.

Ruang lingkup failover

Situasi yang berbeda memerlukan strategi failover yang berbeda. Untuk mengilustrasikan kemungkinan strategi ini, pertimbangkan contoh solusi yang terdiri dari aplikasi yang mengakses data dari database. Anda mengonfigurasi solusi untuk failover dengan membuat salinan redundan server aplikasi Anda dan beberapa replika database. Selanjutnya, Anda mengonfigurasi:

  • Redundansi zona dengan menempatkan salinan dan replika di zona ketersediaan yang berbeda dalam wilayah Azure.
  • Redundansi geografis dengan menggunakan load balancer global untuk melakukan failover antar wilayah.

Berikut adalah diagram yang disederhanakan yang mengilustrasikan arsitektur keseluruhan dalam operasi normal:

Diagram memperlihatkan arsitektur solusi yang menggunakan beberapa replika database di zona ketersediaan yang berbeda, di dua wilayah terpisah.

Situasi yang berbeda dapat memicu peristiwa failover yang berbeda dalam solusi ini. Masing-masing ini sesuai dengan cakupan failover, yang mewakili granularitas komponen yang gagal:

  • Failover database replika mungkin terjadi ketika database replika aktif menjadi tidak tersedia. Replika pasif dipromosikan untuk menjadi replika aktif. Biasanya, aplikasi dapat dengan cepat mengalihkan permintaan mereka ke replika aktif baru:

    Diagram yang menunjukkan arsitektur solusi di mana replika pasif telah dipromosikan menjadi replika aktif baru.

  • Kegagalan zona ketersediaan mungkin terjadi jika zona ketersediaan lengkap mengalami pemadaman. Jenis pemadaman ini mengharuskan semua lalu lintas diarahkan ke server web di zona yang tersisa, dan juga memastikan bahwa replika database di zona yang bertahan menjadi replika aktif jika belum menjadi demikian:

    Diagram memperlihatkan arsitektur solusi di mana satu zona ketersediaan tidak tersedia.

  • Failover regional A mungkin terjadi jika ada kehilangan besar-besaran dari seluruh wilayah Azure utama.

    Diagram memperlihatkan arsitektur solusi di mana satu wilayah tidak tersedia.

Meskipun masing-masing cakupan ini menyediakan jenis failover, mereka mungkin memiliki persyaratan dan proses failover yang berbeda. Selain itu, Microsoft mungkin bertanggung jawab atas beberapa cakupan failover, seperti saat Anda menggunakan layanan redundan zona, sementara Anda mungkin bertanggung jawab atas failover pada cakupan yang lebih luas, seperti failover antara wilayah Azure.

Failover dan perencanaan kelangsungan bisnis

Bagian dari perencanaan kelangsungan bisnis adalah merancang strategi failover Anda, termasuk berbagai cakupan di mana Anda dapat melakukan failover.

Umumnya, rencana kelangsungan bisnis Anda harus menyertakan prosedur failover otomatis di dalam atau di antara zona ketersediaan. Jenis failover ini merupakan bagian dari strategi tingkat ketersediaan tinggi Anda. Misalnya, jika replika aktif database gagal, proses otomatis dapat mempromosikan replika pasif untuk menjadi replika aktif. Kemudian, server web berkomunikasi dengan replika aktif baru. Demikian pula, jika zona ketersediaan gagal, banyak solusi dibuat untuk pulih secara otomatis dengan menggunakan zona yang tersisa.

Prosedur failover yang berbeda digunakan untuk skenario bencana, seperti dalam kejadian tidak terduga terjadi pemadaman pada seluruh wilayah. Dalam kasus pemadaman wilayah, Anda mungkin mengalihkan permintaan web masuk untuk menggunakan wilayah kedua, serta memicu failover database ke replika di wilayah sekunder.

Perlu diingat bahwa termasuk prosedur failover dalam perencanaan kelangsungan bisnis Anda mengharuskan Anda untuk melakukan desain dan pengujian yang lebih rinci. Untuk informasi selengkapnya, lihat Apa itu kelangsungan bisnis, ketersediaan tinggi, dan pemulihan bencana?.

Failover terencana dan tidak terencana

Failover yang tidak direncanakan adalah yang dilakukan selama pemadaman komponen, sehingga Anda dapat memulihkan layanan dengan menggunakan instans lain. Failover yang tidak direncanakan terkadang mengakibatkan waktu henti atau kehilangan data, tergantung pada bagaimana solusi dirancang. Failover yang tidak direncanakan memerlukan sesuatu untuk mendeteksi kegagalan dan membuat keputusan tentang kapan harus memicu failover.

Sebaliknya, failover yang direncanakan adalah yang Anda picu secara proaktif. Anda mungkin melakukan ini untuk mengantisipasi sesuatu yang terjadi, seperti komputer virtual yang akan di-patch dan di-boot ulang. Failover yang direncanakan mungkin memiliki toleransi yang lebih rendah untuk waktu henti dan kehilangan data, karena merupakan bagian dari prosedur pemeliharaan reguler.

Cara kerja failover

Failover umumnya terdiri dari langkah-langkah berikut, yang dapat dilakukan secara manual atau oleh sistem otomatis. Detail spesifik untuk masing-masing langkah ini bergantung pada sistem tertentu.

  1. Mendeteksi kegagalan (failover yang tidak direncanakan saja). Failover otomatis mengharuskan sesuatu mendeteksi ketika instans tidak tersedia, yang biasanya didasarkan pada semacam pemeriksaan kesehatan. Layanan yang berbeda mendefinisikan kesehatan mereka dengan cara yang berbeda. Misalnya, beberapa layanan secara proaktif mengirim peristiwa heartbeat antar instans. Yang lain memerlukan komponen terpisah untuk mengecek setiap instance secara berkala. Sering kali dibutuhkan beberapa waktu bagi pemantau kesehatan untuk mendeteksi bahwa suatu instans telah gagal, dan sangat penting untuk memberikan masa tenggang jika instans tersebut sedang sibuk dan tidak dapat merespons.

  2. Pilih untuk melakukan failover. Pada titik tertentu, keputusan akan dibuat untuk melakukan failover. Keputusan dapat dibuat oleh alat otomatis, atau secara manual. Toleransi risiko organisasi Anda dapat memengaruhi seberapa cepat keputusan ini dibuat. Jika Anda memiliki toleransi risiko yang rendah, Anda mungkin memilih untuk failover dengan cepat jika ada indikasi masalah. Jika Anda memiliki toleransi risiko yang lebih tinggi, Anda mungkin memilih untuk menunggu untuk melihat apakah masalah dapat diselesaikan sebelum failover.

  3. Pilih instans utama baru. Salah satu instans yang tersisa harus sekarang menjadi instans utama yang baru.

    Dalam beberapa situasi, Anda mungkin telah menentukan instans mana yang harus menjadi utama baru, atau Anda mungkin hanya memiliki satu instans untuk beralih.

    Dalam situasi lain, ada proses otomatis di mana sistem memilih instans utama baru. Ada sejumlah algoritma konsekuensi yang digunakan dalam komputasi terdistribusi, termasuk untuk pemilihan pemimpin. Algoritma ini diimplementasikan dalam layanan yang relevan, seperti database. Dalam beberapa sistem, penting bagi setiap instans untuk mengetahui replika utama baru dan sehingga hasil pemilihan diumumkan ke setiap replika secara otomatis.

  4. Mengalihkan permintaan. Konfigurasikan lingkungan Anda sehingga permintaan diarahkan ke instans sehat, atau ke instans utama baru.

    Untuk mencapai hal ini, Anda mungkin perlu memperbarui sistem lain sehingga mereka tahu di mana harus mengirim permintaan. Ini mungkin melibatkan memperbarui sistem penyeimbangan beban untuk mengecualikan instance yang tidak sehat. Dalam situasi lain, sistem nama domain (DNS) biasanya digunakan sebagai cara untuk mengirim permintaan ke instans aktif sistem. Sebagai bagian dari proses failover, Anda biasanya perlu memperbarui catatan DNS sehingga permintaan dirutekan ke instans utama baru. DNS memiliki konsep time-to-live (TTL), yang menginstruksikan klien tentang seberapa sering mereka harus memeriksa catatan DNS yang diperbarui. Jika TTL Anda diatur ke nilai yang tinggi, mungkin perlu waktu bagi klien untuk menerima informasi tentang failover, dan mereka mungkin terus mengirim permintaan ke server utama lama.

Karena proses failover dapat mencakup penundaan, penting bagi Anda untuk merencanakan prosedur failover Anda untuk memenuhi persyaratan Anda untuk waktu henti (tujuan titik pemulihan Anda, atau RTO) dan kehilangan data (tujuan titik pemulihan Anda, atau RPO). Untuk mempelajari lebih lanjut, lihat Apa itu kelangsungan bisnis, ketersediaan tinggi, dan pemulihan bencana?.

Failback

Failback adalah proses untuk mengembalikan dan mengalihkan trafik kembali ke instans utama asli.

Dalam beberapa situasi, tidak perlu melakukan failback sama sekali karena setiap instans sama-sama mampu bertindak sebagai yang utama. Namun, ada beberapa situasi di mana penting untuk mengembalikan, seperti ketika Anda perlu menjalankan aplikasi Anda dari wilayah Azure tertentu dan telah beralih sementara ke wilayah lain selama pemadaman regional.

Terkadang, failback ditangani dengan cara yang sama seperti failover. Namun, failback juga bisa lebih kompleks daripada failover, karena beberapa alasan:

  • Masalah sinkronisasi data. Selama, dan bahkan setelah kegagalan reguler, instans utama sebelumnya mungkin masih melakukan beberapa pekerjaan atau menulis beberapa data ke penyimpanan data. Bagian dari proses failback adalah memastikan konsistensi dan integritas data di seluruh solusi Anda, termasuk mengelola konflik atau duplikasi antara instans primer dan sekunder.

    Umum bagi masalah sinkronisasi data untuk memerlukan intervensi manual. Jika Anda tidak memerlukan data yang berkonflik, Anda mungkin memilih untuk mengatur ulang database atau status lainnya.

  • Langkah-langkah remediasi. Jika ada langkah-langkah remediasi yang dicoba pada utama sebelum failover terjadi, langkah-langkah tersebut mungkin telah meninggalkan instans utama dalam keadaan yang tidak diketahui.

    Jika ada risiko instans utama berada dalam keadaan tidak konsisten, Anda mungkin perlu menghancurkan dan menyebarkan ulang instans utama sehingga berada pada status baik yang diketahui sebelum Anda gagal kembali.

  • Waktu henti ekstra. Waktu henti selama proses failback bisa lebih lama daripada selama failover karena konfigurasi ulang diperlukan atau operasi untuk memulihkan konsistensi data.

    Anda dapat mengurangi masalah ini dengan menjalankan proses failback selama jendela pemeliharaan atau dengan memberi tahu pengguna tentang perubahan sebelumnya. Selain itu, Anda mungkin dapat melakukan beberapa operasi persiapan saat sistem online, dan meminimalkan waktu henti yang diperlukan.

  • Toleransi risiko. Jika failover terjadi karena pemadaman, toleransi organisasi untuk waktu henti atau risiko lain selama failback dapat lebih rendah.

    Pemangku kepentingan bisnis harus diberi informasi tentang situasi sepanjang proses, dan harus sepenuhnya menyadari kebutuhan akan failback serta konsekuensi dari prosedur failback. Anda mungkin dapat menegosiasikan waktu yang sesuai untuk membuat perubahan.

Failover dan failback di layanan Azure

Meskipun penting untuk memahami cara kerja failover secara umum, perlu diingat bahwa setiap layanan Azure dapat mendekati failover dan failback secara berbeda. Untuk informasi tentang cara kerja layanan Azure spesifik dari perspektif keandalan, lihat panduan keandalan setiap layanan.

Banyak layanan Azure menangani jenis failover tertentu secara otomatis. Misalnya, saat Anda menggunakan layanan Azure yang dikonfigurasi menjadi zona redundan, Microsoft secara otomatis melakukan failover antar zona ketersediaan untuk Anda. Untuk mempelajari selengkapnya, lihat Apa itu zona ketersediaan? dan panduan keandalan layanan Azure.

Jika Anda menggunakan komputer virtual, Azure Site Recovery mereplikasi komputer virtual dan disk mereka antara zona ketersediaan atau ke wilayah Azure lain, dan dapat melakukan failover untuk Anda.

Saat Anda merancang solusi Anda sendiri yang menggabungkan beberapa layanan Azure bersama-sama, persyaratan failover Anda mungkin menjadi lebih kompleks. Misalkan Anda merancang solusi dengan tingkat aplikasi dan database, dan Anda ingin membuat arsitektur aktif/pasif multi-wilayah. Selama pemadaman di wilayah utama, penting bahwa aplikasi dan database Anda melakukan failover ke wilayah sekunder bersama-sama. Tergantung pada layanan yang Anda gunakan, Anda mungkin perlu merencanakan pendekatan failover (sistem cadangan otomatis) Anda sendiri untuk berpindah antar penerapan di setiap wilayah. Azure menyediakan perutean lalu lintas global dan penyeimbangan beban melalui Azure Front Door dan Azure Traffic Manager, dan Anda dapat memilih teknologi yang memenuhi persyaratan failover Anda. Setiap layanan mendukung pemantauan kesehatan setiap instans regional aplikasi Anda dan Anda dapat mengonfigurasinya untuk secara otomatis mengalihkan lalu lintas ke instans sehat.

Langkah selanjutnya

  • Last updated on