Udostępnij za pośrednictwem


Planowanie i przygotowywanie wdrożenia klastra

Planowanie i przygotowywanie wdrożenia klastra produkcyjnego jest bardzo ważne. Należy wziąć pod uwagę wiele czynników. W tym artykule przedstawiono kroki przygotowywania wdrożenia klastra.

Przeczytaj informacje o najlepszych rozwiązaniach

Aby pomyślnie zarządzać aplikacjami i klastrami usługi Azure Service Fabric, zdecydowanie zalecamy wykonanie operacji w celu zoptymalizowania niezawodności środowiska produkcyjnego. Aby uzyskać więcej informacji, przeczytaj Artykuł Service Fabric application and cluster best practices (Najlepsze rozwiązania dotyczące aplikacji usługi Service Fabric i klastra).

Wybierz system operacyjny dla klastra

Usługa Service Fabric umożliwia tworzenie klastrów usługi Service Fabric na dowolnych maszynach wirtualnych lub komputerach z systemem Windows Server lub Linux. Przed wdrożeniem klastra należy wybrać system operacyjny: Windows lub Linux. Każdy węzeł (maszyna wirtualna) w klastrze działa w tym samym systemie operacyjnym, nie można mieszać maszyn wirtualnych z systemami Windows i Linux w tym samym klastrze.

Planowanie zdolności produkcyjnych

W przypadku wszystkich wdrożeń produkcyjnych planowanie pojemności jest ważnym krokiem. Poniżej przedstawiono niektóre zagadnienia, które należy uwzględnić w ramach tego procesu.

  • Początkowa liczba typów węzłów dla klastra
  • Właściwości każdego typu węzła (rozmiar, liczba wystąpień, podstawowy, dostępny z Internetu, liczba maszyn wirtualnych itp.)
  • Charakterystyka niezawodności i trwałości klastra

Wybierz początkową liczbę typów węzłów

Najpierw należy dowiedzieć się, do czego będzie używany tworzony klaster. Jakiego rodzaju aplikacje planujesz wdrożyć w tym klastrze? Czy aplikacja ma wiele usług i czy każda z nich musi być publiczna lub internetowa? Czy usługi (które tworzą aplikację) mają różne potrzeby dotyczące infrastruktury, takie jak większe cykle pamięci RAM lub wyższe procesory CPU? Klaster usługi Service Fabric może składać się z więcej niż jednego typu węzła: typu węzła podstawowego i co najmniej jednego typu węzła innego niż podstawowy. Każdy typ węzła jest mapowany na zestaw skalowania maszyn wirtualnych. Następnie każdy typ węzła może być niezależnie skalowany w górę lub w dół oraz może mieć różne zestawy otwartych portów i różne metryki pojemności. Właściwości węzła i ograniczenia umieszczania można skonfigurować tak, aby ograniczyć określone usługi do określonych typów węzłów. Aby uzyskać więcej informacji, zobacz Planowanie pojemności klastra usługi Service Fabric.

Wybieranie właściwości węzła dla każdego typu węzła

Typy węzłów definiują jednostkę SKU, liczbę i właściwości maszyn wirtualnych w skojarzonym zestawie skalowania.

Minimalny rozmiar maszyn wirtualnych dla każdego typu węzła zależy od warstwy trwałości wybranej dla typu węzła. Przed wybraniem jednostki SKU maszyny wirtualnej upewnij się, że znasz kroki wymagane do skalowania w pionie , jeśli zdecydujesz, że w przyszłości potrzebujesz innej jednostki SKU maszyny wirtualnej.

Minimalna liczba maszyn wirtualnych dla typu węzła podstawowego jest określana przez wybraną warstwę niezawodności.

Zapoznaj się z minimalnymi zaleceniami dotyczącymi typów węzłów podstawowych, obciążeń stanowych w typach węzłów innych niż podstawowe oraz bezstanowych obciążeń w typach węzłów innych niż podstawowe.

Każda więcej niż minimalna liczba węzłów powinna być oparta na liczbie replik aplikacji/usług, które mają być uruchamiane w tym węźle. Planowanie pojemności aplikacji usługi Service Fabric ułatwia oszacowanie zasobów potrzebnych do uruchamiania aplikacji. Zawsze można skalować klaster w górę lub w dół później, aby dostosować się do zmiany obciążenia aplikacji.

Używanie efemerycznych dysków systemu operacyjnego dla zestawów skalowania maszyn wirtualnych

Efemeryczne dyski systemu operacyjnego są magazynem tworzonym na lokalnej maszynie wirtualnej i nie są zapisywane w zdalnej usłudze Azure Storage. Są one zalecane dla wszystkich typów węzłów usługi Service Fabric (podstawowy i pomocniczy), ponieważ w porównaniu z tradycyjnymi trwałymi dyskami systemu operacyjnego, efemerycznych dysków systemu operacyjnego:

  • Zmniejszanie opóźnienia odczytu/zapisu na dysku systemu operacyjnego
  • Włączanie szybszych operacji resetowania/zarządzania węzłami reimage
  • Obniżanie ogólnych kosztów (dyski są bezpłatne i nie generują dodatkowych kosztów magazynowania)

Efemeryczne dyski systemu operacyjnego nie są określoną funkcją usługi Service Fabric, ale raczej funkcją zestawów skalowania maszyn wirtualnych platformy Azure mapowanych na typy węzłów usługi Service Fabric. Użycie ich z usługą Service Fabric wymaga następujących elementów w szablonie usługi Azure Resource Manager klastra:

  1. Upewnij się, że typy węzłów określają obsługiwane rozmiary maszyn wirtualnych platformy Azure dla efemerycznych dysków systemu operacyjnego i że rozmiar maszyny wirtualnej ma wystarczający rozmiar pamięci podręcznej do obsługi rozmiaru dysku systemu operacyjnego (zobacz uwaga poniżej). Na przykład:

    "vmNodeType1Size": {
        "type": "string",
        "defaultValue": "Standard_DS3_v2"
    

    Uwaga

    Pamiętaj, aby wybrać rozmiar maszyny wirtualnej o rozmiarze pamięci podręcznej równym lub większym niż rozmiar dysku systemu operacyjnego samej maszyny wirtualnej. W przeciwnym razie wdrożenie platformy Azure może spowodować błąd (nawet jeśli początkowo zostanie zaakceptowany).

  2. Określ wersję zestawu skalowania maszyn wirtualnych (vmssApiVersion) lub nowszą 2018-06-01 :

    "variables": {
        "vmssApiVersion": "2018-06-01",
    
  3. W sekcji zestaw skalowania maszyn wirtualnych szablonu wdrożenia określ Local opcję :diffDiskSettings

    "apiVersion": "[variables('vmssApiVersion')]",
    "type": "Microsoft.Compute/virtualMachineScaleSets",
        "virtualMachineProfile": {
            "storageProfile": {
                "osDisk": {
                        "caching": "ReadOnly",
                        "createOption": "FromImage",
                        "diffDiskSettings": {
                            "option": "Local"
                        },
                }
            }
        }
    

Uwaga

Aplikacje użytkownika nie powinny mieć żadnych zależności/plików/artefaktów na dysku systemu operacyjnego, ponieważ dysk systemu operacyjnego zostanie utracony w przypadku uaktualnienia systemu operacyjnego.

Uwaga

Nie można uaktualnić istniejącego efemerycznego zestawu skalowania maszyn wirtualnych w miejscu w celu używania dysków efemerycznych. Aby przeprowadzić migrację, użytkownicy będą musieli dodać nowy typ węzła z dyskami efemeracyjnymi, przenieść obciążenia do nowego nodeType i usunąć istniejący typ węzła.

Aby uzyskać więcej informacji i dalsze opcje konfiguracji, zobacz Efemeryczny dysk systemu operacyjnego dla maszyn wirtualnych platformy Azure

Wybieranie poziomów trwałości i niezawodności klastra

Warstwa trwałości służy do wskazywania systemowi uprawnień maszyn wirtualnych z podstawową infrastrukturą platformy Azure. W podstawowym typie węzła to uprawnienie umożliwia usłudze Service Fabric wstrzymanie dowolnego żądania infrastruktury na poziomie maszyny wirtualnej (na przykład ponowne uruchomienie maszyny wirtualnej, przywracanie obrazu maszyny wirtualnej lub migracja maszyny wirtualnej), które mają wpływ na wymagania kworum dla usług systemowych i usług stanowych. W typach węzłów innych niż podstawowe to uprawnienie umożliwia usłudze Service Fabric wstrzymanie żądań infrastruktury na poziomie maszyny wirtualnej (takich jak ponowne uruchomienie maszyny wirtualnej, ponowny obraz maszyny wirtualnej i migracja maszyny wirtualnej), które mają wpływ na wymagania kworum dla usług stanowych. Aby uzyskać informacje o zaletach różnych poziomów i zaleceń dotyczących tego, na jakim poziomie należy używać i kiedy, zobacz Charakterystykę trwałości klastra.

Warstwa niezawodności służy do ustawiania liczby replik usług systemowych, które mają być uruchamiane w tym klastrze w typie węzła podstawowego. Tym większa liczba replik, tym bardziej niezawodne usługi systemowe znajdują się w klastrze. Aby uzyskać korzyści z różnych poziomów i zaleceń, na których poziom ma być używany i kiedy, zobacz Charakterystykę niezawodności klastra.

Włączanie zwrotnego serwera proxy i/lub systemu DNS

Usługi łączące się ze sobą wewnątrz klastra zazwyczaj mogą uzyskiwać bezpośredni dostęp do punktów końcowych innych usług, ponieważ węzły w klastrze znajdują się w tej samej sieci lokalnej. Aby ułatwić nawiązywanie połączenia między usługami, usługa Service Fabric udostępnia dodatkowe usługi: usługę DNS i usługę zwrotnego serwera proxy. Obie usługi można włączyć podczas wdrażania klastra.

Ponieważ wiele usług, zwłaszcza usług konteneryzowanych, może mieć istniejącą nazwę adresu URL, możliwość ich rozpoznawania przy użyciu standardowego protokołu DNS (a nie protokołu usługi Nazewnictwa) jest wygodna, szczególnie w scenariuszach "lift and shift" aplikacji. Jest to dokładnie to, co robi usługa DNS. Umożliwia mapowania nazw DNS na nazwę usługi, a tym samym rozpoznawanie adresów IP punktu końcowego.

Zwrotny serwer proxy adresuje usługi w klastrze, które uwidaczniają punkty końcowe HTTP (w tym HTTPS). Zwrotny serwer proxy znacznie upraszcza wywoływanie innych usług przez udostępnienie określonego formatu identyfikatora URI. Zwrotny serwer proxy obsługuje również kroki rozwiązywania, nawiązywania połączenia i ponawiania próby wymagane przez jedną usługę do komunikowania się z inną usługą.

Przygotowywanie do odzyskiwania po awarii

Krytyczną częścią dostarczania wysokiej dostępności jest zapewnienie, że usługi mogą przetrwać wszystkie różne typy awarii. Jest to szczególnie ważne w przypadku niepoplanowanych i spoza kontroli. Przygotowanie do odzyskiwania po awarii opisuje niektóre typowe tryby awarii, które mogą być awariami, jeśli nie są prawidłowo modelowane i zarządzane. Omówiono również środki zaradcze i działania, które należy podjąć w przypadku wystąpienia awarii.

Lista kontrolna gotowości do produkcji

Czy aplikacja i klaster są gotowe do podjęcia ruchu produkcyjnego? Przed wdrożeniem klastra w środowisku produkcyjnym uruchom listę kontrolną Gotowość produkcyjna. Zachowaj bezproblemowe działanie aplikacji i klastra, pracując przez elementy na tej liście kontrolnej. Zdecydowanie zalecamy, aby wszystkie te elementy były wyewidencjonowane przed przejściem do środowiska produkcyjnego.

Następne kroki