Planejamento de capacidade para Serviços de Domínio Ative Directory

Este artigo fornece recomendações para o planejamento de capacidade para os Serviços de Domínio Ative Directory (AD DS).

Metas do planejamento de capacidade

Planejamento de capacidade não é o mesmo que solucionar problemas de incidentes de desempenho. Os objetivos do planejamento de capacidade são:

• Implementar e operar adequadamente um ambiente.
• Minimize o tempo gasto na solução de problemas de desempenho.

No planejamento de capacidade, uma organização pode ter uma meta de linha de base de 40% de utilização do processador durante os períodos de pico para atender aos requisitos de desempenho do cliente e dar tempo suficiente para atualizar o hardware no datacenter. Enquanto isso, eles definiram o seu limite de alerta de monitorização para problemas de desempenho para 90% num intervalo de cinco minutos.

Quando você excede continuamente o limite de gerenciamento de capacidade, adicionar mais processadores ou processadores mais rápidos para aumentar a capacidade ou dimensionar o serviço em vários servidores seria uma solução. Os limites de alerta de desempenho permitem que você saiba quando você precisa tomar medidas imediatas quando problemas de desempenho afetam negativamente a experiência do cliente. Em contrapartida, uma solução de solução de problemas estaria mais preocupada em lidar com eventos únicos.

O gerenciamento de capacidade é proativo: projete, dimensione e monitore o ambiente para que as tendências de utilização permaneçam dentro dos limites definidos e as ações de dimensionamento possam ocorrer antes do impacto do usuário. A solução de problemas de desempenho é reativa: resolva condições agudas que já estão degradando as operações do usuário.

O planejamento de capacidade para sistemas em expansão consiste em garantir que o hardware e o serviço possam lidar com a carga esperada. Em ambos os casos, o objetivo é garantir que o sistema possa lidar com a carga esperada e, ao mesmo tempo, fornecer uma boa experiência ao usuário. As seguintes opções de arquitetura podem ajudá-lo a atingir essa meta:

• Virtualization
• Armazenamento de alta velocidade, como unidades de estado sólido (SSDs) e NVMe (memória expressa não volátil)
• Cenários de nuvem

Os Serviços de Domínio Ative Directory (AD DS) são um serviço distribuído maduro que muitos produtos da Microsoft e de terceiros usam como back-end. É um dos componentes mais críticos para garantir que outros aplicativos tenham a capacidade de que precisam.

Informações importantes a considerar antes de começar a planear

Para tirar o máximo proveito deste artigo, você deve fazer as seguintes coisas:

• Certifique-se de que leu e compreendeu as Diretrizes de Ajuste de Desempenho para o Windows Server.
• A plataforma Windows Server é uma arquitetura baseada em x64, que fornece maior espaço de endereçamento de memória em comparação com sistemas x86. As diretrizes deste artigo se aplicam ao seu ambiente do Ative Directory, independentemente da versão do Windows Server. Para versões atuais, os recursos de memória x64 expandidos permitem armazenar em cache bancos de dados maiores na memória, embora os princípios de planejamento de capacidade permaneçam os mesmos. As diretrizes também se aplicam se o seu ambiente tiver uma árvore de informações de diretório (DIT) que possa caber inteiramente na memória do sistema disponível.
• Entenda que o planejamento de capacidade é um processo contínuo, portanto, você deve revisar regularmente o quão bem o ambiente que você cria está atendendo às suas expectativas.
• Compreenda que a otimização ocorre ao longo de vários ciclos de vida de hardware à medida que os custos de hardware mudam. Por exemplo, se a memória se tornar mais barata, o custo por núcleo diminui ou o preço das diferentes opções de armazenamento muda.
• Planeje para o período de maior movimento diário. Recomendamos que você faça seus planos com base em intervalos de 30 minutos ou horas. Considere as seguintes informações ao escolher seu intervalo:
  • Intervalos superiores a uma hora podem ocultar o momento em que o seu serviço realmente atinge a capacidade de pico.
  • Intervalos inferiores a 30 minutos podem fazer com que os aumentos transitórios pareçam mais importantes do que realmente são.
• Planeje o crescimento ao longo do ciclo de vida do hardware para a empresa. Esse planejamento de crescimento pode incluir estratégias para atualizar ou adicionar hardware de forma escalonada ou uma atualização completa a cada três ou cinco anos. Cada plano de crescimento requer que você estime quanto a carga no Ative Directory cresce. Os dados históricos podem ajudá-lo a fazer uma avaliação mais precisa.
• A tolerância a falhas é a capacidade de um sistema continuar a funcionar corretamente quando alguns componentes falham. Depois de determinar a capacidade necessária (conhecida como n), você deve planejar a tolerância a falhas. Considere n + 1, n + 2 ou até mesmo n + x cenários. Por exemplo, se você precisar de dois controladores de domínio (DCs), planeje três para poder lidar com uma falha de DC.

  • Com base no seu plano de crescimento, adicione servidores extras de acordo com a necessidade organizacional para garantir que a perda de um ou mais servidores não faça com que o sistema exceda as estimativas de capacidade máxima de pico.

  • Lembre-se de integrar seus planos de crescimento e tolerância a falhas. Por exemplo, um controlador de domínio (DC) lida com a carga atual. As previsões mostram que a carga duplica num ano e precisará de dois centros de dados apenas para atender à procura. Isso não deixa nenhuma capacidade ociosa para tolerância a falhas. Para evitar essa falta de capacidade, você deve planejar começar com três DCs. Se o seu orçamento não permitir três DCs, você também pode começar com dois DCs e, em seguida, planejar adicionar um terceiro após três ou seis meses.

    Note

    Adicionar aplicativos com reconhecimento do Ative Directory pode ter um impacto percetível na carga do DC, quer a carga seja proveniente dos servidores de aplicativos ou clientes.

O ciclo de planejamento de capacidade em três partes

Antes de iniciar seu ciclo de planejamento, você precisa decidir qual qualidade de serviço sua organização exige. Todas as recomendações e orientações neste artigo são para ambientes de desempenho ideal. No entanto, você pode relaxá-los seletivamente nos casos em que não precisa de otimização. Por exemplo, se sua organização precisa de um nível mais alto de simultaneidade e uma experiência de usuário mais consistente, você deve examinar a configuração de um datacenter. Os datacenters permitem que você preste mais atenção à redundância e minimize os gargalos do sistema e da infraestrutura. Por outro lado, se você estiver planejando uma implantação para um escritório satélite com apenas alguns usuários, não precisará se preocupar tanto com a otimização de hardware e infraestrutura, o que permite escolher opções de baixo custo.

Em seguida, você deve decidir se deseja usar máquinas virtuais ou físicas. Do ponto de vista do planejamento de capacidade, não há resposta certa ou errada. No entanto, você precisa ter em mente que cada cenário oferece um conjunto diferente de variáveis para trabalhar.

Os cenários de virtualização oferecem duas opções:

• Mapeamento direto, onde você tem apenas um convidado por anfitrião.
• Cenários de host compartilhado , onde você tem vários convidados por host.

Pode tratar cenários de mapeamento direto da mesma forma que os hosts físicos. Se você escolher um cenário de host compartilhado, ele apresentará outras variáveis que você deve levar em consideração nas seções posteriores. Os hosts compartilhados também competem por recursos com os Serviços de Domínio Ative Directory (AD DS), o que pode afetar o desempenho do sistema e a experiência do usuário.

Depois de responder a essas perguntas de planejamento anteriores, vamos examinar o ciclo de planejamento de capacidade em si. Cada ciclo de planejamento de capacidade envolve um processo de três etapas:

1. Meça o ambiente existente, determine onde estão os gargalos do sistema atualmente e obtenha as noções básicas ambientais necessárias para planejar a quantidade de capacidade de que sua implantação precisa.
2. Determine de que hardware você precisa com base em seus requisitos de capacidade.
3. Monitore e valide se a infraestrutura configurada está operando dentro das especificações. Os dados coletados nesta etapa tornam-se a linha de base para o próximo ciclo de planejamento de capacidade.

Aplicação do processo

Para otimizar o desempenho, certifique-se de que os seguintes componentes principais estejam corretamente selecionados e ajustados às cargas do aplicativo:

• Memory
• Network
• Armazenamento
• Processor
• Netlogon

Os requisitos básicos de armazenamento para AD DS e o comportamento geral do software cliente compatível significam que o hardware moderno de classe de servidor atende facilmente às necessidades de planejamento de capacidade de ambientes com até 10.000 a 20.000 usuários. Embora o planejamento de capacidade continue sendo importante para todas as implantações, os ambientes menores geralmente têm mais flexibilidade em suas opções de hardware, uma vez que a maioria dos sistemas de servidor atuais pode lidar com essas cargas sem exigir otimização especializada.

As tabelas em Tabelas de resumo da coleta de dados explicam como avaliar seu ambiente existente para selecionar o hardware certo. As seções seguintes entram em mais detalhes sobre recomendações de linha de base e princípios específicos de ambiente para hardware para ajudar os administradores do AD DS a avaliar sua infraestrutura.

Outras informações que você deve ter em mente ao planejar:

• Qualquer dimensionamento baseado em dados atuais é preciso apenas para o ambiente atual.
• Ao fazer estimativas, espere que a demanda cresça ao longo do ciclo de vida do hardware.
• Acomode o crescimento futuro determinando se você deve superdimensionar seu ambiente hoje ou adicionar capacidade gradualmente ao longo do ciclo de vida.
• Todos os princípios e metodologias de planejamento de capacidade que você aplicaria a uma implantação física também se aplicam a uma implantação virtualizada. No entanto, ao planejar um ambiente virtualizado, você precisa se lembrar de adicionar a sobrecarga de virtualização a qualquer planejamento ou estimativa relacionada ao domínio.
• O planejamento de capacidade é uma previsão, não um valor perfeitamente correto, então não espere que seja perfeitamente preciso. Lembre-se sempre de ajustar a capacidade conforme necessário e valide constantemente se seu ambiente está funcionando conforme o esperado.

Tabelas de resumo da recolha de dados

As tabelas a seguir listam e explicam os critérios para determinar suas estimativas de hardware.

Ambiente de trabalho

Critérios de avaliação de alto nível

Planning

Por muito tempo, a recomendação típica para o dimensionamento do AD DS era colocar tanta RAM quanto o tamanho do banco de dados. Embora o aumento do poder de computação e a mudança da arquitetura x86 para x64 tornassem os aspetos mais sutis do dimensionamento para desempenho menos importantes para o AD DS hospedado em máquinas físicas, a virtualização enfatizou a importância do ajuste de desempenho.

Para resolver essas preocupações, as seções a seguir descrevem como determinar e planejar as demandas do Ative Directory como um serviço. Você pode aplicar essas diretrizes a qualquer ambiente, independentemente de ser físico, virtualizado ou misto. Para maximizar seu desempenho, seu objetivo deve ser obter seu ambiente AD DS o mais próximo possível do limite do processador.

RAM

Quanto mais armazenamento você pode armazenar em cache na RAM, menos precisa ir para o disco.

Para maximizar a escalabilidade do servidor, calcule os requisitos mínimos de RAM somando estes componentes:

• Tamanho atual do banco de dados
• Quantidade recomendada para o seu sistema operativo
• Recomendações de fornecedores para agentes, tais como:
  • Programas antivírus
  • Software de monitorização
  • Aplicativos de backup

Você também deve incluir RAM extra para acomodar o crescimento futuro ao longo da vida útil do servidor. Essa estimativa muda com base no crescimento do banco de dados e nas mudanças ambientais.

Para ambientes em que maximizar a RAM não é rentável ou viável, consulte a seção Armazenamento para configurar corretamente o armazenamento. Esses cenários incluem:

• Localizações satélite com restrições orçamentais
• Implantações em que a Árvore de Informações de Diretório (DIT) é muito grande para caber na memória

Outra coisa importante a considerar para dimensionar a memória é o dimensionamento do arquivo de paginação. No dimensionamento de disco, como tudo relacionado à memória, o objetivo é minimizar o uso do disco. Em particular, quanta RAM você precisa para minimizar a paginação? As próximas seções devem fornecer as informações necessárias para responder a essa pergunta. Outras considerações sobre o tamanho da página que não afetam necessariamente o desempenho do AD DS são as recomendações do sistema operacional (SO) e a configuração do sistema para despejos de memória.

Determinar a quantidade de RAM de que um controlador de domínio (DC) precisa pode ser difícil devido a muitos fatores complexos:

• Os sistemas existentes nem sempre são indicadores fiáveis dos requisitos de RAM porque o Local Security Authority Subsystem Service (LSASS) corta a RAM sob pressão de memória, deflacionando artificialmente os requisitos.
• Os DCs individuais só precisam armazenar em cache os dados em que seus clientes estão interessados. Isso significa que os dados armazenados em cache em diferentes ambientes mudam dependendo dos tipos de clientes que eles contêm. Por exemplo, um controlador de domínio em um ambiente com um Exchange Server coleta dados diferentes de um controlador de domínio que apenas autentica usuários.
• A quantidade de esforço necessária para avaliar a RAM de cada DC caso a caso é muitas vezes excessiva e muda à medida que o ambiente muda.

Os critérios subjacentes às recomendações podem ajudá-lo a tomar decisões mais informadas:

• Quanto mais você armazenar em cache na RAM, menos você precisa ir para o disco.
• O armazenamento é o componente mais lento de um computador. O acesso a dados em suportes de armazenamento baseados em eixos e SSD é um milhão de vezes mais lento do que o acesso a dados na RAM.

Considerações de virtualização para RAM

Seu objetivo para otimizar a RAM é minimizar o tempo gasto indo para o disco. Evite a confirmação excessiva de memória no host (alocando mais RAM para convidados do que a máquina física). O excesso de confirmação por si só não é um problema, mas se o uso total de convidados exceder a RAM do host, as páginas do host. A paginação torna o desempenho dependente do disco quando o Controlador de Domínio (DC) acede ao NTDS.dit ou ao arquivo de paginação, ou quando o host pagina a RAM. Esse comportamento reduz drasticamente o desempenho e a experiência do usuário.

Exemplo de resumo de cálculo

Recomendado: 16GB

Com o tempo, mais dados são adicionados ao banco de dados e a vida útil média do servidor é de cerca de três a cinco anos. Com base em uma estimativa de crescimento de 33%, 18GB é uma quantidade razoável de RAM para colocar em um servidor físico.

Network

Esta seção trata da avaliação de quanta largura de banda total e capacidade de rede sua implantação precisa, incluindo consultas de clientes, configurações de Diretiva de Grupo e assim por diante. Você pode recolher dados para fazer a sua estimativa usando os contadores de desempenho Network Interface(*)\Bytes Received/sec e Network Interface(*)\Bytes Sent/sec. Os intervalos de amostra para contadores de Interface de Rede devem ser de 15, 30 ou 60 minutos. Qualquer coisa menos é muito volátil para boas medições, e qualquer coisa maior suaviza excessivamente os picos diários.

Necessidades de largura de banda

O planejamento da escalabilidade da rede abrange duas categorias distintas: a quantidade de tráfego e a carga da CPU do tráfego de rede.

Há duas coisas que você precisa levar em conta ao planejar a capacidade para suporte ao tráfego. Primeiro, você precisa saber quanto tráfego de replicação do Active Directory ocorre entre os seus DCs. Em segundo lugar, você deve avaliar o tráfego cliente-servidor intrasite. O tráfego intrasite recebe principalmente pequenas solicitações de clientes em relação às grandes quantidades de dados que envia de volta aos clientes. Normalmente, 100 MB são suficientes para ambientes com até 5.000 usuários por servidor. Para ambientes com mais de 5.000 usuários, recomendamos que você use um adaptador de rede de 1 GB e suporte a RSS (Receive Side Scaling).

Para avaliar a capacidade de tráfego intrasite, particularmente em cenários de consolidação de servidor, deve-se examinar o Network Interface(*)\Bytes/sec contador de desempenho em todos os DCs de um site, adicioná-los juntos e dividir a soma pelo número alvo de DCs. Uma maneira fácil de calcular esse número é abrir o Monitor de Confiabilidade e Desempenho do Windows e ver a visualização Área Empilhada. Certifique-se de que todos os contadores estão dimensionados da mesma forma.

Vamos dar uma olhada em um exemplo de uma maneira mais complexa de validar que essa regra geral se aplica a um ambiente específico. Neste exemplo, estamos fazendo as seguintes suposições:

• O objetivo é reduzir a pegada para o menor número possível de servidores. Idealmente, um servidor carrega a carga, em seguida, você implanta outro servidor para redundância (cenário n + 1).
• Nesse cenário, o adaptador de rede atual suporta apenas 100MB e está em um ambiente comutado.
• A utilização máxima da largura de banda da rede de destino é de 60% em um cenário n (perda de um DC).
• Cada servidor tem cerca de 10.000 clientes conectados a ele.

Agora, vamos ver o que o gráfico no contador Network Interface(*)\Bytes Sent/sec mostra para este cenário de exemplo.

1. O dia útil começa a aumentar por volta das 5h30 e termina às 19h00.
2. O período de pico mais movimentado é das 8h00 às 8h15, com mais de 25 bytes enviados por segundo no DC mais movimentado.

   Note

   Todos os dados de desempenho são históricos, portanto, o ponto de dados de pico às 8h15 indica a carga das 8h00 às 8h15.

3. Há picos antes das 4h00, com mais de 20 bytes enviados por segundo no DC mais movimentado, o que pode indicar carga de fusos horários diferentes ou atividade de infraestrutura em segundo plano, como backups. Uma vez que o pico às 8h00 ultrapassa esta atividade, não é relevante.
4. Há cinco DCs no site.
5. A carga máxima é de cerca de 5,5 MBps por DC, o que representa 44% da conexão de 100 MB. Usando esses dados, podemos estimar que a largura de banda total necessária entre 8:00 AM e 8:15 AM é de 28MBps.

   Note

   Os contadores de envio/recebimento da Interface de Rede estão em bytes, mas a largura de banda da rede é medida em bits. Portanto, para calcular a largura de banda total, você precisaria fazer 100MB ÷ 8 = 12,5MB e 1GB ÷ 8 = 128MB.

Depois de analisar os dados, que conclusões pode tirar do exemplo de utilização da rede?

• O ambiente atual atende ao nível n + 1 de tolerância a falhas com 60% do nível de utilização alvo. Colocar um sistema offline muda a largura de banda por servidor de cerca de 5,5 MBps (44%) para cerca de 7 MBps (56%).
• Com base no objetivo declarado anteriormente de consolidar em um servidor, essa alteração de consolidação excede a utilização máxima de destino e a possível utilização de uma conexão de 100 MB.
• Com uma conexão de 1GB, esse valor de largura de banda por servidor representa 22% da capacidade total.
• Em condições normais de operação no cenário n + 1, a carga do cliente é relativamente distribuída em cerca de 14 MBps por servidor ou 11% da capacidade total.
• Para garantir que se tenha capacidade suficiente enquanto um DC não estiver disponível, os alvos operacionais normais por servidor seriam cerca de 30% de utilização da rede ou 38 MBps por servidor. Os alvos de tolerância a falhas seriam uma utilização de rede de 60% ou 72 MBps por servidor.

A implantação final do sistema deve ter um adaptador de rede de 1 GB e uma conexão com a infraestrutura de rede que possa suportar a carga necessária. Devido à quantidade de tráfego de rede, a carga da CPU das comunicações de rede pode potencialmente limitar a escalabilidade máxima do AD DS. Você pode usar esse mesmo processo para estimar a comunicação de entrada para o DC. No entanto, na maioria dos cenários, você não precisa calcular o tráfego de entrada porque ele é menor do que o tráfego de saída.

É importante certificar-se de que o seu hardware suporta RSS em ambientes com mais de 5.000 utilizadores por servidor. Em cenários de alto tráfego de rede, o balanceamento da carga de interrupção pode se tornar um gargalo. Você pode detetar possíveis gargalos verificando o contador para ver se o tempo de interrupção está distribuído Processor(*)\% Interrupt Time de forma desigual entre as CPUs. Os controladores de interface de rede (NICs) habilitados para RSS podem atenuar essas limitações e aumentar a escalabilidade.

Considerações de virtualização para largura de banda de rede

A recomendação típica para um servidor físico é um adaptador de 1GB para servidores que suportam mais de 5.000 usuários. Quando vários convidados começarem a compartilhar uma infraestrutura de comutador virtual subjacente, confirme se o host tem largura de banda de rede agregada adequada para suportar todos os convidados. Considere a largura de banda em ambos os cenários: quando o DC é executado como uma VM em um host com tráfego de rede em um comutador virtual e quando ele se conecta diretamente a um comutador físico. Os comutadores virtuais requerem um planeamento cuidadoso da largura de banda. O uplink deve suportar os dados agregados passados através dele. O adaptador de rede host físico vinculado ao switch deve suportar a carga DC e todos os outros convidados que compartilham o comutador virtual e se conectam através do adaptador físico.

Exemplo de resumo de cálculo de rede

A tabela a seguir contém valores de um cenário de exemplo que podemos usar para calcular a capacidade da rede:

Com base nesta tabela, a largura de banda recomendada seria de 72MBps (28,5MBps ÷ 40%).

Como sempre, você deve assumir que a carga do cliente aumentará com o tempo, então você deve planejar esse crescimento o mais cedo possível. Recomendamos que planeie para um crescimento estimado de tráfego de rede de pelo menos 50%.

Armazenamento

Há duas coisas que você deve considerar ao planejar a capacidade de armazenamento:

• Capacidade ou tamanho de armazenamento
• Performance

Embora a capacidade seja importante, é importante não negligenciar o desempenho. Com os custos atuais de hardware, a maioria dos ambientes não é grande o suficiente para que qualquer um dos fatores seja uma grande preocupação. Portanto, a recomendação habitual é apenas colocar tanta RAM quanto o tamanho do banco de dados. No entanto, essa recomendação pode ser exagerada para locais via satélite em ambientes maiores.

Sizing

Avaliação para armazenamento

Em comparação com quando o Ative Directory chegou pela primeira vez em uma época em que as unidades de 4 GB e 9 GB eram os tamanhos de unidade mais comuns, agora o dimensionamento para o Ative Directory nem é uma consideração para todos, exceto para os maiores ambientes. Com os menores tamanhos de disco rígido disponíveis na faixa de 180GB, todo o sistema operacional, SYSVOLe NTDS.dit pode caber facilmente em uma unidade. Como resultado, recomendamos que você evite investir muito no dimensionamento do armazenamento.

Recomendamos que 110% do tamanho de NTDS.dit esteja disponível para que possa desfragmentar o seu armazenamento.

Além desta recomendação, você deve tomar as considerações usuais para acomodar o crescimento futuro.

Se fores avaliar o teu armazenamento, tu tens que primeiro avaliar o quão grandes o NTDS.dit e o SYSVOL precisam de ser. Essas medidas ajudam a dimensionar as alocações de disco fixo e RAM. Como os componentes são de custo relativamente baixo, você não precisa ser super preciso ao fazer as contas. Para obter mais informações sobre a avaliação do armazenamento, consulte Limites de armazenamento e estimativas de crescimento para usuários do Ative Directory e unidades organizacionais.

Ao revisar ambientes existentes com vários domínios, você pode notar variações nos tamanhos dos bancos de dados. Quando detetar essas variações, use os menores tamanhos de catálogo global (GC) e não GC.

Os tamanhos dos bancos de dados podem variar entre as versões do sistema operacional. Os DCs que executam versões anteriores do sistema operacional têm tamanhos de banco de dados menores do que um que executa uma versão posterior. O DC com recursos como Ative Directory REcycle Bin ou Credential Roaming habilitado também pode afetar o tamanho do banco de dados.

Considerações de virtualização para armazenamento

Em cenários em que você aloca vários arquivos de disco rígido virtual (VHD) para um único volume, você deve usar um disco de estado fixo. O disco deve ter pelo menos 210% o tamanho do DIT para garantir que você tenha espaço suficiente reservado para suas necessidades. Este tamanho VHD fixo inclui 100% do tamanho DIT mais 110% de espaço livre.

Exemplo de resumo de cálculo de armazenamento

A tabela a seguir lista os valores que você usaria para estimar os requisitos de espaço para um cenário de armazenamento hipotético.

A estimativa de armazenamento também deve incluir mais componentes de armazenamento além do banco de dados. Esses componentes incluem:

• SYSVOL
• Arquivos do sistema operacional
• Arquivo de paginação
• Arquivos temporários
• Dados locais armazenados em cache, como arquivos do instalador
• Aplicações

Desempenho do armazenamento

Como o componente mais lento dentro de qualquer computador, o armazenamento pode ter o maior impacto adverso na experiência do cliente. Para ambientes grandes o suficiente para que as recomendações de dimensionamento de RAM neste artigo não sejam viáveis, as consequências de ignorar o planejamento de capacidade para armazenamento podem ser devastadoras para o desempenho do sistema. As complexidades e variedades da tecnologia de armazenamento disponível aumentam ainda mais o risco, já que a recomendação típica de colocar o sistema operacional, os logs e o banco de dados em discos físicos separados não se aplica universalmente em todos os cenários.

As recomendações antigas sobre discos pressupunham que um disco era um eixo dedicado que permitia operações de entrada/saída isoladas. Esta suposição de eixo dedicado não é mais verdadeira devido à introdução dos seguintes tipos de armazenamento:

• RAID
• Novos tipos de armazenamento e cenários de armazenamento virtualizado e compartilhado
• Eixos compartilhados em uma SAN (Storage Area Network, rede de armazenamento de dados)
• Arquivo VHD em uma SAN ou armazenamento conectado à rede
• Unidades de estado sólido (SSDs)
• Unidades NVMe (Memória Não Volátil Expressa)
• Arquiteturas de armazenamento hierárquico, como o cache de camada de armazenamento SSD para armazenamento baseado em disco rígido maior

Outras cargas de trabalho colocadas no armazenamento back-end podem sobrecarregar o armazenamento compartilhado, como RAID, SAN, NAS, JBOD, Espaços de Armazenamento e VHD. Estes tipos de dispositivos de armazenamento podem apresentar uma consideração extra. Por exemplo, problemas de SAN, rede ou driver entre o disco físico e o aplicativo AD podem causar limitação e atrasos. Para esclarecer, esses tipos de arquiteturas de armazenamento não são uma má escolha, mas são mais complexos, o que significa que você precisa prestar atenção extra para garantir que todos os componentes estejam funcionando conforme o esperado. Para obter explicações mais detalhadas, consulte o Apêndice C e o Apêndice D mais adiante neste artigo.

Esta tecnologia de armazenamento de estado sólido (NVMe e SSD) não tem as mesmas limitações mecânicas que os discos rígidos tradicionais. No entanto, eles ainda têm limitações de E/S. Quando você excede esses limites, o sistema pode ficar sobrecarregado.

O objetivo do planejamento de desempenho de armazenamento é garantir que o número necessário de E/S esteja sempre disponível e que elas aconteçam dentro de um período de tempo aceitável. Para obter mais informações sobre cenários com armazenamento conectado localmente, consulte o Apêndice C. Você pode aplicar os princípios do apêndice a cenários de armazenamento mais complexos e conversas com fornecedores que dão suporte às suas soluções de armazenamento back-end.

Devido ao número de opções de armazenamento disponíveis atualmente, recomendamos que você consulte suas equipes ou fornecedores de suporte de hardware enquanto planeja garantir que a solução atenda às necessidades de sua implantação do AD DS. Durante essas conversas, você pode achar úteis os seguintes contadores de desempenho, especialmente quando o banco de dados é muito grande para a RAM:

• LogicalDisk(*)\Avg Disk sec/Read (por exemplo, se NTDS.dit estiver armazenado na unidade D, o caminho completo será LogicalDisk(D:)\Avg Disk sec/Read)
• LogicalDisk(*)\Avg Disk sec/Write
• LogicalDisk(*)\Avg Disk sec/Transfer
• LogicalDisk(*)\Reads/sec
• LogicalDisk(*)\Writes/sec
• LogicalDisk(*)\Transfers/sec

Ao fornecer os dados, você deve certificar-se de que os intervalos de amostra são de 15, 30 ou 60 minutos para fornecer a imagem mais precisa possível do seu ambiente atual.

Avaliação dos resultados

Esta seção se concentra em leituras do banco de dados, pois o banco de dados geralmente é o componente mais exigente. Você pode aplicar a mesma lógica para gravar no arquivo de log substituindo <NTDS Log>)\Avg Disk sec/Write e LogicalDisk(<NTDS Log>)\Writes/sec).

O LogicalDisk(<NTDS>)\Avg Disk sec/Read contador mostra se o armazenamento atual está dimensionado adequadamente. Se o valor for aproximadamente igual ao tempo de acesso ao disco esperado para o tipo de disco, o LogicalDisk(<NTDS>)\Reads/sec contador é uma medida válida. Se os resultados forem aproximadamente iguais ao tempo de acesso ao disco para o tipo de disco, o LogicalDisk(<NTDS>)\Reads/sec contador é uma medida válida. Embora a latência aceitável varie de acordo com o fornecedor de armazenamento, os bons intervalos são LogicalDisk(<NTDS>)\Avg Disk sec/Read :

• 7.200 rpm: 9 milissegundos a 12,5 milissegundos (ms)
• 10.000 rpm: 6 ms a 10 ms
• 15.000 rpm: 4 ms a 6 ms
• SSD – 1 ms a 3 ms

Você pode ouvir de outras fontes que o desempenho do armazenamento está degradado em 15 ms a 20 ms. A diferença entre esses valores e os valores na lista anterior é que os valores da lista mostram o intervalo de operação normal. Os outros valores são para fins de solução de problemas, que ajudam a identificar quando a experiência do cliente se degradou o suficiente para se tornar percetível. Para obter mais informações, consulte o Apêndice C.

• LogicalDisk(<NTDS>)\Reads/sec é a quantidade de E/S que o sistema está executando no momento.
  • Se LogicalDisk(<NTDS>)\Avg Disk sec/Read estiver dentro do intervalo ideal para o armazenamento de back-end, você pode usar LogicalDisk(<NTDS>)\Reads/sec diretamente para dimensionar o armazenamento.
  • Se LogicalDisk(<NTDS>)\Avg Disk sec/Read não estiver dentro do intervalo ideal para o armazenamento de back-end, mais E/S será necessária de acordo com a seguinte fórmula: LogicalDisk(<NTDS>)\Avg Disk sec/Read ÷ Tempo de acesso ao disco de mídia física × LogicalDisk(<NTDS>)\Avg Disk sec/Read

Ao fazer esses cálculos, aqui estão algumas coisas que você deve considerar:

• Se o servidor tiver uma quantidade subótima de RAM, os valores resultantes podem ser muito altos e não precisos o suficiente para serem úteis para o planejamento. No entanto, você ainda pode usá-los para prever os piores cenários.
• Se adicionar ou otimizar a RAM, também reduzirá a quantidade de leituras de E/SLogicalDisk(<NTDS>)\Reads/Sec. Essa diminuição pode fazer com que a solução de armazenamento seja menos robusta do que os cálculos originais sugeridos. Infelizmente, não podemos dar mais detalhes sobre o que essa declaração significa, pois os cálculos variam muito dependendo de ambientes individuais, particularmente da carga do cliente. No entanto, recomendamos que você ajuste o tamanho do armazenamento depois de otimizar a RAM.

Considerações de virtualização para desempenho

Semelhante às seções anteriores, o objetivo para o desempenho da virtualização é garantir que a infraestrutura compartilhada possa suportar a carga total de todos os consumidores. Tenha esse objetivo em mente ao planejar os seguintes cenários:

• Um CD físico que compartilha a mesma mídia em uma infraestrutura SAN, NAS ou iSCSI que outros servidores ou aplicativos.
• Um usuário que usa acesso de passagem a uma infraestrutura SAN, NAS ou iSCSI que compartilha a mídia.
• Um usuário usando um arquivo VHD em mídia compartilhada localmente ou uma infraestrutura SAN, NAS ou iSCSI.

Do ponto de vista de um usuário convidado, ter que passar por um host para acessar qualquer armazenamento afeta o desempenho, já que o usuário deve percorrer mais caminhos de código para obter acesso. Os testes de desempenho indicam que a virtualização afeta a taxa de transferência com base na quantidade de processador que o sistema host utiliza. A utilização do processador influencia quantos recursos o usuário convidado exige do host. Essa demanda contribui para as considerações de virtualização para processamento que você deve tomar para as necessidades de processamento em cenários virtualizados. Para obter mais informações, consulte o Apêndice A.

Outras questões complicadas são quantas opções de armazenamento estão disponíveis atualmente, cada uma com impactos de desempenho muito diferentes. Essas opções incluem pass-through storage, adaptadores SCSI e IDE. Ao migrar de um ambiente físico para um ambiente virtual, você deve ajustar para diferentes opções de armazenamento para usuários convidados virtualizados usando um multiplicador de 1,10. No entanto, você não precisa considerar ajustes ao transferir entre diferentes cenários de armazenamento, pois se o armazenamento é local, SAN, NAS ou iSCSI é mais importante.

Exemplo de cálculo de virtualização

Determinar a quantidade de E/S necessária para um sistema saudável em condições normais de funcionamento:

• LogicalDisk(<NTDS Database Drive>) ÷ Transferências por segundo durante o período de pico de 15 minutos
• Para determinar a quantidade de E/S necessária para armazenamento em que a capacidade do armazenamento subjacente é excedida:

  IOPS necessário = (LogicalDisk(<NTDS Database Drive>)) ÷ Leitura média de disco/s ÷ <Target Avg Disk Read/sec>) × LogicalDisk(<NTDS Database Drive>)\Read/seg

Para determinar a taxa na qual você deve aquecer o cache:

• Determine o tempo máximo que você considera aceitável para gastar no aquecimento do cache. Em cenários típicos, uma quantidade de tempo aceitável seria quanto tempo deveria levar para carregar todo o banco de dados de um disco. Em cenários em que a RAM não pode carregar todo o banco de dados, use o tempo que levaria para preencher toda a RAM.
• Determine o tamanho do banco de dados, excluindo o espaço que você não planeja usar. Para obter mais informações, consulte Avaliação para armazenamento.
• Divida o tamanho do banco de dados por 8KB para obter o número total de E/S necessárias para carregar o banco de dados.
• Divida o total de E/S pelo número de segundos no período de tempo definido.

O número que você calcula é uma aproximação. Não é exato porque o tamanho do cache do Mecanismo de Armazenamento Extensível (ESE) não é fixo. Por padrão, o cache cresce e diminui, portanto, o AD DS pode remover páginas carregadas anteriormente. Um tamanho de cache fixo tornaria a estimativa mais precisa.

Processing

Avaliando o uso do processador do Ative Directory

Para a maioria dos ambientes, o gerenciamento da capacidade de processamento é o componente que merece mais atenção. Ao avaliar quanta capacidade de CPU sua implantação precisa, você deve considerar as duas coisas a seguir:

• Os aplicativos em seu ambiente se comportam como pretendido dentro de uma infraestrutura de serviços compartilhados com base nos critérios descritos em Rastreando pesquisas caras e ineficientes? Em ambientes maiores, aplicativos mal codificados podem fazer com que a carga da CPU se torne volátil, levar uma quantidade excessiva de tempo de CPU às custas de outros aplicativos, aumentar as necessidades de capacidade e distribuir a carga de forma desigual em relação aos DCs.
• O AD DS é um ambiente distribuído com muitos clientes potenciais cujas necessidades de processamento variam muito. Os custos estimados para cada cliente podem variar devido aos padrões de uso e quantos aplicativos estão usando o AD DS. Assim como em Network, você deve abordar a estimativa como uma avaliação da capacidade total necessária no ambiente, em vez de olhar para cada cliente um de cada vez.

Conclua a estimativa de armazenamento antes de começar a estimar o uso do processador. Você não pode fazer uma suposição precisa sem dados válidos sobre a carga do processador. Também é importante certificar-se de que seu armazenamento não está criando gargalos antes de solucionar problemas do processador. À medida que você remove os estados de espera do processador, a utilização da CPU aumenta porque ela não precisa mais esperar nos dados. Portanto, os contadores de desempenho aos quais você deve prestar mais atenção são:

• Logical Disk(<NTDS Database Drive>)\Avg Disk sec/Read
• Process(lsass)\ Processor Time

Se o contador ultrapassar 10 milissegundos ou 15 milissegundos, então os dados em Process(lsass)\ Processor Time são artificialmente baixos e o problema está relacionado no desempenho do armazenamento. Recomendamos que você defina intervalos de amostra para 15, 30 ou 60 minutos para obter os dados mais precisos possíveis.

Visão geral do processamento

Para planejar o planejamento de capacidade para controladores de domínio, o poder de processamento requer mais atenção e compreensão. Ao dimensionar sistemas para garantir o máximo desempenho, há sempre um componente que é o gargalo, e em um controlador de domínio de tamanho adequado esse componente é o processador.

Semelhante à seção de rede, onde a demanda do ambiente é revisada site a site, o mesmo deve ser feito para a capacidade de computação demandada. Ao contrário da seção de rede, onde as tecnologias de rede disponíveis excedem em muito a demanda normal, preste mais atenção ao dimensionamento da capacidade da CPU. Tal como qualquer ambiente de tamanho moderado; qualquer ambiente com mais de alguns milhares de utilizadores simultâneos pode colocar uma carga significativa na CPU.

Infelizmente, devido à enorme variabilidade de aplicativos cliente que usam AD, uma estimativa geral de usuários por CPU é lamentavelmente inaplicável a todos os ambientes. Especificamente, as demandas de computação estão sujeitas ao comportamento do usuário e ao perfil do aplicativo. Portanto, cada ambiente precisa ser dimensionado individualmente.

Perfil de comportamento do site de destino

Quando você está planejando a capacidade para um site inteiro, sua meta deve ser um design de capacidade N + 1. Neste projeto, mesmo que um sistema falhe durante o período de pico, o serviço ainda pode continuar em níveis aceitáveis de qualidade. Em um cenário N , a carga em todas as caixas deve ser inferior a 80%-100% durante os períodos de pico.

Além disso, os aplicativos e clientes do site usam o método de função DsGetDcName recomendado para localizar DCs. Eles já devem ser distribuídos uniformemente com apenas pequenos picos transitórios.

Agora vamos observar dois exemplos de ambientes que estão dentro do alvo e fora do alvo. Primeiro, vamos dar uma olhada em um exemplo de um ambiente que funciona como pretendido e não excede a meta de planejamento de capacidade.

Para o primeiro exemplo, estamos fazendo as seguintes suposições:

• Cada um dos cinco DCs no site tem quatro CPUs.
• O uso total da CPU de destino durante o horário comercial é de 40% em condições normais de operação (N + 1) e 60% caso contrário (N). Durante o horário não comercial, o uso da CPU de destino é de 80% porque esperamos que o software de backup e outros processos de manutenção consumam todos os recursos disponíveis.

Agora, vamos dar uma olhada no (Processor Information(_Total)\% Processor Utility) gráfico, para cada um dos DCs, como mostrado na imagem a seguir.

• A carga é distribuída uniformemente, que é o que esperaríamos quando os clientes usam o localizador DC e pesquisas bem escritas.

• Em vários intervalos de cinco minutos, há picos de 10%, às vezes até 20%. No entanto, a menos que esses picos façam com que o uso da CPU exceda a meta do plano de capacidade, você não precisa investigá-los.

• O período de pico para todos os sistemas é entre 8:00 e 9:15. O dia útil médio dura das 5h00 às 17h00. Portanto, quaisquer picos aleatórios de uso da CPU que aconteçam entre 17:00 e 4:00 estão fora do horário comercial e, portanto, você não precisa incluí-los em suas preocupações de planejamento de capacidade.

  Durante as horas fora de pico, breves picos em um sistema bem gerenciado geralmente vêm de:

  • Trabalhos de backup
  • Verificações antivírus completas
  • Verificações de inventário de hardware
  • Verificações de inventário de software
  • Distribuição de software ou implantações de patches

  Picos fora dessas tarefas podem indicar uma carga anormal e justificar investigação. Como esses picos acontecem fora do horário comercial, eles não contam para exceder as metas de planejamento de capacidade.

• Como cada sistema tem cerca de 40% e todos eles têm o mesmo número de CPUs, se um deles ficar offline, os sistemas restantes rodam a uma estimativa de 53%. A carga de 40% inicialmente atribuída ao Sistema D é então dividida uniformemente entre os sistemas restantes e adicionada à carga de 40% que já possuem. Esta suposição de redistribuição linear não é perfeitamente precisa, mas fornece precisão suficiente para a estimativa.

Em seguida, vejamos um exemplo de um ambiente que não tem um bom uso da CPU e excede a meta de planejamento de capacidade.

Neste exemplo, dois data centers funcionam a 40%. Um dos data centers fica offline e o data center restante aumenta para aproximadamente 80%. Durante o failover, essa carga ultrapassa o limite estabelecido no plano de capacidade e reduz o espaço livre para 10% a 20% para picos. Cada pico pode agora conduzir o DC para 90% ou até 100%, reduzindo a capacidade de resposta.

Calculando demandas de CPU

O Process\% Processor Time contador de desempenho rastreia a quantidade total de tempo que todos os threads de aplicativos gastam na CPU e, em seguida, divide essa soma pela quantidade total de tempo do sistema que passou. Um aplicativo multithreaded em um sistema multi-CPU pode exceder 100% tempo de CPU, e você interpretaria seus dados de forma diferente do Processor Information\% Processor Utility contador. Na prática, o Process(lsass)\% Processor Time contador rastreia quantas CPUs rodando a 100% o sistema requer para suportar as demandas de um processo. Por exemplo, se o contador tiver um valor de 200%, isso significa que o sistema precisa de duas CPUs rodando a 100% para suportar a carga completa do AD DS. Embora uma CPU a funcionar a 100% da capacidade seja a mais eficiente em termos de custo em termos de consumo de potência e energia, um sistema multithreaded é mais responsivo quando o seu sistema não está a funcionar a 100%. As razões para esta eficiência são descritas no apêndice A.

Para acomodar picos transitórios na carga do cliente, recomendamos que você direcione uma CPU de período de pico entre 40% e 60% de capacidade do sistema. Por exemplo, no primeiro exemplo no perfil de comportamento do site de destino, você precisaria de entre 3,33 CPUs (60% destino) e 5 CPUs (40% destino) para suportar a carga do AD DS. Você deve adicionar capacidade extra de acordo com as demandas do sistema operacional e quaisquer outros agentes necessários, como antivírus, backup, monitoramento e assim por diante. Planeje reservar de 5 a 10% da capacidade de uma CPU para agentes de infraestrutura (antivírus, backup, monitoramento). Meça o uso real do agente em seu ambiente e ajuste conforme necessário. Para revisitar nosso exemplo, precisaríamos de entre 3,43 (60% de destino) e 5,1 (40% de destino) CPUs para suportar carga durante períodos de pico.

Agora, vamos dar uma olhada em um exemplo de cálculo para um processo específico. Neste caso, estamos analisando o processo LSASS.

Calculando o uso da CPU para o processo LSASS

Neste exemplo, o sistema é um cenário N + 1 em que um servidor carrega a carga do AD DS enquanto um servidor extra está lá para redundância.

O gráfico a seguir mostra o tempo do processador para o processo LSASS em todos os processadores para este cenário de exemplo. Esses pontos de dados vêm do Process(lsass)\% Processor Time contador de desempenho.

Veja o que o gráfico de tempo do processador LSASS mostra sobre o ambiente do cenário:

• Há três controladores de domínio no site.
• O dia útil começa a aumentar por volta das 7h00 e, em seguida, desce às 17h00.
• O período mais movimentado do dia é das 9h30 às 11h00.

  Note

  Todos os dados de desempenho são históricos. O ponto de dados de pico às 9h15 indica a carga do período das 9h00 às 9h15.

• Picos antes das 7h00 podem indicar carga extra de diferentes fusos horários ou atividade de infraestrutura em segundo plano, como backups. No entanto, como este pico é menor do que o pico de atividade às 9h30, não é motivo de preocupação.

Na carga máxima, o processo LSASS consome cerca de 4,85 CPUs rodando a 100%, o que seria 485% em uma única CPU. Esses resultados sugerem que o site do cenário precisa de cerca de 12 a 25 CPUs para gerir o AD DS. Quando se traz a capacidade extra recomendada de 5% a 10% para processos em segundo plano, o servidor necessita de 12,25 a 12,30 CPUs para suportar a sua carga atual. As estimativas que antecipam o crescimento futuro tornam este número ainda maior.

Quando ajustar pesos LDAP

Existem certos cenários em que se deve considerar ajustar LdapSrvWeight. No contexto do planejamento de capacidade, você o ajustaria quando seus aplicativos, cargas de usuário ou recursos subjacentes do sistema não estivessem equilibrados.

As secções a seguir descrevem dois cenários de exemplo em que se deve ajustar as ponderações do protocolo LDAP (Lightweight Directory Access Protocol).

Exemplo 1: Ambiente do emulador PDC

Se você estiver usando um emulador de Controlador de Domínio Primário (PDC), o comportamento de usuário ou aplicativo distribuído de forma desigual pode afetar vários ambientes ao mesmo tempo. O emulador PDC geralmente tem maior carga de CPU do que outros controladores de domínio. Muitas operações preferem ou sempre entram em contato com ele, exemplos incluem:

• Ferramentas de gerenciamento de Diretiva de Grupo (criação, edição, vinculação, atualização do GPMC)
• Verificação de alteração de senha / segunda tentativa de autenticação (verificação de senha de fallback)
• Criação de confiança e operações de manutenção
• Hierarquia de serviço de tempo (fonte temporal autoritária no domínio/floresta)
• Processamento de bloqueio de conta
• Aplicativos herdados ou mal configurados que ainda visam o emulador de PDC

Monitore sua CPU separadamente e planeje espaço extra se essas atividades forem comuns.

Você deve ajustar seu emulador PDC somente se houver uma diferença notável na utilização da CPU. O ajuste deve reduzir a carga no emulador PDC e aumentar a carga em outros DCs, permitindo uma distribuição de carga mais uniforme.

Nesses casos, defina o valor entre LDAPSrvWeight 50 e 75 para o emulador PDC.

O problema é que, se a função de emulador de PDC for transferida ou apreendida, particularmente para outro controlador de domínio no site, a utilização da CPU aumentará drasticamente no novo emulador de PDC.

Neste cenário de exemplo, assumimos, com base no perfil de comportamento do site de destino , que todos os três controladores de domínio neste site têm quatro CPUs. Em condições normais, o que aconteceria se um desses DCs tivesse oito CPUs? Existiriam dois DCs a 40% de utilização e um a 20% de utilização. Embora essa configuração não seja necessariamente ruim, há uma oportunidade aqui para você usar o ajuste de peso LDAP para equilibrar melhor a carga.

Exemplo 2: ambiente com diferentes contagens de CPU

Quando você tem servidores com diferentes contagens de CPU e velocidades no mesmo site, você precisa garantir que eles sejam distribuídos uniformemente. Por exemplo, se o seu site tiver dois servidores de oito núcleos e um servidor de quatro núcleos, o servidor de quatro núcleos terá apenas metade do poder de processamento dos outros dois servidores. Se a carga do cliente for distribuída uniformemente, isso significa que o servidor de quatro núcleos precisa trabalhar duas vezes mais do que os dois servidores de oito núcleos para gerenciar sua carga de CPU. Além disso, se um dos servidores de oito núcleos ficar offline, o servidor de quatro núcleos ficará sobrecarregado.

Planejar um cenário N +1 é fundamental. O impacto de um DC ficar offline deve ser calculado para cada cenário. No exemplo anterior, a carga é compartilhada uniformemente entre todos os servidores. Em um cenário N (um servidor perdido), cada servidor restante permanece em cerca de 60%. A distribuição atual é aceitável porque os rácios permanecem consistentes. Quando você olha para o cenário de ajuste do emulador PDC ou qualquer cenário geral em que a carga do usuário ou do aplicativo está desequilibrada, o efeito é diferente:

Considerações de virtualização para processamento

Quando você está planejando capacidade para um ambiente virtualizado, há dois níveis que você precisa considerar: o nível de host e o nível de convidado. No nível do host, você deve identificar os períodos de pico do seu ciclo de negócios. Como agendar threads convidados na CPU para uma máquina virtual é semelhante a obter threads do AD DS na CPU para uma máquina física, ainda recomendamos que você use de 40% a 60% do host subjacente. No nível de convidado, como os princípios de agendamento de threads subjacentes permanecem inalterados, também recomendamos que você mantenha o uso da CPU dentro do intervalo de 40% a 60%.

Para uma configuração mapeada diretamente (um convidado por host), reutilize os números de planejamento de capacidade coletados anteriormente. Aplique-os diretamente para dimensionar essa implantação.

Em um cenário de host compartilhado, suponha cerca de 10% de sobrecarga de eficiência da CPU da virtualização. Se o site precisar de 10 CPUs com um uso alvo de 40% em hardware físico, adicione mais uma CPU para compensar essa sobrecarga. Aloque um total de 11 CPUs virtuais (vCPUs) entre os N controladores de domínio convidados.

Em sites com distribuições mistas de servidores físicos e virtuais, essa sobrecarga de virtualização só se aplica às máquinas virtuais (VMs). Em um design N + 1, um servidor físico de 10 CPU (ou mapeado diretamente) é aproximadamente equivalente a um DC virtual com 11 vCPUs. O host também precisa de outras 11 CPUs reservadas para essa VM.

Enquanto analisa e calcula quantas CPUs precisa para suportar a carga do AD DS. Tenha em mente que, se você planeja comprar hardware físico, os tipos de hardware disponíveis no mercado podem não corresponder exatamente às suas estimativas. No entanto, você não tem esse problema quando usa a virtualização. O uso de VMs diminui o esforço necessário para adicionar capacidade de computação a um site, pois você pode adicionar quantas CPUs com as especificações exatas desejar a uma VM. No entanto, a virtualização não elimina sua responsabilidade de avaliar com precisão quanto poder de computação você precisa para garantir que seu hardware subjacente esteja disponível quando os convidados precisarem de mais recursos de CPU. Planeie sempre com antecedência o crescimento.

Exemplo de resumo de cálculo de virtualização

Se você projeta um crescimento de demanda de 50% em três anos, planeje 18.375 CPUs (12,25 × 1,5) até esse momento. Como alternativa, você pode analisar a demanda após o primeiro ano e, em seguida, adicionar capacidade extra com base no que os resultados lhe dizem.

Carga de autenticação de clientes em ambientes de confiança cruzada para NTLM

Avaliação da carga de autenticação de cliente em ambiente de confiança cruzada

Muitos ambientes podem ter um ou mais domínios conectados por uma relação de confiança. As solicitações de autenticação para identidades em outros domínios que não usam Kerberos precisam atravessar uma relação de confiança usando um canal seguro entre dois controladores de domínio. O controlador de domínio do usuário entra em contato com um controlador de domínio no domínio de destino ou com o próximo ao longo do caminho de confiança para esse domínio. A configuração *MaxConcurrentAPI controla quantas chamadas o DC pode fazer para o outro DC no domínio confiável. Para garantir que o canal seguro possa lidar com a quantidade de carga necessária para que os DCs se comuniquem entre si, você pode ajustar MaxConcurrentAPI ou, se estiver em uma floresta, criar relações de confiança de atalho. Saiba mais sobre como determinar o volume de tráfego entre relações de confiança em Como fazer o ajuste de desempenho para autenticação NTLM usando a configuração MaxConcurrentApi.

Como nos cenários anteriores, você deve coletar dados durante os períodos de pico de movimento do dia para que eles sejam úteis.

Planejamento de virtualização

Há algumas coisas que você deve ter em mente ao planejar a capacidade para virtualização:

• Muitos aplicativos usam a autenticação NTLM por padrão ou em determinadas configurações.
• À medida que o número de clientes ativos aumenta, aumenta também a necessidade de os servidores de aplicativos terem mais capacidade.
• Os clientes às vezes mantêm as sessões abertas por um tempo limitado e, em vez disso, se reconectam regularmente para serviços como sincronização de email via pull.
• Os servidores proxy da Web que exigem autenticação para acesso à Internet podem causar alta carga NTLM.

Esses aplicativos podem criar uma grande carga para autenticação NTLM, o que coloca uma pressão significativa sobre os DCs, especialmente quando os usuários e recursos estão em domínios diferentes.

Há muitas abordagens que você pode adotar para gerenciar a carga de confiança cruzada, que muitas vezes você pode e deve usar juntos ao mesmo tempo:

• Reduza a autenticação de cliente de confiança cruzada localizando os serviços que um usuário consome no domínio em que está localizado.
• Aumente o número de canais seguros disponíveis. Esses canais são chamados de relações de confiança de atalho e são relevantes para o tráfego intraflorestal e entre florestas.
• Ajuste as configurações padrão para MaxConcurrentAPI.

Para ajustar MaxConcurrentAPI em um servidor existente, use a seguinte equação:

New_MaxConcurrentApi_setting ≥ (semaphore_acquires + semaphore_time-outs) × average_semaphore_hold_time ÷ time_collection_length

Para obter mais informações, consulte o artigo da Base de Dados de Conhecimento 2688798: Como fazer o ajuste de desempenho para autenticação NTLM usando a configuração MaxConcurrentApi.

Considerações sobre virtualização

Não há considerações especiais que você precise fazer, pois a virtualização é uma configuração de ajuste do sistema operacional.

Exemplo de cálculo de ajuste de virtualização

Para este sistema para este período de tempo, os valores padrão são aceitáveis.

Monitoramento para conformidade com as metas de planejamento de capacidade

Ao longo deste artigo, discutimos como o planejamento e o dimensionamento vão em direção às metas de utilização. A tabela a seguir resume os limites recomendados que você deve monitorar para garantir que os sistemas estejam operando conforme o esperado. Lembre-se de que esses não são limites de desempenho, apenas limites de planejamento de capacidade. Um servidor operando acima desses limites ainda funciona, mas você precisa validar que seus aplicativos estão funcionando como pretendido antes de começar a ver problemas de desempenho à medida que a demanda do usuário aumenta. Se os aplicativos estiverem corretos, você deve começar a avaliar atualizações de hardware ou outras alterações de configuração.

Apêndice A: Critérios de dimensionamento da CPU

Este apêndice discute termos e conceitos úteis que podem ajudá-lo a estimar as necessidades de dimensionamento da CPU do seu ambiente.

Definições: Dimensionamento da CPU

• Um processador (microprocessador) é um componente que lê e executa instruções do programa.

• Um processador multi-core tem várias CPUs no mesmo circuito integrado.

• Um sistema multi-CPU tem várias CPUs que não estão no mesmo circuito integrado.

• Um processador lógico é um processador que tem apenas um mecanismo de computação lógica da perspetiva do sistema operacional.

Essas definições incluem hyper-threaded, um núcleo no processador multi-core ou um processador de núcleo único.

Como os sistemas de servidor atuais têm vários processadores, vários processadores multi-core e hyper-threading, essas definições são generalizadas para cobrir ambos os cenários. Usamos o termo processador lógico porque representa o SO e a perspetiva de aplicação dos motores de computação disponíveis.

Paralelismo ao nível do thread

Cada thread é uma tarefa independente, pois cada thread tem sua própria pilha e instruções. O AD DS pode ser bem dimensionado em vários processadores lógicos, pois é multithreaded e permite o ajuste do número de threads disponíveis. Para saber mais sobre como ajustar os threads disponíveis, siga as instruções em Como exibir e definir a política LDAP no Ative Directory usando Ntdsutil.exe.

Paralelismo no nível de dados

O paralelismo a nível de dados ocorre quando um serviço partilha dados através de muitos threads para o mesmo processo e partilha muitos threads entre múltiplos processos. O processo do AD DS sozinho contaria como um serviço compartilhando dados em vários threads para um único processo. Quaisquer alterações nos dados são refletidas em todos os threads em execução em todos os níveis do cache, em todos os núcleos e em quaisquer atualizações da memória compartilhada. O desempenho pode diminuir durante as operações de gravação porque todos os locais de memória se ajustam às alterações antes que o processamento de instruções possa continuar.

Velocidade da CPU versus considerações de vários núcleos

Processadores lógicos mais rápidos reduzem o tempo que um único thread precisa para concluir seu trabalho. Adicionar mais processadores lógicos aumenta a quantidade de threads que podem ser executados em paralelo. No entanto, o dimensionamento não é linear devido à latência de memória, contenção de recursos compartilhados, sincronização/bloqueio, caminhos de código serial e sobrecarga de agendamento. Como resultado, a escalabilidade em sistemas multi-core não é linear.

A utilização é dimensionada de forma não linear porque várias restrições interagem:

• Um único thread executável termina mais cedo em um núcleo mais rápido; Adicionar mais núcleos ociosos não oferece nenhum benefício, a menos que haja trabalho paralelo executável.
• Quando um thread para em uma falha de cache ou precisa de dados da memória principal, ele não pode avançar até que os dados retornem. Núcleos mais rápidos não eliminam a latência da memória; eles podem esperar mais tempo em relação à sua taxa de ciclo.
• À medida que a simultaneidade (threads executáveis) aumenta, a sincronização, o tráfego de coerência de cache, a contenção de bloqueio e a sobrecarga do agendador consomem uma porcentagem maior do total de ciclos.
• Sistemas mais amplos (mais soquetes/núcleos) amplificam os efeitos de latência para operações que exigem ordenação global (por exemplo, modificação de dados compartilhados, abates de TLB, interrupções entre processadores).
• Alguns caminhos de código são seriais (Lei de Amdahl). Uma vez que as regiões paralelas estão saturadas, núcleos adicionais contribuem com retornos decrescentes.

Portanto, a adição de núcleos ou frequência só melhora a taxa de transferência do AD DS quando a carga de trabalho é suficientemente executável e paralelizável e não está majoritariamente limitada por contenção de memória, armazenamento ou bloqueio.

Em resumo, as perguntas sobre se você deve adicionar mais ou mais processadores mais rápidos tornam-se altamente subjetivas e devem ser consideradas caso a caso. Para o AD DS em particular, suas necessidades de processamento dependem de fatores ambientais e podem variar de servidor para servidor em um único ambiente. Como resultado, as seções anteriores deste artigo não investiram muito em fazer cálculos super precisos. Quando você toma decisões de compra orientadas pelo orçamento, recomendamos que você primeiro otimize o uso do processador em 40% ou qualquer número que seu ambiente específico exija. Se o seu sistema não está otimizado, então você não se beneficia tanto de comprar mais processadores.

Tempo de resposta e como os níveis de atividade do sistema afetam o desempenho

A teoria das filas é o estudo matemático das filas de espera, ou filas. Na teoria das filas de espera para computação, a lei de utilização é representada pela equação t:

U k = B ÷ T

Onde U k é a percentagem de utilização, B é a quantidade de tempo gasto a estar ocupado e T é o tempo total gasto a observar o sistema. No contexto da Microsoft, isto significa o número de threads de intervalo de 100 nanossegundos (ns) que estão no estado de execução dividido por quantos intervalos de 100 ns estavam disponíveis no intervalo de tempo especificado. Esta é a mesma fórmula que calcula a percentagem de utilização do processador mostrada no Processor Object e PERF_100NSEC_TIMER_INV.

A teoria da fila também fornece a fórmula: N = U k ÷ (1 - U k) para estimar o número de itens de espera com base na utilização, onde N é o comprimento da fila. Traçar esta equação ao longo de todos os intervalos de utilização fornece as seguintes estimativas de quanto tempo a fila para entrar no processador dura a qualquer carga de CPU.

Com base nessa estimativa, podemos observar que, após 50% de carga na% da CPU, a espera média geralmente inclui mais um item na fila e a utilização da CPU aumenta rapidamente para 70% na%.

Para entender como a teoria do enfileiramento se aplica à sua implementação do AD DS, vamos voltar à metáfora da autoestrada que usamos em velocidade da CPU versus considerações de múltiplos núcleos.

Os horários mais movimentados no meio da tarde cairiam em algum lugar na faixa de 40% a 70% de capacidade. Há tráfego suficiente para que sua capacidade de escolher uma faixa para dirigir não seja severamente restringida. Embora a probabilidade de outro condutor atrapalhar o teu caminho seja alta, não requer o mesmo nível de esforço que terias para encontrar um espaço seguro entre outros carros na faixa em hora de ponta.

À medida que a hora de ponta se aproxima, o sistema rodoviário aproxima-se dos 100% da sua capacidade. Mudar de faixa durante a hora de ponta torna-se muito difícil porque os carros estão tão próximos uns dos outros que não tem tanto espaço de manobra quando muda de faixa. O comportamento de enfileiramento explica a meta de capacidade média a longo prazo de 40%. Manter a utilização média perto de 40% deixa espaço para picos breves (por exemplo, consultas lentas ou mal codificadas) e eventos de explosão maiores (como o aumento na manhã seguinte a um feriado).

A declaração anterior considera que o cálculo percentual do tempo do processador é o mesmo que a equação da lei de utilização. Esta versão simplificada destina-se a introduzir o conceito a novos utilizadores. No entanto, para matemática mais avançada, você pode usar as seguintes referências como guia:

• Tradução do PERF_100NSEC_TIMER_INV
  • B = O número de intervalos de 100 ns que o thread ocioso gasta no processador lógico. A alteração da variável X no cálculo do PERF_100NSEC_TIMER_INV
  • T = o número total de intervalos de 100 ns num determinado intervalo de tempo. A alteração da variável Y no cálculo PERF_100NSEC_TIMER_INV .
  • U k = A porcentagem de utilização do processador lógico pelo Idle Thread ou % Idle Time.
• Fazendo as contas:
  • U k = 1 – % de Tempo de Processador
  • %Tempo do Processador = 1 – U k
  • %Tempo do Processador = 1 – B / T
  • %Tempo de Processador = 1 – X1 – X0 / Y1 – Y0

Aplicando esses conceitos ao planejamento de capacidade

A matemática na seção anterior provavelmente faz com que determinar quantos processadores lógicos você precisa em um sistema pareça complexo. Como resultado, sua abordagem para dimensionar o sistema deve se concentrar em determinar a utilização máxima do destino com base na carga atual e, em seguida, calcular o número de processadores lógicos necessários para atingir esse objetivo. Além disso, sua estimativa não precisa ser perfeitamente exata. Embora as velocidades do processador lógico tenham um impacto significativo na sincronização, outras áreas também podem afetar o desempenho, como:

• Eficiência do cache
• Requisitos de coerência da memória
• Agendamento e sincronização de threads
• Cargas de cliente imperfeitamente equilibradas

Como o poder de computação é relativamente de baixo custo, não vale a pena investir muito tempo no cálculo do número perfeitamente exato de CPUs que você precisa.

Também é importante lembrar que a recomendação de 40%, neste caso, não é um requisito obrigatório. Usamo-lo como um começo razoável para fazer cálculos. Diferentes tipos de usuários do AD precisam de diferentes níveis de capacidade de resposta. Alguns ambientes podem ter uma média de 80%a 90% CPU e ainda atender às expectativas dos usuários se os tempos de espera da fila não aumentarem visivelmente. Trate isso como uma exceção, valide os dados com dados de latência e monitore de perto a contenda emergente.

Outras partes do sistema são mais lentas do que a CPU. Sintonize-os também. Concentre-se no acesso à RAM, no acesso ao disco e no tempo de resposta à rede. Por exemplo:

• Se você adicionar processadores a um sistema com 90% de utilização que está limitado pelo disco, provavelmente não melhorará significativamente o desempenho. Se olhar mais de perto para o sistema, há muitos encadeamentos que nem estão entrando no processador porque estão esperando que as operações de entrada/saída sejam concluídas.

• Resolver problemas ligados ao disco pode significar que threads anteriormente presos no estado de espera param de ficar presos, criando mais competição pelo tempo da CPU. Como resultado, a utilização de 90% vai para 100%. Você precisa ajustar ambos os componentes para reduzir a utilização para níveis gerenciáveis.

  Note

  O Processor Information(*)\% Processor Utility contador pode ultrapassar os 100% com sistemas que tenham um modo Turbo. O modo Turbo permite que a CPU exceda a velocidade nominal do processador por curtos períodos. Se precisar de mais informações, consulte a documentação dos fabricantes de CPU e as descrições dos contadores.

Discutir considerações de utilização de todo o sistema também envolve controladores de domínio como convidados virtualizados. O tempo de resposta e como os níveis de atividade do sistema afetam o desempenho se aplica ao host e ao convidado em um cenário virtualizado. Em um host com apenas um convidado, um DC ou sistema tem quase o mesmo desempenho que teria em hardware físico. Adicionar mais convidados aos hosts aumenta a utilização do host subjacente, aumentando também os tempos de espera para obter acesso aos processadores. Portanto, você deve gerenciar a utilização do processador lógico nos níveis de host e convidado.

Vamos revisitar a metáfora da autoestrada das secções anteriores, só que desta vez estamos a imaginar a máquina virtual convidada como um autocarro expresso. Os ônibus expressos, ao contrário do transporte público ou dos ônibus escolares, vão direto para o destino do passageiro sem fazer nenhuma parada.

Agora, vamos imaginar quatro cenários:

• Os horários fora do horário de pico de um sistema são como andar de ônibus expresso tarde da noite. Quando o motociclista sobe, quase não há outros passageiros e a estrada está quase vazia. Como não há trânsito a atrapalhar o autocarro, a viagem é fácil e tão rápida quanto se o passageiro tivesse conduzido até lá no seu próprio carro. No entanto, o limite de velocidade local pode limitar o tempo de viagem do motociclista.
• Em horas de menor movimento, quando a utilização da CPU de um sistema é muito alta, é como uma viagem noturna quando a maioria das pistas da rodovia estão fechadas. Embora o ônibus em si esteja praticamente vazio, a estrada ainda está congestionada devido ao tráfego remanescente que lida com as faixas restritas. Embora o motociclista seja livre para se sentar onde quiser, o seu tempo real de viagem é determinado pelo tráfego fora do autocarro.
• Um sistema com alta utilização da CPU durante o horário de pico é como um ônibus lotado durante o horário de pico. Não só a viagem demora mais tempo, mas entrar e sair do ônibus é mais difícil porque o ônibus está cheio de outros passageiros. Adicionar mais processadores lógicos ao sistema convidado para tentar acelerar os tempos de espera seria como tentar resolver o problema de tráfego adicionando mais ônibus. O problema não é o número de ônibus, mas o tempo que a viagem demora.
• Um sistema com alta utilização de CPU fora do horário de pico é como aquele mesmo ônibus lotado em uma estrada praticamente vazia à noite. Embora os passageiros possam ter problemas para encontrar assentos ou entrar e sair do ônibus, a viagem é bastante tranquila quando o ônibus pega todos os seus passageiros. Este cenário é o único em que o desempenho melhoraria com a adição de mais ônibus.

Com base nos exemplos anteriores, você pode ver que há muitos cenários entre 0% e 100% de utilização que têm vários graus de impacto no desempenho. Além disso, adicionar mais processadores lógicos não necessariamente melhora o desempenho fora de cenários específicos. Deve ser bastante simples aplicar esses princípios ao objetivo recomendado de utilização da CPU de 40% para hosts e convidados.

Apêndice B: Considerações sobre diferentes velocidades do processador

Em Processamento, assumimos que o processador está funcionando a 100% de velocidade de clock enquanto você coleta dados e que todos os sistemas de substituição têm a mesma velocidade de processamento. Apesar dessas suposições não serem precisas, especialmente para o Windows Server 2008 R2 e posterior, onde o plano de energia padrão é Balanceado, essas suposições ainda funcionam para estimativas conservadoras. Embora os erros potenciais possam aumentar, isso só aumenta a margem de segurança à medida que as velocidades do processador aumentam.

• Por exemplo, em um cenário que exige 11,25 CPUs, se os processadores funcionassem a meia velocidade quando você coletava seus dados, a estimativa mais precisa de sua demanda seria 5,125 ÷ 2.
• É impossível garantir que dobrar a velocidade do relógio dobre a quantidade de processamento que acontece dentro do período de tempo gravado. A quantidade de tempo que os processadores passam esperando na RAM ou em outros componentes permanece aproximadamente a mesma. Portanto, processadores mais rápidos podem passar uma porcentagem maior de tempo ocioso enquanto aguardam que o sistema busque dados. Recomendamos que você mantenha o menor denominador comum, mantenha suas estimativas conservadoras e evite assumir uma comparação linear entre as velocidades do processador que poderia tornar seus resultados imprecisos.

Se as velocidades do processador no hardware de substituição forem inferiores às do hardware atual, você deverá aumentar proporcionalmente a estimativa de quantos processadores são necessários. Por exemplo, vamos ver um cenário em que você calcula que precisa de 10 processadores para sustentar a carga do seu site. Os processadores atuais são executados a 3,3 GHz, e os processadores que você planeja substituí-los por são executados a 2,6 GHz. Substituir apenas os 10 processadores originais resultaria numa redução de 21% na velocidade. Para aumentar a velocidade, você precisa obter pelo menos 12 processadores em vez de 10.

No entanto, essa variabilidade não altera as metas de utilização do processador de gerenciamento de capacidade. As velocidades de clock do processador são ajustadas dinamicamente com base na demanda de carga, portanto, executar o sistema sob cargas mais altas faz com que a CPU passe mais tempo em um estado de velocidade de clock mais alta. O objetivo final é que a CPU esteja a 40% de utilização em um estado de velocidade de clock de 100% durante o horário comercial de pico. Qualquer coisa menos gera economia de energia ao limitar as velocidades da CPU durante cenários fora de pico.

Para ajustar as estimativas para diferentes processadores, recomendamos que você use o benchmark de SPECint_rate2006 da Standard Performance Evaluation Corporation. Para usar este benchmark:

1. Vá para o site da Standard Performance Evaluation Corporation (SPEC).

2. Selecione Resultados.

3. Digite CPU2006 e selecione Pesquisar.

4. No menu suspenso Configurações disponíveis, selecione Todos os CPU2006 SPEC.

5. No campo Pedido de Formulário de Pesquisa , selecione Simples e, em seguida, selecione Ir!.

6. Em Solicitação simples, insira os critérios de pesquisa para o processador de destino. Por exemplo, se estiver à procura de um processador E5-2630, no menu pendente, selecione Processador e, em seguida, introduza o nome do processador no campo de pesquisa. Quando terminar, selecione Executar Busca Simples.

7. Procure a configuração do servidor e do processador nos resultados da pesquisa. Se o mecanismo de pesquisa não retornar uma correspondência exata, procure a correspondência mais próxima possível.

8. Registre os valores nas colunas Resultado e # Cores .

9. Determine o modificador usando esta equação:

   ((Valor da pontuação por núcleo da plataforma de destino) × (MHz por núcleo da plataforma de linha de base)) ÷ ((Valor da pontuação por núcleo da linha de base) × (MHz por núcleo da plataforma de destino))

   Por exemplo, veja como você encontraria o modificador para um processador E5-2630:

   (35,83 × 2000) ÷ (33,75 × 2300) = 0,92

10. Multiplique o número de processadores que você estima que precisa por esse modificador.

    Para o exemplo de processador E5-2630, 0,92 × 10,3 = 10,35 processadores.

Apêndice C: Como o sistema operacional interage com o armazenamento

Os conceitos da teoria da fila que discutimos em Tempo de resposta e como os níveis de atividade do sistema afetam o desempenho também se aplicam ao armazenamento. Você precisa estar familiarizado com a forma como seu sistema operacional lida com E/S para aplicar esses conceitos de forma eficaz. Nos sistemas operacionais Windows, o sistema cria uma fila que contém solicitações de E/S para cada disco físico. No entanto, um disco físico não é necessariamente um único disco. O sistema operacional também pode registrar uma agregação de eixos em um controlador de array ou SAN como um disco físico. Os controladores de array e SANs também podem agregar vários discos em um único conjunto de matrizes, dividi-los em várias partições e, em seguida, usar cada partição como um disco físico, conforme mostrado na imagem a seguir.

Nesta ilustração, os dois eixos são espelhados e divididos em áreas lógicas para armazenamento de dados, rotuladas como Dados 1 e Dados 2. O SO regista cada uma destas áreas lógicas como discos físicos separados.

Agora esclarecemos o que define um disco físico. Os termos a seguir podem ajudá-lo a entender melhor as informações deste Apêndice.

• Um eixo é o dispositivo fisicamente instalado no servidor.
• Uma matriz é uma coleção de eixos agregados pelo controlador.
• Uma partição de matriz é um particionamento da matriz agregada.
• Um LUN (Número de Unidade Lógica) é uma matriz de dispositivos SCSI conectados a um computador. Este artigo usa esses termos quando fala sobre SANs.
• Um disco inclui qualquer eixo ou partição que o SO regista como um único disco físico.
• Uma partição é um particionamento lógico do que o sistema operacional registra como um disco físico.

Considerações sobre a arquitetura do sistema operacional

O SO cria uma fila de E/S First In, First out (FIFO) para cada disco registado. Esses discos podem ser eixos, matrizes ou partições de matriz. Quando se trata de como o sistema operacional lida com E/S, quanto mais filas ativas, melhor. Quando o sistema operacional serializa a fila FIFO, ele deve processar todas as solicitações de E/S FIFO emitidas para o subsistema de armazenamento em ordem de chegada. Ao manter uma fila de E/S separada para cada eixo ou matriz, o sistema operacional impede que os discos compitam pelos mesmos recursos de E/S escassos e mantém a atividade isolada apenas para os discos envolvidos. No entanto, o Windows Server 2008 introduziu uma exceção na forma de priorização de E/S. Os aplicativos projetados para usar E/S de baixa prioridade são movidos para o fim da fila, não importa quando o sistema operacional os recebeu. Aplicações que não estão programadas para usar a configuração de baixa prioridade usam, por padrão, a prioridade normal.

Introdução a subsistemas de armazenamento simples

Nesta seção, falamos sobre subsistemas de armazenamento simples. Vamos começar com um exemplo: um único disco rígido dentro de um computador. Se dividirmos esse sistema em seus principais componentes de subsistema de armazenamento, aqui está o que obtemos:

• Um HD SCSI ultrarrápido de 10.000 RPM (SCSI ultrarrápido tem uma taxa de transferência de 20 MBps)
• Um barramento SCSI (o cabo)
• Um adaptador SCSI ultrarrápido
• Um barramento PCI de 32 bits e 33MHz

Depois de identificar os componentes, você pode começar a ter uma ideia de quantos dados o sistema pode transmitir e quanta E/S ele pode lidar. A quantidade de E/S e a quantidade de dados que podem transitar pelo sistema estão relacionadas entre si, mas não o mesmo valor. Essa correlação depende do tamanho do bloco e se a E/S do disco é aleatória ou sequencial. O sistema grava todos os dados no disco como um bloco, mas diferentes aplicativos podem usar tamanhos de bloco diferentes.

Em seguida, vamos analisar esses itens componente por componente.

Tempos de acesso ao disco rígido

O disco rígido médio de 10.000 RPM tem um tempo de busca de 7ms e um tempo de acesso de 3ms. O tempo de busca é a quantidade média de tempo que a cabeça de leitura ou gravação leva para se mover para um local no prato. O tempo de acesso é a quantidade média de tempo que a cabeça leva para ler ou gravar os dados no disco quando eles estão no local correto. Portanto, o tempo médio para ler um bloco único de dados em um HD de 10.000 RPM inclui tempos de busca e acesso para um total de aproximadamente 10 ms, ou 0,010 segundos, por bloco de dados.

Quando cada acesso ao disco requer que a cabeça seja movida para um novo local no disco, o comportamento de leitura ou gravação é chamado de aleatório. Quando todas as E/S são aleatórias, um HD de 10.000 RPM pode lidar com aproximadamente 100 E/S por segundo (IOPS).

Quando todas as E/S ocorrem a partir de setores adjacentes no disco rígido, chamamos de E/S sequencial. A operação de E/S sequencial não adiciona tempo de busca extra. Após a conclusão da primeira E/S, a cabeça de leitura/gravação já está posicionada no próximo bloco de dados. Por exemplo, um HD de 10.000 RPM é capaz de lidar com aproximadamente 333 E/S por segundo, com base na seguinte equação:

1000ms por segundo ÷ 3ms por E/S

Até agora, a taxa de transferência do disco rígido não tem sido relevante para o nosso exemplo. Não importa o tamanho do disco rígido, a quantidade real de IOPS que o HD de 10.000 RPM pode suportar é sempre de cerca de 100 E/S aleatórias ou 300 sequenciais. À medida que os tamanhos dos blocos mudam com base na aplicação que está a gravar na unidade, a quantidade de dados transferidos por E/S também muda. Por exemplo, se o tamanho do bloco for de 8KB, 100 operações de E/S lerão ou gravarão no disco rígido um total de 800KB. No entanto, se o tamanho do bloco for de 32KB, 100 E/S lerão ou gravarão 3.200KB (3,2MB) no disco rígido. Se a taxa de transferência SCSI exceder a quantidade total de dados transferidos, obter uma taxa de transferência mais rápida não mudará nada. Para obter mais informações, consulte as tabelas a seguir:

O backplane SCSI

Como o tamanho do bloco influencia a forma como o backplane SCSI — que neste exemplo é representado pelo cabo de fita — afeta a taxa de transferência do subsistema de armazenamento. Quanta E/S o barramento pode suportar se a E/S estiver em blocos de 8KB? Nesse cenário, o barramento SCSI é 20MBps ou 20480KB/s. 20480KB/s ao dividir por blocos de 8KB resulta em um máximo de aproximadamente 2500 IOPS suportados pelo barramento SCSI.

Como mostra a tabela anterior, no nosso cenário de exemplo, o barramento nunca é um gargalo porque o máximo do eixo é 100 E/S, muito abaixo de qualquer um dos limites listados.

O adaptador SCSI

Para determinar a quantidade de E/S que o sistema pode suportar, você deve verificar as especificações do fabricante. Direcionar solicitações de E/S para o dispositivo apropriado requer poder de processamento, portanto, a quantidade de E/S que o sistema pode lidar depende do adaptador SCSI ou do processador do controlador de matriz.

Neste cenário de exemplo, estamos assumindo que o sistema pode lidar com 1.000 E/S.

O barramento PCI

O barramento PCI é um componente frequentemente negligenciado. Neste cenário de exemplo, o barramento PCI não é o gargalo. No entanto, à medida que os sistemas aumentam, isso pode se tornar um gargalo no futuro.

Podemos ver o quanto um barramento PCI pode transferir dados em nosso cenário de exemplo usando esta equação:

32 bits ÷ 8 bits por byte × 33 MHz = 133MBps

Portanto, podemos supor que um barramento PCI de 32 bits operando a 33 Mhz pode transferir 133MBps de dados.

Um barramento PCI de 64 bits de 66MHz pode suportar um máximo teórico de 528MBps com base nesta equação:

64 bits ÷ 8 bits por byte × 66Mhz = 528MBps

Adicionar outro dispositivo (por exemplo, um adaptador de rede ou um segundo controlador SCSI) reduz a largura de banda disponível para o sistema. Todos os dispositivos no barramento compartilham essa largura de banda e cada novo dispositivo compete por recursos de processamento limitados.

Analisando subsistemas de armazenamento para encontrar gargalos

Nesse cenário, o fuso é o fator limitante para a quantidade de entrada/saída que você pode solicitar. Como resultado, esse gargalo também limita a quantidade de dados que o sistema pode transmitir. Como nosso exemplo é um cenário do AD DS, a quantidade de dados transmissíveis é de 100 E/S aleatórias por segundo em incrementos de 8KB, para um total de 800KB por segundo quando você acessa o banco de dados Jet. Em comparação, um eixo dedicado apenas a arquivos de log pode fornecer até 300 E/S sequenciais de 8 KB por segundo. Isso equivale a 2.400 KB (2,4 MB) por segundo.

Agora que analisamos os componentes de nossa configuração de exemplo, vamos examinar uma tabela que demonstra onde os gargalos podem acontecer à medida que adicionamos e alteramos componentes no subsistema de armazenamento.

Apresentando RAID

Quando você introduz um controlador de array no subsistema de armazenamento, ele não altera drasticamente sua natureza. O controlador de matriz substitui apenas o adaptador SCSI nos cálculos. No entanto, o custo de leitura e gravação de dados no disco quando você usa os vários níveis de matriz muda.

No RAID 0, a gravação de dados distribui as faixas de dados por todos os discos do conjunto RAID. Durante uma operação de leitura ou gravação, o sistema extrai dados ou os envia para cada disco, aumentando a quantidade de dados que o sistema pode transmitir durante esse período de tempo específico. Portanto, neste exemplo em que estamos usando unidades de 10.000 RPM, o uso de RAID 0 permitiria executar operações de 100 E/S. A quantidade total de I/O suportada pelo sistema é de N fusos vezes 100 I/O por segundo por fuso, ou N fusos × 100 I/O por segundo por fuso.

No RAID 1, o sistema espelha ou duplica dados em um par de eixos para redundância. Quando o sistema executa uma operação de E/S de leitura, ele pode ler dados de ambos os eixos no conjunto. Esse espelhamento torna a capacidade de E/S para ambos os discos disponível durante uma operação de leitura. No entanto, o RAID 1 não oferece vantagens de desempenho às operações de gravação, porque o sistema também precisa espelhar dados gravados no par de eixos. Embora o espelhamento não faça com que as operações de gravação demorem mais, ele impede que o sistema faça mais de uma operação de leitura ao mesmo tempo. Portanto, cada operação de E/S de gravação custa duas operações de E/S de leitura.

A equação a seguir calcula quantas operações de E/S estão acontecendo nesse cenário:

E/S de leitura + 2 × E/S de gravação = Total de E/S disponíveis de disco consumidas

Quando você souber a proporção de leituras para gravações e o número de eixos em sua implantação, poderá usar esta equação para calcular a quantidade de E/S que seu array pode suportar:

IOPS máximo por eixo × 2 eixos × [(% Leituras + % Gravações) ÷ (% Leituras + 2 × % Gravações)] = IOPS Total

Um cenário usando RAID 1 e RAID 0 se comporta exatamente como RAID 1 no custo das operações de leitura e gravação. No entanto, a E/S agora é intercalada em cada conjunto espelhado. Isto significa que a equação muda para:

IOPS máximo por eixo × 2 eixos × [(% Leituras + % Gravações) ÷ (% Leituras + 2 × % Gravações)] = E/S Total

Em um conjunto RAID 1, quando você distribui o número N de conjuntos RAID 1, o total de E/S que sua matriz pode processar torna-se N × E/S por conjunto RAID 1:

N × {IOPS máximo por eixo × 2 eixos × [(% Leituras + % Gravações) ÷ (% Leituras + 2 × % Gravações)]} = IOPS Total

Por vezes, chamamos RAID 5 RAID N + 1 porque o sistema distribui os dados por N discos e grava a informação de paridade no + 1 disco. No entanto, o RAID 5 usa mais recursos ao executar uma E/S de gravação do que RAID 1 ou RAID 1 + 0. O RAID 5 executa o seguinte processo sempre que o sistema operacional envia uma E/S de gravação para a matriz:

1. Leia os dados antigos.
2. Leia a paridade antiga.
3. Escreva os novos dados.
4. Escreva a nova paridade.

Cada solicitação de E/S de gravação que o sistema operacional envia para o controlador de array requer quatro operações de E/S para concluir. Portanto, as solicitações de gravação RAID N + 1 levam quatro vezes mais tempo do que uma E/S de leitura para serem concluídas. Em outras palavras, para determinar quantas solicitações de E/S do sistema operacional se traduzem em quantas solicitações os eixos recebem, use esta equação:

Ler E/S + 4 × E/S de gravação = Total E/S

Para RAID 1, depois de saber a taxa de leitura/gravação e o número de eixos, você pode usar a seguinte equação para estimar o total de E/S suportadas para a matriz:

IOPS por eixo × (Eixos – 1) × [(% Leituras + % Gravações) ÷ (% Leituras + 4 × % Gravações)] = IOPS Total

Introdução às SANs

Quando você introduz uma SAN (Storage Area Network, rede de armazenamento de dados) em seu ambiente, isso não afeta os princípios de planejamento descritos nas seções anteriores. No entanto, você deve levar em consideração que a SAN pode alterar o comportamento de I/O de todos os sistemas conectados a ela. Uma SAN adiciona redundância em comparação com o armazenamento interno ou de conexão direta. Você ainda deve planejar a tolerância a falhas. Suponha que um ou mais caminhos, controladores ou prateleiras possam falhar sem ultrapassar a utilização prevista do restante. Além disso, à medida que você introduz mais componentes em seu sistema, você também precisa fatorar essas novas peças em seus cálculos.

Agora, vamos dividir uma SAN em seus componentes:

• O disco rígido SCSI ou Fibre Channel
• O backplane do canal da unidade de armazenamento
• As próprias unidades de armazenamento
• O módulo do controlador de armazenamento
• Um ou mais switches SAN
• Um ou mais adaptadores de barramento de host (HBAs)
• O barramento de interconexão de componentes periféricos (PCI)

Ao projetar um sistema para redundância, você deve incluir componentes extras para garantir que seu sistema continue funcionando durante um cenário de crise em que um ou mais dos componentes originais parem de funcionar. No entanto, ao planejar a capacidade, você precisa excluir componentes redundantes dos recursos disponíveis para obter uma estimativa precisa da capacidade de linha de base do sistema, já que esses componentes geralmente não ficam online, a menos que haja uma emergência. Por exemplo, se a SAN tiver dois módulos de controlador, você só precisará usar um ao calcular a taxa de transferência total de E/S disponível, pois o outro não será ligado a menos que o módulo original pare de funcionar. Você também não deve trazer o switch SAN redundante, a unidade de armazenamento ou os eixos para os cálculos de E/S.

Além disso, como o planejamento de capacidade considera apenas períodos de pico de uso, você não deve considerar componentes redundantes em seus recursos disponíveis. O pico de utilização não deve exceder 80% saturação do sistema para acomodar picos ou outro comportamento incomum do sistema.

Ao analisar o comportamento do disco rígido SCSI ou Fibre Channel, você deve analisá-lo de acordo com os princípios descritos nas seções anteriores. Apesar de cada protocolo ter suas próprias vantagens e desvantagens, a principal coisa que limita o desempenho em uma base por disco são as limitações mecânicas do disco rígido.

Ao analisar o canal na unidade de armazenamento, você deve adotar a mesma abordagem, fez ao calcular quantos recursos estavam disponíveis no barramento SCSI: dividir a largura de banda pelo tamanho do bloco. Por exemplo, se a sua unidade de armazenamento tiver seis canais que suportam uma taxa de transferência máxima de 20 MBps, a quantidade total de E/S disponíveis e transferência de dados é de 100 MBps. Seis canais a 20 MBps cada resultam em um valor teórico de 120 MBps. Limitamos a taxa de transferência planejada em 100MBps (design N+1). Se um canal falhar, os cinco restantes (5 × 20MBps) ainda entregam os 100MBps necessários. Este exemplo também pressupõe que o sistema está distribuindo uniformemente a carga e a tolerância a falhas em todos os canais.

Se você pode transformar o exemplo anterior em um perfil de E/S depende do comportamento do aplicativo. Para E/S do Ative Directory Jet, o valor máximo seria aproximadamente 12.500 E/S por segundo ou 100 MBps ÷ 8 KB por E/S.

Para entender quanto rendimento seus módulos de controlador suportam, você também precisa obter as especificações do fabricante. Neste exemplo, a SAN tem dois módulos de controlador que suportam 7.500 E/S cada. Se você não estiver usando redundância, a taxa de transferência total do sistema será de 15.000 IOPS. No entanto, em um cenário em que a redundância é necessária, você calcularia a taxa de transferência máxima com base nos limites de apenas um dos controladores, que é de 7.500 IOPS. Supondo que o tamanho do bloco seja de 4KB, esse limite está bem abaixo do máximo de 12.500 IOPS que os canais de armazenamento podem suportar e, portanto, é o gargalo em sua análise. No entanto, para fins de planejamento, a E/S máxima desejada que você deve planejar é de 10.400 E/S.

Quando os dados saem do módulo controlador, eles transmitem uma conexão Fibre Channel classificada em 1GBps ou 128MBps. Como essa quantidade excede a largura de banda total de 100 MBps em todos os canais da unidade de armazenamento, isso não afunilará o sistema. Apenas um dos dois caminhos de comunicação Fibre Channel transporta tráfego durante a operação normal; o outro caminho é destinado à redundância. Se o caminho ativo falhar, o caminho em espera assumirá o controle. Ele tem capacidade suficiente para lidar com a carga total de dados.

Em seguida, os dados transitam por um switch SAN a caminho do servidor. O switch limita a quantidade de E/S que pode lidar porque precisa processar a solicitação de entrada e, em seguida, encaminhá-la para a porta apropriada. No entanto, só pode saber qual é o limite do interruptor se consultar as especificações do fabricante. Por exemplo, se o seu sistema tiver dois switches e cada switch puder lidar com 10.000 IOPS, a taxa de transferência total será de 20.000 IOPS. Com base nas regras de tolerância a falhas, se um switch parar de funcionar, a taxa de transferência total do sistema é de 10.000 IOPS. Portanto, em circunstâncias normais, não deverá usar mais de 80 de utilização de% ou 8.000 I/O.

Finalmente, o HBA instalado no servidor também limita a quantidade de E/S que ele pode suportar. Instale mais HBAs para redundância. Ao calcular a capacidade, exclua o HBA redundante. Planeje como se um HBA estivesse offline (N - 1) e dimensione o total de E/S disponíveis em um ou mais HBAs ativos restantes.

Considerações sobre cache

Os caches são um dos componentes que podem afetar significativamente o desempenho geral em qualquer lugar do sistema de armazenamento. No entanto, uma análise detalhada dos algoritmos de cache está além do escopo deste artigo. Em vez disso, aqui está uma lista rápida de coisas que você deve saber sobre cache em subsistemas de disco.

• A cache melhora o desempenho de escrita sequencial sustentada ao agrupar muitas operações menores em blocos de entrada/saída maiores. Também transfere as operações para armazenamento em alguns blocos grandes em vez de muitos blocos minúsculos. Essa otimização reduz o total de operações de E/S aleatórias e sequenciais, disponibilizando mais recursos para outras operações de E/S.
• O cache não melhora a taxa de transferência de E/S de gravação sustentada no subsistema de armazenamento porque só armazena gravações em buffer até que eixos estejam disponíveis para confirmar os dados. Quando todo o I/O disponível dos eixos está saturado por dados durante longos períodos de tempo, o cache acaba por se encher. Para esvaziar o cache, você deve fornecer E/S suficiente para que o cache se limpe, fornecendo eixos extras ou dando tempo suficiente entre as explosões para que o sistema recupere.
• Caches maiores permitem que mais dados sejam armazenados em buffer, o que significa que o cache pode lidar com períodos mais longos de saturação.
• Em subsistemas de armazenamento típicos, o sistema operacional experimenta um melhor desempenho de gravação com caches, já que o sistema só precisa gravar os dados no cache. No entanto, quando a mídia subjacente estiver saturada com operações de E/S, o cache será preenchido e o desempenho de gravação retornará à velocidade normal do disco.
• Quando você armazena E/S de leitura em cache, o cache é mais útil quando você armazena dados sequencialmente na mesa e permite que o cache leia com antecedência. A leitura antecipada é quando o cache pode se mover imediatamente para o próximo setor, como se o próximo setor contivesse os dados que o sistema solicitará em seguida.
• Quando a E/S lida é aleatória, o armazenamento em cache no controlador da unidade não aumenta a quantidade de dados que o disco pode ler. Se o tamanho do sistema operacional ou do cache baseado em aplicativo for maior do que o tamanho do cache baseado em hardware, qualquer tentativa de melhorar a velocidade de leitura do disco não mudará nada.
• No Ative Directory, o cache é limitado apenas pela quantidade de RAM que o sistema retém.

Considerações sobre SSD

As unidades de estado sólido (SSD) são fundamentalmente diferentes dos discos rígidos baseados em eixos. As SSD podem suportar volumes mais elevados de E/S com menor latência. Embora as SSD possam ser dispendiosas numa base de custo por gigabyte, são baratas numa base de custo por E/S. O planejamento de capacidade com SSDs ainda faz as mesmas perguntas centrais que com eixos: quantas IOPS elas podem lidar e qual é a latência dessas IOPS?

Aqui estão algumas coisas que você deve considerar ao planejar SSDs:

• Tanto o IOPS quanto a latência estão sujeitos aos designs do fabricante. Em alguns casos, certos designs de SSD podem ter um desempenho pior do que as tecnologias baseadas em fusos. Validar as especificações do fornecedor para cada SSD ou modelo de eixo; O desempenho e a latência variam de acordo com o design. Não trate todos os SSDs ou todos os eixos como iguais. Compare IOPS, latência, resistência, comportamento de profundidade de fila e recursos de firmware por modelo.
• Os tipos de IOPS podem ter valores diferentes, dependendo se são lidos ou gravados. Os serviços do AD DS são predominantemente baseados em leitura e, portanto, são menos afetados pela tecnologia de gravação usada em comparação com outros cenários de aplicativo.
• A resistência à escrita é o pressuposto de que as células SSD têm uma vida útil limitada e acabarão por se desgastar depois de as utilizar muito. Para unidades de banco de dados, um perfil de I/O predominantemente de leitura aumenta a durabilidade de gravação das células ao ponto em que você não precisa se preocupar tanto com a resistência de gravação.

Summary

A contenção de armazenamento compartilhado ocorre quando várias cargas de trabalho independentes competem por IOPS (operações de E/S limitadas por segundo) e largura de banda na mesma mídia subjacente ou interconexão. As fontes típicas de contenção incluem:

• Vários servidores usando o mesmo LUN SAN
• Várias VMs cujos discos virtuais residem no mesmo volume NAS
• Hosts que acessam destinos iSCSI comuns em uma malha compartilhada

Quando uma carga de trabalho gera um I/O elevado sustentado — por exemplo, backups, varreduras antivírus completas, enumerações de diretórios grandes ou tarefas de exportação ou importação em massa — a latência média e de cauda das operações de leitura e gravação aumenta para todos os utilizadores desse recurso partilhado. A latência elevada reduz diretamente a capacidade de resposta do AD DS caso NTDS.dit ou a E/S de log tenha que aguardar nas filas de dispositivos.

Fluxo de trabalho de correção recomendado:

1. Medir: Recolher estatísticas de LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Read, Avg Disk sec/Write, Reads/sec e Writes/sec, assim como do array de armazenamento (profundidade da fila, utilização do controlador), em intervalos de 15 a 60 minutos, cobrindo as janelas de pico e de manutenção.

2. Atributo: identifique qual carga de trabalho está causando picos de latência (correlacione com janelas de backup, verificações antivírus, trabalhos em lote ou atividade vizinha de VM). Use métricas por LUN/por VM quando disponíveis.

3. Classifique o tipo de problema:

   • Saturação de capacidade (IOPS ou taxa de transferência consistentemente perto da especificação do dispositivo/controlador e aumento da latência).
   • Interferência de burst (tarefas curtas de alta intensidade aumentando a latência da cauda, mas não a utilização média).
   • Ponto de estrangulamento da infraestrutura (HBA sobrescrito, switch, falha de caminho reduzindo as faixas disponíveis, driver/firmware desatualizado, política de multipath desalinhada).

4. Agir:

   • Reequilibre ou isole cargas de trabalho pesadas para separar LUNs/volumes/níveis de armazenamento.
   • Escalone ou reagende backups, verificações antivírus completas e desfragmentação fora dos períodos de pico de autenticação/consulta do AD DS.
   • Adicione ou atualize componentes de armazenamento quando o uso sustentado permanecer alto.
   • Verifique se os drivers/firmware e o software multipath estão atualizados e configurados corretamente.
   • Dimensione corretamente a RAM para que os dados acessados com frequência residam na memória, reduzindo a pressão de leitura sobre o armazenamento.

5. Validar: confirme se a latência pós-alteração retorna ao destino (por exemplo, SSD/NVMe de 2 a 6 ms, eixo de 4 a 12 ms) e se a profundidade da fila de pico permanece dentro de limites aceitáveis.

Os potenciais pontos de estrangulamento que imitam ou exacerbam a contenção de armazenamento incluem switches superescritos ou adaptadores de barramento do host compartilhando canais.

Verifique e exclua-os antes de adicionar mais discos ou mover para uma mídia mais rápida.

Sempre emparelhe dados de latência com o comprimento da fila e a utilização do dispositivo/controlador para determinar se deve otimizar, reagendar ou dimensionar.

Principais critérios de sucesso:

• Mantido Avg Disk sec/Read e Avg Disk sec/Write dentro da faixa de latência alvo durante o pico de carga do AD DS.
• Não existem períodos prolongados em que o IOPS se estabilize e a latência aumente. Se observado, isso pode indicar saturação.
• Tarefas de manutenção pesadas são executadas durante as janelas de manutenção definidas sem empurrar a latência de produção acima dos limites.

Se as metas não forem atingidas após ajustes de programação e configuração, prossiga para a expansão da capacidade ou migração para níveis de armazenamento de alto desempenho.

Apêndice D: solução de problemas de armazenamento em ambientes onde mais RAM não é uma opção

Muitas recomendações de armazenamento antes do armazenamento virtualizado serviam a dois propósitos:

• Isolamento de E/S para evitar que problemas de desempenho no eixo do sistema operacional afetem o desempenho do banco de dados e dos perfis de E/S.
• Aproveitando o aumento de desempenho que os discos rígidos com discos rotativos e caches podem oferecer ao seu sistema quando usados com E/S sequencial dos arquivos de log do AD DS. Isolando o I/O sequencial numa unidade física separada também pode aumentar o desempenho.

Com as novas opções de armazenamento, muitas suposições fundamentais por trás das recomendações de armazenamento anteriores não são mais verdadeiras. Cenários de armazenamento virtualizado, como arquivos de imagem iSCSI, SAN, NAS e Virtual Disk, geralmente compartilham mídia de armazenamento subjacente em vários hosts. O armazenamento compartilhado nega as suposições de que você deve isolar a E/S e otimizar a E/S sequencial. Agora, outros hosts que acessam a mídia compartilhada podem reduzir a capacidade de resposta ao controlador de domínio.

Você deve considerar o seguinte ao planejar o desempenho do armazenamento:

• Estado de cache frio
• Estado de cache quente
• Backup e restauração

O estado de cache frio é quando você reinicializa inicialmente o controlador de domínio ou reinicia o serviço Ative Directory, portanto, não há dados do Ative Directory na RAM. Um estado de cache quente é quando o controlador de domínio está operando em um estado estável e armazenou em cache o banco de dados. Em termos de design de desempenho, aquecer um cache frio é como um sprint, enquanto executar um servidor com um cache totalmente aquecido é como uma maratona. Definir esses estados e os diferentes perfis de desempenho que eles geram é importante, pois você precisa considerá-los ambos ao estimar a capacidade. Por exemplo, só porque você tem RAM suficiente para armazenar em cache todo o banco de dados durante um estado de cache quente não ajuda a otimizar o desempenho durante o estado de cache frio.

Para ambos os cenários de cache, o mais importante é a rapidez com que o armazenamento pode mover dados do disco para a memória. Quando você aquece o cache, com o tempo o desempenho melhora à medida que as consultas reutilizam dados, a taxa de acertos do cache aumenta e a frequência de ir ao disco para recuperar dados diminui. Como resultado, os impactos adversos no desempenho de acessar o disco também diminuem. Quaisquer degradações de desempenho são temporárias e geralmente desaparecem quando o cache atinge seu estado quente e o tamanho máximo permitido pelo sistema.

Você pode medir a rapidez com que o sistema pode obter dados do disco medindo as IOPS disponíveis no Ative Directory. Quantas IOPS disponíveis existem também está sujeito a quantas IOPS estão disponíveis no armazenamento subjacente. Você também deve considerar o planejamento para alguns estados excecionais, por exemplo:

• Aquecimento do cache após uma reinicialização
• Operações de backup
• Operações de restauração

Trate-os como estados excecionais. Execute-os fora do horário de pico. Sua duração e impacto dependem da carga atual do controlador de domínio, portanto, nenhuma regra de dimensionamento universal se aplica além de programá-los fora dos períodos de pico.

Na maioria dos cenários, o AD DS é predominantemente de E/S de leitura, com uma proporção de 90% de leitura para 10% de escrita. A E/S de leitura é o gargalo típico da experiência do usuário, enquanto a E/S de gravação é o gargalo que degrada o desempenho de gravação. Os caches tendem a fornecer benefícios mínimos para ler E/S porque as operações de E/S para o NTDS.dit arquivo são predominantemente aleatórias. Portanto, a sua principal prioridade é certificar-se de configurar corretamente o perfil de E/S de leitura no armazenamento.

Em condições normais de operação, sua meta de planejamento de armazenamento é minimizar os tempos de espera para que o sistema retorne solicitações do AD DS para o disco. O número de operações de E/S em aberto e pendentes deve ser menor ou igual ao número de caminhos no disco. Para cenários de monitoramento de desempenho, geralmente recomendamos que o contador seja inferior a LogicalDisk((<NTDS Database Drive>))\Avg Disk sec/Read 20 ms. Defina o limite operacional próximo à latência de armazenamento nativa. Direcione de 2 a 6 ms, escolhendo a extremidade inferior para mídia mais rápida (NVMe/SSD) e a extremidade superior para camadas mais lentas.

O gráfico de linhas a seguir mostra a medição da latência do disco em um sistema de armazenamento.

Vamos analisar este gráfico de linhas:

• A área à esquerda do gráfico que está circulada em verde mostra que a latência é consistente em 10 ms à medida que a carga aumenta de 800 IOPS para 2.400 IOPS. Essa linha de base de latência é afetada pelo tipo de solução de armazenamento que você usa.
• A área no lado direito do gráfico circundada em marrom mostra a taxa de transferência do sistema entre a linha de base e o final da coleta de dados. A taxa de transferência em si não muda, mas a latência aumenta. Esta área mostra o que acontece quando o volume de solicitação ultrapassa o limite físico do sistema de armazenamento. As solicitações ficam mais tempo na fila antes que o disco as responda.

Agora, vamos pensar no que esses dados nos dizem.

Primeiro, vamos supor que um usuário consultando a associação de um grupo grande exija que o sistema leia 1MB de dados do disco. Você pode avaliar a quantidade de E/S necessária e quanto tempo as operações levam com estes valores:

• O tamanho de cada página de banco de dados do Ative Directory é de 8KB.
• O número mínimo de páginas que o sistema precisa ler é de 128.
• Portanto, na área de linha de base no diagrama, o sistema deve levar pelo menos 1,28 segundos para carregar os dados do disco e devolvê-los ao cliente. Na marca de 20ms, onde o rendimento vai bem acima do máximo recomendado, o processo leva 2,5 segundos.

Com base nesses números, você pode calcular a velocidade com que o cache aquece usando esta equação:

2,400 IOPS × 8KB por operação de entrada/saída

Depois de executar esse cálculo, podemos dizer que a taxa de aquecimento do cache neste cenário é de 20MBps. Em outras palavras, o sistema carrega cerca de 1GB de banco de dados na RAM a cada 53 segundos.

Há um limite físico para a rapidez com que o cache aquece com base em como você projeta o sistema de armazenamento. A única coisa que pode aquecer o cache até a taxa que o armazenamento subjacente pode acomodar são as solicitações de entrada do cliente. A execução de scripts para tentar pré-aquecer o cache durante o horário de pico compete com as solicitações reais do cliente, aumenta a carga geral, carrega dados que não são relevantes para as solicitações do cliente e degrada o desempenho. Recomendamos que evite o uso de medidas artificiais para aquecer o cache.