Tworzenie kopii zapasowych i przywracanie usług Reliable Services i Reliable Actors

Usługa Azure Service Fabric to platforma o 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 mogła utworzyć kopię zapasową danych (do magazynu zewnętrznego).

Uwaga

Tworzenie kopii zapasowej 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 polegające na tym, że stan został 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 do 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, aby przetwarzanie danych w trybie offline na potrzeby analizy biznesowej odbywało 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 z 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ć tworzona co pięć minut. Za każdym razem, gdy kopia zapasowa musi skopiować 16 GB punktów kontrolnych oprócz 50 MB (konfigurowalne przy użyciu CheckpointThresholdInMB) wartości dzienników.

Rozwiązaniem tego problemu są przyrostowe kopie zapasowe, w których kopia zapasowa zawiera tylko zmienione rekordy dziennika od ostatniej kopii zapasowej.

Ponieważ przyrostowe kopie zapasowe są tylko zmianami od ostatniej kopii zapasowej (nie obejmuje punktów kontrolnych), są one zwykle 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, a następnie 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ć dziedziczona funkcja BackupAsyncskładowa .
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, Func<< BackupInfo, CancellationToken, Task<bool>>> która jest wywoływana, 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 tworzenia przyrostowych kopii zapasowych, konfigurując MinLogSizeInMB program lub TruncationThresholdFactor. Zwiększenie tych wartości zwiększa użycie dysku repliki. Aby uzyskać więcej informacji, zobacz 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 obiekt 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 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 spowoduje ograniczenie FabricBackupInProgressException kopii zapasowych w lotach 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, wywołując 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 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 usługa musi zostać uaktualniona lub przywrócona, aby usunąć przyczynę uszkodzenia, a dane niezwiązane z uszkodzeniem 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ąpij metodę OnDataLossAsyncwirtualnej 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 element RestoreContext. Wywołaj interfejs RestoreAsync API w podanym RestoreContextpliku .
• 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 przekazane do wywołania RestoreContext.RestoreAsync zawiera element członkowski o nazwie BackupFolderPath. Podczas przywracania pojedynczej pełnej kopii zapasowej BackupFolderPath należy ustawić tę 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łaszać, FabricMissingFullBackupExceptionBackupFolderPath jeśli podany element nie zawiera pełnej kopii zapasowej. Może również zgłaszać ArgumentException , jeśli BackupFolderPath ma uszkodzony łańcuch 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

Wartość RestorePolicy jest domyślnie ustawiona na Wartość Bezpieczna. 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 w ramach elementu 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 rozpocząć aktualizowanie każdego rekordu 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 wie o charakterze przechowywanych danych.

Pierwszą rzeczą, 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, a tym samym dane mogą być konieczne do przywrócenia. W takich przypadkach przywracanie najnowszej kopii zapasowej może być niewystarczające, 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 najnowszych do najmniejszych. 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 usterki.

Należy pamiętać, że:

• Podczas przywracania istnieje prawdopodobieństwo, że przywracana kopia zapasowa jest starsza niż stan partycji przed utratą danych. Z tego powodu 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, spowodują zgłoszenie wyjątku PathTooLongException . Jednym z obejść jest bezpośrednie wywoływanie interfejsów API jądra32, takich jak CopyFile.

Tworzenie kopii zapasowej i przywracanie elementów Reliable Actors

Platforma Reliable Actors Framework jest oparta na usługach Reliable Services. Usługa 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ą tworzone na podstawie poszczególnych partycji, stany dla wszystkich aktorów w tej partycji będą tworzone kopie zapasowe (a przywracanie jest podobne i będzie wykonywane dla 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ć tworzenie kopii zapasowej/przywracanie podobne do usług 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 zarejestrować również 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 ją 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 powodu błędu 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 program nie używa buforu cyklicznego do zarządzania rekordami dziennika 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 jej 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ą, a inne podkatalogi zawierające przyrostowe kopie zapasowe. Interfejs API przywracania zgłosi wyjątek FabricException z odpowiednim komunikatem o błędzie, jeśli walidacja łańcucha kopii zapasowych zakończy się niepowodzeniem.

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 zapewnić tworzenie kopii zapasowych krytycznych danych 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 przetestować, 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 kopii zapasowych i przywracania można znaleźć w aplikacji dokumentacji internetowej w witrynie GitHub. Aby uzyskać więcej informacji, zapoznaj się z usługą Inventory.Service .

Pod maską: więcej szczegółów na temat tworzenia kopii zapasowych i przywracania

Oto kilka dodatkowych szczegółów dotyczących tworzenia kopii zapasowych i przywracania.

Backup

Program Reliable State Manager 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ę dziennika transakcyjnego i poprawić czas odzyskiwania. Po BackupAsync wywołaniu funkcja Reliable State Manager nakazuje wszystkim obiektom Reliable skopiowanie najnowszych plików punktów kontrolnych 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, program 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ę (czyli tworzenia lokalnej kopii zapasowej przez środowisko uruchomieniowe) wywołanie zwrotne kopii zapasowej usługi jest wywoływane. To wywołanie zwrotne jest odpowiedzialne za przeniesienie folderu kopii zapasowej do lokalizacji zewnętrznej, takiej jak Usługa Azure Storage.

Przywracanie

Program Reliable State Manager umożliwia przywracanie z kopii zapasowej przy użyciu interfejsu RestoreAsync API.
Metodę RestoreAsync w metodzie RestoreContextOnDataLossAsync można wywołać tylko wewnątrz metody . Wartość logiczna zwrócona przez OnDataLossAsync program wskazuje, czy usługa przywróciła jej stan ze źródła zewnętrznego. Jeśli wartość OnDataLossAsync zwraca wartość true, usługa Service Fabric ponownie skompiluje wszystkie inne repliki z tego podstawowego. Usługa Service Fabric zapewnia, że repliki, które będą odbierać OnDataLossAsync wywołanie pierwszego przejścia do roli głównej, ale nie mają przyznanego stanu odczytu ani stanu zapisu. Oznacza to, RunAsync że w przypadku implementatorów StatefulService nie będzie wywoływana do momentu OnDataLossAsync pomyślnego zakończenia. OnDataLossAsync Następnie zostanie wywołana na nowym serwerze podstawowym. Dopóki usługa nie ukończy tego interfejsu API pomyślnie (przez zwrócenie wartości true lub false) i zakończy odpowiednią ponowną konfigurację, interfejs API będzie jednocześnie wywoływany pojedynczo.

RestoreAsync najpierw odrzuca cały istniejący stan w repliki podstawowej, do którego 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, aby przywrócić je z punktów kontrolnych w folderze kopii zapasowej. Na koniec program Reliable State Manager 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

• Elementy Reliable Collections
• Przewodnik Szybki start dotyczący usług Reliable Services
• Powiadomienia usług Reliable Services
• Konfiguracja usług Reliable Services
• Dokumentacja dla deweloperów dotycząca kolekcji Reliable
• Okresowe wykonywanie kopii zapasowej i przywracanie w usłudze Azure Service Fabric