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 bir 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) önemlidir.

Not

Microsoft, Reliable Stateful hizmetlerinin ve Reliable Actors'ın veri yedeklemesini yapılandırmak için Düzenli aralıklarla yedekleme ve geri yükleme kullanmanızı ö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 kaybedilmesi 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. İş zekası için verileri oluşturan hizmetten ayrı olarak gerçekleşen verilerin çevrimdışı işlenmesi uygun olabilir.

Yedekleme/Geri Yükleme özelliği, Reliable Services API'sinde oluşturulan hizmetlerin yedekleme oluşturmasını ve geri yüklemesini sağlar. 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 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 tek 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 ekleyen denetim noktaları olacaktır. Beş dakikalık bir Kurtarma Noktası Hedefimiz varsa çoğaltmanın beş dakikada bir yedeklenmesi gerekir. Her yedeklemesi için 50 MB (kullanılarak yapılandırılabilir CheckpointThresholdInMB) günlüklere 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 yedeklemeyle başlayan ve ardından bir dizi ardışık artımlı yedeklemeden oluşan bir yedekleme zinciridir.

Güvenilir Hizmetleri Yedekleme

Hizmet yazarı, yedeklemelerin ne zaman yapılacağı ve yedeklemelerin nerede depolandığı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 tam BackupDescription 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 olduğundan hiçbir zaman tam yedekleme almamıştır,
• 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 TruncationThresholdFactor'yi yapı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 bir dış depoya veya başka bir konuma taşıyabilir BackupInfo.Directory . Bu işlev ayrıca yedekleme klasörünü hedef konumuna başarıyla taşıyıp taşıyamayacağını belirten bir bool döndürür.

Aşağıdaki kod, yedeklemeyi Azure Depolama'ya BackupCallbackAsync yüklemek için yönteminin 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şturmada kullanılan örnek sınıf ve klasörü sıkıştıran ve UploadBackupFolderAsync 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.

Güvenilir Hizmetleri 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 birincilin yedekten verileri geri yüklemesi gerekebilir.
• Tüm hizmet 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ğalttı (ö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'ta 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.

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 yedeklemeyi geri yüklerken 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şturabilirFabricMissingFullBackupException. Artımlı yedekleme zinciri bozuksa BackupFolderPath da oluşturabilirArgumentException. Örneğin, tam yedeklemeyi içeriyorsa, ilk artımlı ve üçüncü artımlı yedekleme ancak ikinci artımlı yedekleme yoktur.

Not

RestorePolicy varsayılan olarak Güvenli olarak ayarlanır. Bu, yedekleme klasörünün bu çoğaltmada RestoreAsync bulunan durumdan daha eski veya ona 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 olduğunda, verileri geri yüklemek için API'nin (OnDataLossAsync yukarıda) 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 artık 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 tanımlamak 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 depolanan verilerin doğasının farkında olmadığından geçersiz telefon numaraları çoğaltılır.

Veri bozulmasına neden olan bu tür 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 yukarıdaki "Silinmiş veya kayıp hizmet" senaryosunda olduğu gibi etkilenen bölümlerin yedeklerini geri yükleyebilirsiniz. Her bölüm için yedeklemeleri en son olandan en küçüke 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 yedekten) taşıyın/silin. Bu işlemi her bölüm için yineleyin. Artık ü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 veriler kaybolmadan önceki bölümün durumundan daha eski olma olasılığı vardır. Bu nedenle, mümkün olduğunca fazla 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'de sağlanan 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 temelinde 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 temelinde 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 önceki bölümlerde yukarıda açıklandığı gibi Reliable Services'e benzer bir yedekleme/geri yükleme yapması gerekir.

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

Özel 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 fabricMissingFullBackupException ile aşağıdaki nedenlerden biri nedeniyle 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 arabelleği kullanmaz ve düzenli aralıklarla keser. Kullanıcı tarafından 45 dakikalık bir süre boyunca yedek alınmazsa, sistem günlük kayıtlarını otomatik olarak kesir. 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 sahip alt dizinler ve artımlı yedeklemeler içeren diğer 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 üzere belirli bir bölümde veri kaybına neden olabilecek Cmdlet'i PowerShell'de çağırarak yapılabilir. Bu olaydan program aracılığıyla veri kaybı ve geri yükleme de çağrılabilir.

Not

Yedekleme ve geri yükleme işlevinin örnek uygulamasını GitHub'daki Web Başvurusu Uygulaması'nda bulabilirsiniz. Daha fazla ayrıntı 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 hakkında daha fazla ayrıntı aşağıdadır.

Backup

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ı hafifletmek ve kurtarma sürelerini iyileştirmek için belirli noktalarda belirsiz (hafif) denetim 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 en son günlük kaydına kadar tüm günlük kayıtlarını yedekleme klasörüne kopyalar. En son günlük kaydına kadar olan tüm günlük kayıtları yedeklemeye dahil olduğundan 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.

Sonrasında işlemesi BackupAsync yapılan herhangi bir işlem çağrılabilir veya yedekte olmayabilir. Yerel yedekleme klasörü platform tarafından doldurulduktan sonra (yani yerel yedekleme çalışma zamanı tarafından tamamlandığında), hizmetin yedekleme geri çağırması çağrılır. Bu geri çağırma, yedekleme klasörünü Azure Depolama gibi bir dış konuma taşımakla sorumludur.

Geri Yükleme

Reliable State Manager, API'yi kullanarak RestoreAsync bir yedeklemeden geri yükleme olanağı sağlar.
RestoreAsync üzerinde 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 geri yüklemediğini gösterir. OnDataLossAsync true döndürürse, Service Fabric bu birincil çoğaltmadan diğer tüm çoğaltmaları yeniden oluşturur. Service Fabric, birincil role çağrı ilk geçişi alacak OnDataLossAsync ancak okuma durumu veya yazma durumu verilmeyen çoğaltmaların sağlanmasını sağlar. Bu durum StatefulService RunAsync uygulayıcıları için başarıyla 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 önce, birincil çoğaltmada çağrıldığı 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