Sizing Guidance

Introducción a la guía para el ajuste de tamaño

Al planear la implementación de los servicios de datos de Azure Arc, planee la cantidad correcta de:

• Compute
• Memory
• Storage

Estos recursos son necesarios para:

• El controlador de datos
• Instancias administradas de SQL

Como los servicios de datos habilitados para Azure Arc se implementan en Kubernetes, tiene la flexibilidad de agregar más capacidad al clúster de Kubernetes a lo largo del tiempo mediante nodos de ejecución o almacenamiento. En esta guía se explican los requisitos mínimos y se recomiendan los tamaños para algunos requisitos comunes.

Requisitos generales de tamaño

El número de núcleos debe ser un valor entero mayor o igual que uno.

Al implementar con la CLI de Azure (az), use una potencia de dos números para establecer los valores de memoria. En concreto, use los sufijos:

• Ki
• Mi
• Gi

Los valores límite siempre deben ser mayores que el valor de la solicitud, si se especifica.

Los valores límite para los núcleos son la métrica facturable en una instancia administrada de SQL.

Requisitos mínimos de implementación

Una implementación de servicios de datos habilitados para Azure Arc de tamaño mínimo podría considerarse controlador de datos de Azure Arc más una instancia administrada de SQL. For this configuration, you need at least 16-GB RAM and 4 cores of available capacity on your Kubernetes cluster. Debe asegurarse de que tiene un tamaño mínimo de nodo de Kubernetes de 8 GB de memoria RAM y 4 núcleos y una capacidad total de 16 GB de RAM disponible entre todos los nodos de Kubernetes. Por ejemplo, podría tener 1 nodo con 32 GB de memoria RAM y 4 núcleos o bien tener 2 nodos con 16 GB de memoria RAM y 4 núcleos cada uno.

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

Detalles sobre el ajuste de tamaño del controlador de datos

El controlador de datos es una colección de pods que se implementan en el clúster de Kubernetes para proporcionar una API, el servicio de controlador, el programa previo y las bases de datos y paneles de supervisión. En esta tabla se describen los valores predeterminados para las solicitudes y límites de memoria y CPU.

metricsdc es un daemonset que se crea en cada uno de los nodos de Kubernetes del clúster. The numbers in the table are per node. Si establece allowNodeMetricsCollection = false en el archivo de perfil de implementación antes de crear el controlador de datos, no se crea este daemonset.

Puede invalidar la configuración predeterminada de los pods de control y controldb en el archivo YAML del controlador de datos. 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.

Detalles de ajuste de tamaño de la instancia administrada de SQL

Cada instancia administrada de SQL debe tener las siguientes solicitudes y límites de recursos mínimos:

Cada pod de instancia administrada de SQL que se crea tiene tres contenedores:

El tamaño de volumen predeterminado para todos los volúmenes persistentes es 5 5Gi.

Cumulative sizing

El tamaño total necesario de un entorno para los servicios de datos habilitados para Azure Arc es principalmente una función del número y el tamaño de las instancias de base de datos. Puede ser difícil predecir con anticipación el tamaño total sabiendo que el número de instancias podría crecer y disminuir y que la cantidad de recursos necesarios para cada instancia de base de datos puede cambiar.

El tamaño de línea base de un entorno de servicios de datos habilitados para Azure Arc determinado es el tamaño del controlador de datos, que requiere 4 núcleos y 16 GB de RAM. Desde ahí, agregue el total acumulado de núcleos y memoria que se requieran para las instancias de base de datos. SQL Managed Instance requiere un pod por cada instancia.

Además de los núcleos y la memoria que solicite para cada instancia de base de datos, deberá sumar 250m de núcleos y 250Mi de RAM para los contenedores del agente.

Ejemplo del cálculo de dimensionamiento

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:

• El tamaño de "SQL1" es: 1 pod * ([16Gi RAM, 4 cores] + [250Mi RAM, 250m cores]). Para los agentes por pod, use 16.25 Gi RAM y 4,25 núcleos.

• El tamaño de "SQL2" es: 1 pod * ([256Gi RAM, 16 cores] + [250Mi RAM, 250m cores]). Para los agentes por pod, use 256.25 Gi RAM y 16,25 núcleos.

• El tamaño total de SQL 1 y SQL 2 es:

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

• El tamaño de "Postgres1" es: 1 pod * ([12Gi RAM, 4 cores] + [250Mi RAM, 250m cores]). Para los agentes por pod, use 12.25 Gi RAM y 4.25 núcleos.

• Capacidad total necesaria:

  • Para instancias de base de datos:
    • 272.5-GB RAM
    • 20.5 cores
  • For SQL:
    • 12.25-GB RAM
    • 4.25 cores

• La capacidad total que se necesita para las instancias de base de datos más el controlador de datos es:

  • Para la instancia de base de datos
    • 284.75-GB RAM
    • 24.75 cores
  • Para el controlador de datos
    • 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

Tenga en cuenta que la solicitud de tamaño de una instancia de base de datos determinada para núcleos o RAM no puede superar la capacidad disponible de los nodos de Kubernetes en el clúster. Por ejemplo, si el nodo de Kubernetes más grande que tiene en el clúster de Kubernetes tiene 256 GB de RAM y 24 núcleos, no podrá crear una instancia de base de datos con una solicitud de 512 GB de RAM y 48 núcleos.

Mantenga al menos el 25 % de la capacidad disponible en los nodos de Kubernetes. Esta capacidad permite a Kubernetes:

• Programar de forma eficaz los pods que se vayan a crear
• Habilitar el escalado elástico
• Admitir actualizaciones graduales de los nodos de Kubernetes
• Facilitar un mayor crecimiento a largo plazo a petición

En los cálculos de dimensionamiento, agregue los requisitos de recursos de los pods del sistema de Kubernetes, así como cualquier otra carga de trabajo que pudiera estar compartiendo capacidad con los servicios de datos habilitados para Azure Arc en el mismo clúster de Kubernetes.

Para mantener la alta disponibilidad durante el mantenimiento planeado y la continuidad ante desastres, planee que al menos uno de los nodos de Kubernetes en el clúster no estará disponible en un momento determinado. Kubernetes intentará volver a programar los pods que se ejecutaban en un nodo determinado que se retiró para realizar mantenimiento o debido a un error. Si no hubiera ninguna capacidad disponible en el resto de los nodos, estos pods no se volverán a programar para su creación hasta que haya capacidad disponible de nuevo. Tenga especial cuidado con las instancias de base de datos de gran tamaño. Por ejemplo, si solo hubiera un nodo de Kubernetes lo suficientemente grande como para cumplir con los requisitos de recursos de una instancia de base de datos de gran tamaño y ese nodo presentase un error, Kubernetes no programará el pod de dicha instancia de base de datos en otro nodo de Kubernetes.

Tenga en cuenta los límites máximos para un tamaño de clúster de Kubernetes.

Your Kubernetes administrator may have set up resource quotas on your namespace/project. Tenga estas cuotas en cuenta al planear los tamaños de instancia de base de datos.