Planejamento de capacidade para o Active Directory Domain Services

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

Metas de planejamento da capacidade

O planejamento de capacidade não é o mesmo que solucionar problemas de incidentes de desempenho. As metas de planejamento da capacidade são:

• Implemente e opere um ambiente corretamente.
• 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, o cliente definiu seu limite de alerta de monitoramento para problemas de desempenho em 90% em um 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 precisa tomar medidas imediatas quando problemas de desempenho afetam negativamente a experiência do cliente. Por outro lado, uma 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 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 de expansão é garantir que o hardware e o serviço possam lidar com a carga esperada. Em ambos os casos, a meta é garantir que o sistema possa lidar com a carga esperada e, ao mesmo tempo, fornecer uma boa experiência do 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

O AD DS (Active Directory Domain Services) é 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 necessária.

Informações importantes a serem consideradas antes de começar a planejar

Para tirar o máximo proveito deste artigo, você deve fazer o seguinte:

• Verifique se você leu e entendeu as Diretrizes de Ajuste de Desempenho para o Windows Server.
• A plataforma do Windows Server é uma arquitetura baseada em x64, que fornece maior espaço de endereço de memória em comparação com sistemas x86. As diretrizes deste artigo se aplicam ao seu ambiente do Active 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 ambiente tem uma DIT (árvore de informações de diretório) que pode 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ê constrói está atendendo às suas expectativas.
• Entenda que a otimização ocorre em vários ciclos de vida de hardware à medida que os custos de hardware mudam. Por exemplo, se a memória ficar mais barata, o custo por núcleo diminuirá ou o preço de diferentes opções de armazenamento mudará.
• Planeje para o período diário de maior fluxo. Recomendamos que você faça seus planos com base em intervalos de 30 minutos ou 1 hora. Considere as seguintes informações ao escolher o intervalo:
  • Intervalos maiores que uma hora podem ser ocultados quando o serviço realmente atinge a capacidade máxima.
  • Intervalos inferiores a 30 minutos podem fazer com que os aumentos transitórios pareçam mais importantes do que realmente são.
• Planejar para o crescimento ao longo do ciclo de vida do hardware da 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 exige que você estime o quanto a carga no Active 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 operando corretamente quando alguns componentes falharem. Depois de determinar a capacidade necessária (conhecida como n), você deve planejar a tolerância a falhas. Considere os cenários n + 1, n + 2 ou mesmo n + x. Por exemplo, se você precisar de dois controladores de domínio (DCs), planeje três para que possa lidar com uma falha de DC.

  • Com base em 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. Um controlador de domínio (DC) gerencia a carga de hoje, por exemplo. As previsões mostram que a carga dobra dentro de um ano e precisarão de dois DCs apenas para atender à demanda. Isso não deixa nenhuma capacidade de reposição 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 planejar adicionar um terceiro após três ou seis meses.

    Note

    Adicionar aplicativos com reconhecimento do Active Directory pode ter um impacto perceptível na carga do DC, seja a carga 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 diretrizes 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 precisar de um nível mais alto de simultaneidade e uma experiência de usuário mais consistente, você deverá considerar 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 custo mais baixo.

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, em que você tem apenas um convidado por host.
• Cenários de host compartilhados , em que você tem vários convidados por host.

Você pode tratar cenários de mapeamento direto de forma idêntica aos 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 o AD DS (Active Directory Domain Services), 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 próprio ciclo de planejamento de capacidade. 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 os fundamentos ambientais necessários para planejar a quantidade de capacidade necessária para sua implantação.
2. Determine qual 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 se tornam a linha de base para o próximo ciclo de planejamento de capacidade.

Aplicando o 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 o AD DS e o comportamento geral do software cliente compatível significam que o hardware moderno da 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 permaneça importante para todas as implantações, ambientes menores geralmente têm mais flexibilidade em suas opções de hardware, já que a maioria dos sistemas de servidor atuais pode lidar com essas cargas sem a necessidade de otimização especializada.

As tabelas nas tabelas de resumo da coleta de dados explicam como avaliar seu ambiente existente para selecionar o hardware correto. As seções seguintes entram em mais detalhes sobre recomendações de linha de base e princípios específicos do 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, portanto, não espere que ele seja perfeitamente preciso. Lembre-se sempre de ajustar a capacidade conforme necessário e validar constantemente se o ambiente está funcionando conforme o esperado.

Tabelas de resumo da coleta 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 foi colocar tanto 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 aspectos mais sutis de dimensionamento para o 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 Active Directory como um serviço. Você pode aplicar essas diretrizes a qualquer ambiente, independentemente de seu ambiente ser físico, virtualizado ou misto. Para maximizar seu desempenho, sua meta deve ser fazer com que seu ambiente AD DS seja o mais próximo possível do limite do processador.

RAM

Quanto mais armazenamento você puder armazenar em cache na RAM, menos precisará ir para o disco.

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

• Tamanho do banco de dados atual
• Quantidade recomendada para seu sistema operacional
• Recomendações do fornecedor para agentes, como:
  • Programas antivírus
  • Software de monitoramento
  • 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 alterações ambientais.

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

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

Outra coisa importante a considerar para dimensionar a memória é o tamanho 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 SO (sistema operacional) e a configuração do sistema para despejos de memória.

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

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

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

• Quanto mais você armazena em cache na RAM, menos precisa ir para o disco.
• O armazenamento é o componente mais lento de um computador. O acesso a dados em mídia de armazenamento SSD e baseada em eixo é um milhão de vezes mais lento do que o acesso a dados na RAM.

Considerações sobre virtualização para RAM

Sua meta para otimizar a RAM é minimizar o tempo gasto indo para o disco. Evite o excesso de confirmação de memória no host (alocando mais RAM para convidados do que o computador físico). A confirmação excessiva por si só não é um problema, mas se o uso total de convidado exceder a RAM do host, o host faz paginação. A paginação torna o desempenho limitado ao disco quando o DC vai para o NTDS.dit ou arquivo de paginação, ou quando a RAM é paginada pelo host. Esse comportamento reduz drasticamente o desempenho e a experiência do usuário.

Exemplo de resumo de cálculo

Recomendado: 16 GB

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%, 18 GB é 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 cliente, configurações de Política de Grupo e assim por diante. Você pode coletar dados para fazer sua estimativa usando os contadores de desempenho Network Interface(*)\Bytes Received/sec e Network Interface(*)\Bytes Sent/sec. Os intervalos de exemplo para contadores de Adaptador de Rede devem ser de 15, 30 ou 60 minutos. Qualquer coisa menos é volátil demais para boas medidas, e qualquer coisa maior suaviza excessivamente os picos diários.

Necessidades de largura de banda

O planejamento da escalabilidade de 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 consideração ao planejar a capacidade para suporte de tráfego. Primeiro, você precisa saber quanto tráfego de replicação do Active Directory vai entre seus DCs. Em segundo lugar, você deve avaliar o tráfego de cliente para servidor intra-site. O tráfego intra-site 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 ao RSS (Receive Side Scaling).

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

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

• A meta é reduzir o volume para o menor número possível de servidores. Idealmente, um servidor carrega a carga e, em seguida, você implanta outro servidor para redundância (cenário n + 1).
• Nesse cenário, o adaptador de rede atual dá suporte apenas a 100 MB e está em um ambiente comutado.
• A utilização máxima da largura de banda de 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 examinar o que o gráfico no Network Interface(*)\Bytes Sent/sec contador 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 8h às 8h15, com mais de 25 bytes enviados por segundo no controlador de domínio 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 8h às 8h15.

3. Há picos antes das 4h, com mais de 20 bytes enviados por segundo no controlador de domínio mais movimentado, o que pode indicar carga de diferentes fusos horários ou atividade de infraestrutura em segundo plano, como backups. Como o pico às 8h excede essa atividade, não é relevante.
4. Existem 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 8h e 8h15 é de 28MBps.

   Note

   Os contadores de envio/recebimento do adaptador 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 100 MB ÷ 8 = 12,5 MB e 1 GB ÷ 8 = 128 MB.

Depois de examinar os dados, quais conclusões você pode tirar do exemplo de utilização de rede?

• O ambiente atual atende ao nível n + 1 de tolerância a falhas a 60% utilização de destino. Colocar um sistema offline desloca a largura de banda por servidor de cerca de 5,5MBps (44%) para cerca de 7MBps (56%).
• Com base na meta declarada anteriormente de consolidação 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 1 GB, esse valor de largura de banda por servidor representa 22% da capacidade total.
• Em condições operacionais normais no cenário n + 1, a carga do cliente é relativamente distribuída a cerca de 14MBps por servidor ou 11% da capacidade total.
• Para garantir que você tenha capacidade suficiente enquanto um DC não estiver disponível, as metas operacionais normais por servidor são de cerca de 30% de utilização de rede ou 38 MBps por servidor. Os objetivos de failover seriam 60% de uso de rede ou 72MBps 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 dar suporte à carga necessária. Devido à quantidade de tráfego de rede, a carga da CPU das comunicações de rede pode limitar potencialmente a escalabilidade máxima do AD DS. Você pode usar esse mesmo processo para estimar a comunicação de entrada com o DC. No entanto, na maioria dos cenários, você não precisa calcular o tráfego de entrada porque ele é menor que o tráfego de saída.

É importante garantir que seu hardware suporte RSS em ambientes com mais de 5.000 usuários por servidor. Em cenários de tráfego de rede elevados, o balanceamento da carga de interrupção pode se tornar um gargalo. Você pode detectar possíveis gargalos verificando o contador para ver se o Processor(*)\% Interrupt Time tempo de interrupção é distribuído de forma irregular entre CPUs. Os NICs (controladores de adaptador de rede) habilitados para RSS podem mitigar essas limitações e aumentar a escalabilidade.

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

A recomendação típica para um servidor físico é um adaptador de 1 GB para servidores com suporte para mais de 5.000 usuários. Depois que 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 dar suporte a todos os convidados. Contabilize a largura de banda em ambos os cenários: quando o DC é executado como uma VM em um host com tráfego de rede por um comutador virtual e quando ele se conecta diretamente a um comutador físico. Switches virtuais exigem um planejamento cuidadoso de largura de banda. O uplink deve dar suporte aos dados agregados que são transmitidos por ele. O adaptador de rede de host físico vinculado ao comutador deve dar suporte à carga dc e a todos os outros convidados que compartilham o comutador virtual e se conectam por meio 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 nessa tabela, a largura de banda recomendada seria 72MBps (28,5MBps ÷ 40%).

Como sempre, você deve presumir que a carga de clientes aumentará com o tempo; portanto, planeje esse crescimento o mais cedo possível. Recomendamos que você planeje pelo menos 50% de crescimento estimado do tráfego de rede.

Armazenamento

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

• Capacidade ou tamanho do 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 usual é apenas colocar tanta RAM quanto o tamanho do banco de dados. No entanto, essa recomendação pode ser um exagero para locais satélites em ambientes maiores.

Sizing

Avaliação do armazenamento

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

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

Além dessa recomendação, você deve considerar as práticas usuais para acomodar o crescimento futuro.

Antes de avaliar seu armazenamento, você deve primeiro determinar o tamanho que NTDS.dit e SYSVOL precisam ter. Essas medidas ajudam você 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 avaliação de armazenamento, consulte Limites de Armazenamento e Estimativas de Crescimento para Usuários do Active Directory e Unidades Organizacionais.

Ao examinar ambientes existentes com vários domínios, você poderá observar variações nos tamanhos do banco de dados. Ao identificar essas variações, use o menor GC (catálogo global) e tamanhos não GC.

Os tamanhos do banco 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 executando uma versão posterior. O controlador de domínio com recursos como a Lixeira do Active Directory ou o Roaming de Credenciais habilitado também pode afetar o tamanho do banco de dados.

Considerações sobre virtualização para armazenamento

Em cenários em que você aloca vários arquivos VHD (Disco Rígido Virtual) 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. Esse tamanho de VHD fixo inclui 100% do tamanho do DIT mais 110% 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. Estes componentes incluem:

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

Desempenho do armazenamento

Como o componente mais lento em qualquer computador, o armazenamento pode causar 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, pois 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 presumiam que um disco era um eixo dedicado que permitia E/S isolada. Essa 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 (Rede de área de armazenamento)
• Arquivo VHD em um armazenamento SAN ou conectado à rede
• Unidades de Estado Sólido (SSDs)
• Unidades de memória não volátil expressa (NVMe)
• Arquiteturas de armazenamento em camadas, como armazenamento em cache de camada de armazenamento SSD maior armazenamento baseado em eixo

Outras cargas de trabalho colocadas no armazenamento de back-end podem sobrecarregar o armazenamento compartilhado, como RAID, SAN, NAS, JBOD, Espaços de Armazenamento e VHD. Esses 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 do AD podem causar limitação e atrasos. Para esclarecer, esses tipos de arquiteturas de armazenamento não são uma má opção, 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 Apêndice C e Apêndice D mais adiante neste artigo.

Essa 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.

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

Devido à quantidade de opções de armazenamento disponíveis atualmente, recomendamos que você consulte suas equipes ou fornecedores de suporte de hardware durante o planejamento para garantir que a solução atenda às necessidades de sua implantação do AD DS. Durante essas conversas, você pode achar os seguintes contadores de desempenho úteis, especialmente quando o banco de dados é muito grande para sua 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 verificar se os intervalos de exemplo são de 15, 30 ou 60 minutos para dar a imagem mais precisa do seu ambiente atual possível.

Avaliando os resultados

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

O contador LogicalDisk(<NTDS>)\Avg Disk sec/Read 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 contador LogicalDisk(<NTDS>)\Reads/sec será uma medida válida. Se os resultados forem aproximadamente iguais ao Tempo de Acesso ao Disco esperado para o tipo de disco, o contador LogicalDisk(<NTDS>)\Reads/sec será 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 a faixa 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 foi degradada o suficiente para se tornar perceptível. Para obter mais informações, consulte 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ê poderá 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 inferior de RAM, os valores resultantes poderão 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 você adicionar ou otimizar a RAM, também diminuirá a quantidade de LogicalDisk(<NTDS>)\Reads/Sec de E/S de leitura. 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 dos ambientes individuais, principalmente da carga do cliente. No entanto, recomendamos que você ajuste o tamanho do armazenamento depois de otimizar a RAM.

Considerações sobre virtualização para desempenho

Semelhante às seções anteriores, a meta de desempenho de virtualização é garantir que a infraestrutura compartilhada possa dar suporte à carga total de todos os consumidores. Tenha essa meta 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 que usa um arquivo VHD em mídia compartilhada localmente ou em uma infraestrutura SAN, NAS ou iSCSI.

Da perspectiva de um usuário convidado, ter que passar por um host para acessar qualquer armazenamento afeta o desempenho, pois o usuário deve percorrer mais caminhos de código para obter acesso. O teste de desempenho indica que a virtualização afeta a taxa de transferência com base em quanto do processador 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 necessidades de processamento em cenários virtualizados. Para obter mais informações, consulte Apêndice A.

Outras questões complicadas são quantas opções de armazenamento estão disponíveis no momento, cada uma com impactos de desempenho extremamente diferentes. Essas opções incluem armazenamento de passagem, adaptadores SCSI e IDE. Ao migrar de um ambiente físico para um virtual, você deve ajustar as 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 íntegro em condições operacionais normais:

• LogicalDisk(<NTDS Database Drive>) ÷ Transfers 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 = (LogicalDisk(<NTDS Database Drive>)) ÷ ÷ <Target Avg Disk Read/sec>de Leitura/s de Disco do Avg ) × LogicalDisk(<NTDS Database Drive>)\Read/s

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, um período de tempo aceitável seria quanto tempo deve 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 necessário 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 do armazenamento.
• Divida o tamanho do banco de dados por 8 KB para obter o número total de E/S que você precisa 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 ESE (Mecanismo de Armazenamento Extensível) 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

Avaliação do uso do processador do Active 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 conforme o esperado em 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, consumir uma quantidade excessiva de tempo da CPU às custas de outros aplicativos, aumentar as necessidades de capacidade e distribuir a carga de forma desigual nos DCs.
• O AD DS é um ambiente distribuído com muitos clientes em potencial 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 na Rede, você deve abordar a estimativa como uma avaliação da capacidade total necessária no ambiente em vez de examinar cada cliente um de cada vez.

Conclua sua estimativa de armazenamento antes de começar a estimar o uso do processador. Você não pode fazer uma estimativa precisa sem dados válidos sobre a carga do processador. Também é importante garantir que o armazenamento não esteja 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 aguardar os 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 Logical Disk(<NTDS Database Drive>)\Avg Disk sec/Read estiver acima de 10 milissegundos ou 15 milissegundos, então os dados em Process(lsass)\ Processor Time estarão artificialmente baixos e o problema estará relacionado ao desempenho do armazenamento. Recomendamos que você defina intervalos de amostragem para 15, 30 ou 60 minutos para obter os dados mais precisos possíveis.

Visão geral do processamento

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

Semelhante à seção de rede em que a demanda do ambiente é revisada site a site, o mesmo deve ser feito na capacidade de computação exigida. Ao contrário da seção de rede, em que as tecnologias de rede disponíveis excedem bastante a demanda normal, preste mais atenção ao dimensionamento da capacidade da CPU. Como qualquer ambiente de tamanho moderado; qualquer coisa acima de alguns milhares de usuários simultâneos pode colocar uma carga significativa na CPU.

Infelizmente, devido à enorme variabilidade de aplicativos cliente que usam o AD, uma estimativa geral de usuários por CPU é lamentavelmente inaplicada para 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ê estiver planejando a capacidade de um site inteiro, sua meta deve ser um design de capacidade N + 1. Nesse 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 ver dois exemplos de ambientes que estão no alvo e fora do alvo. Primeiro, vamos dar uma olhada em um exemplo de um ambiente que funciona conforme o esperado 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 operacionais normais (N + 1) e 60% caso contrário (N). Durante o horário não comercial, o uso de CPU de destino é 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 gráfico (Processor Information(_Total)\% Processor Utility), para cada um dos DCs, conforme 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 8h e 9h15. O dia útil médio dura das 5h às 17h. Portanto, todos os picos aleatórios de uso da CPU que ocorrem entre 17h e 4h estão fora do horário comercial e, portanto, você não precisa incluí-los em suas preocupações de planejamento de capacidade.

  Durante o horário fora de pico, picos breves em um sistema bem gerenciado geralmente vêm de:

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

  Picos fora dessas tarefas podem indicar uma carga anormal e merecem uma 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 têm o mesmo número de CPUs, se um deles ficar off-line, os sistemas restantes serão executados a cerca de 53%. A carga de 40% do Sistema D é então dividida uniformemente entre os sistemas restantes e adicionada à carga existente deles de 40%. Essa suposição de redistribuição linear não é perfeitamente precisa, mas fornece precisão suficiente para 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 DCs operam a 40%. Um fica offline e o DC restante salta para cerca de 80%. Durante o failover, essa carga excede o limite do plano de capacidade e reduz o espaço para 10%–20% para picos. Cada pico agora pode levar o DC a 90% ou até 100%, reduzindo a capacidade de resposta.

Calculando as demandas de CPU

O contador de desempenho Process\% Processor Time rastreia a quantidade total de tempo que todos os threads do aplicativo gastam na CPU e, em seguida, divide essa soma pela quantidade total de tempo do sistema que passou. Um aplicativo multithreaded em um sistema de várias CPUs pode exceder 100% de uso de CPU, e você deve interpretar seus dados de forma diferente do contador Processor Information\% Processor Utility. Na prática, o contador Process(lsass)\% Processor Time 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 em execução a 100% para dar suporte à carga total do AD DS. Embora uma CPU operando a 100% de capacidade seja a mais econômica em termos de consumo de energia e potência, um sistema multiencadeado é mais reativo quando não está operando a 100%. Os motivos para essa eficiência são descritos 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% da capacidade do sistema. Por exemplo, no primeiro exemplo em Perfil de comportamento do site de destino, você precisaria de 3,33 CPUs (meta de 60%) a 5 CPUs (meta de 40%) para dar suporte à 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). Medir o uso real do agente em seu ambiente e ajustar conforme necessário. Para revisitar nosso exemplo, precisaríamos de 3,43 (meta de 60%) a 5,1 (meta de 40%) de CPUs para suportar a carga durante os períodos de pico.

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

Calcular 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 deste cenário de exemplo. Esses pontos de dados vêm do Process(lsass)\% Processor Time contador de desempenho.

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

• Há três controladores de domínio no site.
• O dia útil começa a acelerar por volta das 7h e termina às 19h.
• O período mais movimentado do dia é a partir das 9h30 às 11h.

  Note

  Todos os dados de desempenho são históricos. O ponto de dados de pico às 9h15 indica a carga das 9h às 9h15.

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

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

Quando ajustar pesos LDAP

Há certos cenários em que você deve considerar o ajuste 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 uniformemente.

As seções a seguir descrevem dois cenários de exemplo em que você deve ajustar os pesos do LDAP (Lightweight Directory Access Protocol).

Exemplo 1: ambiente do emulador PDC

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

• Ferramentas de gerenciamento de Política 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 alternativa)
• Operações de criação e manutenção de confiança
• Hierarquia de serviço de tempo (fonte de tempo autoritativa no domínio/floresta)
• Processamento de bloqueio de conta
• Aplicativos herdados ou configurados incorretamente que ainda têm como destino o emulador PDC

Monitore sua CPU separadamente e planeje uma margem extra se essas atividades forem comuns.

Você deve ajustar seu emulador PDC somente se houver uma diferença perceptí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 para LDAPSrvWeight entre 50 e 75 para o emulador PDC.

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

Neste cenário de exemplo, supomos com base no perfil de comportamento do site de destino que todos os três controladores de domínio neste site tenham quatro CPUs. Em condições normais, o que aconteceria se um desses DCs tivesse oito CPUs? Haveria dois CDs com 40% de utilização e um com 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 e velocidades de CPU no mesmo site, você precisa garantir que eles estejam 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.

O planejamento de um cenário N + 1 é fundamental. O impacto de um DC ficando offline deve ser calculado para cada cenário. No exemplo anterior, a carga é compartilhada uniformemente em 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 as taxas permanecem consistentes. Quando você olha para o cenário de ajuste do emulador PDC ou qualquer cenário geral em que a carga de usuário ou aplicativo está desequilibrada, o efeito é diferente:

Considerações sobre virtualização para processamento

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

Para uma configuração com mapeamento direto (um convidado por host), reaproveite os números de planejamento de capacidade que foram coletados anteriormente. Aplique-os diretamente para dimensionar essa implantação.

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

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

Enquanto você está analisando e calculando quantas CPUs você precisa para dar suporte à 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 ao usar 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. Sempre planeje com antecedência para o crescimento.

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

Se você projetar um crescimento de 50% na demanda ao longo de três anos, planeje 18,375 CPUs (12,25 × 1,5) para esse período. Como alternativa, você pode revisar a demanda após o primeiro ano e, em seguida, adicionar capacidade extra com base no que os resultados indicam.

Carga de autenticação de cliente entre relações de confiança para NTLM

Avaliação da carga de autenticação de cliente entre relações de confiança

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

Assim como nos cenários anteriores, você deve coletar dados durante os períodos de pico do dia para que 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, também aumenta 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, ao invés disso, reconectam-se regularmente para serviços como a sincronização progressiva de email.
• 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 um estresse significativo nos DCs, especialmente quando 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 em conjunto 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 entre florestas e intraforest.
• 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 saber mais, confira Artigo da KB 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 esse sistema nesse período, os valores padrão são aceitáveis.

Monitoramento para cumprimento das metas de planejamento da capacidade

Ao longo deste artigo, discutimos como o planejamento e o dimensionamento contribuem para atingir 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 que opera acima desses limites ainda funciona, mas você precisa validar se seus aplicativos estão funcionando conforme o esperado 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 as 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 de CPU do seu ambiente.

Definições: dimensionamento da CPU

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

• Um processador de vários núcleos tem várias CPUs no mesmo circuito integrado.

• Um sistema de várias CPUs 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 perspectiva do sistema operacional.

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

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 ele representa a perspectiva do sistema operacional e do aplicativo dos mecanismos de computação disponíveis.

Paralelismo no nível do thread

Cada thread é uma tarefa independente, pois cada thread tem sua própria pilha e instruções. O AD DS pode dimensionar bem em vários processadores lógicos, pois ele é multi-threaded e pode ajustar o 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 Active Directory usando Ntdsutil.exe.

Paralelismo no nível de dados

O paralelismo no nível de dados é quando um serviço compartilha dados entre muitos threads para o mesmo processo e compartilha muitos threads em vários processos. O processo do AD DS sozinho contaria como um serviço que compartilha dados em vários threads para um único processo. Todas as 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 todas as atualizações na 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 da instrução possa continuar.

Velocidade da CPU x 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. A adição de processadores mais lógicos aumenta quantos threads 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 não linearmente 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 um trabalho paralelo executável.
• Quando uma thread trava devido a um erro de cache ou necessita de dados da memória principal, ela não pode progredir até que os dados sejam recuperados. Núcleos mais rápidos não eliminam a latência de memória; eles podem esperar mais tempo em relação à 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 dos ciclos totais.
• Sistemas mais amplos (mais soquetes/núcleos) ampliam os efeitos de latência para operações que exigem ordenação global (por exemplo, modificação de dados compartilhados, reduções de TLB, interrupções entre processadores).
• Alguns caminhos de código são seriais (Lei de Amdahl). Depois que regiões paralelas são saturadas, núcleos extras contribuem para a diminuição dos retornos.

Portanto, a adição de núcleos ou aumento da frequência de processamento só melhora a taxa de transferência do AD DS quando a carga de trabalho tem trabalho executável e paralelizável suficiente e não está predominantemente parada devido à contenção de memória, armazenamento ou bloqueio.

Em resumo, as perguntas sobre se você deve adicionar mais processadores ou processadores mais rápidos foram altamente subjetivas e devem ser consideradas caso a caso. Para o AD DS em particular, as 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. Ao tomar decisões de compra orientadas pelo orçamento, recomendamos que você primeiro otimize o uso do processador em 40% ou em qualquer número que seu ambiente específico exigir. Se o sistema não for otimizado, você não se beneficiará tanto da compra de mais processadores.

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

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

U k = B ÷ T

Onde U k é o percentual de utilização, B é a quantidade de tempo gasto sendo ocupado, e T é o tempo total gasto observando o sistema. Em um contexto da Microsoft, isso significa o número de threads de intervalo de 100 nanossegundos (ns) que estão em um estado em execução dividido por quantos intervalos de 100 ns estavam disponíveis no intervalo de tempo especificado. Essa é a mesma fórmula que calcula a porcentagem de utilização do processador mostrada no Objeto processador 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, em que N é o comprimento da fila. O gráfico dessa equação em todos os intervalos de utilização fornece as estimativas a seguir de tempo de fila para entrar no processador em qualquer carga de CPU.

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

Para entender como a teoria do enfileiramento se aplica à implantação do AD DS, vamos retornar à metáfora da rodovia que usamos em Considerações sobre a velocidade da CPU x considerações de vários núcleos.

Os horários mais movimentados no meio da tarde cairiam em algum lugar na faixa de capacidade de 40% a 70%. Há tráfego suficiente para que sua capacidade de escolher uma faixa para dirigir não seja severamente restrita. Embora a chance de outro motorista atrapalhar seja alta, ainda não é preciso fazer o mesmo esforço para encontrar uma lacuna segura entre outros carros na pista, como acontece durante a hora do rush.

À medida que a hora do rush se aproxima, o sistema viário se aproxima de 100% da capacidade. Mudar de faixa durante a hora do rush é muito desafiador porque os carros estão tão próximos que você não tem tanto espaço de manobra ao mudar de faixa. O comportamento de enfileiramento explica a meta de uma capacidade média de 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 pico maiores (como o aumento na manhã após um feriado).

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

• Traduzindo o 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 na variável X no cálculo PERF_100NSEC_TIMER_INV
  • T = o número total de intervalos de 100 ns em um determinado intervalo de tempo. A alteração na variável Y no cálculo PERF_100NSEC_TIMER_INV .
  • U k = O percentual de utilização do processador lógico pelo Thread Ocioso ou % Tempo Ocioso.
• Estimando os cálculos:
  • U k = 1 – %Tempo de Processador
  • %Tempo do Processador = 1 – U k
  • %Processor Time = 1 – B / T
  • %Processor Time = 1 – X1 – X0 / Y1 – Y0

Aplicar 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 alvo com base na carga atual e, em seguida, calcular o número de processadores lógicos necessários para atingir essa meta. 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 de memória
• Agendamento e sincronização de threads
• Cargas de cliente balanceadas com defeito

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

Também é importante lembrar que a recomendação de 40%, neste caso, não é um requisito obrigatório. Nós o usamos 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, em média, 80%–90% CPU e ainda atender às expectativas do usuário se os tempos de espera da fila não aumentarem consideravelmente. Trate isso como uma exceção, valide com dados de latência e monitore de perto a concorrência emergente.

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

• Se você adicionar processadores a um sistema executado com 90% de utilização vinculada ao disco, isso provavelmente não melhorará significativamente o desempenho. Se você observar o sistema mais de perto, há muitos threads que nem estão entrando no processador porque estão aguardando a conclusão das operações de E/S.

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

  Note

  O contador Processor Information(*)\% Processor Utility pode exceder 100% com sistemas que possuem 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 da CPU e as descrições dos contadores.

A discussão de 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 aplicam 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 ter 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 rodovia das seções anteriores, só que desta vez vamos imaginar a VM convidada como um ônibus 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 paradas.

Vamos imaginar quatro cenários:

• Os horários fora de pico de um sistema são como andar de ônibus expresso tarde da noite. Quando o motociclista entra, quase não há outros passageiros e a estrada está quase vazia. Como não há tráfego para o ônibus enfrentar, a viagem é fácil e tão rápida quanto se o passageiro tivesse dirigido até lá em seu próprio carro. No entanto, o limite de velocidade local pode restringir o tempo de viagem do piloto.
• Fora do horário de pico, quando a utilização da CPU de um sistema é muito alta, é como uma corrida noturna quando a maioria das pistas da rodovia está fechada. Mesmo que o ônibus em si esteja quase vazio, a estrada ainda está congestionada por causa do trânsito restante devido às faixas restritas. Embora o passageiro seja livre para se sentar onde quiser, o tempo real da viagem é determinado pelo trânsito fora do ônibus.
• Um sistema com alta utilização da CPU durante os horários de pico é como um ônibus lotado na hora do rush. Não só a viagem demora mais, mas entrar e sair do ônibus é mais difícil porque o ônibus está lotado 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ânsito adicionando mais ônibus. O problema não é o número de ônibus, mas quanto tempo leva a viagem.
• Um sistema com alta utilização da CPU fora do horário de pico é como o mesmo ônibus lotado em uma estrada quase vazia à noite. Embora os passageiros possam ter dificuldade para encontrar lugares ou entrar e sair do ônibus, a viagem é bastante suave uma vez que o ônibus pega todos os passageiros. Esse cenário é o único em que o desempenho melhoraria adicionando 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 graus variados 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 à meta recomendada de 40% de utilização da CPU para hosts e convidados.

Apêndice B: considerações sobre diferentes velocidades de processadores

No Processamento, presumimos que o processador está em execução a 100% velocidade do relógio 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 Windows Server 2008 R2 e versões posteriores, em que o plano de energia padrão é equilibrado, essas suposições ainda funcionam para estimativas conservadoras. Embora possíveis erros 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 na metade da velocidade em que você coletou seus dados, a estimativa mais precisa de sua demanda seria 5,125 ÷ 2.
• É impossível garantir que dobrar a velocidade do clock dobre a quantidade de processamento que ocorre dentro do período de tempo registrado. A quantidade de tempo que os processadores gastam esperando pela RAM ou outros componentes permanece praticamente a mesma. Portanto, processadores mais rápidos podem gastar uma porcentagem maior de tempo ocioso enquanto aguardam o sistema buscar dados. Recomendamos que você fique com o menor denominador comum, mantenha suas estimativas conservadoras e evite presumir uma comparação linear entre as velocidades do processador que possa tornar seus resultados incorretos.

Se as velocidades do processador no hardware de substituição forem menores do que no hardware atual, você deverá aumentar proporcionalmente a estimativa de quantos processadores são necessários. Por exemplo, vejamos um cenário em que você calcula que são necessários 10 processadores para sustentar a carga do seu site. Os processadores atuais rodam a 3,3 GHz, e os processadores pelos quais você pretende substituí-los rodam a 2,6 GHz. Substituir apenas os 10 processadores originais daria a você uma 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 do clock do processador se ajustam 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 alto. O objetivo final é que a CPU tenha 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 limitando as velocidades da CPU durante cenários fora do pico.

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

1. Acesse o site da Standard Performance Evaluation Corporation (SPEC).

2. Selecione Resultados.

3. Insira CPU2006 e selecione Pesquisar.

4. No menu suspenso para Configurações Disponíveis, selecione Todos os CPU2006 DE ESPECIFICAÇÃO.

5. No campo Pesquisar solicitação de formulário, selecione Simples e, em seguida, selecione Agora!.

6. Em Solicitação Simples, insira os critérios de pesquisa para o processador de destino. Por exemplo, se você estiver procurando um processador E5-2630, no menu suspenso, selecione Processador e insira 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 # Núcleos .

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 de pontuação de linha de base por núcleo) × (MHz por núcleo da plataforma de destino))

   Por exemplo, veja como encontrar 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 com este 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 de enfileiramento discutidos em Tempo de resposta e como os níveis de atividade do sistema afetam o desempenho também se aplicam ao armazenamento. Você precisa se familiarizar com a forma como seu sistema operacional lida com a 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 matriz ou SAN como um disco físico. Os controladores de matriz e SANs também podem agregar vários discos em um único conjunto de matrizes, dividi-lo em várias partições e 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, rotulados como Dados 1 e Dados 2. O sistema operacional registra cada uma dessas á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 neste Apêndice.

• Um eixo é o dispositivo instalado fisicamente 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 ao falar sobre SANs.
• Um disco inclui qualquer eixo ou partição que o sistema operacional registra 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 arquitetura de sistema operacional

O sistema operacional cria uma fila de E/S FIFO (First In, First Out) para cada disco registrado. 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. Mantendo uma fila de E/S separada para cada eixo ou matriz, o sistema operacional impede que os discos concorram 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 final da fila, independentemente de quando o sistema operacional os recebeu. Aplicativos que não são codificados para usar a configuração de baixa prioridade passam a ter, por padrão, prioridade normal.

Introdução aos 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 do subsistema de armazenamento, vamos obter o seguinte:

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

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

Em seguida, vamos analisar esses itens componente por componente.

Momentos 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 o cabeçote 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 leva para o cabeçote ler ou gravar os dados no disco, uma vez que está no local correto. Portanto, o tempo médio para ler um bloco exclusivo 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 exige que o cabeçote se mova 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 suportar aproximadamente 100 E/S por segundo (IOPS).

Quando todas as E/Ss ocorrem de setores adjacentes no disco rígido, chamamos de E/S sequencial. A E/S sequencial não adiciona tempo extra de busca. Após a conclusão da primeira E/S, o cabeçalho de leitura/gravação já está posicionado no próximo bloco de dados. Por exemplo, um HD de 10.000 RPM é capaz de suportar 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 foi 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 em qual aplicativo está gravando na unidade, a quantidade de dados extraídos por E/S também muda. Por exemplo, se o tamanho do bloco for 8KB, 100 operações de E/S lerão ou gravarão no disco rígido um total de 800 KB. No entanto, se o tamanho do bloco for de 32 KB, 100 E/S lerão ou gravarão 3.200 KB (3,2 MB) 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, confira as tabelas a seguir:

O backplane SCSI

A forma como o backplane SCSI, que neste cenário de exemplo é o cabo chato, afeta a taxa de transferência do subsistema de armazenamento depende do tamanho do bloco. Quanta E/S o barramento pode processar se estiver em blocos de 8KB? Nesse cenário, o barramento SCSI é de 20 MBps ou 20.480 KB/s. 20480KB/s divididos por blocos de 8KB produzem um máximo de aproximadamente 2500 IOPS suportados pelo barramento SCSI.

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

O adaptador SCSI

Para determinar quanta E/S 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 suportar depende do adaptador SCSI ou do processador do controlador de matriz.

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

O barramento PCI

O barramento PCI é um componente frequentemente esquecido. Neste cenário de exemplo, o barramento PCI não é o gargalo. No entanto, à medida que os sistemas são expandidos, 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 que opera a 33 Mhz possa transferir 133MBps de dados.

Um barramento PCI de 66MHz de 64 bits pode dar suporte a 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 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.

Analisar subsistemas de armazenamento para encontrar gargalos

Nesse cenário, o eixo é o fator limitante para a quantidade de E/S 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 transmitíveis é de 100 incrementos aleatórios de E/S 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 somente 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 analisar uma tabela que mostra onde os gargalos podem ocorrer à medida que adicionamos e alteramos componentes no subsistema de armazenamento.

Introdução ao RAID

Quando você introduz um controlador de matriz em seu subsistema de armazenamento, ele não muda 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 os distribui em 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.000RPM, o uso de RAID 0 permite que você execute 100 operações de E/S. A quantidade total de E/S que o sistema dá suporte é N spindles vezes 100 1/O por segundo por eixo ou N eixos × 100 E/S por segundo por eixo.

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 leitura de E/S, ele pode ler dados de ambos os eixos no conjunto. Esse espelhamento disponibiliza a capacidade de E/S para ambos os discos durante uma operação de leitura. No entanto, o RAID 1 não oferece nenhuma vantagem de desempenho às operações de gravação, porque o sistema também precisa espelhar os 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 ocorrendo nesse cenário:

Ler E/S + 2 × E/S total de E /S = de gravação consumida

Quando você sabe a proporção de leituras e gravações e o número de eixos em sua implantação, é possível usar esta equação para calcular quanta E/S sua matriz pode suportar:

IOPS máximas por eixo × 2 eixos × [(% de leituras + % de gravações) ÷ (% de leituras + 2 × % de gravações)] = IOPS totais

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

IOPS máximas por eixo × 2 eixos × [(% de leituras + % de gravações) ÷ (% de leituras + 2 × % de gravações)] = E/S total

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

N × {IOPS máximo por eixo × 2 eixos × [(% lê + % gravações) ÷ ( leituras de% + 2 × gravações de%)]} = IOPS total

Às vezes, chamamos de RAID 5 N + 1 RAID porque o sistema distribui os dados em N eixos e grava informações de paridade no eixo + 1. No entanto, o RAID 5 usa mais recursos ao executar uma E/S de gravação do que o RAID 1 ou RAID 1 + 0. O RAID 5 executa o seguinte processo toda vez 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. Grave os novos dados.
4. Grave a nova paridade.

Cada solicitação de E/S de gravação que o sistema operacional envia ao controlador de matriz requer quatro operações de E/S para ser concluída. Portanto, as solicitações de gravação RAID N + 1 levam quatro vezes mais 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 transformam em quantas solicitações os eixos recebem, use esta equação:

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

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

IOPS por eixo × (eixos – 1) × [(% de leituras + % de gravações) ÷ (% de leituras + 4 × % de gravações)] = IOPS totais

Apresentando SANs

Quando você introduz uma SAN (rede de área de armazenamento) em seu ambiente, isso não afeta os princípios de planejamento que descrevemos nas seções anteriores. No entanto, você deve levar em conta que a SAN pode alterar o comportamento de E/S de todos os sistemas conectados a ela. Uma SAN adiciona redundância em comparação com o armazenamento interno ou anexado direto. Você ainda deve planejar a tolerância a falhas. Suponha que um ou mais caminhos, controladores ou prateleiras possam falhar sem comprometer a utilização esperada do restante. Além disso, à medida que você introduz mais componentes em seu sistema, também precisa levar em consideração 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 PCI (interconexão de componente periférico)

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 param 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, pois esses componentes geralmente não ficam online, a menos que haja uma emergência. Por exemplo, se sua SAN tiver dois módulos controladores, você só precisará usar um ao calcular a taxa de transferência total de E/S disponível, pois o outro não será ativado a menos que o módulo original pare de funcionar. Você também não deve incluir o switch SAN redundante, a unidade de armazenamento ou os eixos nos cálculos de E/S.

Além disso, como seu planejamento de capacidade considera apenas períodos de pico de uso, você não deve fatorar componentes redundantes em seus recursos disponíveis. O pico de utilização não deve exceder 80% de saturação do sistema para acomodar intermitências 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, o que mais limita o desempenho 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 que fez ao calcular quantos recursos estavam disponíveis no barramento SCSI: dividir a largura de banda pelo tamanho do bloco. Por exemplo, se sua unidade de armazenamento tiver seis canais que dão suporte a uma taxa de transferência máxima de 20MBps, sua quantidade total de E/S disponível e transferência de dados será de 100MBps. Seis canais a 20MBps cada um dão 120MBps teóricos. Limitamos a taxa de transferência planejada em 100MBps (design N+1). Se um canal falhar, os cinco restantes (5 × 20MBps) ainda entregarão os 100MBps necessários. Este exemplo também pressupõe que o sistema esteja distribuindo uniformemente a carga e a tolerância a falhas em todos os canais.

A capacidade de transformar o exemplo anterior em um perfil de E/S depende do comportamento do aplicativo. Para o I/O do Jet do Active Directory, o valor máximo seria de aproximadamente 12.500 I/O por segundo, ou 100MBps ÷ 8KB por I/O.

Para entender que taxa de transferência seus módulos controladores suportam, você também precisa obter as especificações do fabricante. Neste exemplo, a SAN tem dois módulos de controlador que dão suporte à E/S de 7.500 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 é 7.500 IOPS. Supondo que o tamanho do bloco seja 4KB, esse limite está bem abaixo do máximo de 12.500 IOPS que os canais de armazenamento podem dar suporte e, portanto, é o gargalo em sua análise. No entanto, para fins de planejamento, a E/S máxima desejada para a qual você deve se planejar é de 10.400 E/S.

Quando os dados saem do módulo do controlador, ele transmite uma conexão Fibre Channel avaliada em 1GBps ou 128MBps. Como esse valor excede a largura de banda total de 100MB/s em todos os canais de armazenamento da unidade, ele não causará gargalo no sistema. Apenas um dos dois caminhos Fibre Channel transmite o tráfego durante a operação normal; o outro caminho é reservado para redundância. Se o caminho ativo falhar, o caminho em espera assumirá o controle. Ele tem capacidade suficiente para lidar com a carga de dados completa.

Em seguida, os dados passam por um switch SAN a caminho do servidor. O switch limita a quantidade de E/S que consegue suportar porque precisa processar a solicitação de entrada e encaminhá-la para a porta apropriada. No entanto, só é possível saber o limite do switch se observar as especificações do fabricante. Por exemplo, se o seu sistema tiver dois comutadores e cada comutador suportar 10.000 IOPS, a capacidade total será de 20.000 IOPS. Com base nas regras de tolerância a falhas, se um comutador parar de funcionar, a taxa de transferência total do sistema será de 10.000 IOPS. Portanto, em circunstâncias normais, você não deve usar mais de 80% de utilização ou 8.000 E/S.

Por fim, 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 tamanho total de E/S disponível 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 o cache em subsistemas de disco.

• O cache melhora a E/S de gravação sequencial sustentada porque armazena em buffer muitas operações de gravação menores em blocos de E/S maiores. Ele também reorganiza as operações para armazenamento em alguns blocos grandes, em vez de muitos pequenos. 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 armazena em buffer apenas as gravações até que os eixos estejam disponíveis para confirmar os dados. Quando toda a E/S disponível dos eixos é saturada por dados por longos períodos de tempo, o cache eventualmente é preenchido. Para esvaziar o cache, você deve fornecer E/S suficiente para a limpeza do cache, fornecendo eixos extras ou dando tempo suficiente entre as intermitências para que o sistema se atualize.
• Caches maiores permitem que mais dados sejam armazenados em buffer, o que significa que o cache pode suportar períodos mais longos de saturação.
• Em subsistemas de armazenamento típicos, o sistema operacional experimenta um desempenho de gravação aprimorado com caches, pois 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 adiante. A leitura antecipada é quando o cache pode ser movido 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 de leitura é aleatória, o cache no controlador da unidade não aumenta a quantidade de dados que o disco pode ler. Se o tamanho do cache baseado em sistema operacional ou aplicativo for maior que o tamanho do cache baseado em hardware, qualquer tentativa de aumentar a velocidade de leitura do disco não alterará nada.
• No Active Directory, o cache é limitado apenas pela quantidade de RAM que o sistema contém.

Considerações do SSD

As unidades de estado sólido (SSDs) são fundamentalmente diferentes dos discos rígidos baseados em eixo. Os SSDs suportam volumes maiores de E/S com menor latência. Embora os SSDs possam ser caros em uma base de custo por Gigabyte, eles são baratos em uma base de custo por E/S. O planejamento de capacidade com SSDs ainda faz as mesmas perguntas principais que com eixos: quantos IOPS eles podem lidar e qual é a latência desses IOPS?

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

• Tanto as IOPS quanto a latência estão sujeitas aos designs do fabricante. Em alguns casos, certos designs de SSD podem ter um desempenho pior do que as tecnologias baseadas em eixo. Valide as especificações do fornecedor para cada modelo SSD ou spindle; 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, profundidade de fila e recursos de firmware por modelo.
• Os tipos de IOPS podem ter valores diferentes, caso sejam 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 que você usa em comparação com outros cenários de aplicativo.
• A resistência de gravação é a suposição de que as células SSD têm uma vida útil limitada e acabarão se desgastando depois de muito uso. Para unidades de banco de dados, um perfil de E/S predominantemente de leitura estende a resistência de gravação das células até o ponto em que você não precisa se preocupar muito 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 ou interconexão subjacente. As fontes de contenção típicas incluem:

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

Quando uma carga de trabalho gera alta E/S sustentada, como backups, verificações 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 aumentam para todos os consumidores do recurso compartilhado. A latência elevada reduz diretamente a capacidade de resposta do AD DS se a E/S de log ou NTDS.dit tiver que aguardar nas filas do dispositivo.

Fluxo de trabalho de correção recomendado:

1. Medida: coletar LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Read, Avg Disk sec/Write, Reads/sec, Writes/sece estatísticas de matriz de armazenamento (profundidade da fila, utilização do controlador) em intervalos de 15 a 60 minutos que abrangem janelas de pico e manutenção.

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

3. Classificar tipo de problema:

   • Saturação de capacidade (IOPS ou throughput consistentemente perto da especificação do dispositivo/controlador, com a latência aumentando).
   • Interferência de explosões (tarefas curtas de alta intensidade que aumentam a latência da cauda sem afetar a utilização média).
   • Ponto de estrangulamento de infraestrutura (HBA subscrito, comutador, failover de caminho reduzindo as faixas disponíveis, driver/firmware desatualizado, política multicamada desalinhada).

4. Agir:

   • Rebalancee ou isole cargas de trabalho pesadas em LUNs/volumes/camadas de armazenamento separadas.
   • Escalonar ou reagendar backups, verificações antivírus completas e desfragmentação fora dos períodos de autenticação/consulta de pico do AD DS.
   • Adicione ou atualize componentes de armazenamento quando o uso contínuo ficar elevado.
   • Verifique se os drivers/firmware e os softwares de multipath estão atuais e configurados corretamente.
   • Dimensione corretamente a RAM para que os dados acessados com frequência permaneçam na memória, reduzindo a pressão de leitura sobre o armazenamento.

5. Validar: Confirme que a latência pós-alteração retorna aos valores definidos (por exemplo, 2 a 6 ms para SSD/NVMe, 4 a 12 ms para disco rígido) e que a profundidade máxima da fila permanece dentro dos limites aceitáveis.

Possíveis pontos de estrangulamento que imitam ou exacerbam a contenção de armazenamento incluem comutadores superalocados ou adaptadores de barramento de host compartilhando faixas de dados.

Verifique e desmarque-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 deseja otimizar, reagendar ou escalar horizontalmente.

Principais critérios de sucesso:

• Mantido o Avg Disk sec/Read e Avg Disk sec/Write dentro do intervalo de latência alvo durante o pico de carga do AD DS.
• Não há períodos prolongados em que o IOPS estabilize e a latência suba. Se observado, isso pode indicar saturação.
• Tarefas de manutenção pesada são executadas durante janelas de manutenção definidas sem aumentar a latência de produção acima dos limites estabelecidos.

Se as metas não forem atingidas após os ajustes de agendamento e configuração, prossiga para expansão de capacidade ou migração para camadas de armazenamento de alto desempenho.

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

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

• Isolar a E/S para evitar que problemas de desempenho no eixo do sistema operacional afetassem o desempenho do banco de dados e dos perfis de E/S.
• Aproveitar o aumento de desempenho que os discos rígidos e caches baseados em eixo podem proporcionar ao sistema quando usados com a E/S sequencial dos arquivos de log do AD DS. Isolar a E/S sequencial em uma unidade física separada também pode aumentar a taxa de transferência.

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 iSCSI, SAN, NAS e arquivos de imagem de Disco Virtual, 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 a capacidade para o desempenho de armazenamento:

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

O estado de cache frio é quando você reinicia inicialmente o controlador de domínio ou reinicia o serviço do Active Directory, portanto, não há dados do Active Directory na RAM. Um estado de cache quente é quando o controlador de domínio está operando em um estado estável e armazena 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 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 ocorrências do cache aumenta e a frequência de acesso ao disco para recuperar dados diminui. Como resultado, os impactos adversos no desempenho de ter que 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 o IOPS disponível no Active Directory. A quantidade de IOPS disponíveis também está sujeita a quantas IOPS estão disponíveis no armazenamento subjacente. Você também deve considerar o planejamento de alguns estados excepcionais, por exemplo:

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

Trate-os como estados excepcionais. Execute-as 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 agendá-los fora dos períodos de pico.

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

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 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 LogicalDisk((<NTDS Database Drive>))\Avg Disk sec/Read tenha menos de 20 ms. Defina o limite operacional próximo à latência de armazenamento nativa. Alvo de 2 a 6 ms, escolhendo o limite inferior para mídia mais rápida (NVMe/SSD) e o limite 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 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 circulada em bordô 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. Essa área mostra o que acontece quando o volume de solicitação passa o limite físico do sistema de armazenamento. As solicitações ficam na fila por mais tempo antes que o disco as atenda.

Agora, vamos pensar sobre o que esses dados nos dizem.

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

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

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

2.400 IOPS × 8KB por 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 1 GB 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. Executar scripts para tentar pré-ativar o cache durante o horário de pico compete com solicitações reais do cliente, aumenta a carga geral, carrega dados que não são relevantes para solicitações de cliente e degrada o desempenho. Recomendamos que você evite usar medidas artificiais para aquecer o cache.