Diretrizes de tamanho e desempenho do gestor de configuração

Artigo
08/14/2021

Aplica-se a: Configuration Manager (ramo atual)

O Gestor de Configuração lidera a indústria em escala e desempenho. Outra documentação abrange limites máximos de escala suportados e diretrizes de hardware para executar sites nos maiores tamanhos de ambiente. Este artigo oferece orientação de desempenho suplementar para ambientes de todos os tamanhos. Esta orientação pode ajudá-lo a estimar com mais precisão o hardware necessário para implementar o Gestor de Configuração.

Este artigo centra-se no maior contribuinte para os estrangulamentos de desempenho do Gestor de Configuração: o subsistema de entrada/saída do disco ou iOPS.

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

Metodologia de teste de desempenho

Pode implementar o Gestor de Configurações de muitas formas únicas, mas é importante compreender algumas variáveis em quaisquer discussões de dimensionamento. Uma variável é o intervalo de características, como um ciclo de inventário. Outra variável é o número de utilizadores, implementações de software ou outros objetos que o sistema referencia ou implementa. Os testes de desempenho aplicam estas variáveis como parte de uma carga. A carga gera objetos a um ritmo típico para clientes empresariais que usam implementações de produção em diferentes ambientes de tamanho.

Nota

Os dados de utilização do cliente permitem testar as construções de filiais atuais com os cenários, configurações e configurações mais comuns para a maioria dos clientes. As recomendações deste artigo baseiam-se nestas médias. As suas experiências podem variar em função do tamanho e configuração do seu ambiente. Em geral, o Gestor de Configuração requer bom senso quando se trata de objetos e intervalos. Só porque pode recolher todos os ficheiros de um sistema, ou definir o intervalo para um ciclo para um minuto, não significa que deva.

As secções seguintes destacam algumas definições e configurações chave a utilizar quando as necessidades de processamento e de modelação para as grandes empresas. Estas diretrizes ajudam a definir expectativas básicas de desempenho do sistema para os tamanhos de hardware sugeridos.

Definições de intervalos de recurso

A maioria dos testes deve utilizar intervalos predefinidos para os ciclos de chaves no sistema. Por exemplo, os testes de inventário de hardware ocorrem uma vez por semana com um ficheiro .mof maior do que o padrão. Alguns intervalos de funcionalidades 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 a recolha de dados precisam de hardware de grandes dimensões em proporção direta ao aumento da atividade. Por exemplo, digamos que tem 25.000 clientes de desktop e que quer recolher o inventário de hardware duas vezes mais rápido do que o intervalo padrão. Comece por dimensionar o hardware do seu site como se tivesse 50.000 clientes.

Objetos

Os testes devem utilizar a média superior dos objetos que as grandes empresas tendem a utilizar com o sistema. Valores típicos são milhares de coleções e aplicações, que são implementadas para centenas de milhares de utilizadores ou sistemas. Os testes devem ser efetuados simultaneamente em todos os objetos do sistema nestes limites. Muitos clientes usam várias funcionalidades, mas geralmente não usam todas as funcionalidades do produto nestes limites superiores. Testar com todas as funcionalidades do produto ajuda a garantir o melhor desempenho possível em todo o sistema, e permite um tampão para funcionalidades que alguns clientes podem usar acima da média.

Cargas

Os testes também devem ser executados em cargas diárias superiores às médias padrão, fazendo simulações que geram exigências de utilização máxima no sistema. Um exemplo é simular os lançamentos de Patch Tuesday, para garantir que o sistema pode devolver os dados de conformidade da atualização rapidamente durante estes dias de pico de atividade. Outro exemplo é simular a atividade do site durante um surto de malware generalizado, para garantir que a notificação e resposta oportunas são possíveis. Embora as máquinas implantadas do tamanho recomendado possam ser subusidas em qualquer dia, situações mais extremas requerem algum tampão de processamento.

Configurações

Executar testes numa gama de hardware físico, Hiper-V e Azure, com uma mistura de sistemas operativos suportados e versões SQL Server. Valide sempre os piores casos para a configuração suportada. Em geral, o retorno do Hyper-V e do Azure resulta em resultados de desempenho comparáveis a hardware físico equivalente quando configurados da mesma forma. Os sistemas operativos atuais do servidor tendem a ter um desempenho igual ou melhor do que as versões os anteriores. Apesar de todas as plataformas suportadas cumprirem os requisitos mínimos, normalmente as versões mais recentes de suporte de produtos como Windows e SQL Server produzir ainda melhor desempenho.

A maior variação provém das versões SQL Server em uso. Para obter mais informações sobre versões SQL Server, veja que versão de SQL Server devo executar?

Determinantes de desempenho chave

Pode testar e medir o desempenho do Gestor de Configuração com diferentes tipos de configurações, de diferentes formas e em diferentes tamanhos do site. As seguintes configurações e objetos podem afetar drasticamente o desempenho. Não se esqueça de considerá-los ao testar e modelar o desempenho no seu ambiente.

Atenção

Embora poucos aspetos do Gestor de Configuração tenham limites oficiais de segurança ou interface de utilizador que impeçam o uso excessivo, ir além das diretrizes pode ter efeitos adversos significativos no desempenho de um site. Exceder os níveis recomendados ou ignorar a orientação de dimensionamento normalmente requer hardware maior, e pode tornar o 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, desave a coleção de inventário de hardware para uma vez por semana, com o tamanho padrão .mof de ficheiros mais aproximadamente 20% de outras propriedades. Não ative todas as propriedades e recolha apenas propriedades que realmente precisa. Preste especial atenção na recolha de propriedades, como a memória virtual disponível, que mudará sempre a cada ciclo de inventário. A recolha destas propriedades pode causar uma agitação excessiva em cada ciclo de inventário de cada cliente.

Inventário de software

Para testar o desempenho da linha de base, desaprote a recolha de inventário de software para uma vez por semana, com apenas detalhes do produto. A recolha de muitos ficheiros pode colocar uma pressão significativa no subsistema de inventário. Evite especificar filtros que podem acabar por recolher milhares de ficheiros em muitos clientes, tais como *.exe *.dll ou .

Coleções

Os testes de desempenho de base podem incluir vários milhares de coleções com diferentes tipos de âmbito, tamanho, complexidade e configurações de atualização. O desempenho do site não é uma função direta do número absoluto de coleções num site. O desempenho é também um produto transversal da complexidade da consulta das coleções, atualizações completas e incrementais e frequência de mudança, dependências entre coleções e número de clientes nas coleções.

Sempre que possível, minimize as coleções que tenham consultas de regras dinâmicas caras ou complicadas. Para coleções que exijam este tipo de regras, desembarave intervalos de atualização adequados e tempos de atualização para minimizar o efeito da reavaliação da recolha no sistema. Por exemplo, atualize à meia-noite em vez de 8:00 da manhã.

Ativar atualizações incrementais nas coleções garante atualizações rápidas e atempadamente para a adesão à recolha. Mas, apesar de as atualizações incrementais serem eficientes, ainda colocam carga no sistema. Equilibre a frequência de alteração que espera com a necessidade de atualizações quase em tempo real sobre a adesão. Por exemplo, digamos que espera-se uma forte agitação nos membros da recolha, mas não precisa de atualizações de membros em tempo real. É mais eficiente e produz menos carga no sistema para atualizar a coleção com uma atualização completa programada em algum intervalo, do que para ativar atualizações incrementais.

Quando ativar atualizações incrementais, reduza quaisquer atualizações completas programadas sobre as mesmas coleções. São apenas um método de avaliação de backup, uma vez que as atualizações incrementais devem manter a sua filiação de cobrança atualizada 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, a sua experiência pode variar com base em muitos fatores.

As coleções apenas com regras de adesão diretas e com uma coleção limitante que não está a fazer atualizações incrementais não precisam de atualizações completas programadas. Desative os horários de atualização deste tipo de coleções para evitar cargas desnecessárias no sistema. Se a recolha limitativa utilizar atualizações incrementais, as cobranças com apenas regras de adesão diretas podem não refletir atualizações de adesão até 24 horas, ou até que uma atualização programada ocorra.

Embora não seja uma boa prática, algumas organizações criam centenas ou mesmo milhares de coleções como parte de vários processos de negócio. Se utilizar a automatização para criar coleções, é importante ativar corretamente quaisquer atualizações incrementais necessárias. Minimize e divulgue todos os horários de atualização completos para evitar pontos quentes de avaliação da recolha durante um único período de tempo. Estabeleça um processo de preparação regular para eliminar coleções não habituadas, especialmente se criar automaticamente coleções que já não necessita após algum tempo.

Lembre-se que o Gestor de Configuração cria políticas para todos os objetos das suas coleções quando direciona tarefas como implementações para as mesmas. As mudanças de adesão, quer através de atualizações programadas ou incrementais, podem criar muito mais trabalho para todo o sistema. As mais recentes construções de sucursais têm otimizações de políticas especiais para as coleções de Todos os Sistemas e Todos os Utilizadores. Ao direcionar toda a sua empresa, use as coleções incorporadas em vez de um clone destas coleções incorporadas.

Para investigar o desempenho da coleção ainda mais profunda, veja a avaliação da coleção na consola. Para mais informações, consulte Como visualizar a avaliação da recolha.

Métodos de descoberta

Para testes de desempenho de base, executar 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 da empresa simulada. O teste de base de desempenho para a descoberta do batimento cardíaco também deve ser executado uma vez por semana.

Os dados da descoberta são dados globais. Um problema comum relacionado com o desempenho é configurar mal métodos de descoberta baseados em servidores numa hierarquia, causando a descoberta duplicada dos mesmos recursos de vários locais primários. Configurar cuidadosamente os métodos de descoberta para otimizar a comunicação com o serviço alvo, como controladores de domínio do Ative Directory, evitando simultaneamente a duplicação do mesmo âmbito de descoberta em vários locais primários.

Diretrizes gerais de dimensionamento

Com base na metodologia anterior de teste de desempenho,a tabela seguinte fornece orientações gerais mínimas de requisitos de hardware para números específicos de clientes geridos. Estes valores devem permitir que a maioria dos clientes com o número especificado de clientes processem objetos rapidamente o suficiente para administrar o site especificado. O poder de computação continua a diminuir de preço todos os anos, e alguns dos requisitos abaixo são pequenos para configurações modernas de hardware de servidor. Hardware que excede as seguintes diretrizes proporcionalmente aumenta o desempenho para sites que requerem mais poder de processamento, ou têm padrões especiais de utilização do produto.

Clientes de desktop	Tipo/função do site	Notas ^{de Núcleos 1}	Memória (GB)	SQL Server atribuição da memória ^{Nota 2}	IOPS: Caixas de entrada ^{Nota 3}	IOPS: SQL Server ^{Nota 3}	Armazenamento espaço necessário (GB) ^{Nota 4}
25k	Primário ou CAS com papel do site de base 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	Primário ou CAS com papel do site de base 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

100k	Primário ou CAS com papel do site de base de dados no mesmo servidor	12	64	70%	1200	5000	1100
100k	Primário ou CAS	6	12		1200		300
	SQL Server remoto	12	48	80%		5000	800

150k	Primário ou CAS com papel do site de base 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 papel do site de base de dados no mesmo servidor	Mais de 20	128+	80%	1800+	9000+	5000+
700k	CAS	8+	16+		1800+		500+
	SQL Server remoto	16+	96+	90%		9000+	4500+

5k	Sítio Secundário	4	8		500	-	200
15k	Sítio Secundário	8	16		500	-	300

Notas sobre orientações gerais de dimensionamento

Nota 1: Núcleos

O Gestor de Configuração executa muitos processos simultâneos, por isso precisa de um certo número mínimo de núcleos de CPU para vários tamanhos do site. Enquanto os núcleos são mais rápidos a cada ano, é importante garantir que um certo número mínimo de núcleos funcione em paralelo. Em geral, qualquer CPU de nível de servidor produzido após 2015 satisfaz as necessidades básicas de desempenho dos núcleos especificados na tabela. O Gestor de Configuração tira partido de outros núcleos para além das recomendações. Uma vez que tenha os núcleos mínimos sugeridos, dê prioridade ao investimento em recursos da CPU para aumentar a velocidade dos núcleos existentes. Não adicione mais, mais núcleos mais lentos. Por exemplo, o Gestor de Configuração tem um melhor desempenho em tarefas de processamento de chaves com 16 núcleos rápidos do que com 24 núcleos mais lentos. Este desempenho pressupõe que existem recursos suficientes do sistema, como o IOPS do disco.

A relação entre os núcleos e a memória também é importante. Em geral, ter menos de 3-4 GB de RAM por núcleo reduz a capacidade total de processamento nos seus servidores SQL. Precisa de mais RAM por núcleo quando SQL Server estiver consigo com os componentes do servidor do site.

Nota

Todos os testes definem planos de potência da máquina para permitir o consumo máximo de energia e desempenho de energia cpu.

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

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

Não configuure os valores mínimos e máximos iguais. Esta orientação é especificamente para a memória máxima que deve permitir SQL Server atribuir.

Nota 3: IOPS: Caixas de entrada e IOPS: SQL

Estes valores referem-se às necessidades do IOPS para o Gestor de Configuração e SQL Server unidades lógicas. A coluna IOPS: Inboxes mostra os requisitos do IOPS para a unidade lógica com os diretórios de caixa de entrada do Gestor de Configuração. A coluna IOPS: SQL mostra as necessidades totais de IOPS para a unidade lógica(s) que vários ficheiros SQL Server usam. Estas colunas são diferentes porque as duas unidades devem ter formatação diferente. Para obter mais informações e exemplos sobre configurações de discos SQL Server sugeridas e as melhores práticas de ficheiros, incluindo detalhes sobre a divisão de ficheiros em vários volumes, consulte o tamanho do Site e o desempenho faQ.

Ambas as colunas IOPS utilizam dados da ferramenta padrão da indústria, Diskspd. Consulte como medir o desempenho do disco para obter instruções sobre a duplicação destas medições. Em geral, uma vez que você satisfaz os requisitos básicos de CPU e memória, o subsistema de armazenamento tem o maior impacto no desempenho do site, e as melhorias aqui darão o maior retorno sobre o investimento.

Nota 4: Armazenamento espaço necessário

Estes valores do mundo real podem diferir de outras recomendações documentadas. Fornecemos estes números apenas como uma orientação geral; os requisitos individuais podem variar muito. Planeie cuidadosamente as necessidades de espaço do disco antes da instalação do local. Suponha que alguma quantidade deste armazenamento permanece como espaço livre em disco a maior parte do tempo. Pode utilizar este espaço tampão num cenário de recuperação ou para atualização de cenários que necessitem de espaço em disco gratuito para a expansão do pacote de configuração. O seu site pode necessitar de mais armazenamento para grandes quantidades de recolha de dados, períodos mais longos de retenção de dados e grandes quantidades de conteúdo de distribuição de software. Também pode armazenar estes itens em volumes separados e de menor produção.

Como medir o desempenho do disco

Pode utilizar a ferramenta padrão da indústria Diskspd para fornecer sugestões padronizadas para o IOPS que os ambientes de várias dimensões do Gestor de Configuração exigem. Embora não exaustivas, as seguintes etapas de teste e linhas de comando fornecem uma forma simples e reprodutível de estimar o subsistema do disco dos seus servidores. Pode comparar os seus resultados com o IOPS recomendado no quadro de diretrizes de dimensionamento geral.

Para obter resultados de testes de diferentes tipos de configurações de hardware em ambientes de laboratório, consulte as configurações do disco Exemplo. Pode utilizar os dados para um ponto de partida difícil ao conceber o subsistema de armazenamento para um novo ambiente de raiz.

Como testar o IOPS do disco

Descarregue o utilitário Diskspd.
Certifique-se de que tem pelo menos 100 GB de espaço em disco livre. Desative quaisquer aplicações que possam interferir ou causar carga extra no disco, como a digitalização antivírus ativa do diretório, SQL ou SMSExec.
Executar Diskspd a partir de um pedido de comando elevado.

Executar a ferramenta duas vezes em sequência para o volume que pretende testar. O primeiro teste com tamanho 64k com operações de escrita aleatórias durante um minuto. Este teste valida a carga de cache do controlador e a atribuição de espaço em disco, caso o volume esteja a expandir-se dinamicamente. Elimine os resultados do primeiro teste. O segundo teste deve seguir imediatamente o primeiro teste e fazer a mesma carga durante cinco minutos.

Por exemplo, utilize 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
```

Reveja a saída do segundo teste para encontrar o IOPS total na coluna I/O por s. No exemplo seguinte, o total de IOPS é de 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 discos de exemplo

As tabelas que se seguem mostram os resultados da execução dos passos de teste em Como medir o desempenho do disco com várias configurações de laboratório de teste. Utilize estes dados para um ponto de partida difícil ao conceber o subsistema de armazenamento para um novo ambiente de raiz.

Máquinas físicas e Hiper-V

O hardware está sempre a melhorar. Espere que as gerações mais recentes de hardware e diferentes combinações de hardware, como SSDs e SANs, excedam o desempenho indicado abaixo. Estes resultados são um ponto de partida básico a ter em conta ao desenhar um servidor ou discutir com o seu fornecedor de hardware.

A tabela seguinte mostra os resultados dos testes em vários subsistemas de disco, incluindo discos de eixo e discos rígidos baseados em SSD, em várias configurações de laboratório de teste. Todas as configurações formatam os discos com clusters de 64k e fixam-nos a um controlador de disco de classe empresarial. Além da contagem de discos raid, cada um tem pelo menos um disco sobressalente.

Tipo de disco	Contagem de discos, não incluindo +1 disco sobressalente	RAID	IOPS medido
15k SAS	2	1	620
15k SAS	4	10	1206
15k SAS	6	10	1751
15k SAS	8	10	2322
15k SAS	10	10	2882
15k SAS	12	10	3476
15k SAS	16	10	4236
15k SAS	20	10	5148
15k SAS	30	10	7398
15k SAS	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 que se segue lista os dispositivos específicos utilizados neste exemplo. Esta informação não é uma recomendação para qualquer modelo ou fabricante de hardware específico.

Tipo de disco	Modelação	Controlador RAID	Cache memória e configuração
15k RPM SAS HD	HP EH0300JDYTH	Matriz Inteligente P822	2 GB, 20% Ler / 80% Escrever
SSD SATA	ATA MK0200GCTYV	Matriz Inteligente P420i	1 GB, 20% Ler / 80% Escrever
SSD SAS	HP MO0800 JEFPB	Matriz Inteligente P420i	1 GB, 20% Ler / 80% Escrever

Desempenho da máquina azul e do disco

O desempenho do disco azul depende de vários fatores, como o tamanho do VM Azure, e o número e tipo de discos que utiliza. O Azure também está constantemente a adicionar novos tipos de máquinas e velocidades de disco que são diferentes do gráfico seguinte. Para obter mais informações sobre o Gestor de Configuração em execução no Azure, e informações adicionais sobre a compreensão do disco I/O no Azure, consulte o Gestor de Configuração no Azure perguntas frequentemente feitas.

Todos os discos são formatados ntfS 64k cluster size, e linhas com mais de um disco são configurados como volumes listrados através do utilitário Windows De Gestão de Discos.

VM do Azure	Disco azul	Contagem de discos	Espaço disponível	IOPS medido	Fator de limitação
DS2/DS11	P20	1	512 GB	965	Tamanho Azure VM
DS2/DS11	P20	2	1024 GB	996	Tamanho Azure VM
DS2/DS11	P30	1	1024 GB	996	Tamanho Azure VM
DS2/DS11	P30	2	2048 GB	996	Tamanho Azure VM
DS3/DS12/F4S	P20	1	512 GB	1994	Tamanho Azure VM
DS3/DS12/F4S	P20	2	1024 GB	1992	Tamanho Azure VM
DS3/DS12/F4S	P30	1	1024 GB	1993	Tamanho Azure VM
DS3/DS12/F4S	P30	2	2048 GB	1992	Tamanho Azure VM
DS4/DS13/F8S	P20	1	512 GB	2334	Disco P20
DS4/DS13/F8S	P20	2	1024 GB	3984	Tamanho Azure VM
DS4/DS13/F8S	P20	3	1536 GB	3984	Tamanho Azure VM
DS4/DS13/F8S	P30	1	1024 GB	3112	Disco P30
DS4/DS13/F8S	P30	2	2048 GB	3984	Tamanho Azure VM
DS4/DS13/F8S	P30	3	3072 GB	3996	Tamanho Azure VM
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 Azure VM
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 Azure VM
DS5/DS14/F16S	P30	4	4096 GB	7968	Tamanho Azure VM
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 Azure VM

Para obter mais informações sobre os discos atualmente disponíveis, consulte Selecione um tipo de disco para VMs Azure Iaa .