Orientação de dimensionamento

Visão geral das diretrizes de dimensionamento

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

• Computação
• Memória
• Armazenamento

Estes recursos são necessários para:

• O responsável pelo tratamento dos dados
• Instâncias geridas 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

Nota

Se você não estiver familiarizado com os conceitos deste artigo, poderá ler mais sobre governança de recursos do Kubernetes e notação de tamanho do Kubernetes.

Os números de núcleos devem 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-limite devem ser sempre superiores ao valor da solicitação, se especificado.

Os valores limite para núcleos são a métrica faturável na instância gerenciada SQL e nos servidores PostgreSQL.

Requisitos mínimos de implantação

Uma implantação de serviços de dados habilitada para Azure Arc de tamanho mínimo pode ser considerada como o controlador de dados do Azure Arc mais uma instância gerenciada SQL mais um servidor 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 seus nós Kubernetes. Por exemplo, você pode ter 1 nó com 32 GB de RAM e 4 núcleos ou pode ter 2 nós com 16 GB de RAM e 4 núcleos cada.

Consulte o artigo de configuração de armazenamento para obter detalhes sobre o dimensionamento do armazenamento.

Detalhes de dimensionamento do controlador de dados

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

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

Você pode substituir as configurações padrão para os controldb pods de controle e 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"

Consulte o artigo de configuração de armazenamento para obter detalhes sobre o dimensionamento do armazenamento.

Detalhes de dimensionamento da instância gerenciada SQL

Cada instância gerenciada pelo SQL deve ter os seguintes limites e solicitações mínimas de recursos:

Escalão de serviço	Fins Gerais	Crítico para a Empresa
Pedido de CPU	Mínimo: 1 Máximo: 24 Padrão: 2	Mínimo: 3 Máximo: ilimitado Padrão: 4
Limite de CPU	Mínimo: 1 Máximo: 24 Padrão: 2	Mínimo: 3 Máximo: ilimitado Padrão: 4
Pedido de memória	Mínimo: 2Gi Máximo: 128Gi Predefinição: 4Gi	Mínimo: 2Gi Máximo: ilimitado Predefinição: 4Gi
Limite de memória	Mínimo: 2Gi Máximo: 128Gi Predefinição: 4Gi	Mínimo: 2Gi Máximo: ilimitado Predefinição: 4Gi

Cada pod de instância gerenciada SQL criado tem três contêineres:

Nome do contentor	Pedido à CPU	Pedido de Memória	Limite de CPU	Limite de Memória	Notas
fluentbit	100m	100Mi	Não especificado	Não especificado	As fluentbit solicitações de recursos de contêiner são adicionais às solicitações especificadas para a instância gerenciada SQL.
arc-sqlmi	Usuário especificado ou não especificado.	Usuário especificado ou não especificado.	Usuário especificado ou não especificado.	Usuário especificado ou não especificado.
collectd	Não especificado	Não especificado	Não especificado	Não especificado

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

Detalhes de dimensionamento do servidor PostgreSQL

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

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

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

Nome do contentor	Pedido à CPU	Pedido de Memória	Limite de CPU	Limite de Memória	Notas
fluentbit	100m	100Mi	Não especificado	Não especificado	As fluentbit solicitações de recursos de contêiner são adicionais às solicitações especificadas para o servidor PostgreSQL.
postgres	Usuário especificado ou não especificado.	Usuário especificado ou 256Mi (padrão).	Usuário especificado ou não especificado.	Usuário especificado 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 serviços de dados habilitados para Azure Arc é principalmente uma função do número e tamanho das instâncias de banco de dados. O tamanho geral pode ser difícil de prever com antecedência, sabendo que o número de instâncias pode crescer 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 SQL requer um pod para cada instância. O servidor PostgreSQL cria um pod para cada servidor.

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

Exemplo de cálculo de dimensionamento

Requisitos:

• "SQL1": 1 instância gerenciada SQL com 16 GB de RAM, 4 núcleos
• "SQL2": 1 instância gerenciada SQL com 256 GB de RAM, 16 núcleos
• "Postgres1": 1 servidor PostgreSQL com 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 de RAM
    • 20,5 núcleos
  • Para SQL:
    • 12,25 GB de RAM
    • 4,25 núcleos
  • Para 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 responsável pelo tratamento dos dados
    • 16 GB de RAM
    • 4 cores
  • No total:
    • 300,75 GB de RAM
    • 28,75 núcleos.

Consulte o artigo de configuração de armazenamento para obter detalhes sobre o dimensionamento do armazenamento.

Outras considerações

Lembre-se de 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 tiver 256 GB de RAM e 24 núcleos, não será possível 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:

• Agende eficientemente os pods a serem criados
• Habilitar o dimensionamento elástico
• Suporta atualizações contínuas dos nós do Kubernetes
• Facilita o crescimento a longo prazo sob demanda

Em seus cálculos de dimensionamento, adicione os requisitos de recursos dos pods do sistema Kubernetes e quaisquer outras cargas de trabalho, que podem estar compartilhando capacidade com 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 em qualquer momento. O Kubernetes tenta reprogramar os pods que estavam sendo executados 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 reprogramados 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 agendará esse pod de instância de banco de dados para outro nó do Kubernetes.

Tenha em mente os limites máximos para um tamanho de cluster do Kubernetes.

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