Mencadangkan dan memulihkan Reliable Services dan Reliable Actor

Azure Service Fabric adalah platform ketersediaan tinggi yang mereplikasi status di beberapa simpul untuk mempertahankan ketersediaan tinggi ini. Dengan demikian, bahkan jika satu simpul dalam kluster gagal, layanan terus tersedia. Meskipun redundansi bawaan yang disediakan oleh platform ini mungkin cukup untuk beberapa orang, dalam kasus tertentu diinginkan agar layanan mencadangkan data (ke penyimpanan eksternal).

Nota

Sangat penting untuk mencadangkan dan memulihkan data Anda (dan menguji bahwa data berfungsi seperti yang diharapkan) sehingga Anda dapat pulih dari skenario kehilangan data.

Nota

Microsoft merekomendasikan untuk menggunakan pencadangan dan pemulihan berkala untuk mengonfigurasi pencadangan data layanan Reliable Stateful dan Reliable Actor.

Misalnya, layanan mungkin ingin mencadangkan data untuk melindungi dari skenario-skenario berikut:

• Jika seluruh kluster Service Fabric hilang secara permanen.
• Kehilangan permanen sebagian besar replika partisi layanan
• Kesalahan administratif di mana status secara tidak sengaja dihapus atau rusak. Misalnya, ini dapat terjadi jika administrator dengan hak istimewa yang memadai secara keliru menghapus layanan.
• Bug dalam layanan yang menyebabkan kerusakan data. Misalnya, ini mungkin terjadi ketika peningkatan kode layanan mulai menulis data yang rusak ke Reliable Collection. Dalam kasus seperti itu, kode dan data mungkin harus dikembalikan ke status sebelumnya.
• Pemrosesan data offline. Mungkin lebih mudah untuk memiliki pemrosesan data offline untuk kecerdasan bisnis yang terjadi secara terpisah dari layanan yang menghasilkan data.

Fitur Pencadangan/Pemulihan memungkinkan layanan yang dibangun di RELIABLE Services API untuk membuat dan memulihkan cadangan. API cadangan yang disediakan oleh platform memungkinkan pencadangan status partisi layanan, tanpa memblokir operasi baca atau tulis. API pemulihan memungkinkan status partisi layanan dipulihkan dari cadangan yang dipilih.

Jenis Pencadangan

Ada dua opsi pencadangan: Penuh dan Bertahap. Pencadangan penuh adalah cadangan yang berisi semua data yang diperlukan untuk membuat ulang status replika: titik pemeriksaan dan semua rekaman log. Karena memiliki titik pemeriksaan dan log, cadangan lengkap dapat dipulihkan dengan sendirinya.

Masalah dengan pencadangan penuh muncul ketika titik pemeriksaan besar. Misalnya, replika yang memiliki status 16 GB akan memiliki cek poin yang berjumlah sekitar 16 GB. Jika kita memiliki Tujuan Pemulihan Titik (RPO) lima menit, replika perlu dicadangkan setiap lima menit. Setiap kali mencadangkan, ia perlu menyalin 16 GB cek poin selain 50 MB log (dapat dikonfigurasi menggunakan CheckpointThresholdInMB).

Solusi untuk masalah ini adalah pencadangan bertambah bertahap, di mana pencadangan hanya berisi rekaman log yang diubah sejak cadangan terakhir.

Karena pencadangan inkremental hanya perubahan sejak pencadangan terakhir (tidak menyertakan titik pemeriksaan), pencadangan tersebut cenderung lebih cepat tetapi tidak dapat dipulihkan sendiri. Untuk memulihkan cadangan inkremental, seluruh rantai cadangan diperlukan. Rantai cadangan adalah rantai pencadangan yang dimulai dengan pencadangan penuh dan diikuti oleh sejumlah pencadangan inkremental yang berdampingan.

Layanan Cadangan yang Andal

Pembuat layanan memiliki kontrol penuh tentang kapan harus membuat cadangan dan di mana cadangan akan disimpan.

Untuk memulai pencadangan, layanan perlu memanggil fungsi anggota BackupAsync yang diwariskan.
Pencadangan hanya dapat dilakukan dari replika utama, dan memerlukan status tulis yang diberikan.

Seperti yang ditunjukkan di bawah ini, BackupAsync menerima objek BackupDescription di mana Anda dapat menentukan cadangan penuh atau bertahap, serta fungsi callback, Func<< BackupInfo, CancellationToken, Task<bool>>> yang dipanggil ketika folder cadangan telah dibuat secara lokal dan siap untuk dipindahkan ke penyimpanan eksternal.

BackupDescription myBackupDescription = new BackupDescription(BackupOption.Incremental,this.BackupCallbackAsync);

await this.BackupAsync(myBackupDescription);

Permintaan untuk mengambil cadangan inkremental dapat gagal dengan FabricMissingFullBackupException. Pengecualian ini menunjukkan bahwa salah satu hal berikut ini terjadi:

• replika belum pernah mengambil cadangan penuh karena telah menjadi primer,
• beberapa catatan log sejak pencadangan terakhir telah dipotong atau
• replika melewati MaxAccumulatedBackupLogSizeInMB batas.

Pengguna dapat meningkatkan kemungkinan dapat melakukan pencadangan inkremental dengan mengonfigurasi MinLogSizeInMB atau TruncationThresholdFactor. Meningkatkan nilai-nilai ini meningkatkan penggunaan disk per replika. Untuk informasi selengkapnya, lihat Konfigurasi Reliable Services

BackupInfo memberikan informasi mengenai cadangan, termasuk lokasi folder tempat runtime menyimpan cadangan (BackupInfo.Directory). Fungsi panggilan balik dapat memindahkan BackupInfo.Directory ke penyimpanan eksternal atau lokasi lain. Fungsi ini juga mengembalikan bool yang menunjukkan apakah dapat berhasil memindahkan folder cadangan ke lokasi targetnya.

Kode berikut menunjukkan bagaimana BackupCallbackAsync metode dapat digunakan untuk mengunggah cadangan ke Azure Storage:

private async Task<bool> BackupCallbackAsync(BackupInfo backupInfo, CancellationToken cancellationToken)
{
    var backupId = Guid.NewGuid();

    await externalBackupStore.UploadBackupFolderAsync(backupInfo.Directory, backupId, cancellationToken);

    return true;
}

Dalam contoh sebelumnya, ExternalBackupStore adalah kelas sampel yang digunakan untuk berinteraksi dengan penyimpanan Azure Blob, dan UploadBackupFolderAsync merupakan metode yang mengompresi folder dan menempatkannya di penyimpanan Azure Blob.

Perhatikan bahwa:

• Hanya ada satu operasi pencadangan dalam penerbangan per replika pada waktu tertentu. Lebih dari satu BackupAsync panggilan pada satu waktu akan melempar FabricBackupInProgressException untuk membatasi pencadangan dalam penerbangan menjadi satu.
• Jika replika gagal saat pencadangan sedang berlangsung, cadangan mungkin belum selesai. Dengan demikian, setelah failover selesai, layanan bertanggung jawab untuk memulai ulang cadangan dengan memanggil BackupAsync seperlunya.

Pulihkan Layanan yang Andal

Secara umum, kasus ketika Anda mungkin perlu melakukan operasi pemulihan termasuk dalam salah satu kategori ini:

• Partisi layanan kehilangan data. Misalnya, disk untuk dua dari tiga replika untuk partisi (termasuk replika utama) dapat rusak atau dihapus. Primer baru mungkin perlu memulihkan data dari cadangan.
• Seluruh layanan hilang. Misalnya, administrator menghapus seluruh layanan dan dengan demikian layanan dan data perlu dipulihkan.
• Layanan mereplikasi data aplikasi yang rusak (misalnya, karena bug aplikasi). Dalam hal ini, layanan harus ditingkatkan atau dikembalikan untuk menghapus penyebab kerusakan, dan data yang tidak rusak harus dipulihkan.

Meskipun banyak pendekatan dimungkinkan, kami menawarkan beberapa contoh penggunaan RestoreAsync untuk pulih dari skenario di atas.

Kehilangan data partisi dalam Layanan Andal

Dalam hal ini, runtime akan secara otomatis mendeteksi kehilangan data dan memanggil OnDataLossAsync API.

Penulis layanan perlu melakukan hal berikut untuk memulihkan layanan:

• Timpa metode OnDataLossAsync dari kelas dasar virtual.
• Temukan cadangan terbaru di lokasi eksternal yang berisi cadangan layanan.
• Unduh cadangan terbaru (dan hapus kompresi cadangan ke folder cadangan jika dikompresi).
• Metode OnDataLossAsync ini menyediakan RestoreContext. Panggil API RestoreAsync pada RestoreContext yang disediakan.
• Mengembalikan "true" jika pemulihan berhasil.

Berikut adalah contoh implementasi OnDataLossAsync metode:

protected override async Task<bool> OnDataLossAsync(RestoreContext restoreCtx, CancellationToken cancellationToken)
{
    var backupFolder = await this.externalBackupStore.DownloadLastBackupAsync(cancellationToken);

    var restoreDescription = new RestoreDescription(backupFolder);

    await restoreCtx.RestoreAsync(restoreDescription);

    return true;
}

RestoreDescription diteruskan ke panggilan RestoreContext.RestoreAsync berisi anggota yang bernama BackupFolderPath. Saat memulihkan satu cadangan penuh, BackupFolderPath ini harus diatur ke jalur lokal folder yang berisi cadangan penuh Anda. Saat memulihkan cadangan penuh dan sejumlah cadangan bertahap, BackupFolderPath harus diatur ke jalur lokal folder yang tidak hanya berisi cadangan penuh, tetapi juga semua cadangan bertahap. RestoreAsync panggilan dapat menimbulkan FabricMissingFullBackupException jika BackupFolderPath yang disediakan tidak berisi cadangan penuh. Ini juga dapat menghasilkan ArgumentException jika BackupFolderPath memiliki rantai cadangan inkremental yang rusak. Misalnya, jika berisi pencadangan penuh, pencadangan inkremental pertama, dan pencadangan inkremental ketiga tetapi tidak ada pencadangan inkremental kedua.

Nota

RestorePolicy disetel ke Aman secara default. Ini berarti bahwa RestoreAsync API akan gagal dengan ArgumentException jika mendeteksi bahwa folder cadangan berisi status yang lebih lama dari atau sama dengan status yang terkandung dalam replika ini. RestorePolicy.Force dapat digunakan untuk melewati pemeriksaan keamanan ini. Ini ditentukan sebagai bagian dari RestoreDescription.

Layanan yang dihapus atau hilang

Jika layanan dihapus, Anda harus terlebih dahulu membuat ulang layanan sebelum data dapat dipulihkan. Penting untuk membuat layanan dengan konfigurasi yang sama, misalnya, skema partisi, sehingga data dapat dipulihkan dengan mulus. Setelah layanan habis, API untuk memulihkan data (OnDataLossAsync di atas) harus dipanggil pada setiap partisi layanan ini. Salah satu cara untuk mencapainya adalah dengan menggunakan FabricClient.TestManagementClient.StartPartitionDataLossAsync pada setiap partisi.

Dari titik ini, implementasinya sama dengan skenario di atas. Setiap partisi perlu memulihkan cadangan terbaru yang relevan dari penyimpanan eksternal. Salah satu peringatan adalah bahwa ID partisi sekarang dapat berubah, karena runtime membuat ID partisi secara dinamis. Dengan demikian, layanan perlu menyimpan informasi partisi dan nama layanan yang sesuai untuk mengidentifikasi cadangan terbaru yang benar untuk dipulihkan dari untuk setiap partisi.

Nota

Tidak disarankan untuk digunakan FabricClient.ServiceManager.InvokeDataLossAsync pada setiap partisi untuk memulihkan seluruh layanan, karena itu dapat merusak status kluster Anda.

Replikasi data aplikasi yang rusak

Jika pembaruan aplikasi yang baru disebarkan memiliki bug, ini dapat merusak data. Misalnya, peningkatan aplikasi dapat mulai memperbarui setiap rekaman nomor telepon dalam Reliable Dictionary dengan kode area yang tidak valid. Dalam hal ini, nomor telepon yang tidak valid akan direplikasi karena Service Fabric tidak mengetahui sifat data yang disimpan.

Hal pertama yang harus dilakukan setelah Anda mendeteksi bug mengerikan yang menyebabkan kerusakan data adalah membekukan layanan di tingkat aplikasi dan, jika memungkinkan, tingkatkan ke versi kode aplikasi yang tidak memiliki bug. Namun, bahkan setelah kode layanan diperbaiki, data mungkin masih rusak, dan dengan demikian data mungkin perlu dipulihkan. Dalam kasus seperti itu, mungkin tidak cukup untuk memulihkan cadangan terbaru, karena cadangan terbaru mungkin juga rusak. Dengan demikian, Anda harus menemukan cadangan terakhir yang dibuat sebelum data rusak.

Jika Anda tidak yakin cadangan mana yang rusak, Anda dapat menyebarkan kluster Service Fabric baru dan memulihkan cadangan partisi yang terpengaruh seperti skenario "Layanan yang dihapus atau hilang" di atas. Untuk setiap partisi, mulai memulihkan cadangan dari yang terbaru ke yang paling sedikit. Setelah Anda menemukan cadangan yang tidak memiliki kerusakan, pindahkan/hapus semua cadangan partisi ini yang lebih baru (daripada cadangan itu). Ulangi proses ini untuk setiap partisi. Sekarang, ketika OnDataLossAsync dipanggil pada partisi dalam kluster produksi, cadangan terakhir yang ditemukan di penyimpanan eksternal akan menjadi yang dipilih oleh proses di atas.

Sekarang, langkah-langkah di bagian "Layanan yang dihapus atau hilang" dapat digunakan untuk memulihkan status layanan ke status sebelum kode buggy merusak status.

Perhatikan bahwa:

• Saat Anda memulihkan, ada kemungkinan cadangan yang dipulihkan lebih lama dari status partisi sebelum data hilang. Karena itu, Anda harus memulihkan hanya sebagai upaya terakhir untuk memulihkan data sebanyak mungkin.
• String yang mewakili jalur folder cadangan dan jalur file di dalam folder cadangan dapat lebih besar dari 255 karakter, tergantung pada jalur FabricDataRoot dan panjang nama Jenis Aplikasi. Ini dapat menyebabkan beberapa metode .NET, seperti Directory.Move, melemparkan pengecualian PathTooLongException. Salah satu solusinya adalah langsung memanggil API kernel32, seperti CopyFile.

Mencadangkan dan memulihkan Reliable Actors (Aktor Andal)

Reliable Actors Framework dibangun di atas Reliable Services. ActorService, yang menghosting aktor adalah layanan yang dapat diandalkan yang stateful. Oleh karena itu, semua fungsi pencadangan dan pemulihan yang tersedia di Reliable Services juga tersedia untuk Reliable Actors (kecuali perilaku yang spesifik untuk penyedia status). Karena cadangan akan diambil per partisi, status semua pelaku dalam partisi tersebut akan dicadangkan (dan pemulihan juga akan dilakukan per partisi). Untuk melakukan pencadangan/pemulihan, pemilik layanan harus membuat kelas layanan aktor kustom yang berasal dari kelas ActorService dan kemudian melakukan pencadangan/pemulihan yang mirip dengan Reliable Services seperti yang dijelaskan di atas di bagian sebelumnya.

class MyCustomActorService : ActorService
{
    public MyCustomActorService(StatefulServiceContext context, ActorTypeInformation actorTypeInfo)
          : base(context, actorTypeInfo)
    {
    }
    
    //
    // Method overrides and other code.
    //
}

Ketika Anda membuat kelas layanan aktor kustom, Anda perlu mendaftarkan itu juga saat mendaftarkan aktor.

ActorRuntime.RegisterActorAsync<MyActor>(
    (context, typeInfo) => new MyCustomActorService(context, typeInfo)).GetAwaiter().GetResult();

Penyedia status default untuk Reliable Actors adalah KvsActorStateProvider. Pencadangan inkremental tidak diaktifkan secara default untuk KvsActorStateProvider. Anda dapat mengaktifkan pencadangan bertambah bertahap dengan membuat KvsActorStateProvider dengan pengaturan yang sesuai di konstruktornya lalu meneruskannya ke konstruktor ActorService seperti yang ditunjukkan dalam cuplikan kode berikut:

class MyCustomActorService : ActorService
{
    public MyCustomActorService(StatefulServiceContext context, ActorTypeInformation actorTypeInfo)
          : base(context, actorTypeInfo, null, null, new KvsActorStateProvider(true)) // Enable incremental backup
    {
    }
    
    //
    // Method overrides and other code.
    //
}

Setelah pencadangan inkremental diaktifkan, pengambilan cadangan inkremental dapat gagal karena FabricMissingFullBackupException untuk salah satu alasan berikut, dan Anda harus melakukan cadangan penuh sebelum mengambil cadangan inkremental:

• Replika belum pernah mengambil cadangan penuh sejak menjadi replika utama.
• Beberapa catatan log terpotong sebagian sejak pencadangan terakhir dilakukan.

Ketika pencadangan inkremental diaktifkan, KvsActorStateProvider tidak menggunakan buffer melingkar untuk mengelola catatan lognya dan secara berkala memotong catatan tersebut. Jika tidak ada cadangan yang diambil oleh pengguna selama jangka waktu 45 menit, sistem secara otomatis memotong rekaman log. Interval ini dapat dikonfigurasi dengan menentukan logTruncationIntervalInMinutes di dalam KvsActorStateProvider konstruktor (mirip dengan saat mengaktifkan pencadangan inkremental). Rekaman log juga dapat dipotong jika replika utama perlu membangun replika lain dengan mengirim semua datanya.

Saat melakukan pemulihan dari rantai cadangan, mirip dengan Reliable Services, BackupFolderPath harus berisi subdirektori dengan satu subdirektori yang berisi cadangan penuh dan subdirektori lain yang berisi cadangan inkremental. API pemulihan akan melempar FabricException dengan pesan kesalahan yang sesuai jika validasi rantai cadangan gagal.

Nota

KvsActorStateProvider saat ini mengabaikan opsi RestorePolicy.Safe. Dukungan untuk fitur ini direncanakan dalam rilis mendatang.

Menguji Pencadangan dan Pemulihan

Penting untuk memastikan bahwa data penting sedang dicadangkan, dan dapat dipulihkan. Ini dapat dilakukan dengan memanggil Start-ServiceFabricPartitionDataLoss cmdlet di PowerShell yang dapat menyebabkan kehilangan data dalam partisi tertentu untuk menguji apakah fungsionalitas pencadangan dan pemulihan data untuk layanan Anda berfungsi seperti yang diharapkan. Dimungkinkan juga untuk secara terprogram memanggil kehilangan dan pemulihan data dari peristiwa itu juga.

Nota

Anda dapat menemukan contoh implementasi fungsionalitas pencadangan dan pemulihan di Aplikasi Referensi Web di GitHub. Silakan lihat layanan Inventory.Service untuk detail lebih lanjut.

Di balik layar: rincian lebih lanjut tentang pencadangan dan pemulihan

Berikut adalah beberapa detail tambahan tentang pencadangan dan pemulihan.

Backup

Reliable State Manager menyediakan kemampuan untuk membuat cadangan yang konsisten tanpa memblokir operasi baca atau tulis apa pun. Untuk melakukannya, ia menggunakan mekanisme titik pemeriksaan dan persistensi log. Reliable State Manager mengambil titik pemeriksaan fuzzy (ringan) pada titik-titik tertentu untuk mengurangi beban pada log transaksional dan meningkatkan waktu pemulihan. Ketika BackupAsync dipanggil, Reliable State Manager menginstruksikan semua objek Reliable untuk menyalin file titik pemeriksaan terbaru mereka ke folder cadangan lokal. Kemudian, Reliable State Manager menyalin semua rekaman log, mulai dari "start pointer" hingga rekaman log terbaru ke folder cadangan. Karena semua catatan log hingga catatan log terbaru disertakan dalam cadangan dan Reliable State Manager mempertahankan pengelogan write-ahead, Reliable State Manager menjamin bahwa semua transaksi yang telah dikomit (CommitAsync telah berhasil dikembalikan) disertakan dalam cadangan.

Setiap transaksi yang dilakukan setelah BackupAsync dipanggil mungkin atau mungkin tidak ada dalam cadangan. Setelah folder cadangan lokal diisi oleh platform (yaitu, pencadangan lokal selesai oleh proses runtime), fungsi callback cadangan layanan dipanggil. Panggilan balik ini bertanggung jawab untuk memindahkan folder cadangan ke lokasi eksternal seperti Azure Storage.

Pulihkan

Reliable State Manager menyediakan kemampuan untuk memulihkan dari cadangan dengan menggunakan RestoreAsync API.
Metode RestoreAsync hanya dapat dipanggil di dalam metode OnDataLossAsync. Bool yang dikembalikan dengan OnDataLossAsync menunjukkan apakah layanan memulihkan statusnya dari sumber eksternal. Jika mengembalikan OnDataLossAsync true, Service Fabric akan membangun kembali semua replika lain dari primer ini. Service Fabric memastikan bahwa replika yang akan menerima panggilan OnDataLossAsync pertama-tama harus bertransisi ke peran utama tetapi tidak diberikan status baca maupun status tulis. Ini menyiratkan bahwa untuk pelaksana StatefulService, RunAsync tidak akan dipanggil sampai OnDataLossAsync selesai dengan sukses. Kemudian, OnDataLossAsync akan dipanggil pada primer baru. Hingga layanan berhasil menyelesaikan API ini (dengan mengembalikan true atau false) dan menyelesaikan konfigurasi ulang yang relevan, API akan terus dipanggil satu per satu.

RestoreAsync pertama-tama menghilangkan semua status yang ada di replika utama yang dipanggil. Kemudian Reliable State Manager membuat semua objek Reliable yang ada di folder cadangan. Selanjutnya, objek Reliable diinstruksikan untuk memulihkan dari titik pemeriksaan mereka di folder cadangan. Terakhir, Reliable State Manager memulihkan statusnya sendiri dari rekaman log di folder cadangan dan melakukan pemulihan. Sebagai bagian dari proses pemulihan, operasi mulai dari "titik awal" yang memiliki rekaman log yang telah dikomit di folder cadangan diputar kembali ke objek Reliable. Langkah ini memastikan bahwa status yang dipulihkan konsisten.

Langkah berikutnya

• Reliable Collections
• Quickstart Reliable Services
• Pemberitahuan Layanan Andal
• Konfigurasi Layanan Andal
• Referensi pengembang untuk Koleksi yang Andal
• Pencadangan dan pemulihan berkala di Azure Service Fabric