Tworzenie kopii zapasowych i przywracanie usług Reliable Services i Reliable Actors
Azure Service Fabric to platforma wysokiej dostępności, która replikuje stan między wieloma węzłami, aby zachować tę wysoką dostępność. W związku z tym nawet jeśli jeden węzeł w klastrze ulegnie awarii, usługi będą nadal dostępne. Chociaż ta wbudowana nadmiarowość zapewniana przez platformę może być wystarczająca dla niektórych, w niektórych przypadkach pożądane jest, aby usługa tworzyła kopię zapasową danych (do magazynu zewnętrznego).
Uwaga
Tworzenie kopii zapasowych i przywracanie danych (i testowanie ich działania zgodnie z oczekiwaniami) ma kluczowe znaczenie, aby można było odzyskać dane po scenariuszach utraty danych.
Uwaga
Firma Microsoft zaleca używanie okresowych kopii zapasowych i przywracania do konfigurowania kopii zapasowej danych usług Reliable Stateful i Reliable Actors.
Na przykład usługa może chcieć utworzyć kopię zapasową danych w celu ochrony przed następującymi scenariuszami:
- W przypadku trwałej utraty całego klastra usługi Service Fabric.
- Trwała utrata większości replik partycji usługi
- Błędy administracyjne, w których stan zostanie przypadkowo usunięty lub uszkodzony. Na przykład może się to zdarzyć, jeśli administrator z wystarczającym uprawnieniem błędnie usunie usługę.
- Usterki w usłudze, które powodują uszkodzenie danych. Na przykład może się to zdarzyć, gdy uaktualnienie kodu usługi rozpoczyna zapisywanie uszkodzonych danych w kolekcji Reliable Collection. W takim przypadku zarówno kod, jak i dane mogą być przywracane do wcześniejszego stanu.
- Przetwarzanie danych w trybie offline. Może być wygodne posiadanie przetwarzania danych w trybie offline na potrzeby analizy biznesowej, która odbywa się oddzielnie od usługi, która generuje dane.
Funkcja tworzenia/przywracania kopii zapasowych umożliwia usługom opartym na interfejsie API usług Reliable Services tworzenie i przywracanie kopii zapasowych. Interfejsy API kopii zapasowych udostępniane przez platformę umożliwiają tworzenie kopii zapasowych stanu partycji usługi bez blokowania operacji odczytu lub zapisu. Interfejsy API przywracania umożliwiają przywrócenie stanu partycji usługi z wybranej kopii zapasowej.
Typy kopii zapasowych
Dostępne są dwie opcje tworzenia kopii zapasowej: Pełne i Przyrostowe. Pełna kopia zapasowa to kopia zapasowa zawierająca wszystkie dane wymagane do odtworzenia stanu repliki: punkty kontrolne i wszystkie rekordy dziennika. Ponieważ zawiera ona punkty kontrolne i dziennik, pełną kopię zapasową można przywrócić samodzielnie.
Problem z pełnymi kopiami zapasowymi występuje, gdy punkty kontrolne są duże.
Na przykład replika, która ma 16 GB stanu, będzie zawierać punkty kontrolne, które sumują się około 16 GB.
Jeśli mamy cel punktu odzyskiwania w ciągu pięciu minut, kopia zapasowa repliki musi być wykonywana co pięć minut.
Za każdym razem, gdy kopie zapasowe są kopiami zapasowymi, musi skopiować 16 GB punktów kontrolnych oprócz 50 MB (konfigurowalnych przy użyciu polecenia CheckpointThresholdInMB
) wartości dzienników.
Rozwiązaniem tego problemu są przyrostowe kopie zapasowe, w których kopia zapasowa zawiera tylko zmienione rekordy dziennika od czasu utworzenia ostatniej kopii zapasowej.
Ponieważ przyrostowe kopie zapasowe są tylko zmianami od ostatniej kopii zapasowej (nie obejmuje punktów kontrolnych), zwykle są szybsze, ale nie można ich przywrócić samodzielnie. Aby przywrócić przyrostową kopię zapasową, wymagany jest cały łańcuch kopii zapasowych. Łańcuch kopii zapasowych to łańcuch kopii zapasowych rozpoczynający się od pełnej kopii zapasowej, po którym następuje szereg ciągłych przyrostowych kopii zapasowych.
Tworzenie kopii zapasowych usług Reliable Services
Autor usługi ma pełną kontrolę nad tym, kiedy tworzyć kopie zapasowe i gdzie będą przechowywane kopie zapasowe.
Aby uruchomić kopię zapasową, usługa musi wywołać funkcję dziedziczonej składowej BackupAsync
.
Kopie zapasowe można tworzyć tylko z replik podstawowych i wymagają udzielenia stanu zapisu.
Jak pokazano poniżej, BackupAsync
przyjmuje BackupDescription
obiekt, w którym można określić pełną lub przyrostową kopię zapasową, a także funkcję wywołania zwrotnego wywoływaną Func<< BackupInfo, CancellationToken, Task<bool>>>
, gdy folder kopii zapasowej został utworzony lokalnie i jest gotowy do przeniesienia do magazynu zewnętrznego.
BackupDescription myBackupDescription = new BackupDescription(BackupOption.Incremental,this.BackupCallbackAsync);
await this.BackupAsync(myBackupDescription);
Żądanie wykonania przyrostowej kopii zapasowej może zakończyć się niepowodzeniem za pomocą polecenia FabricMissingFullBackupException
. Ten wyjątek wskazuje, że dzieje się jedna z następujących rzeczy:
- replika nigdy nie utworzyła pełnej kopii zapasowej, ponieważ stała się podstawowa,
- niektóre rekordy dziennika od czasu ostatniej kopii zapasowej zostały obcięte lub
- replika przekroczyła
MaxAccumulatedBackupLogSizeInMB
limit.
Użytkownicy mogą zwiększyć prawdopodobieństwo możliwości tworzenia przyrostowych kopii zapasowych przez skonfigurowanie MinLogSizeInMB
lub TruncationThresholdFactor
.
Zwiększenie tych wartości zwiększa użycie dysku repliki.
Aby uzyskać więcej informacji, zobacz Reliable Services Configuration (Konfiguracja usług Reliable Services)
BackupInfo
zawiera informacje dotyczące kopii zapasowej, w tym lokalizację folderu, w którym środowisko uruchomieniowe zapisało kopię zapasową (BackupInfo.Directory
). Funkcja wywołania zwrotnego może przenieść BackupInfo.Directory
element do magazynu zewnętrznego lub innej lokalizacji. Ta funkcja zwraca również wartość logiczną wskazującą, czy udało mu się pomyślnie przenieść folder kopii zapasowej do lokalizacji docelowej.
Poniższy kod pokazuje, jak BackupCallbackAsync
można użyć metody do przekazania kopii zapasowej do usługi Azure Storage:
private async Task<bool> BackupCallbackAsync(BackupInfo backupInfo, CancellationToken cancellationToken)
{
var backupId = Guid.NewGuid();
await externalBackupStore.UploadBackupFolderAsync(backupInfo.Directory, backupId, cancellationToken);
return true;
}
W poprzednim przykładzie ExternalBackupStore
jest to przykładowa klasa używana do interfejsu z usługą Azure Blob Storage i UploadBackupFolderAsync
jest metodą kompresowania folderu i umieszcza ją w magazynie obiektów blob platformy Azure.
Należy pamiętać, że:
- W danym momencie można wykonać tylko jedną operację tworzenia kopii zapasowej na replikę. Więcej niż jedno
BackupAsync
wywołanie w danym momencie zostanie zgłoszonychFabricBackupInProgressException
, aby ograniczyć wykonywanie kopii zapasowych w locie do jednego. - Jeśli replika przechodzi w tryb failover podczas wykonywania kopii zapasowej, tworzenie kopii zapasowej mogło nie zostać ukończone. W związku z tym po zakończeniu pracy w trybie failover usługa jest odpowiedzialna za ponowne uruchomienie kopii zapasowej przez wywołanie
BackupAsync
w razie potrzeby.
Przywracanie usług Reliable Services
Ogólnie rzecz biorąc, przypadki, w których może być konieczne wykonanie operacji przywracania, należą do jednej z następujących kategorii:
- Partycja usługi straciła dane. Na przykład dysk dla dwóch z trzech replik partycji (w tym repliki podstawowej) jest uszkodzony lub czyszczony. Nowy element podstawowy może wymagać przywrócenia danych z kopii zapasowej.
- Cała usługa zostanie utracona. Na przykład administrator usuwa całą usługę, a tym samym usługę i dane muszą zostać przywrócone.
- Usługa replikował uszkodzone dane aplikacji (na przykład z powodu usterki aplikacji). W takim przypadku należy uaktualnić lub przywrócić usługę, aby usunąć przyczynę uszkodzenia, a nieuprawizowane dane muszą zostać przywrócone.
Chociaż istnieje wiele możliwych podejść, oferujemy kilka przykładów użycia RestoreAsync
do odzyskiwania po powyższych scenariuszach.
Partycjonowanie utraty danych w usługach Reliable Services
W takim przypadku środowisko uruchomieniowe automatycznie wykryje utratę danych i wywoła OnDataLossAsync
interfejs API.
Aby odzyskać dane, autor usługi musi wykonać następujące czynności:
- Zastąpi metodę
OnDataLossAsync
wirtualnej klasy bazowej . - Znajdź najnowszą kopię zapasową w lokalizacji zewnętrznej zawierającej kopie zapasowe usługi.
- Pobierz najnowszą kopię zapasową (i usuń kompresję kopii zapasowej do folderu kopii zapasowej, jeśli została skompresowana).
- Metoda
OnDataLossAsync
udostępnia metodęRestoreContext
. Wywołaj interfejsRestoreAsync
API w podanymRestoreContext
pliku . - Zwraca wartość true, jeśli przywracanie powiodło się.
Poniżej przedstawiono przykładową implementację OnDataLossAsync
metody :
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
przekazana do wywołania RestoreContext.RestoreAsync
zawiera element członkowski o nazwie BackupFolderPath
.
Podczas przywracania pojedynczej pełnej kopii zapasowej należy ustawić tę BackupFolderPath
opcję na ścieżkę lokalną folderu zawierającego pełną kopię zapasową.
Podczas przywracania pełnej kopii zapasowej i wielu przyrostowych kopii zapasowych należy ustawić ścieżkę lokalną folderu, BackupFolderPath
który nie tylko zawiera pełną kopię zapasową, ale także wszystkie przyrostowe kopie zapasowe.
RestoreAsync
wywołanie może zgłosić, FabricMissingFullBackupException
jeśli podana BackupFolderPath
wartość nie zawiera pełnej kopii zapasowej.
Może również zgłaszać uszkodzenie ArgumentException
BackupFolderPath
łańcucha przyrostowych kopii zapasowych.
Jeśli na przykład zawiera pełną kopię zapasową, pierwsza przyrostowa i trzecia przyrostowa kopia zapasowa, ale nie druga przyrostowa kopia zapasowa.
Uwaga
Ustawienie RestorePolicy jest domyślnie ustawione na Wartość Bezpieczne. Oznacza to, że RestoreAsync
interfejs API zakończy się niepowodzeniem z argumentemException, jeśli wykryje, że folder kopii zapasowej zawiera stan starszy lub równy stanowi zawartemu w tej repliki. RestorePolicy.Force
można pominąć tę kontrolę bezpieczeństwa. Jest to określone jako część .RestoreDescription
Usunięto lub utracono usługę
Jeśli usługa zostanie usunięta, musisz najpierw ponownie utworzyć usługę przed przywróceniem danych. Należy utworzyć usługę z tą samą konfiguracją, na przykład schemat partycjonowania, aby można było bezproblemowo przywrócić dane. Po uruchomieniu usługi interfejs API do przywrócenia danych (OnDataLossAsync
powyżej) musi być wywoływany na każdej partycji tej usługi. Jednym ze sposobów osiągnięcia tego celu jest użycie klasy FabricClient.TestManagementClient.StartPartitionDataLossAsync na każdej partycji.
Od tego momentu implementacja jest taka sama jak w powyższym scenariuszu. Każda partycja musi przywrócić najnowszą odpowiednią kopię zapasową z magazynu zewnętrznego. Jednym z zastrzeżeń jest to, że identyfikator partycji mógł się teraz zmienić, ponieważ środowisko uruchomieniowe tworzy identyfikatory partycji dynamicznie. W związku z tym usługa musi przechowywać odpowiednie informacje o partycji i nazwę usługi, aby zidentyfikować poprawną najnowszą kopię zapasową do przywrócenia z każdej partycji.
Uwaga
Nie zaleca się używania FabricClient.ServiceManager.InvokeDataLossAsync
na każdej partycji w celu przywrócenia całej usługi, ponieważ może to spowodować uszkodzenie stanu klastra.
Replikacja uszkodzonych danych aplikacji
Jeśli nowo wdrożone uaktualnienie aplikacji zawiera usterkę, może to spowodować uszkodzenie danych. Na przykład uaktualnienie aplikacji może zacząć aktualizować każdy rekord numeru telefonu w słowniku Reliable Dictionary z nieprawidłowym kodem obszaru. W takim przypadku nieprawidłowe numery telefonów zostaną zreplikowane, ponieważ usługa Service Fabric nie zna charakteru przechowywanych danych.
Pierwszą czynnością, którą należy wykonać po wykryciu takiej rażącej usterki, która powoduje uszkodzenie danych, jest zablokowanie usługi na poziomie aplikacji i, jeśli to możliwe, uaktualnienie do wersji kodu aplikacji, która nie ma usterki. Jednak nawet po naprawieniu kodu usługi dane mogą nadal być uszkodzone i w związku z tym dane mogą być konieczne do przywrócenia. W takich przypadkach może nie wystarczyć do przywrócenia najnowszej kopii zapasowej, ponieważ najnowsze kopie zapasowe również mogą być uszkodzone. W związku z tym należy znaleźć ostatnią kopię zapasową utworzoną przed uszkodzeniem danych.
Jeśli nie masz pewności, które kopie zapasowe są uszkodzone, możesz wdrożyć nowy klaster usługi Service Fabric i przywrócić kopie zapasowe partycji, których dotyczy problem, podobnie jak w powyższym scenariuszu "Usunięto lub utracono usługę". Dla każdej partycji rozpocznij przywracanie kopii zapasowych z najnowszej do najmniejszej. Po znalezieniu kopii zapasowej, która nie ma uszkodzenia, przenieś/usuń wszystkie kopie zapasowe tej partycji, które były nowsze (niż ta kopia zapasowa). Powtórz ten proces dla każdej partycji. Teraz po OnDataLossAsync
wywołaniu partycji w klastrze produkcyjnym ostatnia kopia zapasowa znaleziona w magazynie zewnętrznym będzie wybrana przez powyższy proces.
Teraz kroki opisane w sekcji "Usunięta lub utracona usługa" mogą służyć do przywrócenia stanu usługi do stanu przed uszkodzeniem stanu przez kod błędu.
Należy pamiętać, że:
- Podczas przywracania istnieje prawdopodobieństwo, że przywracana kopia zapasowa jest starsza niż stan partycji przed utratą danych. W związku z tym należy przywrócić tylko w ostateczności, aby odzyskać jak najwięcej danych.
- Ciąg reprezentujący ścieżkę folderu kopii zapasowej i ścieżki plików w folderze kopii zapasowej może być większy niż 255 znaków, w zależności od długości ścieżki FabricDataRoot i nazwy typu aplikacji. Może to spowodować, że niektóre metody platformy .NET, takie jak
Directory.Move
, zgłaszająPathTooLongException
wyjątek. Jednym z obejść jest bezpośrednie wywołanie interfejsów API jądra32, takich jakCopyFile
.
Tworzenie kopii zapasowej i przywracanie elementów Reliable Actors
Platforma Reliable Actors Framework jest oparta na usługach Reliable Services. ActorService, która hostuje aktorów, jest stanową niezawodną usługą. W związku z tym wszystkie funkcje tworzenia kopii zapasowych i przywracania dostępne w usługach Reliable Services są również dostępne dla elementów Reliable Actors (z wyjątkiem zachowań specyficznych dla dostawcy stanu). Ponieważ kopie zapasowe będą wykonywane na podstawie poszczególnych partycji, stany wszystkich aktorów w tej partycji zostaną utworzone w kopii zapasowej (i przywrócenie będzie podobne i będzie wykonywane na podstawie poszczególnych partycji). Aby wykonać tworzenie kopii zapasowych/przywracanie, właściciel usługi powinien utworzyć niestandardową klasę usługi aktora pochodzącą z klasy ActorService, a następnie wykonać kopię zapasową/przywrócić podobną do usługi Reliable Services, jak opisano powyżej w poprzednich sekcjach.
class MyCustomActorService : ActorService
{
public MyCustomActorService(StatefulServiceContext context, ActorTypeInformation actorTypeInfo)
: base(context, actorTypeInfo)
{
}
//
// Method overrides and other code.
//
}
Podczas tworzenia niestandardowej klasy usługi aktora należy je również zarejestrować podczas rejestrowania aktora.
ActorRuntime.RegisterActorAsync<MyActor>(
(context, typeInfo) => new MyCustomActorService(context, typeInfo)).GetAwaiter().GetResult();
Domyślnym dostawcą stanu dla elementów Reliable Actors jest KvsActorStateProvider
. Przyrostowa kopia zapasowa nie jest domyślnie włączona dla programu KvsActorStateProvider
. Możesz włączyć przyrostową kopię zapasową, tworząc KvsActorStateProvider
odpowiednie ustawienie w konstruktorze, a następnie przekazując je do konstruktora ActorService, jak pokazano w poniższym fragmencie kodu:
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.
//
}
Po włączeniu przyrostowej kopii zapasowej wykonywanie przyrostowej kopii zapasowej może zakończyć się niepowodzeniem z użyciem klasy FabricMissingFullBackupException z jednego z następujących powodów i należy wykonać pełną kopię zapasową przed wykonaniem przyrostowych kopii zapasowych:
- Replika nigdy nie utworzyła pełnej kopii zapasowej, ponieważ stała się podstawowa.
- Niektóre rekordy dziennika zostały obcięte od czasu utworzenia ostatniej kopii zapasowej.
Po włączeniu KvsActorStateProvider
przyrostowej kopii zapasowej nie używa buforu cyklicznego do zarządzania rekordami dzienników i okresowo obcina je. Jeśli użytkownik nie wykonuje kopii zapasowej przez okres 45 minut, system automatycznie obcina rekordy dziennika. Ten interwał można skonfigurować, określając logTruncationIntervalInMinutes
w KvsActorStateProvider
konstruktorze (podobnie jak w przypadku włączania przyrostowej kopii zapasowej). Rekordy dziennika mogą również zostać obcięte, jeśli replika podstawowa musi skompilować inną replikę, wysyłając wszystkie jego dane.
Podczas przywracania z łańcucha kopii zapasowych, podobnie jak w przypadku usług Reliable Services, ścieżka BackupFolderPath powinna zawierać podkatalogi z jednym podkatalogem zawierającym pełną kopię zapasową i inne podkatalogi zawierające przyrostowe kopie zapasowe. Jeśli walidacja łańcucha kopii zapasowych zakończy się niepowodzeniem, interfejs API przywracania zgłosi wyjątek FabricException z odpowiednim komunikatem o błędzie.
Uwaga
KvsActorStateProvider
obecnie ignoruje opcję RestorePolicy.Safe. Obsługa tej funkcji jest planowana w nadchodzącej wersji.
Testowanie tworzenia kopii zapasowej i przywracania
Ważne jest, aby upewnić się, że kopie zapasowe krytycznych danych są tworzone i można je przywrócić. Można to zrobić, wywołując Start-ServiceFabricPartitionDataLoss
polecenie cmdlet w programie PowerShell, które może wywołać utratę danych w określonej partycji, aby sprawdzić, czy funkcja tworzenia kopii zapasowej i przywracania danych dla usługi działa zgodnie z oczekiwaniami. Istnieje również możliwość programowego wywoływania utraty danych i przywracania z tego zdarzenia.
Uwaga
Przykładową implementację funkcji tworzenia i przywracania kopii zapasowych można znaleźć w aplikacji do dokumentacji internetowej w usłudze GitHub. Aby uzyskać więcej informacji, zapoznaj się z usługą Inventory.Service
.
Pod maską: więcej szczegółów dotyczących tworzenia kopii zapasowych i przywracania
Poniżej przedstawiono więcej szczegółów dotyczących tworzenia kopii zapasowych i przywracania.
Wykonywanie kopii zapasowej
Menedżer niezawodnego stanu umożliwia tworzenie spójnych kopii zapasowych bez blokowania operacji odczytu i zapisu. W tym celu korzysta z punktu kontrolnego i mechanizmu trwałości dziennika. Menedżer reliable state manager przyjmuje rozmyte (lekkie) punkty kontrolne w niektórych punktach, aby zmniejszyć presję z dziennika transakcyjnego i poprawić czas odzyskiwania. Po BackupAsync
wywołaniu program Reliable State Manager instruuje wszystkie obiekty Reliable, aby skopiowały najnowsze pliki punktu kontrolnego do lokalnego folderu kopii zapasowej. Następnie program Reliable State Manager kopiuje wszystkie rekordy dziennika, począwszy od wskaźnika początkowego do najnowszego rekordu dziennika w folderze kopii zapasowej. Ponieważ wszystkie rekordy dziennika do najnowszego rekordu dziennika są uwzględniane w kopii zapasowej, a program Reliable State Manager zachowuje rejestrowanie z wyprzedzeniem, menedżer reliable state manager gwarantuje, że wszystkie zatwierdzone transakcje (CommitAsync
zostały zwrócone pomyślnie) zostaną uwzględnione w kopii zapasowej.
Każda transakcja zatwierdzana po BackupAsync
wywołaniu może lub nie może znajdować się w kopii zapasowej. Po wypełnieniu lokalnego folderu kopii zapasowej przez platformę (tj. tworzenie lokalnej kopii zapasowej jest wykonywane przez środowisko uruchomieniowe), wywołanie wywołania zwrotnego kopii zapasowej usługi. To wywołanie zwrotne jest odpowiedzialne za przeniesienie folderu kopii zapasowej do lokalizacji zewnętrznej, takiej jak Usługa Azure Storage.
Przywracanie
Menedżer niezawodnego stanu zapewnia możliwość przywracania z kopii zapasowej przy użyciu interfejsu RestoreAsync
API.
Metoda RestoreAsync
on RestoreContext
może być wywoływana tylko wewnątrz OnDataLossAsync
metody .
Wartość logiczna zwrócona przez OnDataLossAsync
program wskazuje, czy usługa przywróciła stan z zewnętrznego źródła.
Jeśli zwraca OnDataLossAsync
wartość true, usługa Service Fabric ponownie skompiluje wszystkie inne repliki z tego podstawowego elementu. Usługa Service Fabric zapewnia, że repliki, które otrzymają OnDataLossAsync
wywołanie pierwszego przejścia do roli podstawowej, ale nie mają przyznanego stanu odczytu ani stanu zapisu.
Oznacza to, RunAsync
że w przypadku implementacji StatefulService nie będzie wywoływana do momentu OnDataLossAsync
pomyślnego zakończenia.
OnDataLossAsync
Następnie zostanie wywołana na nowym podstawowym.
Dopóki usługa nie ukończy tego interfejsu API (zwracając wartość true lub false) i zakończy odpowiednią ponowną konfigurację, interfejs API będzie nadal wywoływany pojedynczo.
RestoreAsync
najpierw pomiń cały istniejący stan w repliki podstawowej, na którą został wywołany.
Następnie narzędzie Reliable State Manager tworzy wszystkie obiekty Reliable, które istnieją w folderze kopii zapasowej.
Następnie obiekty Reliable są poinstruowane o przywróceniu z punktów kontrolnych w folderze kopii zapasowej.
Na koniec menedżer niezawodnego stanu odzyskuje swój własny stan z rekordów dziennika w folderze kopii zapasowej i wykonuje odzyskiwanie.
W ramach procesu odzyskiwania operacje rozpoczynające się od "punktu początkowego", które mają zatwierdzone rekordy dziennika w folderze kopii zapasowej, są odtwarzane do obiektów Reliable. Ten krok gwarantuje, że odzyskany stan jest spójny.
Następne kroki
- Niezawodne kolekcje
- Przewodnik Szybki start dotyczący usług Reliable Services
- Powiadomienia dotyczące usług Reliable Services
- Konfiguracja usług Reliable Services
- Dokumentacja dla deweloperów dotycząca kolekcji Reliable Collections
- Okresowe wykonywanie kopii zapasowej i przywracanie w usłudze Azure Service Fabric