Compartilhar via


Configuration Manager o tamanho do site e as diretrizes de desempenho

Aplica-se a: Gerenciador de Configurações (branch atual)

Configuration Manager lidera o setor em escala e desempenho. Outra documentação aborda limites máximos de escala com suporte e diretrizes de hardware para executar sites nos maiores tamanhos de ambiente. Este artigo fornece diretrizes de desempenho suplementar para ambientes de todos os tamanhos. Essas diretrizes podem ajudá-lo a estimar com mais precisão o hardware necessário para implantar Configuration Manager.

Este artigo se concentra no maior colaborador para Configuration Manager gargalos de desempenho: o subsistema de entrada/saída de disco ou IOPS.

  • Apresenta detalhes e resultados de teste focados no IOPS
  • Documentos como reproduzir os testes com seus próprios ambientes e hardware
  • Sugere requisitos de IOPS de disco para vários ambientes de tamanho

Metodologia de teste de desempenho

Você pode implantar Configuration Manager de várias maneiras exclusivas, mas é importante entender algumas variáveis em qualquer discussão de dimensionamento. Uma variável é o intervalo de recursos, como um ciclo de inventário. Outra variável é o número de usuários, implantações de software ou outros objetos que o sistema referencia ou implanta. O teste de desempenho aplica essas variáveis como parte de uma carga. A carga gera objetos a uma taxa típica para clientes corporativos usando implantações de produção em ambientes de tamanhos diferentes.

Observação

Os dados de uso do cliente permitem testar builds de branch atuais com os cenários, configurações e configurações mais comuns para a maioria dos clientes. As recomendações neste artigo são baseadas nessas médias. Suas experiências podem variar de acordo com o tamanho e a configuração do ambiente. Em geral, Configuration Manager requer bom senso quando se trata de objetos e intervalos. Só porque você pode coletar todos os arquivos em um sistema ou definir o intervalo de um ciclo como um minuto, não significa que você deve.

As seções a seguir realçam algumas configurações e configurações de chave a serem usadas ao testar e modelar as necessidades de processamento para grandes empresas. Essas diretrizes ajudam a definir as expectativas básicas de desempenho do sistema para os tamanhos de hardware sugeridos.

Configurações de intervalos de recursos

A maioria dos testes deve usar intervalos padrão para os ciclos de chave no sistema. Por exemplo, o teste de inventário de hardware ocorre uma vez por semana com um arquivo .mof maior que o padrão. Alguns intervalos de recursos recorrentes, especialmente ciclos de inventário de hardware e software, podem ter efeitos significativos nas características de desempenho de um ambiente. Ambientes que permitem intervalos padrão agressivos para coleta de dados precisam de hardware superdimensionado em proporção direta ao aumento da atividade. Por exemplo, digamos que você tenha 25.000 clientes de área de trabalho e queira coletar inventário de hardware duas vezes mais rápido que o intervalo padrão. Comece dimensionando o hardware do site como se tivesse 50.000 clientes.

Objetos

Os testes devem usar a média superior dos objetos que grandes empresas tendem a usar com o sistema. Os valores típicos são milhares de coleções e aplicativos, que são implantados para centenas de milhares de usuários ou sistemas. Os testes devem ser executados simultaneamente em todos os objetos do sistema nesses limites. Muitos clientes usam vários recursos, mas geralmente não usam todos os recursos do produto nesses limites superiores. O teste com todos os recursos do produto ajuda a garantir o melhor desempenho possível em todo o sistema e permite um buffer para recursos que alguns clientes podem usar acima da média.

Cargas

Os testes também devem ser executados em cargas diárias maiores que a média padrão, fazendo simulações que geram demandas de uso de pico no sistema. Um exemplo é simular distribuições de terça-feira de patch, para garantir que o sistema possa retornar dados de conformidade de atualização prontamente durante esses dias de atividade de pico. Outro exemplo é simular a atividade do site durante um surto de malware generalizado, para garantir que a notificação e a resposta oportunas sejam possíveis. Embora os computadores implantados do tamanho recomendado possam ser subutilizados em qualquer dia, situações mais extremas exigem algum buffer de processamento.

Configurações

Execute testes em um intervalo de hardware físico, Hyper-V e Azure, com uma mistura de sistemas operacionais compatíveis e versões SQL Server. Sempre valide os piores casos para a configuração com suporte. Em geral, o Hyper-V e o Azure retornam resultados de desempenho comparáveis ao hardware físico equivalente quando configurados da mesma forma. Os sistemas operacionais do servidor atual tendem a ter um desempenho igual ou melhor do que as versões anteriores do sistema operacional. Embora todas as plataformas com suporte atendam aos requisitos mínimos, geralmente as versões mais recentes de produtos de suporte, como Windows e SQL Server produzem um desempenho ainda melhor.

A maior variação vem das versões SQL Server em uso. Para obter mais informações sobre SQL Server versões, consulte Qual versão do SQL Server devo executar?.

Principais determinantes de desempenho

Você pode testar e medir Configuration Manager desempenho com diferentes tipos de configurações, de diferentes maneiras e em diferentes tamanhos de site. As configurações e objetos a seguir podem afetar drasticamente o desempenho. Considere-os ao testar e modelar o desempenho em seu ambiente.

Cuidado

Embora poucos aspectos do Configuration Manager tenham limites oficiais de interface do usuário ou máximos que impedem o uso excessivo, ir além das diretrizes pode ter efeitos adversos significativos no desempenho de um site. Exceder níveis recomendados ou ignorar as diretrizes de dimensionamento normalmente requer hardware maior e pode tornar seu ambiente inalcançável até reduzir a frequência ou a contagem de vários objetos.

Inventário de hardware

Para testar o desempenho da linha de base, defina a coleção de inventário de hardware como uma vez por semana, com o tamanho padrão do arquivo .mof mais aproximadamente 20% de outras propriedades. Não habilite todas as propriedades e colete apenas as propriedades de que você realmente precisa. Preste atenção especial ao coletar propriedades, como a memória virtual disponível, que sempre serão alteradas a cada ciclo de inventário. A coleta dessas propriedades pode causar uma rotatividade excessiva em cada ciclo de inventário de cada cliente.

Inventário de software

Para testar o desempenho da linha de base, defina a coleção de inventário de software como uma vez por semana, com apenas detalhes do produto . A coleta de muitos arquivos pode colocar uma tensão significativa no subsistema de inventário. Evite especificar filtros que podem acabar coletando milhares de arquivos em muitos clientes, como *.exe ou *.dll.

Coleções

O teste de desempenho da linha de base pode incluir milhares de coleções com diferentes tipos de escopo, tamanho, complexidade e configurações de atualização. O desempenho do site não é uma função direta do grande número de coleções em um site. O desempenho também é um produto cruzado da complexidade de consulta das coleções, atualizações completas e incrementais e frequência de alterações, dependências entre coleções e número de clientes nas coleções.

Sempre que possível, minimize coleções que tenham consultas de regra dinâmica caras ou complicadas. Para coleções que exigem esses tipos de regras, defina intervalos de atualização e tempos de atualização apropriados para minimizar o efeito da reavaliação de coleção no sistema. Por exemplo, atualize à meia-noite em vez das 8h.

Habilitar atualizações incrementais em coleções garante atualizações rápidas e oportunas para a associação de coleção. Mas, embora as atualizações incrementais sejam eficientes, elas ainda colocam carga no sistema. Balancee a frequência de alteração esperada com a necessidade de atualizações quase em tempo real sobre a associação. Por exemplo, digamos que você espera uma forte rotatividade nos membros da coleção, mas não exige atualizações de associação quase em tempo real. Ele é mais eficiente e produz menos carga no sistema para atualizar a coleção com uma atualização completa agendada em algum intervalo do que habilitar atualizações incrementais.

Ao habilitar atualizações incrementais, reduza todas as atualizações completas agendadas nas mesmas coleções. Eles são apenas um método de avaliação de backup, já que as atualizações incrementais devem manter sua associação de coleção atualizada quase em tempo real. As melhores práticas para coleções recomendam um número máximo de coleções totais para atualizações incrementais, mas, como o artigo aponta, sua experiência pode variar com base em muitos fatores.

Coleções com apenas regras de associação direta e com uma coleção limitante que não está fazendo atualizações incrementais não precisam de atualizações completas agendadas. Desabilite agendamentos de atualização para esses tipos de coleções para evitar carga desnecessária no sistema. Se a coleção de limitação usar atualizações incrementais, coleções com apenas regras de associação direta podem não refletir as atualizações de associação por até 24 horas ou até que uma atualização agendada ocorra.

Embora não seja uma prática recomendada, algumas organizações criam centenas ou até milhares de coleções como parte de vários processos de negócios. Se você usar a automação para criar coleções, é importante habilitar as atualizações incrementais necessárias corretamente. Minimize e espalhe todos os agendamentos de atualização completos para evitar pontos quentes de avaliação de coleção durante um único período de tempo. Estabeleça um processo de preparação regular para excluir coleções não utilizados, especialmente se você criar automaticamente coleções que você não precisa mais depois de algum tempo.

Lembre-se de que Configuration Manager cria políticas para todos os objetos em suas coleções quando você direciona tarefas como implantações para eles. As alterações de associação, por meio de atualizações de atualização agendadas ou incrementais, podem criar muito mais trabalho para todo o sistema. Os builds de branch atuais mais recentes têm otimizações de políticas especiais para as coleções Todos os Sistemas e Todos os Usuários. Ao direcionar toda a sua empresa, use as coleções internas em vez de um clone dessas coleções internas.

Para investigar ainda mais o desempenho da coleção, exiba a avaliação da coleção no console. Para obter mais informações, consulte Como exibir a avaliação da coleção.

Métodos de descoberta

Para testes de desempenho de linha de base, execute métodos de descoberta baseados em servidor uma vez por semana, permitindo a descoberta delta conforme apropriado para manter os dados frescos durante a semana. Os testes devem descobrir uma quantidade de objeto proporcional ao tamanho simulado da empresa. O teste de linha de base de desempenho para descoberta de pulsação também deve ser executado uma vez por semana.

Dados de descoberta são dados globais. Um problema comum relacionado ao desempenho é configurar incorretamente métodos de descoberta baseados em servidor em uma hierarquia, causando a descoberta duplicada dos mesmos recursos de vários sites primários. Configure cuidadosamente os métodos de descoberta para otimizar a comunicação com o serviço de destino, como controladores de domínio do Active Directory, evitando a duplicação do mesmo escopo de descoberta em vários sites primários.

Diretrizes de dimensionamento geral

Com base na metodologia de teste de desempenho anterior, a tabela a seguir fornece diretrizes gerais mínimas de requisito de hardware para números específicos de clientes gerenciados. Esses valores devem permitir que a maioria dos clientes com o número especificado de clientes processe objetos rápido o suficiente para administrar o site especificado. O poder de computação continua a diminuir de preço a cada ano, e alguns dos requisitos abaixo são pequenos para configurações modernas de hardware do servidor. O hardware que excede as diretrizes a seguir aumenta proporcionalmente o desempenho para sites que exigem mais poder de processamento ou têm padrões especiais de uso do produto.

Clientes da área de trabalho Tipo/função do site Cores Observação 1 Memória (GB) SQL Server alocação de memória Nota 2 IOPS: Caixas de entrada Observação 3 IOPS: SQL Server Nota 3 Espaço de armazenamento necessário (GB) Nota 4
25k Principal ou CAS com função de site de banco de dados no mesmo servidor 6 24 65% 600 1700 350
25k Primário ou CAS 4 8 600 100
SQL Server remoto 4 16 70% 1700 250
50k Principal ou CAS com função de site de banco de dados no mesmo servidor 8 32 70% 1200 2800 600
50k Primário ou CAS 4 8 1200 200
SQL Server remoto 8 24 70% 2800 400
100 mil Principal ou CAS com função de site de banco de dados no mesmo servidor 12 64 70% 1200 5000 1100
100 mil Primário ou CAS 6 12 1200 300
SQL Server remoto 12 48 80% 5000 800
150k Principal ou CAS com função de site de banco de dados no mesmo servidor 16 96 70% 1800 7400 1600
150k Primário ou CAS 8 16 1800 400
SQL Server remoto 16 72 90% 7400 1200
700k CAS com função de site de banco de dados no mesmo servidor 20+ 128+ 80% 1800+ 9000+ 5000+
700k Cas 8+ 16+ 1800+ 500+
SQL Server remoto 16+ 96+ 90% 9000+ 4500+
5k Site Secundário 4 8 500 - 200
15k Site Secundário 8 16 500 - 300

Anotações sobre diretrizes de dimensionamento geral

Observação 1: Núcleos

Configuration Manager executa muitos processos simultâneos, portanto, precisa de um determinado número mínimo de núcleos de CPU para vários tamanhos de site. Embora os núcleos obtenham mais velocidade a cada ano, é importante garantir que um determinado número mínimo de núcleos funcione em paralelo. Em geral, qualquer CPU no nível do servidor produzida após 2015 atende às necessidades básicas de desempenho para os núcleos especificados na tabela. Configuration Manager aproveita outros núcleos além das recomendações. Depois de ter os núcleos sugeridos mínimos, priorize o investimento em recursos da CPU para aumentar a velocidade dos núcleos existentes. Não adicione núcleos mais lentos. Por exemplo, Configuration Manager tem melhor desempenho em tarefas de processamento de chaves com 16 núcleos rápidos do que com 24 núcleos mais lentos. Esse desempenho pressupõe que haja recursos suficientes do sistema, como o IOPS de disco.

A relação entre núcleos e memória também é importante. Em geral, ter menos de 3 a 4 GB de RAM por núcleo reduz a capacidade total de processamento em seus SQL Servers. Você precisa de mais RAM por núcleo quando SQL Server é colocado com os componentes do servidor do site.

Observação

Todos os testes definem planos de energia de máquina para permitir o máximo de consumo e desempenho de energia da CPU.

Observação 2: alocação de memória SQL Server

Use esse valor para configurar a memória máxima do servidor (em MB) nas propriedades do SQL Server. É o percentual da quantidade total de memória disponível no servidor.

Não configure os valores mínimos e máximos da mesma forma. Essa diretriz é especificamente para a memória máxima que você deve permitir SQL Server alocar.

Observação 3: IOPS: Caixas de entrada e IOPS: SQL

Esses valores referem-se às necessidades do IOPS para as unidades lógicas Configuration Manager e SQL Server. A coluna IOPS: Inboxes mostra os requisitos do IOPS para a unidade lógica com os diretórios de caixa de entrada Configuration Manager. A coluna IOPS: SQL mostra as necessidades totais de IOPS para a unidade lógica que vários arquivos SQL Server usam. Essas colunas são diferentes porque as duas unidades devem ter formatação diferente. Para obter mais informações e exemplos sobre as configurações sugeridas SQL Server disco e as melhores práticas de arquivo, incluindo detalhes sobre como dividir arquivos em vários volumes, consulte o dimensionamento do site e as perguntas frequentes sobre desempenho.

Ambas as colunas IOPS usam dados da ferramenta padrão do setor, Diskspd. Consulte Como medir o desempenho do disco para obter instruções sobre como duplicar essas medidas. Em geral, depois de atender aos requisitos básicos de CPU e memória, o subsistema de armazenamento terá o maior efeito no desempenho do site e as melhorias aqui darão mais retorno sobre o investimento.

Observação 4: Espaço de armazenamento necessário

Esses valores reais podem ser diferentes de outras recomendações documentadas. Fornecemos esses números apenas como uma diretriz geral; os requisitos individuais podem variar amplamente. Planeje cuidadosamente as necessidades de espaço em disco antes da instalação do site. Suponha que alguma quantidade desse armazenamento permaneça como espaço livre em disco na maior parte do tempo. Você pode usar esse espaço de buffer em um cenário de recuperação ou para cenários de atualização que precisam de espaço livre em disco para a expansão do pacote de instalação. Seu site pode exigir mais armazenamento para grandes quantidades de coleta de dados, períodos mais longos de retenção de dados e grandes quantidades de conteúdo de distribuição de software. Você também pode armazenar esses itens em volumes separados e de baixa taxa de transferência.

Como medir o desempenho do disco

Você pode usar a ferramenta padrão do setor Diskspd para fornecer sugestões padronizadas para o IOPS que vários ambientes de Configuration Manager exigem. Embora não seja exaustivo, as seguintes etapas de teste e linhas de comando fornecem uma maneira simples e reprodutível de estimar a taxa de transferência do subsistema de disco dos servidores. Você pode comparar seus resultados com o IOPS mínimo recomendado na tabela de diretrizes de dimensionamento geral .

Para obter resultados de teste de diferentes tipos de configurações de hardware em ambientes de laboratório, consulte Exemplo de configurações de disco. Você pode usar os dados para um ponto de partida bruto ao projetar o subsistema de armazenamento para um novo ambiente do zero.

Como testar o IOPS de disco

  1. Baixe o utilitário Diskspd.

  2. Verifique se você tem pelo menos 100 GB de espaço em disco gratuito. Desabilite todos os aplicativos que possam interferir ou causar carga extra no disco, como a verificação ativa de antivírus do diretório, SQL ou SMSExec.

  3. Execute Diskspd de um prompt de comando elevado.

    Execute a ferramenta duas vezes em sequência para o volume que você deseja testar. O primeiro teste com tamanho de 64k com operações de gravação aleatórias por um minuto. Esse teste valida o carregamento de cache do controlador e a alocação de espaço em disco, caso o volume esteja se expandindo dinamicamente. Descarte os resultados do primeiro teste. O segundo teste deve seguir imediatamente o primeiro teste e fazer a mesma carga por cinco minutos.

    Por exemplo, use as seguintes linhas de comando específicas para testar o G: volume.

    DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d60 -h -L G:\\test\testfile.dat
    
    del G:\\test\testfile.dat
    
    DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d300 -h -L G:\\test\testfile.dat
    
  4. Examine a saída do segundo teste para localizar o IOPS total na coluna E/S por s . No exemplo a seguir, o IOPS total é 3929.18.

    Total IO
    | thread |  bytes      |  I/Os   |  MB/s  | I/O per s | AvgLat | LatStdDev |
    |--------|-------------|---------|--------|-----------|--------|-----------|
    |   1    |  9651814400 |  147275 |  30.68 |    490.92 | 16.294 | 10.210    |
    |   2    |  9676652544 |  147654 |  30.76 |    492.18 | 16.252 |  9.998    |
    |   3    |  9638248448 |  147068 |  30.64 |    490.23 | 16.317 | 10.295    |
    |   4    |  9686089728 |  147798 |  30.79 |    492.66 | 16.236 | 10.072    |
    |   5    |  9590931456 |  146346 |  30.49 |    487.82 | 16.398 | 10.384    |
    |   6    |  9677242368 |  147663 |  30.76 |    492.21 | 16.251 | 10.067    |
    |   7    |  9637330944 |  147054 |  30.64 |    490.18 | 16.319 | 10.249    |
    |   8    |  9692577792 |  147897 |  30.81 |    492.99 | 16.225 | 10.125    |
    | Total: | 77250887680 | 1178755 | 245.57 |   3929.18 | 16.286 | 10.176    |
    

Configurações de disco de exemplo

As tabelas a seguir mostram os resultados da execução das etapas de teste em Como medir o desempenho do disco com várias configurações de laboratório de teste. Use esses dados para um ponto de partida bruto ao projetar o subsistema de armazenamento para um novo ambiente do zero.

Máquinas físicas e Hyper-V

O hardware está sempre melhorando. Espere que as novas gerações de hardware e diferentes combinações de hardware, como SSDs e SANs, excedam o desempenho indicado abaixo. Esses resultados são um ponto de partida básico a ser considerado ao projetar um servidor ou discutir com seu fornecedor de hardware.

A tabela a seguir mostra os resultados do teste em vários subsistemas de disco, incluindo discos rígidos baseados em fuso e SSD, em várias configurações de laboratório de teste. Todas as configurações formatizam os discos com clusters de 64k e os anexam a um controlador de disco de classe empresarial. Além da contagem de discos da matriz RAID, cada um deles tem pelo menos um disco sobressalente.

Tipo de disco Contagem de discos, sem incluir +1 disco sobressalente RAID IOPS medido
SAS de 15k 2 1 620
SAS de 15k 4 10 1206
SAS de 15k 6 10 1751
SAS de 15k 8 10 2322
SAS de 15k 10 10 2882
SAS de 15k 12 10 3476
SAS de 15k 16 10 4236
SAS de 15k 20 10 5148
SAS de 15k 30 10 7398
SAS de 15k 40 10 9913
SSD SATA 2 1 3300
SSD SATA 4 10 5542
SSD SATA 6 10 7201
SSD SAS 2 1 7539
SSD SAS 4 10 14346
SSD SAS 6 10 15607

A tabela a seguir lista os dispositivos específicos usados neste exemplo. Essas informações não são uma recomendação para nenhum modelo de hardware ou fabricante específico.

Tipo de disco Modelo Controlador RAID Memória e configuração de cache
15k RPM SAS HD HP EH0300JDYTH Smart Array P822 2 GB, 20% Leitura /80% Gravação
SSD SATA ATA MK0200GCTYV Smart Array P420i 1 GB, 20% Leitura /80% Gravação
SSD SAS HP MO0800 JEFPB Smart Array P420i 1 GB, 20% Leitura /80% Gravação

Desempenho de computador e disco do Azure

O desempenho do disco do Azure depende de vários fatores, como o tamanho da VM do Azure e o número e o tipo de discos que ele usa. O Azure também está constantemente adicionando novos tipos de máquina e velocidades de disco diferentes do gráfico a seguir. Para obter mais informações sobre Configuration Manager em execução no Azure e informações adicionais sobre como entender a E/S do disco no Azure, consulte Configuration Manager em perguntas frequentes do Azure.

Todos os discos são formatados tamanho de cluster NTFS 64k e linhas com mais de um disco são configuradas como volumes listrados por meio do utilitário de Gerenciamento de Disco do Windows.

Azure VM Disco do Azure Contagem de discos Espaço disponível IOPS medido Fator limitante
DS2/DS11 P20 1 512 GB 965 Tamanho da VM do Azure
DS2/DS11 P20 2 1024 GB 996 Tamanho da VM do Azure
DS2/DS11 P30 1 1024 GB 996 Tamanho da VM do Azure
DS2/DS11 P30 2 2048 GB 996 Tamanho da VM do Azure
DS3/DS12/F4S P20 1 512 GB 1994 Tamanho da VM do Azure
DS3/DS12/F4S P20 2 1024 GB 1992 Tamanho da VM do Azure
DS3/DS12/F4S P30 1 1024 GB 1993 Tamanho da VM do Azure
DS3/DS12/F4S P30 2 2048 GB 1992 Tamanho da VM do Azure
DS4/DS13/F8S P20 1 512 GB 2334 Disco P20
DS4/DS13/F8S P20 2 1024 GB 3984 Tamanho da VM do Azure
DS4/DS13/F8S P20 3 1536 GB 3984 Tamanho da VM do Azure
DS4/DS13/F8S P30 1 1024 GB 3112 Disco P30
DS4/DS13/F8S P30 2 2048 GB 3984 Tamanho da VM do Azure
DS4/DS13/F8S P30 3 3072 GB 3996 Tamanho da VM do Azure
DS5/DS14/F16S P20 1 512 GB 2335 Disco P20
DS5/DS14/F16S P20 2 1024 GB 4639 Disco P20
DS5/DS14/F16S P20 3 1536 GB 6913 Disco P20
DS5/DS14/F16S P20 4 2048 GB 7966 Tamanho da VM do Azure
DS5/DS14/F16S P30 1 1024 GB 3112 Disco P30
DS5/DS14/F16S P30 2 2048 GB 6182 Disco P30
DS5/DS14/F16S P30 3 3072 GB 7963 Tamanho da VM do Azure
DS5/DS14/F16S P30 4 4096 GB 7968 Tamanho da VM do Azure
DS15 P30 1 1024 GB 3113 Disco P30
DS15 P30 2 2048 GB 6184 Disco P30
DS15 P30 3 3072 GB 9225 Disco P30
DS15 P30 4 4096 GB 10200 Tamanho da VM do Azure

Para obter mais informações sobre os discos disponíveis no momento, consulte Selecionar um tipo de disco para VMs IaaS do Azure.

Confira também