Bagikan melalui

Pemulihan bencana di Azure Service Fabric

Bagian penting dari memberikan ketersediaan tinggi adalah memastikan bahwa layanan dapat bertahan dari semua jenis kegagalan yang berbeda. Ini sangat penting untuk kegagalan yang tidak direncanakan dan di luar kendali Anda.

Artikel ini menjelaskan beberapa mode kegagalan umum yang mungkin berupa bencana jika tidak dimodelkan dan dikelola dengan benar. Ini juga membahas mitigasi dan tindakan yang harus diambil jika bencana tetap terjadi. Tujuannya adalah untuk membatasi atau menghilangkan risiko waktu henti atau kehilangan data ketika kegagalan, direncanakan atau sebaliknya, terjadi.

Menghindari bencana

Tujuan utama Azure Service Fabric adalah untuk membantu Anda memodelkan lingkungan dan layanan Anda singgah jenis kegagalan umum bukan bencana.

Secara umum, ada dua jenis skenario bencana/kegagalan:

  • Kesalahan perangkat keras dan perangkat lunak
  • Kesalahan operasional

Kesalahan perangkat keras dan perangkat lunak

Kesalahan perangkat keras dan perangkat lunak tidak dapat diprediksi. Cara termudah untuk mengatasi kesalahan adalah menjalankan lebih banyak salinan layanan melewati batas kesalahan perangkat keras atau perangkat lunak.

Misalnya, jika layanan Anda hanya berjalan pada satu komputer, kegagalan satu komputer tersebut adalah bencana untuk layanan tersebut. Cara sederhana untuk menghindari bencana ini adalah dengan memastikan bahwa layanan berjalan di beberapa komputer. Pengujian juga diperlukan untuk memastikan bahwa kegagalan satu komputer tidak mengganggu layanan yang sedang berjalan. Perencanaan kapasitas memastikan bahwa instans pengganti dapat dibuat di tempat lain dan pengurangan kapasitas tersebut tidak membebani layanan yang tersisa.

Pola yang sama berfungsi terlepas dari apa yang Anda coba hindari kegagalannya. Misalnya, jika Anda khawatir tentang kegagalan SAN, Anda menghadapi beberapa SAN. Jika Anda khawatir tentang hilangnya satu rak server, Anda menyebarkan beban kerja ke beberapa rak. Jika Anda khawatir tentang hilangnya pusat data, layanan Anda harus berjalan di beberapa wilayah Azure, di beberapa Zona Ketersediaan Azure, atau di seluruh pusat data Anda sendiri.

Saat layanan terbentang di beberapa instans fisik (mesin, rak, pusat data, wilayah), Anda masih rentan terhadap beberapa jenis kegagalan bersamaan. Tetapi kegagalan tunggal dan bahkan beberapa jenis tertentu (misalnya, satu komputer virtual atau tautan jaringan gagal) secara otomatis ditangani dan jadi bukan lagi "bencana."

Service Fabric menyediakan mekanisme untuk memperluas kluster dan mengembalikan simpul dan layanan yang gagal. Service Fabric juga memungkinkan menjalankan banyak instans layanan Anda untuk mencegah kegagalan tak terduga berubah menjadi bencana sebenarnya.

Mungkin ada alasan mengapa menjalankan penyebaran yang cukup besar untuk menjangkau kegagalan tidak layak. Misalnya, mungkin memerlukan lebih banyak sumber daya perangkat keras daripada yang anda bersedia bayar relatif terhadap kemungkinan kegagalan. Saat Anda berhadapan dengan aplikasi terdistribusi, lompatan komunikasi tambahan atau biaya replikasi status di seluruh jarak geografis dapat menyebabkan latensi yang tidak dapat diterima. Di mana baris ini digambar berbeda untuk setiap aplikasi.

Untuk kesalahan perangkat lunak secara khusus, kesalahannya mungkin ada di layanan yang ingin Anda skalakan. Dalam hal ini, lebih banyak salinan tidak mencegah bencana, karena kondisi kegagalan berkorelasi di semua instans.

Kesalahan operasional

Bahkan jika layanan Anda terbentang di seluruh dunia dengan banyak redundansi, layanan tersebut masih dapat mengalami peristiwa bencana. Misalnya, seseorang mungkin secara tidak sengaja mengonfigurasi ulang nama DNS untuk layanan, atau menghapusnya secara langsung.

Sebagai contoh, katakanlah Anda memiliki layanan Service Fabric yang berkeadaan tetap (stateful), dan seseorang menghapus layanan tersebut secara tidak sengaja. Kecuali ada mitigasi lain, layanan itu dan semua keadaan yang ada sekarang telah hilang. Jenis bencana operasional seperti ini memerlukan mitigasi dan langkah-langkah yang berbeda untuk pemulihan dibandingkan dengan kegagalan tak terencana yang biasa.

Cara terbaik untuk menghindari jenis kesalahan operasional ini adalah dengan:

  • Membatasi akses operasional ke lingkungan.
  • Mengaudit operasi berbahaya secara ketat.
  • Menerapkan otomatisasi, mencegah perubahan manual atau di luar jalur umum, dan memvalidasi perubahan spesifik dalam konteks lingkungan sebelum melaksanakannya.
  • Pastikan bahwa operasi destruktif "lunak." Operasi lunak tidak langsung berlaku atau dapat dibatalkan dalam jangka waktu tertentu.

Service Fabric menyediakan mekanisme untuk mencegah kesalahan operasional, seperti menyediakan kontrol akses berbasis peran untuk operasi kluster. Namun, sebagian besar kesalahan operasional ini memerlukan upaya organisasi dan sistem lainnya. Service Fabric memang menyediakan mekanisme untuk menghadapi kesalahan operasional, terutama pencadangan dan pemulihan untuk layanan stateful.

Mengelola kegagalan

Tujuan dari Service Fabric adalah manajemen kegagalan otomatis. Tetapi untuk menangani beberapa jenis kegagalan, layanan harus memiliki kode tambahan. Jenis kegagalan lainnya tidak boleh diatasi secara otomatis karena alasan keamanan dan kelangsungan bisnis.

Menangani kegagalan tunggal

Mesin tunggal dapat gagal karena berbagai alasan. Terkadang itu penyebab perangkat keras, seperti pasokan listrik dan kegagalan perangkat keras jaringan. Kegagalan lain ada dalam perangkat lunak. Ini termasuk kegagalan sistem operasi dan layanan itu sendiri. Service Fabric secara otomatis mendeteksi jenis kegagalan ini, termasuk kasus di mana mesin menjadi terisolasi dari komputer lain karena masalah jaringan.

Terlepas dari jenis layanan, menjalankan satu instance menyebabkan downtime untuk layanan tersebut jika satu salinan kode gagal karena alasan apa pun.

Untuk menangani kegagalan tunggal, hal paling sederhana yang dapat Anda lakukan adalah memastikan bahwa layanan Anda berjalan pada lebih dari satu simpul secara default. Untuk layanan stateless, pastikan lebih besar dari InstanceCount 1. Untuk layanan stateful, rekomendasi minimum adalah bahwa TargetReplicaSetSize dan MinReplicaSetSize keduanya ditetapkan pada 3. Menjalankan lebih banyak salinan kode layanan Anda memastikan bahwa layanan Anda dapat menangani kegagalan tunggal secara otomatis.

Menangani kegagalan terkoordinasi

Kegagalan terkoordinasi dalam kluster dapat disebabkan oleh kegagalan dan perubahan infrastruktur yang direncanakan atau tidak direncanakan, atau perubahan perangkat lunak yang direncanakan. Service Fabric memodelkan zona infrastruktur yang mengalami kegagalan terkoordinasi sebagai domain kesalahan. Area yang akan mengalami perubahan perangkat lunak terkoordinasi dimodelkan sebagai domain peningkatan. Untuk informasi selengkapnya tentang domain kesalahan, domain peningkatan, dan topologi kluster, lihat Menjelaskan kluster Service Fabric dengan menggunakan Cluster Resource Manager.

Secara bawaan, Service Fabric mempertimbangkan domain kerusakan dan peningkatan saat merencanakan di mana layanan Anda harus berjalan. Secara default, Service Fabric mencoba memastikan bahwa layanan Anda berjalan di beberapa domain kesalahan dan peningkatan sehingga jika perubahan yang direncanakan atau tidak direncanakan terjadi, layanan Anda tetap tersedia.

Misalnya, kegagalan sumber daya menyebabkan semua mesin di rak gagal secara bersamaan. Dengan beberapa salinan layanan yang berjalan, kehilangan banyak mesin dalam kegagalan domain kesalahan hanya menjadi contoh lain dari satu kegagalan dalam layanan. Inilah sebabnya mengapa mengelola domain kesalahan serta domain peningkatan sangat penting untuk memastikan layanan Anda tetap tersedia secara optimal.

Saat Anda menjalankan Service Fabric di Azure, domain kesalahan dan domain peningkatan dikelola secara otomatis. Di lingkungan lain, mungkin tidak. Jika Anda membangun kluster Anda sendiri secara lokal, pastikan untuk memetakan dan merencanakan tata letak domain kesalahan Anda dengan benar.

Domain peningkatan berguna untuk memodelkan area di mana perangkat lunak akan ditingkatkan secara bersamaan. Karena itu, domain upgrade juga sering menentukan batas di mana perangkat lunak dimatikan selama peningkatan yang direncanakan. Peningkatan Service Fabric dan layanan Anda mengikuti model yang sama. Untuk informasi selengkapnya tentang pembaruan bergulir, domain pembaruan, dan model kesehatan Service Fabric yang membantu mencegah perubahan yang tidak diinginkan memengaruhi kluster dan layanan Anda, lihat:

Anda dapat memvisualisasikan tata letak kluster Anda dengan menggunakan peta kluster yang disediakan di Service Fabric Explorer:

Simpul yang tersebar di domain kesalahan di Service Fabric Explorer

Nota

Pemodelan area kegagalan, peningkatan bergulir, menjalankan banyak instans kode layanan dan status Anda, aturan penempatan untuk memastikan bahwa layanan Anda berjalan di seluruh domain kesalahan dan peningkatan, dan pemantauan kesehatan bawaan hanyalah beberapa fitur yang disediakan Service Fabric untuk mencegah masalah operasional normal dan kegagalan menjadi bencana.

Menangani kegagalan perangkat keras atau perangkat lunak secara bersamaan

Kami telah berbicara tentang kegagalan tunggal. Seperti yang Anda lihat, layanan ini mudah ditangani untuk layanan stateless dan stateful hanya dengan menyimpan lebih banyak salinan kode (dan status) yang berjalan di seluruh domain kesalahan dan peningkatan.

Beberapa kegagalan acak simultan juga dapat terjadi. Ini lebih mungkin mengakibatkan gangguan atau bencana nyata.

Layanan stateless

Jumlah instans untuk layanan stateless menunjukkan jumlah instans yang diinginkan yang perlu dijalankan. Ketika salah satu (atau semua) instans gagal, Service Fabric merespons dengan secara otomatis membuat instans pengganti pada simpul lain. Service Fabric terus membuat penggantian hingga layanan kembali ke jumlah instans yang diinginkan.

Misalnya, asumsikan bahwa layanan stateless memiliki InstanceCount nilai -1. Nilai ini berarti bahwa satu instans harus berjalan pada setiap simpul dalam kluster. Jika beberapa instans tersebut gagal, Service Fabric akan mendeteksi bahwa layanan tidak dalam keadaan yang diinginkan dan akan mencoba membuat instans pada node tempat mereka hilang.

Layanan stateful

Ada dua jenis layanan stateful:

  • Stateful dengan status persisten.
  • Stateful dengan status tidak bertahan. (Status disimpan dalam memori.)

Pemulihan dari kegagalan layanan stateful tergantung pada jenis layanan stateful, berapa banyak replika yang dimiliki layanan, dan berapa banyak replika yang gagal.

Dalam layanan stateful, data masuk direplikasi antara replika utama dan sekunder aktif apa pun. Jika sebagian besar replika menerima data, data dianggap sebagai kuorum yang diterapkan. (Untuk lima replika, tiga akan menjadi kuorum.) Ini berarti bahwa pada titik mana pun, setidaknya akan ada kuorum replika dengan data terbaru. Jika replika gagal (katakanlah dua dari lima), kita dapat menggunakan nilai kuorum untuk menghitung apakah kita dapat pulih. (Karena tiga dari lima replika yang tersisa masih aktif, dijamin setidaknya satu replika akan memiliki data lengkap.)

Ketika kuorum replika gagal, partisi dinyatakan berada dalam status kehilangan kuorum . Katakanlah partisi memiliki lima replika, yang berarti bahwa setidaknya tiga dijamin memiliki data lengkap. Jika kuorum (tiga dari lima) replika gagal, Service Fabric tidak dapat menentukan apakah replika yang tersisa (dua dari lima) memiliki data yang cukup untuk memulihkan partisi. Dalam kasus di mana Service Fabric mendeteksi kehilangan kuorum, perilaku defaultnya adalah mencegah penulisan tambahan ke partisi, menyatakan kehilangan kuorum, dan menunggu kuorum replika dipulihkan.

Menentukan apakah bencana terjadi untuk layanan stateful dan kemudian mengelolanya mengikuti tiga tahap:

  1. Menentukan apakah telah ada kerugian kuorum atau tidak.

    Kehilangan kuorum dinyatakan ketika sebagian besar replika layanan stateful tidak berfungsi pada saat yang sama.

  2. Menentukan apakah kerugian kuorum bersifat permanen atau tidak.

    Sebagian besar waktu, kegagalan bersifat sementara. Proses dimulai ulang, node dimulai ulang, mesin virtual diluncurkan kembali, dan partisi jaringan pulih. Namun, terkadang, kegagalan bersifat permanen. Apakah kegagalan bersifat permanen atau tidak tergantung pada apakah layanan stateful mempertahankan statusnya atau apakah itu hanya menyimpannya dalam memori:

    • Untuk layanan tanpa status persisten, kegagalan kuorum atau lebih replika segera menghasilkan kehilangan kuorum permanen. Ketika Service Fabric mendeteksi kehilangan batas kuorum dalam sebuah layanan stateful yang non-persisten, layanan tersebut segera melanjutkan ke langkah 3 dengan menyatakan (potensi) kehilangan data. Melanjutkan ke situasi kehilangan data adalah pilihan yang masuk akal karena Service Fabric mengetahui bahwa menunggu replika kembali tidak ada gunanya. Bahkan jika mereka pulih, data akan hilang karena sifat layanan yang tidak menyimpan data secara permanen.
    • Untuk layanan persisten stateful, kegagalan kuorum atau lebih dari replika menyebabkan Service Fabric harus menunggu replika-replika untuk kembali dan memulihkan kuorum tersebut. Ini menyebabkan gangguan layanan untuk setiap penulisan ke partisi layanan yang terpengaruh (atau "set replika"). Namun, bacaan mungkin masih dimungkinkan dengan jaminan konsistensi yang berkurang. Jumlah waktu default yang ditunda Service Fabric untuk kuorum dipulihkan tidak terbatas, karena melanjutkan adalah peristiwa kehilangan data (potensial) dan membawa risiko lain. Ini berarti bahwa Service Fabric tidak akan melanjutkan ke langkah berikutnya kecuali administrator mengambil tindakan untuk menyatakan kehilangan data.

  3. Menentukan apakah data hilang, dan memulihkan dari cadangan.

    Jika kehilangan kuorum telah dinyatakan (baik secara otomatis atau melalui tindakan administratif), Service Fabric dan layanan melanjutkan untuk menentukan apakah data benar-benar hilang. Pada titik ini, Service Fabric juga tahu bahwa replika lain tidak akan kembali. Itu adalah keputusan yang dibuat ketika kami berhenti menunggu kehilangan kuorum untuk menyelesaikannya sendiri. Tindakan terbaik untuk layanan ini biasanya membekukan dan menunggu intervensi administratif tertentu.

    Ketika Service Fabric memanggil metode OnDataLossAsync, itu selalu karena dugaan kehilangan data. Service Fabric memastikan bahwa panggilan ini dikirimkan ke replika terbaik yang tersisa. Ini adalah replika mana pun yang telah membuat kemajuan terbanyak.

    Alasan kami selalu mengatakan dugaan kehilangan data adalah karena kemungkinan replika yang tersisa memiliki semua keadaan yang sama dengan yang dimiliki oleh yang utama tatkala kuorum hilang. Namun, tanpa status itu untuk membandingkannya dengan, tidak ada cara yang baik bagi Service Fabric atau operator untuk mengetahui dengan pasti.

    Jadi, apa yang biasanya dilakukan oleh implementasi metode OnDataLossAsync ini?

    1. Catatan implementasi menunjukkan bahwa OnDataLossAsync telah dipicu, dan mengaktifkan peringatan administratif yang diperlukan.

    2. Biasanya, implementasi berhenti sejenak dan menunggu keputusan lebih lanjut dan tindakan manual diambil. Ini karena bahkan jika cadangan tersedia, cadangan mungkin perlu disiapkan.

      Misalnya, jika dua layanan yang berbeda mengoordinasikan informasi, cadangan tersebut mungkin perlu dimodifikasi untuk memastikan bahwa setelah pemulihan terjadi, informasi yang dipedulikan kedua layanan tersebut konsisten.

    3. Seringkali ada beberapa telemetri atau data sampingan lain dari layanan. Metadata ini mungkin terkandung dalam layanan lain atau dalam log. Informasi ini dapat digunakan sesuai kebutuhan untuk menentukan apakah ada panggilan yang diterima dan diproses di primer yang tidak ada dalam cadangan atau direplikasi ke replika khusus ini. Panggilan ini mungkin perlu diputar ulang atau ditambahkan ke cadangan sebelum pemulihan dapat dilakukan.

    4. Implementasi membandingkan status replika yang tersisa dengan yang terkandung dalam cadangan yang tersedia. Jika Anda menggunakan koleksi andal dari Service Fabric, tersedia alat dan proses untuk mendukung penggunaannya. Tujuannya adalah untuk melihat apakah status dalam replika sudah cukup, dan untuk melihat apa cadangan yang mungkin hilang.

    5. Setelah perbandingan selesai, dan setelah pemulihan selesai (jika perlu), kode layanan harus mengembalikan true jika ada perubahan status yang dilakukan. Jika replika menentukan bahwa itu adalah salinan status terbaik yang tersedia dan tidak membuat perubahan, kode mengembalikan false.

      Nilai true menunjukkan bahwa replika lain yang tersisa sekarang mungkin tidak konsisten dengan yang satu ini. Mereka akan dihilangkan dan dibangun kembali dari replika ini. Nilai false menunjukkan bahwa tidak ada perubahan status yang dilakukan, sehingga replika lain dapat menyimpan apa yang mereka miliki.

Sangat penting bahwa penulis layanan mempraktikkan skenario potensi kehilangan data dan kegagalan sebelum layanan disebarkan dalam produksi. Untuk melindungi dari kemungkinan kehilangan data, penting untuk secara berkala mencadangkan status setiap layanan stateful Anda ke penyimpanan geo-redundan.

Anda juga harus memastikan bahwa Anda memiliki kemampuan untuk memulihkan keadaan. Karena cadangan dari berbagai layanan diambil pada waktu yang berbeda, Anda perlu memastikan bahwa setelah pemulihan, layanan Anda memiliki tampilan yang konsisten satu sama lain.

Misalnya, pertimbangkan situasi di mana satu layanan menghasilkan angka dan menyimpannya, lalu mengirimkannya ke layanan lain yang juga menyimpannya. Setelah pemulihan, Anda mungkin menemukan bahwa layanan kedua memiliki angka tetapi yang pertama tidak, karena cadangannya tidak menyertakan operasi tersebut.

Jika Anda mengetahui bahwa replika yang tersisa tidak cukup untuk melanjutkan dalam skenario kehilangan data, dan Anda tidak dapat membangun kembali status layanan dari telemetri atau sumber lainnya, frekuensi pencadangan Anda menentukan tujuan titik pemulihan terbaik Anda (RPO). Service Fabric menyediakan banyak alat untuk menguji berbagai skenario kegagalan, termasuk kuorum permanen dan kehilangan data yang memerlukan pemulihan dari cadangan. Skenario ini disertakan sebagai bagian dari alat uji coba di Service Fabric, yang dikelola oleh Fault Analysis Service. Untuk informasi selengkapnya tentang alat dan pola tersebut, lihat Pengantar Layanan Analisis Kesalahan.

Nota

Layanan sistem juga dapat mengalami kehilangan kuorum. Dampaknya khusus untuk layanan yang dimaksud. Misalnya, kehilangan kuorum dalam layanan penamaan memengaruhi resolusi nama, sedangkan kehilangan kuorum dalam layanan Manajer Failover memblokir pembuatan dan failover layanan baru.

Layanan sistem Service Fabric mengikuti pola yang sama dengan layanan Anda untuk pengelolaan status, tetapi kami tidak menyarankan agar Anda mencoba memindahkannya dari kehilangan kuorum menuju potensi kehilangan data. Sebagai gantinya, kami sarankan Anda mencari dukungan untuk menemukan solusi yang ditargetkan untuk situasi Anda. Biasanya lebih disukai untuk hanya menunggu sampai replika yang tidak aktif kembali.

Pemecahan masalah kehilangan kuorum

Replika mungkin mengalami gangguan karena kegagalan sementara. Tunggu beberapa saat karena Service Fabric mencoba mengaktifkannya. Jika replika telah tidak berfungsi selama lebih dari durasi yang diharapkan, ikuti tindakan pemecahan masalah berikut:

  • Replika-replika mungkin mengalami kerusakan. Periksa laporan kesehatan tingkat replika dan log aplikasi Anda. Kumpulkan data kerusakan dan ambil tindakan yang perlu untuk memulihkan.
  • Proses replika mungkin menjadi tidak responsif. Periksa log aplikasi Anda untuk memverifikasi ini. Kumpulkan cadangan proses lalu hentikan proses yang tidak responsif. Service Fabric akan membuat proses penggantian dan akan mencoba membawa replika kembali.
  • Node yang menghosting replika mungkin tidak berfungsi. Mulai ulang komputer virtual inti untuk mengaktifkan simpul.

Terkadang, mungkin tidak mungkin untuk memulihkan replika. Misalnya, drive telah gagal atau komputer secara fisik tidak merespons. Dalam kasus ini, Service Fabric perlu diberitahu untuk tidak menunggu pemulihan replika.

Jangan gunakan metode ini jika potensi kehilangan data tidak dapat diterima untuk membuat layanan online. Dalam hal ini, semua upaya harus dilakukan untuk memulihkan mesin fisik.

Tindakan berikut mungkin mengakibatkan kehilangan data. Periksa sebelum Anda mengikutinya.

Nota

Tidak pernah aman untuk menggunakan metode ini selain dengan cara yang ditargetkan terhadap partisi tertentu.

  • Gunakan API Repair-ServiceFabricPartition -PartitionId atau System.Fabric.FabricClient.ClusterManagementClient.RecoverPartitionAsync(Guid partitionId). API ini memungkinkan untuk menentukan ID partisi agar keluar dari keadaan kehilangan kuorum dan menuju kemungkinan kehilangan data.
  • Jika kluster Anda sering mengalami kegagalan yang menyebabkan layanan masuk ke status kehilangan kuorum dan potensi kehilangan data dapat diterima, menentukan nilai QuorumLossWaitDuration yang sesuai dapat membantu layanan Anda pulih secara otomatis. Service Fabric akan menunggu nilai yang disediakan QuorumLossWaitDuration (defaultnya tidak terbatas) sebelum melakukan pemulihan. Kami tidak merekomendasikan metode ini karena dapat menyebabkan kehilangan data yang tidak terduga.

Ketersediaannya Kluster Service Fabric

Secara umum, kluster Service Fabric adalah lingkungan yang sangat terdistribusi tanpa titik kegagalan tunggal. Kegagalan satu node tidak akan menyebabkan masalah ketersediaan atau keandalan untuk kluster, terutama karena layanan sistem Service Fabric mengikuti pedoman yang sama yang disediakan sebelumnya. Artinya, mereka selalu berjalan dengan tiga atau lebih replika secara default, dan layanan sistem yang tidak memiliki status berjalan di semua simpul.

Lapisan jaringan dan deteksi kegagalan pada Service Fabric yang mendasar sepenuhnya didistribusikan. Sebagian besar layanan sistem dapat dibangun kembali dari metadata dalam kluster, atau tahu cara menyinkronkan ulang statusnya dari tempat lain. Ketersediaan kluster dapat terganggu jika layanan sistem mengalami situasi kehilangan kuorum seperti yang dijelaskan sebelumnya. Dalam kasus ini, Anda mungkin tidak dapat melakukan operasi tertentu pada kluster (seperti memulai peningkatan atau menyebarkan layanan baru), tetapi kluster itu sendiri masih aktif.

Layanan pada kluster yang sedang berjalan akan terus berjalan dalam kondisi ini kecuali memerlukan penulisan ke layanan sistem untuk terus berfungsi. Misalnya, jika Manajer Failover mengalami kehilangan kuorum, semua layanan akan terus berjalan. Tetapi layanan apa pun yang gagal tidak akan dapat dimulai ulang secara otomatis, karena ini memerlukan keterlibatan Failover Manager.

Kegagalan pusat data atau wilayah Azure

Dalam kasus yang jarang terjadi, pusat data fisik dapat menjadi tidak tersedia untuk sementara waktu karena hilangnya daya atau konektivitas jaringan. Dalam kasus ini, kluster dan layanan Service Fabric Anda di pusat data atau wilayah Azure tersebut tidak akan tersedia. Namun, data Anda dipertahankan.

Untuk kluster yang berjalan di Azure, Anda dapat melihat pembaruan tentang pemadaman di halaman status Azure. Dalam kejadian yang sangat tidak mungkin bahwa pusat data fisik sebagian atau sepenuhnya hancur, setiap kluster Service Fabric yang dihosting di sana, atau layanan di dalamnya, mungkin hilang. Kerugian ini mencakup data atau informasi apa pun yang tidak dicadangkan di luar pusat data atau wilayah tersebut.

Ada beberapa strategi berbeda untuk bertahan dari kegagalan permanen atau berkelanjutan dari satu pusat data atau wilayah:

  • Jalankan kluster Service Fabric yang terpisah di beberapa wilayah, dan gunakan mekanisme tertentu untuk failover dan failback di antara lingkungan-lingkungan ini. Jenis model aktif/aktif/aktif/pasif multi-kluster ini memerlukan kode manajemen dan operasi tambahan. Model ini juga memerlukan koordinasi cadangan dari layanan di satu pusat data atau wilayah sehingga tersedia di pusat data atau wilayah lain ketika satu gagal.

  • Jalankan satu kluster Service Fabric yang mencakup beberapa pusat data. Konfigurasi minimum yang didukung untuk strategi ini adalah tiga pusat data. Untuk informasi selengkapnya, lihat Menyebarkan kluster Service Fabric di seluruh Zona Ketersediaan.

    Model ini memerlukan penyiapan tambahan. Namun, manfaatnya adalah bahwa kegagalan satu pusat data dikonversi dari bencana menjadi kegagalan normal. Kegagalan ini dapat ditangani oleh mekanisme yang berfungsi untuk kluster dalam satu wilayah. Domain kesalahan operasional, domain peningkatan, dan aturan penempatan Service Fabric memastikan bahwa beban kerja didistribusikan sehingga dapat mentolerir kegagalan biasa.

    Untuk informasi selengkapnya tentang kebijakan yang dapat membantu mengoperasikan layanan dalam jenis kluster ini, lihat Kebijakan penempatan untuk layanan Service Fabric.

  • Jalankan satu kluster Service Fabric yang mencakup beberapa wilayah menggunakan model Mandiri. Jumlah wilayah yang direkomendasikan adalah tiga. Lihat Membuat kluster mandiri untuk detail tentang penyiapan Service Fabric mandiri.

Kegagalan acak yang menyebabkan kegagalan kluster

Service Fabric memiliki konsep seed nodes. Ini adalah simpul yang mempertahankan ketersediaan kluster yang menjadi dasar.

Node benih membantu memastikan bahwa kluster tetap aktif dengan membuat sewa dengan node lain dan berfungsi sebagai pemangku tiebreaker selama jenis kegagalan tertentu. Jika kegagalan acak menghapus sebagian besar node benih dalam kluster dan tidak dibawa kembali dengan cepat, kluster Anda secara otomatis dimatikan. Kluster tersebut kemudian mengalami kegagalan.

Di Azure, Penyedia Sumber Daya Service Fabric mengelola konfigurasi kluster Service Fabric. Pada dasarnya, Penyedia Sumber Daya mendistribusikan simpul benih ke seluruh domain kesalahan dan peningkatan untuk jenis node utama. Jika tipe node utama ditandai sebagai durabilitas Silver atau Gold, ketika Anda menghapus node seed (baik dengan penskalaan pada tipe node utama Anda atau dengan menghapusnya secara manual), cluster akan mencoba mempromosikan node non-seed lain dari kapasitas tipe node utama yang tersedia. Upaya ini akan gagal jika Anda memiliki kapasitas yang kurang tersedia daripada tingkat keandalan kluster yang diperlukan untuk jenis node utama Anda.

Dalam kluster Service Fabric yang berdiri sendiri dan Azure, jenis node utama adalah yang menjalankan seeds. Ketika Anda mendefinisikan jenis node utama, Service Fabric akan secara otomatis memanfaatkan jumlah simpul yang disediakan dengan membuat hingga sembilan node seed dan tujuh replika dari setiap layanan sistem. Jika serangkaian kegagalan acak menghilangkan sebagian besar replika tersebut secara bersamaan, layanan sistem akan mengalami kehilangan kuorum. Jika sebagian besar node benih hilang, kluster akan dimatikan segera setelahnya.

Langkah berikutnya

  • Last updated on