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ęć
• Przechowywanie

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ść w dodawaniu dodatkowej pojemności do klastra Kubernetes w czasie przez węzły obliczeniowe lub pamięć masową. W tym przewodniku opisano minimalne wymagania i zalecamy rozmiary niektórych typowych wymagań.

Ogólne wymagania dotyczące ustalania rozmiaru

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

Minimalne wdrożenie usług danych z obsługą Azure Arc można uznać za składające się z kontrolera danych Azure Arc, jednego zarządzanego wystąpienia SQL oraz jednego serwera 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.

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

Możesz zmienić domyślne ustawienia dla zasobników controldb i zasobników kontrolnych 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:

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

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 pod serwera PostgreSQL ma trzy kontenery:

Rozmiar kumulacyjny

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 pod dla każdego serwera.

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

Przykładowe obliczenie rozmiaru

Wymagania:

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

Obliczenia dotyczące rozmiarów

• 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" wynosi: 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 pod 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 żądanie dotyczące rozmiaru instancji bazy danych dla rdzeni lub pamięci RAM nie może przekroczyć dostępnej pojemności węzłów 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 stopniowe aktualizacje węzłów Kubernetes
• Umożliwia długoterminowy wzrost według potrzeb

W obliczeniach ustalania rozmiaru dodaj wymagania dotyczące zasobów zasobników systemowych Kubernetes oraz wszelkich innych obciążeń, które mogą współdzielić zasoby z usługami danych obsługiwanymi przez Azure Arc w tym samym klastrze Kubernetes.

Aby zachować wysoką dostępność podczas planowanej konserwacji i ciągłość działania w przypadku awarii, zaplanuj, że co najmniej jeden z węzłów Kubernetes w klastrze będzie niedostępny 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 na pozostałych węzłach nie będzie dostępna pojemność, te zasobniki nie zostaną utworzone ponownie, dopóki znowu nie będzie dostępna pojemność. 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żej instancji bazy danych, i ten węzeł zawiedzie, Kubernetes nie zaplanuje tego podu instancji bazy danych na inny węzeł klastra 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.