Sizing Guidance

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
• Memory
• Armazenamento

Estes recursos são necessários para:

• O responsável pelo tratamento dos dados
• Instâncias SQL geridas

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

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 pelo SQL.

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 pelo SQL. For this configuration, you need at least 16-GB RAM and 4 cores of available capacity on your Kubernetes cluster. Você deve garantir que cada nó Kubernetes tenha um tamanho mínimo de 8 GB de RAM e 4 núcleos, e que a capacidade total de 16 GB de RAM esteja 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.

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

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.

metricsdc é um daemonset, que é criado em cada um dos nós do Kubernetes no seu cluster. The numbers in the table are per node. 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 o controldb e os pods de controle no arquivo YAML do seu controlador de dados. 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.

Detalhes do dimensionamento da instância SQL gerida

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

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

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

Cumulative sizing

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.

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

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:

• 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 agentes em cada pod utilize 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 cores
  • For SQL:
    • 12.25-GB RAM
    • 4.25 cores

• 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 RAM
    • 24.75 cores
  • Para o responsável pelo tratamento dos dados
    • 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

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 conforme necessário

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.

Your Kubernetes administrator may have set up resource quotas on your namespace/project. Tenha essas cotas em mente ao planejar o tamanho da instância do banco de dados.