Bagikan melalui

Pemulihan bencana di Azure Service Fabric

  • Artikel

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

Artikel ini menjelaskan beberapa mode kegagalan umum yang mungkin merupakan bencana jika tidak dimodelkan dan dikelola dengan benar. Ini juga membahas mitigasi dan tindakan yang harus diambil jika bencana terjadi. Tujuannya adalah untuk membatasi atau menghilangkan risiko downtime 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 sedemikian rupa sehingga jenis kegagalan umum bukanlah 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 bisa diprediksi. Cara termudah untuk bertahan dari kesalahan adalah menjalankan lebih banyak salinan layanan di seluruh batas kesalahan perangkat keras atau perangkat lunak.

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

Pola yang sama berfungsi terlepas dari kegagalan yang Anda coba hindari. Misalnya, jika Anda khawatir tentang kegagalan SAN, Anda menjalankan di beberapa SAN. Jika Anda khawatir tentang hilangnya rak server, jalankan di 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 tersebar di beberapa instans fisik (mesin, rak, pusat data, wilayah), Anda masih mengalami beberapa jenis kegagalan simultan. Tetapi kegagalan tunggal dan bahkan beberapa jenis tertentu (misalnya, satu mesin virtual atau tautan jaringan gagal) secara otomatis ditangani dan tidak lagi menjadi "bencana".

Service Fabric menyediakan mekanisme untuk memperluas kluster dan menangani membawa simpul dan layanan yang gagal kembali. Service Fabric juga memungkinkan menjalankan banyak instans layanan Anda untuk mencegah kegagalan yang tidak direncanakan berubah menjadi bencana nyata.

Mungkin ada alasan mengapa menjalankan penyebaran yang cukup besar untuk rentang kegagalan tidak layak. Misalnya, mungkin perlu lebih banyak sumber daya perangkat keras daripada yang Anda bersedia membayar relatif terhadap kemungkinan kegagalan. Saat Anda berurusan dengan aplikasi terdistribusi, hop 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

Meskipun layanan Anda membentang di seluruh dunia dengan banyak redundansi, itu 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 stateful, dan seseorang menghapus layanan itu secara tidak sengaja. Kecuali ada beberapa mitigasi lain, layanan itu dan semua negara bahwa itu sekarang hilang. Jenis bencana operasional ini ("ups") memerlukan mitigasi dan langkah-langkah yang berbeda untuk pemulihan daripada kegagalan reguler yang tidak direncanakan.

Cara terbaik untuk menghindari jenis kesalahan operasional ini adalah dengan:

  • Membatasi akses operasional ke lingkungan.
  • Mengaudit operasi berbahaya secara ketat.
  • Memberlakukan otomatisasi, mencegah perubahan manual atau di luar band, dan memvalidasi perubahan spesifik terhadap lingkungan sebelum memberlakukannya.
  • Pastikan bahwa operasi destruktif bersifat "lunak". Operasi lunak tidak langsung diterapkan atau dapat dibatalkan dalam sela 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 bertahan dari kesalahan operasional, terutama pencadangan dan pemulihan untuk layanan stateful.

Mengelola kegagalan

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

Menangani kegagalan tunggal

Mesin tunggal dapat gagal karena segala macam alasan. Terkadang itu penyebab perangkat keras, seperti pasokan listrik dan kegagalan perangkat keras jaringan. Kegagalan lainnya 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 mesin lain karena masalah jaringan.

Terlepas dari jenis layanan, menjalankan satu instans menghasilkan waktu henti untuk layanan tersebut jika salinan tunggal kode tersebut 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 InstanceCount lebih besar dari 1. Untuk layanan stateful, rekomendasi minimum adalah TargetReplicaSetSize dan MinReplicaSetSize diatur ke 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 membuat model 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 default, Service Fabric mempertimbangkan kesalahan dan meningkatkan domain 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, hilangnya banyak mesin dalam kegagalan domain kesalahan berubah menjadi contoh lain dari satu kegagalan untuk layanan. Inilah sebabnya mengapa mengelola domain kesalahan dan peningkatan sangat penting untuk memastikan ketersediaan layanan yang tinggi.

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

Domain peningkatan berguna untuk memodelkan area di mana perangkat lunak akan ditingkatkan pada saat yang sama. Karena itu, domain peningkatan juga sering menentukan batas di mana perangkat lunak dihapus selama peningkatan yang direncanakan. Peningkatan Service Fabric dan layanan Anda mengikuti model yang sama. Untuk informasi selengkapnya tentang peningkatan bergulir, peningkatan domain, 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

Catatan

Area pemodelan kegagalan, peningkatan bergulir, menjalankan banyak contoh 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 menjaga masalah operasional normal dan kegagalan berubah menjadi bencana.

Menangani kegagalan perangkat keras atau perangkat lunak secara bersamaan

Kami telah membahas tentang kegagalan tunggal. Seperti yang Anda lihat, mereka 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 menyebabkan downtime atau bencana yang sebenarnya.

Layanan stateless

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

Misalnya, asumsikan bahwa layanan stateless memiliki nilai InstanceCount -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 simpul saat hilang.

Layanan stateful

Ada dua jenis layanan stateful:

  • Negara dengan status persisten.
  • Stateful dengan status non-persiten. (Status disimpan dalam memori.)

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

Dalam layanan stateful , data masuk direplikasi antara replika (sekunder utama dan aktif apa pun). Jika sebagian besar replika menerima data, data dianggap sebagai kuorum yang dilakukan. (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 (misalnya dua dari lima), kita dapat menggunakan nilai kuorum untuk menghitung apakah dapat memulihkannya. (Karena tiga dari lima replika yang tersisa masih naik, dijamin setidaknya satu replika akan memiliki data lengkap.)

Ketika kuorum replika gagal, partisi dinyatakan berada dalam status kehilangan kuorum. Misalnya, 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 terjadi kerugian kuorum atau tidak.

    Kerugian kuorum dinyatakan ketika sebagian besar replika layanan stateful pada saat yang sama.

  2. Menentukan apakah kerugian kuorum bersifat permanen atau tidak.

    Sebagian besar waktu, kegagalan bersifat sementara. Proses dimulai ulang, simpul dimulai ulang, komputer virtual diluncurkan kembali, dan pemulihan partisi jaringan. Terkadang, kegagalan bersifat permanen. Apakah kegagalan bersifat permanen atau tidak tergantung pada apakah layanan stateful mempertahankan statusnya atau apakah menyimpannya hanya dalam memori:

    • Untuk layanan tanpa status persisten, kegagalan kuorum atau lebih dari replika segera mengakibatkan kerugian kuorum permanen. Ketika Service Fabric mendeteksi kehilangan kuorum dalam layanan non-persisten yang bernegara, kain ini segera melanjutkan ke langkah 3 dengan menyatakan (potensi) kehilangan data. Melanjutkan ke kehilangan data masuk akal karena Service Fabric tahu bahwa tidak ada gunanya menunggu replika kembali. Bahkan jika sudah pulih, data akan hilang karena sifat layanan non-persisten.
    • Untuk layanan persisten stateful, kegagalan kuorum atau lebih dari replika menyebabkan Service Fabric menunggu replika kembali dan memulihkan kuorum. Ini mengakibatkan pemadaman layanan untuk setiap tulisan ke partisi yang terpengaruh (atau "set replika") dari layanan. Namun, bacaan mungkin masih dimungkinkan dengan jaminan konsistensi yang berkurang. Jumlah waktu default yang Service Fabric menunggu kuorum dipulihkan tidak terbatas, karena proses adalah (potensi) peristiwa kehilangan data 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 kerugian kuorum telah dinyatakan (baik secara otomatis atau melalui tindakan administratif), Service Fabric dan layanan beralih ke 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 kerugian kuorum untuk menyelesaikan sendiri. Tindakan terbaik untuk layanan ini biasanya untuk membekukan dan menunggu intervensi administratif tertentu.

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

    Alasan kami selalu mengatakan dugaan kehilangan data adalah bahwa ada kemungkinan bahwa replika yang tersisa memiliki semua keadaan yang sama seperti yang dilakukan utama ketika kuorum hilang. Namun, tanpa status tersebut untuk membandingkannya dengan, tidak ada cara yang baik bagi Service Fabric atau operator untuk mengetahui dengan pasti.

    Jadi apa implementasi khas metode OnDataLossAsync ini?

    1. Implementasi mencatat bahwa OnDataLossAsync telah dipicu, dan menembakkan peringatan administratif yang diperlukan.

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

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

    3. Sering kali ada beberapa telemetri atau pembuangan lain dari layanan. Metadata ini mungkin berada dalam layanan lain atau 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 layak.

    4. Implementasi membandingkan status replika yang tersisa dengan yang terkandung dalam cadangan yang tersedia. Jika Anda menggunakan reliable collections Service Fabric, ada alat dan proses yang tersedia untuk melakukannya. Tujuannya adalah untuk melihat apakah status dalam replika cukup, dan untuk melihat apa cadangan 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. Nilai akan diturunkan 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 kerugian data dan kegagalan sebelum layanan disebarkan dalam produksi. Untuk melindungi dari kemungkinan kehilangan data, penting untuk secara berkala mencadangkan status layanan negara Anda ke toko geo-redundan.

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

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

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

Catatan

Layanan sistem juga dapat mengalami kerugian kuorum. Dampaknya khusus untuk layanan yang bersangkutan. Misalnya, kehilangan kuorum dalam layanan penamaan mempengaruhi resolusi nama, sedangkan kerugian kuorum dalam layanan Manajer Kegagalan memblokir pembuatan dan kegagalan layanan baru.

Layanan sistem Service Fabric mengikuti pola yang sama dengan layanan Anda untuk manajemen negara, tetapi kami tidak merekomendasikan Anda mencoba untuk memindahkannya keluar dari kerugian kuorum dan menjadi potensi kehilangan data. Sebagai gantinya, kami menyarankan Anda mencari dukungan untuk menemukan solusi yang sesuai dengan situasi Anda. Biasanya lebih baik hanya menunggu sampai replika yang tidak berfungsi kembali.

Pemecahan masalah kerugian kuorum

Replika mungkin tidak berfungsi secara terputus-putus karena kegagalan sementara. Tunggu beberapa waktu karena Service Fabric mencoba untuk memulihkannya. Jika replika telah turun selama lebih dari durasi yang diharapkan, ikuti tindakan pemecahan masalah ini:

  • Replika mungkin mengalami crash. Periksa laporan kesehatan tingkat replika dan log aplikasi Anda. Kumpulkan crash dump dan ambil tindakan yang diperlukan untuk memulihkan.
  • Proses replika mungkin menjadi tidak responsif. Periksa log aplikasi Anda untuk memverifikasi hal ini. Kumpulkan cadangan proses, lalu hentikan proses yang tidak responsif. Service Fabric akan membuat proses penggantian dan akan mencoba membawa replika kembali.
  • Simpul yang menghosting replika mungkin tidak berfungsi. Mulai ulang komputer virtual yang mendasarinya untuk memunculkan simpul.

Kadang-kadang, mungkin tidak mungkin untuk memulihkan replika. Misalnya, drive telah gagal atau mesin 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 membawa layanan online. Dalam hal ini, semua upaya harus dilakukan untuk memulihkan mesin fisik.

Tindakan berikut dapat mengakibatkan hilangnya data. Periksa sebelum Anda mengikuti mereka.

Catatan

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

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

Ketersediaan kluster Service Fabric

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

Jaringan Service Fabric ervis yang mendasari dan lapisan deteksi kegagalan sepenuhnya didistribusikan. Sebagian besar layanan sistem dapat dibangun kembali dari metadata dalam kluster, atau mengetahui cara menyinkronkan ulang status mereka dari tempat lain. Ketersediaan kluster dapat dikompromikan jika layanan sistem masuk ke situasi kerugian 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 berfungsi.

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

Kegagalan pusat data atau wilayah Azure

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

Untuk kluster yang berjalan di Azure, Anda dapat melihat peningkatan pada pemadaman pada halaman status Azure. Dalam hal yang sangat tidak mungkin bahwa pusat data fisik sebagian atau sepenuhnya dihancurkan, kluster Service Fabric apa pun yang dihosting di sana, atau layanan di dalamnya, mungkin hilang. Kerugian ini mencakup keadaan apa pun yang tidak dicadangkan di luar pusat data atau wilayah tersebut.

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

  • Jalankan kluster Service Fabric terpisah di beberapa wilayah tersebut, dan gunakan beberapa mekanisme untuk kegagalan dan failback di antara lingkungan ini. Jenis model aktif/pasif atau beberapa kluster aktif/aktif ini memerlukan manajemen dan kode operasi tambahan. Model ini juga memerlukan koordinasi pencadangan dari layanan dalam satu pusat data atau wilayah sehingga tersedia di pusat data atau wilayah lain ketika ada yang 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, keuntungan dari model ini adalah konversi kegagalan satu pusat data atau wilayah dari bencana menjadi kegagalan normal. Kegagalan ini dapat ditangani oleh mekanisme yang bekerja untuk kluster dalam satu wilayah. Domain kesalahan, domain peningkatan, dan aturan penempatan Service Fabric memastikan bahwa beban kerja didistribusikan sehingga mentolerir kegagalan normal.

    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 lima. Lihat Membuat kluster mandiri untuk detail tentang pengaturan Service Fabric mandiri.

Kegagalan acak yang menyebabkan kegagalan kluster

Service Fabric memiliki konsep simpul nilai awal. Ini adalah simpul yang mempertahankan ketersediaan kluster yang mendasarinya.

Simpul nilai awal membantu memastikan bahwa kluster tetap terjaga dengan menetapkan sewa dengan simpul lain dan berfungsi sebagai tiebreaker selama jenis kegagalan tertentu. Jika kegagalan acak menghapus sebagian besar simpul benih dalam kluster dan tidak dibawa kembali dengan cepat, kluster Anda akan mati secara otomatis. Kluster kemudian gagal.

Di Azure, Penyedia Sumber Daya Service Fabric mengelola konfigurasi kluster Service Fabric. Secara default, Penyedia Sumber Daya mendistribusikan simpul benih di seluruh domain kesalahan dan peningkatan untuk jenis simpul utama. Jika jenis simpul utama ditandai sebagai ketahanan Silver atau Gold, ketika Anda menghapus simpul nilai awal (baik dengan penskalaan pada jenis simpul utama Anda atau dengan menghapusnya secara manual), kluster akan mencoba mempromosikan simpul selain nilai awal lain dari kapasitas tipe simpul utama yang tersedia. Upaya ini akan gagal jika Anda memiliki kapasitas yang kurang tersedia daripada tingkat keandalan kluster yang diperlukan untuk jenis simpul utama Anda.

Di kedua kluster Service Fabric mandiri dan Azure, jenis simpul utama adalah yang menjalankan nilai awal. Ketika Anda mendefinisikan jenis simpul utama, Service Fabric akan secara otomatis memanfaatkan jumlah simpul yang disediakan dengan membuat hingga sembilan simpul benih dan tujuh replika setiap layanan sistem. Jika serangkaian kegagalan acak mengeluarkan sebagian besar replika tersebut secara bersamaan, layanan sistem akan memasuki kerugian kuorum. Jika sebagian besar simpul benih hilang, kluster akan dinonaktifkan segera setelahnya.

Langkah berikutnya