Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Tradycyjnie zarządzanie systemami IT lub usługami online oznaczało przydzielanie określonych maszyn fizycznych lub wirtualnych tym konkretnym usługom lub systemom. Usługi zostały zaprojektowane w postaci warstw. Istnieje warstwa „web” oraz warstwa „danych” lub „magazynowania”. 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ł określone maszyny dedykowane: baza danych ma kilka maszyn dedykowanych, serwery internetowe kilka. Jeśli określony typ obciążenia spowodował, że maszyny, na których działał, pracowały w zbyt wysokiej temperaturze, dodawano więcej maszyn z tą samą konfiguracją do tej samej warstwy. Jednak nie wszystkie obciążenia mogą być rozszerzane tak łatwo — szczególnie w przypadku warstwy danych zwykle zastępuje się maszyny większymi maszynami. Łatwy. Jeśli maszyna nie powiodła 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 zabawa).
Teraz jednak świat usług i architektury oprogramowania uległ zmianie. Coraz częściej aplikacje przyjmują projekt skalowania poziomego. Tworzenie aplikacji z kontenerami lub mikrousługami (lub obie) jest typowe. Teraz, mimo że nadal masz tylko kilka maszyn, nie są uruchomione tylko pojedyncze wystąpienie obciążenia. Mogą nawet uruchamiać wiele różnorodnych obciążeń w tym samym czasie. Masz teraz dziesiątki różnych typów usług (żadna z nich nie wykorzystuje pełnych zasobów maszyny), a być może setki różnych wystąpień tych usług. Każde nazwane wystąpienie ma jedno lub więcej wystąpień lub replik na potrzeby zapewnienia wysokiej dostępności. W zależności od rozmiarów tych obciążeń i tego, jak bardzo są zajęte, możesz mieć setki lub tysiące maszyn.
Nagle zarządzanie środowiskiem nie jest tak proste, jak zarządzanie kilkoma maszynami dedykowanymi dla pojedynczych typów obciążeń. Serwery są wirtualne i nie mają już nazw (przerzuciłeś umysły ze zwierząt domowych na bydło po wszystkim). Konfiguracja dotyczy mniej maszyn, a bardziej samych usług. Sprzęt przeznaczony dla pojedynczego wystąpienia obciążenia w dużej mierze należy już do przeszłości. Same usługi stały się małymi systemami rozproszonymi, które obejmują wiele mniejszych elementów sprzętu towarowego.
Ponieważ twoja aplikacja nie jest już serią monolitów rozmieszczonych w kilku warstwach, masz teraz o wiele więcej kombinacji do obsługi. Kto decyduje, jakie typy obciążeń mogą być uruchamiane na jakim sprzęcie lub ile? Które obciążenia robocze działają dobrze na tym samym sprzęcie, a które konfliktują? Kiedy maszyna ulegnie awarii, w jaki sposób wiesz, co było uruchomione na tej maszynie? Kto jest odpowiedzialny za upewnienie się, że obciążenie zostanie uruchomione ponownie? Czy czekasz, aż maszyna (wirtualna?) wróci, czy Twoje obciążenia automatycznie przełączają się na inne maszyny i nadal działają? Czy wymagana jest interwencja człowieka? Co z uaktualnieniami w tym środowisku?
Jako deweloperzy i operatorzy działający w tym środowisku, będziemy potrzebowali pomocy w zarządzaniu tą złożonością. Szał zatrudniania i próba ukrycia złożoności poprzez zatrudnianie ludzi prawdopodobnie nie jest właściwą odpowiedzią, więc co powinniśmy zrobić?
Wprowadzenie do orkiestratorów
"Orchestrator" to ogólny termin dla 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ą dostosować środowisko do żądanego stanu, niezależnie od tego, co się stanie.
To orkiestratory, 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 zajmować się awarią. Inne funkcje, które posiadają, to zarządzanie nowymi wdrożeniami, obsługa uaktualnień oraz zajmowanie się zużyciem zasobów i ładem. Wszystkie orkiestratory zasadniczo służą do utrzymania żądanego stanu konfiguracji środowiska. Chcesz móc powiedzieć orkiestratorowi, co chcesz, i zlecić mu wykonanie ciężkiej pracy. Aurora na szczycie Mesos, Docker Datacenter/Docker Swarm, Kubernetes i Service Fabric to przykłady orkiestratorów. Te orkiestratory są aktywnie opracowywane w celu zaspokojenia potrzeb rzeczywistych obciążeń w środowiskach produkcyjnych.
Orkiestracja jako usługa
Menedżer zasobów klastra to składnik systemowy, który obsługuje koordynację w ramach usługi Service Fabric. Zadanie Resource Manager klastra jest podzielone na trzy części:
- Wymuszanie reguł
- Optymalizowanie środowiska
- Pomoc dotycząca innych procesów
Co to nie jest
W tradycyjnych aplikacjach n-warstwowych zawsze istnieje moduł równoważenia obciążenia. Zazwyczaj był to moduł równoważenia obciążenia sieciowego (NLB) lub moduł równoważenia obciążenia aplikacji (ALB) w zależności od tego, gdzie znajdował się w stosie sieciowym. Niektóre systemy równoważenia obciążenia opierają się na sprzęcie, jak w przypadku BigIP oferowanego przez firmę F5, inne na oprogramowaniu, na przykład na NLB 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 otrzymują (mniej więcej) taką samą ilość pracy. Strategie równoważenia obciążenia różnią się. Niektóre moduły równoważenia wysyłają każde inne wywołanie do innego serwera. Inni zapewniali utrzymanie sesji lub jej przywiązanie. Bardziej zaawansowane moduły równoważenia obciążenia wykorzystują szacowanie rzeczywistego obciążenia lub raportowanie, aby kierować wywołanie na podstawie oczekiwanego kosztu i bieżącego obciążenia maszyny.
Równoważniki sieci lub routery komunikatów próbowały upewnić się, że warstwa web/pracowników pozostała odpowiednio 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, zarządzaniu widokami, procedurach składowanych i innych mechanizmach specyficznych dla konkretnego magazynu.
Chociaż niektóre z tych strategii są interesujące, menedżer zasobów klastra usługi Service Fabric nie jest równoważnikiem obciążenia sieci ani pamięcią podręczną. Moduł równoważenia obciążenia sieciowego równoważy frontony przez rozłożenie ruchu między frontonami. Menedżer zasobów klastra usługi Service Fabric ma inną strategię. Zasadniczo usługa Service Fabric przenosi usługi do miejsca, w którym mają największe znaczenie, 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 tam nie pracują zbytnio. Węzły mogą być zimne, ponieważ usługi, które były obecne, zostały usunięte lub przeniesione w inne miejsce. W innym przykładzie menedżer zasobów klastra może również przenieść usługę z dala od maszyny. Być może maszyna ma zostać uaktualniona lub jest przeciążona z powodu wzrostu zużycia przez uruchomione na nim usługi. Alternatywnie mogą zostać zwiększone 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ż menedżer zasobów 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. Dzieje się tak, ponieważ moduły równoważenia obciążenia sieciowego dostarczają ruch sieciowy do lokalizacji, w której już znajdują się usługi, nawet jeśli ta lokalizacja nie jest idealna do uruchamiania samej usługi. Menedżer zasobów klastra usługi Service Fabric stosuje 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 usłudze Resource Manager klastra, zapoznaj się z tym artykułem
- Menedżer zasobów klastra ma wiele opcji opisywania klastra. Aby dowiedzieć się więcej na temat metryk, 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
- Menedżer zasobów klastra współpracuje z możliwościami zarządzania usługi Service Fabric. Aby dowiedzieć się więcej na temat tej integracji, przeczytaj ten artykuł
- Aby dowiedzieć się, jak menedżer zasobów klastra zarządza obciążeniem klastra i równoważy obciążenie w klastrze, zapoznaj się z artykułem dotyczącym równoważenia obciążenia