Diretrizes de dimensionamento

  • Artigo

Visão geral das diretrizes de dimensionamento

Ao planejar a implantação de serviços de dados do Azure Arc, planeje a quantidade correta de:

  • Computação
  • Memória
  • Armazenamento

Esses recursos são necessários para:

  • O controlador de dados
  • Instâncias gerenciadas do SQL
  • Servidores PostgreSQL

Como os serviços de dados habilitados para Azure Arc são implantados no Kubernetes, você tem a flexibilidade de adicionar mais capacidade ao cluster do Kubernetes ao longo do tempo por nós de computação ou armazenamento. Este guia explica os requisitos mínimos e recomenda tamanhos para alguns requisitos comuns.

Requisitos gerais de dimensionamento

Observação

Caso você não conheça os conceitos deste artigo, leia mais sobre a Governança de recursos do Kubernetes e a Notação de tamanho do Kubernetes.

Os números de núcleos precisam ser um valor inteiro maior ou igual a um.

Ao implantar com a CLI do Azure (az), use uma potência de dois números para definir os valores de memória. Especificamente, use os sufixos:

  • Ki
  • Mi
  • Gi

Os valores de limite devem ser sempre maiores que o valor da solicitação, se especificado.

Os valores de limite dos núcleos são a métrica faturável na Instância Gerenciada de SQL e nos servidores do PostgreSQL.

Requisitos mínimos de implantação

O tamanho mínimo da implantação dos serviços de dados habilitados para Azure Arc pode ser considerado o controlador de dados do Azure Arc, mais uma Instância Gerenciada de SQL e um servidor do PostgreSQL. Para essa configuração, você precisa de pelo menos 16 GB de RAM e 4 núcleos de capacidade disponível no cluster do Kubernetes. Você deve garantir que você tenha um tamanho mínimo de nó Kubernetes de 8 GB de RAM e 4 núcleos e uma capacidade total de soma de 16 GB de RAM disponível em todos os nós do Kubernetes. Por exemplo, você pode ter um nó com 32 GB de RAM e 4 núcleos ou pode ter dois nós com 16 GB de RAM e 4 núcleos cada.

Confira o artigo Configuração de armazenamento para ver detalhes sobre o dimensionamento de armazenamento.

Detalhes de dimensionamento do controlador de dados

O controlador de dados é uma coleção de pods implantados no cluster do Kubernetes para fornecer uma API, o serviço do controlador, o inicializador e o monitoramento de bancos de dados e painéis. Esta tabela descreve os valores padrão para solicitações e limites de memória e CPU.

Nome do pod Solicitação de CPU Solicitação de memória Limite da CPU Limite de memória
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 é um daemonset, que é criado em cada um dos nós do Kubernetes em seu cluster. Os números na tabela são por nó. Se você definir allowNodeMetricsCollection = false no arquivo de perfil de implantação antes de criar o controlador de dados, esse daemonset não será criado.

Você pode substituir as configurações padrão para os pods de controldb e controle no arquivo YAML do controlador de dados. Exemplo:

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

Confira o artigo Configuração de armazenamento para ver detalhes sobre o dimensionamento de armazenamento.

Detalhes de dimensionamento da Instância Gerenciada de SQL

Cada Instância Gerenciada de SQL deve ter as seguintes limites e solicitações de recursos mínimos:

Camada de serviço Uso Geral Comercialmente Crítico
Solicitação de CPU Mínimo: 1
Máximo: 24
Padrão: 2		 Mínimo: 3
Máximo: ilimitado
Padrão: 4
Limite da CPU Mínimo: 1
Máximo: 24
Padrão: 2		 Mínimo: 3
Máximo: ilimitado
Padrão: 4
Solicitação de memória Mínimo: 2Gi
Máximo: 128Gi
Padrão: 4Gi		 Mínimo: 2Gi
Máximo: ilimitado
Padrão: 4Gi
Limite de memória Mínimo: 2Gi
Máximo: 128Gi
Padrão: 4Gi		 Mínimo: 2Gi
Máximo: ilimitado
Padrão: 4Gi

Cada pod de Instância Gerenciada de SQL criado tem três contêineres:

Nome do contêiner Solicitação de CPU Solicitação de memória Limite de CPU Limite de Memória Observações
fluentbit 100m 100Mi Não especificado Não especificado As solicitações de recurso de contêiner fluentbit são além de as solicitações especificadas para a instância gerenciada de SQL.
arc-sqlmi Especificado pelo usuário ou não especificado. Especificado pelo usuário ou não especificado. Especificado pelo usuário ou não especificado. Especificado pelo usuário ou não especificado.
collectd Não especificado Não especificado Não especificado Não especificado

O tamanho do volume padrão para todos os volumes persistentes é 5Gi.

Detalhes de dimensionamento do servidor PostgreSQL

Cada nó de servidor PostgreSQL precisa ter as seguintes solicitações de recursos mínimas:

  • Memória: 256Mi
  • Núcleos: 1

Cada pod de servidor PostgreSQL criado tem três contêineres:

Nome do contêiner Solicitação de CPU Solicitação de memória Limite de CPU Limite de Memória Observações
fluentbit 100m 100Mi Não especificado Não especificado As solicitações de recurso de contêiner fluentbit são além de as solicitações especificadas para o servidor PostgreSQL.
postgres Especificado pelo usuário ou não especificado. Usuário especificado ou 256Mi (padrão). Especificado pelo usuário ou não especificado. Especificado pelo usuário ou não especificado.
arc-postgresql-agent Não especificado Não especificado Não especificado Não especificado

Dimensionamento cumulativo

O tamanho geral de um ambiente necessário para os serviços de dados habilitados para Azure Arc é principalmente uma função do número e do tamanho das instâncias de banco de dados. O tamanho geral pode ser difícil de prever antecipadamente sabendo que o número de instâncias pode aumentar e diminuir e a quantidade de recursos necessários para cada instância de banco de dados pode mudar.

O tamanho da linha de base para um determinado ambiente de serviços de dados habilitado para Azure Arc é o tamanho do controlador de dados, que requer 4 núcleos e 16 GB de RAM. A partir daí, adicione o total cumulativo de núcleos e memória necessários para as instâncias de banco de dados. A Instância Gerenciada de SQL requer um pod para cada instância. O servidor PostgreSQL cria um pod para cada servidor.

Além dos núcleos e memória que você solicita para cada instância de banco de dados, você deve adicionar 250m de núcleos e 250Mi de RAM para os contêineres do agente.

Cálculo de dimensionamento de exemplo

Requisitos:

  • "SQL1": 1 instância gerenciada de SQL com 16 GB de RAM, 4 núcleos
  • "SQL2": 1 instância gerenciada de SQL com 256 GB de RAM, 16 núcleos
  • "Postgres1": 1 servidor PostgreSQL a 12 GB de RAM, 4 núcleos

Cálculos de dimensionamento:

  • O tamanho de "SQL1" é: 1 pod * ([16Gi RAM, 4 cores] + [250Mi RAM, 250m cores]). Para os agentes por pod, use 16.25 Gi RAM e 4,25 núcleos.

  • O tamanho de "SQL2" é: 1 pod * ([256Gi RAM, 16 cores] + [250Mi RAM, 250m cores]). Para os agentes por pod, use 256.25 Gi RAM e 16,25 núcleos.

  • O tamanho total do SQL 1 e do SQL 2 é:

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

  • O tamanho de "Postgres1" é: 1 pod * ([12Gi RAM, 4 cores] + [250Mi RAM, 250m cores]). Para os agentes por pod, use 12.25 Gi RAM e 4.25 núcleos.

  • A capacidade total necessária:

    • Para as instâncias de banco de dados:
      • 272.5-GB RAM
      • 20,5 núcleos
    • Para o SQL:
      • 12,25 GB DE RAM
      • 4,25 núcleos
    • Para o servidor PostgreSQL
      • 284,75 GB DE RAM
      • 24,75 núcleos

  • A capacidade total necessária para as instâncias de banco de dados mais o controlador de dados é:

    • Para a instância do banco de dados
      • 284,75 GB DE RAM
      • 24,75 núcleos
    • Para o controlador de dados
      • 16 GB de RAM
      • 4 núcleos
    • No total:
      • 300,75 GB DE RAM
      • 28,75 núcleos.

Confira o artigo Configuração de armazenamento para ver detalhes sobre o dimensionamento de armazenamento.

Outras considerações

Tenha em mente que uma determinada solicitação de tamanho de instância de banco de dados para núcleos ou RAM não pode exceder a capacidade disponível dos nós do Kubernetes no cluster. Por exemplo, se o maior nó do Kubernetes que você tem no cluster do Kubernetes for 256 GB de RAM e 24 núcleos, você não poderá criar uma instância de banco de dados com uma solicitação de 512 GB de RAM e 48 núcleos.

Mantenha pelo menos 25% da capacidade disponível nos nós do Kubernetes. Essa capacidade permite que o Kubernetes:

  • Agendar pods com eficiência para serem criados
  • Habilitar o dimensionamento elástico
  • Dá suporte a atualizações sem interrupção dos nós do Kubernetes
  • Facilita o crescimento de longo prazo sob demanda

Em seus cálculos de dimensionamento, adicione os requisitos de recursos dos pods do sistema do Kubernetes e quaisquer outras cargas de trabalho, que podem estar compartilhando capacidade com os serviços de dados habilitados para Azure Arc no mesmo cluster do Kubernetes.

Para manter a alta disponibilidade durante a manutenção planejada e a continuidade de desastres, planeje que pelo menos um dos nós do Kubernetes em seu cluster fique indisponível a qualquer momento. O Kubernetes tenta reagendar os pods que estavam em execução em um determinado nó que foi retirado para manutenção ou devido a uma falha. Se não houver capacidade disponível nos nós restantes, esses pods não serão reagendados para criação até que haja capacidade disponível novamente. Tenha cuidado extra com instâncias de banco de dados grandes. Por exemplo, se houver apenas um nó do Kubernetes grande o suficiente para atender aos requisitos de recursos de uma instância de banco de dados grande e esse nó falhar, o Kubernetes não agenda o pod da instância do banco de dados para outro nó do Kubernetes.

Lembre-se dos limites máximos de tamanho de um cluster do Kubernetes.

O administrador do Kubernetes pode ter configurado cotas de recursos em seu namespace/projeto. Tenha essas cotas em mente ao planejar os tamanhos da instância do banco de dados.