Wskazówki dotyczące ustalania rozmiaru

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	Minimum: 2Gi Maksimum: 128Gi Domyślnie: 4Gi	Minimum: 2Gi Maksymalna: nieograniczona Domyślnie: 4Gi
Limit pamięci	Minimum: 2Gi Maksimum: 128Gi Domyślnie: 4Gi	Minimum: 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ęć: 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 uwagi

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.