Guia de considerações de design da malha de virtualização

Artigo
10/26/2015

A quem este guia se destina? Profissionais de tecnologia da informação (TI) em médias e grandes empresas que são responsáveis pela criação de uma malha de virtualização que oferece suporte a muitas máquinas virtuais. Essas pessoas são denominadas administradores da malha ao longo deste documento. As pessoas que administram máquinas virtuais hospedadas na malha são chamadas de administradores da máquina virtual, mas elas não são o público-alvo deste documento. Na sua organização, você pode ser responsável sobre ambas as funções.

Como este guia pode ajudar você? Você pode usar este para compreender como projetar uma malha de virtualização capaz de hospedar muitas máquinas virtuais na organização. Neste documento, a coleção de servidores, hipervisores e o hardware de rede e armazenamento que são usados para hospedar as máquinas virtuais em uma organização é conhecida como uma malha de virtualização. O gráfico a seguir mostra uma malha de virtualização de exemplo.

Malha de virtualização

Figure 1:Exemplo de malha de virtualização

Observação: Cada diagrama neste documento existe em uma guia separada do documento Diagramas de consideração de design de malha de virtualização que pode ser baixado clicando no nome da figura em cada legenda da tabela.

Embora todas as malhas de virtualização contenham servidores para armazenamento e hospedagem de máquinas virtuais, bem como das redes que as conectam, o design de malha de virtualização de cada organização provavelmente será diferente de exemplo ilustrado na Figura 1, devido a requisitos diferentes.

Este guia fornece detalhes sobre uma série de etapas e tarefas que você pode seguir para ajudá-lo a criar uma malha de virtualização que atenda às necessidades da sua organização. Durante tais etapas e tarefas, o guia apresenta as tecnologias relevantes e opções de recursos disponíveis para você atender os requisitos de nível de funcionalidade e qualidade de serviço (como disponibilidade, escalabilidade, desempenho, capacidade de gerenciamento e segurança).

Embora este documento possa ajudá-lo a projetar uma malha de virtualização gerenciável, ele não aborda considerações de design e opções para gerenciar e operar a malha de virtualização com um produto como o Microsoft System Center 2012 ou o System Center 2012 R2. Para obter mais informações, consulte ISystem Center 2012 na biblioteca do TechNet.

Este guia ajuda você a projetar uma malha de virtualização usando o Windows Server 2012 R2 e o Windows Server 2012, bem como um hardware independente de fornecedor. Alguns recursos discutidos no documento são exclusivos do Windows Server 2012 R2 e são mencionados em todo o documento.

Suposições: Você tem alguma experiência em implantação do Hyper-V, máquinas virtuais, redes virtuais, serviços de arquivos do Windows Server e clustering de failover e certa experiência na implantação de servidores físicos, armazenamento e equipamentos de rede.

Recursos adicionais

As informações nos documentos a seguir podem ser úteis para projetar uma malha de virtualização:

Ambos esses documentos fornecem conceitos fundamentais observado em vários designs de malha de virtualização e que podem servir como base de um design deste.

Feedback: Para fazer comentários sobre este documento, envie um email para virtua@microsoft.com.

Visão geral de considerações de design

O restante deste documento fornece um conjunto de etapas e tarefas que você pode seguir para criar uma malha de virtualização que possa atenda melhor às suas necessidades. As etapas são apresentadas em uma sequência ordenada. As considerações de design que você aprenderá nas etapas seguintes podem exigir mudar as decisões que você tomou nas etapas anteriores devido a conflitos de alteração. Contudo, tentamos de todas as maneiras alertar sobre possíveis conflitos de design em todo o documento.

Você chegará no design que melhor atenda às suas necessidades somente após percorrer as etapas quantas vezes forem necessárias para incorporar todas as considerações deste documento.

Etapa 1: Determinar os requisitos de recursos de máquina virtual

Etapa 2: Planejar a configuração da máquina virtual

Etapa 3: Planejar grupos de host de virtualização de servidores

Etapa 4: Planejar hosts de virtualização de servidores

Etapa 5: Planejar conceitos de arquitetura da malha de virtualização

Etapa 6: Planejar as características de capacidade inicial

Etapa 1: Determinar os requisitos de recursos de máquina virtual

A primeira etapa na criação de uma malha de virtualização é determinar os requisitos de recursos das máquinas virtuais hospedadas na malha. A malha deve possuir o hardware físico necessário para atender a esses requisitos. Os requisitos de recursos de máquina virtual são determinados pelos sistemas operacionais e aplicativos executados nas máquinas virtuais. Pelo restante deste documento, a combinação de sistema operacional e aplicativos que são executados em uma máquina virtual será referida como uma carga de trabalho. As tarefas nesta etapa ajudam a definir os requisitos de recursos para suas cargas de trabalho.

Dica: Em vez de avaliar os requisitos de recursos das suas cargas de trabalho existentes e, posteriormente, projetar uma malha de virtualização capaz de dar suporte a cada uma delas, você pode decidir, em vez disso, projetar uma malha de virtualização que possa atender às necessidades de cargas de trabalho mais comuns. Depois disso, você poderá tratar individualmente as cargas de trabalho que possuem necessidades específicas.

Exemplos de tais malhas de virtualização são aquelas oferecidas por provedores de nuvem pública, como o Microsoft Azure (Azure). Para obter mais informações, consulte Tamanhos de máquina virtual e de serviço de nuvem para o Azure.

Provedores de nuvem pública geralmente oferecem uma seleção de configurações de máquina virtual que atendem às necessidades da maioria das cargas de trabalho. Se você optar por essa abordagem, poderá pular diretamente para Etapa 2: Planejar a configuração da máquina virtual deste documento. Benefícios adicionais de usar essa abordagem são:

Ao decidir migrar algumas máquinas virtuais locais para um provedor de nuvem pública, se os tipos de configuração de máquina virtual local forem semelhantes aos do provedor público, migrar as máquinas virtuais será mais fácil do que se os tipos de configuração fossem diferentes.
Isso pode permitir prever mais facilmente os requisitos de capacidade e habilitar um recurso de provisionamento de autoatendimento para sua malha de virtualização. Isso significa que os administradores de máquina virtual dentro da organização podem automaticamente autoprovisionar novas máquinas virtuais sem o envolvimento de administradores da malha.

Tarefa 1: Determinar os requisitos de recursos de carga de trabalho

Cada carga de trabalho tem requisitos para os recursos a seguir. A primeira coisa que você deve fazer é responder às seguintes perguntas listadas para cada uma das suas cargas de trabalho.

Processador: Qual é a velocidade ou arquitetura do processador (Intel ou AMD) ou qual o número de processadores necessário?
Rede: Em gigabits por segundo (Gbps), qual largura de banda é necessária para o tráfego de entrada e de saída? O que é a quantidade máxima de latência de rede que a carga de trabalho pode tolerar para funcionar corretamente?
Armazenamento: Quantos gigabytes (GB) de armazenamento os aplicativos e arquivos do sistema operacional da carga de trabalho exigem? Quantos GBs de armazenamento a carga de trabalho exige para seus dados? Quantas operações de entrada/saída por segundo (IOPS) a carga de trabalho exige para seu armazenamento?
Memória: Em gigabytes (GB), qual a quantidade de memória que a carga de trabalho exige? A carga de trabalho reconhece acesso não uniforme à memória (NUMA)?

Além de entender os requisitos de recursos acima, também é importante determinar:

Se os requisitos de recursos são mínimos ou recomendados.
Quais são os requisitos de pico e média para cada um dos requisitos de hardware em uma base por hora, diária, semanal, mensal ou anual.
O número de minutos de inatividade por mês aceitáveis para a carga de trabalho e os dados da carga de trabalho. Para determinar isso, considere o seguinte:
- A carga de trabalho é executada em uma única máquina virtual ou em uma coleção de máquinas virtuais que atua como uma só, como uma coleção de servidores com balanceamento de carga de rede, todos executando a mesma carga de trabalho? Se você estiver usando um conjunto de servidores, o tempo de inatividade expresso deve esclarecer sobre se ele se aplica a cada servidor na coleção, a todos os servidores na coleção ou ao nível da coleção.
- Horas de trabalho e de folga. Por exemplo, se ninguém usará a carga de trabalho entre as 21h e 6h, porém é crucial que ela esteja disponível tanto quanto possível entre as 6h e as 21h, com um valor aceitável de tempo de inatividade por mês de apenas dez minutos, esse requisito deve ser especificado.
O volume de perda de dados aceitável em caso de uma falha inesperada da infraestrutura virtual. Isso é expresso em minutos, pois as estratégias de replicação de infraestrutura virtual são normalmente baseados em tempo. Embora nenhuma perda de dados se usualmente expressa como um requisito, considere que alcançá-lo normalmente representa um alto preço, também podendo trazer um desempenho inferior.
Se os arquivos de carga de trabalho e/ou seus dados devem ser criptografados em disco e se seus dados devem ser criptografados entre as máquinas virtuais e seus usuários finais.

Você tem as seguintes opções disponíveis para determinar os requisitos de recursos anteriores.

Opção	Vantagens	Desvantagens
Avalia manualmente e registra em log a utilização de recursos	É capaz de gerar relatórios sobre tudo o que você escolher	Pode exigir esforço manual significativo
Use o Microsoft Assessment and Planning Toolkit para avaliar e registrar automaticamente a utilização de recursos	Cria uma variedade de relatórios de utilização de recursos Não requer um agente para ser instalado na carga de trabalho	Os relatórios podem ou não podem fornecer todos os dados necessários

Observação: Se você preferir determinar seus requisitos de recursos manualmente, poderá baixar as Planilhas do guia de considerações de design de malha de virtualização e inserir as informações na planilha de requisitos de recursos de carga de trabalho. Este guia faz referência a planilhas específicas nesse documento.

Tarefa 2: Definir caracterizações da carga de trabalho

Você pode definir qualquer número de caracterizações da carga de trabalho em seu ambiente. Os exemplos a seguir foram selecionados porque cada um deles requer uma configuração diferente de componentes de malha de virtualização, que será discutida mais em etapas posteriores.

Sem monitoração de estado: Não escreva nenhuma informação exclusiva no disco rígido local depois que for inicialmente provisionado e receber nomes de computador e endereços de rede exclusivos. Eles podem, no entanto, gravar informações exclusivas para armazenamento, como um banco de dados distinto. Cargas de trabalho sem monitoração de estado são ideais para a execução em uma malha de virtualização, pois uma imagem "mestre" pode ser criada para a máquina virtual. Essa imagem pode ser facilmente copiada e inicializada na malha de virtualização para adicionar escala à carga de trabalho ou substituir rapidamente uma máquina virtual que se tornou indisponível em caso de falha do host de virtualização. Um exemplo de uma carga de trabalho sem monitoração de estado é um servidor web executando um aplicativo web de front-end.
Com monitoração de estado: Escreva informações exclusivas no disco rígido local depois que for inicialmente provisionado e receber nomes de computador e endereços de rede exclusivos. Eles também podem gravar informações exclusivas para armazenamento, como um banco de dados distinto. Cargas de trabalho com monitoração de estado geralmente exigem estratégias de provisionamento e dimensionando mais complexas que as cargas de trabalho sem monitoração de estado. Estratégias de alta disponibilidade para cargas de trabalho com monitoração de estado podem exigir estado compartilhado com outras máquinas virtuais. Um exemplo de uma carga de trabalho com monitoração de estado é o mecanismo de banco de dados do SQL Server.
Monitoração de estado compartilhada: Cargas de trabalho com monitoração de estado que exigem certo estado compartilhado com outras máquinas virtuais. Essas cargas de trabalho geralmente usam clustering de failover no Windows Server para obter alta disponibilidade, o que requer acesso ao armazenamento compartilhado. Um exemplo de uma carga de trabalho com monitoração de estado compartilhado é o Microsoft System Center – Virtual Machine Manager.
Outros: Caracteriza cargas de trabalho que podem não funcionar ou são executadas com problemas em uma malha de virtualização. Atributos de tais cargas de trabalho são exigir:
- Acesso a periféricos físicos. Um exemplo de tal aplicativo é uma carga de trabalho de telefonia que se comunica com um adaptador de rede de telefonia em um host físico.
- Requisitos de recursos muito maiores do que a maioria das outras cargas de trabalho. Um exemplo é um aplicativo em tempo real que exige uma latência inferior a um milissegundo entre as camadas do aplicativo.
Esses aplicativos podem ou não ser executados em sua malha de virtualização ou podem requerer hardware ou configuração muito específicos que não são compartilhados pela maioria das outras cargas de trabalho.

Observação: Você pode definir suas caracterizações de carga de trabalho na planilha Configurações e selecionar a caracterização adequada para cada carga de trabalho na planilha Requisito de recursos de carga de trabalho.

Etapa 2: Planejar a configuração da máquina virtual

Nesta etapa, você definirá os tipos de máquinas virtuais que precisará atender aos requisitos de recursos e caracterizações das cargas de trabalho definidos na etapa 1.

Tarefa 1: Definir configuração de computação

Nesta tarefa, você poderá determinar a quantidade de memória e processadores exigidos por cada máquina virtual.

Tarefa 1a: Definir o tipo de geração de máquina virtual

O Windows Server 2012 R2 apresentou máquinas virtuais de 2 geração. Máquinas virtuais de 2ª geração oferecem suporte a recursos de virtualização e hardware que não são suportados em máquinas virtuais de 1ª geração. É importante tomar a decisão certa para suas necessidades, porque depois que uma máquina virtual tiver sido criada, seu tipo não poderá ser alterado.

Uma máquina virtual de 2ª geração oferece as seguintes novas funcionalidades:

Inicialização PXE usando um adaptador de rede padrão
Inicializar por meio de um disco rígido virtual de SCSI
Inicializar por meio de um DVD virtual de SCSI
Inicialização segura (habilitada por padrão)
Suporte a firmware UEFI

Máquinas virtuais de 2ª geração oferecem suporte para os seguintes sistemas operacionais convidados:

Windows Server 2012 R2
Windows Server 2012
Versões de 64 bits do Windows 8.1
Versões de 64 bits do Windows 8
Versões específicas do Linux. Para ver uma lista de distribuição e versões que suportam máquina virtuais da 2ª geração, consulte Máquinas virtuais do Linux no Hyper-V.

A tabela a seguir lista as vantagens e desvantagens de máquina virtuais da 1ª e 2ª geração.

Opção	Vantagens	Desvantagens
1ª geração	Oferece suporte a todos os sistemas operacionais Hyper-V convidado Fornece compatibilidade com máquinas virtuais do Azure Oferece suporte a versões anteriores do Hyper-V	Sem acesso a novas funcionalidades de máquina virtual
2ª geração	Oferece suporte a novas funcionalidades Fornece ligeira melhoria nos tempos de instalação e inicialização de convidado de máquina virtual Usa dispositivos SCSI ou um adaptador de rede padrão para inicializar uma máquina virtual Impede firmware, sistemas operacionais ou drivers UEFI não autorizados de serem executados quando a inicialização segura está habilitada	Suporte limitado a sistemas operacionais convidados Não é compatível com máquinas virtuais do Azure Não há suporte para o RemoteFX Não há suporte para disquete virtual

Importante: Máquinas virtuais do Linux de 2ª geração não oferecem suporte à inicialização segura. Ao criar uma máquina virtual e se você pretender instalar o Linux, desative a inicialização segura nas configurações de máquina virtual.

Informações adicionais:

Visão geral de máquina virtual de 2ª geração

Tarefa 1b: Definir memória

Você deve planejar o tamanho da memória de sua máquina virtual como faria normalmente para aplicativos de servidor em um computador físico. Ele deve trabalhar razoavelmente com a carga esperada em horários comuns e em horários de pico. Memória insuficiente pode aumentar significativamente os tempos de resposta e utilização de CPU ou de E/S.

Memória estática ou dinâmica

Memória estática é a quantidade de memória atribuída à máquina virtual. Ela sempre é alocada quando a máquina virtual é iniciada e não é alterada quando a máquina virtual está em execução. Toda a memória é atribuído à máquina virtual durante a inicialização e a memória que não está sendo usada pela máquina virtual não está disponível para outras máquinas virtuais. Se não houver memória suficiente disponível no host a ser alocada para a máquina virtual quando ele é iniciado, a máquina virtual não será iniciada.

Memória estática é boa para cargas de trabalho que fazem uso intensivo de memória e para aquelas que têm seus próprios sistemas de gerenciamento de memória, como o SQL Server. Esses tipos de cargas de trabalho terão melhor desempenho com memória estática.

Observação: Não há nenhuma configuração para habilitar a memória estática. A memória estática é habilitada quando a configuração de memória dinâmica não está habilitada.

Memória dinâmica permite usar melhor a memória física em um sistema, balanceando a memória física total entre várias máquinas virtuais, alocando mais memória para máquinas virtuais que estão ocupadas e removendo memória de máquinas virtuais menos usadas. Isso pode levar a maior proporção de consolidação, especialmente em ambientes dinâmicos, como nos servidores Web ou de Virtual Desktop Infrastructure (VDI).

Ao usar a memória estática, se uma máquina virtual receber 10 GB de memória e estiver usando apenas 3 GB, os 7 GB restantes de memória não estarão disponível para uso por outras máquinas virtuais. Quando a memória dinâmica é habilitada em uma máquina virtual, esta usa somente a quantidade de memória necessária, mas não abaixo do RAM mínimo configurada. Isso libera mais memória para outras máquinas virtuais.

A tabela a seguir lista as vantagens e desvantagens de memória estática e dinâmica.

Opção	Vantagens	Desvantagens
Memória estática	Fornece às máquinas virtuais uma memória configurada disponível a todos momento Proporciona um melhor desempenho Pode ser usada com NUMA virtual	Não é possível alocar a memória não está sendo usada por uma máquina virtual para outra. Máquinas virtuais não será iniciadas se não houver memória suficiente disponível.
Memória Dinâmica	Proporciona uma densidade maior de máquina virtual ao executar cargas de trabalho ociosas ou baixas Permite a alocação de memória que não está sendo usada, para que ela possa ser usada por outras máquinas virtuais	Você pode subscrever a memória configurada. Uma sobrecarga adicional é necessária para gerenciar as alocações de memória. Não é compatível com NUMA virtual. Não é compatível com cargas de trabalho que implementam seus próprios gerenciadores de memória.

A seguir estão as definições de configuração de memória:

Memória RAM de inicialização: Especifica a quantidade de memória necessária para iniciar a máquina virtual. O valor deve ser alto o suficiente para permitir que o sistema operacional convidado inicie, mas deve ser o mais baixo possível para permitir a utilização de memória ideal e potencialmente mais altas taxas de consolidação.
Memória RAM mínima: Especifica a quantidade mínima de memória que deve ser alocada para a máquina virtual depois que a máquina virtual tiver sido iniciada. O valor pode ser definido para apenas 32 MB até um valor máximo igual ao valor da memória RAM de inicialização. Essa configuração só estará disponível se a memória dinâmica estiver habilitada.
Memória RAM máxima: Especifica a quantidade máxima de memória que esta máquina virtual tem permissão para usar. O valor pode ser definido tão baixo quanto o valor de memória RAM de inicialização e até 1 TB. No entanto, uma máquina virtual pode usar apenas o máximo de memória como o valor máximo suportado pelo sistema operacional convidado. Por exemplo, se você especificar 64 GB para uma máquina virtual que executa um sistema operacional convidado que suporta um máximo de 32 GB, a máquina virtual não poderá usar mais de 32 GB. Essa configuração só estará disponível se a memória dinâmica estiver habilitada.
Peso da memória: Fornece ao Hyper-V uma maneira de determinar como distribuir a memória entre máquinas virtuais se não houver memória física suficiente disponível no host para fornecer a quantidade solicitada de memória de cada máquina virtual. Máquinas virtuais com um peso mais alto de memória têm precedência sobre as máquinas virtuais com pesos de memória inferiores.

Observações:

A memória dinâmica e os recursos NUMA virtual não podem ser usados ao mesmo tempo. Uma máquina virtual com memória dinâmica habilitada efetivamente possui somente um nó NUMA virtual e nenhuma topologia NUMA é apresentada à máquina virtual, independentemente das configurações de NUMA virtuais.
Ao instalar ou atualizar o sistema operacional de uma máquina virtual, a quantidade de memória que está disponível para a máquina virtual durante a instalação e o processo de atualização é o valor especificado como RAM de inicialização. Mesmo se a memória dinâmica tiver sido configurada para a máquina virtual, esta usará somente a quantidade de memória que está configurada na configuração de RAM de inicialização. Certifique-se de que o valor da RAM de inicialização atenda aos requisitos mínimos de memória do sistema operacional durante os procedimentos de instalação ou atualização.
O sistema operacional convidado executado na máquina virtual deve oferecer suporte à memória dinâmica.
Aplicativos de banco de dados complexos como SQL Server ou Exchange Server implementam seus próprios gerenciadores de memória. Consulte a documentação da carga de trabalho para determinar se a carga de trabalho é compatível com a memória dinâmica.

Informações adicionais:

Visão geral de memória dinâmica

Tarefa 1c: Definir o processador

As seguintes configurações deverão ser determinadas para a configuração de máquinas virtuais:

Determine o número de processadores necessários para cada máquina virtual. Isso geralmente será igual ao número de processadores necessários para a carga de trabalho. O Hyper-V oferece suporte a um máximo de 64 processadores virtuais por máquina virtual.
Determine o controle de recursos para cada máquina virtual. Limites podem ser definidos para garantir que nenhuma máquina virtual possa monopolizar os recursos do processador do host de virtualização.
Definir uma topologia NUMA. Para cargas de trabalho de alto desempenho que reconhecem NUMA, você pode especificar o número máximo de processadores, a quantidade de memória permitida em um único nó NUMA virtual e o número máximo de nós permitido em um soquete de processador único. Para obter mais informações, consulte Visão geral de NUMA Virtual do Hyper-V.

Observação: NUMA virtual e memória dinâmica não podem ser usados ao mesmo tempo. Ao tentar decidir se deseja usar a memória dinâmica ou NUMA, responda às perguntas a seguintes. Se a resposta para ambos for Sim, habilite o NUMA virtual e não a memória dinâmica.

A carga de trabalho em execução na máquina virtual reconhece NUMA?
A máquina virtual consome mais recursos, processadores ou memória do que o disponível em um único nó NUMA físico?

Tarefa 1d: Definir os sistemas operacionais com suporte

É necessário confirmar que o sistema operacional necessário para sua carga de trabalho tem suporte como um sistema operacional convidado. Considere o seguinte:

Supported Windows Guest Operating Systems for Hyper-V in Windows Server 2012 R2 and Windows 8.1
Supported Windows Guest Operating Systems for Hyper-V in Windows Server 2012 and Windows 8
Para Linux: Para obter mais informações sobre as distribuições de Linux com suporte, consulte Máquinas virtuais Linux no Hyper-V.

Observação: O Hyper-V inclui um pacote de software para sistemas operacionais convidados com suporte que melhora o desempenho e a integração entre o computador físico e a máquina virtual. Esta coleção de serviços e drivers de software é conhecida como serviços de integração. Para obter um melhor desempenho, as máquinas virtuais devem executar os serviços de integração mais recentes.

Licenciamento

É necessário garantir que sistemas operacionais convidados estejam devidamente licenciados. Consulte a documentação do fornecedor para ver os requisitos específicos de licenciamento ao executar um ambiente virtualizado.

A ativação automática de máquina virtual (AVMA) é um recurso apresentado no Windows Server 2012 R2. A AVMA vincula a ativação da máquina virtual ao servidor de virtualização licenciado e ativa a máquina virtual quando ele é iniciado. Isso elimina a necessidade de inserir as informações de licenciamento e ativar cada máquina virtual individualmente.

A AVMA requer que o host execute o Windows Server 2012 R2 Datacenter, sendo que o sistema operacional de máquina virtual é o Windows Server 2012 R2 Datacenter, o Windows Server 2012 R2 Standard ou o Windows Server 2012 R2 Essentials.

Observação: É necessário configurar a AVMA em cada host implantado na sua malha de virtualização.

Informações adicionais:

Ativação automática de máquina virtual

Tarefa 1e: Definir a convenção de nomenclatura de máquina virtual

Sua estratégia de nomenclatura de computador existente pode indicar onde o computador ou o servidor se encontra fisicamente. Máquinas virtuais podem ser movidas de host para host, até mesmo entre datacenters diferentes, por isso a estratégia de nomenclatura existente pode não ser aplicável. Uma atualização da convenção de nomenclatura existente para indicar que o computador está em execução como uma máquina virtual pode ajudar a localizar onde a máquina virtual está em execução.

Tarefa 2: Definir a configuração de rede

Cada máquina virtual receberá ou enviará diferentes tipos de tráfego de rede. Cada tipo de tráfego de rede terá diferentes requisitos de desempenho, disponibilidade e segurança.

Máquinas virtuais da 1ª geração podem ter no máximo 12 adaptadores de rede: quatro adaptadores de rede herdados e oito adaptadores de rede virtual. Máquinas virtuais da 2ª geração não dão suporte a adaptadores de rede herdado, portanto, o número máximo de adaptadores com suporte é 8.

Tarefa 2a: Determinar os tipos de tráfego de rede

Cada máquina virtual enviará e receberá diferentes tipos de dados, tais como:

Dados de aplicativos
Backup de dados
Comunicações com os computadores cliente, servidores ou serviços
Comunicação intracluster, se a carga de trabalho fizer parte de um cluster de failover de máquina virtual convidada
Suporte
Armazenamento

Se você já tiver redes existentes dedicadas a diferentes tipos de tráfego de rede, poderá usá-las para essa tarefa. Se você estiver definindo novos designs de rede para dar suporte à malha de virtualização, defina quais tipos de tráfego de rede terão suporte para cada máquina virtual.

Tarefa 2b: Definir opções de desempenho de tráfego de rede

Cada tipo de tráfego de rede possui requisitos de latência mínima e largura de banda máxima. A tabela a seguir mostra as estratégias que podem ser usadas para atender às diferentes necessidades de desempenho de rede.

Estratégia	Vantagens	Desvantagens
Separação dos tipos de tráfego para adaptadores de rede física diferentes	Separa o tráfego de forma que ele não seja compartilhado por outros tipos de tráfego	Adaptadores de rede física separados devem ser instalados no host para cada tipo de tráfego de rede. Hardware adicional é necessário para cada rede que requer alta disponibilidade. Não escalável com um grande número de redes.
Gerenciamento de largura de banda de Hyper-V (Hyper-V QoS)	Fornece QoS para tráfego de rede virtual Impõe uma largura de banda mínima e máxima para um fluxo de tráfego, que é identificada por um número de porta do comutador virtual do Hyper-V. Configure a largura de banda mínima e máxima por porta do comutador virtual do Hyper-V usando cmdlets do PowerShell ou Windows Management Instrumentation (WMI). Configure vários adaptadores de rede virtual no Hyper-V e especifique QoS em cada adaptador de rede virtual individualmente. Forneça um suplemento para política de QoS para a rede física.	QoS de software e hardware não devem ser usados ao mesmo tempo no mesmo adaptador de rede. É necessário planejar adequadamente a política de QoS para a rede e o Hyper-V, para que eles não substituam uns aos outros. Após definir o modo de qualidade de serviço para um comutador virtual, ele não poderá ser alterado. Você não poderá migrar máquinas virtuais em um host com um comutador virtual configurado para usar um modo diferente de QoS. A migração será bloqueada quando valores absolutos configurados para uma máquina virtual não puderem ser cumpridos.
SR-IOV	Fornece a menor latência de rede para uma máquina virtual Fornece a maior E/S de rede para uma máquina virtual Reduz a sobrecarga de CPU necessária para a rede virtual	É necessário um adaptador de rede compatível com SR-IOV e o driver no host e em cada máquina virtual onde uma função virtual está atribuída. Adaptadores de rede virtual habilitados para SR-IOV não podem fazer parte da equipe de NIC no host. Para alta disponibilidade de rede, dois ou mais adaptadores de rede SR-IOV precisam ser instalados no host e o agrupamento NIC precisa ser configurado na máquina virtual. A SR-IOV deve ser usada somente por cargas de trabalho confiáveis porque o tráfego ignora o comutador do Hyper-V e tem acesso direto ao adaptador de rede física. Configurar a porta do comutador virtual de ACLs, Hyper-V QoS, RouterGuard e DHCPGuard impedirá que a SR-IOV possa ser usada. Não há suporte para SR-IOV para máquinas virtuais em execução no Azure.
Dimensionamento do lado recebedor virtual	Oferece suporte ao dimensionamento do lado recebedor virtual, que permite que as máquinas virtuais distribuam a carga de processamento de rede entre vários processadores virtuais (vCPUs) para aumentar a taxa de transferência de rede em máquinas virtuais Oferece compatibilidade com: Agrupamento de NICs Migração ao vivo NVGRE	O dimensionamento do lado recebedor virtual requer que o adaptador de rede física ofereça suporte à Fila de Máquina Virtual (VMQ), que deverá estar habilitada no host. Não é compatível com um adaptador de rede virtual habilitado para SR-IOV. Máquinas virtuais devem executar o Windows Server 2012 R2 ou Windows 8.1. Desabilitado por padrão se o adaptador de VMQ for menor que 10 Gbps.
Quadros jumbo	Permite que mais dados sejam transferidos com cada transação de Ethernet, reduzindo o número de quadros que precisam ser transmitidos Normalmente usado para comunicação com o armazenamento, mas pode ser usado para todos os tipos de comunicação Reduz a sobrecarga em máquinas virtuais, equipamento de rede e o servidor final para o qual os dados estão sendo enviados Configurado para comunicação em um data center onde você pode controlar as configurações de unidade de transmissão máxima (MTU) em todos os saltos	Fornece uma probabilidade ligeiramente menor de detecção de erro. Cada dispositivo de rede no caminho deve dar suporte aos quadros jumbo e ser configurado com a configuração de MTU igual ou superior. Use o comando Ping para verificar as configurações de MTU ponta a ponta. Se um salto ao longo do caminho não oferecer suporte a quadros Jumbo ou se estiver configurado com uma MTU menor, os pacotes serão descartados.

Tarefa 2c: Definir opções de disponibilidade de tráfego de rede

O agrupamento NIC, também conhecido como balanceamento de carga e failover (LBFO), permite que vários adaptadores de rede sejam colocados em uma equipe para fins de failover de tráfego e agregação de largura de banda. Isso mantém a conectividade em caso de falha de um componente de rede. O agrupamento NIC é normalmente configurado no host e, ao criar o comutador virtual, ele estará vinculado à equipe de adaptador de rede.

Os comutadores de rede que são implantados determinam o modo do agrupamento NIC. As configurações padrão no Windows Server 2012 R2 devem ser suficientes para a maioria das implantações.

Observação: SR-IOV não é compatível com agrupamento NIC. Para obter mais informações sobre SR-IOV, consulte a Tarefa 2b: Definir opções de desempenho de tráfego de rede.

Informações adicionais:

Visão geral de agrupamento NIC

Tarefa 2d: Definir opções de segurança de tráfego de rede

Cada tipo de tráfego de rede pode ter requisitos de segurança diferentes, por exemplo, requisitos relacionados à criptografia e isolamento. A tabela a seguir explica estratégias que podem ser usadas para atender a vários requisitos de segurança.

Estratégia	Vantagens	Desvantagens
Separação de diferentes adaptadores de rede	Tráfego separado de outros tráfegos de rede	Não apresenta bom dimensionamento. Quanto mais redes você tiver, mais adaptadores de rede precisará instalar e gerenciar no host.
IPsec com IPsec Descarregamento de tarefa	Oferece suporte ao descarregamento de criptografia de tráfego de rede em máquinas virtuais usando o Hyper-V Criptografa o tráfego enquanto ele está atravessando a rede	A instalação é complexa Pode dificultar a solução de problemas porque não é possível abrir o tráfego entre os hosts e máquinas virtuais Aumenta a utilização do processador quando adaptadores de rede física no host não oferecem suporte ao descarregamento de IPsec
Marcação de VLAN	Já usado pela maioria das empresas Compatível com as políticas de QoS Oferece suporte a VLANs privados Oferece suporte ao modo tronco de VLAN para máquinas virtuais Reduz o número de adaptadores físicos que precisam ser instalados no host	Limitado a 4094 VLANs A configuração é necessária para comutadores, hosts e máquinas virtuais Alterações incorretas nas definições da configuração de VLAN podem levar a problemas de rede específicos do servidor ou de todo o sistema
Virtualização de rede do Hyper-V	Fornece o posicionamento da carga de trabalho flexível, incluindo isolamento de rede e reutilização de endereços IP sem VLANs Permite a mudança fácil de cargas de trabalho para a nuvem Oferece suporte à migração dinâmica em sub-redes sem a necessidade de inserir um novo endereço IP no novo servidor Permite soluções de rede multilocatários Fornece o design de rede simplificada, o servidor aprimorado e o uso de recursos de rede. A rigidez das VLANs com a dependência do posicionamento da máquina virtual em uma infraestrutura de rede física normalmente resulta em excesso de provisionamento e subutilização.	O Gerenciamento de Virtualização de Rede do Hyper-V requer o System Center 2012 R2 - Virtual Machine Manager ou uma solução de gerenciamento que não seja da Microsoft. Um gateway de virtualização de rede do Hyper-V é necessário para permitir a comunicação fora da rede virtual.
DHCPGuard	Impede a máquina virtual de realizar ofertas de DHCP na rede virtual Configurado por adaptador de rede virtual Não impede a máquina virtual de receber um endereço de um servidor DHCP	Impacto mínimo no desempenho quando ativado
RouterGuard	Bloqueia os pacotes a seguir: ICMPv4 tipo 5 (redirecionamento de mensagem) ICMPv4 tipo 9 (anúncio do roteador) ICMPv6 tipo 134 (anúncio do roteador) ICMPv6 tipo 137 (redirecionamento de mensagem) Configurado por adaptador de rede virtual	Impacto mínimo no desempenho quando ativado

Decisão de design - Você pode baixar a Planilha do guia de considerações de design de malha de virtualização e alterar os dados de exemplo na planilha de configurações de máquina virtual para refletir as decisões tomadas nas tarefas anteriores desta etapa. Para decisões de design subsequentes, este documento faz referência a planilhas específicas neste guia nas quais você pode inserir os dados.

Tarefa 2e: Definir os adaptadores de rede virtual

Com uma compreensão dos tipos de tráfego exigidos pelas máquinas virtuais, bem como sobre as estratégias de desempenho, disponibilidade e segurança para o tráfego, você pode determinar quantos adaptadores de rede virtual cada máquina virtual exigirá.

Um adaptador de rede virtual é conectado a um comutador virtual. Há três tipos de comutadores virtuais:

Comutador virtual externo
Comutador virtual interno
Comutador virtual privado

O comutador virtual externo fornece à máquina virtual o acesso à rede física através do adaptador de rede associado ao comutador virtual conectado. Um adaptador de rede física no host somente pode ser associado a um único comutador externo.

Se você atribuir o tráfego de máquina virtual a VLANs diferentes, um adaptador de rede que dá suporte a VLANs deverá ser instalado no host e atribuído ao comutador virtual. Você pode definir a ID de VLAN para a máquina virtual nas propriedades da máquina virtual. A ID de VLAN definido no comutador virtual é aquele que será atribuído ao adaptador de rede virtual atribuído ao sistema operacional do host.

Observação: Se você possui uma máquina virtual que requer acesso a mais redes do que os adaptadores disponíveis, habilite o modo de tronco de VLAN para o adaptador de rede da máquina virtual usando o cmdlet Set-VMNetworkAdapterVlan do Windows PowerShell.

Tarefa 2f: Definir a estratégia de endereçamento IP

É necessário determinar como você atribuirá endereços IP às suas máquinas virtuais. Se você não fizer isso, poderão ocorrer conflitos de endereços IP, podendo gerar um impacto negativo sobre outras máquinas virtuais e dispositivos físicos na rede.

Além disso, servidores DHCP não autorizados podem causar estragos na sua infraestrutura de rede e podem ser especialmente difíceis de controlar quando o servidor estiver sendo executado como uma máquina virtual. Você pode proteger sua rede contra servidores DHCP não autorizados em execução em uma máquina virtual habilitando DHCPGuard nas configurações das máquinas virtuais. O DHCPGuard protege contra uma máquina virtual mal-intencionada que se apresenta como um servidor DHCP para ataques a intermediários.

Informações adicionais:

Visão geral do protocolo DHCP

DHCPGuard

Visão geral do Gerenciamento de Endereços IP (IPAM)

Tarefa 3: Definir a configuração de armazenamento

Para determinar a configuração de armazenamento, é necessário definir os tipos de dados que serão armazenados nas máquinas virtuais e o tipo de armazenamento que eles precisam.

Tarefa 3a: Definir os tipos de dados

A tabela a seguir lista os tipos de dados que uma máquina virtual pode necessitar armazenar, bem como onde tais tipos de dados geralmente são armazenado.

Tipo de dado	Local de armazenamento para o tipo de dado
Arquivos do sistema operacional	Dentro de um arquivo de disco rígido virtual que é armazenado pelo host de virtualização. As considerações de armazenamento para o host de virtualização são abordadas com mais detalhes na etapa 4: Planejar os hosts de virtualização de servidores, abaixo.
Arquivo de paginação do Windows	Geralmente armazenado no mesmo local que os arquivos do sistema operacional.
Arquivos de programa do aplicativo	Geralmente armazenado no mesmo local que os arquivos do sistema operacional.
Dados de configuração do aplicativo	Geralmente armazenado no mesmo local que os arquivos do sistema operacional.
Dados de aplicativos	Geralmente armazenados separadamente dos arquivos de aplicativo e do sistema operacional. Por exemplo, se o aplicativo for um aplicativo de banco de dados, os arquivos de banco de dados geralmente são armazenados em uma solução de armazenamento eficiente, de rede e altamente disponível que fica separada do local onde são armazenados os arquivos de programa do aplicativo ou do sistema operacional.
Volumes Compartilhados de Cluster (CSV) e testemunha de disco (necessário para cluster de máquina virtual convidada)	Geralmente armazenados separadamente dos arquivos de aplicativo e do sistema operacional. O armazenamento CSV é onde os aplicativos em cluster armazenam dados para que estes fiquem disponíveis para todos os nós no cluster. Uma testemunha de disco é um disco no armazenamento de cluster designado para manter uma cópia do banco de dados de configuração de cluster. Um cluster de failover tem uma testemunha de disco somente se isto for especificado como parte da configuração de quórum.
Arquivos de despejo de memória	Geralmente armazenado no mesmo local que os arquivos do sistema operacional.

Tarefa 3b: Definir tipos de armazenamento

A tabela a seguir lista os tipos de armazenamento que podem ser usados para os tipos de dados definidos na Etapa 2, tarefa 2a acima.

Tipo de armazenamento	Considerações
Disco virtual de IDE	Máquinas virtuais da 1ª geração: dois controladores IDE e cada controlador oferece suporte a no máximo dois dispositivos IDE para um máximo de quatro dispositivos IDE. O disco de inicialização, também conhecido como o disco de boot, deve ser anexado a um dos dispositivos IDE como um disco rígido virtual ou um disco físico. Máquinas virtuais da 2ª geração não dão suporte a dispositivos IDE.
SCSI Virtual	4 controladores SCSI virtuais são suportados por cada controlador com suporte para até 64 dispositivos para um total de 256 dispositivos SCSI. Como máquinas virtuais de 2ª geração só oferecem suporte a uma unidade SCSI, as máquinas virtuais da 2ª geração oferecem suporte a discos de inicialização de SCSI.
Iniciador de iSCSI na máquina virtual	Aproveite o armazenamento em SAN sem instalar adaptadores de Fibre Channel no host. Não pode ser usado para o disco de inicialização. Use políticas de QoS da rede para garantir a disponibilidade de largura de banda adequada para armazenamento e outros tráfegos de rede. Não é compatível com a réplica do Hyper-V. Ao usar um back-end de armazenamento SAN, use as opções de replicação de SAN indicadas pelo seu fornecedor de armazenamento.
Fibre Channel virtual	Requer um ou mais adaptadores de barramento de host (HBAs) Fibre Channel ou adaptadores de rede convergidos Fibre Channel over Ethernet (FCoE) em cada host que hospeda máquinas virtuais com adaptadores de Fibre Channel virtual. Drivers HBA e FCoE devem oferecer suporte a Fibre Channel virtual. Uma SAN habilitado para NPIV. Requer configuração adicional para oferecer suporte à migração dinâmica. Para obter mais informações sobre a migração dinâmica e Fibre Channel virtual, consulte Visão geral do Fibre Channel virtual do Hyper-V. Não é compatível com a réplica do Hyper-V. Ao usar um armazenamento SAN, use as opções de replicação de SAN indicadas pelo seu fornecedor de armazenamento. Uma máquina virtual pode ter até quatro portas virtuais. LUNs de Fibre Channel virtual não podem ser usados como mídia de inicialização para a máquina virtual.
SMB 3.0	Acessar arquivos armazenados em compartilhamentos de SMB 3.0 de dentro da máquina virtual.

Tarefa 3c: Definir o tipo e o formato do disco rígido virtual

Se você estiver usando o tipo de armazenamento de disco rígido virtual, deverá primeiro selecionar o formato VHD que será usado dentre as opções listadas na tabela a seguir.

Formato de disco	Vantagens	Desvantagens
VHD	Com suporte em todas as versões do Hyper-V Com suporte em implementações locais e do Azure	Capacidade máxima de armazenamento de 2040 GB Tamanho máximo de disco rígido virtual com suporte no Azure é de 1 TB Não tem suporte em máquinas virtuais da 2ª geração
VHDX	Capacidade máxima de armazenamento de 64 terabytes (TB) Proteção contra corrupção de dados durante falhas de energia Alinhamento aprimorado do formato de disco rígido virtual para funcionar bem em discos com grandes setores Um disco virtual do setor lógico de 4 KB possibilita um maior desempenho quando usado por aplicativos e cargas de trabalho projetados para setores de 4 KB Pode ser usado como armazenamento compartilhado para máquinas virtuais que requerem o Clustering de Failover	Atualmente não há suporte em máquinas virtuais no Azure Não pode ser usado com as versões do Hyper-V anteriores ao Windows Server 2012
VHDX compartilhado	Usado para armazenamento compartilhado para clusters de máquina virtual convidada	Requer o Windows Server 2012 R2 no host que executa o Hyper-V Sistemas operacionais convidados com suporte para clusters convidados que usam um disco rígido virtual compartilhado que inclui o Windows Server 2012 R2 e o Windows Server 2012. Para oferecer suporte ao Windows Server 2012 como um sistema operacional convidado, o Windows Server 2012 R2 Integration Services deve ser instalado no convidado (máquina virtual). Os recursos a seguir não são compatíveis com VHDX compartilhado: Réplica do Hyper-V Redimensionando o disco rígido virtual durante a execução de qualquer uma das máquinas virtuais configuradas Migração de armazenamento ao vivo Backups de VSS no nível do host. Backups no nível do convidado devem ser realizados usando os mesmos métodos que você deseja usar para um cluster em execução em servidores físicos. Pontos de verificação de máquina virtual QoS de armazenamento

Em seguida, selecione o tipo de disco que você usará nas opções listadas na tabela a seguir.

Tipo de disco	Vantagens	Desvantagens
Fixo	Provavelmente será menos afetado pela fragmentação que outros tipos de disco Menor sobrecarga de CPU que outros tipos de disco Depois que o arquivo VHD é criado, há menos preocupação quanto ao espaço em disco disponível que em outros tipos de disco Com suporte em implementações locais e do Azure	Um disco rígido virtual criado requer que todo o espaço esteja disponível, mesmo se a máquina virtual não estiver usando todo o espaço. O disco rígido virtual não poderá ser criado se não houver espaço suficiente disponível. O espaço não usado no disco rígido virtual não pode ser alocado para outros discos rígidos virtuais.
Dinâmico	Somente usa espaço em disco conforme a necessidade, em vez de usar tudo o que foi provisionado	Atualmente não há suporte no Azure, embora os discos dinâmicos possam ser convertidos em discos fixos É importante monitorar o espaço livre em disco ao usar discos rígidos virtuais dinâmicos. Se não houver espaço em disco disponível para um disco rígido virtual dinâmico crescer, a máquina virtual entrará em um estado de pausa crítica. O arquivo de disco rígido virtual pode se tornar fragmentado CPU com sobrecarga ligeiramente maior para operações de leitura e gravação do que para o tipo de disco fixo
Diferencial	Pode usar menos espaço em disco se vários discos diferenciais usarem o mesmo pai	Atualmente não há suporte no Azure As alterações feitas em um disco pai podem causar inconsistência de dados no disco filho CPU com sobrecarga ligeiramente maior para operações de leitura e gravação para altas cargas de trabalho intensas de E/S

Ao selecionar um formato e tipo de arquivo de disco rígido virtual, considere o seguinte:

Ao usar o formato VHDX, um disco dinâmico pode ser usado porque ele oferece garantias de resiliência, além de economia de espaço associada ao alocar espaço somente quando há necessidade.
Um disco fixo também pode ser usado, independentemente do formato, quando o armazenamento no volume do host não é ativamente monitorado. Isso garante que haja espaço em disco suficiente quando o arquivo VHD for expandido no tempo de execução.
Pontos de verificação (anteriormente conhecidos como instantâneos) de uma máquina virtual criam um disco rígido virtual diferencial para armazenar gravações nos discos. Ter apenas alguns pontos de verificação pode aumentar o uso da CPU de E/S de armazenamento, mas eles não afetam o desempenho visivelmente (exceto em cargas de trabalho de E/S altamente intensiva).

No entanto, ter uma grande cadeia de pontos de verificação pode afetar profundamente o desempenho, porque ler por meio de discos rígidos virtuais pode exigir verificação para os blocos solicitados de muitos discos diferenciais. Manter cadeias de ponto de verificação breves é importante para manter o desempenho de E/S de disco.

Tarefa 3d: Definir o tipo de armazenamento a ser usado para cada tipo de dados

Depois de definir os tipos de dados e armazenamento usados pelas máquinas virtuais, você pode determinar qual tipo de armazenamento e qual formato e tipo de disco virtual será usado para cada tipo de dados.

Tarefa 4: Definir a estratégia de disponibilidade de máquina virtual

Embora os administradores de malha sejam responsáveis pela disponibilidade da malha, os administradores de máquina virtual são responsáveis em última instância pela disponibilidade de suas máquinas virtuais. Como resultado, o administrador da máquina virtual deve compreender os recursos da malha para criar a estratégia de disponibilidade apropriada para suas máquinas virtuais.

As tabelas a seguir analisam três estratégias de disponibilidade para máquinas virtuais executando cargas de trabalho com as caracterizações definidas na etapa 1, tarefa 2 acima. Normalmente, o administrador de malha informa os administradores da máquina virtual com antecedência ao planejar atividades programadas para a malha, para que os administradores da máquina virtual possam planejar adequadamente. As três estratégias de disponibilidade são:

Sem monitoração de estado
Com monitoração de estado
Monitoração de estado compartilhada

Sem monitoração de estado

Opção	Considerações
Migração dinâmica de máquina virtual no nível do host	Se um host precisar ser desativado para manutenção planejada, as máquinas virtuais em execução podem ser migradas para um host operável sem tempo de inatividade para as máquinas virtuais. Para obter mais informações sobre as considerações de host, consulte a Tarefa 5: Definir a estratégia de disponibilidade do host de virtualização de servidor abaixo. Se as máquinas virtuais não forem armazenadas em um repositório que seja acessível a ambos os hosts, será necessário mover o armazenamento de máquina virtual durante uma migração dinâmica. Se um host falhar inesperadamente, todas as máquinas virtuais em execução no host interromperão sua execução. É necessário iniciar as máquinas virtuais executando a mesma carga de trabalho em outro host.
Clusters com balanceamento de carga (usando o Balanceamento de Carga de Rede do Windows)	Requer que o administrador da máquina virtual tenha pelo menos duas máquinas virtuais executando uma carga de trabalho idêntica hospedada em hosts diferentes. O Balanceamento de Carga de Rede (NLB) é configurado nas máquinas virtuais pelo administrador da máquina virtual. O NLB requer que endereços IP estáticos sejam atribuídos aos adaptadores de rede. Não há suporte para a atribuição de endereço DHCP. O administrador da máquina virtual precisa trabalhar em conjunto com o administrador de malha para obter endereços IP a serem usados para o endereço IP virtual do NLB e criar a entrada DNS necessária. Habilite a falsificação de MAC para a rede virtual usada pelo NLB nos convidados. Isso somente ser feito por meio das configurações de adaptador de rede em cada máquina virtual que está participando de um cluster NLB como um nó. Você pode criar clusters NLB, adicionar nós e atualizar configurações de cluster NLB sem reinicializar as máquinas virtuais. Todas as máquinas virtuais que estão participando do cluster NLB devem estar na mesma sub-rede. Para garantir a disponibilidade da carga de trabalho (mesmo em caso de falha do host), o administrador de malha de máquina virtual precisa garantir que as máquinas virtuais estejam em execução em hosts diferentes.
Clusters com balanceamento de carga (usando um balanceador de carga de hardware)	É necessário fornecer esse recurso no nível de malha e os administradores devem configurar clusters com balanceamento de carga para máquinas virtuais que precisam dele. Ou então, eles podem permitir que os administradores da máquina virtual o configurem por meio do portal de gerenciamento para o balanceador de carga de hardware. Requer que o administrador da máquina virtual tenha pelo menos duas máquinas virtuais executando uma carga de trabalho idêntica hospedada na malha. Analise a documentação do produto do fornecedor de hardware para obter informações adicionais.

Com monitoração de estado

Opção	Considerações
Cluster de Hyper-V	Requer a configuração de um cluster de failover. Requer armazenamento compartilhado entre todos os nós no cluster para os arquivos CSV. Este pode ser o armazenamento SAN ou um compartilhamento de arquivos SMB 3.0. Quando o cluster detecta um problema com um host ou o Hyper-V detecta um problema com o armazenamento ou a rede de máquina virtual, esta pode ser movida para outro host. A máquina virtual continua em execução durante a mudança. Se houver uma falha catastrófica em um host, as máquinas virtuais que estavam em execução no host poderão ser iniciadas em outros nós no cluster. Máquinas virtuais essenciais podem ser configuradas para iniciarem automaticamente. Isso limita o tempo de inatividade em caso de falha catastrófica do host. Aplique patches em hosts sem afetar a execução de máquinas virtuais com a atualização com suporte a cluster. Configure a anti-afinidade de máquina virtual para evitar a execução de máquinas virtuais no mesmo nó. Por exemplo, se você estiver executando dois servidores web que fornecem serviços de front-end para um aplicativo de back-end, não é recomendável que ambos os servidores web estejam em execução no mesmo nó. Um nó pode ser colocado em modo de manutenção e o serviço de cluster de failover se mudará as máquinas virtuais em execução para outro nó no cluster. Quando não houver máquinas virtuais em execução no nó, a manutenção necessária poderá ser executada. O cluster de failover não moverá as máquinas virtuais para um nó no modo de manutenção. Antes de colocar um nó no modo de manutenção, certifique-se de que há capacidade suficiente nos outros nós do cluster do Hyper-V para executar as máquinas virtuais existentes e ainda manter os SLAs para seus clientes.

Cluster de Hyper-V

Requer a configuração de um cluster de failover.
Requer armazenamento compartilhado entre todos os nós no cluster para os arquivos CSV. Este pode ser o armazenamento SAN ou um compartilhamento de arquivos SMB 3.0.
Quando o cluster detecta um problema com um host ou o Hyper-V detecta um problema com o armazenamento ou a rede de máquina virtual, esta pode ser movida para outro host. A máquina virtual continua em execução durante a mudança.
Se houver uma falha catastrófica em um host, as máquinas virtuais que estavam em execução no host poderão ser iniciadas em outros nós no cluster. Máquinas virtuais essenciais podem ser configuradas para iniciarem automaticamente. Isso limita o tempo de inatividade em caso de falha catastrófica do host.
Aplique patches em hosts sem afetar a execução de máquinas virtuais com a atualização com suporte a cluster.
Configure a anti-afinidade de máquina virtual para evitar a execução de máquinas virtuais no mesmo nó. Por exemplo, se você estiver executando dois servidores web que fornecem serviços de front-end para um aplicativo de back-end, não é recomendável que ambos os servidores web estejam em execução no mesmo nó.
Um nó pode ser colocado em modo de manutenção e o serviço de cluster de failover se mudará as máquinas virtuais em execução para outro nó no cluster. Quando não houver máquinas virtuais em execução no nó, a manutenção necessária poderá ser executada.

O cluster de failover não moverá as máquinas virtuais para um nó no modo de manutenção. Antes de colocar um nó no modo de manutenção, certifique-se de que há capacidade suficiente nos outros nós do cluster do Hyper-V para executar as máquinas virtuais existentes e ainda manter os SLAs para seus clientes.

Monitoração de estado compartilhada

Ao executar cargas de trabalho com suporte a cluster, você poderá fornecer uma camada adicional de disponibilidade habilitando o cluster convidado da máquina virtual. O cluster convidado suporta alta disponibilidade para cargas de trabalho dentro da máquina virtual. O cluster convidado fornece proteção para a carga de trabalho em execução em máquinas virtuais, mesmo se um host falhar onde a máquina virtual está em execução. Como a carga de trabalho foi protegida pelo clustering de Failover, a máquina virtual no outro nó poderá assumir automaticamente.

Opção	Considerações
Cluster convidado de máquina virtual	Requer armazenamento compartilhado acessível por duas ou mais máquinas virtuais ao mesmo tempo. Os tipos de arquivo com suporte incluem: iSCSI Fibre Channel virtual VHDX compartilhado Configure a antiafinidade de máquina virtual para evitar a execução de ambas as máquinas virtuais no mesmo nó de cluster. Não há suporte para cluster convidado de máquina virtual no Azure. Os recursos a seguir não são compatíveis com VHDX compartilhado: Réplica do Hyper-V Redimensionando o disco rígido virtual durante a execução de qualquer uma das máquinas virtuais configuradas Migração de armazenamento ao vivo Backups de VSS no nível do host. Backups no nível do convidado devem ser realizados usando os mesmos métodos que você deseja usar para um cluster em execução em servidores físicos. Pontos de verificação de máquina virtual QoS de armazenamento

Cluster convidado de máquina virtual

Requer armazenamento compartilhado acessível por duas ou mais máquinas virtuais ao mesmo tempo. Os tipos de arquivo com suporte incluem:
- iSCSI
- Fibre Channel virtual
- VHDX compartilhado
Configure a antiafinidade de máquina virtual para evitar a execução de ambas as máquinas virtuais no mesmo nó de cluster.
Não há suporte para cluster convidado de máquina virtual no Azure.
Os recursos a seguir não são compatíveis com VHDX compartilhado:
- Réplica do Hyper-V
- Redimensionando o disco rígido virtual durante a execução de qualquer uma das máquinas virtuais configuradas
- Migração de armazenamento ao vivo
- Backups de VSS no nível do host. Backups no nível do convidado devem ser realizados usando os mesmos métodos que você deseja usar para um cluster em execução em servidores físicos.
- Pontos de verificação de máquina virtual
- QoS de armazenamento

Informações adicionais:

Implantar um cluster convidado usando um disco rígido virtual compartilhado

Usando um cluster convidado para alta disponibilidade

Recuperação de Desastres

Em caso de desastre, com que rapidez você consegue restaurar as cargas de trabalho necessárias para que possam atender os clientes? Em alguns casos, o tempo alocado pode ser apenas alguns minutos.

A replicação de dados de seus data centers principais os centros de recuperação de desastres é necessária para garantir que os dados mais atualizados possam sempre ser replicados com uma perda de dados aceitável devido a atrasos. Ao executar cargas de trabalho em máquinas virtuais, você pode duplicar os discos rígidos virtuais e os arquivos de configuração de máquina virtual do site primário para um site de réplica.

A tabela a seguir compara as opções de recuperação de desastres.

Opção	Considerações
Réplica do Hyper-V	Baixo custo e não há necessidade de duplicar o hardware de armazenamento e de host em locais de recuperação de desastres. Use as mesmas ferramentas de gerenciamento para gerenciar a replicação bem como as máquinas virtuais. Intervalos de duplicação configuráveis para atender seus requisitos de perda de dados. Configure diferentes endereços IP a serem usados no site de réplica. Impacto mínimo sobre a infraestrutura de rede. Sem suporte para máquinas virtuais configuradas com discos físicos (também conhecido como discos de passagem), armazenamento de Fibre Channel virtual ou discos rígidos virtuais compartilhados. A réplica do Hyper-V não deve ser usada como uma substituição para o armazenamento de backup de dados e recuperação de dados. Armazenamento adicional será necessário no site réplica se os pontos de recuperação adicionais forem configurados. A taxa de intervalo de replicação determinará o volume de perda de dados. O armazenamento adicional será necessário no site de réplica se uma máquina virtual com uma grande quantidade de alterações for configurada com um intervalo de replicação curto.
Backup	Faça backup completo da máquina virtual usando uma solução de backup com suporte no Hyper-V, como o System Center Data Protection Manager. A perda de dados será determinada de acordo com a idade do último backup. Não é possível realizar o backup no nível do host de máquinas virtuais configuradas com um arquivo VHDX compartilhado. Instale um agente de backup na máquina virtual e faça backup dos dados de dentro da máquina virtual.

Réplica do Hyper-V

Baixo custo e não há necessidade de duplicar o hardware de armazenamento e de host em locais de recuperação de desastres.
Use as mesmas ferramentas de gerenciamento para gerenciar a replicação bem como as máquinas virtuais.
Intervalos de duplicação configuráveis para atender seus requisitos de perda de dados.
Configure diferentes endereços IP a serem usados no site de réplica.
Impacto mínimo sobre a infraestrutura de rede.
Sem suporte para máquinas virtuais configuradas com discos físicos (também conhecido como discos de passagem), armazenamento de Fibre Channel virtual ou discos rígidos virtuais compartilhados.
A réplica do Hyper-V não deve ser usada como uma substituição para o armazenamento de backup de dados e recuperação de dados.
Armazenamento adicional será necessário no site réplica se os pontos de recuperação adicionais forem configurados.
A taxa de intervalo de replicação determinará o volume de perda de dados.
O armazenamento adicional será necessário no site de réplica se uma máquina virtual com uma grande quantidade de alterações for configurada com um intervalo de replicação curto.

Backup

Faça backup completo da máquina virtual usando uma solução de backup com suporte no Hyper-V, como o System Center Data Protection Manager.
A perda de dados será determinada de acordo com a idade do último backup.
Não é possível realizar o backup no nível do host de máquinas virtuais configuradas com um arquivo VHDX compartilhado. Instale um agente de backup na máquina virtual e faça backup dos dados de dentro da máquina virtual.

Observações:

Para gerenciar centralmente e automatizar a replicação executando o System Center 2012 R2 - Virtual Machine Manager, você precisará usar o Microsoft Azure Site Recovery.
Para replicar máquinas virtuais no Azure usando o Microsoft Azure Site Recovery. Replicar uma máquina virtual no Azure está atualmente em modo de visualização.

Informações adicionais:

Microsoft Azure Site Recovery

Importante:

Use o Hyper-V Replica Capacity Planner para compreender o impacto que a réplica do Hyper-V terá sobre sua infraestrutura de rede, a utilização do processador nos servidores primário, de réplica e de réplica estendida, o uso de memória nos servidores primário e de réplica e o IOPS de disco nos servidores primário, de réplica e de réplica estendida com base em suas máquinas virtuais existentes.
Sua carga de trabalho pode ter uma solução de recuperação de desastres, como os Grupos de Disponibilidade AlwaysOn no SQL Server. Consulte a documentação da carga de trabalho para confirmar se a réplica do Hyper-V é suportada pela carga de trabalho.

Informações adicionais:

Réplica do Hyper-V

System Center Data Protection Manager

Tarefa 5: Definir os tipos de máquina virtual

Para oferecer suporte às cargas de trabalho em seu ambiente, você pode criar máquinas virtuais com os requisitos de recursos exclusivos para atender às necessidades de cada carga de trabalho. Como alternativa, você pode adotar uma abordagem semelhante a provedores públicos de máquina virtual que hospeda serviços (também chamados de infraestrutura como um serviço (IaaS).

Consulte Tamanhos de máquina virtual e de serviço de nuvem para o Azure para ver uma descrição das configurações de máquina virtual oferecidas pelo Microsoft Azure Infrastructure Services. Até o momento de criação deste artigo, o serviço oferece suporte a 13 configurações de máquina virtual, cada uma com diferentes combinações de espaço para o processador, memória, armazenamento e IOP.

Decisão de design - As decisões tomadas em todas as tarefas desta etapa podem ser inseridas na planilha de configurações de máquina virtual.

Etapa 3: Planejar grupos de host de virtualização de servidores

Antes de definir os hosts de servidor individual, convém primeiro definir grupos de hosts. Grupos de hosts são simplesmente um conjunto nomeado de servidores que são agrupados para atender aos objetivos comuns que descritos nas tarefas restantes desta etapa.

Tarefa 1: Definir locais físicos

Você provavelmente agrupará e gerenciará recursos de hardware por local físico, por isso deverá primeiro definir os locais que contém recursos de malha em sua organização.

Tarefa 2: Definir tipos de grupos de hosts

Você pode criar grupos de hosts por vários motivos, tal como cargas de trabalho de host com itens específicos de:

Caracterizações da carga de trabalho
Requisitos de recursos
Requisitos de qualidade de serviço

A imagem a seguir ilustra uma organização que criou cinco grupos de hosts em dois locais.

Grupo de hosts

Figure 2:Exemplo de grupo de hosts

A organização criou os grupos de hosts pelos motivos descritos na tabela a seguir.

Grupo de hosts	Motivos para criá-los
Carga de trabalho com e sem monitoração de estado	Essas caracterizações de cargas de trabalho são as mais comuns na organização, por isso esse tipo de grupo de hosts existe em ambos os locais. Essas cargas de trabalho têm requisitos semelhantes de nível de serviço e de desempenho.
Cargas de trabalho com e sem monitoração de estado do departamento de contabilidade	Embora a configuração de hardware dos servidores nesse grupo de hosts sejam os mesmos que outros grupos de hosts com e sem monitoração de estado em seu ambiente, o departamento de contabilidade tem aplicativos com requisitos de segurança mais altos que outros departamentos na organização. Por isso, um grupo de hosts dedicado foi criado para eles, para que possam ser protegidos de maneira diferente de outros grupos de hosts na malha.
Cargas de trabalho com monitoração de estado compartilhada	As cargas de trabalho hospedadas por este grupo de hosts requerem armazenamento compartilhado por dependerem de clustering de failover no Windows Server para manter sua disponibilidade. Essas cargas de trabalho são hospedadas por um grupo de hosts dedicado porque a configuração dessas máquinas virtuais é diferente de outras máquinas virtuais na organização.
Cargas de trabalho com monitoração de estado e alta E/S	Todos os hosts nesse grupo de hosts estão conectados a redes de velocidade mais altas que os hosts nos grupos de host.

Embora a organização poderia ter estendidos locais com seus grupos de hosts, eles decidiram manter todos os membros de cada grupo de hosts no mesmo local para facilitar o gerenciamento. Como você pode ver neste exemplo, grupos de hosts podem ser criados para uma variedade de motivos, os quais variam entre as organizações. Quanto mais tipos de grupos de hosts você criar na sua organização, mais complexo será a tarefa d gerenciar o ambiente, aumentando assim o custo de hospedagem de máquinas virtuais.

Dica: Quanto mais padronizado for o hardware do servidor em um grupo de hosts, mais fácil ele será dimensionado e manterá o grupo de hosts com o passar do tempo. Se você determinar que deseja padronizar o hardware dentro de um grupo de hosts, poderá adicionar os dados de configuração padronizada à planilha de grupos de hosts nas Planilhas de considerações de design da malha de virtualização. Para obter mais informações sobre considerações de hardware físico, consulte a Etapa 4: Planejar hosts de virtualização de servidores.

Considere que, atualmente, a maioria dos provedores de nuvem pública que hospedam as máquinas virtuais:

Somente hospedam máquinas virtuais que não exigem estado compartilhado.
Geralmente só têm um conjunto de métricas de qualidade de serviço que eles fornecem a todos os clientes.
Não dedicam hardware específicos a clientes específicos.

É recomendável que você comece com o tipo de grupo de hosts que contém hardware idêntico e somente adicione tipos de grupos de hosts, pois o benefício de fazer isso supera o custo.

Tarefa 3: Determinar o uso de cluster nos membros do grupo de host

No passado, o clustering de failover no Windows Server era usado apenas para aumentar a disponibilidade do servidor, mas agora ele foi expandido para fornecer muito mais funcionalidades. Considere as informações na tabela a seguir para ajudá-lo a decidir se deseja usar cluster nos membros do grupo de hosts.

Opção	Vantagens	Desvantagens
Membros do grupo de hosts fazem parte de um cluster de failover	Se qualquer um dos hosts falhar, as máquinas virtuais hospedadas por ele são automaticamente reiniciadas em nós sobreviventes. As máquinas virtuais podem ser movidas para outro nó no cluster quando o nó em execução no momento detecta um problema com o nó ou na máquina virtual. Use a atualização com suporte a cluster para atualizar facilmente os nós do cluster sem afetar a execução de máquinas virtuais.	Os hosts exigem configuração específica para serem membros do cluster. Os hosts devem ser membros de um domínio do Active Directory. O clustering de failover requer requisitos adicionais de rede e armazenamento.
Membros do grupo de hosts não fazem parte de um cluster de failover	Hosts não exigem uma configuração de cluster específica. Hosts não precisam ser membros de um domínio do Active Directory. Armazenamento e rede adicionais não são necessários.	Máquinas virtuais em execução em um host com falha deverá ser movido manualmente (ou você pode usar alguma forma de automação) para um host sobrevivente e reiniciado.

Decisão de design - As decisões tomadas em todas as tarefas desta etapa podem ser inseridas na planilha de Configurações.

Etapa 4: Planejar hosts de virtualização de servidores

Nesta etapa, você definirá os tipos de hosts necessários para hospedar as máquinas virtuais que você planeja executar em sua malha de virtualização. Em alguns casos, você deve limitar o número de configurações de host a uma única configuração para reduzir os custos de aquisição e suporte. Além disso, adquirir o equipamento errado aumentará os custos de implantação.

Cloud Platform System

A Microsoft traz sua experiência na execução de alguns dos maiores data centers e serviços de nuvem em um sistema convergido integrado de fábrica e totalmente validado. O Cloud Platform System (CPS) combina as pilhas comprovadas da Microsoft do Windows Server 2012 R2, System Center 2012 R2 e Windows Azure Pack com o hardware de servidor de nuvem, armazenamento e rede da Dell. Como um bloco de construção dimensionável para sua nuvem, o CPS reduz o tempo de implantação e proporciona uma experiência de nuvem consistente.

O CPS fornece um ambiente de autoatendimento multilocatário na nuvem para plataforma como serviço, máquinas virtuais do Windows e Linux, e ainda inclui pacotes de implantação otimizada para aplicativos Microsoft como SQL Server, SharePoint e Exchange. A integração de fábrica diminui o risco e a complexidade, acelerando ainda o tempo de implantação de meses para dias. O processo de suporte simplificado e automação de tarefas rotineiras de infraestrutura também libera recursos de TI para se concentrar na inovação.

Para obter mais informações, consulte o site do Cloud Platform System.

Fast Track

Em vez de projetar sua configuração de hardware (e software), você pode adquirir as configurações de hardware pré-configurado de uma variedade de parceiros de hardware por meio do programa Microsoft Private Cloud Fast Track.

O programa Fast Track é um esforço conjunto entre a Microsoft e seus parceiros de hardware para fornecer soluções pré-configuradas validadas que reduzem a complexidade e o risco de implementar uma malha de virtualização, bem como as ferramentas para gerenciá-la.

O programa Fast Track oferece flexibilidade de soluções e escolha do cliente em tecnologias de fornecedores de hardware. Ele usa os recursos essenciais do sistema operacional Windows Server, a tecnologia Hyper-V e o Microsoft System Center para proporcionar os blocos de construção de uma infraestrutura de nuvem privada como uma oferta de serviço.

Informações adicionais:

Site do Microsoft Private Cloud Fast Track

Tarefa 1: Definir configuração de computação

Nesta tarefa, você poderá determinar a quantidade de memória, o número de processadores e a versão do Windows Server necessários para cada host. O número de máquinas virtuais a serem executadas em um host será determinado pelos componentes de hardware abordados nesta seção.

Observação: Para garantir que sua solução é totalmente suportada, todo o hardware que você comprar deve possuir o logotipo "Certificado para Windows Server" para a versão do servidor do Windows você está executando.

O logotipo "Certificado para Windows Server" demonstra que um sistema de servidor atende os mais altos níveis técnicos da Microsoft em segurança, confiabilidade e capacidade de gerenciamento. Com outros dispositivos e drivers, ele pode oferecer suporte a funções, recursos e interfaces para nuvem e cargas de trabalho, e para aplicativos de negócios.

Para obter alista mais recente do hardware Certificado para o Windows Server, consulte o Catálogo do Windows Server.

Tarefa 1a: Definir o processador

O Hyper-V apresenta os processadores lógicos a cada máquina virtual ativa como um ou mais processadores virtuais. Você pode obter eficiência adicional de tempo de execução usando processadores com suporte a tecnologias de Conversão de Endereços de Segundo Nível (SLAT), como Extended Page Tables (EPTs) ou Nested Page Tables (NPTs). O Hyper-V no Windows Server 2012 R2 oferece suporte a um máximo de 320 processadores lógicos.

Considerações:

Cargas de trabalho que não exige muito do processador devem ser configuradas para usar um processador virtual. Monitore a utilização do processador do host ao longo do tempo para garantir que você alocou processadores adequados para uma eficiência máxima.
Dois ou mais processadores virtuais devem ser atribuídos a cargas de trabalho com uso intensivo de CPU. Você pode atribuir um máximo de 64 processadores virtuais a uma máquina virtual. O número de processadores virtuais reconhecido pela máquina virtual depende do sistema operacional convidado. Por exemplo, o Windows Server 2008 com Service Pack 2 reconhece apenas quatro processadores virtuais.

Informações adicionais:

Visão geral do Hyper-V

Ajuste de desempenho para servidores do Hyper-V

Tarefa 1b: Definir memória

O servidor físico requer memória suficiente para o host e para executar as máquinas virtuais. O host requer memória para executar com eficiência E/S em nome de máquinas virtuais e operações como um ponto de verificação de máquina virtual. O Hyper-V garante que há memória suficiente para o host e permite que o restante da memória seja atribuída às máquinas virtuais. As máquinas virtuais devem ser dimensionadas de acordo com as necessidades da carga esperada para cada máquina virtual.

O hipervisor virtualiza a memória física do convidado para isolar as máquinas virtuais entre si e fornecer um espaço de memória contígua, com base em zero para cada sistema operacional convidado, e o mesmo em sistemas não-virtualizados. Para garantir que você obtenha o máximo de desempenho, use hardware baseado em SLAT para minimizar o custo de desempenho da virtualização de memória.

Você deve planejar o tamanho da memória da sua máquina virtual como faria normalmente para aplicativos de servidor em um computador físico. A quantidade de memória atribuída à máquina virtual deve permitir que ela manipule a carga esperada em momentos de pico e ordinários, porque memória insuficiente pode aumentar significativamente os tempos de resposta e utilização de CPU ou de E/S.

A memória alocada para uma máquina virtual reduz a quantidade de memória disponível para outras máquinas virtuais. Se não houver memória suficiente disponível no host, a máquina virtual não será iniciada.

A memória dinâmica permite que atingir os números mais altos de consolidação com maior confiabilidade para operações de reinicialização. Isso pode reduzir custos, especialmente em ambientes com muitas máquinas virtuais ociosas ou de baixa carga, tal como ambientes de VDI em pools. Alterações de configuração de tempo de execução de memória dinâmica podem reduzir o tempo de inatividade e oferecem maior agilidade para responder às alterações de requisitos.

Para obter mais informações sobre a memória dinâmica, consulte a Tarefa 1b: Definir memória, que descreve como determinar a memória para uma máquina virtual.

Informações adicionais:

Visão geral de memória dinâmica

Visão geral de NUMA virtual

Tarefa 1c: Definir a edição do sistema operacional Windows Server

Os conjuntos de recursos no Windows Server Standard e Windows Server Datacenter são exatamente os mesmos. O Windows Server Datacenter oferece um número ilimitado de máquinas virtuais. Com o Windows Server Standard, você está limitado a duas máquinas virtuais.

No Windows Server 2012 R2, foi adicionado o recurso de ativação automática de máquina virtual (AVMA). O AVMA permite que instalar máquinas virtuais em um servidor devidamente ativado sem ter que gerenciar chaves de produto para cada máquina virtual, mesmo em ambientes desconectados.

O AVMA exige que os sistemas operacionais convidados executem o Windows Server 2012 R2 Datacenter, o Windows Server 2012 R2 Standard ou o Windows Server 2012 R2 Essentials. A tabela a seguir compara as edições.

Edição	Vantagens	Desvantagens
Standard	Inclui todos os recursos do Windows Server Aceitável para ambientes não virtualizados ou pouco virtualizados	Limitado a duas máquinas virtuais
Datacenter	Inclui todos os recursos do Windows Server Oferece um número ilimitado de máquinas virtuais Aceitável para ambientes de nuvem privada altamente virtualizados	Mais caro

O Hyper-V pode ser instalado em uma opção de instalação do Server Core do Windows Server. Uma instalação Server Core reduz o espaço necessário em disco, a superfície de ataque em potencial e especialmente os requisitos de manutenção. Uma instalação Server Core é gerenciada usando a linha de comando, o Windows PowerShell ou administração remota.

É importante revisar os termos de licenciamento de qualquer software que você pretende usar.

Microsoft Hyper-V Server

O Microsoft Hyper-V Server fornece uma solução de virtualização simples e confiável para ajudar as organizações a melhorar a utilização do servidor e reduzir os custos. Ele é um produto autônomo que contém somente o hipervisor do Windows, um modelo de driver do Windows Server e componentes de virtualização.

O Hyper-V Server pode caber em ambientes de TI existentes dos clientes e aproveitar seus processos de provisionamento, gerenciamento e ferramentas de suporte existentes. Ele oferece suporte à mesma lista de compatibilidade de hardware que as edições correspondentes do Windows Server e é totalmente integrado ao Microsoft System Center e tecnologias do Windows como o Windows Update, o Active Directory e o clustering de failover.

O Hyper-V Server é um download gratuito e sua instalação é está ativada. No entanto, todos os sistemas operacionais em execução em uma máquina virtual hospedada exigem uma licença adequada.

Informações adicionais:

Ativação automática de máquina virtual

Microsoft Hyper-V Server

Gerenciar o Hyper-V Server remotamente

Tarefa 2: Definir a configuração de rede

Na Etapa 2, tarefa 2 acima, abordamos as considerações de design para a rede de máquina virtual. Agora vamos discutir as considerações de rede para o host. Há vários tipos de tráfego de rede que você deve considerar e planejar ao implantar o Hyper-V. Você deve projetar sua configuração de rede com os seguintes objetivos em mente:

Garantir a QoS da rede
Fornecer redundância de rede
Isolar o tráfego para redes definidas

Tarefa 2a: Definir os tipos de tráfego de rede

Ao implantar um cluster do Hyper-V, você deve planejar vários tipos de tráfego de rede. A tabela a seguir resume os tipos de tráfego.

Tipo de tráfego	Descrição
Gerenciamento	Fornece conectividade entre o servidor que executa o Hyper-V e a funcionalidade de infraestrutura básica Usado para gerenciar o sistema operacional do host do Hyper-V e máquinas virtuais
Cluster e CSVs	Usado na comunicação de cluster entrenós, como a pulsação do cluster e o redirecionamento de volumes compartilhados de cluster (CSV) Somente quando o Hyper-V foi implantado usando clustering de failover
Migração ao vivo	Usado para migração dinâmica e migração dinâmica não compartilhado de máquina virtual
Armazenamento	Usado para tráfego SMB ou para tráfego iSCSI
Réplica	Usada para o tráfego de replicação de máquina virtual por meio do recurso de réplica do Hyper-V
Tráfego de máquina virtual (locatário)	Usado para conectividade de máquina virtual Normalmente requer conectividade de rede externa às solicitações de cliente Observação: Consulte Etapa 2: Planejar a configuração da máquina virtual para ver uma lista de tipos de tráfego de máquina virtual.
Backup	Usado para fazer backup de arquivos do disco rígido virtual

Tarefa 2b: Definir opções de desempenho de tráfego de rede

Cada tipo de tráfego de rede terá requisitos de largura de banda máxima e mínima e latência mínima. A tabela a seguir mostra as estratégias que podem ser usadas para atender às diferentes necessidades de desempenho de rede.

QoS baseado em política

Ao implantar um cluster de Hyper-V, é necessário um mínimo de seis padrões de tráfego ou redes. Cada rede requer redundância de rede. Para começar, estamos falando de cerca de 12 adaptadores de rede no host. É possível instalar vários adaptadores de rede quadrupleto, mas em algum momento você ficará sem slots no seu host.

O equipamento de rede está ficando mais rápido. Há pouco tempo atrás, os adaptadores de rede de 1 GB eram a última geração. Adaptadores de 10 GB em servidores estão se tornando mais comuns e os preços para oferecer suporte a infraestruturas de 10 GB estão se tornando mais razoáveis.

Instalar dois adaptadores de rede de 10 GB emparelhado fornece mais largura de banda que dois adaptadores de 1 GB quadrupletos, requer menos portas de comutador e simplifica a suas necessidades de cabeamento. Ao concentrar mais dos seus tipos de tráfego de rede nos adaptadores de rede emparelhados de 10 GB, QoS baseada em política permite gerenciar o tráfego de rede para atender adequadamente a necessidade de sua infraestrutura de virtualização.

A QoS baseada em política permite especificar o controle de largura de banda de rede, com base no tipo de aplicativo, usuários e computadores. As políticas de QoS permitem atender aos requisitos de serviço de uma carga de trabalho ou um aplicativo medindo a largura de banda, detectar alteração de condições da rede (como congestionamento ou disponibilidade de largura de banda) e priorizar o tráfego (ou limitação) de rede.

Além da capacidade de impor uma largura de banda máxima, as políticas de QoS no Windows Server 2012 R2 fornecem um novo recurso de gerenciamento de largura de banda: largura de banda mínima. Ao contrário da largura de banda máxima, que é um limite de largura de banda, largura de banda mínima é um piso mínimo de largura de banda e atribui uma certa quantidade de largura de banda para um determinado tipo de tráfego. Você pode implementar simultaneamente os limites de largura de banda mínima e máxima.

Vantagens	Desvantagens
Gerenciado por política de grupo Facilmente aplicados a VLANs para fornecer configurações de largura de banda adequada quando várias VLANs estão em execução no adaptador de rede ou usando o agrupamento NIC QoS baseada em políticas podem ser aplicadas ao tráfego de IPsec	Não oferece gerenciamento de largura de banda para o tráfego que está usando um comutador virtual Hosts do Hyper-V devem ser ingressados no domínio As políticas de QoS baseada em software e hardware (DCB) não devem ser usadas ao mesmo tempo

Informações adicionais:

Visão geral de Qualidade de Servidor (QoS)

Qualidade de Serviço baseada em política

Ponte de Data Center

A Ponte de Data Center (DCB) fornece alocação de largura de banda baseada em hardware para um tipo específico de tráfego e melhora a confiabilidade do transporte Ethernet com o uso do controle de fluxo baseado em prioridade. O DCB é recomendado ao usar FCoE e iSCSI.

Vantagens	Desvantagens
Suporte para Microsoft iSCSI Suporte para FCoE	Investimentos de hardware necessários, incluindo: Adaptadores Ethernet compatíveis com DCB Comutadores de hardware compatíveis com DCB Complexo de implantar e gerenciar Não oferece gerenciamento de largura de banda para o tráfego do comutador virtual As políticas de QoS baseada em software e as políticas DCB não devem ser usadas ao mesmo tempo

Informações adicionais:

Visão geral de Ponte de Data Center (DCB)

SMB Direct

SMB Direct (SMB por Acesso Remoto Direto à Memória ou RDMA) é um protocolo de armazenamento no Windows Server 2012 R2. Ele permite transferências diretas de dados de memória para memória direta entre o servidor e o armazenamento. Ele exige uso mínimo de CPU e usa adaptadores de rede padrão compatíveis com RDMA. Isso proporciona respostas extremamente rápidas às solicitações de rede e, como resultado, coloca os tempos de resposta de armazenamento de arquivo remoto no mesmo nível que com armazenamento de bloco conectado diretamente.

Vantagens	Desvantagens
Maior taxa de transferência: Aproveita a taxa de transferência total de redes de alta velocidade onde os adaptadores de rede coordenam a transferência de grandes volumes de dados em velocidade da linha Baixa latência: Fornece respostas extremamente rápidas às solicitações de rede, fazendo com que o armazenamento de arquivo remoto pareça um armazenamento em bloco diretamente anexado Baixa utilização da CPU: Usa menos ciclos de CPU ao transferir dados pela rede, o que libera mais ciclos de CPU para as máquinas virtuais A migração dinâmica pode ser configurada para usar o SMB Direct para migrações dinâmicas mais rápidas. Habilitado por padrão no host O cliente SMB detecta e usa automaticamente várias conexões de rede se uma configuração apropriada for identificada Configure o gerenciamento de largura de banda do SMB para definir limites para migração dinâmica, máquinas virtuais e tráfego de armazenamento padrão O SMB Multichannel não requer suporte para adaptadores RDMA	Adaptadores de rede habilitados para RDMA não são compatíveis com o agrupamento NIC Requer dois ou mais adaptadores de rede RDMA implantado em cada host para fornecer alta disponibilidade Limitado atualmente aos seguintes tipos de adaptadores de rede: iWARP Infiniband RoCE RDMA com RoCE requer DCB para controle de fluxo.

Maior taxa de transferência: Aproveita a taxa de transferência total de redes de alta velocidade onde os adaptadores de rede coordenam a transferência de grandes volumes de dados em velocidade da linha
Baixa latência: Fornece respostas extremamente rápidas às solicitações de rede, fazendo com que o armazenamento de arquivo remoto pareça um armazenamento em bloco diretamente anexado
Baixa utilização da CPU: Usa menos ciclos de CPU ao transferir dados pela rede, o que libera mais ciclos de CPU para as máquinas virtuais
A migração dinâmica pode ser configurada para usar o SMB Direct para migrações dinâmicas mais rápidas.
Habilitado por padrão no host
O cliente SMB detecta e usa automaticamente várias conexões de rede se uma configuração apropriada for identificada
Configure o gerenciamento de largura de banda do SMB para definir limites para migração dinâmica, máquinas virtuais e tráfego de armazenamento padrão
O SMB Multichannel não requer suporte para adaptadores RDMA

Adaptadores de rede habilitados para RDMA não são compatíveis com o agrupamento NIC
Requer dois ou mais adaptadores de rede RDMA implantado em cada host para fornecer alta disponibilidade
Limitado atualmente aos seguintes tipos de adaptadores de rede:
- iWARP
- Infiniband
- RoCE
RDMA com RoCE requer DCB para controle de fluxo.

Receber a união de segmentos

receber união de segmentos (RSC) reduz a utilização de CPU para processamento de rede de entrada ao descarregar tarefas da CPU em um adaptador de rede compatível com RSC.

Vantagens	Desvantagens
Melhora a escalabilidade dos servidores, reduzindo a sobrecarga de processamento de uma grande quantidade de tráfego de rede Minimiza os ciclos de CPU que serão gasto no armazenamento em rede e migrações dinâmicas	Requer um adaptador de rede compatível com RSC Não fornece uma melhoria significativa para cargas de trabalho com uso intensivo de envio Não é compatível com o tráfego criptografado IPsec Aplica-se ao tráfego de host. Para aplicar a RSC ao tráfego de máquina virtual, esta deve estar executando o Windows Server 2012 R2 e configurada com um adaptador de rede SR-IOV. Não é habilitado por padrão nos servidores atualizados para o Windows Server 2012 R2

Melhora a escalabilidade dos servidores, reduzindo a sobrecarga de processamento de uma grande quantidade de tráfego de rede
Minimiza os ciclos de CPU que serão gasto no armazenamento em rede e migrações dinâmicas

Requer um adaptador de rede compatível com RSC
Não fornece uma melhoria significativa para cargas de trabalho com uso intensivo de envio
Não é compatível com o tráfego criptografado IPsec
Aplica-se ao tráfego de host. Para aplicar a RSC ao tráfego de máquina virtual, esta deve estar executando o Windows Server 2012 R2 e configurada com um adaptador de rede SR-IOV.
Não é habilitado por padrão nos servidores atualizados para o Windows Server 2012 R2

Receive Side Scaling

Receive-side scaling (RSS) permite que adaptadores de rede distribuam a carga de processamento de modo kernel da rede entre vários núcleos de processador em vários computadores de núcleo de rede ativa. A distribuição desse processamento torna possível dar suporte a cargas de tráfego de rede maiores que seria possível se apenas um único núcleo fosse usado. O RSS obtém isso espalhando a rede a carga de processamento em muitos processadores e ativamente a carga do tráfego de balanceamento que é encerrado, o protocolo TCP (Transmission Control).

Vantagens	Desvantagens
Espalha interrupções de monitoramento por vários processadores, portanto não é necessário um único processador para lidar com todas as interrupções de e/s, que eram comuns com versões anteriores do Windows Server. Funciona com agrupamento NIC Funciona com o tráfego do protocolo UDP (User Datagram)	Requer um adaptador de rede compatível com RSS Desabilitado se o adaptador de rede virtual for associado a um comutador virtual. O VMQ é usado em vez de RSS para adaptadores de rede associados a um comutador virtual.

SR-IOV

O Hyper-V oferece suporte a dispositivos de rede habilitados para SR-IOV e permite atribuir diretamente uma função virtual de SR-IOV de um adaptador de rede física para uma máquina virtual. Isso aumenta a taxa de transferência de rede, reduz a latência de rede e reduz o sobrecarga de CPU necessária para processar o tráfego de rede do host.

Para obter mais informações sobre SR-IOV, consulte a Tarefa 2b: Definir opções de desempenho de tráfego de rede acima.

Tarefa 2c: Definir a estratégia de tráfego alta disponibilidade e agregação de largura de banda

Esse recurso está disponível em fornecedores de adaptadores de rede. Apresentado no Windows Server 2012, o agrupamento NIC é incluído como um recurso do sistema operacional Windows Server.

O agrupamento NIC é compatível com todos os recursos de rede no Windows Server 2012 R2 com três exceções:

SR-IOV
RDMA
Autenticação 802.1X

De uma perspectiva de escalabilidade, no Windows Server 2012 R2, um mínimo de um e um máximo de 32 adaptadores de rede podem ser adicionados a uma única equipe. Um número ilimitado de equipes pode ser criado em um único host.

Informações adicionais:

Visão geral de agrupamento NIC

Microsoft Virtual Academy: agrupamento NIC no Windows Server 2012

Cmdlets do agrupamento NIC (NetLBFO) no Windows PowerShell

Implantação e gerenciamento do agrupamento NIC (LBFO) no Windows Server 2012 R2

Data Center convergido com o armazenamento de servidor de arquivos

Tarefa 2d: Definir a estratégia de segurança e isolamento do tráfego de rede

Cada tipo de tráfego de rede pode ter requisitos de segurança diferentes para funções, como isolamento e criptografia. A tabela a seguir explica as estratégias que podem ser usadas para atender aos vários requisitos de segurança.

Estratégia	Vantagens	Desvantagens
Criptografia (IPsec)	O tráfego é protegido para atravessar a rede	Impacto no desempenho para criptografar e descriptografar o tráfego Difícil de configurar, gerenciar e solucionar problemas Alterações de configuração do IPsec incorretas podem causar interrupções de rede ou tráfego pode não ser criptografado adequadamente
Redes físicas separadas	A rede é fisicamente separada	Requer que adaptadores de rede adicionais sejam instalados no host Se a rede exigir alta disponibilidade, dois ou mais adaptadores de rede são necessárias para cada rede.
Rede local virtual (VLAN)	Isola o tráfego usando uma ID de VLAN atribuído Suporte ao protocolo de truncamento VLAN Suporte para VLANs privadas Já é usado por muitos clientes corporativos	Limitado a 4094 VLANs e a maioria dos comutadores oferecem suporte a apenas 1.000 VLANs Requer configuração adicional e gerenciamento de equipamento de rede VLANs não podem abranger várias sub-redes de Ethernet, o que limita o número de nós em uma única VLAN e o posicionamento das máquinas virtuais, com base no local físico.

Tarefa 2e: Definir os adaptadores de rede virtual

Com uma compreensão dos tipos de tráfego necessários para os hosts do servidor de virtualização e desempenho, bem como a estratégia de desempenho, disponibilidade e segurança para o tráfego, você pode determinar quantos adaptadores de rede físicos são necessários para cada host e os tipos de tráfego de rede que serão transmitidas em cada adaptador.

Tarefa 2f: Definir comutadores virtuais

Para conectar uma máquina virtual a uma rede, você precisa conectar o adaptador de rede a um comutador virtual do Hyper-V.

Há três tipos de comutadores virtuais que podem ser criados no Hyper-v:

Comutador virtual externo

Use um comutador virtual externo para fornecer às máquinas virtuais o acesso a uma rede física para se comunicar com clientes e servidores externos. Esse tipo de comutador virtual também permite que máquinas virtuais no mesmo host se comuniquem entre si. Esse tipo de rede também está disponível para uso pelo sistema operacional do host, dependendo de como você configurar o sistema de rede.

Importante: Um adaptador de rede físico só pode ser associado a um comutador virtual por vez.
Comutador virtual interno

Use um comutador virtual interno para permitir a comunicação entre as máquinas virtuais no mesmo host e entre máquinas virtuais e o sistema operacional do host. Esse tipo de comutador virtual normalmente é usado para criar um ambiente de teste no qual você precisa se conectar às máquinas virtuais do sistema operacional do host. Um comutador virtual interno não está associado a um adaptador de rede física. Como resultado, uma rede virtual interna é isolada de tráfego de rede externo.
Comutador virtual privado

Use um comutador virtual privado quando você desejar permitir a comunicação somente entre máquinas virtuais no mesmo host. Um comutador virtual privado não está associado a um adaptador de rede física. Um comutador virtual privado é isolado de todo o tráfego de rede externo no servidor de virtualização e de qualquer tráfego de rede entre o sistema operacional do host e a rede externa. Esse tipo de rede é útil quando você precisa criar um ambiente isolado de rede, como um domínio de teste isolada.

Observação: Comutadores virtuais privados e internos não aproveitam os recursos de aceleração de hardware que estão disponíveis para uma máquina virtual que está conectada a um comutador virtual externo

Decisões de design - As decisões tomadas em todas as tarefas desta etapa podem ser inseridas nas planilhas de hosts de virtualização.

Dica: O nome de comutadores virtuais em diferentes hosts que se conectam à mesma rede deve ser o mesmo. Isso elimina a confusão sobre a qual comutador virtual uma máquina virtual deve estar conectada e simplifica a mudança de uma máquina virtual de um host para outro. O cmdlet do Windows PowerShell Move-VM falhará se o mesmo nome do comutador virtual não for encontrado no host de destino.

Tarefa 3: Definir a configuração de armazenamento

Além do armazenamento necessário para o sistema operacional host, cada host requer acesso ao armazenamento onde os arquivos de configuração da máquina virtual e discos rígidos virtuais são armazenados. Essa tarefa se concentrará no armazenamento de máquina virtual.

Tarefa 3a: Definir os tipos de dados

A seguir estão os tipos de dados de exemplo que você precisa considerar para os requisitos de armazenamento.

Tipo de dado	Local de armazenamento para o tipo de dado
Arquivos de sistema operacional do host	Normalmente, em um disco rígido local
Arquivo de paginação do host e despejos de memória no Windows	Normalmente, em um disco rígido local
Estado compartilhado de cluster de failover	Volume compartilhado do cluster ou do armazenamento de rede compartilhada
Arquivos de disco rígido virtual e arquivo de configuração de máquina virtual	Geralmente, no armazenamento de rede compartilhada ou volume compartilhado do cluster

O restante desta etapa é voltada para o armazenamento necessário para as máquinas virtuais.

Tarefa 3b: Opções de armazenamento

As seguintes opções estão disponíveis para armazenar os arquivos de configuração de máquina virtual e discos rígidos virtuais.

Opção 1: Armazenamento anexado direto

O armazenamento anexado direto se refere a um sistema de armazenamento do computador que está diretamente conectado ao seu servidor, em vez de ser anexado diretamente a uma rede. O armazenamento anexado direto não está limitado apenas ao armazenamento interno. Ele também pode usar um compartimento de disco externo que contém unidades de disco rígido, incluindo compartimentos JBOD e compartimentos conectados por meio de SAS ou outro controlador de disco.

Vantagens	Desvantagens
Não requer uma rede de armazenamento E/S de disco rápida, portanto, não é necessário que as solicitações de armazenamento trafeguem pela rede Pode ser um compartimento de disco externo, incluindo JBODs, ou de armazenamento interno Você pode usar JBOD com a tecnologia Espaços de Armazenamento para combinar todos os discos físicos em um pool de armazenamento e, em seguida, criar um ou mais discos virtuais (chamados de espaços de armazenamento) de espaço livre no pool. JBOD normalmente são menos caro e geralmente mais flexíveis e fáceis de gerenciar do que os compartimentos RAID porque eles usam os sistemas operacionais Windows ou Windows Server para gerenciar o armazenamento em vez de usar adaptadores RAID dedicados.	Número limitado de servidores que podem ser anexados ao compartimento de disco externo Apenas armazenamento compartilhado externo, como SAS compartilhado com espaços de armazenamento, oferece suporte para clustering de failover

Não requer uma rede de armazenamento
E/S de disco rápida, portanto, não é necessário que as solicitações de armazenamento trafeguem pela rede
Pode ser um compartimento de disco externo, incluindo JBODs, ou de armazenamento interno
Você pode usar JBOD com a tecnologia Espaços de Armazenamento para combinar todos os discos físicos em um pool de armazenamento e, em seguida, criar um ou mais discos virtuais (chamados de espaços de armazenamento) de espaço livre no pool.
JBOD normalmente são menos caro e geralmente mais flexíveis e fáceis de gerenciar do que os compartimentos RAID porque eles usam os sistemas operacionais Windows ou Windows Server para gerenciar o armazenamento em vez de usar adaptadores RAID dedicados.

Número limitado de servidores que podem ser anexados ao compartimento de disco externo
Apenas armazenamento compartilhado externo, como SAS compartilhado com espaços de armazenamento, oferece suporte para clustering de failover

Opção 2: NAS

Dispositivos NAS conectam o armazenamento a uma rede em que eles são acessados por meio de compartilhamentos de arquivos. Ao contrário do armazenamento anexado direto, eles não são diretamente conectados ao computador.

Os dispositivos NAS oferecem suporte a conexões Ethernet e normalmente permitem ao administrador gerenciar o espaço em disco, definir cotas de disco, fornecer segurança e usar as tecnologias de ponto de verificação. Dispositivos NAS oferecem suporte a vários protocolos. Eles incluem os sistemas de arquivos anexados à rede , Common Internet File Systems (CIFS) e Server Message Block (SMB).

Vantagens	Desvantagens
Mais simples de configurar que o armazenamento de SAN, exigindo menos hardware de armazenamento dedicado Plug and play Pode usar a rede Ethernet existente	Dispositivo NAs deve oferecer suporte a SMB 3.0 — não há suporte para CIFS Não é diretamente conectado aos servidores do host que estão acessando o armazenamento Mais lento do que outras opções Geralmente requerem uma rede dedicada para desempenho ideal Funcionalidade e gerenciamento limitado O Hyper-V oferece suporte a dispositivos NAS que oferecem suporte a SMB 3.0, o SMB 2.0 e CIFS não possuem suporte Pode ou não oferecer suporte a RDMA

Mais simples de configurar que o armazenamento de SAN, exigindo menos hardware de armazenamento dedicado
Plug and play
Pode usar a rede Ethernet existente

Dispositivo NAs deve oferecer suporte a SMB 3.0 — não há suporte para CIFS
Não é diretamente conectado aos servidores do host que estão acessando o armazenamento
Mais lento do que outras opções
Geralmente requerem uma rede dedicada para desempenho ideal
Funcionalidade e gerenciamento limitado
O Hyper-V oferece suporte a dispositivos NAS que oferecem suporte a SMB 3.0, o SMB 2.0 e CIFS não possuem suporte
Pode ou não oferecer suporte a RDMA

Opção 3: Rede de área de armazenamento

Uma rede de área de armazenamento (SAN) é uma rede dedicada que permite que você compartilhe o armazenamento. Uma SAN consiste em um dispositivo de armazenamento, interconexão de infraestrutura de rede (comutadores, adaptadores de barramento do host e cabeamento) e servidores que estão conectados à rede. Dispositivos SAN fornecem acesso contínuo e rápido a grandes quantidades de dados. O mecanismo de transferência de comunicação e os dados para uma determinada implantação é conhecido como uma malha de armazenamento.

Uma SAN usa uma rede separada, e geralmente não acessível por outros dispositivos na rede local. Uma SAN pode ser gerenciada usando Storage Management Initiative Specification (SMI-S), protocolo de gerenciamento de rede simples (SNMP) ou um protocolo de gerenciamento proprietário.

Uma SAN não fornece a abstração de arquivos, somente no nível de bloco operações. Os protocolos de SAN mais comuns usados são Fiber Channel, iSCSI e Fibre Channel over Ethernet (FCoE). Um SMI-S ou um protocolo de gerenciamento proprietário pode fornecer recursos adicionais, como gerenciamento de falhas, mapeamento de disco, mascaramento e zoneamento de disco.

Vantagens	Desvantagens
A SAN usa uma rede separada, para que haja impacto limitado na rede de dados Fornece acesso contínuo e rápido a grandes quantidades de dados Normalmente fornece recursos adicionais, como proteção de dados e replicação Pode ser compartilhado entre várias equipes Suporte para Fibre Channel virtual de acesso direto a LUNs de armazenamento Suporte para cluster convidado Máquinas virtuais que precisam acessar volumes de dados maiores que 64 TB podem usar Fibre Channel virtual para acesso direto ao LUN	Caro Exige habilidades especializadas para implantar, gerenciar e manter Adaptadores de rede HBA ou FCoE precisam ser instalado em cada host. Migrar um cluster Hyper-V requer planejamento adicional e tempo de inatividade limitado. Para fornecer gerenciamento de largura de banda para o tráfego FCoE, uma política de QoS que usa a ponte de datacenter de hardware é necessária. Tráfego de FCoE não é roteável.

A SAN usa uma rede separada, para que haja impacto limitado na rede de dados
Fornece acesso contínuo e rápido a grandes quantidades de dados
Normalmente fornece recursos adicionais, como proteção de dados e replicação
Pode ser compartilhado entre várias equipes
Suporte para Fibre Channel virtual de acesso direto a LUNs de armazenamento
Suporte para cluster convidado
Máquinas virtuais que precisam acessar volumes de dados maiores que 64 TB podem usar Fibre Channel virtual para acesso direto ao LUN

Caro
Exige habilidades especializadas para implantar, gerenciar e manter
Adaptadores de rede HBA ou FCoE precisam ser instalado em cada host.
Migrar um cluster Hyper-V requer planejamento adicional e tempo de inatividade limitado.
Para fornecer gerenciamento de largura de banda para o tráfego FCoE, uma política de QoS que usa a ponte de datacenter de hardware é necessária.
Tráfego de FCoE não é roteável.

Opção 4: Compartilhamentos de arquivos Server Message Block 3.0

O Hyper-V pode armazenar arquivos de máquina virtual, como arquivos de configuração, arquivos de disco rígido virtual e pontos de verificação, em compartilhamentos de arquivos que usam o protocolo SMB 3.0. Os compartilhamentos de arquivos normalmente estarão em um servidor de arquivos de expansão para fornecer redundância. Ao executar um servidor de arquivos de expansão, se um nó estiver inativo, os compartilhamentos de arquivos ainda estão disponíveis de outros nós no servidor de arquivos de expansão.

Vantagens	Desvantagens
Opção de usar protocolos e as redes existentes O SMB Multichannel fornece uma agregação de tolerância a falhas e de largura de banda da rede quando vários caminhos disponíveis entre o servidor que executa o Hyper-V e o compartilhamento de arquivos SMB 3.0. Você pode usar JBOD com a tecnologia Espaços de Armazenamento para combinar todos os discos físicos em um pool de armazenamento e, em seguida, criar um ou mais discos virtuais (chamados de espaços de armazenamento) de espaço livre no pool. O SMB Multichannel pode ser usado para migrações de máquina virtual. Menos dispendioso do que as implantações de SAN Configurações de armazenamento flexíveis no servidor de arquivos que executam o Windows Server Separa serviços do Hyper-V de serviços de armazenamento, que permite que você dimensione cada serviço conforme necessário Fornece flexibilidade ao atualizar para a versão seguinte ao executar um cluster de Hyper-V. Você pode atualizar os servidores que executam o Hyper-V ou servidores de arquivos de expansão em qualquer ordem, sem tempo de inatividade. Você precisará de capacidade suficiente no cluster para remover um ou dois nós para realizar a atualização. Servidor de arquivos de expansão fornece suporte para VHDX compartilhado O gerenciamento de largura de banda do SMB permite definir limites para migração dinâmica, o disco rígido virtual e o tráfego de armazenamento padrão. Suporte para criptografia de tráfego SMB com impacto mínimo sobre o desempenho Economize espaço em disco com eliminação de duplicação de dados para implantações de VDI Não exige habilidades especializadas para implantar, gerenciar e manter	Desempenho de E/S não é tão rápido como em implantações de SAN. Não há suporte para a eliminação de duplicação de dados na execução de arquivos de máquina virtual, exceto para implantações de VDI.

Opção de usar protocolos e as redes existentes
O SMB Multichannel fornece uma agregação de tolerância a falhas e de largura de banda da rede quando vários caminhos disponíveis entre o servidor que executa o Hyper-V e o compartilhamento de arquivos SMB 3.0.
Você pode usar JBOD com a tecnologia Espaços de Armazenamento para combinar todos os discos físicos em um pool de armazenamento e, em seguida, criar um ou mais discos virtuais (chamados de espaços de armazenamento) de espaço livre no pool.
O SMB Multichannel pode ser usado para migrações de máquina virtual.
Menos dispendioso do que as implantações de SAN
Configurações de armazenamento flexíveis no servidor de arquivos que executam o Windows Server
Separa serviços do Hyper-V de serviços de armazenamento, que permite que você dimensione cada serviço conforme necessário
Fornece flexibilidade ao atualizar para a versão seguinte ao executar um cluster de Hyper-V. Você pode atualizar os servidores que executam o Hyper-V ou servidores de arquivos de expansão em qualquer ordem, sem tempo de inatividade. Você precisará de capacidade suficiente no cluster para remover um ou dois nós para realizar a atualização.
Servidor de arquivos de expansão fornece suporte para VHDX compartilhado
O gerenciamento de largura de banda do SMB permite definir limites para migração dinâmica, o disco rígido virtual e o tráfego de armazenamento padrão.
Suporte para criptografia de tráfego SMB com impacto mínimo sobre o desempenho
Economize espaço em disco com eliminação de duplicação de dados para implantações de VDI
Não exige habilidades especializadas para implantar, gerenciar e manter

Desempenho de E/S não é tão rápido como em implantações de SAN.
Não há suporte para a eliminação de duplicação de dados na execução de arquivos de máquina virtual, exceto para implantações de VDI.

SMB Direct

O SMB Direct funciona como parte de compartilhamentos de arquivos SMB. O SMB Direct requer adaptadores de rede e comutadores que oferecem suporte a RDMA para proporcionar velocidade total acesso de armazenamento de baixa latência. O SMB Direct permite que os servidores de arquivos remoto se pareça com o armazenamento local e direta. Além dos benefícios do SMB, o SMB Direct tem as seguintes vantagens e desvantagens.

Vantagens	Desvantagens
Funções em velocidade máxima com latência baixa, usando muito pouco da CPU Permite que um servidor de arquivos de expansão forneça desempenho de armazenamento e a resiliência semelhante a uma SAN tradicional usando soluções de armazenamento da Microsoft e armazenamento compartilhado com conexão direta de baixo custo Fornece a opção mais rápida para migrações dinâmicas e migrações de armazenamento	Não tem suporte com o agrupamento NIC Dois ou mais adaptadores de rede habilitados para RDMA são necessários para conexões redundantes com o armazenamento.

Funções em velocidade máxima com latência baixa, usando muito pouco da CPU
Permite que um servidor de arquivos de expansão forneça desempenho de armazenamento e a resiliência semelhante a uma SAN tradicional usando soluções de armazenamento da Microsoft e armazenamento compartilhado com conexão direta de baixo custo
Fornece a opção mais rápida para migrações dinâmicas e migrações de armazenamento

Não tem suporte com o agrupamento NIC
Dois ou mais adaptadores de rede habilitados para RDMA são necessários para conexões redundantes com o armazenamento.

Expandir o servidor de arquivos

Figure 3:Exemplo de servidor de arquivos expandido que usa redes convergidas com o RDMA

Informações adicionais:

Fornecer armazenamento econômico para cargas de trabalho do Hyper-V usando o Windows Server

Data Center convergido com o armazenamento de servidor de arquivos

Implantar o Hyper-V no SMB

Obtendo mais de 1 milhão de IOPS de VMs do Hyper-V em um cluster de servidor de arquivos expandido usando o Windows Server 2012 R2

Tarefa 3c: Definir tipos de arquitetura do disco físico

O tipo de arquitetura de unidade física selecionada para seu armazenamento afetará o desempenho de sua solução de armazenamento. Para obter informações adicionais sobre os tipos de disco, consulte a Seção 7.1 de Arquitetura da linha de produto de Infraestrutura como um Serviço.

Tarefa 3d: Definir o tipo de rede de armazenamento

Os tipos de controlador de armazenamento ou de armazenamento de rede que você usar são determinados pela opção de armazenamento que você selecionar para cada grupo de hosts. Para obter mais informações, consulte a Tarefa 3b: Opções de armazenamento.

Tarefa 3e: Definir o tipo de armazenamento a ser usado para cada tipo de dado

Com uma compreensão dos seus tipos de dados, agora é possível determinar qual opção de armazenamento, o controlador de armazenamento, o controlador de rede de armazenamento e arquiteturas de disco físico melhor atendem às suas necessidades.

Decisões de design - As decisões tomadas nesta tarefa podem ser inseridas nas planilhas de hosts de virtualização.

Informações adicionais:

Configurações de rede para Hyper-V no SMB no Windows Server 2012 e Windows Server 2012 R2

Pôster de arquitetura de componentes e referências do guia do Windows Server 2012 Hyper-V

Visão geral de tecnologias de armazenamento

Tarefa 4: Definir unidades de escala de host de virtualização de servidor

Comprar servidores individuais requer aquisição, instalação e configuração para cada servidor. Dimensionar unidades permite adquirir coleções de servidores (que normalmente contêm hardware idêntico). Eles são pré-configurados, o que permite adicionar capacidade ao data center com a adição de unidades de escala e não com a adição de servidores individuais.

A imagem a seguir ilustra uma unidade de escala comprada pré-configurada de qualquer fornecedor de hardware. Ela inclui um rack, uma fonte de alimentação ininterrupta (no-break), um par redundante de comutadores de rede para os servidores contidos no rack e dez servidores.

Unidade de escala do host

Figure 4:Exemplo de unidade de dimensionamento de host do servidor de virtualização

A unidade de escala é fornecida pré-configurada e previamente cabeada para os comutadores de rede e no-break. A unidade simplesmente precisa ser adicionada a um datacenter, conectada à energia e à rede e armazenamento. Em seguida, ela estará pronta para ser usada. Se os componentes individuais não foram comprados como uma unidade dimensionada, o comprador precisaria organizar e conectar todos os componentes.

Decisão de design - Se você decidir usar unidades de dimensionamento de host de virtualização e servidor, defina o hardware das suas unidades na planilha de unidades de dimensionamento de host.

Dica: Você pode comprar as unidades de dimensionamento pré-configuradas em diversos parceiros de hardware da Microsoft por meio do programa Microsoft Private Cloud Fast Track.

Tarefa 5: Definir a estratégia de disponibilidade do host de virtualização de servidor

Hosts de servidor de virtualização podem ficar indisponíveis por razões planejadas (tais como manutenção) ou não planejadas. A seguir estão algumas estratégias que podem ser usadas para ambos os casos.

Planejado

Você pode usar a migração dinâmica para mover as máquinas virtuais de um host para outro. Isso não requer nenhum tempo de inatividade para máquinas virtuais.

Não planejado

Este cenário depende dos tipos de caracterização de cargas de trabalho que o host hospeda.

Para cargas de trabalho com monitoração de estado compartilhadas, use o Clustering de Failover em máquinas virtuais.
Para cargas de trabalho com monitoração de estado, execute como uma máquina virtual de alta disponibilidade em um cluster do Hyper-V.
Para cargas de trabalho sem monitoração de estado, inicie novas instâncias manualmente ou por automação.

Se você estiver usando o Clustering de Failover no Windows Server com o Hyper-V, considere usar os recursos listados na tabela a seguir. Para obter informações adicionais sobre cada recurso, clique no hiperlink.

Funcionalidade	Considerações
Monitoramento de aplicativos do Hyper-V	Monitore uma máquina virtual contra falhas na rede e armazenamento que não são monitorados pelo serviço de clustering de failover.
Configurações de prioridade de máquina virtual	Defina a prioridade de máquina virtual, com base na carga de trabalho. Você pode atribuir as seguintes configurações de prioridade às máquinas virtuais de alta disponibilidade (também conhecido como máquinas virtuais em cluster): Alta Médio (padrão) Baixa Não Iniciar Automaticamente Funções clusterizadas com prioridade mais alta são iniciadas e colocadas em nós antes daquelas com prioridade mais baixa. Se uma prioridade Não Iniciar Automaticamente for atribuída, a função não fica online automaticamente após uma falha, mantendo os recursos disponíveis para que outras funções possam começar.
Antiafinidade de máquina virtual	Definir a antiafinidade para máquinas virtuais que você não deseja executar no mesmo nó em um cluster Hyper-V. Isso pode ser para máquinas virtuais que fornecem serviços redundantes ou fazem parte do cluster de máquina virtual do convidado. Observação: Configurações de antiafinidade são configuradas por meio do Windows PowerShell.
Drenagem de nó automatizada	O cluster drena automaticamente um nó (move as funções de cluster que estão executando no nó para outro nó) antes de colocar o nó no modo de manutenção ou fazer outras alterações no nó. Funções realizam failback para o nó original após operações de manutenção. Os administradores podem drenar um nó com uma única ação no Gerenciador de Cluster de Failover ou usando o cmdlet do Windows PowerShell Suspend-ClusterNode. O nó de destino para as funções clusterizadas movidas pode ser especificado. Atualização com suporte a cluster usa a drenagem de nó no processo automatizado para aplicar atualizações de software a nós do cluster.
Atualização com suporte a cluster	A atualização com suporte a cluster permite que você atualize nós em um cluster sem afetar as máquinas virtuais em execução no cluster. Um número suficiente de nós de cluster deve permanecer disponível durante o processo de atualização para lidar com a carga das máquinas virtuais em execução.
Preempção de máquinas virtuais baseada em prioridade	Outro motivo para definir a prioridade de máquina virtual é que o serviço de cluster pode deixar offline uma VM de prioridade inferior quando uma máquina virtual de alta prioridade não tem a memória necessária e outros recursos para começar. A preempção inicia com a máquina de prioridade mais baixa e continua a máquinas virtuais com prioridade mais altas. Máquinas virtuais com preempção são reiniciadas depois em ordem de prioridade.

Observação: Clusters do Hyper-V podem ter um máximo de 64 nós e 8.000 máquinas virtuais.

Etapa 5: Planejar conceitos de arquitetura da malha de virtualização

Esta etapa requer a definição de conceitos lógicos aos quais a arquitetura de malha será alinhada.

Tarefa 1: Definir domínios de manutenção

Domínios de manutenção são coleções lógicas de servidores que são atendidas juntas. A manutenção pode incluir atualizações de hardware ou software, ou alterações de configuração. Domínios de manutenção normalmente abrangem grupos de hosts de cada tipo ou dentro de cada local, embora não seja necessário. A finalidade é impedir que a manutenção do servidor comprometa cargas de trabalho dos consumidores.

Observação: Esse conceito se aplica aos componentes de rede e armazenamento físicos.

Tarefa 2: Definir domínios de falha física

Grupos de hosts de servidores de virtualização falham juntos com frequência como resultado de um componente de infraestrutura compartilhado com falha, como um comutador de rede ou a fonte de alimentação ininterrupta (no-break). Domínios de falha física ajudam a dar suporte à resiliência dentro da malha de virtualização. É importante entender como um domínio de falha afeta cada um dos grupos de hosts que você definiu para a malha.

Observação: Esse conceito se aplica aos componentes de rede e armazenamento físicos.

Considere o exemplo na imagem a seguir, no que sobrepõe manutenção e domínios de falha física em uma coleção de grupos em um data center de hosts.

Domínio de falha

Figure 5:Exemplo de uma definição domínio de falha física e de manutenção

Neste exemplo, cada rack de servidores é definido como um domínio de falha física separada, numerado. Isso ocorre porque cada rack contém um comutador de rede na parte superior e no-break na parte inferior. Todos os servidores em rack contam com esses dois componentes e, se alguma falhar, todos os servidores em rack efetivamente falham.

Como todos os servidores em um rack também são membros de grupos de host exclusivo, esse design significa que não há nenhuma atenuação em caso de falha de qualquer um dos domínios de falha física. Para atenuar os problemas, você pode adicionar domínios de falha física de cada tipo de grupo de host. Em ambientes de menor escala, você poderia adicionar comutadores redundantes e fontes de alimentação em cada rack ou usar o Clustering de Failover para hosts de servidor de virtualização em domínios de falha física.

Na Figura 5, cada uma das caixas coloridas tracejada define um domínio de manutenção (denominados MD 1 a 5). Observe como cada um dos servidores no cluster de balanceamento de carga de máquinas virtuais está hospedado em um host de virtualização de servidor que contido em um domínio separado de manutenção e um domínio de falha física separado.

Isso permite que o administrador de malha desative todos os hosts do servidor de virtualização dentro de um domínio de manutenção sem afetar significativamente aplicativos que têm vários servidores distribuídos entre domínios de manutenção. Isso também significa que o aplicativo em execução no cluster de balanceamento de carga não estará completamente indisponível se um domínio de falha física falhar.

Decisão de design - As decisões tomadas em todas nas tarefas 1 e 2 podem ser inseridas na planilha de Configurações.

Tarefa 3: Definir a capacidade de reserva

A falha dos servidores individuais na malha é inevitável. O design de malha precisa acomodar falhas de servidores individual, bem como acomodar falhas de coleções de servidores em domínios de falha e manutenção. A ilustração a seguir é o mesmo que a Figura 5, mas utiliza vermelho para identificar os três servidores com falha.

Servidores com falha

Figure 6:Servidores com falha

Na Figura 6, os hosts de virtualização de servidor falharam nas seguintes grupos de hosts, domínios de manutenção e domínios de falha física.

Grupo de hosts	Domínio de falha física	Domínio de manutenção
2	2	3
3	3	2
4	4	2

O aplicativo em execução no cluster de balanceamento de carga ainda está disponível, mesmo que o host no domínio de falha física 2 falhou, mas o aplicativo funcionará com um terço a menos de capacidade.

Considere o que aconteceria se o host de virtualização de servidor hospedado em uma das máquinas virtuais no domínio de falha física 3 também falhou, ou se o domínio de manutenção 2 foi desativado para manutenção. Nesses casos, a capacidade do aplicativo poderia diminuir em 2/3.

Você pode decidir que isso é inaceitável para sua malha de virtualização. Para atenuar o impacto da falha nos servidores, você pode garantir que cada um dos seu domínios de falha física e domínios de manutenção tenha capacidade suficiente de reserva para que capacidade nunca fique abaixo do nível aceitável que você definir.

Para obter mais informações sobre como calcular a capacidade de reserva, consulte Capacidade de reserva em Arquitetura de referência do Microsoft Cloud Services Foundation – Princípios, conceitos e padrões.

Etapa 6: Planejar as características de capacidade inicial

Depois de concluir todas as tarefas neste documento, você poderá determinar os custos iniciais para hospedar máquinas virtuais e armazenamento na malha, além dos níveis de qualidade de serviço inicial que a malha poderá atender. Você não conseguirá concluir essas tarefas, contudo, até implementar suas ferramentas de gerenciamento de malha e recursos humanos, que são discutidas na seção Próximas etapas deste documento.

Tarefa 1: Definir as métricas de SLA iniciais para armazenamento e máquinas virtuais

Como um administrador de malha, você provavelmente definirá um contrato de nível de serviço (SLA) que detalha as métricas de qualidade de serviço que a malha cumpre. Os administradores de máquina virtual precisarão conhecer o SLA para planejar como usarão a malha.

No mínimo, isso provavelmente incluirá uma métrica de disponibilidade, mas também pode incluir outras métricas. Para obter uma ideia de uma linha de base para as métricas do SLA da malha de virtualização, você pode analisar as métricas oferecidas por provedores de nuvem pública, como o Microsoft Azure. Para hospedagem de máquinas virtuais, esse SLA garante que quando um cliente implantar duas ou mais instâncias de uma máquina virtual com a mesma carga de trabalho e implantá-las em diferente domínios de falha e atualização (conhecidos como "domínios de manutenção" neste documento), pelo menos uma das máquinas virtuais estará disponível 99,95% do tempo.

Para ver uma descrição completa do SLA do Azure, consulte Contratos de Nível de Serviço. O ideal é que sua malha de virtualização atenda ou exceda os provedores de nuvem pública.

Tarefa 2: Definir os custos iniciais para hospedar o armazenamento e máquinas virtuais

Com sua malha projetada, você também poderá calcular:

Os custos de hardware, espaço, energia e resfriamento da malha
A capacidade de hospedagem da malha

Essas informações, combinadas com os outros custos, tal como o custo das suas ferramentas de gerenciamento de malha e recursos humanos, ajudarão a determinar o custo final para hospedar máquinas virtuais e armazenamento.

Para obter uma ideia dos custos da linha de base para máquinas virtuais e armazenamento, você pode examinar os custos de hospedagem de provedores de nuvem pública, como o Microsoft Azure. Para obter mais informações, consulte Detalhes de preços de máquinas virtuais.

Embora nem sempre seja o caso, você geralmente verá que os custos de hospedagem são maiores que os dos provedores públicos porque sua malha será muito menor do que as malhas que grandes provedores públicos são capazes de atingir, obtendo descontos por volume em hardware, espaço no datacenter e energia.

Próximas etapas

Depois de concluir todas as tarefas neste documento, você terá um design de malha que atende aos requisitos da sua organização. Você também terá uma definição de característica de serviço inicial que inclui os custos e as métricas de nível de serviço. Você não poderá determinar suas métricas de nível de serviço e custos finais até determinar os custos de recursos humanos e as ferramentas de gerenciamento, bem como os processos que você usará para sua estrutura.

O Microsoft System Center 2012 fornece um conjunto abrangente de funcionalidades para permitir que você provisione, monitore e mantenha sua malha de virtualização. Você pode aprender mais sobre como usar o System Center para gerenciar a malha lendo os seguintes recursos:

Biblioteca de documentação técnica do System Center

Guia de arquitetura de gerenciamento de malha