Guía para el ajuste de tamaño

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:

• Proceso
• Memoria
• Storage

Estos recursos son necesarios para:

• El controlador de datos
• Instancias administradas de SQL
• Servidores PostgreSQL

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

Nota:

Si no está familiarizado con los conceptos que aparecen en este artículo, puede leer más sobre la gobernanza de los recursos de Kubernetes y la notación de tamaño de Kubernetes.

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 de los núcleos son la métrica facturable en la instancia administrada de SQL y los servidores de PostgreSQL.

Requisitos mínimos de implementación

Se puede considerar que el controlador de datos de Azure Arc más una instancia administrada de SQL más un servidor de PostgreSQL es una implementación de servicios de datos habilitados para Azure Arc de tamaño mínimo. En el caso de esta configuración, se necesitan al menos 16 GB de RAM y 4 núcleos de capacidad disponible en el clúster de Kubernetes. 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.

Para detalles sobre el ajuste de tamaño, consulte el artículo storage-configuration.

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.

Nombre del pod	Solicitud de CPU	Solicitud de memoria	Límite de CPU	Límite de memoria
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 es un daemonset que se crea en cada uno de los nodos de Kubernetes del clúster. Los números de la tabla son por nodo. 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. Ejemplo:

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

Para detalles sobre el ajuste de tamaño, consulte el artículo storage-configuration.

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:

Nivel de servicio	Uso general	Crítico para la empresa
Solicitud de CPU	Mínimo: 1 Máximo: 24 Valor predeterminado: 2	Mínimo: 3 Máximo: ilimitado Valor predeterminado: 4
Límite de CPU	Mínimo: 1 Máximo: 24 Valor predeterminado: 2	Mínimo: 3 Máximo: ilimitado Valor predeterminado: 4
Solicitud de memoria	Mínimo: 2Gi Máximo: 128Gi Opción predeterminada: 4Gi	Mínimo: 2Gi Máximo: ilimitado Opción predeterminada: 4Gi
Límite de memoria	Mínimo: 2Gi Máximo: 128Gi Opción predeterminada: 4Gi	Mínimo: 2Gi Máximo: ilimitado Opción predeterminada: 4Gi

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

Nombre del contenedor	Solicitud de CPU	Solicitud de memoria	Límite de CPU	Límite de memoria	Notas
fluentbit	100m	100Mi	No especificado	No especificado	Las solicitudes de recursos de contenedor fluentbit son adicionales a las solicitudes especificadas para la instancia administrada de SQL.
arc-sqlmi	Especificado o no especificado por el usuario.	Especificado o no especificado por el usuario.	Especificado o no especificado por el usuario.	Especificado o no especificado por el usuario.
collectd	No especificado	No especificado	No especificado	No especificado

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

Detalles de dimensionamiento del servidor PostgreSQL

Cada nodo del servidor de PostgreSQL debe tener las siguientes solicitudes de recursos mínimas:

• Memoria: 256Mi
• Núcleos: 1

Cada pod de servidor de PostgreSQL que se crea tiene tres contenedores:

Nombre del contenedor	Solicitud de CPU	Solicitud de memoria	Límite de CPU	Límite de memoria	Notas
fluentbit	100m	100Mi	No especificado	No especificado	Las solicitudes de recursos de contenedor fluentbit son adicionales a las solicitudes especificadas para el servidor de PostgreSQL.
postgres	Especificado o no especificado por el usuario.	Especificado por el usuario o 256Mi (valor predeterminado).	Especificado o no especificado por el usuario.	Especificado o no especificado por el usuario.
arc-postgresql-agent	No especificado	No especificado	No especificado	No especificado

Ajuste de tamaño acumulado

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. El servidor PostgreSQL crea un pod para cada servidor.

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

Requisitos:

• "SQL1": 1 instancia administrada de SQL con 16 GB de RAM y 4 núcleos
• "SQL2": 1 instancia administrada de SQL con 256 GB de RAM y 16 núcleos
• "Postgres1": 1 servidor de PostgreSQL de 12 GB de RAM y 4 núcleos

Cálculos de ajuste de tamaño:

• 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 DE RAM
    • 20,5 núcleos
  • Para SQL:
    • 12,25 GB DE RAM
    • 4,25 núcleos
  • Para servidores PostgreSQL
    • 284,75 GB DE RAM
    • 24,75 núcleos

• 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 DE RAM
    • 24,75 núcleos
  • Para el controlador de datos
    • 16 GB de memoria RAM
    • 4 núcleos
  • En total:
    • 300,75 GB DE RAM
    • 28,75 núcleos.

Para detalles sobre el ajuste de tamaño, consulte el artículo storage-configuration.

Otras consideraciones

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.

Es posible que el administrador de Kubernetes haya configurado cuotas de recursos en su espacio de nombre o proyecto. Tenga estas cuotas en cuenta al planear los tamaños de instancia de base de datos.