Często zadawane pytania dotyczące usługi Service Fabric

Istnieje wiele często zadawanych pytań dotyczących tego, co może zrobić usługa Service Fabric i jak należy jej używać. Ten dokument zawiera wiele typowych pytań i odpowiedzi.

Uwaga

Do interakcji z platformą Azure zalecamy używanie modułu Azure Az w programie PowerShell. Aby rozpocząć, zobacz Instalowanie programu Azure PowerShell. Aby dowiedzieć się, jak przeprowadzić migrację do modułu Az PowerShell, zobacz Migracja programu Azure PowerShell z modułu AzureRM do modułu Az.

Konfigurowanie klastra i zarządzanie nim

Jak mogę wycofać certyfikat klastra usługi Service Fabric?

Wycofywanie wszelkich uaktualnień do aplikacji wymaga wykrycia awarii kondycji przed zatwierdzeniem zmiany kworum klastra usługi Service Fabric; zatwierdzone zmiany mogą być wprowadzane tylko do przodu. Inżynier eskalacji za pośrednictwem usług obsługi klienta może być wymagany do odzyskania klastra, jeśli coś wprowadza niemonitorowaną zmianę certyfikatu powodującego niezgodność. Uaktualnienie aplikacji usługi Service Fabric stosuje parametry uaktualniania aplikacji i zapewnia obietnicę uaktualnienia bez przestojów. Zgodnie z naszym zalecanym trybem uaktualniania aplikacji, automatyczny postęp za pośrednictwem domen aktualizacji jest oparty na przekazywaniu kontroli kondycji, co powoduje automatyczne wycofywanie w przypadku niepowodzenia aktualizacji usługi domyślnej.

Jeśli klaster nadal używa klasycznej właściwości odcisku palca certyfikatu w szablonie usługi Resource Manager, zalecamy zmianę klastra z odcisku palca certyfikatu na nazwę pospolitą, aby zastosować nowoczesne funkcje zarządzania wpisami tajnymi.

Czy mogę utworzyć klaster obejmujący wiele regionów platformy Azure lub moich własnych centrów danych?

Tak.

Podstawowa technologia klastrowania usługi Service Fabric może służyć do łączenia maszyn działających w dowolnym miejscu na świecie, o ile mają one łączność sieciową ze sobą. Jednak kompilowanie i uruchamianie takiego klastra może być skomplikowane.

Jeśli interesuje Cię ten scenariusz, zachęcamy do skontaktowania się za pośrednictwem listy problemów usługi GitHub usługi Service Fabric lub przedstawiciela pomocy technicznej w celu uzyskania dodatkowych wskazówek. Zespół usługi Service Fabric pracuje nad zapewnieniem dodatkowej przejrzystości, wskazówek i zaleceń dotyczących tego scenariusza.

Oto kilka rzeczy, które warto przemyśleć:

1. Zasób klastra usługi Service Fabric na platformie Azure jest obecnie regionalny, podobnie jak zestawy skalowania maszyn wirtualnych, na których jest oparty klaster. Oznacza to, że w przypadku awarii regionalnej możesz utracić możliwość zarządzania klastrem za pośrednictwem usługi Azure Resource Manager lub witryny Azure Portal. Może się tak zdarzyć, mimo że klaster pozostaje uruchomiony i można z nim bezpośrednio korzystać. Ponadto platforma Azure obecnie nie oferuje możliwości posiadania jednej sieci wirtualnej, która może być dostępna w różnych regionach. Oznacza to, że klaster z wieloma regionami na platformie Azure wymaga publicznych adresów IP dla każdej maszyny wirtualnej w zestawach skalowania maszyn wirtualnych lub w usłudze Azure VPN Gateway. Te opcje sieciowe mają różny wpływ na koszty, wydajność i pewien stopień projektowania aplikacji, dlatego przed utworzeniem takiego środowiska wymagana jest staranna analiza i planowanie.
2. Konserwacja, zarządzanie i monitorowanie tych maszyn może stać się skomplikowane, zwłaszcza w przypadku różnych typów środowisk, takich jak między różnymi dostawcami chmury lub między zasobami lokalnymi a platformą Azure. Należy zadbać o zapewnienie, że uaktualnienia, monitorowanie, zarządzanie i diagnostyka są zrozumiałe zarówno dla klastra, jak i aplikacji przed uruchomieniem obciążeń produkcyjnych w takim środowisku. Jeśli masz już doświadczenie w rozwiązywaniu tych problemów na platformie Azure lub we własnych centrach danych, prawdopodobnie te same rozwiązania można zastosować podczas kompilowania lub uruchamiania klastra usługi Service Fabric.

Czy węzły usługi Service Fabric automatycznie otrzymują aktualizacje systemu operacyjnego?

Obecnie możesz użyć funkcji automatycznego aktualizowania obrazów systemu operacyjnego zestawu skalowania maszyn wirtualnych.

W przypadku klastrów, które nie są uruchamiane na platformie Azure, udostępniliśmy aplikację do stosowania poprawek systemów operacyjnych pod węzłami usługi Service Fabric.

Czy mogę używać dużych zestawów skalowania maszyn wirtualnych w klastrze SF?

Krótka odpowiedź — nie.

Długa odpowiedź — mimo że duże zestawy skalowania maszyn wirtualnych umożliwiają skalowanie konfiguracji skalowania maszyn wirtualnych do 1000 wystąpień maszyn wirtualnych, robi to przy użyciu grup umieszczania (PG). Domeny błędów (FD) i domeny uaktualniania (UD) są spójne tylko w grupie umieszczania usługa Service Fabric używa identyfikatorów FD i identyfikatorów UD do podejmowania decyzji dotyczących umieszczania replik usługi/wystąpień usługi. Ponieważ identyfikatory FD i UD są porównywalne tylko w grupie umieszczania, sf nie może jej używać. Na przykład jeśli maszyna VM1 w pg1 ma topologię FD=0 i VM9 w PG2 ma topologię FD=4, nie oznacza to, że maszyny VM1 i VM2 znajdują się w dwóch różnych stojakach sprzętowych, dlatego sf nie może użyć wartości FD w tym przypadku do podejmowania decyzji dotyczących umieszczania.

Obecnie występują inne problemy z dużymi zestawami skalowania maszyn wirtualnych, takimi jak brak obsługi równoważenia obciążenia na poziomie 4. Aby uzyskać szczegółowe informacje na temat dużych zestawów skalowania, zobacz

Jaki jest minimalny rozmiar klastra usługi Service Fabric? Dlaczego nie może być mniejszy?

Minimalny obsługiwany rozmiar klastra usługi Service Fabric z obciążeniami produkcyjnymi to pięć węzłów. W przypadku scenariuszy deweloperskich obsługujemy jeden węzeł (zoptymalizowany pod kątem szybkiego programowania w programie Visual Studio) i pięć klastrów węzłów.

Wymagamy, aby klaster produkcyjny miał co najmniej pięć węzłów z następujących trzech powodów:

1. Nawet jeśli żadne usługi użytkownika nie są uruchomione, klaster usługi Service Fabric uruchamia zestaw usług systemu stanowego, w tym usługę nazewnictwa i usługę menedżera trybu failover. Te usługi systemowe są niezbędne, aby klaster pozostał operacyjny.
2. Zawsze umieszczamy jedną replikę usługi na węzeł, więc rozmiar klastra jest górną granicą liczby replik usługi (w rzeczywistości partycji).
3. Ponieważ uaktualnienie klastra spowoduje wyłączenie co najmniej jednego węzła, chcemy mieć bufor co najmniej jednego węzła, dlatego chcemy, aby klaster produkcyjny miał co najmniej dwa węzły oprócz minimum. Minimalny rozmiar kworum usługi systemowej, jak wyjaśniono poniżej.

Chcemy, aby klaster był dostępny w obliczu jednoczesnej awarii dwóch węzłów. Aby klaster usługi Service Fabric był dostępny, usługi systemowe muszą być dostępne. Stanowe usługi systemowe, takie jak usługa nazewnictwa i usługa menedżera trybu failover, które śledzą, jakie usługi zostały wdrożone w klastrze i gdzie są obecnie hostowane, zależą od silnej spójności. Ta silna spójność zależy z kolei od możliwości uzyskania kworum dla każdej danej aktualizacji stanu tych usług, gdzie kworum reprezentuje ścisłą większość replik (N/2 +1) dla danej usługi. W związku z tym, jeśli chcemy być odporni na jednoczesne utratę dwóch węzłów (jednoczesna utrata dwóch replik usługi systemowej), musimy mieć klasterSize — QuorumSize >= 2, co wymusza minimalny rozmiar na pięć.

Należy pamiętać, że w powyższym argumencie zakładaliśmy, że każdy węzeł ma replikę usługi systemowej; w związku z tym rozmiar kworum jest obliczany na podstawie liczby węzłów w klastrze. Jednak przez zmianę targetReplicaSetSize możemy zmniejszyć rozmiar kworum mniejszy niż (N/2+1), co może dać wrażenie, że możemy mieć klaster mniejszy niż 5 węzłów i nadal mieć 2 dodatkowe węzły powyżej rozmiaru kworum. Na przykład w klastrze 4 węzłów, jeśli ustawimy właściwość TargetReplicaSetSize na 3, rozmiar kworum na podstawie parametru TargetReplicaSetSize to (3/2 + 1) lub 2, w związku z tym mamy klasterSize — KworumSize = 4–2 = 2 >. Nie możemy jednak zagwarantować, że usługa systemowa będzie znajdować się w kworum lub powyżej, jeśli utracimy jednocześnie dowolną parę węzłów, może to oznaczać, że dwa utracone węzły hostowały dwie repliki, więc usługa systemowa przejdzie do utraty kworum (z tylko jedną repliką w lewo) i stanie się niedostępna.

W tym tle przyjrzyjmy się niektórym możliwym konfiguracjom klastra:

Jeden węzeł: ta opcja nie zapewnia wysokiej dostępności, ponieważ utrata pojedynczego węzła z jakiegokolwiek powodu oznacza utratę całego klastra.

Dwa węzły: kworum dla usługi wdrożonej w dwóch węzłach (N = 2) to 2 (2/2 + 1 = 2). W przypadku utraty pojedynczej repliki nie można utworzyć kworum. Ponieważ wykonanie uaktualnienia usługi wymaga tymczasowego zdejmowania repliki, nie jest to przydatna konfiguracja.

Trzy węzły: z trzema węzłami (N=3), wymóg utworzenia kworum jest nadal dwoma węzłami (3/2 + 1 = 2). Oznacza to, że można utracić pojedynczy węzeł i nadal utrzymywać kworum, ale jednoczesne niepowodzenie dwóch węzłów spowoduje utratę kworum usług systemowych i spowoduje, że klaster stanie się niedostępny.

Cztery węzły: z czterema węzłami (N=4), wymóg utworzenia kworum to trzy węzły (4/2 + 1 = 3). Oznacza to, że można utracić pojedynczy węzeł i nadal utrzymywać kworum, ale jednoczesne niepowodzenie dwóch węzłów spowoduje utratę kworum usług systemowych i spowoduje, że klaster stanie się niedostępny.

Pięć węzłów: z pięcioma węzłami (N=5), wymaganie utworzenia kworum jest nadal trzy węzły (5/2 + 1 = 3). Oznacza to, że w tym samym czasie można utracić dwa węzły i nadal utrzymywać kworum dla usług systemowych.

W przypadku obciążeń produkcyjnych należy mieć odporność na jednoczesne awarie co najmniej dwóch węzłów (na przykład jeden z powodu uaktualnienia klastra ze względu na inne przyczyny), więc wymagane jest pięć węzłów.

Czy mogę wyłączyć klaster w nocy/weekendy, aby zaoszczędzić koszty?

Ogólnie rzecz biorąc, nie. Usługa Service Fabric przechowuje stan na dyskach lokalnych, efemerycznych, co oznacza, że jeśli maszyna wirtualna zostanie przeniesiona na inny host, dane nie będą się z nim przenosić. W normalnej operacji nie jest to problem, ponieważ nowy węzeł jest aktualizowany przez inne węzły. Jeśli jednak zatrzymasz wszystkie węzły i uruchomisz je ponownie później, istnieje znacząca możliwość uruchomienia większości węzłów na nowych hostach i uniemożliwienie odzyskania systemu.

Jeśli chcesz utworzyć klastry do testowania aplikacji przed jej wdrożeniem, zalecamy dynamiczne tworzenie tych klastrów w ramach potoku ciągłej integracji/ciągłego wdrażania.

Jak mogę uaktualnić system operacyjny (na przykład z systemu Windows Server 2012 do systemu Windows Server 2016)?

Obecnie pracujemy nad ulepszonym środowiskiem, ale odpowiadasz za uaktualnienie. Obraz systemu operacyjnego należy uaktualnić na maszynach wirtualnych klastra pojedynczo.

Czy mogę zaszyfrować dołączone dyski danych w typie węzła klastra (zestaw skalowania maszyn wirtualnych)?

Tak. Aby uzyskać więcej informacji, zobacz Tworzenie klastra z dołączonymi dyskami danych i usługą Azure Disk Encryption dla zestawów skalowania maszyn wirtualnych.

Czy można używać maszyn wirtualnych o niskim priorytcie w typie węzła klastra (zestaw skalowania maszyn wirtualnych)?

L.p. Maszyny wirtualne o niskim priorytcie nie są obsługiwane.

Jakie katalogi i procesy należy wykluczyć podczas uruchamiania programu antywirusowego w klastrze?

Katalogi wykluczone z oprogramowania antywirusowego
Program Files\Microsoft Service Fabric
FabricDataRoot (z konfiguracji klastra)
FabricLogRoot (z konfiguracji klastra)

Procesy wykluczone z oprogramowania antywirusowego
Fabric.exe
FabricHost.exe
FabricInstallerService.exe
FabricSetup.exe
FabricDeployer.exe
ImageBuilder.exe
FabricGateway.exe
FabricDCA.exe
FabricFAS.exe
FabricUOS.exe
FabricRM.exe
FileStoreService.exe

Jak moja aplikacja może uwierzytelniać się w usłudze Key Vault, aby uzyskać wpisy tajne?

Poniżej przedstawiono metody uzyskiwania przez aplikację poświadczeń do uwierzytelniania w usłudze Key Vault:

Odp. Podczas kompilowania/pakowania aplikacji można ściągnąć certyfikat do pakietu danych aplikacji SF i użyć go do uwierzytelniania w usłudze Key Vault. B. W przypadku hostów z obsługą tożsamości usługi zarządzanej zestawu skalowania maszyn wirtualnych można utworzyć prostą konfigurację programu PowerShellEntryPoint dla aplikacji SF, aby uzyskać token dostępu z punktu końcowego msi, a następnie pobrać wpisy tajne z usługi Key Vault.

Czy mogę przenieść moją subskrypcję do innej dzierżawy firmy Microsoft Entra?

L.p. W tej chwili należy utworzyć nowy zasób klastra usługi Service Fabric po przeniesieniu subskrypcji do innej dzierżawy usługi Microsoft Entra.

Czy mogę przenieść/zmigrować klaster między dzierżawami firmy Microsoft Entra?

L.p. W tej chwili należy utworzyć nowy zasób klastra usługi Service Fabric w ramach nowej dzierżawy.

Czy mogę przenieść/zmigrować klaster między subskrypcjami?

L.p. W tej chwili należy utworzyć nowy zasób klastra usługi Service Fabric w ramach nowej subskrypcji.

Czy mogę przenieść/zmigrować zasoby klastra lub klastra do innych grup zasobów lub zmienić ich nazwę?

L.p. W tej chwili należy utworzyć nowy zasób klastra usługi Service Fabric w obszarze nowej grupy zasobów/nazwy.

Projekt aplikacji

Jaki jest najlepszy sposób wykonywania zapytań o dane między partycjami kolekcji Reliable Collection?

Niezawodne kolekcje są zwykle partycjonowane , aby umożliwić skalowanie w poziomie w celu zwiększenia wydajności i przepływności. Oznacza to, że stan dla danej usługi może być rozłożony na dziesiątki lub setki maszyn. Aby wykonać operacje na tym pełnym zestawie danych, masz kilka opcji:

• Utwórz usługę, która wysyła zapytania do wszystkich partycji innej usługi w celu ściągnięcia wymaganych danych.
• Utwórz usługę, która może odbierać dane ze wszystkich partycji innej usługi.
• Okresowo wypychaj dane z każdej usługi do magazynu zewnętrznego. Takie podejście jest odpowiednie tylko wtedy, gdy wykonywane zapytania nie są częścią podstawowej logiki biznesowej, ponieważ dane magazynu zewnętrznego będą nieaktualne.
• Możesz też przechowywać dane, które muszą obsługiwać wykonywanie zapytań dotyczących wszystkich rekordów bezpośrednio w magazynie danych, a nie w niezawodnej kolekcji. Eliminuje to problem z nieaktualnymi danymi, ale nie pozwala na wykorzystanie zalet niezawodnych kolekcji.

Jaki jest najlepszy sposób wykonywania zapytań o dane między moimi aktorami?

Aktorzy mają być niezależnymi jednostkami stanu i obliczeń, dlatego nie zaleca się wykonywania szerokich zapytań dotyczących stanu aktora w czasie wykonywania. Jeśli musisz wykonać zapytanie w pełnym zestawie stanu aktora, rozważ jedną z następujących kwestii:

• Zastąpienie usług aktora stanowymi niezawodnymi usługami, tak aby liczba żądań sieciowych zbierała wszystkie dane z liczby aktorów do liczby partycji w usłudze.
• Projektowanie aktorów w celu okresowego wypychania ich stanu do magazynu zewnętrznego w celu łatwiejszego wykonywania zapytań. Jak powyżej, takie podejście jest możliwe tylko wtedy, gdy wykonywane zapytania nie są wymagane do zachowania środowiska uruchomieniowego.

Ile danych można przechowywać w kolekcji Reliable Collection?

Usługi niezawodne są zwykle partycjonowane, więc ilość, którą można przechowywać, jest ograniczona tylko przez liczbę maszyn w klastrze oraz ilość pamięci dostępnej na tych maszynach.

Załóżmy na przykład, że masz niezawodną kolekcję w usłudze z 100 partycjami i 3 replikami, przechowując obiekty o średnim rozmiarze 1 kb. Teraz załóżmy, że masz 10 maszynowy klaster z 16 gb pamięci na maszynę. Dla uproszczenia i być konserwatywne, załóżmy, że system operacyjny i usługi systemowe, środowisko uruchomieniowe usługi Service Fabric i usługi zużywają 6 gb tego, pozostawiając 10 gb dostępne na maszynę lub 100 GB dla klastra.

Należy pamiętać, że każdy obiekt musi być przechowywany trzy razy (jeden podstawowy i dwa repliki), wystarczająca ilość pamięci dla około 35 milionów obiektów w kolekcji podczas działania w pełnej pojemności. Zalecamy jednak odporność na jednoczesne utratę domeny awarii i domeny uaktualnienia, która reprezentuje około 1/3 pojemności, i zmniejszy liczbę do około 23 milionów.

To obliczenie zakłada również:

• Rozkład danych między partycjami jest w przybliżeniu jednolity lub raportuje metryki obciążenia do menedżera zasobów klastra. Domyślnie usługa Service Fabric ładuje równoważenie na podstawie liczby replik. W poprzednim przykładzie umieściłoby to 10 replik podstawowych i 20 replik pomocniczych w każdym węźle w klastrze. Działa to dobrze w przypadku obciążenia równomiernie rozłożonego na partycje. Jeśli obciążenie nie jest równe, musisz zgłosić obciążenie, aby usługa Resource Manager mogła spakować mniejsze repliki razem i zezwolić większym replikom na zużywanie większej ilości pamięci w pojedynczym węźle.

• Ta niezawodna usługa, o której mowa, jest jedyną usługą przechowującącą stan w klastrze. Ponieważ można wdrożyć wiele usług w klastrze, należy pamiętać o zasobach, które należy uruchomić i zarządzać jego stanem.

• Że sam klaster nie rośnie ani nie zmniejsza się. Jeśli dodasz więcej maszyn, usługa Service Fabric ponownie zrównoważy repliki, aby wykorzystać dodatkową pojemność, dopóki liczba maszyn nie przekroczy liczby partycji w usłudze, ponieważ pojedyncza replika nie może obejmować maszyn. Natomiast w przypadku zmniejszenia rozmiaru klastra przez usunięcie maszyn repliki są bardziej ciasne i mają mniej ogólnej pojemności.

Ile danych mogę przechowywać w aktorze?

Podobnie jak w przypadku niezawodnych usług, ilość danych, które można przechowywać w usłudze aktora, jest ograniczona tylko przez łączną ilość miejsca na dysku i pamięć dostępną w węzłach w klastrze. Jednak poszczególne podmioty są najbardziej skuteczne, gdy są używane do hermetyzacji niewielkiej ilości stanu i skojarzonej logiki biznesowej. Ogólnie rzecz biorąc, pojedynczy aktor powinien mieć stan mierzony w kilobajtach.

Gdzie dostawca zasobów usługi Azure Service Fabric przechowuje dane klientów?

Dostawca zasobów usługi Azure Service Fabric nie przenosi ani nie przechowuje danych klientów z regionu, w którym jest wdrażany.

Inne pytania

Jak usługa Service Fabric odnosi się do kontenerów?

Kontenery oferują prosty sposób tworzenia pakietów usług i ich zależności, tak aby działały spójnie we wszystkich środowiskach i mogą działać w sposób izolowany na jednej maszynie. Usługa Service Fabric oferuje sposób wdrażania usług i zarządzania nimi, w tym usług spakowanych w kontenerze.

Czy planujesz uruchomić usługę Service Fabric typu open source?

Mamy w usłudze Service Fabric części typu open source (struktura niezawodnych usług, struktura niezawodnych aktorów, biblioteki integracji platformy ASP.NET Core, narzędzie Service Fabric Explorer i interfejs wiersza polecenia usługi Service Fabric) w usłudze GitHub i akceptujemy współtworzenie tych projektów przez społeczność.

Niedawno ogłosiliśmy, że planujemy open source środowiska uruchomieniowego usługi Service Fabric. W tym momencie mamy repozytorium usługi Service Fabric w usłudze GitHub z narzędziami kompilacji i testowania systemu Linux, co oznacza, że można sklonować repozytorium, skompilować usługę Service Fabric dla systemu Linux, uruchomić podstawowe testy, otworzyć problemy i przesłać żądania ściągnięcia. Ciężko pracujemy nad przeprowadzeniem migracji środowiska kompilacji systemu Windows wraz z kompletnym środowiskiem ciągłej integracji.

Postępuj zgodnie z blogami usługi Service Fabric, aby uzyskać więcej szczegółowych informacji w miarę ich ogłaszania.

Następne kroki

Dowiedz się więcej o pojęciach i najlepszych rozwiązaniach dotyczących środowiska uruchomieniowego usługi Service Fabric