Planejamento de capacidade para o Active Directory Domain Services

Este tópico foi originalmente escrito por Ken Brumfield, Gerente de programas da Microsoft, e fornece recomendações para planejamento de capacidade para o AD DS (Active Directory Domain Services).

Metas de planejamento da capacidade

O planejamento da capacidade não é o mesmo que solucionar problemas de incidentes de desempenho. Eles estão intimamente relacionados, mas são bem diferentes. As metas de planejamento da capacidade são:

• Implementar e operar um ambiente corretamente
• Minimizar o tempo gasto para solucionar problemas de desempenho.

No planejamento da capacidade, uma organização pode ter um destino de linha de base de 40% de utilização do processador durante períodos de pico para atender aos requisitos de desempenho do cliente e alocar o tempo necessário para atualizar o hardware no datacenter. Considerando que, para ser notificado sobre incidentes de desempenho anormais, um limite de alerta de monitoramento pode ser definido em 90% em um intervalo de 5 minutos.

A diferença é que quando um limite de gerenciamento da capacidade é continuamente excedido (um evento único não é preocupante), adicionar capacidade (ou seja, adicionar mais processadores ou processadores mais rápidos) seria uma solução ou dimensionar o serviço entre vários servidores seria uma solução. Os limites de alerta de desempenho indicam que a experiência do cliente está sofrendo no momento e etapas imediatas são necessárias para resolver o problema.

Fazendo uma analogia: o gerenciamento de capacidade é como se evita um acidente de carro (com direção defensiva, ao garantir que os freios estejam funcionando corretamente e assim por diante), enquanto a solução de problemas de desempenho é o que a polícia, os bombeiros e os médicos da emergência fazem após um acidente. Trata-se da "direção defensiva" ao estilo Active Directory.

Nos últimos anos, as diretrizes de planejamento da capacidade para sistemas de expansão mudaram drasticamente. As seguintes alterações nas arquiteturas do sistema desafiaram suposições fundamentais sobre como projetar e dimensionar um serviço:

• Plataformas de servidor de 64 bits
• Virtualização
• Maior atenção ao consumo de energia
• Armazenamento SSD
• Cenários de nuvem

Além disso, a abordagem está mudando de um exercício de planejamento da capacidade baseado em servidor para um exercício de planejamento da capacidade baseado em serviço. O AD DS, um serviço distribuído desenvolvido que muitos produtos da Microsoft e de terceiros usam como back-end, torna-se um dos produtos que mais necessitam ser planejados corretamente para garantir a capacidade necessária para que outros aplicativos sejam executados.

Requisitos de linha de base para diretrizes de planejamento da capacidade

Ao longo deste artigo, os seguintes requisitos de linha de base são esperados:

• Os leitores leram e estão familiarizados com as Diretrizes de ajuste de desempenho para o Windows Server 2012 R2.
• A plataforma do Windows Server é uma arquitetura baseada em x64. Mas mesmo que seu ambiente do Active Directory esteja instalado no Windows Server 2003 x86 (além do fim do ciclo de vida de suporte agora) e tenha uma DIT (árvore de informações de diretório) com menos 1,5 GB de tamanho e que possa ser facilmente mantida na memória, as diretrizes deste artigo ainda serão aplicáveis.
• O planejamento da capacidade é um processo contínuo e você deve examinar regularmente até que ponto o ambiente está atendendo às expectativas.
• A otimização ocorrerá em vários ciclos de vida de hardware à medida que os custos de hardware mudarem. Por exemplo, a memória fica mais barata, o custo por núcleo diminui ou o preço de diferentes opções de armazenamento é alterado.
• Planejar para o período de pico ocupado do dia. É recomendável conferir isso em intervalos de 30 minutos ou por hora. Períodos maiores podem ocultar os picos reais e os menores podem ser distorcidos pelos "picos transitórios".
• Planejar para o crescimento ao longo do ciclo de vida do hardware da empresa. Isso pode incluir uma estratégia de atualização ou adição de hardware de maneira escalonada ou uma atualização completa a cada três ou cinco anos. Cada um deles exigirá uma "suposição" do quanto a carga no Active Directory crescerá. Os dados históricos, se coletados, ajudarão nessa avaliação.
• Planejar para tolerância a falhas. Depois que uma estimativa N for derivada, planeje cenários que incluam N – 1, N – 2, N – x.

  • Adicione mais servidores de acordo com a necessidade organizacional para garantir que a perda de um ou vários servidores não exceda as estimativas máximas de capacidade de pico.

  • Considere também que o plano de crescimento e o plano de tolerância a falhas precisam ser integrados. Por exemplo, se um DC for necessário para dar suporte à carga, mas a estimativa é que a carga será duplicada no próximo ano e exigirá dois DCs no total, não haverá capacidade suficiente para dar suporte à tolerância a falhas. A solução seria começar com três DCs. Também seria possível planejar para adicionar o terceiro DC após 3 ou 6 meses se os orçamentos estiverem apertados.

    Observação

    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.

Processo de três etapas para o ciclo de planejamento da capacidade

No planejamento da capacidade, primeiro decida qual qualidade de serviço é necessária. Por exemplo, um datacenter principal dá suporte a um nível mais alto de simultaneidade e exige uma experiência mais consistente para usuários e aplicativos de consumo, o que exige maior atenção à redundância e à minimização de gargalos de sistema e infraestrutura. Por outro lado, uma localização por satélite com uma porção de usuários não precisa do mesmo nível de simultaneidade ou tolerância a falhas. Portanto, o escritório satélite pode não precisar de tanta atenção para otimizar o hardware e a infraestrutura subjacentes, o que pode levar a uma economia de custos. Todas as recomendações e diretrizes contidas aqui servem para o desempenho ideal e podem ser seletivamente flexibilizadas para cenários com requisitos menos exigentes.

A próxima pergunta é: virtualizado ou físico? Do ponto de vista do planejamento da capacidade, não há resposta certa ou errada, mas um conjunto diferente de variáveis com as quais trabalhar. Os cenários de virtualização se resumem em uma das duas opções:

• "Mapeamento direto" com um convidado por host (no qual a virtualização existe exclusivamente para abstrair o hardware físico do servidor)
• "Host compartilhado"

Cenários de teste e produção indicam que o cenário de "mapeamento direto" pode ser tratado de forma idêntica a um host físico. O "Host compartilhado", no entanto, apresenta uma série de considerações explicadas em mais detalhes mais tarde. O cenário de "host compartilhado" significa que o AD DS também está competindo por recursos e existem considerações sobre penalidades e ajustes para fazer isso.

Com essas considerações em mente, o ciclo de planejamento da capacidade é um processo iterativo de três etapas:

1. Medir o ambiente existente, determinar onde estão os gargalos do sistema no momento e obter as noções básicas ambientais necessárias para planejar a quantidade de capacidade necessária.
2. Determinar o hardware necessário de acordo com os critérios descritos na etapa 1.
3. Monitorar e validar se a infraestrutura implementada está operando dentro das especificações. Alguns dados coletados nesta etapa se tornam a linha de base para o próximo ciclo de planejamento da capacidade.

Aplicando o processo

Para otimizar o desempenho, verifique se esses componentes principais foram corretamente selecionados e ajustados para as cargas do aplicativo:

1. Memória
2. Rede
3. Armazenamento
4. Processador
5. Logon de Rede

Os requisitos básicos de armazenamento do AD DS e o comportamento geral do software cliente bem escrito permitem que ambientes que possuem de 10.000 a 20.000 usuários dispensem o investimento pesado no planejamento da capacidade em relação ao hardware físico, pois quase todo sistema de classe de servidor moderno tratará a carga. Sendo assim, a tabela a seguir resume como avaliar um ambiente existente para selecionar o hardware certo. Cada componente é analisado detalhadamente nas seções subsequentes para ajudar os administradores do AD DS a avaliar a infraestrutura deles usando recomendações de linha de base e entidades de segurança específicas do ambiente.

Em geral:

• Todo dimensionamento com base nos dados atuais será preciso somente para o ambiente atual.
• Em qualquer estimativa, espere que a demanda cresça ao longo do ciclo de vida do hardware.
• Determine se irá dimensionar hoje e crescer no ambiente maior ou adicionará capacidade ao longo do ciclo de vida.
• Na virtualização, todas as mesmas entidades de planejamento da capacidade e metodologias são aplicáveis, com exceção da sobrecarga de virtualização que precisa ser adicionada a tudo relacionado ao domínio.
• O planejamento da capacidade, como tudo que ele tenta prever, NÃO é uma ciência exata. Não espere que as coisas sejam perfeitamente calculadas e com 100% de precisão. A orientação aqui é a recomendação mais simples: adicionar capacidade para segurança adicional e validar continuamente se o ambiente permanece no destino.

Tabelas de resumo da coleta de dados

Novo ambiente

Componente	Estimativas
Tamanho do Banco de dados/Armazenamento	De 40 KB a 60 KB para cada usuário
RAM	Tamanho do banco de dados Recomendações de sistema operacional base Aplicativo de terceiros
Rede	1 GB
CPU	1000 usuários simultâneos para cada núcleo

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

Componente	Critérios de avaliação	Considerações sobre o planejamento
Tamanho do Banco de dados/Armazenamento	A seção intitulada "Para ativar o registro em log do espaço em disco que é liberado por desfragmentação" em Limites de armazenamento
Desempenho de Banco de dados/Armazenamento	"LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Read", "LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Write", "LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Transfer" "LogicalDisk(<NTDS Database Drive>)\Reads/s", "LogicalDisk(<NTDS Database Drive>)\Writes/sec", "LogicalDisk(<NTDS Database Drive>)\Transfers/sec"	O armazenamento tem duas questões a serem resolvidas O espaço disponível, que com o tamanho do armazenamento baseado em eixo e em SSD atualmente é irrelevante na maioria dos ambientes do AD. As operações de E/S (entrada/saída) disponíveis – em muitos ambientes, isso geralmente é ignorado. Mas é importante avaliar apenas ambientes em que não há RAM suficiente para carregar todo o Banco de Dados NTDS na memória. O armazenamento pode ser um tópico complexo e deve envolver a experiência do fornecedor de hardware para que seja dimensionado adequadamente. Particularmente em cenários mais complexos, como cenários SAN, NAS e iSCSI. No entanto, em geral, o custo por Gigabyte de armazenamento geralmente é diretamente oposto ao custo por E/S: RAID 5 custam menos por Gigabyte do que RAID 1, mas RAID 1 custam menos por E/S Discos rígidos baseados em eixo custam menos por Gigabyte, mas os SSDs custam menos por E/S Após uma reinicialização do computador ou do serviço do Active Directory Domain Services, o cache do ESE (Mecanismo de Armazenamento Extensível) fica vazio e o desempenho será associado ao disco enquanto o cache reinicia. Na maioria dos ambientes, o AD faz a leitura intensiva de E/S em um padrão aleatório para discos, negando grande parte do benefício das estratégias de cache e otimização de leitura. Além disso, o AD tem um cache muito maior na memória do que a maioria dos caches do sistema de armazenamento.
RAM	Tamanho do banco de dados Recomendações de sistema operacional base Aplicativo de terceiros	O armazenamento é o componente mais lento em um computador. Quanto mais ele puder residir na RAM, menos será a necessidade dele ir para o disco. Verifique se a RAM suficiente é alocada para armazenar o sistema operacional, agentes (antivírus, backup, monitoramento), Banco de dados NTDS e crescimento ao longo do tempo. Para ambientes em que maximizar a quantidade de RAM não é econômico (como localizações por satélite) ou inviável (o DIT é muito grande), consulte como referência a seção Armazenamento para garantir que o armazenamento seja dimensionado corretamente.
Rede	''Adaptador de rede(*)/Bytes recebidos/s'' ''Adaptador de rede(*)/Bytes enviados/s''	Em geral, o tráfego enviado de um DC é bem maior do que o tráfego enviado para um DC. Como uma conexão Ethernet alternada é full duplex, o tráfego de rede de entrada e de saída precisa ser dimensionado de forma independente. A consolidação do número de DCs aumentará a quantidade de largura de banda usada para enviar respostas de volta às solicitações de cliente para cada DC, mas será próxima o suficiente de linear para o site como um todo. Se estiver removendo DCs de localização por satélite, não se esqueça de adicionar a largura de banda do DC por satélite aos DCs do hub, bem como usá-lo para avaliar o quanto haverá de tráfego WAN.
CPU	"Logical Disk(<NTDS Database Drive>)\Avg Disk sec/Read" "Process(lsass)\% Processor Time"	Depois de eliminar o armazenamento como um gargalo, resolva a quantidade de potência de computação necessária. Embora não seja perfeitamente linear, o número de núcleos de processador consumidos em todos os servidores dentro de um escopo específico (como um site) pode ser usado para medir quantos processadores são necessários para dar suporte à carga total do cliente. Adicione o mínimo necessário para manter o nível atual de serviço em todos os sistemas dentro do escopo. Alterações na velocidade do processador, incluindo alterações relacionadas ao gerenciamento de energia, afetam os números derivados do ambiente atual. Em geral, é impossível avaliar precisamente como ir de um processador de 2,5 GHz para um processador de 3 GHz reduzirá o número de CPUs necessárias.
Logon de Rede	“Netlogon()\Semaphore Acquires” “Netlogon()\Semaphore Timeouts” “Netlogon(*)\Tempo médio de espera do semáforo”	A Channel/MaxConcurrentAPI protegida de logon de rede afeta apenas ambientes com autenticações NTLM e/ou validação PAC. A validação PAC está ativada por padrão em versões do sistema operacional anteriores ao Windows Server 2008. Essa é uma configuração de cliente, portanto, os DCs serão afetados até que isso seja desativado em todos os sistemas cliente. Ambientes com autenticação entre relação de confiança significativa, que inclui relações de confiança entre florestas, correm risco maior se não forem dimensionados corretamente. As consolidações de servidor aumentarão a simultaneidade da autenticação entre relações de confiança. Os aumentos precisam ser acomodados, como failovers de cluster, à medida que os usuários se autenticam novamente em massa no novo nó de cluster. Sistemas cliente individuais (como um cluster) também podem precisar de ajuste.

Planejamento

Por muito tempo, a recomendação da comunidade para dimensionar o AD DS foi "colocar tanta RAM quanto o tamanho do banco de dados". Na maioria das vezes, essa recomendação era tudo com o que a maioria dos ambientes precisava se preocupar. Mas o ecossistema que consome o AD DS ficou muito maior, assim como os próprios ambientes do AD DS, desde sua apresentação em 1999. Embora o aumento da potência de computação e a mudança de arquiteturas x86 para arquiteturas x64 terem tornado mais sutis os aspectos do dimensionamento para desempenho irrelevantes para um conjunto maior de clientes executando o AD DS em hardware físico, o crescimento da virtualização reintroduziu as preocupações de ajuste para um público maior do que antes.

As diretrizes a seguir são, portanto, sobre como determinar e planejar as demandas do Active Directory como um serviço, independentemente de ele ser implantado em um cenário físico, virtual/físico ou puramente virtualizado. Dessa forma, dividiremos a avaliação para cada um dos quatro componentes principais: armazenamento, memória, rede e processador. Resumindo, para maximizar o desempenho no AD DS, a meta é chegar o mais próximo possível do processador associado.

RAM

Simplesmente, quanto mais ele puder ficar em cache na RAM, menor será a necessidade dele ir para o disco. Para maximizar a escalabilidade do servidor, a quantidade mínima de RAM deve ser a soma do tamanho do banco de dados atual, o tamanho total do SYSVOL, a quantidade recomendada do sistema operacional e as recomendações do fornecedor para os agentes (antivírus, monitoramento, backup e assim por diante). Um valor adicional deve ser alocado para acomodar o crescimento ao longo do tempo de vida do servidor. Isso será ambientalmente subjetivo com base nas estimativas de crescimento do banco de dados com base nas alterações ambientais.

Para ambientes em que maximizar a quantidade de RAM não é econômico (como localizações por satélite) ou inviável (o DIT é muito grande), consulte como referência a seção Armazenamento para garantir que o armazenamento seja criado corretamente.

Uma conclusão que aparece no contexto geral no dimensionamento da memória é o dimensionamento do arquivo de página. No mesmo contexto de tudo relacionado à memória, o objetivo é minimizar a ida para o disco muito mais lento. Portanto, a pergunta deve passar de "Como o arquivo de página deve ser dimensionado?" para "Quanta RAM é necessária para minimizar a paginação?" A resposta para a última pergunta é descrita no restante desta seção. Isso deixa a maior parte da discussão para dimensionar o arquivo de página para o reino das recomendações gerais do sistema operacional e a necessidade de configurar o sistema para despejos de memória, que não estão relacionados ao desempenho do AD DS.

Avaliação

A quantidade de RAM que um controlador de domínio (DC) precisa é, na verdade, um exercício complexo por estes motivos:

• Alto potencial de erro ao tentar usar um sistema existente para medir a quantidade de RAM necessária, pois o LSASS truncará sob condições de pressão de memória, esvaziando artificialmente a necessidade.
• O fato subjetivo de que um DC individual só precisa armazenar em cache o que é "interessante" para seus clientes. Isso significa que os dados que precisam ser armazenados em cache em um DC no site com apenas um servidor Exchange serão muito diferentes dos dados que precisam ser armazenados em cache em um DC que autentica somente usuários.
• O trabalho de avaliar a RAM para cada DC caso a caso é proibitivo e muda conforme o ambiente muda.
• Os critérios por trás da recomendação ajudarão a tomar decisões conscientes:
• Quanto mais ele puder ficar em cache na RAM, menor será a necessidade dele ir para o disco.
• O armazenamento é de longe o componente mais lento de um computador. O acesso a dados em mídia de armazenamento SSD e baseada em eixo está na faixa de 1.000.000x mais lento do que o acesso aos dados na RAM.

Assim, a fim de maximizar a escalabilidade do servidor, a quantidade mínima de RAM é a soma do tamanho do banco de dados atual, o tamanho total do SYSVOL, a quantidade recomendada do sistema operacional e as recomendações do fornecedor para os agentes (antivírus, monitoramento, backup e assim por diante). Adicionar valores adicionais para alocar o crescimento ao longo do tempo de vida do servidor. Isso será ambientalmente subjetivo com base nas estimativas de crescimento do banco de dados. No entanto, em localizações por satélite com um pequeno conjunto de usuários finais, esses requisitos podem ser flexibilizados, pois esses sites não precisarão armazenar tanto em cache para atender à maioria das solicitações.

Para ambientes em que maximizar a quantidade de RAM não é econômico (como localizações por satélite) ou inviável (o DIT é muito grande), consulte como referência a seção Armazenamento para garantir que o armazenamento seja dimensionado corretamente.

Observação

Um conclusão durante o dimensionamento da memória é o dimensionamento do arquivo de página. Como a meta é minimizar a ida ao disco bem mais lento, a pergunta passa de "como o arquivo de página deve ser dimensionado?" para "Quanta RAM é necessária para minimizar a paginação?" A resposta para a última pergunta é descrita no restante desta seção. Isso deixa a maior parte da discussão para dimensionar o arquivo de página para o reino das recomendações gerais do sistema operacional e a necessidade de configurar o sistema para despejos de memória, que não estão relacionados ao desempenho do AD DS.

Considerações sobre virtualização para RAM

Evitar o excesso de confirmação de memória no host. A meta fundamental por trás da otimização da quantidade de RAM é minimizar o tempo gasto de ida para o disco. Em cenários de virtualização, o conceito de excesso de confirmação de memória existe em que mais RAM é alocada aos convidados e, em seguida, existe no computador físico. Isso por si só não é um problema. Isso vira um problema quando a memória total usada ativamente por todos os convidados excede a quantidade de RAM no host e o host subjacente inicia a paginação. O desempenho torna-se associado ao disco nos casos em que o controlador de domínio está indo para o NTDS.dit para obter dados, o controlador de domínio está indo para o arquivo de página para obter dados ou o host está indo para o disco para obter dados que o convidado acha que estão na RAM.

Exemplo de resumo de cálculo

Componente	Memória estimada (exemplo)
RAM recomendada do sistema operacional base (Windows Server 2008)	2 GB
Tarefas internas do LSASS	200 MB
Agente de monitoramento	100 MB
Antivírus	100 MB
Banco de dados (Catálogo Global)	8,5 GB
Amortecimento para execução do backup, administradores para fazer logon sem impacto	1 GB
Total	12 GB

Recomendável: 16 GB

Com o tempo, é possível supor que mais dados serão adicionados ao banco de dados e o servidor provavelmente estará em produção de 3 a 5 anos. Com base em uma estimativa de crescimento de 33%, 16 GB seria uma quantidade razoável de RAM para colocar em um servidor físico. Em uma máquina virtual, dada a facilidade com que as configurações podem ser modificadas e a RAM pode ser adicionada à VM, o razoável é a partir de 12 GB devido aos planos de monitoramento e atualização futuros.

Rede

Avaliação

Esta seção se refere menos à avaliação das demandas em relação ao tráfego de replicação, que se concentra no tráfego passando pela WAN e é totalmente abordada em Tráfego de replicação do Active Directory, do que se refere à avaliação da largura de banda total e da capacidade de rede necessária, inclusive de consultas de cliente, aplicativos de Política de Grupo e assim por diante. Para ambientes existentes, isso pode ser coletado usando os contadores de desempenho "Adaptador de rede(*)\Bytes recebidos/s" e "Adaptador de rede(*)\Bytes enviados/s". Intervalos de exemplo para contadores da Adaptador de rede em 15, 30 ou 60 minutos. Períodos menores geralmente serão muito voláteis para boas medições e os maiores irão suavizar os picos diários excessivamente.

Observação

Em geral, a maior parte do tráfego de rede em um DC é de saída, pois o DC o responde às consultas de cliente. Esse é o motivo do foco no tráfego de saída, embora seja recomendável avaliar cada ambiente também para tráfego de entrada. As mesmas abordagens podem ser usadas para resolver e examinar os requisitos de tráfego de rede de entrada. Para obter mais informações, consulte o artigo da base de dados de conhecimento 929851: O intervalo de porta dinâmica padrão para TCP/IP foi alterado no Windows Vista e no Windows Server 2008.

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. Cada um desses cenários é simples em comparação com alguns dos outros tópicos neste artigo.

Ao avaliar a quantidade de tráfego que deve receber suporte, existem duas categorias exclusivas de planejamento da capacidade para o AD DS em termos de tráfego de rede. A primeira é o tráfego de replicação que passa entre os controladores de domínio e é abordado minuciosamente no Tráfego de replicação do Active Directory de referência e ainda é relevante para as versões atuais do AD DS. A segunda é o tráfego de cliente para servidor intra-site. Um dos cenários mais simples para planejar, o tráfego intra-site recebe predominantemente pequenas solicitações de clientes em relação às grandes quantidades de dados retornados aos clientes. 100 MB geralmente serão adequados em ambientes de até 5.000 usuários por servidor, em um site. O uso de um adaptador de rede de 1 GB e do RSS (Receive Side Scaling) é recomendado para o que tiver acima de 5.000 usuários. Para validar esse cenário, especialmente no caso de cenários de consolidação de servidor, examine o Adaptador de rede(*)\Bytes/s em todos os DCs em um site, adicione-os e divida pelo número de destino de controladores de domínio para garantir que haja capacidade adequada. A maneira mais fácil de fazer isso é usar a exibição "Área empilhada" no Monitor de Desempenho e Confiabilidade do Windows (anteriormente conhecido como Perfmon), certificando-se de que todos os contadores sejam dimensionados da mesma forma.

Considere o exemplo a seguir (também conhecido como uma maneira muito mais complexa de validar se a regra geral é aplicável a um ambiente específico). As seguintes suposições são feitas:

• A meta é reduzir o volume para o menor número possível de servidores. O ideal é que um servidor carregue a carga e um servidor adicional seja implantado para redundância (cenário N + 1).
• Nesse cenário, o adaptador de rede atual dá suporte a apenas 100 MB e está em um ambiente alternado. A utilização máxima da largura de banda de rede de destino é 60% em um cenário N (perda de um DC).
• Cada servidor tem cerca de 10.000 clientes conectados a ele.

Conhecimento obtido com os dados no gráfico (Adaptador de rede(*)\Bytes enviados/s):

1. O dia útil começa a aumentar por volta das 17h30 e acaba às 19h.
2. O período de pico mais ocupado é das 8h às 8h15, com mais de 25 Bytes enviados/s no DC mais movimentado.

   Observação

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

3. Há picos antes das 4h, com mais de 20 bytes enviados/s no DC mais movimentado, o que pode indicar a carga de diferentes fusos horários ou atividade de infraestrutura em segundo plano, como backups. Como o pico às 8h excede essa atividade, ele não é relevante.
4. Há cinco controladores de domínio no site.
5. A carga máxima é de cerca de 5,5 MB/s por DC, o que representa 44% da conexão de 100 MB. Usando esses dados, estima-se que a largura de banda total necessária entre 8h e 8h15 seja de 28 MB/s.

   Observação

   Atente-se ao fato de que os contadores de recebimento/envio da Adaptador de rede estão em bytes e a largura de banda de rede é medida em bits. 100 MB ÷ 8 = 12,5 MB, 1 GB ÷ 8 = 128 MB.

Conclusões:

1. Esse ambiente atual atende ao nível N+1 de tolerância a falhas em 60% da utilização de destino. Colocar um sistema offline alternará a largura de banda por servidor de cerca de 5,5 MB/s (44%) para cerca de 7 MB/s (56%).
2. Com base na meta declarada anteriormente de consolidação em um servidor, isso excede a utilização de destino máxima e, teoricamente, a possível utilização de uma conexão de 100 MB.
3. Com uma conexão de 1 GB, isso representará 22% da capacidade total.
4. Em condições operacionais normais no cenário N + 1, a carga do cliente será relativamente distribuída uniformemente em cerca de 14 MB/s por servidor ou 11% da capacidade total.
5. Para garantir que a capacidade seja adequada durante a indisponibilidade de um DC, os destinos operacionais normais por servidor seriam cerca de 30% de utilização de rede ou 38 MB/s por servidor. Os destinos de failover seriam 60% de utilização de rede ou 72 MB/s por servidor.

Em suma, a implantação final de sistemas deve ter um adaptador de rede de 1 GB e estar conectada a uma infraestrutura de rede que dará suporte a essa carga. Outra observação é que, dada a quantidade de tráfego de rede gerada, a carga de CPU das comunicações de rede pode ter um impacto significativo e limitar a escalabilidade máxima do AD DS. Esse mesmo processo pode ser usado para estimar a quantidade de comunicação de entrada para o DC. Mas dada a predominância do tráfego de saída em relação ao tráfego de entrada, ele é um exercício acadêmico para a maioria dos ambientes. Garantir o suporte de hardware para RSS é importante em ambientes com mais de 5.000 usuários por servidor. Em cenários com tráfego de rede alto, o balanceamento da carga de interrupção pode ser um gargalo. Isso pode ser detectado pelo tempo de interrupção Processor(*)% sendo distribuído de forma desigual entre CPUs. As NICs habilitadas para RSS podem atenuar essa limitação e aumentar a escalabilidade.

Observação

Uma abordagem semelhante pode ser usada para estimar a capacidade adicional necessária ao consolidar data centers ou desativar um controlador de domínio em uma localização por satélite. Basta coletar o tráfego de saída e de entrada dos clientes e essa será a quantidade de tráfego que estará presente nos links WAN no momento.

Em alguns casos, você pode experimentar mais tráfego do que o esperado porque ele é mais lento, como quando a verificação de certificado falha ao atender a tempos limite agressivos na WAN. Por esse motivo, o dimensionamento e a utilização da WAN devem ser um processo iterativo e contínuo.

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

É fácil fazer recomendações para um servidor físico: 1 GB para servidores que dão suporte a mais de 5.000 usuários. Depois que vários convidados começarem a compartilhar uma infraestrutura de comutador virtual subjacente, haverá a necessidade de mais atenção para garantir que o host tenha largura de banda de rede adequada para dar suporte a todos os convidados no sistema e, portanto, exige o rigor adicional. Isso não é nada mais do que uma extensão da garantia da infraestrutura de rede no computador host. Isso acontece independentemente de a rede ser inclusiva do controlador de domínio executando como convidado de máquina virtual em um host com o tráfego de rede passando por um comutador virtual ou se ela está conectada diretamente a um comutador físico. O comutador virtual é apenas mais um componente no qual o uplink precisa dar suporte à quantidade de dados que está sendo transmitida. Portanto, o adaptador de rede física do host físico vinculado ao comutador deve ser capaz de dar suporte à carga do DC, além de todos os outros convidados que compartilham o comutador virtual conectado ao adaptador de rede física.

Exemplo de resumo de cálculo

Sistema	Largura de banda de pico
DC 1	6,5 MB/s
DC 2	6,25 MB/s
DC 3	6,25 MB/s
DC 4	5,75 MB/s
DC 5	4,75 MB/s
Total	28,5 MB/s

Recomendável: 72 MB/s (28,5 MB/s divididos por 40%)

Contagem de sistemas de destino	Largura de banda total (acima)
2	28,5 MB/s
Comportamento normal resultante	28,5 ÷ 2 = 14,25 MB/s

Como sempre, com o tempo, supõe-se que a carga do cliente aumentará e esse crescimento deve ser planejado da melhor forma possível. O valor recomendado para o qual planejar permitiria um crescimento estimado no tráfego de rede de 50%.

Armazenamento

O planejamento do armazenamento representa dois componentes:

• Capacidade ou tamanho do armazenamento
• Desempenho

Gasta-se bastante tempo e documentação no planejamento da capacidade e isso deixa o desempenho muitas vezes completamente de lado. Com os custos atuais de hardware, a maioria dos ambientes não é grande o suficiente para que qualquer um deles seja realmente uma preocupação, e a recomendação para "colocar tanta RAM quanto o tamanho do banco de dados" geralmente se sobrepõe ao resto, embora possa ser um exagero para localizações por satélite em ambientes maiores.

Dimensionamento

Avaliação do armazenamento

Em comparação a 13 anos atrás, quando o Active Directory foi apresentado, uma época em que as unidades de 4 GB e 9 GB eram os tamanhos de unidade mais comuns, o dimensionamento para o Active Directory nem sequer é considerado para todos, exceto para os maiores ambientes. Com os menores tamanhos de disco rígido disponíveis no intervalo de 180 GB, todo o sistema operacional, SYSVOL e NTDS.dit podem caber facilmente em uma unidade. Dessa forma, é recomendável preterir investimentos pesados nessa área.

A única recomendação a ser considerada é garantir que 110% do tamanho NTDS.dit esteja disponível para habilitar o defrag. Além disso, devem ser feitas acomodações para crescimento ao longo da vida útil do hardware.

A primeira e mais importante consideração é avaliar qual será o tamanho do NTDS.dit e do SYSVOL. Essas medidas levarão ao dimensionamento do disco fixo e da alocação da RAM. Devido ao (relativamente) baixo custo desses componentes, a matemática não precisa ser rigorosa e precisa. O conteúdo sobre como avaliar isso em ambientes novos e existentes pode ser encontrado na série de artigos Armazenamento de dados. Consulte, especificamente, os seguintes artigos:

• Para ambientes existentes – A seção intitulada "Para ativar o registro em log do espaço em disco que é liberado por desfragmentação" no artigo Limites de armazenamento.

• Para novos ambientes – O artigo intitulado Estimativas de crescimento para usuários do Active Directory e unidades organizacionais.

  Observação

  Os artigos são baseados em estimativas de tamanho de dados feitas no momento da liberação do Active Directory no Windows 2000. Use tamanhos de objeto que reflitam o tamanho real dos objetos em seu ambiente.

Ao revisar ambientes existentes com vários domínios, podem existir variações nos tamanhos dos bancos de dados. Quando isso acontecer, use os tamanhos de GC (catálogo global) menores e não GC.

O tamanho do banco de dados pode variar entre as versões do sistema operacional. Os DCs que executam sistemas operacionais anteriores, como o Windows Server 2003, têm um tamanho de banco de dados menor do que um DC que executa um sistema operacional mais recente, como o Windows Server 2008 R2, especialmente quando recursos como a Lixeira do Active Directory ou o Roaming de Credenciais estão habilitados.

Observação

• Em novos ambientes, observe que as estimativas em Estimativas de crescimento para usuários e unidades organizacionais do Active Directory indicam que 100.000 usuários (no mesmo domínio) consomem cerca de 450 MB de espaço. Observe que os atributos preenchidos podem ter um grande impacto no valor total. Os atributos serão preenchidos em muitos objetos por produtos de terceiros e da Microsoft, incluindo Microsoft Exchange Server e Lync. É preferível obter uma avaliação baseada no portfólio dos produtos no ambiente, mas o exercício de detalhar a matemática e os testes para estimativas precisas para todos, exceto para os maiores ambientes, pode não valer tempo e esforço significativos.
• Verifique se 110% do tamanho NTDS.dit está disponível como espaço livre para habilitar o defrag offline e planeje o crescimento durante um período de vida de hardware de três a cinco anos. Considerando o valor barato do armazenamento, estime o armazenamento em 300% do tamanho do DIT, pois a alocação de armazenamento é segura para acomodar o crescimento e a necessidade potencial do defrag offline.

Considerações sobre virtualização para armazenamento

Em um cenário em que vários arquivos VHD (Disco Rígido Virtual) estão sendo alocados em um único volume, use um disco de tamanho fixo de pelo menos 210% (100% do DIT + 110% de espaço livre) do tamanho do DIT para garantir que haja espaço adequado reservado.

Exemplo de resumo de cálculo

Dados coletados a partir da fase de avaliação	Tamanho
Tamanho de NTDS.dit	35 GB
Modificador para permitir o defrag offline	2,1 GB
Armazenamento total necessário	73,5 GB

Observação

Esse armazenamento necessário é adicional ao armazenamento necessário para SYSVOL, sistema operacional, arquivo de página, arquivos temporários, dados armazenados em cache local (como arquivos do instalador) e aplicativos.

Desempenho de armazenamento

Avaliação do desempenho de armazenamento

Como o componente mais lento em qualquer computador, o armazenamento pode causar o maior impacto adverso na experiência do cliente. Nesses ambientes grandes o suficiente, para os quais as recomendações de dimensionamento de RAM não são viáveis, as consequências de ignorar o planejamento do armazenamento para desempenho podem ser devastadoras. Além disso, as complexidades e variedades de tecnologia de armazenamento aumentam ainda mais o risco de falha, pois a relevância das melhores práticas de longa data de "colocar sistema operacional, logs e banco de dados" em discos físicos separados é limitada em seus cenários úteis. Isso ocorre porque a melhor prática de longa data baseia-se na suposição de que um "disco" é um eixo dedicado e isso permite que a E/S seja isolada. A suposições que tornam isso verdade não são mais relevantes com a introdução de:

• 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
• Arquiteturas de armazenamento em camadas (ou seja, camada de armazenamento SSD armazenando em cache armazenamento baseado em eixo maior)

Especificamente, todo armazenamento compartilhado (RAID, SAN, NAS, JBOD (ou seja, Espaços de Armazenamento), VHD) tem a capacidade de ser receber excesso de demanda/sobrecarga de outras cargas de trabalho que são colocadas no armazenamento de back-end. Eles também adicionam o desafio de que problemas de SAN/rede/driver (tudo entre o disco físico e o aplicativo do AD) podem causar limitação e/ou atrasos. Para esclarecimentos, essas configurações não são "ruins", elas são configurações mais complexas que exigem que todos os componentes ao longo do caminho estejam funcionando corretamente, exigindo assim atenção adicional para garantir que o desempenho seja aceitável. Consulte o Apêndice C, subseção "Introdução ao SANs" e o Apêndice D mais adiante neste documento para obter explicações mais detalhadas. Além disso, enquanto as unidades de estado sólido não têm a limitação de discos giratórios (discos rígidos) em relação a permitir que seja processada apenas uma E/S por vez, elas ainda têm limitações de E/S, e receber sobrecarga/excesso de demanda das SSDs é possível. Resumindo, o objetivo final de todos os esforços de desempenho de armazenamento, independentemente da arquitetura e do design de armazenamento subjacentes, é garantir que a quantidade necessária de IOPS (operações de entrada/saída por segundo) esteja disponível e que essas IOPS ocorram dentro de um período aceitável (conforme especificado em outro lugar neste documento). Para esses cenários com armazenamento anexado localmente, consulte como referência o Apêndice C para obter as noções básicas de como criar cenários de armazenamento local tradicionais. Essas entidades de segurança geralmente são aplicáveis a camadas de armazenamento mais complexas e também ajudarão na caixa de diálogo com os fornecedores que dão suporte a soluções de armazenamento de back-end.

• Dada a ampla variedade de opções de armazenamento disponíveis, é recomendável acionar a experiência de equipes ou fornecedores do suporte de hardware para garantir que a solução específica atenda às necessidades do AD DS. Os números a seguir são as informações que seriam fornecidas aos especialistas em armazenamento.

Para ambientes em que o banco de dados é muito grande para ser mantido na RAM, use os contadores de desempenho para determinar quanto da E/S precisa receber suporte:

• LogicalDisk(*)\Avg Disk sec/Read (por exemplo, se NTDS.dit estiver armazenado na unidade D:/, o caminho completo seria 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

Eles devem ser amostrados em intervalos de 15/30/60 minutos para avaliar as demandas do ambiente atual.

Avaliando os resultados

Observação

O foco está nas leituras do banco de dados, pois geralmente esse é o componente mais exigente, a mesma lógica pode ser aplicada a gravações no arquivo de log substituindo LogicalDisk(<NTDS Log>)\Avg Disk sec/Write e LogicalDisk(<NTDS Log>)\Writes/sec):

• LogicalDisk(<NTDS>)\Avg Disk sec/Read indica se o armazenamento atual está ou não dimensionado adequadamente. Se os resultados forem aproximadamente iguais ao Tempo de acesso ao disco para o tipo de disco, LogicalDisk(<NTDS>)\Reads/sec será uma medida válida. Verifique as especificações do fabricante para o armazenamento no back-end, mas os bons intervalos para LogicalDisk(<NTDS>)\Avg Disk sec/Read seriam aproximadamente:
  • 7200 – 9 a 12,5 Milissegundos (ms)
  • 10.000 – 6 a 10 ms
  • 15.000 – 4 a 6 ms
  • SSD – 1 a 3 ms

  • Observação

    Existem recomendações informando que o desempenho do armazenamento está degradado em 15 ms a 20 ms (dependendo da origem). A diferença entre os valores acima e as outras diretrizes é que os valores acima são o intervalo operacional normal. As outras recomendações são diretrizes para solucionar problemas e identificar quando a experiência do cliente se degrada significativamente e se torna perceptível. Consulte como referência o Apêndice C para obter uma explicação mais detalhada.

• LogicalDisk(<NTDS>)\Reads/sec é a quantidade de E/S que está sendo executada.
  • Se LogicalDisk(<NTDS>)\Avg Disk sec/Read estiver dentro do intervalo ideal para o armazenamento de back-end, o LogicalDisk(<NTDS>)\Reads/sec poderá ser usado 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, será necessária E/S adicional de acordo com a seguinte fórmula: (LogicalDisk(<NTDS>)\Avg Disk sec/Read) ÷ (Physical Media Disk Access Time) × (LogicalDisk(<NTDS>)\Avg Disk sec/Read)

Considerações:

• Observe que, se o servidor estiver configurado com uma quantidade de RAM abaixo do ideal, esses valores serão imprecisos para fins de planejamento. Eles estarão erroneamente no lado superior e ainda poderão ser usados na ocorrência do pior cenário.
• Adicionar/otimizar a RAM especificamente gerará uma diminuição na quantidade de E/S de leitura (LogicalDisk(<NTDS>)\Reads/sec. Isso significa que a solução de armazenamento talvez não necessite ser tão robusta quanto calculada inicialmente. Infelizmente, qualquer coisa mais específica do que essa instrução geral depende do ambiente da carga do cliente e não é possível fornecer diretrizes gerais. A melhor opção é ajustar o dimensionamento do armazenamento depois de otimizar a RAM.

Considerações sobre virtualização para desempenho

Semelhante a todas as discussões de virtualização anteriores, o segredo aqui é garantir que a infraestrutura compartilhada subjacente possa dar suporte à carga de DC além de aos outros recursos usando a mídia compartilhada subjacente e todos os caminhos para ela. Isso acontece se um controlador de domínio físico estiver compartilhando a mesma mídia subjacente em uma infraestrutura SAN, NAS ou iSCSI como outros servidores ou aplicativos, seja um convidado usando o acesso de passagem para uma infraestrutura SAN, NAS ou iSCSI que compartilha a mídia subjacente ou se o convidado está usando um arquivo VHD que reside em mídia compartilhada localmente ou em uma Infraestrutura SAN, NAS ou iSCSI. O exercício de planejamento serve para garantir que a mídia subjacente possa dar suporte à carga total de todos os consumidores.

Além disso, do ponto de vista do convidado, como há demarcadores de código adicionais que devem ser percorridos, ter que passar por um host para acessar qualquer armazenamento causa um impacto no desempenho. Não surpreende que o teste de desempenho de armazenamento indique que a virtualização tem um impacto na taxa de transferência subjetiva à utilização do processador do sistema host (consulte o Apêndice A: Critérios de dimensionamento de CPU), que obviamente é influenciado pelos recursos do host exigidos pelo convidado. Isso contribui para as considerações de virtualização sobre as necessidades de processamento em um cenário virtualizado (confira Considerações sobre virtualização para processamento).

O que tornar isso mais complexo é que existe uma variedade de opções de armazenamento diferentes disponíveis que causam impactos de desempenho diferentes. Como uma estimativa segura ao migrar de físico para virtual, use um multiplicador de 1,10 para ajustar para diferentes opções de armazenamento para convidados virtualizados no Hyper-V, como armazenamento de passagem, Adaptador SCSI ou IDE. Os ajustes que precisam ser feitos ao transferir entre os diferentes cenários de armazenamento são tão irrelevantes quanto saber se o armazenamento é local, SAN, NAS ou iSCSI.

Exemplo de resumo de cálculo

Determinar a quantidade de E/S necessária para um sistema íntegro em condições operacionais normais:

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

  IOPS necessário = (LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Read ÷ <Target Avg Disk sec/Read>) × LogicalDisk(<NTDS Database Drive>)\Read/sec

Contador	Valor
LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Transfer real	0,02 segundos (20 milissegundos)
LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Transfer de destino	0,01 segundos
Multiplicador para alteração na E/S disponível	0,02 ÷ 0,01 = 2

Nome do valor	Valor
LogicalDisk(<NTDS Database Drive>)\Transfers/sec	400
Multiplicador para alteração na E/S disponível	2
IOPS total necessário durante o período de pico	800

Para determinar a taxa na qual é desejável que o cache seja inicializado:

• Determine o tempo máximo aceitável para inicializar o cache. Ele é a quantidade de tempo que deve levar para carregar todo o banco de dados do disco ou para cenários em que todo o banco de dados não pode ser carregado na RAM, esse seria o tempo máximo para preencher a RAM.
• Determine o tamanho do banco de dados, excluindo espaços em branco. Para obter mais informações, consulte Avaliação do armazenamento.
• Dividir o tamanho do banco de dados por 8 KB; que serão as E/S totais necessárias para carregar o banco de dados.
• Divida o total de E/Ss pelo número de segundos no período definido.

Observe que a taxa calculada, embora precisa, não será exata porque as páginas carregadas anteriormente serão removidas se o ESE não estiver configurado para ter um tamanho de cache fixo e o AD DS, por padrão, usar o tamanho do cache variável.

Pontos de dados a serem coletados	Valores
Tempo máximo aceitável para inicializar	10 minutos (600 segundos)
Tamanho do banco de dados	2 GB

Etapa de cálculo	Fórmula	Resultado
Calcular o tamanho do banco de dados em páginas	(2 GB × 1024 × 1024) = Tamanho do banco de dados em KB	2.097.152 KB
Calculo do número de páginas no banco de dados	2.097.152 KB ÷ 8 KB = Número de páginas	262.144 páginas
Calcular o IOPS necessário para inicializar totalmente o cache	262.144 páginas ÷ 600 segundos = IOPS necessário	437 IOPS

Processando

Avaliação do uso do processador do Active Directory

Na maioria dos ambientes, depois que o armazenamento, a RAM e a rede forem ajustados corretamente, conforme descrito na seção Planejamento, o gerenciamento a quantidade da capacidade de processamento será o componente que mais merece atenção. Há dois desafios na avaliação da capacidade de CPU necessária:

• Se os aplicativos no ambiente estão ou não tendo o comportamento esperado em uma infraestrutura de serviços compartilhados e é discutido na seção intitulada "Acompanhando pesquisas caras e ineficientes" no artigo Como criar aplicativos habilitados para o Microsoft Active Directory mais eficientes ou migrar das chamadas SAM de nível inferior para as chamadas LDAP.

  Em ambientes maiores, o motivo pelo qual isso é importante é que aplicativos mal codificados podem gerar volatilidade na carga da CPU, "roubar" uma quantidade de tempo de CPU de outros aplicativos, aumentar artificialmente as necessidades de capacidade e distribuir de forma desigual a carga em relação aos DCs.

• Como o AD DS é um ambiente distribuído com uma grande variedade de clientes potenciais, estimar a despesa de um "cliente único" é ambientalmente subjetivo devido aos padrões de uso e ao tipo ou quantidade de aplicativos que aproveitam o AD DS. Resumindo, assim como a seção de rede, para obter ampla aplicabilidade, é melhor abordar isso da perspectiva de avaliação da capacidade total necessária no ambiente.

Em ambientes existentes, como o dimensionamento de armazenamento foi discutido anteriormente, agora é considerado que o armazenamento está dimensionado corretamente e, portanto, os dados relativos à carga do processador são válidos. Para reiterar, é fundamental garantir que o gargalo no sistema não seja o desempenho do armazenamento. Quando existe um gargalo e o processador está aguardando, há estados ociosos que desaparecerão assim que o gargalo for removido. Conforme os estados de espera do processador são removidos, por natureza, a utilização da CPU aumenta, por não precisar mais aguardar os dados. Assim, colete os contadores de desempenho "Logical Disk(<NTDS Database Drive>)\Avg Disk sec/Read" e "Process(lsass)\% Processor Time". Os dados em "Process(lsass)\% Processor Time" serão artificialmente baixos se "Logical Disk(<NTDS Database Drive>)\Avg Disk sec/Read" exceder de 10 a 15 ms, que é um limite geral que o suporte da Microsoft usa para solucionar problemas de desempenho relacionados ao armazenamento. Como anteriormente, é recomendável que os intervalos de exemplo sejam de 15, 30 ou 60 minutos. Períodos menores geralmente serão muito voláteis para boas medições e os maiores irão suavizar os picos diários excessivamente.

Introdução

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 haverá um componente que será o gargalo e, em um Controlador de Domínios de tamanho adequado, ele será 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 aproveitam o AD, uma estimativa geral de usuários por CPU é lamentavelmente inaplicável a todos os ambientes. Especificamente, as demandas de computação estão sujeitas ao comportamento do usuário e ao perfil do aplicativo. Portanto, cada ambiente precisa ser dimensionado individualmente.

Perfil de comportamento do site de destino

Conforme mencionado anteriormente, ao planejar a capacidade de um site inteiro, a meta é direcionar um design com um design de capacidade N + 1, de modo que a falha de um sistema durante o período de pico permita a continuação do serviço em um nível razoável de qualidade. Isso significa que, em um cenário "N", a carga em todas as caixas deve ser inferior a 100% (melhor ainda, menos de 80%) durante os períodos de pico.

Além disso, se os aplicativos e clientes no site estiverem usando as melhores práticas para localizar controladores de domínio (ou seja, usando a função DsGetDcName), os clientes deverão ser relativamente distribuídos uniformemente com picos transitórios menores devido a qualquer número de fatores.

No próximo exemplo, as seguintes suposições são feitas:

• 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, caso contrário, 60% ("N"). Fora do horário comercial, o uso da CPU de destino é de 80% porque o software de backup e outras manutenções devem consumir todos os recursos disponíveis.

Analisando os dados no gráfico (Processor Information(_Total)\% Processor Utility) para cada um dos DCs:

• Na maioria das vezes, a carga é relativamente distribuída de maneira uniforme, e isso é o que seria esperado quando os clientes usam o localizador de DC e têm pesquisas bem escritas.

• Existem vários picos de cinco minutos de 10%, com alguns grandes de até 20%. Em geral, a menos que eles façam com que o destino do plano de capacidade seja excedido, não vale a pena investigar isso.

• O período de pico de todos os sistemas é entre 8h e 9h15. Com a transição suave das 5h às 17h aproximadamente, isso geralmente é indicativo do ciclo comercial. Os picos mais aleatórios de uso da CPU em um cenário caixa por caixa entre às 17h e 4h da manhã estariam fora das preocupações do planejamento da capacidade.

  Observação

  Em um sistema bem gerenciado, os mencionados picos podem ser do software de backup em execução, verificações completas de antivírus do sistema, estoque de hardware ou software, implantação de software ou patch e assim por diante. Como eles estão fora do ciclo comercial do usuário de pico, os destinos não são excedidos.

• Como cada sistema é de cerca de 40% e todos os sistemas têm o mesmo número de CPUs, caso um falhe ou seja colocado offline, os sistemas restantes seriam executados com uma carga estimada de 53% (a carga de 40% do sistema D é igualmente dividida e adicionada à carga de 40% existente do sistema A e do sistema C). Por vários motivos, essa suposição linear NÃO é perfeitamente precisa, mas fornece precisão suficiente para medir.

  Cenário alternativo – Dois controladores de domínio executando em 40%: um controlador de domínio falha, a CPU estimada no restante seria estimada em 80%. Isso excede em muito os limites descritos acima para o plano de capacidade e também começa a limitar gravemente a quantidade de espaço de cabeçalho para os 10% a 20% vistos no perfil de carga acima, o que significa que os picos levariam o DC de 90% a 100% durante o cenário "N" e definitivamente degradariam a capacidade de resposta.

Calculando as demandas de CPU

O contador de objeto de desempenho "Process\% Processor Time" soma a quantidade total de tempo que todos os threads de um aplicativo gastam na CPU e divide pela quantidade total de tempo do sistema que passou. O efeito disso é que um aplicativo com multithreads em um sistema de várias CPUs pode exceder 100% do tempo da CPU e isso seria interpretado de maneira MUITO diferente de "Informações do processador\% Utilitário do processador". Na prática, o "Process(lsass)\% Processor Time" pode ser exibido como a contagem de CPUs executando em 100% necessárias para dar suporte às demandas do processo. Um valor de 200% significa que duas CPUs, cada uma a 100%, são necessárias para dar suporte à carga completa do AD DS. Embora uma CPU executando com capacidade de 100% seja a mais econômica da perspectiva do dinheiro gasto em CPUs e consumo de energia, por vários motivos detalhados no Apêndice A, uma melhor capacidade de resposta em um sistema com multithreads ocorre quando o sistema não está em execução a 100%.

Para acomodar picos transitórios na carga do cliente, é recomendável direcionar uma CPU em período de pico de cerca de 40% e 60% da capacidade do sistema. Trabalhando com o exemplo acima, isso significaria que entre 3,33 (60% de destino) e 5 (40% de destino) as CPUs seriam necessárias para a carga do AD DS (processo LSASS). A capacidade adicional deve ser adicionada de acordo com as demandas do sistema operacional de base e outros agentes necessários (como antivírus, backup, monitoramento e assim por diante). Embora o impacto dos agentes precise ser avaliado por ambiente, pode-se fazer uma estimativa de 5% e 10% de uma única CPU. No exemplo atual, isso sugere que são necessárias entre 3,43 (60% de destino) e 5,1 (40% de destino) CPUs durante períodos de pico.

A maneira mais fácil de fazer isso é usar a exibição "Área empilhada" no Monitor de Desempenho e Confiabilidade do Windows (perfmon), certificando-se de que todos os contadores sejam dimensionados da mesma forma.

Suposições:

• A meta é reduzir o volume para o menor número possível de servidores. O ideal seria que um servidor carregasse a carga e um servidor adicional fosse adicionado para redundância (cenário N + 1).

Conhecimento obtido com os dados no gráfico (Process(lsass)\% Processor Time):

• O dia útil começa a aumentar por volta das 7h e a diminuir às 17h.
• O período de pico mais ocupado é das 9h30 às 11h.

  Observação

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

• Há picos antes das 7h, o que pode indicar a carga de diferentes fusos horários ou atividade de infraestrutura em segundo plano, como backups. Como o pico às 9h30 excede essa atividade, ele não é relevante.
• Há três controladores de domínio no site.

Na carga máxima, o LSASS consome cerca de 485% de uma CPU ou 4,85 CPUs executando em 100%. De acordo com a matemática anterior, isso significa que o site precisa de cerca de 12,25 CPUs para o AD DS. Adicione as sugestões acima de 5% a 10% para processos em segundo plano e isso significa que para substituir o servidor hoje seria necessário aproximadamente de 12,30 a 12,35 CPUs para dar suporte à mesma carga. Agora, uma estimativa ambiental para o crescimento precisa ser fatorada.

Quando ajustar pesos LDAP

Existem vários cenários em que o ajuste de LdapSrvWeight deveria ser considerado. Dentro do contexto de planejamento da capacidade, isso seria feito quando as cargas do aplicativo ou do usuário não estão balanceadas uniformemente ou os sistemas subjacentes não estão balanceados uniformemente em termos de capacidade. Os motivos para fazer isso além do planejamento da capacidade estão fora do escopo deste artigo.

Existem dois motivos comuns para ajustar pesos LDAP:

• O emulador do PDC é um exemplo que afeta todos os ambientes dos quais o comportamento de carga do usuário ou aplicativo não está distribuído uniformemente. Como determinadas ferramentas e ações se destinam ao emulador do PDC, como as ferramentas de gerenciamento de Política de Grupo, as segundas tentativas no caso de falhas de autenticação, estabelecimento de confiança e assim por diante, os recursos de CPU no emulador do PDC podem ser mais exigidos do que em outros lugares no site.
  • É útil ajustar isso somente se houver uma diferença perceptível na utilização da CPU para reduzir a carga no emulador do PDC e aumentar a carga em outros controladores de domínio permitirá uma distribuição mais uniforme da carga.
  • Nesse caso, defina LDAPSrvWeight entre 50 e 75 para o emulador do PDC.
• Servidores com contagens diferentes de CPUs (e velocidades) em um site. Por exemplo, digamos que haja dois servidores de oito núcleos e um servidor de quatro núcleos. O último servidor tem metade dos processadores dos outros dois servidores. Isso significa que uma carga de cliente bem distribuída aumentará a carga média da CPU na caixa de quatro núcleos para aproximadamente o dobro das caixas de oito núcleos.
  • Por exemplo, as duas caixas de oito núcleos seriam executadas em 40% e a caixa de quatro núcleos seria executadas em 80%.
  • Além disso, considere o impacto da perda de uma caixa de oito núcleos nesse cenário, especificamente o fato de que a caixa de quatro núcleos agora estaria sobrecarregada.

Exemplo 1 – PDC

Sistema	Utilização com padrões	New LdapSrvWeight	Nova utilização estimada
DC 1 (Emulador de PDC)	53%	57	40%
DC 2	33%	100	40%
DC 3	33%	100	40%

A contrapartida aqui é que, se a função de emulador do PDC for transferida ou tomada, especialmente para outro controlador de domínio no site, haverá um aumento drástico no novo emulador do PDC.

Usando o exemplo da seção Perfil de comportamento do site de destino, foi feita uma suposição de que todos os três controladores de domínio no site tinham quatro CPUs. O que aconteceria, em condições normais, se um dos controladores de domínio tivesse oito CPUs? Haveria dois controladores de domínio com 40% de utilização e um com 20% de utilização. Embora isso não seja ruim, há uma oportunidade de equilibrar um pouco melhor a carga. Aproveite os pesos LDAP para fazer isso. Um cenário de exemplo seria:

Exemplo 2 – Contagens de CPU diferentes

Sistema	Informações do processador\ % Utilitário do processador(_Total) Utilização com padrões	New LdapSrvWeight	Nova utilização estimada
4-CPU DC 1	40	100	30%
4-CPU DC 2	40	100	30%
8-CPU DC 3	20	200	30%

No entanto, muito cuidado com esses cenários. Como pode ser visto acima, a matemática parece muito boa e bonita no papel. Mas ao longo deste artigo, planejar um cenário "N + 1" é de suma importância. O impacto de um DC ficando offline deve ser calculado para cada cenário. No cenário imediatamente anterior em que a distribuição de carga está uniforme, para garantir uma carga de 60% durante um cenário "N", com a carga balanceada uniformemente por todos os servidores, a distribuição será boa, pois as taxas permanecem consistentes. Examinando o cenário de ajuste do emulador do PDC e, em geral, qualquer cenário em que a carga de usuário ou aplicativo esteja desbalanceada, o efeito é muito diferente:

Sistema	Utilização ajustada	New LdapSrvWeight	Nova utilização estimada
DC 1 (Emulador de PDC)	40%	85	47%
DC 2	40%	100	53%
DC 3	40%	100	53%

Considerações sobre virtualização para processamento

Há duas camadas de planejamento da capacidade que precisam ser feitas em um ambiente virtualizado. No nível do host, semelhante à identificação do ciclo comercial descrito anteriormente para o processamento do controlador de domínio, os limites durante o período de pico precisam ser identificados. Como as entidades de segurança subjacentes são as mesmas para um computador host programando threads de convidado na CPU e para obter threads do AD DS na CPU em um computador físico, é recomendada a mesma meta de 40% a 60% no host subjacente. Na próxima camada, a de convidado, como as entidades de segurança da programação de threads não foram alteradas, a meta dentro do convidado permanece no intervalo de 40% a 60%.

Em um cenário mapeado direto, um convidado por host, todo o planejamento da capacidade feito até esse ponto precisa ser adicionado aos requisitos (RAM, disco, rede) do sistema operacional host subjacente. Em um cenário de host compartilhado, o teste indica que existe um impacto de 10% na eficiência dos processadores subjacentes. Isso significa que se um site precisar de 10 CPUs em um destino de 40%, a quantidade recomendada de CPUs virtuais para alocar em todos os convidados "N" seria de 11. Em um site com uma distribuição mista de servidores físicos e servidores virtuais, o modificador só se aplica às VMs. Por exemplo, se um site tiver um cenário "N + 1", um servidor físico ou diretamente mapeado com 10 CPUs ele seria equivalente a um convidado com 11 CPUs em um host, com 11 CPUs reservadas para o controlador de domínio.

Ao longo da análise e do cálculo das quantidades de CPU necessárias para dar suporte à carga do AD DS, os números de CPUs mapeados para o que pode ser comprado em termos de hardware físico não são necessariamente mapeados de forma correta. A virtualização elimina a necessidade de arredondar para cima. A virtualização diminui o esforço necessário para adicionar capacidade de computação a um site, dada a facilidade com que uma CPU pode ser adicionada a uma VM. Isso não elimina a necessidade de avaliar com precisão a potência de computação necessária para que o hardware subjacente esteja disponível quando CPUs adicionais precisarem ser adicionadas aos convidados. Como sempre, não deixe de planejar e monitorar o crescimento da demanda.

Exemplo de resumo de cálculo

Sistema	CPU de pico
DC 1	120%
DC 2	147%
Dc 3	218%
Total de CPU sendo usada	485%

Contagem de sistemas de destino	Largura de banda total (acima)
CPUs necessárias em 40% dos destinos	4.85 ÷ .4 = 12.25

Repetindo devido à importância deste ponto, não deixe de planejar para o crescimento. Considerando um crescimento de 50% nos próximos três anos, esse ambiente precisará de 18,375 CPUs (12,25 × 1,5) em até três anos. Um plano alternativo seria fazer uma revisão após o primeiro ano e adicionar mais capacidade conforme necessário.

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. Uma solicitação de autenticação para uma identidade em outro domínio que não usa a autenticação do Kerberos precisa percorrer uma relação confiança usando o canal seguro do controlador de domínio para outro controlador de domínio no domínio de destino ou no próximo domínio no demarcador para o domínio de destino. O número de chamadas simultâneas usando o canal seguro que um controlador de domínio pode fazer a um controlador de domínio em um domínio confiável é controlado por uma configuração conhecida como MaxConcurrentAPI. Para controladores de domínio, a garantia de que o canal seguro pode tratar a quantidade de carga é conquistada por uma das duas abordagens: ajustando MaxConcurrentAPI ou, dentro de uma floresta, criando atalhos de relações de confiança. Para medir o volume de tráfego em uma relação de confiança individual, consulte Como fazer ajuste de desempenho em autenticação NTLM usando a configuração MaxConcurrentApi.

Durante a coleta de dados, isso, como em todos os outros cenários, deve ser coletado durante os períodos de pico ocupados do dia para que os dados sejam úteis.

Observação

Os cenários na mesma floresta e entre florestas podem fazer com que a autenticação percorra várias relações de confiança e cada estágio precisaria ser ajustado.

Planejamento

Existem vários aplicativos que usam a autenticação NTLM por padrão ou a usam em um determinado cenário de configuração. Os servidores de aplicativos expandem em capacidade e serviço um número crescente de clientes ativos. Há também uma tendência de que os clientes mantenham as sessões abertas por um tempo limitado e se reconectem regularmente (como a sincronização de pull de email). Outro exemplo comum para carga NTLM alta são os servidores proxy da Web que exigem autenticação para acesso à Internet.

Esses aplicativos podem causar uma carga significativa para a autenticação NTLM, o que pode colocar um estresse significativo nos DCs, especialmente quando usuários e recursos estão em domínios diferentes.

Existem várias abordagens para gerenciar a carga entre relações de confiança e na prática elas são usadas em conjunto e não em um cenário exclusivo de um ou outro. As opções possíveis são:

• Reduza a autenticação de cliente entre relações de confiança localizando os serviços que um usuário consome no mesmo domínio em que o usuário está residindo.
• Aumente o número de canais seguros disponíveis. Isso é relevante para o tráfego na mesma floresta e entre florestas e são conhecidos como atalhos de relações de confiança.
• Ajuste as configurações padrão para MaxConcurrentAPI.

Para ajustar MaxConcurrentAPI em um servidor existente, a 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

Nenhum, essa é uma configuração de ajuste do sistema operacional.

Exemplo de resumo de cálculo

Tipo de dados	Valor
Aquisições de semáforo (mínimo)	6,161
Aquisições de semáforo (máximo)	6,762
Tempos limite de semáforo	0
Tempo médio de espera do semáforo	0,012
Duração da coleta (segundos)	1:11 minutos (71 segundos)
Fórmula (da KB 2688798)	((6762 – 6161) + 0) × 0.012 /
Valor mínimo para MaxConcurrentAPI	((6762 – 6161) + 0) × 0.012 ÷ 71 = .101

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, foi discutido que o planejamento e o dimensionamento contribuem com os destinos de utilização. Confira um gráfico de resumo dos limites recomendados que devem ser monitorados para garantir que os sistemas estejam operando dentro dos limites de capacidade corretos. Lembre-se que esses não são limites de desempenho, mas limites de planejamento da capacidade. Um servidor que opera além desses limites funcionará, mas é hora de começar a validar se todos os aplicativos estão se comportando bem. Se os aplicativos estiverem se comportando bem, é hora de começar a avaliar atualizações de hardware ou outras alterações de configuração.

Categoria	Contador de desempenho	Intervalo/amostragem	Destino	Aviso
Processador	Informações do processador(_Total)\% Utilitário do processador	60 min	40%	60%
RAM (Windows Server 2008 R2 ou anterior)	Memória/MB disponível	< 100 MB	N/D	< 100 MB
RAM (Windows Server 2012)	Memória\Tempo de vida médio do cache(s) Em espera de longo prazo	30 min	Deve ser testado	Deve ser testado
Rede	Adaptador de rede(*)/Bytes enviados/s Adaptador de rede(*)/Bytes recebidos/s	30 min	40%	60%
Armazenamento	LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Read LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/write	60 min	10 ms	15 ms
Serviços do AD	Netlogon(*)\Tempo médio de espera do semáforo	60 min	0	1 segundo

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

Definições

Processador (microprocessador) – um componente que faz a leitura e execução de instruções do programa

CPU – Unidade de processamento central

Processador multi-core – várias CPUs no mesmo circuito integrado

CPU múltipla – várias CPUs, não em circuitos integrados diferentes

Processador lógico – um mecanismo de computação lógica da perspectiva do sistema operacional

Isso inclui o hyper-threaded, de um núcleo no processador multi-core ou um processador de núcleo único.

Como os sistemas de servidor atuais têm vários processadores, diversos processadores de multi-core e hyper-threading, essas informações são generalizadas para abranger os dois cenários. Dessa forma, o termo processador lógico será usado, pois representa o sistema operacional e a perspectiva 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. Como o AD DS possui multithreads e o número de threads disponíveis pode ser ajustado usando Como exibir e definir a política LDAP no Active Directory usando Ntdsutil.exe, ele pode ser bem dimensionado em vários processadores lógicos.

Paralelismo no nível de dados

Isso envolve o compartilhamento de dados por vários threads em um processo (no caso do processo do AD DS sozinho) e por vários threads em diversos processos (em geral). Com a preocupação de simplificar demais o caso, isso significa que todas as alterações nos dados refletem em todos os threads em execução em todos os vários níveis de cache (L1, L2, L3) por todos os núcleos que executam esses threads, bem como na atualização da memória compartilhada. O desempenho pode piorar durante as operações de gravação, enquanto todos os diversos locais de memória são trazidos consistentes antes que o processamento de instruções possa continuar.

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

A regra geral é que processadores lógicos mais rápidos reduzem a duração necessária para processar uma série de instruções, enquanto processadores mais lógicos significam que mais tarefas podem ser executadas ao mesmo tempo. Essas regras gerais são afetadas à medida que os cenários se tornam inerentemente mais complexos com considerações de busca de dados da memória compartilhada, espera por paralelismo no nível de dados e a sobrecarga do gerenciamento de vários threads. Também é por isso que a escalabilidade em sistemas de vários núcleos não é linear.

Considere as seguintes analogias nestas considerações: pense em uma rodovia, e nela cada thread é um carro, cada faixa é um núcleo e o limite de velocidade é a velocidade de clock.

1. Se há apenas um carro na rodovia, não importa se há duas ou 12 pistas. Esse carro só vai atingir a velocidade que for permitida.
2. Considere que os dados de que o thread precisa não estão disponíveis imediatamente. A analogia seria que um segmento da estrada é desativado. Se existe apenas um carro na rodovia, não importa qual é o limite de velocidade até que a pista seja reaberta (os dados forem buscados da memória).
3. À medida que o número de carros aumenta, a sobrecarga para gerenciar o número de carros também. Compare a experiência de condução e a quantidade de atenção necessária quando a estrada está praticamente vazia (como no final da noite) versus quando o tráfego é pesado (como no meio da tarde, mas não no horário de pico). Além disso, considere a quantidade de atenção necessária ao dirigir em uma rodovia com duas pistas, onde há apenas uma outra pista para se preocupar com o que os motoristas estão fazendo, contra uma rodovia com seis pistas onde deve-se preocupar com o que muitos outros motoristas estão fazendo.

   Observação

   A analogia sobre o cenário do horário de pico é estendida para a próxima seção: tempo de resposta/como a disponibilidade do sistema afeta o desempenho.

Como resultado, as especificações sobre mais processadores ou processadores mais rápidos tornam-se altamente subjetivas ao comportamento do aplicativo, que no caso do AD DS é muito específico de cada ambiente e varia até de um servidor para outro em um ambiente. É por isso que as referências anteriores ao artigo não investem muito em ser excessivamente precisas e uma margem de segurança está incluída nos cálculos. Ao tomar decisões de compra orientadas por orçamento, é recomendável que ocorra primeiro a otimização do uso dos processadores em 40% (ou o número desejado para o ambiente), antes de considerar a compra de processadores mais rápidos. O aumento da sincronização entre mais processadores reduz o verdadeiro benefício de mais processadores da progressão linear (2× o número de processadores fornece menos de 2× potência de computação adicional disponível).

Observação

Os conceitos relevantes aqui são a Lei de Amdahl e a Lei de Gustafson.

Tempo de resposta/Como a disponibilidade do sistema afeta o desempenho

A teoria do enfileiramento é o estudo matemático sobre as linhas de espera (filas). Na teoria do enfileiramento, a Lei de Utilização é representada pela equação:

U k = B ÷ T

Onde U k é o percentual de utilização, B é a quantidade de tempo ocupado e T é o tempo total em que o sistema foi observado. Convertido para o contexto do Windows, isso significa o número de threads de intervalo de 100 ns (nanossegundos) que estão em um estado Em execução divididos por quantos intervalos de 100 ns estavam disponíveis no intervalo de tempo determinado. Essa é a fórmula exata para calcular a % do Utilitário do processador (consulte como referência o 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 (N é o comprimento da fila). O gráfico disso em todos os intervalos de utilização fornece as estimativas a seguir de quanto tempo a fila para entrar no processador está em qualquer carga de CPU fornecida.

Observa-se que, após a carga de CPU de 50%, em média, há sempre uma espera de um outro item na fila, com um aumento visivelmente rápido após cerca de 70% de utilização da CPU.

Retornando à analogia da direção usada nesta seção:

• Os horários de pico do "meio da tarde" cairiam, hipoteticamente, para a faixa de 40% a 70%. Há tráfego suficiente para que ainda seja possível escolher qualquer pista, e a chance de outro motorista estar no caminho, embora seja alta, não exija o nível de esforço de "encontrar" um espaço seguro entre outros carros na estrada.
• Pode-se observar que à medida que o tráfego se aproxima do horário de pico, o sistema rodoviário se aproxima de 100% da capacidade. Mudar de faixa pode se tornar muito desafiador porque os carros estão tão próximos que deve-se exercer um cuidado maior ao fazer isso.

É por isso que as médias de longo prazo para a capacidade estimadas conservadoramente em 40% permitem obter espaço livre para picos anormais na carga, sejam esses picos transitórios (como consultas mal codificadas que são executadas por alguns minutos) ou intermitências anormais na carga geral (na manhã do primeiro dia útil após um fim de semana prolongado).

A instrução acima considera que o cálculo % Processor Time como o mesmo que a Lei de Utilização serve um pouco para simplificar e facilitar para o leitor geral. Para aqueles mais matematicamente rigorosos:

• 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 de 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 de PERF_100NSEC_TIMER_INV.
  • U k = o percentual de utilização do processador lógico pelo "Thread ocioso" ou % Idle Time.
• Estimando os cálculos:
  • U k = 1 – %Processor Time
  • %Processor Time = 1 – U k
  • %Processor Time = 1 – B / T
  • %Processor Time = 1 – X1 – X0 / Y1 – Y0

Aplicação dos conceitos ao planejamento de capacidade

A matemática anterior pode fazer com que as determinações sobre o número de processadores lógicos necessários em um sistema pareçam extremamente complexas. É por isso que a abordagem para dimensionar os sistemas se concentra em determinar a utilização de destino máxima com base na carga atual e calcular o número de processadores lógicos necessários para alcançar isso. Além disso, embora as velocidades do processador lógico tenham um impacto significativo no desempenho, as eficiências de cache, os requisitos de coerência de memória, o agendamento e sincronização de threads e a carga de cliente com balanceamento imperfeito sofrerão impactos significativos no desempenho que variarão de acordo com o servidor. Como a potência de computação custa relativamente pouco, tentar analisar e determinar o número perfeito de CPUs necessárias serviria mais como exercício acadêmico do que forneceria valor comercial.

Quarenta por cento não é um requisito difícil e rápido de atender, mas é um começo razoável. Vários consumidores do Active Directory exigem vários níveis de capacidade de resposta. Pode haver cenários em que os ambientes podem ser executados com 80% ou 90% de utilização como uma média aceitável, pois o aumento dos tempos de espera para o acesso ao processador não afetará visivelmente o desempenho do cliente. É importante iterar novamente que há diversas áreas no sistema muito mais lentas do que o processador lógico no sistema, incluindo acesso à RAM, o acesso ao disco e a transmissão da resposta pela rede. Todos esses itens precisam ser ajustados em conjunto. Exemplos:

• Adicionar mais processadores a um sistema executando em 90% que é associado ao disco provavelmente não melhorará o desempenho de forma significativa. Uma análise mais profunda do sistema provavelmente identificará que há muitos threads que nem sequer estão entrando no processador porque estão esperando que a E/S seja concluída.
• Resolver os problemas associados ao disco potencialmente significa que os threads que anteriormente passavam muito tempo em um estado de espera não estarão mais em um estado de espera para E/S e haverá mais competição pelo tempo da CPU, o que significa que a utilização de 90% no exemplo anterior irá para 100% (porque não pode ser maior). Os dois componentes precisam ser ajustados em conjunto.

  Observação

  Informações do processador(*)\% Utilitário do processador podem exceder 100% nos sistemas que possuem o modo "Turbo". É nessa hora que a CPU excede a velocidade do processador classificada por curtos períodos. Consulte como referência a documentação e a descrição dos fabricantes da CPU do contador para obter mais informações.

A discussão sobre as considerações de utilização de todo o sistema também inclui na conversa os controladores de domínio como convidados virtualizados. O Tempo de resposta/Como a disponibilidade do sistema afeta o desempenho aplica-se ao host e ao convidado em um cenário virtualizado. É por isso que em um host com apenas um convidado, um controlador de domínio (e geralmente todo sistema) apresenta quase o mesmo desempenho que tem no hardware físico. Adicionar mais convidados aos hosts aumenta a utilização do host subjacente, aumentando assim os tempos de espera para obter acesso aos processadores, conforme explicado anteriormente. Resumindo, a utilização lógica do processador precisa ser gerenciada nos níveis de host e de convidado.

Aproveitando as analogias anteriores, colocando a rodovia como o hardware físico, a VM convidada será análoga a um ônibus (um ônibus expresso que vai direto para o destino desejado pelo passageiro). Considere os quatro cenários a seguir:

• Está fora do horário comercial, um passageiro entra em um ônibus que está quase vazio, e o ônibus pega uma estrada que também está quase vazia. Como não há tráfego para enfrentar, o passageiro tem uma boa viagem e chega lá tão rápido quanto se ele mesmo estivesse dirigindo. O tempo de viagem do passageiro ainda é limitado pelo limite de velocidade.
• Está fora do horário comercial, por isso o ônibus está quase vazio, mas a maioria das pistas da estrada estão fechadas, pois a rodovia ainda está congestionada. O passageiro está em um ônibus quase vazio em uma estrada congestionada. Embora o passageiro não tenha muita competição de onde se sentar no ônibus, o tempo total da viagem ainda é ditado pelo resto do tráfego do lado de fora.
• É horário de pico e por isso a rodovia e o ônibus estão congestionados. Além da viagem levar mais tempo, entrar e sair do ônibus é um pesadelo porque as pessoas estão lado a lado e a rodovia não está muito melhor. Adicionar mais ônibus (processadores lógicos ao convidado) não significa que eles caberiam na estrada mais facilmente, ou que a viagem seria encurtada.
• O cenário final, embora a analogia possa estar sendo usada em demasia, é aquele onde o ônibus está cheio, mas a estrada não está congestionada. E o passageiro ainda terá problemas para entrar e sair do ônibus, mas a viagem será eficiente depois que o ônibus pegar a estrada. Esse é o único cenário em que adicionar mais ônibus (processadores lógicos ao convidado) melhorará o desempenho do convidado.

A partir daí, é relativamente fácil extrapolar que há uma série de cenários entre o estado de 0%-utilizados e 100%utilizados da estrada e o estado de 0%- e 100% utilizados do ônibus que geram graus diferentes de impacto.

Aplicar as entidades de segurança acima de 40% da CPU como destino razoável para o host, bem como o convidado, é um início razoável pelo mesmo motivo mencionado acima, a quantidade de filas.

Apêndice B: considerações sobre diferentes velocidades do processador e o efeito do gerenciamento de energia do processador nas velocidades do processador

Ao longo das seções sobre seleção do processadores, é considerado que o processador esteja executando a 100% da velocidade de clock durante todo o tempo em que os dados estão sendo coletados e que os sistemas de substituição terão os mesmos processadores de velocidade. Apesar das duas considerações serem falsas na prática, especialmente no Windows Server 2008 R2 e posteriores, em que o plano de energia padrão é Balanceado, a metodologia ainda permanece, pois é a abordagem conservadora. Embora a taxa de erros potencial possa aumentar, ela aumenta a margem de segurança somente conforme as velocidades do processador aumentam.

• Por exemplo, em um cenário em que 11,25 CPUs são exigidas, se os processadores estavam executando com metade da velocidade quando os dados foram coletados, a estimativa mais precisa pode ser 5,125 ÷ 2.
• É impossível garantir que ao dobrar as velocidades de clock isso dobraria a quantidade de processamento que acontece por um determinado período. Isso ocorre devido ao fato de que o tempo gasto pelos processadores aguardando a RAM ou outros componentes do sistema pode permanecer o mesmo. O efeito líquido é que os processadores mais rápidos podem gastar uma porcentagem maior do tempo ocioso enquanto esperam que os dados sejam buscados. Novamente, é recomendável manter o menor denominador comum ao ser conservador, evitando a tentativa de calcular um nível potencialmente falso de precisão ao considerar uma comparação linear entre as velocidades de processador.

Opcionalmente, se as velocidades de processador no hardware de substituição forem menores do que o hardware atual, seria seguro aumentar a estimativa dos processadores necessários por uma quantidade proporcional. Por exemplo, calcula-se que 10 processadores são necessários para sustentar a carga em um site, e os processadores atuais estão executando em 3,3 Ghz e os processadores de substituição serão executados em 2,6 Ghz, o que é uma redução de 21% na velocidade. Nesse caso, 12 processadores seriam a quantidade recomendada.

Sendo assim, essa variabilidade não alteraria os destinos de utilização do processador de Gerenciamento de Capacidade. Como as velocidades de clock do processador serão ajustadas dinamicamente com base na carga exigida, a execução do sistema sob cargas mais altas gerará um cenário em que a CPU passa mais tempo em um estado de velocidade de clock maior, tornando a meta final de ser de 40% de utilização em um estado de velocidade de clock de 100% no pico. Períodos menores do que isso gerarão economia de energia, pois as velocidades da CPU serão limitadas novamente durante cenários fora do horário de pico.

Observação

Uma opção seria desativar o gerenciamento de energia nos processadores (definindo o plano de energia como Alto desempenho) enquanto os dados são coletados. Isso geraria uma representação mais precisa do consumo de CPU no servidor de destino.

Para ajustar estimativas de processadores diferentes, costumava ser seguro considerar que duplicar as velocidades do processador dobraria a quantidade de processamento que poderia ser executada, exceto outros gargalos do sistema descritos acima. No momento, a arquitetura interna dos processadores é diferente o suficiente entre processadores, e a forma mais segura de medir os efeitos do uso de processadores diferentes dos dados que foram obtidos é aproveitar o parâmetro de comparação SPECint_rate2006 da Corporação de Avaliação de Desempenho Padrão.

1. Localize as pontuações SPECint_rate2006 para o processador que está em uso e o plano a ser usado.

   1. No site da Corporação de Avaliação de Desempenho Padrão, selecione Resultados, realce a CPU2006 e selecione Pesquisar todos os resultados para SPECint_rate2006.
   2. Em Solicitação simples, insira os critérios de pesquisa para o processador de destino, por exemplo, Correspondências de processador E5-2630 (baselinetarget) e Correspondências de processador E5-2650 (linha de base).
   3. Localize a configuração a ser usada do servidor e do processador (ou algo próximo, se uma correspondência exata não estiver disponível) e observe o valor nas colunas Resultados e Número de núcleos.

2. Use a seguinte equação para determinar o modificador:

   ((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))

   Usando o exemplo acima:

   (35.83 × 2000) ÷ (33.75 × 2300) = 0.92

3. Multiplique o número estimado de processadores pelo modificador. No caso acima, para ir do processador E5-2650 para o processador E5-2630, multiplique as CPUs calculadas de 11,25 × 0,92 = 10,35 processadores necessários.

Apêndice C: conceitos básicos sobre o sistema operacional interagindo com o armazenamento

Os conceitos da teoria de enfileiramento descritos em Tempo de resposta/Como a disponibilidade do sistema afeta o desempenho também são aplicáveis ao armazenamento. Saber como o sistema operacional lida com a E/S é necessário para aplicar esses conceitos. No sistema operacional do Microsoft Windows, uma fila para manter as solicitações de E/S é criada para cada disco físico. No entanto, é necessário esclarecer algo sobre o disco físico. Controladores de matriz e SANs apresentam agregações de eixos para o sistema operacional como discos físicos únicos. Além disso, controladores de matriz e SANs podem agregar vários discos em um conjunto de matrizes e dividir essa matriz definida em várias "partições", que, por sua vez, é apresentada ao sistema operacional como vários discos físicos (figura de ref.).

Nessa figura, os dois eixos são espelhados e divididos em áreas lógicas para armazenamento de dados (Dados 1 e Dados 2). Essas áreas lógicas são exibidas pelo sistema operacional como discos físicos separados.

Embora isso possa ser extremamente confuso, a terminologia a seguir é usada em todo esse apêndice para identificar as diferentes entidades:

• Eixo – o dispositivo que está fisicamente instalado no servidor.
• Matriz – uma coleção de eixos agregados pelo controlador.
• Partição de matriz – um particionamento da matriz agregada
• LUN – uma matriz, usada ao fazer referência às SANs
• Disco – O que o sistema operacional constata como um disco físico único.
• Partição – um particionamento lógico do que o sistema operacional percebe como um disco físico.

Considerações sobre arquitetura de sistema operacional

O sistema operacional cria uma fila de E/S do FIFO (primeiro a entrar, primeiro a sair) para cada disco que é observado; esse disco pode estar representando um eixo, uma matriz ou uma partição de matriz. Do ponto de vista do sistema operacional, quanto mais filas ativas, melhor, no que diz respeito ao tratamento de E/S. Como uma fila FIFO é serializada, o que significa que todas as E/S emitidas para o subsistema de armazenamento devem ser processadas na ordem em que a solicitação chegou. Depois de correlacionar cada disco observado pelo sistema operacional a um eixo/matriz, o sistema operacional manterá uma fila de E/S para cada conjunto exclusivo de discos, eliminando assim a contenção de recursos de E/S escassos em discos e isolando a demanda de E/S para um único disco. Como exceção, o Windows Server 2008 apresenta o conceito de priorização de E/S e os aplicativos projetados para usar a prioridade "Baixa" deixam essa ordem normal e ficam em segundo plano. Aplicativos não codificados especificamente para aproveitar o padrão de prioridade "Baixa" para "Normal".

Introdução aos subsistemas de armazenamento simples

A partir de um exemplo simples (um disco rígido único dentro de um computador), será fornecida uma análise de componente por componente. Dividindo isso pelos principais componentes do subsistema de armazenamento, o sistema consiste em:

• 1 – 10.000 RPM Ultra Fast SCSI HD (o SCSI Ultra rápido tem uma taxa de transferência de 20 MB/s)
• 1 – Barramento SCSI (o cabo)
• 1 – Adaptador SCSI Ultra rápido
• 1 – Barramento PCI de 33 MHz de 32 bits

Depois que os componentes são identificados, é possível calcular a quantidade de dados que podem transitar pelo sistema ou a quantidade de E/S que pode ser tratada. Observe que a quantidade de E/S e a quantidade de dados que podem transitar pelo sistema está correlacionada, mas não é a mesma. Essa correlação depende se a E/S do disco é aleatória ou sequencial e do tamanho do bloco. (Todos os dados são gravados no disco como um bloco, mas aplicativos diferentes usando tamanhos de bloco diferentes). De componente por componente:

• O disco rígido – O disco rígido médio de 10.000 RPM tem um tempo de procura de 7 ms (milissegundos) e um tempo de acesso de 3 ms. O tempo de procura é a quantidade média de tempo que ele leva para o cabeçote de leitura/gravação se mover para um local na bandeja. O tempo de acesso é o tempo médio que leva para ler ou gravar os dados no disco, quando o cabeçote está no local correto. Sendo assim, o tempo médio da leitura de um bloco exclusivo de dados em um HD de 10.000 RPM constitui uma procura e um acesso, por um total de aproximadamente 10 ms (ou 0,010 segundos) por bloco de dados.

  Quando cada acesso ao disco exige a movimentação do cabeçote para um novo local no disco, o comportamento de leitura/gravação é chamado de "aleatório". Sendo assim, quando toda E/S é aleatória, um HD de 10.000 RPM pode tratar aproximadamente E/S de 100 por segundo (IOPS) (a fórmula é 1000 ms por segundo dividida por 10 ms por E/S ou 1000/10=100 IOPS).

  Opcionalmente, quando toda E/S ocorre a partir de setores adjacentes no HD, isso é chamado de E/S sequencial. A E/S sequencial não tem tempo de procura porque quando a primeira E/S é concluída, o cabeçote de leitura/gravação está no início de onde o próximo bloco de dados é armazenado no HD. Portanto, um HD de 10.000 RPM é capaz de tratar aproximadamente E/S de 333 por segundo (1000 ms por segundo dividido por 3 ms por E/S).

  Observação

  Este exemplo não reflete o cache de disco, em que os dados de um cilindro normalmente são mantidos. Nesse caso, os 10 ms são necessários na primeira E/S e o disco lê todo o cilindro. Todas as outras E/S sequenciais são atendidas do cache. Como resultado, os caches em disco podem melhorar o desempenho sequencial de E/S.

  A taxa de transferência do disco rígido foi irrelevante até o momento. Ainda que o disco rígido seja de 20 MB/s Ultra Wide ou um Ultra3 de 160 MB/s, a quantidade real de IOPS que pode ser tratada pelo HD de 10.000 RPM é de aproximadamente E/S de 100 aleatória ou de 300 sequencial. Como os tamanhos de bloco mudam com base na gravação do aplicativo na unidade, a quantidade de dados que é extraída por E/S é diferente. Por exemplo, se o tamanho do bloco for de 8 KB, 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/gravarão 3.200 KB (3,2 MB) no disco rígido. Desde que a taxa de transferência SCSI seja superior à quantidade total de dados transferidos, obter uma unidade de taxa de transferência "mais rápida" não adiantará nada. Consulte as tabelas a seguir para efeito de comparação.

  Description	Procura de 7.200 RPM 9ms, acesso de 4ms	Procura de 10.000 RPM 7ms, acesso de 3ms	Procura de 15.000 RPM 4ms, acesso de 2ms
  E/S Aleatória	80	100	150
  E/S Sequencial	250	300	500

  Unidade de 10.000 RPM	Tamanho do bloco de 8 KB (Jet do Active Directory)
  E/S Aleatória	800 KB/s
  E/S Sequencial	2400 KB/s

• Backplane SCSI (barramento) – Entender como o "backplane SCSI (barramento)", ou nesse cenário, o cabo da faixa de opções, afeta a taxa de transferência do subsistema de armazenamento depende do conhecimento do tamanho do bloco. Basicamente, a pergunta seria, quanta E/S o barramento poderá tratar se a E/S estiver em blocos de 8 KB? Nesse cenário, o barramento SCSI é de 20 MB/s ou 20.480 KB/s. 20480 KB/s divididos em blocos de 8 KB produz um máximo de aproximadamente 2.500 IOPS compatíveis com o barramento SCSI.

  Observação

  As figuras na tabela a seguir representam um exemplo. Atualmente, a maioria dos dispositivos de armazenamento conectados usa o PCI Express, que fornece uma taxa de transferência muito maior.

  E/S compatível com o barramento SCSI por tamanho de bloco	Tamanho do bloco de 2 KB	Tamanho do bloco de 8 KB (AD Jet) (SQL Server 7.0/SQL Server 2000)
  20 MB/s	10.000	2\.500
  40 MB/s	20,000	5\.000
  128 MB/s	65.536	16.384
  320 MB/s	160.000	40.000

  Como pode ser determinado com base nesse gráfico, no cenário apresentado e independentemente do uso, o barramento nunca será um gargalo, pois o máximo de eixos é de 100 E/S, bem abaixo de qualquer um dos limites acima.

  Observação

  Isso supõe que o barramento SCSI seja 100% eficiente.

• Adaptador SCSI – Para determinar a quantidade de E/S que ele pode tratar, as especificações do fabricante precisam ser verificadas. Direcionar solicitações de E/S para o dispositivo apropriado exige algum tipo de processamento, portanto, a quantidade de E/S que pode ser tratada depende do processador do adaptador SCSI (ou controlador de matriz).

  Neste exemplo, será considerado que 1.000 E/S podem ser tratadas.

• Barramento PCI – Muitas vezes esse componente é ignorado. Neste exemplo, este não será o gargalo; no entanto, à medida que os sistemas são escalados verticalmente, ele pode se tornar um gargalo. Para referência, um barramento PCI de 32 bits que opera a 33Mhz pode transferir 133 MB/s de dados, em teoria. Veja a equação a seguir:

  32 bits ÷ 8 bits por byte × 33 MHz = 133 MB/s.

  Observe que é o limite teórico; de fato, apenas cerca de 50% do máximo é realmente atingido, embora em determinados cenários de intermitência, 75% de eficiência possa ser obtida por curtos períodos.

  Um barramento PCI de 66Mhz de 64 bits pode dar suporte a um máximo teórico de (64 bits ÷ 8 bits por byte × 66 Mhz) = 528 MB/s. Além disso, qualquer outro dispositivo (como o adaptador de rede, o segundo controlador SCSI e assim por diante) reduzirá a largura de banda disponível à medida que ela for compartilhada e os dispositivos disputarão os recursos limitados.

Após a análise dos componentes desse subsistema de armazenamento, o eixo é o fator limitante na quantidade de E/S que pode ser solicitada e, consequentemente, a quantidade de dados que podem transitar pelo sistema. Especificamente, em um cenário do AD DS, isso é 100 E/S aleatórias por segundo em incrementos de 8 KB, para um total de 800 KB por segundo ao acessar o banco de dados Jet. Opcionalmente, a taxa de transferência máxima para um eixo alocado exclusivamente para arquivos de log sofreria as seguintes limitações: de 300 E/S sequencial por segundo em incrementos de 8 KB, para um total de 2.400 KB (2,4 MB) por segundo.

Agora, após analisar uma configuração simples, a tabela a seguir demonstra onde o gargalo ocorrerá à medida que os componentes no subsistema de armazenamento forem alterados ou adicionados.

Observações	Análise de gargalo	Disco	Barramento	Adaptador	Barramento PCI
Essa é a configuração do controlador de domínio depois de adicionar um segundo disco. A configuração de disco representa o gargalo em 800 KB/s.	Adicionar um disco (Total=2) A E/S é aleatória Tamanho do bloco de 4 KB HD de 10.000 RPM	E/S total de 200 800 KB/s total.
Após adicionar sete discos, a configuração de disco ainda representa o gargalo em 3200 KB/s.	Adicionar sete discos (Total=8) A E/S é aleatória Tamanho do bloco de 4 KB HD de 10.000 RPM	Total de E/S de 800. 3200 KB/s total
Depois de alterar E/S para sequencial, o adaptador de rede se torna o gargalo porque está limitado a 1000 IOPS.	Adicionar sete discos (Total=8) A E/S é sequencial Tamanho do bloco de 4 KB HD de 10.000 RPM			E/S de 2400 sequenciais podem ser lidas/gravadas em disco, controlador limitado a 1000 IOPS
Depois de substituir o adaptador de rede por um adaptador SCSI que dá suporte a 10.000 IOPS, o gargalo retorna à configuração do disco.	Adicionar sete discos (Total=8) A E/S é aleatória Tamanho do bloco de 4 KB HD de 10.000 RPM Atualizar adaptador SCSI (agora dá suporte à E/S de 10.000)	Total de E/S de 800. 3.200 KB/s total
Depois de aumentar o tamanho do bloco para 32 KB, o barramento se torna o gargalo porque dá suporte apenas a 20 MB/s.	Adicionar sete discos (Total=8) A E/S é aleatória Tamanho do bloco de 32 KB HD de 10.000 RPM		Total de E/S de 800. 25.600 KB/s (25 MB/s) podem ser lidos/gravados em disco. O barramento só dá suporte a 20 MB/s
Depois de atualizar o barramento e adicionar mais discos, o disco continua sendo o gargalo.	Adicionar 13 discos (Total=14) Adicionar o segundo adaptador SCSI com 14 discos A E/S é aleatória Tamanho do bloco de 4 KB HD de 10.000 RPM Atualizar para o barramento SCSI de 320 MB/s	E/S de 2.800 11.200 KB/s (10,9 MB/s)
Depois de alterar E/S para sequencial, o disco continua sendo o gargalo.	Adicionar 13 discos (Total=14) Adicionar o segundo adaptador SCSI com 14 discos A E/S é sequencial Tamanho do bloco de 4 KB HD de 10.000 RPM Atualizar para o barramento SCSI de 320 MB/s	E/S de 8.400 33.600 KB/s (32.8 MB/s)
Após adicionar discos rígidos mais rápidos, o disco continua sendo o gargalo.	Adicionar 13 discos (Total=14) Adicionar o segundo adaptador SCSI com 14 discos A E/S é sequencial Tamanho do bloco de 4 KB HD de 15.000 RPM Atualizar para o barramento SCSI de 320 MB/s	E/S de 14.000 56.000 KB/s (54.7 MB/s)
Depois de aumentar o tamanho do bloco para 32 KB, o barramento PCI se torna o gargalo.	Adicionar 13 discos (Total=14) Adicionar o segundo adaptador SCSI com 14 discos A E/S é sequencial Tamanho do bloco de 32 KB HD de 15.000 RPM Atualizar para o barramento SCSI de 320 MB/s				E/S de 14.000 448.000 KB/s (437 MB/s) é o limite de leitura/gravação para o eixo. O barramento PCI dá suporte a um máximo teórico de 133 MB/s (75% de eficiência na melhor das hipóteses).

Introdução ao RAID

A natureza de um subsistema de armazenamento não muda drasticamente quando um controlador de matriz é introduzido, pois ele substitui apenas o adaptador SCSI nos cálculos. O que muda é o custo de leitura e gravação de dados no disco ao usar os vários níveis de matriz (como RAID 0, RAID 1 ou RAID 5).

Em RAID 0, os dados são distribuídos em todos os discos no conjunto RAID. Isso significa que, durante uma operação de leitura ou gravação, uma parte dos dados é extraída ou enviada por push para cada disco, aumentando a quantidade de dados que podem transitar pelo sistema durante o mesmo período. Sendo assim, em um segundo, em cada eixo (novamente considerando unidades de 10.000 RPM), 100 operações de E/S podem ser executadas. A quantidade total de E/S para a qual há suporte é N eixos vezes E/S de 100 por segundo por eixo (resultando em E/S de 100*N por segundo).

Em RAID 1, os dados são espelhados (duplicados) em um par de eixos para redundância. Sendo assim, quando uma operação de E/S de leitura é executada, os dados podem ser lidos de ambos os eixos no conjunto. Isso efetivamente disponibiliza a capacidade de E/S de ambos os discos durante uma operação de leitura. A ressalva é que as operações de gravação não geram nenhuma vantagem de desempenho em um RAID 1. Isso ocorre porque os mesmos dados precisam ser gravados nas duas unidades para fins de redundância. Mas isso não leva muito tempo, pois a gravação de dados ocorre simultaneamente nos dois eixos, pois eles estão ocupados duplicando os dados, uma operação de E/S de gravação basicamente impede que ocorram duas operações de leitura. Assim, cada E/S de gravação custa duas E/S de leitura. Uma fórmula pode ser criada a partir dessas informações para determinar o número total de operações de E/S que estão ocorrendo:

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

Quando a taxa de leituras para gravações e o número de eixos são conhecidos, a equação a seguir pode ser derivada da equação mencionada a fim de identificar a E/S máxima que a matriz pode dar suporte:

IOPS máximo por eixo × 2 eixos × [(%Reads + %Writes) ÷ (%Reads + 2 × %Writes)] = IOPS total

RAID 1+ 0 se comporta exatamente da mesma forma que RAID 1 em relação aos custos de leitura e gravação. No entanto, agora a E/S é distribuída em cada conjunto espelhado. If

IOPS máximo por eixo × 2 eixos × [(%Reads + %Writes) ÷ (%Reads + 2 × %Writes)] = E/S total

em um conjunto RAID 1, quando uma multiplicidade (N) de conjuntos RAID 1 é distribuída, a E/S Total que pode ser processada torna-se N × E/S por conjunto RAID 1:

N × {IOPS máximo por eixo × 2 eixos × [(%Reads + %Writes) ÷ (%Reads + 2 × %Writes)] } = IOPS total

No RAID 5, às vezes chamado de RAID N + 1, os dados são distribuídos em eixos N e as informações de paritário são gravadas no eixo "+ 1". No entanto, RAID 5 é muito mais caro ao executar uma E/S de gravação do que RAID 1 ou 1 + 0. RAID 5 executa o seguinte processo sempre que uma E/S de gravação é enviada para a matriz:

1. Lê os dados antigos
2. Lê o paritário antigo
3. Grava os novos dados
4. Grava o novo paritário

Como cada solicitação de E/S de gravação enviada ao controlador de matriz pelo sistema operacional exige a conclusão de quatro operações de E/S, as solicitações de gravação enviadas demoram quatro vezes mais para serem concluídas como uma E/S de leitura única. Para derivar uma fórmula para converter solicitações de E/S da perspectiva do sistema operacional para aquela experimentada pelos eixos:

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

Da mesma forma em um conjunto RAID 1, quando a proporção de leituras para gravações e o número de eixos são conhecidos, a equação a seguir pode ser derivada da equação acima para identificar a E/S máxima que a matriz pode dar suporte (Observe que o número total de eixos não inclui a "unidade" perdida para o paritário):

IOPS por eixo × (Eixos – 1) × [(%Reads + %Writes) ÷ (%Reads + 4 × %Writes)] = IOPS total

Introdução ao SANs

Expandindo a complexidade do subsistema de armazenamento, quando uma SAN é introduzida no ambiente, os princípios básicos descritos não mudam, no entanto, o comportamento de E/S de todos os sistemas conectados à SAN precisa considerado. Como uma das principais vantagens em usar uma SAN é uma quantidade adicional de redundância sobre o armazenamento conectado interna ou externamente, o planejamento da capacidade agora precisa considerar as necessidades de tolerância a falhas. Além disso, mais componentes foram introduzidos e precisam ser avaliados. Dividindo uma SAN pelas partes do componente:

• Disco rígido SCSI ou Fibre Channel
• Backplane do canal da unidade de armazenamento
• Unidades de armazenamento
• Módulo do controlador de armazenamento
• Comutador(es) de SAN
• HBA(s)
• O barramento PCI

Ao criar qualquer sistema para redundância, componentes adicionais são incluídos para acomodar o potencial de falhas. É muito importante, no planejamento da capacidade, excluir o componente redundante dos recursos disponíveis. Por exemplo, se a SAN tiver dois módulos de controlador, a capacidade de E/S de um módulo de controlador será o total do que deve ser usado para a taxa de transferência total de E/S disponível para o sistema. Isso ocorre porque se um controlador falhar, toda a carga de E/S exigida por todos os sistemas conectados precisará ser processada pelo controlador restante. Como todo o planejamento de capacidade é feito para períodos de pico de uso, os componentes redundantes não devem ser fatorados nos recursos disponíveis e a utilização de pico planejada não deve exceder 80% de saturação do sistema (a fim de acomodar intermitências ou comportamento anormal do sistema). Da forma similar, o comutador SAN redundante, a unidade de armazenamento e os eixos não devem ser fatorados nos cálculos de E/S.

Ao analisar o comportamento do disco rígido SCSI ou Fibre Channel, o método de analisar o comportamento, conforme descrito anteriormente, não é alterado. Embora existam certas vantagens e desvantagens em cada protocolo, o fator limitante por disco é a limitação mecânica do disco rígido.

Analisar o canal na unidade de armazenamento é exatamente o mesmo que calcular os recursos disponíveis no barramento SCSI ou largura de banda (como 20 MB/s) dividida pelo tamanho do bloco (como 8 KB). Há um desvio simples do exemplo anterior na agregação de vários canais. Por exemplo, se houver seis canais, cada um dando suporte à taxa de transferência máxima de 20 MB/s, a quantidade total de E/S e transferência de dados disponíveis será de 100 MB/s (isso está correto, não será de 120 MB/s). Novamente, a tolerância a falhas é um player importante nesse cálculo, no caso da perda de um canal inteiro, o sistema fica apenas com cinco canais em funcionamento. Portanto, para continuar atendendo às expectativas de desempenho em caso de falhas, a taxa de transferência total para todos os canais de armazenamento não deve exceder 100 MB/s (isso considera que a carga e a tolerância a falhas está distribuída uniformemente em todos os canais). Transformar isso em um perfil de E/S depende do comportamento do aplicativo. No caso da E/S do Jet do Active Directory, isso se correlacionaria a E/S de aproximadamente 12.500 por segundo (100 MB/s ÷ 8 KB por E/S).

Em seguida, é necessário obter as especificações do fabricante para os módulos do controlador a fim de entender qual é a taxa de transferência que cada módulo pode dar suporte. Neste exemplo, a SAN tem dois módulos de controlador que dão suporte à E/S de 7.500 cada. A taxa de transferência total do sistema poderá ser de 15.000 IOPS se a redundância não for desejada. No cálculo da taxa de transferência máxima em caso de falha, a limitação é a taxa de transferência de um controlador ou de 7.500 IOPS. Esse limite está bem abaixo do máximo de 12.500 IOPS (considerando o tamanho do bloco de 4 KB) que pode ter suporte de todos os canais de armazenamento e, portanto, é atualmente o gargalo na análise. Ainda para fins de planejamento, a E/S máxima desejada para ser planejada seria E/S de 10.400.

Quando os dados saem do módulo do controlador, ele transita por uma conexão do Fibre Channel com taxa em 1 GB/s (ou 1 Gigabit por segundo). Para correlacionar isso com as outras métricas, 1 GB/s se transforma em 128 MB/s (1 GB/s ÷ 8 bits/byte). Como isso excede a largura de banda total em todos os canais da unidade de armazenamento (100 MB/s), isso não afunilará o sistema. Além disso, como esse é apenas um dos dois canais (a conexão adicional de 1 GB/s do Fibre Channel serve para redundância), se uma conexão falhar, a conexão restante ainda terá capacidade suficiente para lidar com toda a transferência de dados exigida.

À caminho do servidor, os dados provavelmente transitarão um comutador de SAN. Como o comutador de SAN precisa processar a solicitação de E/S de entrada e encaminhá-la para a porta apropriada, o comutador terá um limite para a quantidade de E/S que poderá ser tratada e serão necessárias as especificações dos fabricantes para determinar qual será o limite. Por exemplo, se houver dois comutadores e cada um puder tratar 10.000 IOPS, a taxa de transferência total será de 20.000 IOPS. Novamente, a tolerância a falhas será uma preocupação se um comutador falhar, a taxa de transferência total do sistema será de 10.000 IOPS. Como é desejado não exceder 80% de utilização em operação normal, o alvo deveria ser usar no máximo E/S de 8.000.

Por fim, o HBA instalado no servidor também teria um limite para a quantidade de E/S que ele pode tratar. Normalmente, um segundo HBA é instalado para redundância, mas assim como com o comutador de SAN, ao calcular a E/S máxima que pode ser tratada, a taxa de transferência total de HBAs N – 1 é qual é a escalabilidade máxima do sistema.

Considerações sobre armazenamento em cache

Os armazenamentos em caches são um dos componentes que podem afetar significativamente o desempenho geral em qualquer ponto do sistema de armazenamento. A análise detalhada sobre algoritmos de armazenamento em cache está além do escopo deste artigo; mas algumas instruções básicas sobre o armazenamento em cache em subsistemas de disco valem a pena ser esclarecidas:

• O armazenamento em cache melhora a E/S de gravação sequencial aceitável, pois pode armazenar em buffer muitas operações de gravação menores em blocos de E/S maiores e desativar o estágio para armazenamento em poucos tamanhos de bloco, mas maiores. Isso reduzirá a E/S aleatória total e a E/S sequencial total, fornecendo assim mais disponibilidade de recursos para outras E/S.

• O armazenamento em cache não melhora a taxa de transferência de E/S de gravação aceitável do subsistema de armazenamento. Ele só permite que as gravações sejam armazenadas em buffer até que os eixos estejam disponíveis para confirmar os dados. Quando toda a E/S disponível dos eixos no subsistema de armazenamento estiver saturada por longos períodos, o cache acabará ficando cheio. Para esvaziar o cache, tempo suficiente entre intermitências ou eixos extras precisa ser alocado para fornecer E/S suficiente para permitir que o cache seja liberado.

  Caches maiores só permitem que mais dados sejam armazenados em buffer. Isso significa que períodos mais longos de saturação podem ser acomodados.

  Em um subsistema de armazenamento normalmente operacional, o sistema operacional experimentará um melhor desempenho de gravação, pois os dados só precisam ser gravados em cache. Depois que a mídia subjacente estiver saturada de E/S, o cache encherá e o desempenho de gravação retornará à velocidade do disco.

• Ao armazenar em cache a E/S de leitura, o cenário em que o cache é mais vantajoso é quando os dados são armazenados sequencialmente no disco, e o cache pode ser lido antecipadamente (ele considera que o próximo setor contém os dados que serão solicitados a seguir).

• Quando a E/S de leitura é aleatória, é improvável que o armazenamento em cache no controlador de unidade forneça um aprimoramento na quantidade de dados que podem ser lidos do disco. Um aprimoramento não existirá se o sistema operacional ou o tamanho do cache baseado em aplicativo for maior que o tamanho do cache baseado em hardware.

  No caso do Active Directory, o cache é limitado apenas pela quantidade de RAM.

Considerações sobre SSD

Os SSDs são um caso completamente diferente dos discos rígidos baseados em eixo. No entanto, os dois critérios principais permanecem os mesmos: "Quantos IOPS ele pode tratar?" e "Qual é a latência para esses IOPS?" Em comparação com discos rígidos baseados em eixo, os SSDs podem tratar volumes maiores de E/S e podem ter latências mais baixas. Em geral e a partir desta escrita, enquanto os SSDs ainda são caros comparados ao custo por Gigabyte, eles são muito baratos em termos de custo por E/S e merecem consideração significativa em termos de desempenho de armazenamento.

Considerações:

• Tanto o IOPS quanto as latências são muito subjetivos aos designs do fabricante e, em alguns casos, observou-se que apresentaram um desempenho pior do que o das tecnologias baseadas em eixo. Resumindo, é mais importante examinar e validar as especificações do fabricante de unidade por unidade e não generalizar nada.
• Os tipos de IOPS podem ter números bem diferentes, dependendo se é de leitura ou gravação. Os serviços do AD DS, em geral, como são predominantemente baseados em leitura, são menos afetados do que alguns outros cenários de aplicativo.
• "Resistência de gravação" – esse é o conceito que as células de SSD acabarão esgotando. Vários fabricantes lidam com esse desafio de formas diferentes. Pelo menos para a unidade de banco de dados, o perfil de E/S predominantemente de leitura permite minimizar a significância dessa preocupação, pois os dados não são altamente voláteis.

Resumo

Uma maneira de pensar no armazenamento é imaginando o encanamento doméstico. Imagine que o IOPS da mídia em que os dados estão armazenados é o principal ralo doméstico. Quando ele está entupido (como quando há raízes no cano) ou limitado (está rompido ou é muito pequeno), todas as pias da casa ficam sem vazão quando muita água está sendo usada (há muitos hóspedes). Isso é perfeitamente análogo a um ambiente compartilhado em que um ou mais sistemas estão aproveitando o armazenamento compartilhado em um SAN/NAS/iSCSI com a mesma mídia subjacente. Diferentes abordagens podem ser usadas para resolver os diferentes cenários:

• Um ralo rompido ou subdimensionado necessita de uma substituição e correção de grande escala. Isso seria semelhante a adicionar um novo hardware ou redistribuir os sistemas usando o armazenamento compartilhado em toda a infraestrutura.
• Um cano "entupido" geralmente significa a identificação de um ou mais problemas ofensivos e a remoção desses problemas. Em um cenário de armazenamento, isso pode ser backups de armazenamento ou de nível de sistema, verificações de antivírus sincronizadas em todos os servidores e software de desfragmentação sincronizado em execução durante os períodos de pico.

Em qualquer projeto de encanamento, vários ralos se alimentam do ralo principal. Se alguma coisa interromper um desses ralos ou um ponto de junção, apenas o que há atrás desse ponto de junção vazará. Em um cenário de armazenamento, isso pode ser um comutador sobrecarregado (cenário SAN/NAS/iSCSI), problemas de compatibilidade do driver (combinação de driver/HBA Firmware/storport.sys incorreta) ou backup/antivírus/desfragmentação. Para determinar se o "cano" de armazenamento é grande o suficiente, o tamanho de E/S e IOPS precisa ser medido. Em cada junção, adicione-as juntas para garantir o "diâmetro de cano" correto.

Apêndice D – Discussão sobre solucionar problemas de armazenamento – Ambientes em que fornecer tanta RAM quanto o tamanho do banco de dados não é uma opção viável

É útil entender por que essas recomendações existem para que as alterações na tecnologia de armazenamento possam ser acomodadas. Essas recomendações existem por dois motivos. O primeiro é o isolamento de E/S, para que os problemas de desempenho (ou seja, paginação) no eixo do sistema operacional não afetem o desempenho dos perfis de E/S e banco de dados. O segundo motivo é que os arquivos de log do AD DS (e a maioria dos bancos de dados) são sequenciais por natureza, e os discos rígidos e caches baseados em eixo ganham um enorme desempenho quando usados com E/S sequencial em comparação com os padrões de E/S mais aleatórias do sistema operacional e padrões de E/S quase puramente aleatórias da unidade de banco de dados do AD DS. Ao isolar a E/S sequencial para uma unidade física separada, a taxa de transferência pode ser aumentada. O desafio apresentado pelas opções de armazenamento atuais é que as suposições básicas por trás dessas recomendações não são mais verdadeiras. Em muitos cenários de armazenamento virtualizado, como arquivos de imagem de iSCSI, SAN, NAS e disco virtual, a mídia de armazenamento subjacente é compartilhada entre vários hosts, negando completamente os aspectos de "isolamento de E/S" e "otimização de E/S sequencial". Na verdade, esses cenários adicionam mais uma camada de complexidade na qual outros hosts que acessam a mídia compartilhada podem diminuir a capacidade de resposta ao controlador de domínio.

Ao planejar o desempenho do armazenamento, deve-se considerar três categorias: o estado do cache frio, o estado do cache inicializado e o backup/restauração. O estado de cache frio ocorre em cenários como quando o controlador de domínio é inicialmente reinicializado ou o serviço do Active Directory é reiniciado e não há dados do Active Directory na RAM. O estado de cache inicializado é quando o controlador de domínio está em um estado estável e o banco de dados está em cache. É importante observar isso, pois eles conduzirão perfis de desempenho muito diferentes e ter RAM suficiente para armazenar em cache todo o banco de dados não ajuda o desempenho quando o cache é frio. É possível considerar o design de desempenho para esses dois cenários com a analogia a seguir, a inicialização do cache frio é um "tiro de corrida" e executar um servidor com um cache inicializado é uma "maratona".

Para o cenário de cache frio e de cache quente, a pergunta seria com qual rapidez o armazenamento pode mover os dados do disco para a memória. A inicialização do cache é um cenário em que, com o tempo, o desempenho melhora à medida que mais consultas reutilizam dados, a taxa de cliques do cache aumenta e a frequência de necessidade de ir para o disco diminui. Como resultado, o impacto adverso no desempenho de ida para o disco diminui. Toda degradação no desempenho é apenas transitória ao aguardar o cache inicializar e aumentar até o tamanho máximo permitido dependente do sistema. A conversa pode ser simplificada para a rapidez com que os dados podem ser retirados do disco e é uma medida simples do IOPS disponível para o Active Directory, que é subjetivo ao IOPS disponível no armazenamento subjacente. Do ponto de vista do planejamento, como os cenários de inicialização de cache e backup/restauração ocorrem de forma excepcional, normalmente eles ocorrem fora do horário de pico e são sujeitos à carga do DC e as recomendações gerais não existem, exceto porque essas atividades são agendadas ocorrerem fora dos horários de pico.

O AD DS, na maioria dos cenários, tem E/S predominantemente de leitura, geralmente com uma taxa de 90% de leitura para 10% de gravação. A E/S de leitura geralmente tende a ser o gargalo para a experiência do usuário e, com a E/S de gravação, faz com que o desempenho de gravação diminua. Como a E/S para o NTDS.dit é predominantemente aleatória, os caches tendem a fornecer um benefício mínimo para E/S de leitura, tornando muito mais importante configurar o armazenamento para o perfil de E/S de leitura corretamente.

Em condições operacionais normais, a meta de planejamento de armazenamento é minimizar os tempos de espera para que uma solicitação do AD DS seja retornada do disco. Isso significa basicamente que o número de E/S excepcionais e pendentes é menor ou equivalente ao número de caminhos para o disco. Há várias maneiras de medir isso. Em um cenário de monitoramento de desempenho, a recomendação geral é que LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Read seja menor que 20 ms. O limite operacional desejado deve ser muito menor, preferencialmente o mais próximo possível da velocidade do armazenamento, no intervalo de 2 a 6 milissegundos (0,002 a 0,006 segundo), dependendo do tipo de armazenamento.

Exemplo:

Analisando o gráfico:

• Oval verde à esquerda – A latência permanece consistente em 10 ms. A carga aumenta de 800 IOPS para 2400 IOPS. Esse é o piso absoluto para a rapidez com que uma solicitação de E/S pode ser processada pelo armazenamento subjacente. Isso está sujeito às especificidades da solução de armazenamento.
• Oval borgonha à direita – A taxa de transferência permanece plana desde a saída do círculo verde até o final da coleta de dados, enquanto a latência continua aumentando. Isso demonstra que, quando os volumes de solicitação excedem as limitações físicas do armazenamento subjacente, mais tempo as solicitações passam na fila aguardando para serem enviadas para o subsistema de armazenamento.

Aplicando esse conhecimento:

• Impacto para um usuário consultando a associação de um grupo grande – Considere que isso exige a leitura de 1 MB de dados do disco, a quantidade de E/S e quanto tempo isso leva podem ser avaliados da seguinte maneira:
  • As páginas de banco de dados do Active Directory têm 8 KB de tamanho.
  • No mínimo, 128 páginas precisam ser lidas do disco.
  • Supondo que nenhuma esteja armazenado em cache, no piso (10 ms) isso levará no mínimo 1,28 segundos para carregar os dados do disco e devolvê-los ao cliente. Em 20 ms, em que a taxa de transferência no armazenamento já foi máxima e também é o máximo recomendado, levará 2,5 segundos para obter os dados do disco e devolvê-los ao usuário final.
• A que taxa o cache será aquecido – Considerando que a carga do cliente maximizará a taxa de transferência neste exemplo de armazenamento, o cache sera inicializado a uma taxa de 2400 IOPS × 8 KB por E/S. Ou, aproximadamente 20 MB/s por segundo, carregando cerca de 1 GB de banco de dados em RAM a cada 53 segundos.

Observação

É normal que em períodos curtos as latências subam quando os componentes leem ou gravam agressivamente em disco, como quando está sendo feito backup do sistema ou quando o AD DS está executando a coleta de lixo. Espaço de cabeçote adicional sobre os cálculos deve ser fornecido para acomodar esses eventos periódicos. A meta é fornecer taxa de transferência suficiente para acomodar esses cenários sem afetar o funcionamento normal.

Como se pode ver, há um limite físico baseado no design de armazenamento para a rapidez com que o cache pode ser inicializado. O que inicializará o cache serão as solicitações de cliente de entrada até a taxa que o armazenamento subjacente pode fornecer. A execução de scripts para "pré-inicializar" o cache durante o horário de pico fornecerá concorrência pela carga orientada por solicitações reais do cliente. Isso pode afetar negativamente a entrega dos dados que os clientes precisam primeiro porque, por design, isso gerará concorrência pelos recursos de disco escassos à medida que tentativas artificiais de inicializar o cache carregarão dados que não são relevantes para os clientes que entram em contato com o DC.