Planowanie pojemności dla aplikacji usługi Service Fabric
W tym dokumencie pokazano, jak oszacować ilość zasobów (procesory CPU, pamięć RAM, magazyn dysku) potrzebne do uruchamiania aplikacji usługi Azure Service Fabric. Często wymagania dotyczące zasobów zmieniają się w czasie. Zwykle potrzebujesz kilku zasobów podczas opracowywania/testowania usługi, a następnie wymagają większej ilości zasobów w miarę przechodzenia do środowiska produkcyjnego, a aplikacja rośnie popularność. Podczas projektowania aplikacji należy zastanowić się nad długoterminowymi wymaganiami i dokonać wyborów, które umożliwiają skalowanie usługi w celu spełnienia wysokiego zapotrzebowania klientów.
Podczas tworzenia klastra usługi Service Fabric decydujesz, jakie rodzaje maszyn wirtualnych tworzą klaster. Każda maszyna wirtualna ma ograniczoną ilość zasobów w postaci procesorów CPU (rdzeni i szybkości), przepustowości sieci, pamięci RAM i magazynu dyskowego. W miarę upływu czasu możesz uaktualnić usługę do maszyn wirtualnych, które oferują większe zasoby i/lub dodać więcej maszyn wirtualnych do klastra. Aby to zrobić, należy początkowo utworzyć architekturę usługi, aby móc korzystać z nowych maszyn wirtualnych, które są dynamicznie dodawane do klastra.
Niektóre usługi nie zarządzają niewielkimi danymi na samych maszynach wirtualnych. W związku z tym planowanie pojemności dla tych usług powinno skupić się przede wszystkim na wydajności, co oznacza wybranie odpowiednich procesorów CPU (rdzeni i szybkości) maszyn wirtualnych. Ponadto należy rozważyć przepustowość sieci, w tym częstotliwość transferów sieci i ilość przesyłanych danych. Jeśli usługa musi działać, a użycie usługi zwiększa się, możesz dodać więcej maszyn wirtualnych do klastra i zrównoważyć obciążenie żądań sieciowych na wszystkich maszynach wirtualnych.
W przypadku usług, które zarządzają dużymi ilościami danych na maszynach wirtualnych, planowanie pojemności powinno skupić się przede wszystkim na rozmiarze. W związku z tym należy dokładnie rozważyć pojemność pamięci RAM i magazynu dyskowego maszyny wirtualnej. System zarządzania pamięcią wirtualną w systemie Windows sprawia, że miejsce na dysku wygląda jak pamięć RAM do kodu aplikacji. Ponadto środowisko uruchomieniowe usługi Service Fabric zapewnia inteligentne stronicowanie, które zachowuje tylko gorące dane w pamięci i przenosi zimne dane na dysk. W związku z tym aplikacje mogą używać większej ilości pamięci niż jest fizycznie dostępna na maszynie wirtualnej. Posiadanie większej ilości pamięci RAM po prostu zwiększa wydajność, ponieważ maszyna wirtualna może zachować więcej miejsca do magazynowania na dysku w pamięci RAM. Wybrana maszyna wirtualna powinna mieć dysk wystarczająco duży, aby przechowywać dane, które mają być przechowywane na maszynie wirtualnej. Podobnie maszyna wirtualna powinna mieć wystarczającą ilość pamięci RAM, aby zapewnić odpowiednią wydajność. Jeśli dane usługi rosną wraz z upływem czasu, możesz dodać więcej maszyn wirtualnych do klastra i podzielić dane na wszystkie maszyny wirtualne.
Określanie liczby potrzebnych węzłów
Partycjonowanie usługi umożliwia skalowanie danych usługi w poziomie. Aby uzyskać więcej informacji na temat partycjonowania, zobacz Partycjonowanie usługi Service Fabric. Każda partycja musi mieścić się w jednej maszynie wirtualnej, ale na jednej maszynie wirtualnej można umieścić wiele (małych) partycji. Dlatego posiadanie większej liczby małych partycji zapewnia większą elastyczność niż posiadanie kilku większych partycji. Kompromis polega na tym, że posiadanie dużej liczby partycji zwiększa obciążenie usługi Service Fabric i nie można wykonywać operacji transakcyjnych między partycjami. Istnieje również większy potencjalny ruch sieciowy, jeśli kod usługi często musi uzyskiwać dostęp do fragmentów danych, które znajdują się w różnych partycjach. Podczas projektowania usługi należy dokładnie rozważyć te zalety i wady, aby uzyskać efektywną strategię partycjonowania.
Załóżmy, że aplikacja ma jedną usługę stanową, która ma rozmiar sklepu, który ma wzrosnąć do DB_Size GB w ciągu roku. Chcesz dodać więcej aplikacji (i partycji) w miarę wzrostu w tym roku. Współczynnik replikacji (RF), który określa liczbę replik dla usługi, ma wpływ na łączną DB_Size. Łączna DB_Size we wszystkich replikach to współczynnik replikacji pomnożony przez DB_Size. Node_Size reprezentuje miejsce na dysku/pamięć RAM na węzeł, którego chcesz użyć dla usługi. Aby uzyskać najlepszą wydajność, DB_Size powinny mieścić się w pamięci w klastrze, a Node_Size wokół pamięci RAM maszyny wirtualnej należy wybrać. Przydzielając Node_Size, która jest większa niż pojemność pamięci RAM, polegasz na stronicowaniu udostępnianym przez środowisko uruchomieniowe usługi Service Fabric. W związku z tym wydajność może nie być optymalna, jeśli całe dane są uważane za gorące (od tego czasu dane są stronicowane w/wy). Jednak w przypadku wielu usług, w których tylko część danych jest gorąca, jest bardziej opłacalna.
Liczbę węzłów wymaganych do maksymalnej wydajności można obliczyć w następujący sposób:
Number of Nodes = (DB_Size * RF)/Node_Size
Konto wzrostu
Możesz chcieć obliczyć liczbę węzłów na podstawie DB_Size, do której oczekujesz, że usługa wzrośnie, oprócz DB_Size, od którego rozpoczęto. Następnie zwiększ liczbę węzłów w miarę zwiększania się usługi, aby nie aprowizować zbyt wielu węzłów. Jednak liczba partycji powinna być oparta na liczbie węzłów, które są potrzebne podczas uruchamiania usługi przy maksymalnym wzroście.
Dobrze jest mieć w dowolnym momencie dostępne dodatkowe maszyny, dzięki czemu można obsłużyć wszelkie nieoczekiwane skoki lub awarie (na przykład jeśli kilka maszyn wirtualnych spadnie). Chociaż dodatkowa pojemność powinna być określana przy użyciu oczekiwanych skoków, punktem wyjścia jest zarezerwowanie kilku dodatkowych maszyn wirtualnych (dodatkowe 5–10 procent).
Powyższe założenie zakłada pojedynczą usługę stanową. Jeśli masz więcej niż jedną usługę stanową, musisz dodać DB_Size skojarzone z innymi usługami w równaniu. Alternatywnie można obliczyć liczbę węzłów oddzielnie dla każdej usługi stanowej. Usługa może mieć repliki lub partycje, które nie są zrównoważone. Należy pamiętać, że partycje mogą również mieć więcej danych niż inne. Aby uzyskać więcej informacji na temat partycjonowania, zobacz artykuł dotyczący partycjonowania na temat najlepszych rozwiązań. Jednak poprzednie równanie jest niezależne od partycji i repliki, ponieważ usługa Service Fabric zapewnia, że repliki są rozłożone między węzły w zoptymalizowany sposób.
Używanie arkusza kalkulacyjnego do obliczania kosztów
Teraz umieśćmy kilka rzeczywistych liczb w formule. Przykładowy arkusz kalkulacyjny przedstawia sposób planowania pojemności aplikacji zawierającej trzy typy obiektów danych. Dla każdego obiektu przybliżamy jego rozmiar i liczbę obiektów, których oczekujemy. Wybieramy również liczbę replik każdego typu obiektu. Arkusz kalkulacyjny oblicza łączną ilość pamięci, która ma być przechowywana w klastrze.
Następnie wprowadzamy rozmiar maszyny wirtualnej i miesięczny koszt. Na podstawie rozmiaru maszyny wirtualnej arkusz kalkulacyjny informuje o minimalnej liczbie partycji, których należy użyć do podzielenia danych w celu fizycznego dopasowania ich do węzłów. Możesz potrzebować większej liczby partycji, aby uwzględnić określone wymagania aplikacji dotyczące obliczeń i ruchu sieciowego. W arkuszu kalkulacyjnym przedstawiono liczbę partycji, które zarządzają obiektami profilu użytkownika, wzrosła z jednego do sześciu.
Teraz, na podstawie wszystkich tych informacji, arkusz kalkulacyjny pokazuje, że można fizycznie pobrać wszystkie dane z żądanymi partycjami i replikami w klastrze 26 węzłów. Jednak ten klaster będzie gęsto zapakowany, więc może być konieczne, aby niektóre dodatkowe węzły uwzględniały awarie węzłów i uaktualnienia. Arkusz kalkulacyjny pokazuje również, że posiadanie więcej niż 57 węzłów nie zapewnia dodatkowej wartości, ponieważ masz puste węzły. Ponownie możesz mimo to przejść powyżej 57 węzłów, aby uwzględnić błędy węzłów i uaktualnienia. Arkusz kalkulacyjny można dostosować tak, aby odpowiadał konkretnym potrzebom aplikacji.
Następne kroki
Zapoznaj się z tematem Partycjonowanie usług Service Fabric, aby dowiedzieć się więcej na temat partycjonowania usługi.