Diretrizes de dimensionamento

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.