Gerenciamento de capacidade e alta disponibilidade em um ambiente virtual (SharePoint Server 2010)

 

Tópico modificado em: 2016-11-30

Este artigo fornece informações sobre o gerenciamento da capacidade e a alta disponibilidade de uma hospedagem de ambiente virtual do Microsoft SharePoint Server 2010. Combinamos esses dois conceitos no artigo porque capacidade e dimensionamento são aspectos importantes do desenvolvimento de um plano de virtualização e da arquitetura de um ambiente virtual, e também porque o gerenciamento da capacidade não está isolado da alta disponibilidade em um ambiente virtual. No caso dos hosts de virtualização, a insuficiência de capacidade pode bloquear a alta disponibilidade no nível do farm e do host.

Assim como em outros aspectos de um ambiente virtual, como backup e recuperação, o gerenciamento da capacidade e a alta disponibilidade precisam acomodar duas camadas do ambiente virtual, que são as máquinas virtuais usadas para o SharePoint Server 2010 e os servidores físicos usados para hospedar essas máquinas virtuais. No caso de um ambiente híbrido, também pode ser necessário trabalhar com servidores de farm do Microsoft SharePoint Server.

Neste artigo:

Visão geral da virtualização

O servidor de virtualização, implementado pelo Tecnologia do Windows Server 2008 Hyper-V ou pelo Microsoft Hyper-V Server 2008, é baseado em hardware e também é mencionado como virtualização assistida por hardware, em contrapartida à virtualização assistida por software. O hipervisor do Hyper-V tem um caminho de comunicação para e de interação com os componentes de hardware do servidor mais direto do que as tecnologias de virtualização assistida por software. O resultado final é um desempenho melhor do que uma tecnologia de virtualização assistida por software. Para obter mais informações sobre a arquitetura do Hyper-V, consulte o documento sobre introdução ao Hyper-V do Windows Server 2008 (https://go.microsoft.com/fwlink/?linkid=188006&clcid=0x416) e o documento sobre monitoramento do desempenho do Hyper-V (https://go.microsoft.com/fwlink/?linkid=187746&clcid=0x416).

Embora um servidor físico possa atender aos requisitos do Hyper-V, cada servidor físico é único. Todo fabricante usa sua própria implementação de processadores, tecnologia multinuclear, memória, barramento de dados, discos rígidos e adaptadores de rede. Além disso, o design do hardware e a implementação variam de modelo para modelo, mesmo que os modelos sejam produzidos pelo mesmo fabricante. Isso realça a necessidade de testes rigorosos ao implantar o SharePoint Server 2010 em um ambiente virtual.

Programas de software e aplicativos apresentam as mesmas variações de desempenho de hardware. Alguns programas fazem intensivo da CPU, outros demandam muita memória e outros fazem uso intensivo do disco rígido. O SharePoint Server tem suas próprias necessidades de capacidade, assim como o IIS (Internet Information Server) e o SQL Server 2008. Mais uma vez, testes rigorosos são necessários.

O gerenciamento da capacidade exige que você considere o servidor de virtualização, a solução de armazenamento, a infraestrutura de rede, as tecnologias em execução em um ambiente do SharePoint Server e os recursos habilitados ao implementar a sua solução do SharePoint Server.

Gerenciamento da capacidade

O gerenciamento da capacidade amplia o conceito de planejamento de capacidade para expressar a abordagem cíclica em que a capacidade de uma implantação do SharePoint Server 2010 é continuamente monitorada e otimizada para acomodar as condições e os requisitos em constante transformação. Você pode aplicar essa abordagem a todos os farms do SharePoint Server, incluindo aqueles totalmente virtualizados e os que estejam parcialmente virtualizados. Para obter uma visão geral do gerenciamento de capacidade, consulte Capacity management and sizing for SharePoint Server 2010. Recursos adicionais de gerenciamento de capacidade podem ser encontrados na página sobre gerenciamento da capacidade do SharePoint Server 2010 (https://go.microsoft.com/fwlink/?linkid=194748&clcid=0x416), na Central de Recursos.

Capacidade e dimensionamento do servidor de virtualização

Assim que tiver as recomendações de design e dimensionamento de um farm do SharePoint Server, você poderá projetar a arquitetura física do host de virtualização que é exigida para suporte ao farm virtual. Para obter mais informações sobre arquiteturas virtuais, consulte Planejar arquiteturas virtuais (SharePoint Server 2010).

É recomendável usar os princípios aplicáveis do gerenciamento de capacidade do SharePoint Server 2010 e usá-los como guia para um ambiente virtual. As seguintes atividades ilustram a natureza iterativa do design, dimensionamento e ajuste de uma arquitetura física no planejamento inicial da implantação em um ambiente de produção.

Observação

Se você fizer todo o planejamento e teste, a arquitetura e as configurações de servidor só precisarão ser alteradas se houver um aumento significativo e imprevisto no uso do farm ou então porque novos recursos foram adicionados à sua solução do SharePoint Server.

  • Antes de iniciar a implantação do farm, crie uma arquitetura virtual e física usando o dimensionamento de máquina virtual e servidor de virtualização. No caso de vários hosts de virtualização, essa arquitetura deverá incluir a distribuição de máquinas virtuais.

  • Durante a fase piloto da implantação, colete dados de integridade e desempenho que possam ser usados para estabelecer benchmarks para as máquinas virtuais e os hosts de virtualização do farm.

  • Durante a fase de teste da implantação referente à aceitação do usuário, ajuste as configurações do host de virtualização e da máquina virtual com base nos dados de benchmark. Se necessário, altere a arquitetura física redistribuindo as máquinas virtuais nos hosts de virtualização.

  • Após a implantação, continue a coletar benchmarks de integridade e desempenho e a refinar a máquina virtual e, se aplicável, as configurações da máquina física. Se necessário, ajuste as duas arquiteturas.

É muito importante que você possa analisar os dados de desempenho do host de virtualização e da máquina virtual e que, além disso, possa entender como isso se reflete nas necessidades de capacidade e os efeitos do aplicativo na capacidade. Você também precisa entender os limites de desempenho e capacidade. Devido à inter-relação entre a camada virtual e a camada física, tudo que afetar a capacidade da máquina virtual e o desempenho também terá efeito direto no host ou precisará ser acomodado por meio de alterações na configuração do host de virtualização para manter um desempenho aceitável no farm.

Em alguns casos, pode ser necessário alterar a arquitetura física adicionando mais hosts de virtualização e alterando a distribuição das máquinas virtuais na arquitetura física.

Importante

Em testes de benchmark entre um computador físico e uma máquina virtual, a produtividade da máquina virtual geralmente não coincide com a do computador físico. O desempenho da máquina virtual é, com raras exceções, sempre menor do que o desempenho do computador físico. O grau de diferença de desempenho depende dos recursos do host de virtualização, dos aplicativos em execução e dos benchmarks escolhidos para uso como principais indicadores de desempenho.

É recomendável ler o documento sobre desempenho do Hyper-V, em Perguntas Frequentes sobre o R2 (https://go.microsoft.com/fwlink/?linkid=187745&clcid=0x416), que foi atualizado para refletir as informações de capacidade e desempenho do Windows Server 2008 R2 e Windows Server 2008 com Service Pack 2 (SP2). Essa seção de Perguntas Frequentes contém respostas para perguntas comuns referentes ao Hyper-V, fornece diretrizes e inclui links para artigos detalhados, que você pode usar para desenvolver benchmarks para host de virtualização, máquinas virtuais e rede do Windows.

Também é recomendável ler as seguintes publicações sobre contadores de desempenho do Hyper-V:

Criando e refinando as arquiteturas

Uma arquitetura completa consiste em hosts de virtualização, máquinas virtuais e máquinas físicas que compõem o ambiente do SharePoint Server a ser implantado. Para obter mais informações sobre arquiteturas de virtualização, consulte Planejar arquiteturas virtuais (SharePoint Server 2010).

O desenvolvimento e a implementação de uma arquitetura virtual consiste nestas etapas:

  1. Criar a arquitetura virtual e física. Crie uma arquitetura para apoiar as metas do seu farm do SharePoint Server 2010.

  2. Analisar as arquiteturas. Identifique e obtenha todas as informações que estiverem faltando ou que irão melhorar o design do ambiente a ser implantado.

  3. Refinar as arquiteturas. Use as informações da etapa 2 para refinar a arquitetura.

  4. Continue refinando a arquitetura e as configurações de servidor à medida que você avança pelos vários estágios de implantação. Para obter mais informações sobre os estágios de implantação, consulte os modelos Implantação de Produtos do SharePoint 2010 e Produtos do SharePoint 2010: Processo de Virtualização, disponíveis no artigo Diagramas técnicos (SharePoint Server 2010).

Criar a arquitetura

Crie um modelo de arquitetura que você possa usar como ferramenta de avaliação e ajuste das configurações de máquina virtual e host de virtualização. Use os critérios a seguir como guia para o desenvolvimento do modelo:

  • Identifique o número de máquinas virtuais necessárias e a função de cada uma delas no farm do SharePoint Server.

  • Especifique os requisitos de cada máquina virtual (espaço em disco, memória e número de processadores). Isso se baseia nos requisitos de capacidade do SharePoint Server.

  • Especifique os requisitos do host de virtualização (espaço em disco, memória e número de processadores). Isso se baseia nos requisitos da máquina virtual.

  • Identifique a distribuição das máquinas virtuais nos hosts de virtualização. Isso se baseia nos requisitos de alta disponibilidade e é imposto pela quantidade e capacidade de hosts de virtualização.

  • Identifique os requisitos gerais de rede e armazenamento.

  • Leve em consideração a expansão nos hosts de virtualização e nas máquinas virtuais (aumento ou expansão).

Depois de criar um modelo de arquitetura, você precisará analisar as duas arquiteturas para validar o design e também as configurações de host de virtualização e máquina virtual.

Analisar as arquiteturas

O objetivo fundamental da análise de arquitetura é determinar se ela é compatível com êxito a solução do SharePoint Server 2010 a ser implantada. Entretanto, é aceitável pressupor que o design e as configurações de servidor serão alterados à medida que você avançar no processo de implantação.

A ilustração a seguir mostra um exemplo de arquitetura virtual para um farm composto de servidores Web front-end, servidores de aplicativos e servidores de banco de dados. Essa arquitetura representa os farms de pequeno a médio porte descritos no documento sobre exemplo de arquiteturas virtuais para farms de pequeno a médio porte. Podemos usá-la para mostrar os principais elementos a serem considerados na análise dos requisitos de capacidade e disponibilidade de um farm virtual.

Importante

O dimensionamento do servidor de virtualização e da máquina virtual na seguinte ilustração não são uma determinação.

Figura 1. Arquitetura preliminar

Topologia de farm virtual do SharePoint Server 2010

Use os critérios fornecidos para a criação de uma arquitetura virtual para analisar a arquitetura de exemplo mostrada na ilustração anterior. A arquitetura da ilustração pressupõe que todos os servidores Web front-end e os servidores de aplicativos sejam máquinas virtuais. Não foi determinado se os servidores de banco de dados do farm são máquinas físicas ou virtuais.

Análise do host de virtualização

As tabelas a seguir (HOST-1 e HOST-2) fornecem uma análise de cada host de virtualização e usam memória, processadores e escalabilidade como critérios. A análise do host é seguida por uma análise do design.

HOST-1

Critérios Análise

Memória

Após a fatoração em 2 GB de RAM para o sistema operacional do host e o uso dos requisitos de RAM projetados, há uma estimativa de 2 GB de RAM disponíveis para uso futuro.

Processadores

A lógica para mapeamento de processador virtual é 8:10 (1:1,25), o que significa que a CPU é ligeiramente superinscrita. Isso pode não ser um problema em um ambiente de teste.

Importante

A superinscrição da CPU em um servidor de virtualização reduz o desempenho global. A extensão desse efeito é determinada pela carga colocada nas máquinas virtuais. Como prática recomendada, se possível, não superinscreva a CPU do servidor de virtualização.

Escalabilidade

Isso não é uma opção porque não há memória suficiente. Além disso, o grau de superinscrição da CPU (mesmo adicionando uma máquina virtual aos dois processadores) pode provocar um efeito significativo no desempenho.

HOST-2

Critérios Análise

Memória

Após a fatoração em 2 GB de RAM para o sistema operacional do host e o uso dos requisitos de RAM projetados, há uma estimativa de 6 GB de RAM disponíveis para uso futuro.

Processadores

A lógica para o mapeamento de processador virtual é 8:8 (1:1), o que atende à diretriz de prática recomendada.

Escalabilidade

Há memória suficiente para aumentar a alocação de memória nas máquinas virtuais. Há capacidade suficiente para adicionar uma nova máquina virtual aos dois processadores de 4 GB de RAM. Isso significa que a CPU do host de virtualização pode ficar ligeiramente superinscrita (8:10), mas, assim como no HOST-1, isso pode não ser um problema em um ambiente de teste.

Análise de projetos

A arquitetura de exemplo geralmente mostra um grau de alta disponibilidade para os servidores do farm. Por exemplo, há três servidores Web front-end distribuídos no HOST-1 e no HOST-2, e os servidores de banco de dados (clusterizados ou espelhados) também residem em hosts de virtualização separados ou em servidores físicos separados. A alta disponibilidade no nível do host de virtualização não faz parte da arquitetura e não há informações pertinentes. As informações a seguir são necessárias para que o design possa ser revisado:

  • Tamanho do banco de dados

    O tamanho do banco de dados de conteúdo determina como você configura e distribui todos os servidores do farm.

  • Subsistema de armazenamento

    Por exemplo, na arquitetura de exemplo, nenhuma informação é fornecida sobre o número de discos necessários em cada máquina virtual nem há qualquer indicação de distribuição e capacidade de disco. Essas informações são muito importantes para determinar e configurar o sistema de armazenamento. A arquitetura de exemplo usa o armazenamento local. É preciso determinar se isso é adequado ao seu ambiente ou se você prefere usar uma configuração de disco de passagem para um LUN em uma SAN.

  • Requisitos de rede

    O número de adaptadores de rede e a produtividade mínima precisam ser identificados.

  • Configurações de disco rígido virtual

    Também é preciso determinar qual das configurações de disco rígido do Hyper-V você deseja usar (por exemplo, tamanho fixo, passagem). Para obter mais informações, consulte o documento sobre planejamento de discos e armazenamento (https://go.microsoft.com/fwlink/?linkid=188007&clcid=0x416) e o documento sobre desempenho do disco rígido virtual: Windows Server 2008/Windows Server 2008 R2/Windows 7 (https://go.microsoft.com/fwlink/?linkid=186519&clcid=0x416).

Após a conclusão da revisão do design, a próxima etapa é refinar a arquitetura.

Refinar a arquitetura

O escopo de refinamento da arquitetura depende da arquitetura inicial, dos resultados da análise e do plano de implementação. Usando o exemplo fornecido, há cenários onde você pode decidir não fazer qualquer alteração. Por exemplo:

  • A arquitetura preliminar é adequada ao teste inicial, verificação de conceito e implantação piloto limitada.

  • Os hosts de virtualização são somente para teste e serão substituídos por hosts com capacidade maior durante a fase de teste de aceitação do usuário.

  • O farm virtual é somente para teste e será desligado após a conclusão do teste. Em alguns casos, o ambiente pode ser preservado e utilizado posteriormente para testar atualizações de software.

A ilustração a seguir mostra uma arquitetura revisada, que é mais adequada a um farm de produção.

Figura 2. Arquitetura revisada

Revisando uma arquitetura virtual

Na arquitetura revisada, a principal hipótese é a de que você queira manter oito servidores de virtualização de mercadoria centrais. As alterações na ilustração precedente reflete essa hipótese e inclui estas considerações:

  • O tamanho estimado do banco de dados de conteúdo é de 1 TB (terabyte).

  • O objetivo é fornecer alta disponibilidade para todos os servidores do farm e maximizar o desempenho na infraestrutura.

  • Os servidores de banco de dados são servidores físicos que podem ser clusterizados ou espelhados para apoiar a alta disponibilidade. Cada servidor tem 8 núcleos, 16 GB de RAM e usa unidades para reduzir a latência.

Análise do host de virtualização

As tabelas a seguir (HOST-1 e HOST-2 revisadas) fornecem uma análise de cada host de virtualização e usam memória, processadores e escalabilidade como critérios. A análise do host é seguida por uma análise do design.

HOST-1 revisada

Critérios Análise

Memória

Após a fatoração em 2 GB de RAM para o sistema operacional do host e o uso dos requisitos de RAM projetados, há uma estimativa de 2 GB de RAM disponíveis para uso futuro.

Processadores

A lógica para o mapeamento de processador virtual é 8:10 (1:1,25), o que implica uma ligeira superinscrição.

Escalabilidade

Há uma margem de memória disponível para aumentar a alocação de memória para as máquinas virtuais. Com base na quantidade de memória e na razão do processador, não há capacidade de host suficiente para adicionar mais uma máquina virtual.

HOST-2 revisada

Critérios Análise

Memória

Após a fatoração em 2 GB de RAM para o sistema operacional do host e o uso dos requisitos de RAM projetados, há uma estimativa de 4 GB de RAM disponíveis para uso futuro.

Processadores

A lógica para o mapeamento de processador virtual é 8:12 (1:1,50), o que implica uma superinscrição de 50%.

Escalabilidade

Há uma margem de memória disponível para aumentar a alocação de memória para as máquinas virtuais. Com base na quantidade de memória e na razão do processador, não há capacidade de host suficiente para adicionar mais uma máquina virtual.

Análise de projetos

  • Cada máquina virtual usa uma configuração de três unidades, dimensionadas de acordo com a diretriz de práticas recomendadas do SharePoint Server. Essas unidades geralmente são configuradas da seguinte forma:

    • Unidade C (50 GB) para instalação do Windows

    • Unidade D (50 GB) para arquivos do SharePoint Server 2010

    • Unidade E (300 GB) conteúdo da Web e arquivos de log

  • Cada servidor Web front-end é configurado com quatro processadores virtuais (4xVP) e 8 GB de RAM. Esta é a configuração mínima recomendada para um ambiente de produção.

  • O número de servidores Web front-end é aumentado para quatro para suportar a clusterização e a alta disponibilidade efetivas. Essa configuração de quatro servidores é particularmente adequada à instalação de atualizações de software, pois sempre haverá dois servidores disponíveis durante a instalação das atualizações.

  • Os dois servidores de aplicativos (App-1, App-2) fornecem alta disponibilidade. O App-1 hospeda a Administração Central, o componente Rastreamento de pesquisa e o índice passivo do componente Consulta de pesquisa. O número de processadores e a quantidade de memória são baseados no tamanho estimado do banco de dados de conteúdo.

    App-2 é um servidor dedicado de consulta de pesquisa. Ele também contém uma cópia da Administração Central. O número de processadores e a quantidade de memória são baseados no tamanho estimado do banco de dados de conteúdo.

  • Para alta disponibilidade, a Administração Central também é instalada em um servidor Web front-end em outro host.

  • Os servidores de banco de dados são servidores físicos que são clusterizados ou espelhados para garantir a alta disponibilidade. Essa mudança para servidores físicos traz os benefícios de aumentar a capacidade do host de virtualização para os servidores de farm virtuais e melhorar o desempenho global do banco de dados.

    Observação

    Como indicado anteriormente neste artigo, a decisão de virtualizar ou não os servidores de banco de dados é complexa e exige muito planejamento e teste.

  • Do ponto de vista da rede, os dois hosts de virtualização são configurados com dois adaptadores de rede físicos e separados, de 1 gigabit. Essa é uma prática recomendada para garantir que o tráfego de dados no host de virtualização e na máquina virtual fique separado, visando melhorar o desempenho e fornecer alguma redundância de adaptador.

  • Cada host de virtualização utiliza uma VLAN (LAN virtual) que fornece os seguintes benefícios: segregação de rede, segurança e desempenho melhorados.

A arquitetura virtual e física revisada é consideravelmente melhorada e pode ser implantada em um ambiente de produção. Entretanto, é importante observar que, quando configurados, os recursos disponíveis do host de virtualização não aceitam o dimensionamento do farm. Além disso, não são compatíveis com a migração de um servidor de farm de um host para outro, caso surja essa necessidade.

Na realidade, se você quiser implantar o farm de exemplo na produção, é recomendável considerar estas atualizações:

  • Aumente a capacidade do host de virtualização usando um computador de 16 núcleos com 48 ou 64 gigabytes de RAM.

  • Adicione um ou mais hosts de virtualização.

Para obter o nível ideal de alta disponibilidade, considere as opções adicionais da seção a seguir.

Opções adicionais para melhoria da arquitetura

A seção anterior forneceu opções para revisão do modelo. Há, é claro, outras opções para obter melhor desempenho e alta disponibilidade. A expansão do ambiente de host de virtualização ou o aumento dos hosts de virtualização são boas alternativas, embora os custos sejam sempre um problema. A estratégia de virtualização da sua organização ajudará a definir a melhor abordagem.

Dica

Em termos de custos, comprar um servidor que tenha mais capacidade do que a necessária em curto prazo é menos dispendioso do que atualizar um servidor para ganhar mais capacidade. Isso é especialmente verdadeiro no caso de atualizações de memória, o que geralmente implica jogar fora os módulos de memória existentes e comprar um conjunto completo de memória nova para atualizá-la.

Ganhos de desempenho podem ser obtidos com estas opções:

  • Implante ou compre servidores com processadores SLAT (Second-Level Address Translation) habilitados. Em processadores Intel, esse recurso é mencionado como Nested Page Tables (tabelas de páginas aninhadas) e está disponível nos processadores da série Nehalem 55xx. Para AMD, o recurso é mencionado como EPT (Enhanced Page Tables, tabelas de páginas aprimoradas).

  • Implante ou compre servidores que forneçam Estacionamento do Núcleo de CPU, um recurso que permite que o Hyper-V em execução use o menor número de núcleos de processador para atender à demanda de carga de trabalho.

  • Investigue o descarregamento de chimney de TCP, as VMQ (Filas da Máquina Virtual) e os quadros jumbo. Esses recursos melhoram o desempenho da rede e reduzem a utilização da CPU, aumentando assim a capacidade global do sistema.

  • Investigue o suporte a quadros jumbo para acelerar o desempenho de rede ao transferir grandes volumes de dados. Entretanto, é preciso testar isso totalmente, pois quadros jumbo não funcionam em todos os ambientes.

  • Investigue a junção do adaptador. Esse recurso pode melhorar o desempenho de rede e fornecer recurso de failover aos adaptadores de rede físicos.

    Importante

    A junção de adaptador é uma solução terceirizada e com suporte apenas pelo fornecedor. Para obter mais informações, consulte o documento sobre a política de suporte da Microsoft para NIC Teaming com Hyper-V (https://go.microsoft.com/fwlink/?linkid=194749&clcid=0x416).

Para garantir a alta disponibilidade de um ambiente virtual, considere a implementação de clusterização de failover do Windows Server 2008 R2 e a migração dinâmica do Hyper-V, da seguinte maneira:

  • O escopo da clusterização de failover pode incluir hosts de virtualização e máquinas virtuais em cada host. Se um host de virtualização falhar inesperadamente, as máquinas virtuais farão failover automaticamente em outro host de virtualização.

  • A migração dinâmica é uma solução de tempo de inatividade planejado. Você pode migrar as máquinas virtuais em execução para outro servidor (sem tempo de inatividade), desligar o servidor físico e executar a manutenção. Quando concluir a manutenção no servidor, use a migração dinâmica para mover as máquinas virtuais de volta ao servidor físico original.

Para obter mais informações, consulte o documento sobre Hyper-V: como usar o Hyper-V e a clusterização de failover (https://go.microsoft.com/fwlink/?linkid=187967&clcid=0x416) e o documento sobre Hyper-V: como usar a migração dinâmica com volumes compartilhados de cluster no Windows Server 2008 R2 (https://go.microsoft.com/fwlink/?linkid=188009&clcid=0x416).