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 FabricMissingFullBackupException
baş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ştururFabricBackupInProgressException
. - 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
OnDataLossAsync
geç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 birRestoreContext
sağlar.RestoreAsync
SağlananRestoreContext
ü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 BackupFolderPath
iç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.
RestoreAsync
sağ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 RestoreDescription
bir 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.Move
bazı .NET yöntemlerinin özel durum oluşturmasınaPathTooLongException
neden olabilir. Geçici çözümlerden biri, gibiCopyFile
kernel32 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 KvsActorStateProvider
varsayı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
Geri Bildirim
https://aka.ms/ContentUserFeedback.
Çok yakında: 2024 boyunca, içerik için geri bildirim mekanizması olarak GitHub Sorunları’nı kullanımdan kaldıracak ve yeni bir geri bildirim sistemiyle değiştireceğiz. Daha fazla bilgi için bkz.Gönderin ve geri bildirimi görüntüleyin