Wskazówki dotyczące ustalania rozmiaru

  • Artykuł

Omówienie wskazówek dotyczących określania rozmiaru

Podczas planowania wdrożenia usług danych Azure Arc zaplanuj poprawną ilość:

  • Compute
  • Pamięć
  • Storage

Te zasoby są wymagane w następujących celach:

  • Kontroler danych
  • Wystąpienia zarządzane SQL
  • Serwery PostgreSQL

Ponieważ usługi danych z obsługą usługi Azure Arc są wdrażane na platformie Kubernetes, masz elastyczność dodawania większej pojemności do klastra Kubernetes w czasie przez węzły obliczeniowe lub magazyn. W tym przewodniku opisano minimalne wymagania i zalecamy rozmiary niektórych typowych wymagań.

Ogólne wymagania dotyczące ustalania rozmiaru

Uwaga

Jeśli nie znasz pojęć w tym artykule, możesz dowiedzieć się więcej na temat ładu zasobów platformy Kubernetes i notacji rozmiaru platformy Kubernetes.

Liczby rdzeni muszą być liczbą całkowitą większą lub równą jednej.

Podczas wdrażania przy użyciu interfejsu wiersza polecenia platformy Azure (az) użyj możliwości dwóch liczb, aby ustawić wartości pamięci. W szczególności użyj sufiksów:

  • Ki
  • Mi
  • Gi

Wartości limitu muszą być zawsze większe niż wartość żądania, jeśli określono.

Wartości limitu rdzeni to metryka rozliczana na serwerach sql managed instance i PostgreSQL.

Minimalne wymagania dotyczące wdrożenia

Wdrożenie usług danych z obsługą usługi Azure Arc o minimalnym rozmiarze może być kontrolerem danych usługi Azure Arc oraz jednym wystąpieniem zarządzanym SQL oraz jednym serwerem PostgreSQL. W przypadku tej konfiguracji potrzebujesz co najmniej 16 GB pamięci RAM i 4 rdzeni dostępnej pojemności w klastrze Kubernetes. Upewnij się, że masz minimalny rozmiar węzła Kubernetes o rozmiarze 8 GB pamięci RAM i 4 rdzeni oraz łączną pojemność 16 GB pamięci RAM dostępną we wszystkich węzłach kubernetes. Można na przykład mieć 1 węzeł z 32 GB pamięci RAM i 4 rdzeni lub mieć 2 węzły z 16 GB pamięci RAM i 4 rdzeniami.

Aby uzyskać szczegółowe informacje na temat ustalania rozmiaru magazynu, zobacz artykuł dotyczący konfiguracji magazynu.

Szczegóły ustalania rozmiaru kontrolera danych

Kontroler danych to kolekcja zasobników wdrożonych w klastrze Kubernetes w celu udostępnienia interfejsu API, usługi kontrolera, programu inicjatora oraz monitorowania baz danych i pulpitów nawigacyjnych. W tej tabeli opisano wartości domyślne żądań i limitów pamięci i procesora CPU.

Nazwa zasobnika Żądanie procesora CPU Żądanie pamięci Limit procesora CPU Limit pamięci
bootstrapper 100m 100Mi 200m 200Mi
control 400m 2Gi 1800m 2Gi
controldb 200m 4Gi 800m 6Gi
logsdb 200m 1600Mi 2 1600Mi
logsui 100m 500Mi 2 2Gi
metricsdb 200m 800Mi 400m 2Gi
metricsdc 100m 200Mi 200m 300Mi
metricsui 20m 200Mi 500m 200Mi

metricsdc to element daemonset, który jest tworzony w każdym z węzłów Kubernetes w klastrze. Liczby w tabeli są na węzeł. Jeśli ustawisz allowNodeMetricsCollection = false w pliku profilu wdrożenia przed utworzeniem kontrolera danych, nie zostanie to daemonset utworzone.

Możesz zastąpić ustawienia domyślne zasobników controldb i w pliku YAML kontrolera danych. Przykład:

  resources:
    controller:
      limits:
        cpu: "1000m"
        memory: "3Gi"
      requests:
        cpu: "800m"
        memory: "2Gi"
    controllerDb:
      limits:
        cpu: "800m"
        memory: "8Gi"
      requests:
        cpu: "200m"
        memory: "4Gi"

Aby uzyskać szczegółowe informacje na temat ustalania rozmiaru magazynu, zobacz artykuł dotyczący konfiguracji magazynu.

Szczegóły ustalania rozmiaru wystąpienia zarządzanego SQL

Każde wystąpienie zarządzane SQL musi mieć następujące minimalne żądania i limity zasobów:

Warstwa usług Ogólnego przeznaczenia Krytyczne dla działania firmy
Żądanie procesora CPU Minimum: 1
Maksymalna: 24
Ustawienie domyślne: 2		 Minimum: 3
Maksymalna: nieograniczona
Ustawienie domyślne: 4
Limit procesora CPU Minimum: 1
Maksymalna: 24
Ustawienie domyślne: 2		 Minimum: 3
Maksymalna: nieograniczona
Ustawienie domyślne: 4
Żądanie pamięci Minimalne: 2Gi
Maksymalna: 128Gi
Domyślnie: 4Gi		 Minimalne: 2Gi
Maksymalna: nieograniczona
Domyślnie: 4Gi
Limit pamięci Minimalne: 2Gi
Maksymalna: 128Gi
Domyślnie: 4Gi		 Minimalne: 2Gi
Maksymalna: nieograniczona
Domyślnie: 4Gi

Każdy utworzony zasobnik wystąpienia zarządzanego SQL ma trzy kontenery:

Nazwa kontenera Żądanie procesora CPU Żądania pamięci Limit procesora CPU Limit pamięci Uwagi
fluentbit 100m 100Mi Nieokreślona Nieokreślona fluentbit Żądania zasobów kontenera są dodatkiem do żądań określonych dla wystąpienia zarządzanego SQL.
arc-sqlmi Użytkownik został określony lub nie został określony. Użytkownik został określony lub nie został określony. Użytkownik został określony lub nie został określony. Użytkownik został określony lub nie został określony.
collectd Nieokreślona Nieokreślona Nieokreślona Nieokreślona

Domyślny rozmiar woluminu dla wszystkich woluminów trwałych to 5Gi.

Szczegóły ustalania rozmiaru serwera PostgreSQL

Każdy węzeł serwera PostgreSQL musi mieć następujące minimalne żądania zasobów:

  • Pamięci: 256Mi
  • Rdzenie: 1

Każdy utworzony zasobnik serwera PostgreSQL ma trzy kontenery:

Nazwa kontenera Żądanie procesora CPU Żądania pamięci Limit procesora CPU Limit pamięci Uwagi
fluentbit 100m 100Mi Nieokreślona Nieokreślona Żądania fluentbit zasobów kontenera są dodatkiem do żądań określonych dla serwera PostgreSQL.
postgres Użytkownik został określony lub nie został określony. Określony użytkownik lub 256Mi (wartość domyślna). Użytkownik został określony lub nie został określony. Użytkownik został określony lub nie został określony.
arc-postgresql-agent Nieokreślona Nieokreślona Nieokreślona Nieokreślona

Ustalanie rozmiaru skumulowanego

Ogólny rozmiar środowiska wymaganego dla usług danych z obsługą usługi Azure Arc jest przede wszystkim funkcją liczby i rozmiaru wystąpień bazy danych. Całkowity rozmiar może być trudny do przewidzenia przed upływem czasu, wiedząc, że liczba wystąpień może wzrosnąć i zmniejszyć, a ilość zasobów wymaganych dla każdego wystąpienia bazy danych może ulec zmianie.

Rozmiar punktu odniesienia dla danego środowiska usług danych z obsługą usługi Azure Arc to rozmiar kontrolera danych, który wymaga 4 rdzeni i 16 GB pamięci RAM. W tym miejscu dodaj łączną sumę rdzeni i pamięci wymaganą dla wystąpień bazy danych. Usługa SQL Managed Instance wymaga jednego zasobnika dla każdego wystąpienia. Serwer PostgreSQL tworzy jeden zasobnik dla każdego serwera.

Oprócz rdzeni i pamięci żądanej dla każdego wystąpienia bazy danych należy dodać 250m rdzenie i 250Mi pamięć RAM dla kontenerów agentów.

Przykładowe obliczenie rozmiaru

Wymagania:

  • "SQL1": 1 wystąpienie zarządzane SQL z 16 GB pamięci RAM, 4 rdzenie
  • "SQL2": 1 wystąpienie zarządzane SQL z 256 GB pamięci RAM, 16 rdzeni
  • "Postgres1": 1 serwer PostgreSQL na 12 GB pamięci RAM, 4 rdzenie

Ustalanie rozmiaru obliczeń:

  • Rozmiar "SQL1" to: 1 pod * ([16Gi RAM, 4 cores] + [250Mi RAM, 250m cores]). W przypadku agentów na zasobnik należy użyć 16.25 Gi pamięci RAM i 4,25 rdzeni.

  • Rozmiar "SQL2" to: 1 pod * ([256Gi RAM, 16 cores] + [250Mi RAM, 250m cores]). W przypadku agentów na zasobnik użyj 256.25 Gi pamięci RAM i 16,25 rdzeni.

  • Całkowity rozmiar sql 1 i SQL 2 to:

    • (16.25 GB + 256.25 Gi) = 272.5-GB RAM
    • (4.25 cores + 16.25 cores) = 20.5 cores

  • Rozmiar "Postgres1" to: 1 pod * ([12Gi RAM, 4 cores] + [250Mi RAM, 250m cores]). W przypadku agentów na zasobnik użyj 12.25 Gi pamięci RAM i 4.25 rdzeni.

  • Łączna wymagana pojemność:

    • W przypadku wystąpień bazy danych:
      • 272,5 GB pamięci RAM
      • 20,5 rdzeni
    • W przypadku języka SQL:
      • 12,25 GB pamięci RAM
      • 4,25 rdzeni
    • Dla serwera PostgreSQL
      • 284,75 GB pamięci RAM
      • 24,75 rdzeni

  • Łączna pojemność wymagana dla wystąpień bazy danych oraz kontrolera danych to:

    • Dla wystąpienia bazy danych
      • 284,75 GB pamięci RAM
      • 24,75 rdzeni
    • Dla kontrolera danych
      • 16 GB pamięci RAM
      • 4 rdzenie
    • Łącznie:
      • 300,75 GB pamięci RAM
      • 28,75 rdzeni.

Aby uzyskać szczegółowe informacje na temat ustalania rozmiaru magazynu, zobacz artykuł dotyczący konfiguracji magazynu.

Inne kwestie wymagające rozważenia

Należy pamiętać, że dane żądanie rozmiaru wystąpienia bazy danych dla rdzeni lub pamięci RAM nie może przekroczyć dostępnej pojemności węzłów Kubernetes w klastrze. Jeśli na przykład największy węzeł Kubernetes w klastrze Kubernetes to 256 GB pamięci RAM i 24 rdzenie, nie można utworzyć wystąpienia bazy danych z żądaniem 512 GB pamięci RAM i 48 rdzeni.

Zachowaj co najmniej 25% dostępnej pojemności w węzłach Kubernetes. Ta pojemność umożliwia platformie Kubernetes:

  • Efektywne planowanie tworzenia zasobników
  • Włączanie elastycznego skalowania
  • Obsługuje uaktualnienia stopniowe węzłów platformy Kubernetes
  • Ułatwia długoterminowy wzrost na żądanie

W obliczeniach ustalania rozmiaru dodaj wymagania dotyczące zasobów zasobników systemowych Kubernetes i innych obciążeń, które mogą być współdzielone z usługami danych z obsługą usługi Azure Arc w tym samym klastrze Kubernetes.

Aby zachować wysoką dostępność podczas planowanej konserwacji i ciągłości awarii, zaplanuj co najmniej jeden z węzłów Kubernetes w klastrze, aby był niedostępny w danym momencie w danym momencie. Platforma Kubernetes próbuje ponownie zaplanować zasobniki uruchomione w danym węźle, który został zdjęty do konserwacji lub z powodu awarii. Jeśli w pozostałych węzłach nie będzie dostępna pojemność, te zasobniki nie zostaną ponownie zaplanowane do utworzenia, dopóki nie będzie dostępna pojemność ponownie. Zachowaj szczególną ostrożność w przypadku dużych wystąpień bazy danych. Jeśli na przykład istnieje tylko jeden węzeł Kubernetes wystarczająco duży, aby spełnić wymagania dotyczące zasobów dużego wystąpienia bazy danych i ten węzeł ulegnie awarii, platforma Kubernetes nie zaplanuje tego zasobnika wystąpienia bazy danych w innym węźle Kubernetes.

Należy pamiętać o maksymalnych limitach rozmiaru klastra Kubernetes.

Administrator platformy Kubernetes mógł skonfigurować limity przydziału zasobów w przestrzeni nazw/projekcie. Należy pamiętać o tych przydziałach podczas planowania rozmiarów wystąpień bazy danych.