Opisywanie klastra usługi Service Fabric przy użyciu usługi Resource Manager klastra
Funkcja Menedżera zasobów klastra usługi Azure Service Fabric udostępnia kilka mechanizmów opisujących klaster:
- Domeny błędów
- Uaktualnianie domen
- Właściwości węzła
- Pojemności węzłów
W czasie wykonywania usługa Resource Manager klastra używa tych informacji w celu zapewnienia wysokiej dostępności usług uruchomionych w klastrze. Wymuszając te ważne reguły, próbuje również zoptymalizować użycie zasobów w klastrze.
Domeny błędów
Domena błędów to dowolny obszar skoordynowanej awarii. Jedna maszyna jest domeną błędów. Może samodzielnie zakończyć się niepowodzeniem z różnych powodów, od awarii zasilania do awarii dysku do złego oprogramowania układowego karty sieciowej.
Maszyny podłączone do tego samego przełącznika Ethernet znajdują się w tej samej domenie błędów. W związku z tym maszyny współużytkujące pojedyncze źródło zasilania lub w jednej lokalizacji.
Ponieważ błędy sprzętowe nakładają się na siebie, domeny błędów są z natury hierarchiczne. Są one reprezentowane jako identyfikatory URI w usłudze Service Fabric.
Ważne jest, aby domeny błędów były poprawnie skonfigurowane, ponieważ usługa Service Fabric używa tych informacji do bezpiecznego umieszczania usług. Usługa Service Fabric nie chce umieszczać usług w taki sposób, że utrata domeny błędów (spowodowana awarią niektórych składników) powoduje, że usługa nie działa.
W środowisku platformy Azure usługa Service Fabric używa informacji o domenie błędów udostępnianych przez środowisko, aby poprawnie skonfigurować węzły w klastrze w Twoim imieniu. W przypadku autonomicznych wystąpień usługi Service Fabric domeny błędów są definiowane w czasie konfigurowania klastra.
Ostrzeżenie
Ważne jest, aby informacje o domenie błędów podane w usłudze Service Fabric były dokładne. Załóżmy na przykład, że węzły klastra usługi Service Fabric działają na 10 maszynach wirtualnych z systemem na 5 hostach fizycznych. W takim przypadku, mimo że istnieje 10 maszyn wirtualnych, istnieje tylko 5 różnych (najwyższego poziomu) domen błędów. Udostępnianie tego samego hosta fizycznego powoduje, że maszyny wirtualne współużytkują tę samą domenę błędów głównych, ponieważ maszyny wirtualne doświadczają skoordynowanej awarii, jeśli ich host fizyczny ulegnie awarii.
Usługa Service Fabric oczekuje, że domena błędów węzła nie zostanie zmieniona. Inne mechanizmy zapewniania wysokiej dostępności maszyn wirtualnych, takich jak maszyny wirtualne wysokiej dostępności, mogą powodować konflikty z usługą Service Fabric. Te mechanizmy używają przezroczystej migracji maszyn wirtualnych z jednego hosta do innego. Nie konfigurują ponownie ani nie powiadamiają uruchomionego kodu wewnątrz maszyny wirtualnej. W związku z tym nie są one obsługiwane jako środowiska do uruchamiania klastrów usługi Service Fabric.
Usługa Service Fabric powinna być jedyną technologią wysokiej dostępności. Mechanizmy takie jak migracja maszyn wirtualnych na żywo i sieci SAN nie są niezbędne. Jeśli te mechanizmy są używane w połączeniu z usługą Service Fabric, zmniejszają dostępność i niezawodność aplikacji. Powodem jest wprowadzenie dodatkowej złożoności, dodanie scentralizowanych źródeł awarii oraz użycie strategii niezawodności i dostępności, które powodują konflikt z tymi w usłudze Service Fabric.
Na poniższej ilustracji kolorujemy wszystkie jednostki, które przyczyniają się do domen błędów, i wyświetlamy listę wszystkich różnych domen błędów, które powodują. W tym przykładzie mamy centra danych ("DC"), stojaki ("R") i bloki ("B"). Jeśli każdy blok zawiera więcej niż jedną maszynę wirtualną, może istnieć inna warstwa w hierarchii domeny błędów.
W czasie wykonywania usługa Service Fabric Cluster Resource Manager uwzględnia domeny błędów w klastrze i układach planów. Repliki stanowe lub wystąpienia bezstanowe dla usługi są dystrybuowane, więc znajdują się w oddzielnych domenach błędów. Dystrybucja usługi między domenami błędów gwarantuje, że dostępność usługi nie zostanie naruszona, gdy domena błędów ulegnie awarii na żadnym poziomie hierarchii.
Menedżer zasobów klastra nie obchodzi, ile warstw znajduje się w hierarchii domeny błędów. Próbuje się upewnić, że utrata jednej części hierarchii nie ma wpływu na uruchomione w niej usługi.
Najlepiej, jeśli ta sama liczba węzłów znajduje się na każdym poziomie głębokości w hierarchii domeny błędów. Jeśli "drzewo" domen błędów jest niezrównoważone w klastrze, trudniej jest ustalić najlepszą alokację usług przez menedżera zasobów klastra. Niezrównoważony układ domeny błędów oznacza, że utrata niektórych domen wpływa na dostępność usług bardziej niż inne domeny. W związku z tym menedżer zasobów klastra jest rozdarty między dwoma celami:
- Chce korzystać z maszyn w tej "ciężkiej" domenie, umieszczając na nich usługi.
- Chce umieścić usługi w innych domenach, aby utrata domeny nie powodowała problemów.
Jak wyglądają niezrównoważonych domen? Na poniższym diagramie przedstawiono dwa różne układy klastra. W pierwszym przykładzie węzły są równomiernie dystrybuowane między domenami błędów. W drugim przykładzie jedna domena błędów ma o wiele więcej węzłów niż inne domeny błędów.
Na platformie Azure wybór domeny błędów zawiera węzeł, jest zarządzany. Jednak w zależności od liczby aprowizowania węzłów nadal można znaleźć domeny błędów, które mają więcej węzłów w nich niż w innych.
Załóżmy na przykład, że w klastrze istnieje pięć domen błędów, ale aprowizacja siedmiu węzłów dla typu węzła (NodeType). W takim przypadku pierwsze dwie domeny błędów kończą się większą większa liczba węzłów. Jeśli nadal wdrażasz więcej wystąpień NodeType tylko z kilkoma wystąpieniami, problem będzie się pogarszać. Z tego powodu zalecamy, aby liczba węzłów w każdym typie węzła to wielokrotność liczby domen błędów.
Uaktualnianie domen
Domeny uaktualniania to kolejna funkcja, która pomaga usłudze Service Fabric Cluster Resource Manager zrozumieć układ klastra. Domeny uaktualniania definiują zestawy węzłów, które są uaktualniane w tym samym czasie. Domeny uaktualniania ułatwiają usłudze Resource Manager klastra zrozumienie i organizowanie operacji zarządzania, takich jak uaktualnienia.
Domeny uaktualniania są bardzo podobne do domen błędów, ale z kilkoma kluczowymi różnicami. Po pierwsze obszary skoordynowanych awarii sprzętu definiują domeny błędów. Z drugiej strony domeny uaktualniania są definiowane przez zasady. Możesz zdecydować, ile chcesz, zamiast zezwalać środowisku na określenie liczby. Można mieć dowolną liczbę domen uaktualniania, jak węzły. Inną różnicą między domenami błędów a domenami uaktualniania jest to, że domeny uaktualniania nie są hierarchiczne. Zamiast tego są one bardziej podobne do prostego tagu.
Na poniższym diagramie przedstawiono trzy domeny uaktualniania rozłożone na trzy domeny błędów. Przedstawiono również jedno możliwe umieszczenie trzech różnych replik usługi stanowej, gdzie każda kończy się w różnych domenach błędów i uaktualnień. To umieszczenie umożliwia utratę domeny błędów podczas uaktualniania usługi i nadal ma jedną kopię kodu i danych.
Istnieją zalety i wady dotyczące dużej liczby domen uaktualniania. Więcej domen uaktualnienia oznacza, że każdy krok uaktualnienia jest bardziej szczegółowy i ma wpływ na mniejszą liczbę węzłów lub usług. Mniejsza liczba usług musi się przenosić naraz, wprowadzając mniej zmian w systemie. Ma to tendencję do poprawy niezawodności, ponieważ mniej usługi ma wpływ na wszelkie problemy wprowadzone podczas uaktualniania. Więcej domen uaktualnienia oznacza również, że potrzebujesz mniej dostępnego buforu w innych węzłach, aby obsłużyć wpływ uaktualnienia.
Jeśli na przykład masz pięć domen uaktualnienia, węzły w każdym z nich obsługują około 20 procent ruchu. Jeśli musisz usunąć domenę uaktualnienia na potrzeby uaktualnienia, obciążenie zwykle musi przejść gdzieś. Ponieważ masz cztery pozostałe domeny uaktualnienia, każdy musi mieć miejsce na około 25 procent całkowitego ruchu. Więcej domen uaktualniania oznacza, że potrzebujesz mniejszego buforu w węzłach w klastrze.
Rozważ, czy zamiast tego masz 10 domen uaktualnienia. W takim przypadku każda domena uaktualnienia będzie obsługiwać tylko około 10 procent całkowitego ruchu. W przypadku wykonania kroków uaktualniania przez klaster każda domena musi mieć miejsce tylko na około 11 procent całkowitego ruchu. Więcej domen uaktualnienia zwykle umożliwia uruchamianie węzłów przy wyższym wykorzystaniu, ponieważ potrzebna jest mniejsza pojemność zarezerwowana. To samo dotyczy domen błędów.
Wadą posiadania wielu domen uaktualnienia jest to, że uaktualnienia zwykle trwa dłużej. Usługa Service Fabric czeka krótki okres po zakończeniu uaktualniania domeny i przeprowadza kontrole przed rozpoczęciem uaktualniania następnego. Te opóźnienia umożliwiają wykrywanie problemów wprowadzonych przez uaktualnienie przed kontynuowaniem uaktualniania. Kompromis jest akceptowalny, ponieważ uniemożliwia nieprawidłowe zmiany wpływające na zbyt dużą część usługi naraz.
Obecność zbyt niewielu domen uaktualnienia ma wiele negatywnych skutków ubocznych. Chociaż każda domena uaktualnienia nie działa i jest uaktualniana, duża część ogólnej pojemności jest niedostępna. Jeśli na przykład masz tylko trzy domeny uaktualnienia, jednocześnie zajmujesz około jednej trzeciej ogólnej pojemności usługi lub klastra. Posiadanie tak dużej ilości usługi naraz nie jest pożądane, ponieważ potrzebujesz wystarczającej pojemności w pozostałej części klastra, aby obsłużyć obciążenie. Utrzymywanie tego buforu oznacza, że podczas normalnego działania te węzły są mniej ładowane niż w przeciwnym razie. Zwiększa to koszt działania usługi.
Nie ma rzeczywistego limitu całkowitej liczby domen błędów lub uaktualnień w środowisku ani ograniczeń dotyczących ich nakładania się. Istnieją jednak typowe wzorce:
- Domeny błędów i domeny uaktualniania mapowane 1:1
- Jedna domena uaktualnienia na węzeł (wystąpienie fizycznego lub wirtualnego systemu operacyjnego)
- Model "rozłożony" lub "macierz", w którym domeny błędów i domeny uaktualniania tworzą macierz z maszynami, które zwykle działają w dół przekątnej
Nie ma najlepszej odpowiedzi na wybór układu. Każdy ma zalety i wady. Na przykład model 1FD:1UD jest prosty do skonfigurowania. Model jednej domeny uaktualnienia na model węzła jest najbardziej podobny do tego, do czego służą osoby. Podczas uaktualniania każdy węzeł jest aktualizowany niezależnie. Jest to podobne do tego, jak małe zestawy maszyn zostały uaktualnione ręcznie w przeszłości.
Najczęstszym modelem jest macierz FD/UD, w której domeny błędów i domeny uaktualniania tworzą tabelę i węzły są umieszczane po przekątnej. Jest to model używany domyślnie w klastrach usługi Service Fabric na platformie Azure. W przypadku klastrów z wieloma węzłami wszystko wygląda jak gęsty wzorzec macierzy.
Uwaga
Klastry usługi Service Fabric hostowane na platformie Azure nie obsługują zmiany strategii domyślnej. Tylko autonomiczne klastry oferują to dostosowanie.
Ograniczenia domeny błędów i uaktualniania oraz wynikające z tego zachowanie
Podejście domyślne
Domyślnie usługa Resource Manager klastra utrzymuje zrównoważony poziom usług w domenach błędów i uaktualnień. Jest to modelowane jako ograniczenie. Ograniczenie dla domen błędów i uaktualnień stwierdza: "W przypadku danej partycji usługi nigdy nie powinna istnieć różnica większa niż jedna w liczbie obiektów usługi (bezstanowych wystąpień usługi lub replik usług stanowych) między dowolnymi dwiema domenami na tym samym poziomie hierarchii.
Załóżmy, że to ograniczenie zapewnia "maksymalną różnicę". Ograniczenie dla domen błędów i uaktualniania uniemożliwia pewne ruchy lub ustalenia, które naruszają regułę.
Załóżmy na przykład, że mamy klaster z sześcioma węzłami skonfigurowanymi z pięcioma domenami błędów i pięcioma domenami uaktualniania.
| FD0 | FD1 | FD2 | FD3 | FD4 | |
|---|---|---|---|---|---|
| UD0 | N1 | ||||
| Ud1 | N6 | N2 | |||
| UD2 | N3 | ||||
| UD3 | N4 | ||||
| UD4 | N5 |
Teraz załóżmy, że utworzymy usługę z wartością TargetReplicaSetSize (lub dla usługi bezstanowej InstanceCount) równą pięć. Repliki wylądowały na N1-N5. W rzeczywistości N6 nigdy nie jest używana niezależnie od liczby usług takich jak ten, które tworzysz. Ale dlaczego? Przyjrzyjmy się różnicy między bieżącym układem a tym, co się stanie, jeśli wybrano N6.
Oto układ, który mamy i łączną liczbę replik na błąd i domenę uaktualnienia:
| FD0 | FD1 | FD2 | FD3 | FD4 | UdTotal | |
|---|---|---|---|---|---|---|
| UD0 | R1 | 1 | ||||
| Ud1 | R2 | 1 | ||||
| UD2 | R3 | 1 | ||||
| UD3 | R4 | 1 | ||||
| UD4 | R5 | 1 | ||||
| FDTotal | 1 | 1 | 1 | 1 | 1 | - |
Ten układ jest zrównoważony pod względem węzłów na domenę błędów i domenę uaktualniania. Jest ona również zrównoważona pod względem liczby replik na domenę błędów i uaktualniania. Każda domena ma taką samą liczbę węzłów i taką samą liczbę replik.
Teraz przyjrzyjmy się temu, co by się stało, gdybyśmy używali N6 zamiast N2. W jaki sposób repliki będą następnie dystrybuowane?
| FD0 | FD1 | FD2 | FD3 | FD4 | UdTotal | |
|---|---|---|---|---|---|---|
| UD0 | R1 | 1 | ||||
| Ud1 | R5 | 1 | ||||
| UD2 | R2 | 1 | ||||
| UD3 | R3 | 1 | ||||
| UD4 | R4 | 1 | ||||
| FDTotal | 2 | 0 | 1 | 1 | 1 | - |
Ten układ narusza definicję "maksymalnej różnicy" gwarancji dla ograniczenia domeny błędów. FD0 ma dwie repliki, podczas gdy FD1 ma zero. Różnica między FD0 i FD1 wynosi łącznie dwa, co jest większe niż maksymalna różnica jednego. Ponieważ ograniczenie jest naruszone, menedżer zasobów klastra nie zezwala na to rozwiązanie.
Podobnie, jeśli wybraliśmy N2 i N6 (zamiast N1 i N2), otrzymamy:
| FD0 | FD1 | FD2 | FD3 | FD4 | UdTotal | |
|---|---|---|---|---|---|---|
| UD0 | 0 | |||||
| Ud1 | R5 | R1 | 2 | |||
| UD2 | R2 | 1 | ||||
| UD3 | R3 | 1 | ||||
| UD4 | R4 | 1 | ||||
| FDTotal | 1 | 1 | 1 | 1 | 1 | - |
Ten układ jest zrównoważony pod względem domen błędów. Ale teraz narusza to ograniczenie domeny uaktualnienia, ponieważ ud0 ma zero replik i UD1 ma dwa. Ten układ jest również nieprawidłowy i nie zostanie wybrany przez usługę Resource Manager klastra.
Takie podejście do dystrybucji replik stanowych lub wystąpień bezstanowych zapewnia najlepszą możliwą odporność na uszkodzenia. Jeśli jedna domena ulegnie awarii, minimalna liczba replik/wystąpień zostanie utracona.
Z drugiej strony takie podejście może być zbyt rygorystyczne i nie pozwala klastrowi korzystać ze wszystkich zasobów. W przypadku niektórych konfiguracji klastra nie można używać niektórych węzłów. Może to spowodować, że usługa Service Fabric nie umieszcza usług, co powoduje wyświetlanie komunikatów ostrzegawczych. W poprzednim przykładzie nie można użyć niektórych węzłów klastra (W przykładzie N6). Nawet jeśli dodano węzły do tego klastra (N7-N10), repliki/wystąpienia zostaną umieszczone tylko w N1–N5 z powodu ograniczeń dotyczących domen błędów i uaktualniania.
| FD0 | FD1 | FD2 | FD3 | FD4 | |
|---|---|---|---|---|---|
| UD0 | N1 | N10 | |||
| Ud1 | N6 | N2 | |||
| UD2 | N7 | N3 | |||
| UD3 | N8 | N4 | |||
| UD4 | N9 | N5 |
Alternatywne podejście
Usługa Resource Manager klastra obsługuje inną wersję ograniczenia dla domen błędów i uaktualnień. Umożliwia umieszczanie przy jednoczesnym zagwarantowaniu minimalnego poziomu bezpieczeństwa. Alternatywne ograniczenie można określić w następujący sposób: "W przypadku danej partycji usługi dystrybucja replik między domenami powinna zapewnić, że partycja nie ma utraty kworum". Załóżmy, że to ograniczenie zapewnia gwarancję "bezpiecznego kworum".
Uwaga
W przypadku usługi stanowej definiujemy utratę kworum w sytuacji, gdy większość replik partycji nie działa w tym samym czasie. Na przykład jeśli parametr TargetReplicaSetSize wynosi pięć, zestaw dowolnych trzech replik reprezentuje kworum. Podobnie jeśli parametr TargetReplicaSetSize wynosi sześć, cztery repliki są niezbędne do kworum. W obu przypadkach nie więcej niż dwie repliki mogą być w tym samym czasie wyłączone, jeśli partycja chce kontynuować normalne działanie.
W przypadku usługi bezstanowej nie ma czegoś takiego jak utrata kworum. Usługi bezstanowe nadal działają normalnie, nawet jeśli większość wystąpień spadnie w tym samym czasie. Dlatego skupimy się na usługach stanowych w pozostałej części tego artykułu.
Wróćmy do poprzedniego przykładu. W przypadku wersji "bezpieczne kworum" ograniczenia wszystkie trzy układy będą prawidłowe. Nawet jeśli FD0 nie powiodło się w drugim układzie lub ud1 nie powiodło się w trzecim układzie, partycja nadal będzie miała kworum. (Większość replik nadal będzie działać). Z tą wersją ograniczenia, N6 może prawie zawsze być używane.
Podejście "bezpieczne kworum" zapewnia większą elastyczność niż podejście "maksymalna różnica". Przyczyną jest to, że łatwiej jest znaleźć dystrybucje replik, które są prawidłowe w prawie każdej topologii klastra. Jednak takie podejście nie może zagwarantować najlepszej charakterystyki odporności na uszkodzenia, ponieważ niektóre awarie są gorsze niż inne.
W najgorszym scenariuszu większość replik może zostać utracona z powodu awarii jednej domeny i jednej dodatkowej repliki. Na przykład zamiast trzech niepowodzeń wymaganych do utraty kworum z pięcioma replikami lub wystąpieniami można teraz utracić większość z zaledwie dwoma awariami.
Podejście adaptacyjne
Ponieważ oba podejścia mają mocne i słabe strony, wprowadziliśmy adaptacyjne podejście, które łączy te dwie strategie.
Uwaga
Jest to zachowanie domyślne, począwszy od usługi Service Fabric w wersji 6.2.
Podejście adaptacyjne domyślnie używa logiki "maksymalnej różnicy" i przełącza się do logiki "bezpieczne kworum" tylko wtedy, gdy jest to konieczne. Usługa Resource Manager klastra automatycznie określa, która strategia jest niezbędna, sprawdzając sposób konfigurowania klastra i usług.
Menedżer zasobów klastra powinien używać logiki "opartej na kworum" dla usługi, która spełnia oba te warunki:
- TargetReplicaSetSize dla usługi jest równomiernie podzielna przez liczbę domen błędów i liczbę domen uaktualnienia.
- Liczba węzłów jest mniejsza lub równa liczbie domen błędów pomnożonych przez liczbę domen uaktualnienia.
Należy pamiętać, że usługa Resource Manager klastra będzie używać tego podejścia zarówno w przypadku usług bezstanowych, jak i stanowych, mimo że utrata kworum nie jest odpowiednia dla usług bezstanowych.
Wróćmy do poprzedniego przykładu i załóżmy, że klaster ma teraz osiem węzłów. Klaster jest nadal skonfigurowany z pięcioma domenami błędów i pięcioma domenami uaktualniania, a wartość TargetReplicaSetSize usługi hostowanej w tym klastrze pozostaje pięć.
| FD0 | FD1 | FD2 | FD3 | FD4 | |
|---|---|---|---|---|---|
| UD0 | N1 | ||||
| Ud1 | N6 | N2 | |||
| UD2 | N7 | N3 | |||
| UD3 | N8 | N4 | |||
| UD4 | N5 |
Ponieważ wszystkie niezbędne warunki są spełnione, usługa Resource Manager klastra będzie używać logiki "opartej na kworum" w dystrybucji usługi. Umożliwia to użycie N6-N8. Jedna z możliwych dystrybucji usług w tym przypadku może wyglądać następująco:
| FD0 | FD1 | FD2 | FD3 | FD4 | UdTotal | |
|---|---|---|---|---|---|---|
| UD0 | R1 | 1 | ||||
| Ud1 | R2 | 1 | ||||
| UD2 | R3 | R4 | 2 | |||
| UD3 | 0 | |||||
| UD4 | R5 | 1 | ||||
| FDTotal | 2 | 1 | 1 | 0 | 1 | - |
Jeśli wartość TargetReplicaSetSize usługi jest ograniczona do czterech (na przykład), menedżer zasobów klastra zauważy, że ta zmiana zostanie zmieniona. Zostanie wznowione użycie logiki "maksymalna różnica", ponieważ parametr TargetReplicaSetSize nie jest już podzielony przez liczbę domen błędów i domen uaktualniania. W związku z tym niektóre ruchy replik będą wykonywane w celu dystrybucji pozostałych czterech replik w węzłach N1-N5. W ten sposób "maksymalna różnica" wersji domeny błędów i uaktualniania logiki domeny nie jest naruszona.
W poprzednim układzie, jeśli wartość TargetReplicaSetSize wynosi pięć, a N1 zostanie usunięta z klastra, liczba domen uaktualnienia będzie równa czterech. Ponownie menedżer zasobów klastra zaczyna używać logiki "maksymalnej różnicy", ponieważ liczba domen uaktualnienia nie dzieli już wartości TargetReplicaSetSize usługi. W rezultacie replika R1, po ponownym utworzeniu, musi wylądować na N4, aby ograniczenie dla domeny błędów i uaktualniania nie zostało naruszone.
| FD0 | FD1 | FD2 | FD3 | FD4 | UdTotal | |
|---|---|---|---|---|---|---|
| UD0 | Brak | NIE DOTYCZY | NIE DOTYCZY | NIE DOTYCZY | NIE DOTYCZY | Brak |
| Ud1 | R2 | 1 | ||||
| UD2 | R3 | R4 | 2 | |||
| UD3 | R1 | 1 | ||||
| UD4 | R5 | 1 | ||||
| FDTotal | 1 | 1 | 1 | 1 | 1 | - |
Konfigurowanie domen błędów i uaktualniania
W przypadku wdrożeń usługi Service Fabric hostowanych na platformie Azure domeny błędów i domeny uaktualniania są definiowane automatycznie. Usługa Service Fabric pobiera i używa informacji o środowisku z platformy Azure.
Jeśli tworzysz własny klaster (lub chcesz uruchomić konkretną topologię w programowania), możesz samodzielnie podać domenę błędów i uaktualnić informacje o domenie. W tym przykładzie definiujemy lokalny klaster deweloperów z dziewięciu węzłów obejmujący trzy centra danych (z których każdy ma trzy stojaki). Ten klaster ma również trzy domeny uaktualniania rozłożone w tych trzech centrach danych. Oto przykład konfiguracji w ClusterManifest.xml:
<Infrastructure>
<!-- IsScaleMin indicates that this cluster runs on one box/one single server -->
<WindowsServer IsScaleMin="true">
<NodeList>
<Node NodeName="Node01" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType01" FaultDomain="fd:/DC01/Rack01" UpgradeDomain="UpgradeDomain1" IsSeedNode="true" />
<Node NodeName="Node02" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType02" FaultDomain="fd:/DC01/Rack02" UpgradeDomain="UpgradeDomain2" IsSeedNode="true" />
<Node NodeName="Node03" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType03" FaultDomain="fd:/DC01/Rack03" UpgradeDomain="UpgradeDomain3" IsSeedNode="true" />
<Node NodeName="Node04" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType04" FaultDomain="fd:/DC02/Rack01" UpgradeDomain="UpgradeDomain1" IsSeedNode="true" />
<Node NodeName="Node05" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType05" FaultDomain="fd:/DC02/Rack02" UpgradeDomain="UpgradeDomain2" IsSeedNode="true" />
<Node NodeName="Node06" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType06" FaultDomain="fd:/DC02/Rack03" UpgradeDomain="UpgradeDomain3" IsSeedNode="true" />
<Node NodeName="Node07" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType07" FaultDomain="fd:/DC03/Rack01" UpgradeDomain="UpgradeDomain1" IsSeedNode="true" />
<Node NodeName="Node08" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType08" FaultDomain="fd:/DC03/Rack02" UpgradeDomain="UpgradeDomain2" IsSeedNode="true" />
<Node NodeName="Node09" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType09" FaultDomain="fd:/DC03/Rack03" UpgradeDomain="UpgradeDomain3" IsSeedNode="true" />
</NodeList>
</WindowsServer>
</Infrastructure>
W tym przykładzie użyto ClusterConfig.json dla wdrożeń autonomicznych:
"nodes": [
{
"nodeName": "vm1",
"iPAddress": "localhost",
"nodeTypeRef": "NodeType0",
"faultDomain": "fd:/dc1/r0",
"upgradeDomain": "UD1"
},
{
"nodeName": "vm2",
"iPAddress": "localhost",
"nodeTypeRef": "NodeType0",
"faultDomain": "fd:/dc1/r0",
"upgradeDomain": "UD2"
},
{
"nodeName": "vm3",
"iPAddress": "localhost",
"nodeTypeRef": "NodeType0",
"faultDomain": "fd:/dc1/r0",
"upgradeDomain": "UD3"
},
{
"nodeName": "vm4",
"iPAddress": "localhost",
"nodeTypeRef": "NodeType0",
"faultDomain": "fd:/dc2/r0",
"upgradeDomain": "UD1"
},
{
"nodeName": "vm5",
"iPAddress": "localhost",
"nodeTypeRef": "NodeType0",
"faultDomain": "fd:/dc2/r0",
"upgradeDomain": "UD2"
},
{
"nodeName": "vm6",
"iPAddress": "localhost",
"nodeTypeRef": "NodeType0",
"faultDomain": "fd:/dc2/r0",
"upgradeDomain": "UD3"
},
{
"nodeName": "vm7",
"iPAddress": "localhost",
"nodeTypeRef": "NodeType0",
"faultDomain": "fd:/dc3/r0",
"upgradeDomain": "UD1"
},
{
"nodeName": "vm8",
"iPAddress": "localhost",
"nodeTypeRef": "NodeType0",
"faultDomain": "fd:/dc3/r0",
"upgradeDomain": "UD2"
},
{
"nodeName": "vm9",
"iPAddress": "localhost",
"nodeTypeRef": "NodeType0",
"faultDomain": "fd:/dc3/r0",
"upgradeDomain": "UD3"
}
],
Uwaga
Podczas definiowania klastrów za pośrednictwem usługi Azure Resource Manager platforma Azure przypisuje domeny błędów i domeny uaktualniania. Dlatego definicja typów węzłów i zestawów skalowania maszyn wirtualnych w szablonie usługi Azure Resource Manager nie zawiera informacji o domenie błędów ani domenie uaktualniania.
Właściwości węzła i ograniczenia umieszczania
Czasami (w rzeczywistości przez większość czasu) należy upewnić się, że niektóre obciążenia działają tylko na niektórych typach węzłów w klastrze. Na przykład niektóre obciążenia mogą wymagać procesorów GPU lub dysków SSD, a inne mogą nie.
Doskonałym przykładem ukierunkowania sprzętu na konkretne obciążenia jest prawie każda architektura n-warstwowa. Niektóre maszyny pełnią rolę frontonu lub interfejsu API obsługującego aplikację i są widoczne dla klientów lub Internetu. Różne maszyny, często z różnymi zasobami sprzętowymi, obsługują pracę warstw obliczeniowych lub magazynowych. Zazwyczaj nie są one bezpośrednio widoczne dla klientów ani Internetu.
Usługa Service Fabric oczekuje, że w niektórych przypadkach określone obciążenia mogą wymagać uruchomienia w określonych konfiguracjach sprzętu. Na przykład:
- Istniejąca aplikacja n-warstwowa została "zniesiona i przeniesiona" do środowiska usługi Service Fabric.
- Obciążenie musi być uruchamiane na określonym sprzęcie ze względów wydajności, skalowania lub izolacji zabezpieczeń.
- Obciążenie powinno być odizolowane od innych obciążeń ze względów związanych z zasadami lub zużyciem zasobów.
Aby obsługiwać te konfiguracje, usługa Service Fabric zawiera tagi, które można zastosować do węzłów. Te tagi są nazywane właściwościami węzła. Ograniczenia umieszczania to instrukcje dołączone do poszczególnych usług wybranych dla co najmniej jednej właściwości węzła. Ograniczenia umieszczania definiują miejsce uruchamiania usług. Zestaw ograniczeń jest rozszerzalny. Każda para klucz/wartość może działać.
Właściwości wbudowanego węzła
Usługa Service Fabric definiuje niektóre domyślne właściwości węzła, które mogą być używane automatycznie, dzięki czemu nie trzeba ich definiować. Domyślne właściwości zdefiniowane w każdym węźle to NodeType i NodeName.
Na przykład możesz napisać ograniczenie umieszczania jako "(NodeType == NodeType03)". NodeType jest powszechnie używaną właściwością. Jest to przydatne, ponieważ odpowiada 1:1 typowi maszyny. Każdy typ maszyny odpowiada typowi obciążenia w tradycyjnej aplikacji n-warstwowej.
Ograniczenia umieszczania i składnia właściwości węzła
Wartość określona we właściwości node może być ciągiem, wartością logiczną lub znakiem długim. Instrukcja w usłudze jest nazywana ograniczeniem umieszczania, ponieważ ogranicza, gdzie usługa może działać w klastrze. Ograniczeniem może być dowolna instrukcja logiczna, która działa we właściwościach węzła w klastrze. Prawidłowe selektory w tych instrukcjach logicznych to:
Sprawdzanie warunkowe tworzenia określonych instrukcji:
Oświadczenie Składnia "równe" "==" "nie równa się" "!=" "większe niż" ">" "większe niż lub równe" ">=" "mniej niż" "<" "mniejsze niż lub równe" "<=" Instrukcje logiczne dla operacji grupowania i operacji logicznych:
Oświadczenie Składnia "i" "&&" "lub" "||" "nie" "!" "grupuj jako pojedynczą instrukcję" "()"
Oto kilka przykładów podstawowych instrukcji ograniczeń:
"Value >= 5""NodeColor != green""((OneProperty < 100) || ((AnotherProperty == false) && (OneProperty >= 100)))"
Tylko węzły, w których ogólna instrukcja ograniczenia umieszczania ocenia wartość "True", może umieścić na niej usługę. Węzły, które nie mają zdefiniowanej właściwości, nie są zgodne z żadnym ograniczeniem umieszczania zawierającym właściwość .
Załóżmy, że następujące właściwości węzła zostały zdefiniowane dla typu węzła w ClusterManifest.xml:
<NodeType Name="NodeType01">
<PlacementProperties>
<Property Name="HasSSD" Value="true"/>
<Property Name="NodeColor" Value="green"/>
<Property Name="SomeProperty" Value="5"/>
</PlacementProperties>
</NodeType>
W poniższym przykładzie przedstawiono właściwości węzła zdefiniowane za pośrednictwem ClusterConfig.json dla wdrożeń autonomicznych lub Template.json dla klastrów hostowanych na platformie Azure.
Uwaga
W szablonie usługi Azure Resource Manager typ węzła jest zwykle sparametryzowany. Wyglądałoby "[parameters('vmNodeType1Name')]" to zamiast NodeType01.
"nodeTypes": [
{
"name": "NodeType01",
"placementProperties": {
"HasSSD": "true",
"NodeColor": "green",
"SomeProperty": "5"
},
}
],
Ograniczenia umieszczania usługi dla usługi można utworzyć w następujący sposób:
FabricClient fabricClient = new FabricClient();
StatefulServiceDescription serviceDescription = new StatefulServiceDescription();
serviceDescription.PlacementConstraints = "(HasSSD == true && SomeProperty >= 4)";
// Add other required ServiceDescription fields
//...
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);
New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceType -Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton -PlacementConstraint "HasSSD == true && SomeProperty >= 4"
Jeśli wszystkie węzły nodeType01 są prawidłowe, możesz również wybrać ten typ węzła z ograniczeniem "(NodeType == NodeType01)".
Ograniczenia umieszczania usługi można aktualizować dynamicznie w czasie wykonywania. Jeśli chcesz, możesz przenieść usługę w klastrze, dodać i usunąć wymagania itd. Usługa Service Fabric zapewnia, że usługa pozostaje w trybie i jest dostępna nawet wtedy, gdy te typy zmian zostaną wprowadzone.
StatefulServiceUpdateDescription updateDescription = new StatefulServiceUpdateDescription();
updateDescription.PlacementConstraints = "NodeType == NodeType01";
await fabricClient.ServiceManager.UpdateServiceAsync(new Uri("fabric:/app/service"), updateDescription);
Update-ServiceFabricService -Stateful -ServiceName $serviceName -PlacementConstraints "NodeType == NodeType01"
Ograniczenia umieszczania są określane dla każdego nazwanego wystąpienia usługi. Aktualizacje zawsze mają miejsce (zastępowanie) wcześniej określonych elementów.
Definicja klastra definiuje właściwości w węźle. Zmiana właściwości węzła wymaga uaktualnienia do konfiguracji klastra. Uaktualnienie właściwości węzła wymaga ponownego uruchomienia każdego węzła, którego dotyczy problem, aby zgłosić nowe właściwości. Usługa Service Fabric zarządza tymi uaktualnieniami kroczącymi.
Opisywanie zasobów klastra i zarządzanie nimi
Jednym z najważniejszych zadań każdego orkiestratora jest pomoc w zarządzaniu zużyciem zasobów w klastrze. Zarządzanie zasobami klastra może oznaczać kilka różnych rzeczy.
Najpierw należy upewnić się, że maszyny nie są przeciążone. Oznacza to, że maszyny nie działają więcej usług niż mogą obsługiwać.
Po drugie, istnieje równoważenie i optymalizacja, które mają kluczowe znaczenie dla wydajnego uruchamiania usług. Ekonomiczne lub wrażliwe na wydajność oferty usług nie mogą zezwalać niektórym węzłom na gorąco, podczas gdy inne są zimne. Węzły gorące prowadzą do rywalizacji o zasoby i niską wydajność. Zimne węzły reprezentują zmarnowane zasoby i zwiększone koszty.
Usługa Service Fabric reprezentuje zasoby jako metryki. Metryki to dowolny zasób logiczny lub fizyczny, który chcesz opisać w usłudze Service Fabric. Przykłady metryk to "WorkQueueDepth" lub "MemoryInMb". Aby uzyskać informacje o zasobach fizycznych, którymi usługa Service Fabric może zarządzać w węzłach, zobacz Zarządzanie zasobami. Aby uzyskać informacje na temat domyślnych metryk używanych przez menedżera zasobów klastra i sposobu konfigurowania metryk niestandardowych, zobacz ten artykuł.
Metryki różnią się od ograniczeń umieszczania i właściwości węzła. Właściwości węzła to statyczne deskryptory samych węzłów. Metryki opisują zasoby, które węzły mają i z których korzystają usługi podczas uruchamiania w węźle. Właściwość węzła może mieć wartość HasSSD i może być ustawiona na wartość true lub false. Ilość miejsca dostępnego na tym dysku SSD i ilość zużywana przez usługi będzie metryką podobną do "DriveSpaceInMb".
Podobnie jak w przypadku ograniczeń umieszczania i właściwości węzła, usługa Service Fabric Cluster Resource Manager nie rozumie, jakie są nazwy metryk. Nazwy metryk to tylko ciągi. Dobrym rozwiązaniem jest deklarowanie jednostek w ramach nazw metryk tworzonych, gdy mogą być niejednoznaczne.
Wydajność
Jeśli wyłączysz wszystkie równoważenie zasobów, menedżer zasobów klastra usługi Service Fabric nadal zapewni, że żaden węzeł nie przekroczy jego pojemności. Zarządzanie przekroczeniami pojemności jest możliwe, chyba że klaster jest zbyt pełny lub obciążenie jest większe niż jakikolwiek węzeł. Pojemność jest kolejnym ograniczeniem używanym przez usługę Resource Manager klastra w celu zrozumienia, ile zasobów ma węzeł. Pozostała pojemność jest również śledzona dla klastra jako całości.
Zarówno pojemność, jak i zużycie na poziomie usługi są wyrażane pod względem metryk. Na przykład metryka może mieć wartość "ClientConnections", a węzeł może mieć pojemność "ClientConnections" wynoszącą 32 768. Inne węzły mogą mieć inne limity. Usługa uruchomiona w tym węźle może powiedzieć, że obecnie zużywa 32 256 metryki "ClientConnections".
W czasie wykonywania usługa Resource Manager klastra śledzi pozostałą pojemność w klastrze i w węzłach. Aby śledzić pojemność, menedżer zasobów klastra odejmuje użycie poszczególnych usług z pojemności węzła, w której działa usługa. Dzięki tym informacjom menedżer zasobów klastra może ustalić, gdzie umieścić lub przenieść repliki, aby węzły nie przejdą przez pojemność.
StatefulServiceDescription serviceDescription = new StatefulServiceDescription();
ServiceLoadMetricDescription metric = new ServiceLoadMetricDescription();
metric.Name = "ClientConnections";
metric.PrimaryDefaultLoad = 1024;
metric.SecondaryDefaultLoad = 0;
metric.Weight = ServiceLoadMetricWeight.High;
serviceDescription.Metrics.Add(metric);
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);
New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton –Metric @("ClientConnections,High,1024,0)
Pojemności zdefiniowane w manifeście klastra są widoczne. Oto przykład ClusterManifest.xml:
<NodeType Name="NodeType03">
<Capacities>
<Capacity Name="ClientConnections" Value="65536"/>
</Capacities>
</NodeType>
Oto przykład pojemności zdefiniowanych za pośrednictwem ClusterConfig.json dla wdrożeń autonomicznych lub Template.json dla klastrów hostowanych na platformie Azure:
"nodeTypes": [
{
"name": "NodeType03",
"capacities": {
"ClientConnections": "65536",
}
}
],
Obciążenie usługi często zmienia się dynamicznie. Załóżmy, że obciążenie repliki "ClientConnections" zmieniło się z 1024 na 2048. Węzeł, na którym był uruchomiony, miał wówczas pojemność tylko 512 pozostałych dla tej metryki. Teraz, gdy umieszczanie repliki lub wystąpienia jest nieprawidłowe, ponieważ w tym węźle nie ma wystarczającego miejsca. Menedżer zasobów klastra musi uzyskać węzeł z powrotem poniżej pojemności. Zmniejsza obciążenie węzła, który jest ponad pojemnością, przenosząc co najmniej jedną replikę lub wystąpienia z tego węzła do innych węzłów.
Usługa Resource Manager klastra próbuje zminimalizować koszt przenoszenia replik. Możesz dowiedzieć się więcej na temat kosztów przenoszenia i ponownego równoważenia strategii i reguł.
Pojemność klastra
W jaki sposób usługa Resource Manager klastra usługi Service Fabric zachowuje zbyt pełny klaster? W przypadku obciążenia dynamicznego nie ma zbyt wiele do zrobienia. Usługi mogą mieć swój skok obciążenia niezależnie od akcji, które wykonuje menedżer zasobów klastra. W rezultacie klaster z dużą ilością miejsca pracy dzisiaj może być niedomocowany, jeśli jutro wystąpi skok.
Kontrolki w usłudze Resource Manager klastra pomagają zapobiegać problemom. Pierwszą rzeczą, którą można zrobić, jest zapobieganie tworzeniu nowych obciążeń, które mogłyby spowodować, że klaster stanie się pełny.
Załóżmy, że tworzysz usługę bezstanową i jest z nią skojarzone pewne obciążenie. Usługa dba o metryki "DiskSpaceInMb". Usługa będzie używać pięciu jednostek "DiskSpaceInMb" dla każdego wystąpienia usługi. Chcesz utworzyć trzy wystąpienia usługi. Oznacza to, że do utworzenia tych wystąpień usługi potrzebne jest 15 jednostek "DiskSpaceInMb" w klastrze.
Usługa Resource Manager klastra stale oblicza pojemność i zużycie każdej metryki, dzięki czemu może określić pozostałą pojemność w klastrze. Jeśli za mało miejsca, usługa Resource Manager klastra odrzuca wywołanie w celu utworzenia usługi.
Ponieważ wymaganie jest tylko, że będzie dostępnych 15 jednostek, możesz przydzielić to miejsce na wiele różnych sposobów. Na przykład może istnieć jedna pozostała jednostka pojemności na 15 różnych węzłach lub trzy pozostałe jednostki pojemności na pięciu różnych węzłach. Jeśli menedżer zasobów klastra może zmienić kolejność elementów, więc w trzech węzłach jest dostępnych pięć jednostek, umieszcza usługę. Zmiana kolejności klastra jest zwykle możliwa, chyba że klaster jest prawie pełny lub z jakiegoś powodu nie można skonsolidować istniejących usług.
Bufor węzła i pojemność overbookingu
Jeśli zostanie określona pojemność węzła dla metryki, menedżer zasobów klastra nigdy nie umieści ani nie przeniesie replik do węzła, jeśli całkowite obciążenie przekroczy określoną pojemność węzła. Czasami może to uniemożliwić umieszczenie nowych replik lub zastąpienie replik, które zakończyły się niepowodzeniem, jeśli klaster jest w pobliżu pełnej pojemności, a replika z dużym obciążeniem musi zostać umieszczona, zastąpiona lub przeniesiona.
Aby zapewnić większą elastyczność, można określić bufor węzła lub pojemność overbookingu. Gdy dla metryki określono pojemność buforu węzła lub overbookingu, menedżer zasobów klastra podejmie próbę umieszczenia lub przeniesienia replik w taki sposób, że pojemność buforu lub nadmiernego tworzenia elementów pozostaje nieużywana, ale umożliwia użycie buforu lub pojemności overbookingu w razie potrzeby w przypadku akcji zwiększających dostępność usługi, takich jak:
- Nowe umieszczanie replik lub zastępowanie replik, które zakończyły się niepowodzeniem
- Umieszczanie podczas uaktualniania
- Naprawianie naruszeń miękkich i twardych ograniczeń
- Defragmentacja
Pojemność buforu węzła reprezentuje zarezerwowaną część pojemności poniżej określonej pojemności węzła, a pojemność overbookingu reprezentuje część dodatkowej pojemności powyżej określonej pojemności węzła. W obu przypadkach menedżer zasobów klastra podejmie próbę zwolnienia tej pojemności.
Jeśli na przykład węzeł ma określoną pojemność dla metryki CpuUpularyz 100 i procent buforu węzła dla tej metryki jest ustawiony na 20%, łączna i niebuforowana pojemność będzie wynosić odpowiednio 100 i 80, a menedżer zasobów klastra nie będzie umieszczać więcej niż 80 jednostek obciążenia na węźle w normalnych okolicznościach.
Bufor węzła powinien być używany, gdy chcesz zarezerwować część pojemności węzła, która będzie używana tylko dla akcji zwiększających dostępność usługi wymienionych powyżej.
Z drugiej strony, jeśli użyto wartości procentowej overbookingu węzła i ustawisz wartość 20%, łączna i niebuforowana pojemność będzie wynosić odpowiednio 120 i 100.
Pojemność overbookingu powinna być używana, gdy chcesz zezwolić usłudze Resource Manager klastra na umieszczenie replik w węźle, nawet jeśli całkowite użycie zasobów przekroczy pojemność. Może to służyć do zapewnienia dodatkowej dostępności dla usług kosztem wydajności. W przypadku użycia overbookingu logika aplikacji użytkownika musi być w stanie działać z mniejszą liczbą zasobów fizycznych, niż może być wymagana.
Jeśli określono bufor węzła lub pojemności overbookingu, menedżer zasobów klastra nie przeniesie ani nie umieści replik, jeśli całkowite obciążenie węzła docelowego przejdą przez łączną pojemność (pojemność węzła w przypadku buforu węzła i pojemności węzła + overbooking pojemności w przypadku overbookingu).
Pojemność overbookingu można również określić jako nieskończoną. W takim przypadku menedżer zasobów klastra podejmie próbę utrzymania całkowitego obciążenia węzła poniżej określonej pojemności węzła, ale może potencjalnie umieścić znacznie większe obciążenie węzła, co może prowadzić do poważnego obniżenia wydajności.
Metryka nie może mieć zarówno buforu węzła, jak i pojemności overbookingu określonej dla niej w tym samym czasie.
Oto przykład sposobu określania buforu węzła lub przepełniania pojemności w ClusterManifest.xml:
<Section Name="NodeBufferPercentage">
<Parameter Name="SomeMetric" Value="0.15" />
</Section>
<Section Name="NodeOverbookingPercentage">
<Parameter Name="SomeOtherMetric" Value="0.2" />
<Parameter Name=”MetricWithInfiniteOverbooking” Value=”-1.0” />
</Section>
Oto przykład sposobu określania buforu węzła lub przepełniania pojemności za pośrednictwem ClusterConfig.json dla wdrożeń autonomicznych lub Template.json dla klastrów hostowanych na platformie Azure:
"fabricSettings": [
{
"name": "NodeBufferPercentage",
"parameters": [
{
"name": "SomeMetric",
"value": "0.15"
}
]
},
{
"name": "NodeOverbookingPercentage",
"parameters": [
{
"name": "SomeOtherMetric",
"value": "0.20"
},
{
"name": "MetricWithInfiniteOverbooking",
"value": "-1.0"
}
]
}
]
Następne kroki
- Aby uzyskać informacje na temat architektury i przepływu informacji w usłudze Resource Manager klastra, zobacz Omówienie architektury usługi Resource Manager klastra.
- Definiowanie metryk defragmentacji jest jednym ze sposobów konsolidacji obciążenia węzłów zamiast rozkładania go. Aby dowiedzieć się, jak skonfigurować defragmentację, zobacz Defragmentacja metryk i ładowania w usłudze Service Fabric.
- Zacznij od początku i zapoznaj się z wprowadzeniem do usługi Service Fabric Cluster Resource Manager.
- Aby dowiedzieć się, jak usługa Resource Manager klastra zarządza obciążeniem i równoważy je w klastrze, zobacz Równoważenie klastra usługi Service Fabric.