Wprowadzenie do menedżera zasobów klastra usługi Service Fabric

Tradycyjnie zarządzanie systemami IT lub Usługi online oznaczało przydzielanie określonych maszyn fizycznych lub wirtualnych tym konkretnym usługom lub systemom. Usługi zostały zaprojektowane jako warstwy. Warstwa "web" i warstwa "data" lub "storage". Aplikacje mają warstwę obsługi komunikatów, w której żądania przepływają i wychodzące, a także zestaw maszyn przeznaczonych do buforowania. Każda warstwa lub typ obciążenia miał dedykowane maszyny: baza danych ma kilka maszyn dedykowanych, kilka serwerów internetowych. Jeśli określony typ obciążenia spowodował, że maszyny były uruchomione zbyt gorąco, dodano więcej maszyn z tą samą konfiguracją do tej samej warstwy. Jednak nie wszystkie obciążenia można skalować w poziomie tak łatwo — szczególnie w przypadku warstwy danych, którą zwykle można zamienić na większe maszyny. Łatwe. Jeśli maszyna nie powiedzie się, ta część ogólnej aplikacji działała z niższą pojemnością do momentu przywrócenia maszyny. Nadal dość łatwe (jeśli niekoniecznie zabawne).

Teraz jednak świat usług i architektury oprogramowania uległ zmianie. Częściej aplikacje przyjmują projekt skalowalny w poziomie. Tworzenie aplikacji z kontenerami lub mikrousługami (lub obydwoma) jest powszechne. Teraz, chociaż nadal może istnieć tylko kilka maszyn, nie są one uruchomione tylko w jednym wystąpieniu obciążenia. Mogą nawet uruchamiać wiele różnych obciążeń w tym samym czasie. Masz teraz dziesiątki różnych typów usług (żadne nie zużywają pełnych zasobów maszyny), być może setki różnych wystąpień tych usług. Każde nazwane wystąpienie ma co najmniej jedno wystąpienie lub repliki na potrzeby wysokiej dostępności. W zależności od rozmiarów tych obciążeń i ich zajętości możesz znaleźć się na setkach lub tysiącach maszyn.

Nagle zarządzanie środowiskiem nie jest tak proste, jak zarządzanie kilkoma maszynami przeznaczonymi dla pojedynczych typów obciążeń. Serwery są wirtualne i nie mają już nazw (przerzuciłeś zestawy umysłów ze zwierząt domowych na bydło ). Konfiguracja jest mniej o maszynach i więcej o samych usługach. Sprzęt przeznaczony dla pojedynczego wystąpienia obciążenia jest w dużej mierze przeszłości. Same usługi stały się małymi systemami rozproszonymi, które obejmują wiele mniejszych części sprzętu towarowego.

Ponieważ twoja aplikacja nie jest już serią monolitów rozmieszczonych w kilku warstwach, masz teraz o wiele więcej kombinacji do czynienia. Kto decyduje, jakie typy obciążeń mogą być uruchamiane na jakim sprzęcie lub ile? Które obciążenia działają dobrze na tym samym sprzęcie i które konflikty? Kiedy maszyna ulegnie awarii, w jaki sposób wiesz, co tam było uruchomione na tej maszynie? Kto jest odpowiedzialny za upewnienie się, że obciążenie zostanie uruchomione ponownie? Czy czekasz, aż maszyna (wirtualna?) powróci, czy obciążenia automatycznie przejdą w tryb failover na inne maszyny i będą nadal działać? Czy wymagana jest interwencja człowieka? A co z uaktualnieniami w tym środowisku?

Jako deweloperzy i operatorzy zajmujący się tym środowiskiem chcemy pomóc w zarządzaniu tą złożonością. Zatrudnianie binge i próba ukrycia złożoności z ludźmi prawdopodobnie nie jest właściwą odpowiedzią, więc co robimy?

Wprowadzenie do orkiestratorów

"Orchestrator" to ogólny termin dotyczący oprogramowania, który pomaga administratorom zarządzać tego typu środowiskami. Orkiestratory to składniki, które przyjmują żądania, takie jak "Chciałbym pięć kopii tej usługi uruchomionej w moim środowisku". Próbują dopasować środowisko do żądanego stanu, niezależnie od tego, co się stanie.

Orkiestratorzy (a nie ludzie) podejmują działania w przypadku awarii maszyny lub przerwania obciążenia z jakiegoś nieoczekiwanego powodu. Większość orkiestratorów robi więcej niż tylko radzić sobie z awarią. Inne funkcje, które mają, to zarządzanie nowymi wdrożeniami, obsługa uaktualnień oraz obsługa zużycia zasobów i ładu. Wszystkie orkiestratory zasadniczo dotyczą utrzymania żądanego stanu konfiguracji w środowisku. Chcesz, aby móc powiedzieć orkiestratorowi, co chcesz i mieć go do podnoszenia ciężkiego. Aurora na szczycie Mesos, Docker Datacenter/Docker Swarm, Kubernetes i Service Fabric są przykładami orkiestratorów. Te orkiestratory są aktywnie opracowywane w celu zaspokojenia potrzeb rzeczywistych obciążeń w środowiskach produkcyjnych.

Orkiestracja jako usługa

Klaster Resource Manager jest składnikiem systemowym, który obsługuje aranżację w usłudze Service Fabric. Zadanie klastra Resource Manager jest podzielone na trzy części:

1. Wymuszanie reguł
2. Optymalizowanie środowiska
3. Pomoc dotycząca innych procesów

Sprawdź tę stronę wideo szkoleniowego, aby dowiedzieć się, jak działa Resource Manager klastra:

Co to nie jest

W tradycyjnych aplikacjach n-warstwowych zawsze istnieje Load Balancer. Zazwyczaj była to sieć Load Balancer (NLB) lub usługa Application Load Balancer (ALB) w zależności od tego, gdzie znajdowała się w stosie sieciowym. Niektóre moduły równoważenia obciążenia są oparte na sprzęcie, takim jak oferta BigIP firmy F5, inne są oparte na oprogramowaniu, takim jak równoważenie obciążenia sieciowego firmy Microsoft. W innych środowiskach możesz zobaczyć w tej roli coś takiego jak HAProxy, nginx, Istio lub Envoy. W tych architekturach zadaniem równoważenia obciążenia jest zapewnienie, że obciążenia bezstanowe odbierają (w przybliżeniu) taką samą ilość pracy. Strategie równoważenia obciążenia różnią się. Niektóre usługi równoważenia wysyłają każde inne wywołanie do innego serwera. Inni pod warunkiem sesji przypinanie/lepość. Bardziej zaawansowane moduły równoważenia obciążenia używają rzeczywistego szacowania obciążenia lub raportowania, aby kierować wywołanie na podstawie oczekiwanego kosztu i bieżącego obciążenia maszyny.

Usługi równoważenia sieci lub routery komunikatów próbowały upewnić się, że warstwa sieci Web/procesu roboczego pozostała w przybliżeniu zrównoważona. Strategie równoważenia warstwy danych były różne i zależały od mechanizmu przechowywania danych. Równoważenie warstwy danych polegało na fragmentowaniu danych, buforowaniu, widokach zarządzanych, procedurach składowanych i innych mechanizmach specyficznych dla magazynu.

Chociaż niektóre z tych strategii są interesujące, klaster usługi Service Fabric Resource Manager nie przypomina modułu równoważenia obciążenia sieciowego ani pamięci podręcznej. Load Balancer sieci równoważy równoważenie frontonów przez rozłożenie ruchu między frontonami. Klaster usługi Service Fabric Resource Manager ma inną strategię. Zasadniczo usługa Service Fabric przenosi usługi do miejsca, w którym mają największy sens, oczekując ruchu lub obciążenia. Może na przykład przenieść usługi do węzłów, które są obecnie zimne, ponieważ usługi, które nie wykonują dużo pracy. Węzły mogą być zimne, ponieważ usługi, które były obecne, zostały usunięte lub przeniesione gdzie indziej. W innym przykładzie klaster Resource Manager może również przenieść usługę z maszyny. Być może maszyna ma zostać uaktualniona lub jest przeciążona z powodu wzrostu zużycia przez uruchomione na nim usługi. Możesz też zwiększyć wymagania dotyczące zasobów usługi. W związku z tym na tym komputerze nie ma wystarczającej ilości zasobów, aby kontynuować jego działanie.

Ponieważ Resource Manager klastra jest odpowiedzialny za przenoszenie usług, zawiera inny zestaw funkcji w porównaniu do tego, co można znaleźć w module równoważenia obciążenia sieciowego. Wynika to z tego, że moduły równoważenia obciążenia sieciowego dostarczają ruch sieciowy do lokalizacji, w której już znajdują się usługi, nawet jeśli nie jest to idealne rozwiązanie do uruchamiania samej usługi. Klaster usługi Service Fabric Resource Manager wykorzystuje zasadniczo różne strategie zapewniające efektywne wykorzystanie zasobów w klastrze.

Następne kroki

• Aby uzyskać informacje na temat architektury i przepływu informacji w Resource Manager klastra, zapoznaj się z tym artykułem
• Resource Manager klastra ma wiele opcji opisywania klastra. Aby dowiedzieć się więcej o metrykach, zapoznaj się z tym artykułem dotyczącym opisywania klastra usługi Service Fabric
• Aby uzyskać więcej informacji na temat konfigurowania usług, dowiedz się więcej o konfigurowaniu usług
• Metryki to sposób, w jaki menedżer zasobów klastra usługi Service Fabric zarządza zużyciem i pojemnością w klastrze. Aby dowiedzieć się więcej o metrykach i sposobie ich konfigurowania, zapoznaj się z tym artykułem
• Resource Manager klastra współdziała z możliwościami zarządzania usługi Service Fabric. Aby dowiedzieć się więcej o tej integracji, przeczytaj ten artykuł
• Aby dowiedzieć się, jak klaster Resource Manager zarządza obciążeniem klastra i równoważy je w klastrze, zapoznaj się z artykułem dotyczącym równoważenia obciążenia