Exportar (0) Imprimir
Expandir Tudo
Expandir Minimizar

Consolidação do SQL Server na plataforma de 32 bits usando um ambiente de cluster

O que se aprendeu

Publicado em: 5 de janeiro de 2004


Autor: Mike Ruthruff

Resumo: Este documento apresenta as lições aprendidas nos cenários de teste nos quais a Microsoft consolidou os bancos de dados do Microsoft® SQL Server™ que anteriormente residiam em servidores físicos separados, colocando-os em um único ambiente de cluster de 32 bits do Windows.

Nesta página

Visão geral
Configuração do ambiente de consolidação
Gerenciando o desempenho da carga de trabalho em um ambiente consolidado
Utilizando várias instâncias do SQL Server
Considerações sobre AWE para ambientes com cluster
Conclusão
Apêndice A: Configuração e desempenho do armazenamento
Apêndice B: Referências
Apêndice C: Configuração de hardware

Visão geral

O desempenho do Microsoft® SQL Server™ em ambientes consolidados depende em grande parte do hardware que está sendo usado e das características das cargas de trabalho do SQL Server envolvidas. Existem restrições impostas pela arquitetura da plataforma de 32 bits, as quais afetam a capacidade de o SQL Server utilizar completamente os sistemas com grandes quantidades de memória física. A utilização de várias instâncias é uma abordagem para a utilização total de grandes recursos de memória em uma única máquina. No entanto, isso pode exigir um maior cuidado com as opções de ajuste usadas no SQL Server, especialmente quando o serviço Cluster é usado em conjunto com o SQL Server.

Este documento aborda as lições aprendidas nos cenários de teste nos quais a Microsoft criou e operou um servidor para consolidar em um ambiente de cluster de 32 bits as instâncias do SQL Server que anteriormente estavam localizadas em máquinas separadas. Especificamente, este documento fornece:

  • Um exemplo de uma configuração de 32 bits que pode ser usada para consolidação do banco de dados.

  • Informações sobre o agrupamento do SQL Server em um ambiente de SAN (rede de área de armazenamento).

  • Informações sobre como executar várias instâncias simultâneas do SQL Server, inclusive as opções de ajuste que podem ser usadas para otimizar o desempenho.

  • Considerações adicionais para o agrupamento do SQL Server em um ambiente de memória grande.

Este documento não tem o objetivo de abordar todas as questões encontradas durante a consolidação de bancos de dados do SQL Server. Sua intenção é apresentar as lições aprendidas durante os testes em uma configuração específica. Além disso, os resultados dos cenários apresentados neste documento não se aplicam necessariamente a todos os ambientes consolidados. Para obter mais informações sobre o planejamento necessário para selecionar e implantar com êxito os ambientes para consolidação do SQL Server, consulte o recurso "Planejando a consolidação com o Microsoft SQL Server 2000" no Apêndice B.

Configuração do ambiente de consolidação

Configuração do hardware do host

Para o servidor de consolidação dos cenários de teste apresentados neste documento, a Microsoft utilizou um servidor Unisys ES7000. Esse servidor foi dividido em duas partições, cada uma delas com metade do total de recursos da máquina. Cada partição foi configurada com 16 CPUs, 32 gigabytes (GB) de RAM e quatro HBAs (adaptadores de barramento do host) Emulex LP9000. Ambas as partições estavam executando o sistema operacional Microsoft Windows® Server™ 2003, Datacenter Edition e o SQL Server 2000 com o Service Pack 3 (SP3). As partições foram agrupadas com o Windows Clustering. O software EMC PowerPath foi utilizado para equilibrar a E/S nos quatro HBAs em cada um dos dois nós do Cluster do Windows.

Configuração do armazenamento

Os requisitos do Windows Clustering ditaram a configuração de armazenamento utilizada no ambiente de teste. Há dois requisitos principais para o armazenamento utilizado com instâncias agrupadas do SQL Server:

  • Quando este documento foi redigido, o SQL Server não oferecia suporte a volumes de ponto de montagem para uso com instâncias agrupadas do SQL Server. Conseqüentemente, as letras das unidades devem ser usadas para quaisquer recursos de disco compartilhados. Para obter mais informações sobre o suporte do SQL Server a volumes de ponto de montagem, consulte o Apêndice B.

  • Cada instância do SQL Server deve ter pelo menos um dos recursos de disco compartilhados.

Além desses requisitos, há outras considerações especiais na implementação de agrupamento com uma SAN. Para obter mais informações sobre o agrupamento em um ambiente SAN, consulte o Apêndice B.

A configuração de armazenamento utilizada nos cenários de teste deste documento foi a storage array (matriz de armazenamento) EMC Symmetrix 5.5 modelo 8530. Durante os testes, a array (matriz) também estava sendo usada por outro host para outro teste do SQL Server não relacionado. O armazenamento total da parte da SAN utilizada para os cenários de teste foi de aproximadamente 1,6 terabytes distribuídos em 22 LUNs (números de unidades lógicas), consistindo em nove LUNs de 108 GB e treze LUNs de 54 GB. Esses LUNs foram mapeados para letras de unidades do Windows e cada LUN foi configurado como um volume separado. Nos cenários de teste, havia no total 16 instâncias do SQL Server, cada uma com um ou dois volumes. Os tamanhos dos bancos de dados variaram de 10 GB no ponto mínimo até aproximadamente 150 GB no ponto máximo.

Para ter uma visão mais detalhada da configuração do armazenamento e dos resultados do desempenho nos cenários de teste apresentados neste documento, consulte o "Apêndice A: Configuração e desempenho do armazenamento".

Bancos de dados e cargas de trabalho de consolidação

O Microsoft SQL Server 2000 pode dar suporte a até 16 instâncias do mecanismo de banco de dados do SQL Server em um único computador que esteja executando o Windows. Para os cenários de teste abordados neste documento, a Microsoft instalou 16 instâncias nomeadas do SQL Server como servidores virtuais agrupados nos dois nós agrupados da configuração. Cada instância do SQL Server continha entre 1 e 25 bancos de dados e a maioria das instâncias tinha em média cinco.

Das 16 instâncias do SQL Server, 12 continham bancos de dados reunidos a partir de várias fontes, tanto de implantações internas quanto externas da Microsoft, e cada fonte era um banco de dados de produção real. A carga de trabalho desses bancos de dados foi criada com o SQL Profiler para reproduzir rastreamentos das cargas de trabalho de produção capturados anteriormente. Os tipos de carga de trabalho capturados nesses rastreamentos foram principalmente cargas de trabalho de OLTP (transações online), embora alguns rastreamentos contivessem algumas consultas relacionadas a manutenção ou outras consultas que foram criadas com um objetivo específico. As cargas de trabalho de OLTP consistem principalmente em inserções, exclusões e atualizações dos dados, juntamente com algumas consultas seletivas.

As quatro instâncias restantes do SQL Server consistiam em dois bancos de dados com cargas de trabalho de OLTP representativas e dois bancos de dados com DSS (sistema de suporte à decisão) representativo, também chamados de cargas de trabalho de RDW (armazenamento de dados relacionais). As cargas de trabalho do DSS consistiam em consultas complexas somente leitura com planos de execução em paralelo.

Antes de definir as cargas de trabalho de consolidação, a Microsoft primeiro determinou quantas instâncias simultâneas do SQL Server poderiam ter suporte usando as cargas de trabalho em nosso ambiente de hardware específico. A decisão sobre quantas cargas de trabalho simultâneas seriam executadas a qualquer momento baseou-se na capacidade do hardware de um único nó do cluster. Para a configuração das cargas de trabalho e do hardware nos cenários de teste, a CPU foi o recurso limitante. Os recursos da CPU foram esgotados antes de qualquer outro recurso de hardware principal. A execução da carga de trabalho em 10 instâncias simultâneas do SQL Server resultou em quase 80 por cento de utilização média de CPU em todas as 16 CPUs de um único nó. Essa se tornou a carga de trabalho de consolidação da linha de base, porque estava próxima à capacidade de um único nó, deixando apenas recursos de CPU suficientes disponíveis para poder adicionar uma ou duas cargas de trabalho adicionais.

Durante os testes de desempenho, a Microsoft executou quatro cenários de carga de trabalho de consolidação diferentes. As cargas de trabalho usadas são mostradas na Tabela 1.1. Esses cenários foram selecionados para medir o efeito da inclusão de cargas de trabalho de manutenção adicionais de OLTP, DSS e DBCC (comando de console de banco de dados) na linha de base.

Tabela 1.1   Detalhes da carga de trabalho de consolidação

Carga de trabalho

Descrição da carga de trabalho

Carga de trabalho A (considerada a linha de base)

10 rastreamentos do SQL Profiler reproduzidos simultaneamente. Os rastreamentos do SQL Profiler continham principalmente cargas de trabalho de OLTP, com algumas consultas no estilo de manutenção ou outras consultas criadas com um objetivo específico.

Carga de trabalho B

A carga de trabalho A mais dois rastreamentos do SQL Profiler adicionais reproduzindo cargas de trabalho de OLTP. As cargas de trabalho de OLTP foram adicionadas porque a utilização de CPU adicional combinada das duas estava próxima em comparação com a utilização de CPU com a inclusão de cargas de trabalho do DSS ou de manutenção.

Carga de trabalho C

A carga de trabalho A mais uma instância do SQL Server executando uma carga de trabalho no estilo DSS (consistindo em consultas select complexas).

Carga de trabalho D

A carga de trabalho A mais uma instância do SQL Server executando uma carga de trabalho exclusivamente relacionada a manutenção (DBCC CHECKDB, DBCC SHOWCONTIG e DBREINDEX de todas as tabelas de usuário do banco de dados).


Gerenciando o desempenho da carga de trabalho em um ambiente consolidado

Opções de ajuste do SQL Server

Em sistemas maiores, pode-se obter ganhos significativos no desempenho por meio do ajuste do SQL Server com as opções do procedimento armazenado SP_CONFIGURE. Para examinar o efeito que as diferentes configurações tiveram no desempenho do ambiente consolidado, a Microsoft aplicou diferentes configurações durante os cenários de teste e mediu os ganhos ou as perdas de desempenho resultantes. Cada uma das configurações a seguir foi testada em todas as quatro cargas de trabalho mencionadas anteriormente na Tabela 1.1:

  • Configurações padrão do servidor. Todas as instâncias do SQL Server foram executadas com as configurações padrão do servidor.

  • Máscara de afinidade (usando a afinidade da CPU para dividir igualmente os recursos da CPU). Cada grupo de três instâncias do SQL Server foi atribuído a um grupo de quatro CPUs (um total de 12 instâncias ativas em qualquer momento). Os grupos foram determinados com base na utilização de CPU observada durante as execuções anteriores. As instâncias do SQL Server que exigiram mais recursos da CPU foram alocadas em grupos separados.

  • Afinidade de E/S (usando afinidade de E/S e CPU para definir a função de cada CPU). As 16 CPUs da configuração foram divididas de forma que 12 CPUs foram usadas para processamento do SQL Server e 4 CPUs foram dedicadas a E/S. Todas as instâncias do SQL Server da configuração podiam usar qualquer uma das 12 CPUs para processamento.

  • Grau máximo de paralelismo (limitando a quantidade de paralelismo nos planos de consulta). A opção MAXDOP foi definida como quatro para todas as instâncias do SQL Server. Todas as outras opções foram definidas para os valores padrão.

  • /3GB, memória máxima do servidor e memória mínima do servidor. Nenhum teste foi feito com essas configurações no sistema de 32 bits.

    Nos cenários de teste apresentados neste documento, a opção de inicialização /3GB não foi utilizada porque o sistema usado na configuração tinha 32 GB de RAM. Para utilizar mais do que 4 GB de memória física, é necessário iniciar o Windows com a opção de inicialização /PAE no arquivo Boot.ini. A habilitação de /3GB com /PAE em sistemas com mais de 16 GB de memória física fará com que o sistema operacional reconheça somente 16 GB de memória disponível no sistema quando for iniciado.

    Os cenários de teste também não precisaram de qualquer ajuste nas configurações de memória mínima do servidor e memória máxima do servidor, porque o sistema utilizado na configuração tinha 32 GB de memória física e somente 12 instâncias ativas do SQL Server estavam sendo executadas de cada vez. O limite da memória prática de cada instância do SQL Server em uma plataforma de 32 bits é pouco menos de 2 GB, portanto o consumo cumulativo de memória dos processos do SQL Server nos cenários de teste não passou de 24 GB. A configuração dos limites de memória superior do SQL Server é considerada uma prática recomendada e deve ser executada em ambientes consolidados, se houver possibilidade de contenção de memória entre as instâncias. Colocar uma instância do SQL Server online quando outras instâncias já consumiram quase toda a memória disponível no sistema pode resultar na queda do desempenho em todas as instâncias.

Resultados do desempenho da carga de trabalho de várias instâncias

Os resultados dos testes de desempenho da carga de trabalho indicam que, para ambientes consolidados, a utilização de configurações padrão do servidor freqüentemente leva a um desempenho geral muito bom em comparação com outras opções de ajuste do SQL Server. A Figura 1.1 e a Figura 1.2 mostram a utilização da CPU do sistema e o total de transações por segundo em todas as instâncias do SQL Server que tinham cargas de trabalho transacionais. Para obter detalhes sobre cada tipo de carga de trabalho, consulte a Tabela 1.1.

Figure 1.1 Cumulative transactions per second

Figura 1.1   Transações cumulativas por segundo

Figure 1.2 Total CPU utilization

Figura 1.2   Total de utilização da CPU

A Figura 1.1 e a Figura 1.2 demonstram que, em todos os cenários de carga de trabalho, a configuração de afinidade da CPU ou de afinidade de E/S resultou em uma taxa de transferência transacional mais baixa e na não utilização do total de recursos da CPU. A utilização dessas configurações também não resultou em qualquer redução significativa do número de opções de contexto. Em todos os cenários de carga de trabalho, as opções de contexto por segundo variaram de 20.000 a 25.000. A afinidade de CPU e a afinidade de E/S são definidas com pouca freqüência e somente em implantações seletivas com um grande número de CPUs, para ajustar com êxito o desempenho de uma única instância do SQL Server ou para gerenciar a coexistência de instâncias diferentes. No entanto, para o ambiente consolidado dos cenários de teste, permitir que o SQL Server gerencie os recursos da CPU simplificou a configuração e resultou em melhor taxa de transferência geral em todas as cargas de trabalho. É recomendável que você teste caso a caso antes de decidir se uma dessas configurações deve ser usada, pois o benefício em termos de desempenho pode variar com base nas características das cargas de trabalho envolvidas.

Dois dos cenários de carga de trabalho apresentados resultaram em uma taxa de transferência transacional mais alta quando a opção MAXDOP foi definida como quatro em vez do padrão (zero). Houve uma taxa de transferência transacional mais alta apesar da utilização total da CPU mais baixa. Em certas consultas, o processador de consultas do SQL Server criará um plano de execução paralela que pode resultar na execução da consulta em todas as CPUs disponíveis. A execução paralela de uma consulta em todas as CPUs disponíveis pode ser benéfica para o desempenho dessa consulta em particular, mas pode exigir mais recursos da CPU e, dessa forma, atrapalhar o desempenho de outras consultas que também estão sendo executadas no sistema. A configuração de um limite para a opção MAXDOP no sistema com muitas CPUs pode ser benéfica. É recomendável que você faça o teste com e sem a configuração da opção MAXDOP para garantir que nenhuma consulta ou conjunto de consultas utilizará uma quantidade desproporcional de recursos da máquina.

Resultados heterogêneos de desempenho da carga de trabalho

Em geral, uma boa prática é separar os tipos de carga de trabalho diferentes (por exemplo, DSS e OLTP) em servidores separados. Porém, isso pode não ser vantajoso em todos os cenários de consolidação. Para determinar qual é o impacto das cargas de trabalho de DSS em outras cargas de trabalho de OLTP simultâneas, a Microsoft utilizou nos cenários de teste uma carga de trabalho de consolidação que continha uma carga de trabalho de DSS que utiliza muito a E/S. A carga de trabalho de DSS consistiu em um conjunto de consultas select complexas (com muitas relações complexas e alta utilização do banco de dados tempdb). A carga de trabalho consolidada é representada como Carga de trabalho C na Figura 1.1 e na Figura 1.2. A Figura 1.3 e a Figura 1.4 mostram o aumento na atividade de leitura de E/S das cargas de trabalho de DSS e de manutenção nos cenários de teste.

Figure 1.3 Disk reads per second

Figura 1.3   Leituras de disco por segundo

Figure 1.4 Disk writes per second

Figura1.4   Gravações no disco por segundo

Como demonstram essas ilustrações, as cargas de trabalho que contêm as consultas de DSS e de manutenção executaram um número maior de leituras de disco do que as cargas de trabalho que consistem principalmente em consultas de OLTP. O impacto das cargas de trabalho que utilizam muito a E/S, como DSS, no desempenho total do sistema depende muito do desempenho do subsistema de disco. Nos cenários de teste, as cargas de trabalho de DSS foram executadas simultaneamente, com o mínimo de impacto no desempenho das cargas de trabalho de OLTP. Esse desempenho foi conseguido sem qualquer ajuste especial do subsistema de E/S.

Devido ao grande número de arquivos de bancos de dados e relacionados a bancos de dados nos cenários de teste, o armazenamento não foi configurado com qualquer isolamento físico entre os arquivos de dados, log e tempdb. Da mesma forma, o armazenamento não foi configurado com qualquer isolamento físico entre as instâncias do SQL Server que tinham cargas de trabalho de DSS e as instâncias que tinham cargas de trabalho de OLTP. Em vez disso, a configuração do armazenamento distribuiu cada um dos LUNs expostos pela SAN entre o máximo de discos físicos possível. Para o SQL Server, isolar fisicamente os dados dos arquivos de log é sempre uma prática recomendada no nível de disco. No entanto, esse procedimento nem sempre é prático em ambientes de consolidação, especialmente naqueles em que são usadas SANs (redes de área de armazenamento). Em muitos casos, na realidade o armazenamento pode ser compartilhado com outros sistemas, como nos cenários de teste apresentados neste documento. A capacidade de consolidar com êxito as cargas de trabalho heterogêneas em um único sistema depende muito das características da carga de trabalho e do desempenho do subsistema de E/S. Se você estiver tentando consolidar cargas de trabalho com características de E/S muito diferentes, deverá fazer um teste cuidadoso para determinar o efeito sobre o desempenho de E/S do sistema inteiro.

Utilizando várias instâncias do SQL Server

Nos cenários de teste apresentados neste documento, houve dois motivos principais para a utilização de várias instâncias do SQL Server:

  • O objetivo do teste foi criar um ambiente com um servidor grande executando muitas instâncias do SQL Server simultaneamente, para medir o desempenho e determinar qual seria o melhor ajuste do desempenho desse ambiente.

  • Na plataforma de 32 bits, a utilização de várias instâncias do SQL Server permite a total utilização da grande quantidade da memória física instalada no servidor Unisys ES7000 (32 GB por nó de cluster, o que resulta em aproximadamente 2 GB de memória alocada para cada instância do SQL Server).

Cada grupo de bancos de dados de um servidor diferente foi colocado em sua própria instância do SQL Server, simplificando a implantação e a configuração gerais dos cenários de teste. Os backups dos bancos de dados de servidores separados foram restaurados no servidor de consolidação.

Se você estiver consolidando bancos de dados de servidores diferentes na mesma instância do SQL Server, lembre-se de considerar questões como conflitos de logon, bem como configurações de agrupamento e ordem de classificação, além de outras configurações específicas do servidor. O mapeamento para instâncias separadas do SQL Server simplifica esse processo. Além disso, com várias instâncias do SQL Server, é possível isolar as cargas de trabalho, sendo que cada instância tem o seu próprio banco de dados tempdb. Para obter mais informações sobre como planejar e tratar essas questões de implantação, consulte "Planejando a consolidação com o Microsoft SQL Server 2000", no Apêndice B.

Em plataformas de 32 bits configuradas com 4 GB ou mais de memória física, você pode usar AWE (extensões de janela de endereço) ou várias instâncias do SQL Server como uma maneira de utilizar totalmente a grande quantidade de memória física. A AWE pode funcionar bem em alguns cenários, mas esteja ciente de que a memória AWE só pode ser usada para cache de dados. A memória para o cache de procedimentos, as conexões, os bloqueios e os outros recursos internos do SQL Server deve vir da parte de 2 GB (ou 3 GB, dependendo das configurações utilizadas) da memória virtual. Em sistemas que precisam dar suporte a um grande número de bancos de dados e conexões de usuários, várias instâncias do SQL Server podem ser uma abordagem melhor para eliminar totalmente a restrição de 2 GB ou 3 GB de memória, imposta pela plataforma de 32 bits a essas estruturas de dados.

Considerações sobre heap de área de trabalho

Nos ambientes em que muitos serviços estão sendo executados sob contas de usuário distintas, saiba que isso pode esgotar os recursos de heap da área de trabalho e pode ser necessário fazer algum ajuste para garantir que os serviços possam ser iniciados com êxito. Cada serviço executado como uma conta de usuário específica será executado em sua própria estação do Windows. Cada estação do Windows pode conter zero ou mais áreas de trabalho e cada objeto de área de trabalho possui uma heap de área de trabalho associada. Uma quantidade finita de heap de área de trabalho está disponível para o Windows e quando essa heap disponível se esgota, podem ocorrer falhas na inicialização de serviços. Você pode configurar a quantidade de heap de área de trabalho alocada por cada estação do Windows utilizando o Registro, e pode ser necessário diminuir a quantidade alocada por cada área de trabalho não interativa para permitir que todos os serviços sejam iniciados sem falhas. Essa necessidade depende do número de serviços que está sendo executado e do número de contas de usuário distintas existentes. Para obter mais informações sobre as estações do Windows, as áreas de trabalho, os tipos de erros que podem ocorrer e como controlar a quantidade de heap de área de trabalho alocada por cada estação não interativa do Windows, consulte o Apêndice B.

Considerações sobre AWE para ambientes com cluster

Após medir o desempenho da carga de trabalho do ambiente consolidado nos cenários de teste, a Microsoft testou instâncias do SQL Server habilitadas para AWE, com o objetivo de determinar como elas se comportariam durante o failover.

Memória AWE e desempenho na inicialização

Quando o SQL Server inicia as instâncias configuradas para usar a memória AWE, ele deve alocar e confirmar as páginas de memória no início do processo. Por razões de segurança, as páginas da memória utilizadas pelo SQL Server devem ser inicializadas com zeros antes de serem usadas pelo processo do SQL Server. O que determina o tempo que o SQL Server leva para ser iniciado é a existência ou não de páginas de memória suficientes no Windows, inicializadas com zeros, para satisfazer os pedidos de alocação no início do processo. Se não houver páginas suficientes disponíveis, será necessário inicializar páginas de memória com zeros durante o início do processo. Terminado o processo do SQL Server, à medida que as páginas de memória são liberadas de volta para o Windows e colocadas na lista de páginas livres, o Windows tem um segmento de página zero (prioridade 0) que irá zerar as páginas de memória. No Windows Server 2003 (assim como no Windows 2000 com o Service Pack 3 ou posterior com o hotfix mencionado no Apêndice B) a inicialização das páginas com zeros ocorre em paralelo em todas as CPUs. Nas versões anteriores do Windows, a inicialização com zeros das páginas de memória ocorria em um único segmento, podendo resultar em maior tempo de inicialização de instâncias do SQL Server habilitadas para AWE e executadas em sistemas com memória grande.

Nos cenários de teste, o tempo de inicialização de instâncias do SQL Server habilitadas para AWE, configuradas para usar aproximadamente 31,5 GB de RAM, variou de menos de 30 segundos até aproximadamente 4 minutos, dependendo de a página de memória precisar ou não ser inicializada com zeros. Nas instâncias do SQL Server habilitadas para AWE que demoram muito para ser iniciadas, pode ser necessário alterar algumas das configurações relacionadas ao serviço Cluster. Esse serviço possui uma propriedade Tempo Limite Pendente no recurso do SQL Server. Se o SQL Server não for iniciado dentro do tempo limite, o serviço Cluster emitirá uma solicitação de parada para o Gerenciador de Controle de Serviços e tentará reiniciar o serviço. Em sistemas de memória grande nos quais o SQL Server é habilitado para AWE, pode ser necessário ajustar o tempo limite padrão (30 segundos) para um valor mais alto.

Instâncias do SQL habilitadas para AWE e failover

Nos cenários de agrupamento ativo/ativo em servidores com memória física superior a 4 GB em cada nó, você pode configurar instâncias do SQL Server com a memória AWE habilitada. O SQL Server permite que você configure a memória de maneira que a memória cumulativa consumida por todas as instâncias executadas em vários nós seja maior do que a memória física disponível em um único nó. Como a memória AWE é alocada estatisticamente e só é liberada quando o processo termina, você deve sempre definir a opção de memória máxima do servidor, SP_CONFIGURE, para limitar a quantidade de memória consumida por qualquer instância em particular, garantindo assim que sempre haja memória física suficiente disponível para qualquer instância que possa falhar. Em geral considera-se uma prática recomendada a configuração de clusters ativo/ativo de forma que os recursos cumulativos consumidos em todos os nós nunca sejam superiores aos recursos disponíveis em um único nó. Esse procedimento garante que sempre haja recursos de sistema adequados caso ocorra um failover. O ponto negativo associado é que toda a memória não está sendo utilizada o tempo todo.

O comportamento das instâncias do SQL Server habilitadas para AWE em situações de failover é o mesmo de qualquer instância do SQL Server habilitada para AWE quando iniciada. Esse comportamento pode ser descrito da seguinte forma:

  • Se houver 2 GB ou menos de RAM física disponível, quando uma instância do SQL Server habilitada para AWE for iniciada ela reverterá para um modelo de memória dinâmica, independentemente da configuração de AWE.

  • Se houver pouco mais do que 2 GB de RAM física disponível (isto é, na faixa de 128 a 300 MB de memória adicional), quando uma instância do SQL Server habilitada para AWE for iniciada ela irá adquirir na inicialização o máximo de memória disponível, até a configuração de memória máxima do servidor. Se a configuração de memória máxima do servidor for zero, a instância obterá o máximo de memória possível e ainda deixará alguma memória para o sistema operacional (no mínimo 128 MB).

A configuração dos cenários de teste demonstrou que o SQL Server sempre tentará deixar um pouco mais de memória física para o Windows quando a AWE estiver habilitada, ou seja, de 128 a 300 MB. De fato, no teste de desempenho, o SQL Server sempre tentou deixar essa quantidade de espaço para o Windows, independentemente da configuração da AWE.

A Tabela 1.2 contém exemplos de consumo de memória antes e após o failover, para diferentes cenários de failover de AWE. Em cada um dos cenários, as instâncias habilitadas para AWE foram configuradas com a opção habilitada para AWE definida como um e a memória mínima do servidor igual à memória máxima do servidor.

Tabela 1.2   Cenários de consumo de memória AWE

Cenário

Memória total (por nó)

Consumo de memória antes do failover

Consumo de memória após o failover

Duas instâncias habilitadas para AWE (uma por nó, ativa/ativa).

Cada instância é configurada com memória máxima do servidor = 20 GB.

32 GB

A instância no Nó 1 tem 20 GB.

A instância no Nó 2 tem 20 GB.

A instância original no Nó 1 tem 20 GB.

A instância com falha tem aproximadamente 11,7 GB.

Quatro instâncias habilitadas para AWE (duas por nó, ativa/ativa).

Cada instância é configurada com memória máxima do servidor = 10 GB.

32 GB

Cada instância no Nó 1 tem 10 GB.

Cada instância no Nó 2 tem 10 GB.

Cada uma das instâncias originais no Nó 1 tem 10 GB.

Se as instâncias falharem em seqüência:

A primeira instância que falhou obtém 10 GB. A segunda instância que falhou reverte para a memória dinâmica.

Se as instâncias falharem ao mesmo tempo:

A quantidade de memória consumida por cada instância varia, mas o total de memória cumulativa consumida pelas duas instâncias será de quase 11,7 GB.


Se houver instâncias não habilitadas para AWE em execução na máquina, as instâncias habilitadas para AWE que ficarem online não resultarão na redução da memória consumida pelas instâncias não habilitadas para AWE e estas irão reter toda a memória que têm. Isso independe de as instâncias não habilitadas para AWE estarem ocupadas ou ociosas. Isso ocorre porque o SQL Server determina a quantidade de memória AWE a ser alocada na inicialização com base na configuração de memória máxima do servidor e na quantidade de memória física disponível.

Embora o SQL Server sempre tente deixar espaço para o sistema operacional, quando a memória física disponível no sistema é insuficiente e instâncias adicionais ficam online, o sistema pode começar a usar a memória virtual do arquivo de paginação. Isso pode afetar negativamente o desempenho geral do sistema. Lembre-se dessas considerações ao configurar a memória para várias instâncias do SQL Server.

Conclusão

O desempenho do SQL Server em ambientes consolidados depende em grande parte do hardware que está sendo usado e das características das cargas de trabalho do SQL Server envolvidas. Os cenários de teste apresentados neste documento fornecem informações sobre como o SQL Server se comportará em ambientes consolidados. No entanto, esteja ciente de que os resultados incluídos aqui não se aplicarão necessariamente a todas as configurações. Antes de consolidar instâncias separadas dos SQL Servers em um único servidor, analise bem para determinar o nível de utilização de recursos no sistema atual. Para obter mais informações sobre como planejar uma consolidação de muitas instâncias em um único servidor, consulte os recursos do Apêndice B.

Principais pontos abordados neste documento:

  • O SQL Server 2000 oferece suporte para até 16 instâncias simultâneas em uma única instância do Windows. Na realidade, o número de instâncias com suporte é limitado pelos recursos de hardware disponíveis. O hardware dos cenários de teste conseguiu dar suporte à carga de trabalho de 12 instâncias simultâneas antes de esgotar os recursos da CPU.

  • Se você estiver agrupando o SQL Server em um ambiente SAN, deverá estar ciente das considerações especiais existentes e é recomendável trabalhar em conjunto com o seu fornecedor de armazenamento. Além disso, verifique se todo o hardware da configuração está na HCL (lista de compatibilidade de hardware do Windows).

  • Para os ambientes consolidados que contêm muitas instâncias do SQL Server, os resultados dos cenários de teste indicam que não há necessidade de ajuste de afinidade de CPU ou E/S e, de fato, isso pode até reduzir o desempenho da carga de trabalho. Por outro lado, o ajuste da opção MAXDOP melhorou o desempenho da carga de trabalho em certos casos.

  • Para ambientes agrupados nos quais as instâncias do SQL Server usam a memória AWE, a quantidade de memória adquirida por uma instância do SQL Server durante o failover depende da quantidade de memória disponível. Em certos casos, as instâncias habilitadas para AWE podem reverter para o modelo de memória dinâmica.


Apêndice A: Configuração e desempenho do armazenamento

A storage array EMC Symmetrix 5.5 modelo 8530 foi utilizada no teste de consolidação da plataforma de 32 bits apresentado neste documento. Os requisitos de agrupamento das instâncias do SQL Server determinaram a maneira como o armazenamento foi configurado para o teste. Há dois requisitos principais para o armazenamento em clusters do SQL Server:

  1. Quando este documento foi redigido, o SQL Server não oferecia suporte para volumes de ponto de montagem para uso com instâncias agrupadas do SQL Server. É necessário usar letras de unidades para quaisquer recursos de disco compartilhados.

  2. Cada instância do SQL Server deve ter pelo menos um dos recursos de disco compartilhados.

Na configuração da storage array, não foi prático estabelecer isolamento físico entre os arquivos de dados, log e tempdb no nível de eixo, devido ao número total de arquivos. Além disso, o número limitado de letras de unidade disponíveis e a necessidade de utilizá-las para agrupamento levou à decisão de colocar os arquivos de dados, log e tempdb no mesmo LUN. Como resultado, todos os arquivos de uma determinada instância do SQL Server compartilharam discos físicos comuns e cada instância tinha um ou dois dos LUNs como recursos de disco compartilhados. A storage array foi configurada de forma que cada LUN incluiu o máximo de discos físicos possível e o RAID 1+0 foi utilizado para otimizar o desempenho. Havia um total de aproximadamente 191 arquivos de dados e de log em todas as instâncias virtuais do SQL Server (sem incluir os arquivos tempdb e de banco de dados do sistema). A Tabela B.1 fornece informações sobre a utilização de cada um dos LUNs.

Tabela B.1   Configuração do LUN

LUN

Tamanho

Utilização

Eixos

LD0 – LD12

54 GB

Arquivos de dados, log e tempdb

8 no total para cada LUN

LD13 – LD21

108 GB

Arquivos de dados, log e tempdb

16 no total para cada LUN


As Figuras B 1 e B 2 incluídas aqui são uma referência ao desempenho de E/S conseguido durante o teste com essa configuração de armazenamento. Nos testes de desempenho, o recurso de hardware limitante foi a disponibilidade da CPU. O desempenho de E/S foi bom mesmo sem o isolamento físico no design.

Figure B 1 Disk throughput with a default settings configuration

Figure B 1   Taxa de transferência de disco com uma configuração padrão

Figure B.2 Average disk latency with a default settings configuration

Figura B.2   Latência de disco média com uma configuração padrão

As cargas de trabalho A, B, C e D da Figura B 1 são aquelas descritas em "Bancos de dados e cargas de trabalho de consolidação" neste documento (Tabela 1.1). Para obter mais informações sobre essas cargas de trabalho, consulte a Tabela 1.1 nessa seção.

Apêndice B: Referências

Planejando a consolidação com o Microsoft SQL Server 2000

http://www.microsoft.com/technet/prodtechnol/sql/2000/plan/SQL2KCon.mspx

Agrupamento e SAN

Microsoft Windows Clustering: Storage Area Networks

http://www.microsoft.com/windowsserver2003/techinfo/overview/san.mspx

Artigo 304415 da Base de Conhecimento da Microsoft Support for Multiple Clusters Attached to the Same SAN Device

http://support.microsoft.com/?id=304415

Artigo 280297 da Base de Conhecimento da Microsoft How to Configure Mount point volumes on a Clustered Server

http://support.microsoft.com/?id=280297

Artigo 819546 da Base de Conhecimento da Microsoft SQL Server 2000 support for mounted volumes

http://support.microsoft.com/?id=819546

Considerações sobre heap de área de trabalho

Artigo 184802 da Base de Conhecimento da Microsoft PRB: User32.dll or Kernel32.dll Fails to Initialize

http://support.microsoft.com/?id=184802

Estações do Windows

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/window_stations.asp

Suporte para AWE e memória grande

Artigo 816488 da Base de Conhecimento da Microsoft Rate of Page-Zeroing Process Is Unexpectedly Slow

http://support.microsoft.com/?id=816488

Artigo 329914 da Base de Conhecimento da Microsoft AWE-Enabled SQL Server 2000 May Take a Long Time to Start

http://support.microsoft.com/?id=329914

Artigo 283037 da Base de Conhecimento da Microsoft Suporte a grandes memórias está disponível no Windows 2000 e no Windows Server 2003

http://support.microsoft.com/?id=283037

Artigo 274750 da Base de Conhecimento da Microsoft HOW TO: Configure memory for more than 2 GB in SQL Server

http://support.microsoft.com/?id=274750

Apêndice C: Configuração de hardware

Os cenários de teste apresentados neste documento foram conduzidos no seguinte ambiente:

Servidor

Unisys ES7000

  • 32 processadores Intel® Pentium® III Xeon de 700 MHz

  • 64 GB de RAM

  • 8 HBAs PCI Emulex LP9000

Armazenamento

EMC Symmetrix 5.5 (modelo 8530) com 16 GB de cache, noventa e seis unidades de 73 GB de 10 K RPM e 12 conexões de host de fibra. Configurado com RAID 1+0.

Switch de malha

Fiber switch de 64 portas, classe de director McData de 1 Gbs da EMC

Sistema operacional

Microsoft Windows Server 2003, Datacenter Edition

Servidor de banco de dados

Microsoft SQL Server 2000, Enterprise Edition, Compilação 2000.80.194.0, Service Pack 3

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
Mostrar:
© 2014 Microsoft