Reliable Services ve Reliable Actors'ı yedekleme ve geri yükleme

Azure Service Fabric, bu yüksek kullanılabilirliği korumak için durumu birden çok düğüm arasında çoğaltan yüksek kullanılabilirlik platformudur. Bu nedenle, kümedeki bir düğüm başarısız olsa bile hizmetler kullanılabilir olmaya devam ediyor. Platform tarafından sağlanan bu yerleşik yedeklilik bazıları için yeterli olsa da, bazı durumlarda hizmetin verileri yedeklemesi (dış depoya) tercih edilir.

Not

Veri kaybı senaryolarından kurtarabilmeniz için verilerinizi yedeklemek ve geri yüklemek (ve beklendiği gibi çalışıp çalışmadığını test etmek) kritik önem taşır.

Not

Microsoft, Reliable Stateful hizmetlerinin ve Reliable Actors'ın veri yedeklemesini yapılandırmak için Düzenli yedekleme ve geri yükleme kullanılmasını önerir.

Örneğin, bir hizmet aşağıdaki senaryolardan korunmak için verileri yedeklemek isteyebilir:

• Service Fabric kümesinin tamamının kalıcı olarak kaybolması durumunda.
• Hizmet bölümünün çoğaltmalarının çoğunluğunun kalıcı olarak kaybedilmesi
• Durumun yanlışlıkla silindiği veya bozulduğu yönetim hataları. Örneğin, yeterli ayrıcalığı olan bir yönetici yanlışlıkla hizmeti silerse bu durum oluşabilir.
• Hizmette veri bozulmasına neden olan hatalar. Örneğin, bir hizmet kodu yükseltmesi Güvenilir Koleksiyona hatalı veri yazmaya başladığında bu durum oluşabilir. Böyle bir durumda hem kodun hem de verilerin önceki bir duruma geri döndürülmesi gerekebilir.
• Çevrimdışı veri işleme. verileri oluşturan hizmetten ayrı olarak gerçekleşen iş zekası için verilerin çevrimdışı işlenmesi uygun olabilir.

Yedekleme/Geri Yükleme özelliği Reliable Services API'sinde oluşturulan hizmetlerin yedekleme oluşturmasına ve geri yüklemesine olanak tanır. Platform tarafından sağlanan yedekleme API'leri, okuma veya yazma işlemlerini engellemeden bir hizmet bölümünün durumunun yedeklenmesine izin verir. Geri yükleme API'leri, bir hizmet bölümünün durumunun seçilen bir yedekten geri yüklenmesine izin verir.

Yedekleme Türleri

İki yedekleme seçeneği vardır: Tam ve Artımlı. Tam yedekleme, çoğaltmanın durumunu yeniden oluşturmak için gereken tüm verileri içeren bir yedeklemedir: denetim noktaları ve tüm günlük kayıtları. Denetim noktalarına ve günlüğe sahip olduğundan, tam yedekleme kendi başına geri yüklenebilir.

Tam yedeklemelerle ilgili sorun, denetim noktaları büyük olduğunda ortaya çıkar. Örneğin, durumu 16 GB olan bir çoğaltmanın yaklaşık 16 GB'a kadar bir denetim noktası olur. Beş dakikalık bir Kurtarma Noktası Hedefimiz varsa çoğaltmanın beş dakikada bir yedeklenmesi gerekir. Her yedeklemesi için 50 MB 'a (kullanılarak yapılandırılabilir CheckpointThresholdInMB) ek olarak 16 GB denetim noktası kopyalaması gerekir.

Bu sorunun çözümü, yedeklemenin yalnızca son yedeklemeden sonra değiştirilen günlük kayıtlarını içerdiği artımlı yedeklemelerdir.

Artımlı yedeklemeler yalnızca son yedeklemeden bu yana yapılan değişiklikler olduğundan (denetim noktalarını içermez), daha hızlı olma eğilimindedir ancak kendi başlarına geri yüklenemezler. Artımlı yedeklemeyi geri yüklemek için yedekleme zincirinin tamamı gereklidir. Yedekleme zinciri, tam yedekleme ile başlayan ve ardından bir dizi bitişik artımlı yedekleme içeren bir yedekleme zinciridir.

Güvenilir Hizmetleri Yedekleme

Hizmet yazarı, yedeklemelerin ne zaman yapılacağı ve yedeklemelerin nerede depolanacağıyla ilgili tam denetime sahiptir.

Yedekleme başlatmak için hizmetin devralınan üye işlevini BackupAsyncçağırması gerekir.
Yedeklemeler yalnızca birincil çoğaltmalardan yapılabilir ve yazma durumunun verilmesini gerektirir.

Aşağıda gösterildiği gibi, BackupAsync bir BackupDescription tam veya artımlı yedeklemenin yanı sıra yedekleme klasörü yerel olarak oluşturulduğunda çağrılan ve bazı dış depolama alanına taşınmaya hazır bir geri çağırma işlevi Func<< BackupInfo, CancellationToken, Task<bool>>> belirtebilen bir nesne alır.

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

await this.BackupAsync(myBackupDescription);

Artımlı yedekleme isteği ile FabricMissingFullBackupExceptionbaşarısız olabilir. Bu özel durum, aşağıdakilerden birinin gerçekleştiğini gösterir:

• çoğaltma birincil haline geldikten sonra hiçbir zaman tam yedekleme almadı,
• son yedeklemeden bu yana günlük kayıtlarından bazıları kesildi veya
• çoğaltma sınırı MaxAccumulatedBackupLogSizeInMB geçti.

Kullanıcılar veya TruncationThresholdFactoryapılandırarak MinLogSizeInMB artımlı yedekleme yapma olasılığını artırabilir. Bu değerlerin artırılması çoğaltma diski başına kullanımı artırır. Daha fazla bilgi için bkz . Reliable Services Yapılandırması

BackupInfo , çalışma zamanının yedeklemeyi (BackupInfo.Directory kaydettiği klasörün konumu da dahil olmak üzere yedeklemeyle ilgili bilgiler sağlar. Geri çağırma işlevi, öğesini BackupInfo.Directory bir dış depoya veya başka bir konuma taşıyabilir. Bu işlev ayrıca yedekleme klasörünü hedef konumuna başarıyla taşıyıp taşıyamayacağını gösteren bir bool döndürür.

Aşağıdaki kod, yöntemin yedeklemeyi BackupCallbackAsync Azure Depolama'ya yüklemek için nasıl kullanılabileceğini gösterir:

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

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

    return true;
}

Yukarıdaki örnekte, ExternalBackupStore Azure Blob depolama ile arabirim oluşturma amacıyla kullanılan örnek sınıf ve UploadBackupFolderAsync klasörü sıkıştıran ve Azure Blob deposuna yerleştiren yöntemdir.

Şunlara dikkat edin:

• Herhangi bir zamanda çoğaltma başına yalnızca bir yedekleme işlemi olabilir. Bir kerede birden BackupAsync fazla çağrı, uçak içi yedeklemeleri tek bir çağrıyla sınırlamak için oluşturur FabricBackupInProgressException .
• Yedekleme devam ederken çoğaltma yük devredilirse, yedekleme tamamlanmamış olabilir. Bu nedenle, yük devretme tamamlandıktan sonra gerektiğinde çağırarak BackupAsync yedeklemeyi yeniden başlatmak hizmetin sorumluluğundadır.

Reliable Services'i geri yükleme

Genel olarak, geri yükleme işlemi gerçekleştirmeniz gerekebilecek durumlar şu kategorilerden birine girer:

• Hizmet bölümü veri kaybetti. Örneğin, bir bölümün (birincil çoğaltma dahil) üç çoğaltmadan ikisinin diski bozulur veya silinir. Yeni birincil veritabanının yedekten verileri geri yüklemesi gerekebilir.
• Hizmetin tamamı kaybolur. Örneğin, bir yönetici hizmetin tamamını kaldırır ve bu nedenle hizmetin ve verilerin geri yüklenmesi gerekir.
• Hizmet bozuk uygulama verilerini çoğaltmış (örneğin, bir uygulama hatası nedeniyle). Bu durumda, bozulmanın nedenini kaldırmak için hizmetin yükseltilmesi veya geri alınması ve bozuk olmayan verilerin geri yüklenmesi gerekir.

Birçok yaklaşım mümkün olsa da, yukarıdaki senaryolardan kurtarmak için kullanımıyla RestoreAsync ilgili bazı örnekler sunuyoruz.

Reliable Services'da bölüm veri kaybı

Bu durumda çalışma zamanı veri kaybını otomatik olarak algılar ve API'yi OnDataLossAsync çağırır.

Hizmet yazarının kurtarmak için aşağıdakileri gerçekleştirmesi gerekir:

• sanal temel sınıf yöntemini OnDataLossAsyncgeçersiz kılın.
• Hizmetin yedeklemelerini içeren dış konumda en son yedeklemeyi bulun.
• En son yedeklemeyi indirin (ve sıkıştırılmışsa yedekleme klasörünün sıkıştırmasını açın).
• OnDataLossAsync yöntemi bir RestoreContextsağlar. RestoreAsync Sağlanan RestoreContextüzerinde API'yi çağırın.
• Geri yükleme başarılı olursa true değerini döndürür.

Aşağıda yönteminin örnek bir uygulaması verilmiştir OnDataLossAsync :

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 çağrısına RestoreContext.RestoreAsync geçirilen adlı bir üye BackupFolderPathiçerir. Tek bir tam yedekleme geri yüklenirken bu, BackupFolderPath tam yedeklemenizi içeren klasörün yerel yoluna ayarlanmalıdır. Tam yedeklemeyi ve bir dizi artımlı yedeklemeyi geri yüklerken, yalnızca tam yedeklemeyi değil, BackupFolderPath aynı zamanda tüm artımlı yedeklemeleri de içeren klasörün yerel yoluna ayarlanmalıdır. RestoreAsyncsağlanan tam yedekleme içermiyorsa BackupFolderPath çağrısı oluşabilirFabricMissingFullBackupException. Artımlı yedekleme zinciri bozuksa BackupFolderPath da oluşturabilirArgumentException. Örneğin, tam yedeklemeyi, ilk artımlı ve üçüncü artımlı yedeklemeyi içeriyorsa ama ikinci artımlı yedeklemeyi içermiyorsa.

Not

RestorePolicy varsayılan olarak Güvenli olarak ayarlanır. Bu, yedekleme klasörünün RestoreAsync bu çoğaltmada yer alan durumdan daha eski veya buna eşit bir durum içerdiğini algılarsa API'nin ArgumentException ile başarısız olacağı anlamına gelir. RestorePolicy.Force bu güvenlik denetimini atlamak için kullanılabilir. Bu, öğesinin RestoreDescriptionbir parçası olarak belirtilir.

Silinen veya kaybolan hizmet

Bir hizmet kaldırılırsa, verilerin geri yüklenebilmesi için önce hizmeti yeniden oluşturmanız gerekir. Verilerin sorunsuz bir şekilde geri yüklenebilmesi için hizmeti bölümleme düzeni gibi aynı yapılandırmayla oluşturmak önemlidir. Hizmet hazır olduktan sonra, verileri geri yüklemek için API'nin (OnDataLossAsync yukarıdaki) bu hizmetin her bölümünde çağrılmış olması gerekir. Bunu başarmanın bir yolu, her bölümde FabricClient.TestManagementClient.StartPartitionDataLossAsync kullanmaktır.

Bu noktadan itibaren uygulama, yukarıdaki senaryoyla aynıdır. Her bölümün dış depodan en son ilgili yedeklemeyi geri yüklemesi gerekir. Çalışma zamanı bölüm kimliklerini dinamik olarak oluşturduğundan bölüm kimliğinin değişmiş olabileceği konusunda bir uyarı vardır. Bu nedenle, hizmetin her bölüm için geri yükleneceği doğru en son yedeklemeyi belirlemek için uygun bölüm bilgilerini ve hizmet adını depolaması gerekir.

Not

Küme durumunuzu bozabileceğinden, hizmetin tamamını geri yüklemek için her bölümde kullanılması FabricClient.ServiceManager.InvokeDataLossAsync önerilmez.

Bozuk uygulama verilerini çoğaltma

Yeni dağıtılan uygulama yükseltmesinde bir hata varsa, bu veri bozulmasına neden olabilir. Örneğin, bir uygulama yükseltmesi, Güvenilir Sözlükteki her telefon numarası kaydını geçersiz bir alan koduyla güncelleştirmeye başlayabilir. Bu durumda, Service Fabric depolanmakta olan verilerin doğasının farkında olmadığından geçersiz telefon numaraları çoğaltılır.

Veri bozulmasına neden olan bu kadar kötü bir hata algıladıktan sonra yapmanız gereken ilk şey, hizmeti uygulama düzeyinde dondurmak ve mümkünse hataya sahip olmayan uygulama kodunun sürümüne yükseltmektir. Ancak, hizmet kodu düzeltildikten sonra bile veriler yine bozuk olabilir ve bu nedenle verilerin geri yüklenmesi gerekebilir. Bu gibi durumlarda, en son yedeklemeler de bozuk olabileceğinden en son yedeklemeyi geri yüklemek yeterli olmayabilir. Bu nedenle, veriler bozulmadan önce yapılan son yedeklemeyi bulmanız gerekir.

Hangi yedeklemelerin bozuk olduğundan emin değilseniz, yeni bir Service Fabric kümesi dağıtabilir ve etkilenen bölümlerin yedeklerini yukarıdaki "Silinmiş veya kayıp hizmet" senaryosu gibi geri yükleyebilirsiniz. Her bölüm için yedeklemeleri en son bölümlerden en az olana geri yüklemeye başlayın. Bozulmaya sahip olmayan bir yedekleme bulduğunuzda, bu bölümün daha yeni olan tüm yedeklerini (bu yedeklemeden) taşıyın/silin. Bu işlemi her bölüm için yineleyin. Şimdi, üretim kümesindeki bölümde çağrıldığında OnDataLossAsync , dış depoda bulunan son yedekleme yukarıdaki işlem tarafından seçilen yedekleme olacaktır.

Artık "Silinen veya kaybolan hizmet" bölümündeki adımlar, buggy kodu durumu bozmadan önce hizmetin durumunu duruma geri yüklemek için kullanılabilir.

Şunlara dikkat edin:

• Geri yüklerken, geri yüklenen yedeklemenin verilerin kaybolmasından önceki bölümün durumundan daha eski olma olasılığı vardır. Bu nedenle, mümkün olduğunca çok veriyi kurtarmak için yalnızca son çare olarak geri yüklemeniz gerekir.
• Yedekleme klasörü yolunu ve yedekleme klasörünün içindeki dosyaların yollarını temsil eden dize, FabricDataRoot yoluna ve Uygulama Türü adının uzunluğuna bağlı olarak 255 karakterden uzun olabilir. Bu, gibi Directory.Movebazı .NET yöntemlerinin özel durum oluşturmasına PathTooLongException neden olabilir. Geçici çözümlerden biri, gibi CopyFilekernel32 API'lerini doğrudan çağırmaktır.

Reliable Actors'ı yedekleme ve geri yükleme

Reliable Actors Framework, Reliable Services üzerine kurulmuştur. Aktörleri barındıran ActorService, durum bilgisi olan güvenilir bir hizmettir. Bu nedenle, Reliable Services'da kullanılabilen tüm yedekleme ve geri yükleme işlevleri Reliable Actors tarafından da kullanılabilir (durum sağlayıcısına özgü davranışlar dışında). Yedeklemeler bölüm başına temel alınacağı için, bu bölümdeki tüm aktörlerin durumları yedeklenir (ve geri yükleme benzerdir ve bölüm başına gerçekleşir). Yedekleme/geri yükleme gerçekleştirmek için hizmet sahibinin ActorService sınıfından türetilen bir özel aktör hizmet sınıfı oluşturması ve ardından önceki bölümlerde yukarıda açıklandığı gibi Reliable Services'a benzer bir yedekleme/geri yükleme gerçekleştirmesi gerekir.

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

Özel bir aktör hizmet sınıfı oluşturduğunuzda, aktörü kaydederken bunu da kaydetmeniz gerekir.

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

Reliable Actors için varsayılan durum sağlayıcısıdır KvsActorStateProvider. Artımlı yedekleme için KvsActorStateProvidervarsayılan olarak etkin değildir. Oluşturucusunda uygun ayar ile oluşturup KvsActorStateProvider ardından aşağıdaki kod parçacığında gösterildiği gibi ActorService oluşturucusunda geçirerek artımlı yedeklemeyi etkinleştirebilirsiniz:

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.
    //
}

Artımlı yedekleme etkinleştirildikten sonra, artımlı yedekleme alma işlemi aşağıdaki nedenlerden biri nedeniyle FabricMissingFullBackupException ile başarısız olabilir ve artımlı yedeklemeleri almadan önce tam yedekleme yapmanız gerekir:

• Çoğaltma birincil hale geldikten sonra hiçbir zaman tam yedekleme almadı.
• Günlük kayıtlarından bazıları son yedekleme alındıktan sonra kesildi.

Artımlı yedekleme etkinleştirildiğinde, KvsActorStateProvider günlük kayıtlarını yönetmek için döngüsel arabellek kullanmaz ve düzenli aralıklarla kesilir. Kullanıcı tarafından 45 dakikalık bir süre boyunca yedek alınmazsa, sistem günlük kayıtlarını otomatik olarak kesilir. Bu aralık oluşturucuda KvsActorStateProvider belirtilerek logTruncationIntervalInMinutes yapılandırılabilir (artımlı yedeklemeyi etkinleştirirken olduğu gibi). Birincil çoğaltmanın tüm verilerini göndererek başka bir çoğaltma oluşturması gerekiyorsa günlük kayıtları da kesilebilir.

Reliable Services'a benzer şekilde bir yedekleme zincirinden geri yükleme yaparken BackupFolderPath, tam yedekleme içeren bir alt dizine ve artımlı yedekleme içeren diğer alt dizinlere sahip alt dizinler içermelidir. Yedekleme zinciri doğrulaması başarısız olursa geri yükleme API'sinde FabricException uygun hata iletisi görüntülenir.

Not

KvsActorStateProvider şu anda RestorePolicy.Safe seçeneğini yoksayar. Bu özellik için destek gelecek bir sürümde planlanıyor.

Yedeklemeyi ve Geri Yüklemeyi Test Etme

Kritik verilerin yedeklendiğinden ve geri yüklenebildiğinden emin olmak önemlidir. Bu, hizmetiniz için veri yedekleme ve geri yükleme işlevinin Start-ServiceFabricPartitionDataLoss beklendiği gibi çalışıp çalışmadığını test etmek için belirli bir bölümde veri kaybına neden olabilecek PowerShell cmdlet'ini çağırarak yapılabilir. Ayrıca program aracılığıyla veri kaybını çağırmak ve bu olaydan geri yüklemek de mümkündür.

Not

Yedekleme ve geri yükleme işlevinin örnek bir uygulamasını GitHub'daki Web Başvurusu Uygulaması'nda bulabilirsiniz. Daha fazla bilgi için lütfen hizmete bakın Inventory.Service .

Arka planda: yedekleme ve geri yükleme hakkında daha fazla ayrıntı

Yedekleme ve geri yükleme ile ilgili diğer ayrıntılar aşağıdadır.

Yedekleme

Reliable State Manager, herhangi bir okuma veya yazma işlemini engellemeden tutarlı yedeklemeler oluşturma olanağı sağlar. Bunu yapmak için bir denetim noktası ve günlük kalıcılığı mekanizması kullanır. Reliable State Manager, işlem günlüğündeki baskıyı azaltmak ve kurtarma sürelerini iyileştirmek için belirli noktalarda belirsiz (hafif) kontrol noktaları alır. Çağrıldığında BackupAsync Reliable State Manager tüm Reliable nesnelerine en son denetim noktası dosyalarını yerel bir yedekleme klasörüne kopyalamalarını bildirir. Ardından Reliable State Manager, "başlangıç işaretçisinden" başlayarak yedekleme klasörüne en son günlük kaydına kadar tüm günlük kayıtlarını kopyalar. En son günlük kaydına kadar olan tüm günlük kayıtları yedeklemeye eklendiğinden ve Reliable State Manager önceden yazma günlüğünü koruduğundan, Reliable State Manager işlenen (CommitAsync başarıyla döndürülen) tüm işlemlerin yedeklemeye dahil olmasını garanti eder.

Sonradan işleyen BackupAsync herhangi bir işlem çağrılmış olabilir veya yedekte olmayabilir. Yerel yedekleme klasörü platform tarafından doldurulduktan sonra (yerel yedekleme çalışma zamanı tarafından tamamlanır), hizmetin yedekleme geri çağırması çağrılır. Bu geri arama, yedekleme klasörünü Azure Depolama gibi bir dış konuma taşımakla sorumludur.

Geri Yükleme

Reliable State Manager, API kullanarak RestoreAsync bir yedeklemeden geri yükleme olanağı sağlar.
RestoreAsync üzerindeki RestoreContext yöntemi yalnızca yönteminin OnDataLossAsync içinde çağrılabilir. tarafından OnDataLossAsync döndürülen bool, hizmetin durumunu bir dış kaynaktan geri yükleyip yüklemediğini gösterir. OnDataLossAsync true döndürürse, Service Fabric bu birincil çoğaltmadaki diğer tüm çoğaltmaları yeniden oluşturur. Service Fabric, çağrı alacak OnDataLossAsync çoğaltmaların birincil role ilk geçişi almasını sağlar, ancak okuma durumu veya yazma durumu verilmemesini sağlar. Bu durum StatefulService uygulayıcıları için başarıyla RunAsync bitene kadar OnDataLossAsync çağrılmayacak anlamına gelir. Ardından, OnDataLossAsync yeni birincilde çağrılır. Bir hizmet bu API'yi başarıyla tamamlayana (true veya false döndürerek) ve ilgili yeniden yapılandırmayı tamamlayana kadar, API tek tek çağrılmaya devam eder.

RestoreAsync ilk olarak, birincil çoğaltmada çağrılan tüm mevcut durumu bırakır. Ardından Reliable State Manager, yedekleme klasöründe bulunan tüm Reliable nesnelerini oluşturur. Ardından Reliable nesnelerin yedekleme klasöründeki denetim noktalarından geri yüklemeleri istenir. Son olarak Reliable State Manager, yedekleme klasöründeki günlük kayıtlarından kendi durumunu kurtarır ve kurtarma gerçekleştirir. Kurtarma işleminin bir parçası olarak, yedekleme klasöründe kaydedilmiş günlük kayıtlarına sahip "başlangıç noktasından" başlayan işlemler Reliable nesnelerine yeniden oynatılır. Bu adım, kurtarılan durumun tutarlı olmasını sağlar.

Sonraki adımlar

• Güvenilir Koleksiyonlar
• Reliable Services hızlı başlangıcı
• Reliable Services bildirimleri
• Reliable Services yapılandırması
• Güvenilir Koleksiyonlar için geliştirici başvurusu
• Azure Service Fabric’te düzenli yedekleme ve geri yükleme