Category: Dzień z Service Fabric

Kolejnym z podsystemów w Service Fabric jest Management subsystem. Jest on odpowiedzialny za zarządzanie cyklem życia aplikacji na co składa się tworzenie, patchowanie, updatowanie i usuwanie zasobów.
Jest to główny podsystem, z którym pracuje się poprzez PowerShella czy API.
On także składa się z kilku elementów:

Image store – usługa do składowania i dystrybucji paczek aplikacji. Zapewnia rozproszony system plików przechowujących ww. paczki,

Health manager – Service Fabric posiada własny model “zdrowia”, czy też, nazwijmy to, jakości działania usługi, na który składają się informacje przekrojowo zbierane z różnych elementów całego klastra. Ta usługa udostępnia swojemu podsystemowi dane oraz zdarzenia umożliwiające reakcję i podejmowanie odpowiednich decyzji służących zapewnieniu dostępności aplikacji,

Cluster manager – ta usługa współpracuje z inną – Failover manager – w celu umieszczania aplikacji na węzłach klastra. To ona technicznie odpowiada za wspomniane na początku funkcjonalności podsystemu – od utworzenia do usunięcia zasobów.161

Wiele maszyn uruchomionych w klastrze, wiele serwisów i replik uruchamianych pod różnymi adresami i słuchającymi na różnych portach stanowi pewne wyzwanie z punktu widzenia klienta wykorzystującego jednolitą aplikację, w której ww. powinny być zupełnie przezroczyste.

Rozwiązać ten problem można na różne sposoby, np. gateway z automatycznym wykrywaniem instancji serwisów. W przypadku Service Fabric najprostszym rozwiązaniem jest jednak Load Balancer, który otrzymujemy out-of-box. Kieruje on ruch jedynie do poprawnie funkcjonujących instancji serwisów (ma wiedzę o ich stanie), co zapewnia wspomnianą już przezroczystość dla klienta – ta funkcjonalność jest jego domyślną i standardową. Posiadając wiedzę o instancjach reaguje oczywiście także na zmianę ich liczby, czyli zapewnia skalowanie aplikacji. Dodatkowo umożliwia też skonfigurowanie takiego mechanizmu jak partycjonowanie ruchu pozwalając na “ręczne” kierowanie określonych żądań do określonych węzłów.

W poprzednim wpisie była mowa o usługach domyślnych w manifeście. Jakie usługi oferuje nam out of the box Service Fabric? Trochę tego jest, dodatkowo serwisy systemowe są pogrupowane w podsystemy, odpowiedzialne za różne aspekty działania klastra.

Jednym z ciekawszych podsystemów z punktu widzenia użytkownika jest z pewnością Reliability subsystem, który odpowiada za utrzymanie wysokiej dostępności aplikacji uruchomionych w Service Fabric i składa się z trzech usług systemowych:

Failover manager – reaguje na dodawanie i znikanie węzłów, wyrównuje obciążenia w przypadku dodania węzła i rekonfiguruje repliki w przypadku jego utraty,

Resource Balancer – odpowiada za zbieranie danych o obciążeniu i przekazywanie ustalonych na ich podstawie rekomendacji do Failover managera,

Replicator – pilnuje prawidłowej replikacji serwisów, zajmuje się także zachowaniem spójności stanów pomiędzy replikami serwisów stateful.

 

Wiemy już, że aplikacja Service Fabric składa się z serwisów. Jak to jest jednak wszystko opisane? Za opis całości aplikacji odpowiada jej manifest, którego zadaniem jest zebrać informacje o wszystkich serwisach w aplikacji oraz o ich rozłożeniu w klastrze Service Fabric. Oprócz serwisów, o których głównie myślimy tworząc aplikację (czyli naszych) manifest zawiera też sekcję dla serwisów domyślnych, które Service Fabric uruchamia automatycznie.

A co z serwisem? Ten składa się z trzech elementów – kodu, konfiguracji, danych. Kod to rzecz jasna pliki wykonywalne serwisu. Konfiguracja może być zmieniana w run time. Dane są to informacje statyczne wykorzystywane przez usługę. Każdy z trzech elementów zebrany jest w niezależną od pozostałych paczkę.
Całość każdego serwisu także opisana jest manifestem, do którego odniesienie znajduje się w manifeście aplikacji.

Wszystkie manifesty, zarówno serwisów jak i aplikacji, mają postać plików XML (podobnie jak konfiguracja serwisu) i są niezależnie wersjonowane.

Service Fabric udostępnia dwa frameworki do tworzenia mikroserwisów w swoim obrębie:

• Reliable Service API – pozwala na bezpośredni dostęp do elementów Service Fabric jak połączenia czy stosy komunikacyjne,
• Reliable Actor API – jednowątkowy, asynchroniczny model programowania z wykorzystaniem, a jakże, aktorów. Pozwala implementować aktora jak jednowątkowy singleton.

Różnią się przede wszystkim tym, że Actor API jest frameworkiem wyższego poziomu, operującym na wyższym poziomie abstrakcji.

Takie dwupoziomowe podejście to ciekawa opcja. Można wykorzystać bardziej przystępny, intuicyjny model do tworzenia nawet skomplikowanych projektów czy do sprawnego wykonania proof of concept albo użyć niższego poziomu jeśli chce się wycisnąć z usługi jej maksimum i przede wszystkim mieć pełną kontrolę nad wszystkim.

Krótko o podstawowych, najważniejszych terminach używanych w trakcie zajmowania się Service Fabric:

• Node – węzeł – proces runtime usługi Service Fabric, w praktyce – pojedyncza maszyna (w przypadku Azure – wirualna),
• Cluster – klaster – zestaw węzłów (o wysokiej dostępności, niezawodności itd…),
• Application – aplikacja – zbiór usług, mikroserwisów,
• Service – usługa, mikroserwis – jednostka dostarczająca jakieś konkretne funkcjonalności
• Partition – partycja – usługa może posiadać wiele partycji, tzn. być uruchomiona w wielu instancjach w klastrze, ten mechanizm służy do zarządzania obciążeniem – load balancing pomiędzy wieloma instancjami tej samej usługi,
• Replica – replika – redundancja w ramach instancji (partycji) usługi, mechanizm służy do zapewnienia ciągłości działania – płynne przełączanie pomiędzy Primary i Secondary zarówno w trakcie wyłożenia się procesu usługi jak i w przypadku deployowania updatu.

Tyle na razie. Do tych jeszcze wrócimy, nadejdzie też parę nowych.

Widywałem już, wynikające zapewne z tłumaczenia tych pojedynczych słów – stateful, stateless – podsumowania, że te dwa rodzaje usług różnią się posiadaniem lub nie posiadaniem stanu przechowywanego między poszczególnymi wywołaniami. Uproszczenie niby małe, ale jednak wprowadzające w konkretny błąd. Należy do niego dodać jeszcze słówko “lokalnie”. To znaczy usługę stateful można przerobić na usługę stateless nie rezygnując z żadnych stanów, a jedynie zmieniając miejsce ich zapisu poprzez umieszczenie go poza samą usługą. Dzięki temu np. po wywrotce węzła jego redundantna lub nowo uruchomiona kopia odczytuje aktualny stan usługi z zewnętrznej lokalizacji i wszystko działa bez zakłóceń.

Most services have states. However, this doesn’t mean they are stateful. The only difference between stateful services and stateless services is where states are stored.

– Programming Microsoft Azure Service Fabric (Haishi Bai)

Swoją drogą nie dziwią mnie te niedopowiedzenia – to nazewnictwo nie jest specjalnie intuicyjne. Co poradzić, opisowe pewnie byłoby niewygodne.