Sizing Guidance

Übersicht über den Dimensionierungsleitfaden

Planen Sie bei der Bereitstellung von Azure Arc-Datendiensten die richtige Menge an Daten ein:

• Compute
• Memory
• Storage

Diese Ressourcen werden benötigt für:

• Der Datencontroller
• Verwaltete SQL-Instanzen

Da die Datendienste mit Arc-Unterstützung von Azure auf Kubernetes bereitgestellt werden, können Sie Ihrem Kubernetes-Cluster im Laufe der Zeit flexibel mehr Kapazität durch Rechenknoten oder Speicher hinzufügen. In diesem Leitfaden werden die Mindestanforderungen erläutert und Größenempfehlungen für einige gängige Anforderungen gegeben.

Allgemeine Dimensionierungsanforderungen

Die Anzahl der Kerne muss eine ganze Zahl größer oder gleich 1 sein.

Wenn Sie mit Azure CLI (az) bereitstellen, verwenden Sie eine Zweierpotenz, um die Speicherwerte festzulegen. Verwenden Sie insbesondere die Suffixe:

• Ki
• Mi
• Gi

Grenzwerte müssen immer größer als der Anforderungswert sein, sofern angegeben.

Grenzwerte für Kerne sind die abrechnende Metrik für die verwaltete SQL-Instanz.

Mindestanforderungen für die Bereitstellung

Eine Mindestgröße für die Bereitstellung von Azure Arc-fähigen Datendiensten könnte als Azure Arc-Datencontroller und eine SQL-verwaltete Instanz angesehen werden. For this configuration, you need at least 16-GB RAM and 4 cores of available capacity on your Kubernetes cluster. Sie sollten sicherstellen, dass die Kubernetes-Knoten eine Mindestgröße von 8 GB RAM und 4 Kernen umfassen und dass auf allen Kubernetes-Knoten eine Gesamtkapazität von 16 GB RAM zur Verfügung steht. Beispielsweise können Sie über einen Knoten mit 32 GB RAM und 4 Kernen oder über zwei Knoten mit jeweils 16 GB RAM und vier Kernen verfügen.

See the storage-configuration article for details on storage sizing.

Dimensionierungsdetails des Datencontrollers

Der Datencontroller ist eine Sammlung von Pods, die im Kubernetes-Cluster bereitgestellt werden, um eine API, den Controllerdienst, den Bootstrapper sowie die Überwachungsdatenbanken und -dashboards zur Verfügung zu stellen. In dieser Tabelle werden die Standardwerte für Arbeitsspeicher- und CPU-Anforderungen sowie CPU-Limits beschrieben.

metricsdc ist ein daemonset, das auf jedem der Kubernetes-Knoten in Ihrem Cluster erstellt wird. The numbers in the table are per node. Wenn Sie allowNodeMetricsCollection = false in Ihrer Bereitstellungsprofildatei festlegen, bevor Sie den Datencontroller erstellen, wird dieses daemonset nicht erstellt.

Sie können die Standardeinstellungen für controldb und den Steuerungspods in der Datencontroller-YAML-Datei überschreiben. Example:

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

See the storage-configuration article for details on storage sizing.

Dimensionierungsdetails verwalteter SQL-Instanzen

Jede verwaltete SQL-Instanz muss über die folgenden Ressourcenmindestanforderungen und -limits verfügen:

Jeder erstellte SQL Managed Instance-Pod umfasst drei Container:

Die Standardvolumegröße für alle persistenten Volumes beträgt 5Gi.

Cumulative sizing

Die erforderliche Gesamtgröße einer Umgebung für Azure Arc-fähige Datendienste hängt hauptsächlich von der Anzahl und Größe der Datenbankinstanzen ab. Die Gesamtgröße kann schwierig vorherzusagen sein, da die Anzahl der Instanzen zunehmen und abnehmen und sich der Umfang der für jede Datenbankinstanz erforderlichen Ressourcen ändern könnte.

Die Baselinegröße einer Umgebung für Azure Arc-fähige Datendienste ist die Größe des Datencontrollers, der 4 Kerne und 16 GB RAM erfordert. Dieser können Sie die Summe der Kerne und des Arbeitsspeichers hinzufügen, die für die Datenbankinstanzen erforderlich sind. SQL Managed Instance erfordert einen Pod für jede Instanz.

Zusätzlich zu den Kernen und dem Arbeitsspeicher, die Sie für jede Datenbankinstanz anfordern, sollten Sie 250m an Kernen und 250Mi an RAM für die Agentcontainer hinzufügen.

Beispiel für die Größenberechnung

Requirements:

• "SQL1": 1 SQL managed instance with 16-GB RAM, 4 cores
• "SQL2": 1 SQL managed instance with 256-GB RAM, 16 cores

Sizing calculations:

• Größe von „SQL1“: 1 pod * ([16Gi RAM, 4 cores] + [250Mi RAM, 250m cores]). Verwenden Sie 16.25 Gi RAM und 4,25 Kerne pro Pod für die Agents.

• Größe von „SQL2“: 1 pod * ([256Gi RAM, 16 cores] + [250Mi RAM, 250m cores]). Verwenden Sie 256.25 Gi RAM und 16,25 Kerne pro Pod für die Agents.

• Gesamtgröße von SQL1 und SQL2:

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

• Größe von „Postgres1“: 1 pod * ([12Gi RAM, 4 cores] + [250Mi RAM, 250m cores]). Verwenden Sie 12.25 Gi RAM und 4.25 Kerne pro Pod für die Agents.

• Die erforderliche Gesamtkapazität:

  • Für die Datenbankinstanzen:
    • 272.5-GB RAM
    • 20.5 cores
  • For SQL:
    • 12.25-GB RAM
    • 4.25 cores

• Die für die Datenbankinstanzen plus Datencontroller erforderliche Gesamtkapazität:

  • Für die Datenbankinstanz
    • 284.75-GB RAM
    • 24.75 cores
  • Für den Datencontroller
    • 16-GB RAM
    • 4 cores
  • In total:
    • 300.75-GB RAM
    • 28.75 cores.

See the storage-configuration article for details on storage sizing.

Other considerations

Beachten Sie, dass die Anforderung der Datenbankinstanzgröße für Kerne oder RAM die verfügbare Kapazität der Kubernetes-Knoten im Cluster nicht überschreiten darf. Wenn beispielsweise der größte Kubernetes-Knoten im Kubernetes-Cluster 256 GB RAM und 24 Kerne umfasst, können Sie keine Datenbankinstanz mit einer Anforderung von 512 GB RAM und 48 Kernen erstellen.

Halten Sie mindestens 25 % der verfügbaren Kapazität der Kubernetes-Knoten vor. Diese Kapazität ermöglicht Kubernetes folgendes:

• Effizientes Planen der Erstellung von Pods
• Aktivieren der elastischen Skalierung
• Unterstützt rollierende Upgrades der Kubernetes-Knoten
• Erleichtert ein langfristiges Wachstum bei Bedarf

Berücksichtigen Sie bei den Dimensionierungsberechnungen die Ressourcenanforderungen der Kubernetes-Systempods und andere Workloads, die möglicherweise gemeinsam mit Azure Arc-fähigen Datendiensten in demselben Kubernetes-Cluster Kapazität nutzen.

Damit während geplanter Wartung und Notfällen Hochverfügbarkeit erhalten bleibt, berücksichtigen Sie bei der Planung, dass stets eine Situation eintreten kann, in der mindestens ein Kubernetes-Knoten im Cluster nicht verfügbar ist. Kubernetes versucht, die Pods, die auf einem wegen Wartung oder aufgrund eines Fehlers außer Betrieb genommenen Knoten ausgeführt wurden, neu zu planen. Falls auf den verbleibenden Knoten keine Kapazität verfügbar ist, wird die Erstellung dieser Pods erst dann neu geplant, wenn wieder Kapazität verfügbar ist. Große Datenbankinstanzen erfordern besondere Vorsicht. Wenn beispielsweise nur ein Kubernetes-Knoten groß genug ist, um die Ressourcenanforderungen einer großen Datendankinstanz zu erfüllen, und dieser Knoten ausfällt, wird Kubernetes diesen Datenbankinstanzpod nicht für die Erstellung auf einem anderen Kubernetes-Knoten planen.

Beachten Sie die oberen Grenzwerte für die Kubernetes-Clustergröße.

Your Kubernetes administrator may have set up resource quotas on your namespace/project. Beachten Sie diese Kontingente beim Planen der Datenbankinstanzgrößen.