Planowanie i przygotowywanie wdrożenia autonomicznego klastra usługi Service Fabric
Przed utworzeniem klastra wykonaj następujące kroki.
Planowanie infrastruktury klastra
Zamierzasz utworzyć klaster usługi Service Fabric na maszynach, które jesteś właścicielem, dzięki czemu możesz zdecydować, jakiego rodzaju awarie mają przetrwać klaster. Czy na przykład potrzebujesz oddzielnych linii zasilania lub połączeń internetowych dostarczanych z tymi maszynami? Ponadto należy wziąć pod uwagę fizyczne zabezpieczenia tych maszyn. Gdzie znajdują się maszyny i kto potrzebuje do nich dostępu? Po podjęciu tych decyzji można logicznie mapować maszyny na różne domeny błędów (zobacz następny krok). Planowanie infrastruktury dla klastrów produkcyjnych jest bardziej zaangażowane niż w przypadku klastrów testowych.
Określanie liczby domen błędów i domen uaktualniania
Domena błędów (FD) jest fizyczną jednostką awarii i jest bezpośrednio związana z infrastrukturą fizyczną w centrach danych. Domena błędów składa się ze składników sprzętowych (komputerów, przełączników, sieci itp.), które współdzielą pojedynczy punkt awarii. Chociaż nie ma mapowania 1:1 między domenami błędów i stojakami, luźno mówiąc, każdy stojak może być uważany za domenę błędów.
Po określeniu identyfikatorów FD w pliku ClusterConfig.json można wybrać nazwę dla każdego FD. Usługa Service Fabric obsługuje hierarchiczne dyski FD, dzięki czemu można odzwierciedlić w nich topologię infrastruktury. Na przykład następujące identyfikatory FD są prawidłowe:
- "faultDomain": "fd:/Room1/Rack1/Machine1"
- "faultDomain": "fd:/FD1"
- "faultDomain": "fd:/Room1/Rack1/PDU1/M1"
Domena uaktualnienia (UD) jest jednostką logiczną węzłów. Podczas organizowania uaktualnień usługi Service Fabric (uaktualnienie aplikacji lub uaktualnienie klastra) wszystkie węzły w ud są usuwane w celu przeprowadzenia uaktualnienia, podczas gdy węzły w innych identyfikatorach UD pozostają dostępne do obsługi żądań. Uaktualnienia oprogramowania układowego wykonywane na maszynach nie honorują identyfikatorów UD, więc należy wykonać je pojedynczo na jednej maszynie.
Najprostszym sposobem myślenia o tych pojęciach jest rozważenie nazw FD jako jednostki nieplanowanych awarii i identyfikatorów UD jako jednostki planowanej konserwacji.
Po określeniu identyfikatorów UD w pliku ClusterConfig.json można wybrać nazwę dla każdej trasy zdefiniowanej przez użytkownika. Na przykład następujące nazwy są prawidłowe:
- "upgradeDomain": "UD0"
- "upgradeDomain": "UD1A"
- "upgradeDomain": "DomainRed"
- "upgradeDomain": "Blue"
Aby uzyskać bardziej szczegółowe informacje na temat identyfikatorów FD i identyfikatorów UD, zobacz Opis klastra usługi Service Fabric.
Klaster w środowisku produkcyjnym powinien obejmować co najmniej trzy dyski FD w celu zapewnienia obsługi w środowisku produkcyjnym, jeśli masz pełną kontrolę nad konserwacją i zarządzaniem węzłami, czyli odpowiadasz za aktualizowanie i zastępowanie maszyn. W przypadku klastrów działających w środowiskach (czyli wystąpieniach maszyn wirtualnych usługi Amazon Web Services), w których nie masz pełnej kontroli nad maszynami, w klastrze powinno istnieć co najmniej pięć dysków FD. Każdy identyfikator FD może mieć co najmniej jeden węzeł. Zapobiega to problemom spowodowanym uaktualnieniami i aktualizacjami maszyn, które w zależności od ich czasu mogą zakłócać działanie aplikacji i usług w klastrach.
Określanie początkowego rozmiaru klastra
Ogólnie rzecz biorąc, liczba węzłów w klastrze jest określana na podstawie potrzeb biznesowych, czyli liczby usług i kontenerów uruchomionych w klastrze oraz liczby zasobów potrzebnych do utrzymania obciążeń. W przypadku klastrów produkcyjnych zalecamy posiadanie co najmniej pięciu węzłów w klastrze obejmujących 5 dysków FD. Jednak zgodnie z powyższym opisem, jeśli masz pełną kontrolę nad węzłami i może obejmować trzy dyski FD, trzy węzły powinny również wykonać zadanie.
Klastry testowe z obciążeniami stanowymi powinny mieć trzy węzły, natomiast klastry testowe z uruchomionymi obciążeniami bezstanowymi potrzebują tylko jednego węzła. Należy również zauważyć, że w celach programistycznych można mieć więcej niż jeden węzeł na danym komputerze. Jednak w środowisku produkcyjnym usługa Service Fabric obsługuje tylko jeden węzeł na maszynę fizyczną lub wirtualną.
Przygotowywanie maszyn, które będą pełnić rolę węzłów
Poniżej przedstawiono zalecane specyfikacje maszyn w klastrze usługi Service Fabric:
- Co najmniej 16 GB pamięci RAM
- Co najmniej 40 GB dostępnego miejsca na dysku
- 4-rdzeniowy lub większy procesor
- Połączenie ivity do bezpiecznej sieci lub sieci dla wszystkich maszyn
- Zainstalowany system operacyjny Windows Server (prawidłowe wersje: 2012 R2, 2016, 1709 lub 1803). Usługa Service Fabric w wersji 6.4.654.9590 lub nowszej obsługuje również programy Server 2019 i 1809.
- Pełna instalacja programu .NET Framework 4.5.1 lub nowszego
- Windows PowerShell 3.0
- Usługa RemoteRegistry powinna być uruchomiona na wszystkich maszynach
- Dysk instalacyjny usługi Service Fabric musi być systemem plików NTFS
- Należy włączyć dzienniki wydajności i alerty usług systemu Windows oraz dziennik zdarzeń systemu Windows.
- Zdalne sterowanie kontem użytkownika musi być wyłączone
Ważne
Administrator klastra wdrażający i konfigurując klaster musi mieć uprawnienia administratora na każdej maszynie. Usługi Service Fabric nie można zainstalować na kontrolerze domeny.
Pobieranie autonomicznego pakietu usługi Service Fabric dla systemu Windows Server
Pobierz link — pakiet autonomiczny usługi Service Fabric — system Windows Server i rozpakuj pakiet do maszyny wdrożeniowej, która nie jest częścią klastra, lub do jednego z maszyn, które będą częścią klastra.
Modyfikowanie konfiguracji klastra
Aby utworzyć klaster autonomiczny, należy utworzyć autonomiczny plik ClusterConfig.json konfiguracji klastra, który opisuje specyfikację klastra. Plik konfiguracji można utworzyć na podstawie szablonów znajdujących się pod poniższym linkiem.
Konfiguracje klastra autonomicznego
Aby uzyskać szczegółowe informacje na temat sekcji w tym pliku, zobacz Ustawienia konfiguracji dla autonomicznego klastra systemu Windows.
Otwórz jeden z plików ClusterConfig.json z pobranego pakietu i zmodyfikuj następujące ustawienia:
| Ustawienie konfiguracji | Opis |
|---|---|
| NodeTypes | Typy węzłów umożliwiają rozdzielenie węzłów klastra na różne grupy. Klaster musi mieć co najmniej jeden typ węzła. Wszystkie węzły w grupie mają następujące typowe cechy: Nazwa — jest to nazwa typu węzła. Porty punktu końcowego — są to punkty końcowe (porty) skojarzone z tym typem węzła. Możesz użyć dowolnego numeru portu, o ile nie powodują one konfliktu z niczym innym w tym manifeście i nie są jeszcze używane przez żadną inną aplikację uruchomioną na maszynie/maszynie wirtualnej. Właściwości umieszczania — te właściwości opisują właściwości tego typu węzła, które są używane jako ograniczenia umieszczania dla usług systemowych lub usług. Te właściwości to pary klucz/wartość zdefiniowane przez użytkownika, które zapewniają dodatkowe metadane dla danego węzła. Przykładem właściwości węzła jest to, czy węzeł ma dysk twardy lub kartę graficzną, liczbę wrzecion w dysku twardym, rdzeniach i innych właściwościach fizycznych. Pojemności — pojemności węzłów definiują nazwę i ilość określonego zasobu dostępnego do użycia przez określony węzeł. Na przykład węzeł może zdefiniować, że ma pojemność dla metryki o nazwie "MemoryInMb" i że ma domyślnie dostępne 2048 MB. Te pojemności są używane w czasie wykonywania, aby zapewnić, że usługi, które wymagają określonych ilości zasobów, są umieszczane w węzłach, które mają te zasoby dostępne w wymaganych ilościach. IsPrimary — jeśli zdefiniowano więcej niż jeden typ węzła, upewnij się, że tylko jeden z nich jest ustawiony na wartość podstawową z wartością true, która jest miejscem uruchamiania usług systemowych. Wszystkie inne typy węzłów powinny być ustawione na wartość false |
| Węzły | Są to szczegóły poszczególnych węzłów, które są częścią klastra (typ węzła, nazwa węzła, adres IP, domena błędów i domena uaktualnienia węzła). Maszyny, na których chcesz utworzyć klaster, muszą być wymienione tutaj z ich adresami IP. Jeśli używasz tego samego adresu IP dla wszystkich węzłów, zostanie utworzony klaster jedno box, którego można użyć do celów testowych. Nie należy używać klastrów jedno box do wdrażania obciążeń produkcyjnych. |
Po skonfigurowaniu wszystkich ustawień klastra w środowisku można je przetestować w środowisku klastra (krok 7).
Konfigurowanie środowiska
Gdy administrator klastra konfiguruje autonomiczny klaster usługi Service Fabric, środowisko musi zostać skonfigurowane przy użyciu następujących kryteriów:
Użytkownik tworzący klaster powinien mieć uprawnienia zabezpieczeń na poziomie administratora do wszystkich maszyn wymienionych jako węzły w pliku konfiguracji klastra.
Maszyna, z której jest tworzony klaster, a także każda maszyna węzła klastra musi:
- Odinstalowywanie zestawu SDK usługi Service Fabric
- Odinstalowywanie środowiska uruchomieniowego usługi Service Fabric
- Włączanie usługi Zapory systemu Windows (mpssvc)
- Włączenie usługi rejestru zdalnego (rejestru zdalnego)
- Włączanie udostępniania plików (SMB)
- Otwieranie niezbędnych portów na podstawie portów konfiguracji klastra
- Mają otwarte niezbędne porty dla usługi Windows SMB i rejestru zdalnego: 135, 137, 138, 139 i 445
- Łączność sieciowa ze sobą
Żaden z maszyn węzłów klastra nie powinien być kontrolerem domeny.
Jeśli klaster, który ma zostać wdrożony, jest bezpiecznym klastrem, sprawdź, czy zostały spełnione niezbędne wymagania wstępne dotyczące zabezpieczeń i zostały prawidłowo skonfigurowane pod kątem konfiguracji.
Jeśli maszyny klastra nie są dostępne w Internecie, ustaw następujące ustawienia w konfiguracji klastra:
- Wyłącz telemetrię: w obszarze właściwości ustawiono wartość "enableTelemetry": false
- Wyłącz automatyczne pobieranie wersji sieci szkieletowej i powiadomienia, że bieżąca wersja klastra zbliża się do końca wsparcia: w obszarze właściwości ustawiono wartość "fabricClusterAutoupgradeEnabled": false
- Alternatywnie, jeśli dostęp do Internetu w sieci jest ograniczony do dozwolonych domen, poniższe domeny są wymagane do automatycznego uaktualniania: go.microsoft.com download.microsoft.com
Ustaw odpowiednie wykluczenia programu antywirusowego usługi Service Fabric:
| 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 |
Weryfikowanie środowiska przy użyciu skryptu TestConfiguration
Skrypt TestConfiguration.ps1 można znaleźć w pakiecie autonomicznym. Jest on używany jako analizator najlepszych rozwiązań do sprawdzania poprawności niektórych powyższych kryteriów i powinien być używany jako sprawdzanie kondycji w celu sprawdzenia, czy klaster można wdrożyć w danym środowisku. Jeśli wystąpi jakikolwiek błąd, zapoznaj się z listą w obszarze Konfiguracja środowiska, aby uzyskać informacje na temat rozwiązywania problemów.
Ten skrypt można uruchomić na dowolnej maszynie, która ma dostęp administratora do wszystkich maszyn wymienionych jako węzły w pliku konfiguracji klastra. Maszyna, na którą jest uruchamiany ten skrypt, nie musi być częścią klastra.
PS C:\temp\Microsoft.Azure.ServiceFabric.WindowsServer> .\TestConfiguration.ps1 -ClusterConfigFilePath .\ClusterConfig.Unsecure.DevCluster.json
Trace folder already exists. Traces will be written to existing trace folder: C:\temp\Microsoft.Azure.ServiceFabric.WindowsServer\DeploymentTraces
Running Best Practices Analyzer...
Best Practices Analyzer completed successfully.
LocalAdminPrivilege : True
IsJsonValid : True
IsCabValid : True
RequiredPortsOpen : True
RemoteRegistryAvailable : True
FirewallAvailable : True
RpcCheckPassed : True
NoConflictingInstallations : True
FabricInstallable : True
Passed : True
Obecnie ten moduł testowania konfiguracji nie weryfikuje konfiguracji zabezpieczeń, dlatego należy to zrobić niezależnie.
Uwaga
Nieustannie wprowadzamy ulepszenia, aby ten moduł był bardziej niezawodny, więc jeśli występuje błąd lub brakuje przypadku, który nie jest obecnie przechwycony przez narzędzie TestConfiguration, daj nam znać za pośrednictwem naszych kanałów pomocy technicznej.
Następne kroki
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla