Guia de Considerações de Design dos Recursos de Infraestrutura de Virtualização

Artigo
10/25/2015

Este guia destina-se a quem? Profissionais de tecnologias de informação (TI) em médias e grandes empresas, responsáveis pela conceção de uma infraestrutura de virtualização que suporte várias máquinas virtuais. Doravante, estes indivíduos são designados por administradores da infraestrutura. As pessoas que administram as máquinas virtuais alojadas nos recursos de infraestrutura são designadas por administradores de máquinas virtuais, mas não são o público-alvo deste documento. Dentro da organização, poderá ser responsável por ambas as funções.

De que forma este guia pode ser útil? Pode utilizar este guia para saber como estruturar uma infraestrutura de virtualização com capacidade para alojar várias máquinas virtuais na sua organização. Neste documento, a coleção de servidores e hipervisores, bem como o hardware de rede e de armazenamento utilizado para alojar as máquinas virtuais numa organização, é designada por recursos de infraestrutura de virtualização. O gráfico seguinte mostra um exemplo de recursos de infraestrutura de virtualização.

Recursos de infraestrutura de virtualização

Figura 1:Exemplo de recursos de infraestrutura de virtualização

Nota: cada um dos diagramas contidos neste documento existe num separador à parte do documento Virtualization Fabric Design Considerations Diagrams (Diagramas de Considerações de Design da Infraestrutura de Virtualização), que poderá transferir ao clicar no nome da figura na legenda de cada tabela.

Embora todos os recursos de infraestrutura de virtualização contenham servidores para armazenamento e alojamento de máquinas virtuais, para além das redes que os ligam, é provável que, devido aos diferentes requisitos, o design dos recursos de infraestrutura de virtualização de cada organização seja diferente do exemplo ilustrado na Figura 1.

Este guia descreve em detalhe uma série de passos e tarefas que poderá seguir para estruturar uma infraestrutura de virtualização que preencha os requisitos exclusivos da sua organização. Ao longo dos passos e das tarefas, o guia apresenta as tecnologias relevantes e as opções de funcionalidades disponíveis para o cumprimento de requisitos funcionais e de qualidade de serviço (como disponibilidade, escalabilidade, desempenho, capacidade de gestão e segurança).

Embora este documento possa ajudá-lo a estruturar uma infraestrutura de virtualização gerível, não aborda considerações de design nem opções para a gestão e operação dos recursos da infraestrutura de virtualização com um produto como, por exemplo, o Microsoft System Center 2012 ou o System Center 2012 R2. Para obter mais informações, consulte System Center 2012 na biblioteca TechNet.

Este guia ajuda-o a conceber uma infraestrutura de virtualização com o Windows Server 2012 R2 e o Windows Server 2012 e hardware livre de fornecedor. Algumas funcionalidades descritas no documento são exclusivas do Windows Server 2012 R2 e estão indicadas ao longo do documento.

Pressupostos: Tem alguma experiência na implementação de Hyper-V, máquinas virtuais, redes virtuais, serviços de ficheiros do Windows Server e Clustering de Ativação Pós-falha, e alguma experiência na implementação de servidores físicos, armazenamento e equipamentos de rede.

Recursos adicionais

Antes de conceber uma infraestrutura de virtualização, poderá considerar as informações nos seguintes documentos úteis:

Ambos os documentos fornecem conceitos básicos observados em vários designs de infraestruturas de virtualização e podem servir como base para qualquer design de infraestrutura de virtualização.

Comentários: Para enviar comentários sobre este documento, envie um e-mail para virtua@microsoft.com.

Descrição geral das considerações de design

O resto deste documento disponibiliza um conjunto de passos e tarefas que poderá seguir para conceber uma infraestrutura de virtualização mais adequada aos seus requisitos. Os passos são apresentados numa sequência ordenada. No entanto, as considerações de design que aprender em passos posteriores podem implicar uma alteração das decisões que tomou em passos anteriores, devido a conflitos. Contudo, tentaremos ao máximo alertá-lo para potenciais conflitos de design ao longo do documento.

Apenas conseguirá obter o design mais adequado aos seus requisitos depois de repetir os passos as vezes necessárias para incorporar todas as considerações no documento.

Passo 1: Determinar os requisitos de recursos das máquinas virtuais

Passo 2: Planear a configuração das máquinas virtuais

Passo 3: Planear grupos de anfitriões de virtualização de servidor

Passo 4: Planear anfitriões de virtualização de servidor

Passo 5: Planear conceitos de arquitetura da infraestrutura de virtualização

Passo 6: Planear as características de capacidade inicial

Passo 1: Determinar os requisitos de recursos das máquinas virtuais

O primeiro passo na conceção de uma infraestrutura de virtualização consiste em determinar os requisitos de recursos das máquinas virtuais que a infraestrutura irá alojar. A infraestrutura tem de incluir o hardware físico necessário para preencher esses requisitos. Os requisitos de recursos das máquinas virtuais são estipulados pelos sistemas operativos e pelas aplicações em execução nas máquinas virtuais. Ao longo do resto do documento, a combinação do sistema operativo e das aplicações executados numa máquina virtual é designada por carga de trabalho. As tarefas deste passo ajudam-no a definir os requisitos de recursos das cargas de trabalho.

Sugestão: Em vez de avaliar os requisitos de recursos das cargas de trabalho existentes e, em seguida, conceber uma infraestrutura de virtualização que consiga suportar cada uma delas, poderá optar por conceber uma infraestrutura de virtualização que possa responder às necessidades das cargas de trabalho mais comuns. Em seguida, avalie em separado as cargas de trabalho que têm necessidades próprias.

Alguns exemplos de recursos de infraestrutura de virtualização são os disponibilizados pelos fornecedores de nuvem pública, como o Microsoft Azure (Azure). Para obter mais informações, consulte Virtual Machine and Cloud Service Sizes for Azure (Tamanhos de Máquinas Virtuais e Serviços em Nuvem para o Azure).

Normalmente, os fornecedores de nuvem pública oferecem uma seleção de configurações de máquinas virtuais que respondem às necessidades da maioria das cargas de trabalho. Se optar por adotar esta abordagem, pode avançar diretamente para o Passo 2: Planear a configuração das máquinas virtuais deste documento. Vantagens adicionais de utilizar esta abordagem:

Se decidir migrar algumas das máquinas virtuais no local para um fornecedor de nuvem pública, a migração será mais fácil caso os tipos de configuração dessas máquinas virtuais sejam semelhantes aos do fornecedor público do que se forem diferentes.
Poderá permitir que preveja mais facilmente os requisitos de capacidade e ative uma capacidade de aprovisionamento de gestão personalizada para a infraestrutura de virtualização. Isto significa que os administradores de máquinas virtuais na organização podem aprovisionar automaticamente máquinas virtuais novas sem o envolvimento dos administradores da infraestrutura.

Tarefa 1: Determinar os requisitos de recursos das cargas de trabalho

Cada carga de trabalho tem requisitos para os seguintes recursos. A primeira coisa que deverá fazer é responder às seguintes perguntas para cada uma das cargas de trabalho.

Processador: Qual é a velocidade de processador ou a arquitetura (Intel ou AMD) ou o número de processadores necessários?
Rede: Em gigabits por segundo (Gbps), qual é a largura de banda de rede necessária para o tráfego de entrada e de saída? Qual é a quantidade máxima de latência de rede que a carga de trabalho consegue tolerar para funcionar corretamente?
Armazenamento: De quantos gigabytes (GB) de armazenamento precisam os ficheiros de aplicações e do sistema operativo da carga de trabalho? De quantos GB de armazenamento precisa a carga de trabalho para os respetivos dados? De quantas operações de entrada/saída por segundo (IOPS) precisa a carga de trabalho para o respetivo armazenamento?
Memória: Em gigabytes (GB), de que quantidade de memória a carga de trabalho precisa? A carga de trabalho tem suporte de NUMA (Non-Uniform Memory Access)?

Para além de compreender os requisitos de recursos anteriores, também é importante determinar:

Se os requisitos de recursos são mínimos ou recomendados.
Quais são os requisitos máximos e médios de cada um dos requisitos de hardware numa base horária, diária, semanal, mensal ou anual.
O número de minutos de indisponibilidade por mês aceitáveis para a carga de trabalho e para os dados da carga de trabalho. Ao determinar este aspeto, tenha em consideração o seguinte:
- A carga de trabalho é executada apenas numa máquina virtual ou é executada numa coleção de máquinas virtuais que funcionam como uma só, como, por exemplo, uma coleção de servidores com balanceamento de carga de rede, todos eles executados na mesma carga de trabalho? Se estiver a utilizar uma coleção de servidores, o período de indisponibilidade indicado deve ser claro em relação ao facto de ser aplicável a cada servidor na coleção, a todos os servidores na coleção ou ao nível da coleção.
- Horas de trabalho e horas de descanso. Por exemplo, se ninguém for utilizar a carga de trabalho entre as 21:00 e as 6:00, mas for crucial que esteja disponível a maior quantidade de tempo possível entre as 6:00 e as 21:00, com um período de indisponibilidade aceitável por mês de apenas dez minutos, este requisito deve ser especificado.
A quantidade de dados perdidos aceitáveis na eventualidade de uma falha inesperada da infraestrutura virtual. Este valor é expresso em minutos porque as estratégias de replicação de infraestrutura são, normalmente, baseadas no tempo. Embora a ausência de perda de dados seja, muitas vezes, expressa como requisito, tenha em conta que o preenchimento deste requisito consegue-se, em muitos casos, a um preço muito alto e poderá provocar igualmente um desempenho inferior.
Se os ficheiros da carga de trabalho e/ou os respetivos dados têm de ser encriptados em disco e se estes dados têm de ser encriptados entre as máquinas virtuais e os respetivos utilizadores finais.

As seguintes opções estão disponíveis para determinar os requisitos de recursos anteriores.

Opção	Vantagens	Desvantagens
Avaliar e registar manualmente a utilização de recursos	Capacidade para gerar relatórios sobre o que quer que escolha	Pode exigir um esforço manual significativo
Utilizar o Microsoft Assessment and Planning Toolkit para avaliar e registar automaticamente a utilização de recursos	Cria uma panóplia de relatórios de utilização de recursos Não requer a instalação de um agente na carga de trabalho	Os relatórios podem ou não fornecer todos os dados de que precisa

Nota: Se optar por determinar os requisitos de recursos manualmente, pode transferir o documento Virtualization Fabric Design Considerations Guide Worksheets (Folhas de Cálculo do Guia de Considerações de Conceção de Recursos de Infraestrutura de Virtualização) e introduzir as informações na folha de cálculo de requisitos de recursos da carga de trabalho. Este guia faz referência a folhas de cálculo específicas nesse documento.

Tarefa 2: Definir caracterizações de cargas de trabalho

Pode definir qualquer número de caracterizações de cargas de trabalho no seu ambiente. Os exemplos seguintes foram selecionados porque cada um deles requer uma configuração diferente dos componentes da infraestrutura de virtualização, que serão abordados mais detidamente em passos posteriores.

Sem monitorização de estado: não escrevem qualquer informação exclusiva no disco rígido local depois de serem inicialmente aprovisionadas e de lhes serem atribuídos nomes de computador e endereços de rede exclusivos. No entanto, podem escrever informações exclusivas em armazenamento separado, como uma base de dados. As cargas de trabalho sem monitorização de estado são ideais para serem executadas numa infraestrutura de virtualização, uma vez que pode ser criada uma imagem “original” para a máquina virtual. Esta imagem pode ser facilmente copiada e arrancada na infraestrutura de virtualização para adicionar dimensionamento à carga de trabalho ou para substituir rapidamente uma máquina virtual que fique indisponível, na eventualidade de uma falha no anfitrião de virtualização. Um exemplo de uma carga de trabalho sem monitorização de estado é um servidor Web que execute uma aplicação Web de front-end.
Com monitorização de estado: escrevem informações exclusivas no disco rígido local depois de serem inicialmente aprovisionadas e de lhes serem atribuídos nomes de computador e endereços de rede exclusivos. Também podem escrever informações exclusivas em armazenamento separado, como uma base de dados. Geralmente, as cargas de trabalho com monitorização de estado requerem estratégias de aprovisionamento e dimensionamento mais complexas do que as cargas de trabalho sem monitorização de estado. As estratégias de elevada disponibilidade para cargas de trabalho com monitorização de estado podem requerer um estado partilhado com outras máquinas virtuais. Um exemplo de uma carga de trabalho com monitorização de estado é o Motor de Base de Dados do SQL Server.
Com monitorização de estado partilhado: cargas de trabalho com monitorização de estado que requerem algum estado partilhado com outras máquinas virtuais. Estas cargas de trabalho utilizam, muitas vezes, o Clustering de Ativação Pós-falha no Windows Server para alcançarem elevada disponibilidade, o que requer acesso a armazenamento partilhado. Um exemplo de uma carga de trabalho com monitorização de estado partilhado é o Microsoft System Center – Virtual Machine Manager.
Outro: caracteriza as cargas de trabalho que não podem ser executadas de todo ou não ser executadas de forma ideal numa infraestrutura de virtualização. Os atributos destas cargas de trabalho consistem no facto de precisarem de:
- Acesso a periféricos físicos. Um exemplo de uma aplicação deste tipo é uma carga de trabalho de telefonia que comunique com um adaptador de rede de telefonia num anfitrião físico.
- Requisitos de recursos muito mais elevados do que a maioria das restantes cargas de trabalho. Um exemplo é uma aplicação em tempo real que requer uma latência de menos de um milissegundo entre camadas da aplicação.
Estas aplicações podem ou não ser executadas na infraestrutura de virtualização ou podem necessitar de hardware muito específico ou de configuração que não seja partilhada pela maioria das restantes cargas de trabalho.

Nota: pode definir as caracterizações da carga de trabalho na folha de cálculo Settings (Definições) e, em seguida, selecionar a caracterização apropriada para cada carga de trabalho na folha de cálculo Workload resource req. (Requisitos de recursos de cargas de trabalho).

Passo 2: Planear a configuração das máquinas virtuais

Neste passo, irá definir os tipos de máquinas virtuais de que vai precisar para preencher os requisitos de recursos e caracterizações das cargas de trabalho definidas no Passo 1.

Tarefa 1: Definir a configuração informática

Nesta tarefa, vai determinar a quantidade de memória e de processadores de que cada máquina virtual precisa.

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

O Windows Server 2012 R2 introduziu as máquinas virtuais de geração 2. As máquinas virtuais de geração 2 suportam hardware e funcionalidades de virtualização que não são suportadas nas máquinas virtuais de geração 1. É importante tomar a decisão certa em relação aos seus requisitos, porque não é possível alterar o tipo de uma máquina virtual após esta ser criada.

As máquinas virtuais de geração 2 oferecem as seguintes funcionalidades novas:

Arranque PXE através de um adaptador de rede padrão
Arranque a partir de um disco rígido virtual SCSI
Arranque a partir de um DVD virtual SCSI
Arranque Seguro (ativado por predefinição)
Suporte de firmware UEFI

As máquinas virtuais de geração 2 suportam os seguintes sistemas operativos 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íficos de Linux. Para obter uma lista da distribuição e das versões que suportam máquinas virtuais de geração 2, consulte Linux Virtual Machines on Hyper-V (Máquinas Virtuais Linux no Hyper-V).

A tabela seguinte apresenta as vantagens e desvantagens das máquinas virtuais de geração 1 e de geração 2.

Opção	Vantagens	Desvantagens
Geração 1	Suporta todos os sistemas operativos convidados Hyper-V suportados Fornece compatibilidade com máquinas virtuais do Azure Suporta as versões anteriores do Hyper-V	Sem acesso às novas funcionalidades de máquinas virtuais
Geração 2	Suporta as novas funcionalidades Proporciona um ligeiro melhoramento no arranque de máquinas virtuais e nos tempos de instalação de convidados Utiliza dispositivos SCSI ou um adaptador de rede padrão para efetuar o arranque das máquinas virtuais Impede a execução de firmware, de sistemas operativos ou de controladores UEFI não autorizados quando o Arranque Seguro está ativado	Suporte limitado de sistemas operativos convidados Não compatível com máquinas virtuais do Azure Sem suporte de RemoteFX Sem suporte de disquete virtual

Importante: as máquinas virtuais Linux de geração 2 não suportam o Arranque Seguro. Quando cria uma máquina virtual e pretender instalar o Linux, tem de desativar o Arranque Seguro nas definições da máquina virtual.

Informações adicionais:

Descrição Geral de Máquinas Virtuais de Geração 2

Tarefa 1b: Definir a memória

Deve planear o tamanho da memória da máquina virtual, tal como faz normalmente para aplicações de servidor num computador físico. Esta deve fazer face, de forma razoável, à carga esperada em horas normais e em horas de ponta. Uma memória insuficiente pode aumentar significativamente os tempos de resposta e a utilização da CPU ou de E/S.

Memória Estática e Memória Dinâmica

A memória estática é a quantidade de memória atribuída à máquina virtual. É sempre alocada quando a máquina virtual é iniciada e não é alterada quando esta está em execução. A totalidade da memória é atribuída à máquina virtual durante o arranque e a memória que não está a ser utilizada pela máquina virtual não está disponível para outras máquinas virtuais. Se não existir memória suficiente disponível no anfitrião para alocar à máquina virtual quando é iniciada, esta não será iniciada.

A memória estática é vantajosa para cargas de trabalho que consomem muita memória e para cargas de trabalho que tenham os seus próprios sistemas de gestão de memória, como o SQL Server. Estes tipos de cargas de trabalho terão um desempenho superior com uma memória estática.

Nota: não existe qualquer definição para ativar a memória estática. Esta é ativada quando a definição Memória Dinâmica não está ativada.

A Memória Dinâmica permite utilizar de forma mais eficaz a memória física num sistema ao balancear a memória física total em várias máquinas virtuais, alocar mais memória a máquinas virtuais que estejam lotadas e ao remover memória em máquinas virtuais com menos utilização. Isto pode levar a taxas de consolidação mais elevadas, sobretudo em ambientes dinâmicos, como na Infraestrutura de Ambiente de Trabalho Virtual (VDI) ou em servidores Web.

Ao utilizar uma memória estática, se forem atribuídos 10 GB de memória a uma máquina virtual e esta estiver a utilizar apenas 3 GB, os restantes 7 GB de memória não estarão disponíveis para serem utilizados por outras máquinas virtuais. Se a máquina virtual tiver a Memória Dinâmica ativada, utiliza apenas a quantidade de memória necessária, mas nunca abaixo da RAM mínima configurada. Isto permite libertar mais memória para outras máquinas virtuais.

A tabela que se segue apresenta as vantagens e desvantagens da memória estática e da Memória Dinâmica.

Opção	Vantagens	Desvantagens
Memória estática	Fornece sempre a memória configurada disponível às máquinas virtuais Proporciona um desempenho superior Pode ser utilizada com NUMA virtual	A memória que não está a ser utilizada por uma máquina virtual não pode ser alocada a outra máquina virtual. As máquinas virtuais não serão iniciadas se não existir memória disponível suficiente.
Memória Dinâmica	Proporciona densidade de máquina virtual melhorada quando é executada em cargas de trabalho inativas ou com pouca carga Permite alocar memória que não está a ser utilizada, para que possa ser utilizada por outras máquinas virtuais	É possível exceder a memória configurada. É necessário overhead adicional para gerir as alocações de memória. Não é compatível com NUMA virtual. Não é compatível com cargas de trabalho que implementem os seus próprios gestores de memória.

A seguir, são apresentadas as definições de configuração da memória:

RAM de Arranque: especifica a quantidade de memória necessária para iniciar a máquina virtual. O valor tem de ser suficientemente alto para permitir o início do sistema operativo convidado, mas deve ser o mais baixo possível para permitir uma utilização de memória ideal e taxas de consolidação potencialmente mais altas.
RAM Mínima: especifica a quantidade mínima de memória que deve ser alocada à máquina virtual depois de esta ser iniciada. O valor pode ser definido como tão baixo como 32 MB até um valor mínimo igual ao valor de RAM de Arranque. Esta definição só está disponível se a Memória Dinâmica estiver ativada.
RAM Máxima: especifica a quantidade máxima de memória que esta máquina virtual pode utilizar. O valor pode ser definido como um valor tão baixo como o valor da RAM de Arranque até um máximo de 1 TB. No entanto, a máquina virtual só pode utilizar uma quantidade de memória igual à quantidade máxima suportada pelo sistema operativo convidado. Por exemplo, se especificar 64 GB para uma máquina virtual com um sistema operativo convidado que suporte um máximo de 32 GB, a máquina virtual não poderá utilizar mais do que 32 GB. Esta definição só está disponível se a Memória Dinâmica estiver ativada.
Peso da memória: Fornece ao Hyper-V uma forma de determinar como distribuir a memória entre máquinas virtuais, caso não exista memória física suficiente disponível no anfitrião para atribuir a todas as máquinas virtuais a quantidade de memória que solicitaram. As máquinas virtuais com um peso de memória superior têm precedência sobre as máquinas virtuais com pesos de memória inferiores.

Notas:

Não é possível utilizar as funcionalidades Memória Dinâmica e NUMA virtual em simultâneo. Uma máquina virtual que tenha a Memória Dinâmica ativada de forma eficaz tem apenas um nó NUMA virtual e não é apresentada qualquer topologia NUMA à máquina virtual, independentemente das definições de NUMA virtual.
Ao instalar ou atualizar o sistema operativo de uma máquina virtual, a quantidade de memória que está disponível para a máquina virtual durante o processo de instalação e atualização corresponde ao valor especificado como RAM de Arranque. Mesmo que a Memória Dinâmica tenha sido configurada na máquina virtual, esta utiliza apenas a quantidade de memória que está configurada na definição RAM de Arranque. Certifique-se de que o valor de RAM de Arranque preenche os requisitos mínimos de memória do sistema operativo durante os procedimentos de instalação e atualização.
O sistema operativo convidado executado na máquina virtual tem de suportar a Memória Dinâmica.
As aplicações de bases de dados complexas, como o SQL Server ou o Exchange Server, implementam os seus próprios gestores 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:

Descrição Geral da Memória Dinâmica

Tarefa 1c: Definir o processador

Para configurar máquinas virtuais, as definições de configuração que se seguem têm de ser determinadas:

Determinar o número de processadores necessários para cada máquina virtual. Este número é, muitas vezes, igual ao número de processadores de que a carga de trabalho precisa. O Hyper-V suporta um máximo de 64 processadores virtuais por máquina virtual.
Determinar o controlo de recursos para cada máquina virtual. É possível definir limites para garantir que nenhuma máquina virtual consiga monopolizar os recursos de processador do anfitrião de virtualização.
Definir uma topologia NUMA. Para cargas de trabalho com suporte para NUMA de elevado desempenho, pode especificar o número máximo de processadores, a quantidade de memória permitida num nó NUMA virtual único e o número máximo de nós permitidos num socket de processador único. Para obter mais informações, consulte Descrição Geral da Arquitetura NUMA Virtual do Hyper-V.

Nota: não é possível utilizar NUMA virtual e Memória Dinâmica ao mesmo tempo. Ao decidir se deve utilizar a Memória Dinâmica ou NUMA, responda às seguintes perguntas. Se a resposta a ambas as perguntas for afirmativa, ative o NUMA virtual e não ative a Memória Dinâmica.

A carga de trabalho que está a ser executada na máquina virtual tem suporte para NUMA?
A máquina virtual irá consumir mais recursos, processadores ou memória do que os que estão disponíveis num único nó NUMA físico?

Tarefa 1d: Definir os sistemas operativos suportados

Tem de confirmar se o sistema operativo de que a carga de trabalho precisa é suportado como sistema operativo 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 informações sobre as distribuições Linux suportadas, consulte Linux Virtual Machines on Hyper-V (Máquinas Virtuais Linux no Hyper-V).

Nota: o Hyper-V inclui um pacote de software para sistemas operativos convidados suportados, 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 controladores de software é designada por serviços de integração. Para obter o melhor desempenho, as máquinas virtuais devem executar os serviços de integração mais recentes.

Licenciamento

Tem de se certificar de que os sistemas operativos convidados estão devidamente licenciados. Reveja a documentação do fornecedor relativamente a requisitos de licenciamento específicos quando estiver a executar um ambiente virtualizado.

A Ativação Automática de Máquina Virtual (Automatic Virtual Machine Activation, AVMA) é uma funcionalidade introduzida 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 durante o arranque. Isto elimina a necessidade de introduzir informações de licenciamento e ativar cada máquina virtual individualmente.

A AVMA requer que o anfitrião execute o Windows Server 2012 R2 Datacenter e que o sistema operativo convidado da máquina virtual seja o Windows Server 2012 R2 Datacenter, o Windows Server 2012 R2 Standard ou o Windows Server 2012 R2 Essentials.

Nota: é necessário configurar a funcionalidade AVMA em cada anfitrião implementado na infraestrutura de virtualização.

Informações adicionais:

Ativação Automática de Máquina Virtual

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

A estratégia de nomenclatura do computador existente poderá indicar onde o computador ou servidor está localizado fisicamente. As máquinas virtuais podem passar de anfitrião para anfitrião, e inclusivamente de centro de dados diferentes, pelo que a estratégia de nomenclatura existente poderá deixar de ser aplicável. Atualizar a convenção de nomenclatura existente, para indicar que o computador está a ser executado como uma máquina virtual, pode ajudar a determinar o local onde a máquina virtual está a ser executada.

Tarefa 2: Definir a configuração de rede

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

As máquinas virtuais de geração 1 podem ter um máximo de 12 adaptadores de rede — quatro adaptadores de rede legados e oito adaptadores de rede virtuais. As máquinas virtuais de geração 2 não suportam adaptadores de rede legados, pelo que o número máximo de adaptadores suportado é oito.

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

Cada máquina virtual irá enviar e receber diferentes tipos de dados, como, por exemplo:

Dados de aplicação
Cópia de segurança de dados
Comunicações com computadores cliente, servidores ou serviços
Comunicação intracluster, caso a carga de trabalho faça parte de um cluster de ativação pós-falha da máquina virtual convidada
Suporte
Armazenamento

Se já tiver redes dedicadas a diferentes tipos de tráfego de rede, poderá optar por utilizar essas redes para esta tarefa. Se estiver a definir novos designs de rede para suportar a infraestrutura de virtualização, pode definir os tipos de tráfego de rede que cada máquina virtual irá suportar.

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

Cada tipo de tráfego de rede tem requisitos máximos de largura de banda e mínimos de latência. A tabela que se segue mostra as estratégias que podem ser utilizadas para preencher diferentes requisitos de desempenho de rede.

Estratégia	Vantagens	Desvantagens
Separação de tipos de tráfego para adaptadores de rede físicos diferentes	Separa o tráfego, de forma a que não seja partilhado por outros tipos de tráfego	Têm de ser instalados adaptadores de rede físicos distintos no anfitrião para cada tipo de tráfego de rede. É necessário hardware adicional para cada rede que precise de elevada disponibilidade de rede. Não se dimensiona bem com um grande número de redes.
Gestão de largura de banda do Hyper-V (Hyper-V QoS)	Proporciona QoS para tráfego de rede virtual Aplicar largura de banda mínima e largura de banda máxima a um fluxo de tráfego, que é identificado por um número de porta de Comutador Virtual de Hyper-V. Configurar largura de banda mínima e largura de banda máxima por porta de comutador virtual de Hyper-V através de cmdlets do PowerShell ou WMI (Windows Management Instrumentation). Configurar vários adaptadores de rede virtuais no Hyper-V e especificar QoS em cada um deles individualmente. Fornece um suplemento à política QoS para a rede física.	O QoS de software e o QoS de hardware não devem ser utilizados ao mesmo tempo no mesmo adaptador de rede. É necessário planear adequadamente a política QoS para a rede e o Hyper-V, de forma a que não se substituam entre si. Quando definir o modo da qualidade de serviço para um comutador virtual, aquele não pode ser alterado. Não é possível migrar máquinas virtuais para um anfitrião com um comutador virtual que esteja definido para utilizar um modo QoS diferente. A migração será bloqueada quando não for possível cumprir os valores absolutos configurados para uma máquina virtual.
SR-IOV	Fornece a latência de rede mais baixa à máquina virtual Fornece a E/S de rede mais alta à máquina virtual Reduz a sobrecarga da CPU necessária para as redes virtuais	São necessários um controlador e um adaptador de rede com capacidade SR-IOV no anfitrião e em cada máquina virtual à qual tenha sido atribuída uma função virtual. Os adaptadores de rede virtuais com SR-IOV ativado não podem fazer parte da Equipa NIC no anfitrião. Para elevada disponibilidade de rede, têm de estar instalados dois ou mais adaptadores de rede SR-IOV no anfitrião e o Agrupamento NIC tem de estar configurado na máquina virtual. O SR-IOV só deve ser utilizado por cargas de trabalho fidedignas, porque o tráfego ignora o comutador Hyper-V e tem acesso direto ao adaptador de rede físico. A configuração de ACLs de porta de comutador virtual, de QoS de Hyper-V, da Proteção de Router e da Proteção de DHCP impedirá a utilização do SR-IOV. O SR-IOV não é suportado em máquinas virtuais executadas no Azure.
Virtual receive-side scaling (Dimensionamento do lado da receção virtual)	Suporta o dimensionamento do lado da receção virtual, que permite que as máquinas virtuais distribuam carga de processamento de rede por vários processadores virtuais (vCPUs), para aumentar o débito de rede nas máquinas virtuais Disponibiliza compatibilidade com: Agrupamento NIC Migração em direto NVGRE	O dimensionamento do lado da receção virtual requer que o adaptador de rede físico suporte a Fila de Máquina Virtual (Virtual Machine Queue, VMQ) e tem de estar ativado no anfitrião. Não compatível com adaptadores de rede virtuais com SR-IOV ativado. As máquinas virtuais têm de executar o Windows Server 2012 R2 ou o Windows 8.1. Desativado por predefinição se o adaptador de VMQ for inferior a 10 Gbps.
Frames Jumbo	Permitem a transferência de mais dados em cada transação Ethernet, reduzindo o número de frames que é necessário transmitir Utilizados normalmente para a comunicação com o armazenamento, mas podem ser utilizados para todos os tipos de comunicação Reduzem a sobrecarga nas máquinas virtuais, no equipamento de rede e no servidor final para o qual os dados estão a ser enviados Configurados para comunicação num centro de dados, onde poderá controlar as definições de unidade máxima de transmissão (Maximum Transmission Unit, MTU) em todos os saltos	Fornecem uma probabilidade de deteção de erros ligeiramente inferior. Cada dispositivo de rede ao longo do caminho tem de suportar Frames Jumbo e tem de ser configurado com a mesma definição de MTU ou superior. Utilize o comando Ping para verificar as definições de MTU ponto a ponto. Se um salto ao longo do caminho não suportar Frames Jumbo ou estiver configurado com uma MTU mais pequena, os pacotes serão ignorados.

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

O Agrupamento NIC, também designado por balanceamento de carga e ativação pós-falha (Load Balancing and Failover, LBFO), permite colocar vários adaptadores de rede numa equipa para fins de agregação de largura de banda e de ativação pós-falha de tráfego. Isto mantém a conectividade na eventualidade de uma falha nos componentes de rede. Regra geral, o agrupamento NIC é configurado no anfitrião e, quando criar o comutador virtual, é vinculado à equipa de adaptadores de rede.

Os comutadores de rede implementados determinam o modo do Agrupamento NIC. As predefinições no Windows Server 2012 R2 devem ser suficientes para a maioria das implementações.

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

Informações adicionais:

Descrição Geral do Agrupamento NIC

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

Cada tipo de tráfego de rede pode ter diferentes requisitos de segurança, como, por exemplo, requisitos relacionados com isolamento e encriptação. A tabela seguinte explica as estratégias que podem ser utilizadas para preencher diversos requisitos de segurança.

Estratégia	Vantagens	Desvantagens
Separação em diferentes adaptadores de rede	Separar o tráfego de outro tráfego de rede	Não dimensiona bem. Quanto mais redes tiver, mais adaptadores de rede terá de instalar e gerir no anfitrião.
IPsec com Descarga de Tarefas IPsec	Suporta a descarga de IPsec para encriptação do tráfego de rede de e para máquinas virtuais com Hyper-V Encripta o tráfego enquanto atravessa a rede	A configuração é complexa Pode dificultar a resolução de problemas, uma vez que não é possível abrir o tráfego de e para os anfitriões e máquinas virtuais Maior utilização do processador quando os adaptadores de rede físicos no anfitrião não suportam a descarga de IPsec
Marcação de VLAN	Já utilizada pela maioria das empresas Compatível com políticas QoS Suporta VLANs Privadas Suporta o modo de ramal de VLAN em máquinas virtuais Reduz o número de adaptadores físicos que têm de ser instalados no anfitrião	Limitada a 4094 VLANs É necessária a configuração de comutadores, anfitriões e máquinas virtuais Alterações incorretas às definições de configuração de VLAN podem originar problemas de rede específicos do servidor ou problemas ao nível da rede
Virtualização de Rede Hyper-V	Fornece posicionamento flexível de cargas de trabalho, incluindo isolamento de rede e reutilização de endereços IP sem VLANs Permite uma movimentação mais fácil de cargas de trabalho para a nuvem Suporta a migração em direto entre sub-redes, sem ser necessário injetar um endereço IP novo no servidor novo Permite soluções de rede multi-inquilino Oferece um design de rede simplificado e proporciona uma utilização otimizada dos recursos de rede e de servidor. Normalmente, a rigidez das VLANs com a dependência de colocação de máquinas virtuais numa infraestrutura de rede física resulta no sobreaprovisionamento e na subutilização.	A gestão da Virtualização de Rede Hyper-V requer o System Center 2012 R2 - Virtual Machine Manager ou uma solução de gestão que não seja da Microsoft. É necessário um gateway de Virtualização de Rede Hyper-V para permitir a comunicação fora da rede virtual.
Proteção de DHCP	Impede a máquina virtual de fazer ofertas DHCP através da rede virtual Configurada individualmente em cada 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 ativada
Proteção de Router	Bloqueia os seguintes pacotes: ICMPv4 Tipo 5 (mensagem de redirecionamento) ICMPv4 Tipo 9 (anúncio do router) ICMPv6 Tipo 134 (anúncio do router) ICMPv6 Tipo 137 (mensagem de redirecionamento) Configurada individualmente em cada adaptador de rede virtual	Impacto mínimo no desempenho quando ativada

Decisão de design - pode transferir o documento Virtualization Fabric Design Considerations Guide Worksheets (Folhas de Cálculo do Guia de Considerações de Design da Infraestrutura de Virtualização) e alterar os dados de exemplo na folha de cálculo Virtual machine configs. (Configurações de máquinas virtuais), para capturar as decisões que tomou relativamente a todas as tarefas anteriores deste passo. Quanto às decisões de design subsequentes, este documento faz referência a folhas de cálculo específicas neste guia e nas quais poderá introduzir os seus dados.

Tarefa 2e: Definir adaptadores de rede virtuais

Tendo conhecimento dos tipos de tráfego necessários para as máquinas virtuais, para além das estratégias de desempenho, disponibilidade e segurança do tráfego, poderá determinar o número de adaptadores de rede virtuais de que cada máquina virtual irá precisar.

Um adaptador de rede virtual está ligado a um comutador virtual. Existem três tipos de comutadores virtuais:

Comutador virtual externo
Comutador virtual interno
Comutador virtual privado

O comutador virtual externo proporciona à máquina virtual acesso à rede física através do adaptador de rede que está associado ao comutador virtual ao qual está ligado. Um adaptador de rede físico no anfitrião só pode ser associado a um único comutador externo.

Se pretender atribuir o tráfego da máquina virtual a VLANs diferentes, é necessário instalar um adaptador de rede que suporte VLANs no anfitrião e atribuí-lo ao comutador virtual. Pode definir o ID de VLAN da máquina virtual nas propriedades da máquina virtual. O ID de VLAN definido no comutador virtual é o ID de VLAN que será dado ao adaptador de rede virtual atribuído ao sistema operativo anfitrião.

Nota: se tiver uma máquina virtual que necessite de acesso a mais redes do que os adaptadores disponíveis, pode ativar o modo de ramal de VLAN num adaptador de rede de máquina através do cmdlet Set-VMNetworkAdapterVlan do Windows PowerShell.

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

É necessário determinar de que forma vai atribuir endereços IP às máquinas virtuais. Se não o fizer, poderá ter conflitos de endereços IP, que podem ter um impacto negativo noutras máquinas virtuais e dispositivos físicos na rede.

Além disso, os servidores DHCP não autorizados podem provocar estragos na infraestrutura de rede e podem ser particularmente difíceis de identificar quando o servidor está a ser executado como máquina virtual. Pode proteger a rede contra servidores DHCP não autorizados em execução numa máquina virtual, ativando a Proteção de DHCP nas definições das máquinas virtuais. A Proteção de DHCP oferece proteção contra máquinas virtuais maliciosas que se representem como um servidor DHCP em ataques man-in-the-middle.

Informações adicionais:

Dynamic Host Configuration Protocol (DHCP) Overview (Descrição Geral do Protocolo DHCP [Dynamic Host Configuration Protocol])

Proteção de DHCP

Descrição Geral da Gestão de Endereços IP (IPAM)

Tarefa 3: Definir a configuração do armazenamento

Para determinar a configuração do armazenamento, tem de definir os tipos de dados que as máquinas virtuais vão armazenar e o tipo de armazenamento de que necessitam.

Tarefa 3a: Definir os tipos de dados

A tabela seguinte apresenta os tipos de dados que as máquinas virtuais poderão ter de armazenar e o local onde aqueles são, muitas vezes, armazenados.

Tipo de dados	Localização do armazenamento do tipo de dados
Ficheiros do sistema operativo	Dentro de um ficheiro de disco rígido virtual que é armazenado pelo anfitrião de virtualização. As considerações de armazenamento do anfitrião de virtualização são abordadas adiante, no Passo 4: Plano para anfitriões de virtualização de servidor abaixo.
Ficheiro de paginação do Windows	Geralmente, armazenado na mesma localização que os ficheiros do sistema operativo.
Ficheiros de programa de aplicações	Geralmente, armazenados na mesma localização que os ficheiros do sistema operativo.
Dados de configuração de aplicação	Geralmente, armazenados na mesma localização que os ficheiros do sistema operativo.
Dados de aplicação	Geralmente, armazenados à parte dos ficheiros de aplicação e do sistema operativo. Por exemplo, se a aplicação for uma aplicação de bases de dados, os ficheiros das bases de dados são, muitas vezes, armazenados numa solução de armazenamento baseada na rede, eficiente e de elevada disponibilidade, que está separada da localização onde os ficheiros de programa de aplicação ou do sistema operativo estão armazenados.
Volumes Partilhados em Cluster (Clustered Shared Volumes, CSV) e testemunho de disco (necessário para clustering de máquinas virtuais convidadas)	Geralmente, armazenados à parte dos ficheiros de aplicação e do sistema operativo. O armazenamento CSV é o local onde as aplicações em cluster armazenam os dados, de modo a que fiquem disponíveis para todos os nós no cluster. Um testemunho de disco é um disco no armazenamento de cluster que é designado para guardar uma cópia da base de dados de configuração do cluster. Um cluster de ativação pós-falha só tem um testemunho de disco se este for especificado como parte da configuração do quórum.
Ficheiros de informação de falha de sistema	Geralmente, armazenados na mesma localização que os ficheiros do sistema operativo.

Tarefa 3b: Definir os tipos de armazenamento

A tabela seguinte apresenta os tipos de armazenamento que poderão ser utilizados para os tipos de dados definidos no Passo 2, Tarefa 2a, acima.

Tipo de armazenamento	Considerações
Disco IDE virtual	Máquinas virtuais de geração 1: Dois controladores IDE e cada controlador pode suportar um máximo de dois dispositivos IDE para um máximo de quatro dispositivos IDE. O disco de arranque tem de estar ligado a um dos dispositivos IDE como um disco rígido virtual ou um disco físico. As máquinas virtuais de geração 2 não suportam dispositivos IDE.
SCSI virtual	São suportados quatro controladores SCSI virtuais, sendo que cada controlador suporta até 64 dispositivos para um total de 256 dispositivos SCSI. Uma vez que as máquinas virtuais de geração 2 apenas suportam uma unidade SCSI, suportam discos de arranque SCSI.
Iniciador iSCSI na máquina virtual	Tire partido do armazenamento em SANs sem instalar adaptadores de Canal de Fibra no anfitrião. Não pode ser utilizado no disco de arranque. Utilize políticas QoS para garantir a disponibilidade de largura de banda adequada para armazenamento e outro tráfego de rede. Não compatível com Réplica do Hyper-V. Se utilizar um back-end de armazenamento de SAN, utilize as opções de replicação de SAN fornecidas pelo seu fornecedor de armazenamento.
Canal de Fibra Virtual	Requer um ou mais adaptadores de barramento anfitrião (Host Bus Adapters, HBAs) do Canal de Fibra ou adaptadores de rede de convergência Canal de Fibra por Ethernet (Fibre Channel over Ethernet, FCoE) em cada anfitrião que vai alojar máquinas virtuais com adaptadores de Canal de Fibra virtuais. Os controladores HBA e FCoE têm de suportar Canal de Fibra virtual. Uma SAN com NPIV ativado. Requer configuração adicional para suportar a migração em direto. Para obter informações adicionais sobre a migração em direto e o Canal de Fibra Virtual, consulte Hyper-V Virtual Fibre Channel Overview (Descrição Geral do Canal de Fibra Virtual do Hyper-V). Não compatível com Réplica do Hyper-V. Se utilizar o armazenamento de SAN, deve utilizar as opções de replicação de SAN fornecidas pelo seu fornecedor de armazenamento. As máquinas virtuais podem ter um máximo de quatro portas virtuais. Os LUNs de Canal de Fibra Virtual não podem ser utilizados como suporte de dados de arranque para a máquina virtual.
SMB 3.0	Aceda a ficheiros armazenados em partilhas SMB (Server Message Block) 3.0 a partir da máquina virtual.

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

Se estiver a utilizar o tipo de armazenamento de disco rígido virtual, terá de selecionar primeiro o formato VHD que vai utilizar a partir das opções apresentadas na tabela seguinte.

Formato de disco	Vantagens	Desvantagens
VHD	Suportado por todas as versões do Hyper-V Suportado pelas implementações no local e no Azure	A capacidade máxima de armazenamento é de 2040 GB O tamanho máximo do disco rígido virtual suportado pelo Azure é 1 TB Não suportado por máquinas virtuais de geração 2
VHDX	A capacidade máxima de armazenamento é de 64 terabytes (TB) Proteção contra danos em dados em caso de falha de energia Alinhamento melhorado do formato do disco rígido virtual, para funcionar melhor em discos de setor grande Um disco virtual de setor lógico de 4 KB que permite um desempenho superior quando utilizado por aplicações e cargas de trabalho concebidas para setores de 4 KB Pode ser utilizado como armazenamento partilhado para máquinas virtuais que necessitem de Clustering de Ativação Pós-falha	Atualmente, não é suportado pelas máquinas virtuais no Azure Não pode ser utilizado com versões do Hyper-V anteriores ao Windows Server 2012
VHDX Partilhado	Utilizado para armazenamento partilhado para clusters de máquinas virtuais convidadas	Requer o Windows Server 2012 R2 no anfitrião com o Hyper-V em execução Os sistemas operativos convidados suportados para clusters convidados que utilizem um disco rígido virtual partilhado incluem o Windows Server 2012 R2 e o Windows Server 2012. Para suportar o Windows Server 2012 como sistema operativo convidado, é necessário instalar os Serviços de Integração do Windows Server 2012 R2 no convidado (máquina virtual). As funcionalidades seguintes não são compatíveis com VHDX partilhado: Réplica do Hyper-V Redimensionamento do disco rígido virtual enquanto qualquer uma das máquinas virtuais configuradas estiver em execução Migração direta do armazenamento Cópias de segurança VSS ao nível do anfitrião. As cópias de segurança ao nível do convidado devem ser efetuadas através dos mesmos métodos que utilizaria num cluster executado em servidores físicos. Pontos de verificação de máquina virtual QoS de armazenamento

Em seguida, selecione o tipo de disco que vai utilizar a partir das opções apresentadas na tabela seguinte.

Tipo de disco	Vantagens	Desvantagens
Fixo	Menor probabilidade de sofrer de fragmentação do que outros tipos de discos Menor sobrecarga da CPU do que outros tipos de discos Depois de o ficheiro de VHD ser criado, a preocupação relativamente ao espaço em disco disponível é menor do que o que acontece com outros tipos de discos Suportado pelas implementações no local e no Azure	Um disco rígido virtual criado requer que todo o espaço esteja disponível, mesmo que a máquina virtual não esteja a utilizar todo o espaço. O disco rígido virtual não será ciado se não existir espaço de armazenamento disponível. O espaço não utilizado no disco rígido virtual não pode ser alocado a outros discos rígidos virtuais.
Dinâmico	Utiliza o espaço em disco necessário apenas, em vez de utilizar todo o espaço aprovisionado	Atualmente, não é suportado pelo Azure, embora os discos dinâmicos possam ser convertidos em discos fixos Ao utilizar discos rígidos dinâmicos, é importante monitorizar o espaço em disco livre. Se não existir espaço em disco disponível para que um disco rígido virtual dinâmico seja aumentado, a máquina virtual entrará num estado crítico em pausa. O ficheiro do disco rígido virtual pode ficar fragmentado Sobrecarga da CPU ligeiramente superior para operações de leitura e escrita do que a registada no tipo de disco fixo
Diferenciação	Pode utilizar menos espaço em disco se vários discos de diferenciação utilizarem o mesmo disco principal	Atualmente, não é suportado pelo Azure As alterações efetuadas a um disco principal podem provocar inconsistências nos dados no disco subordinado Sobrecarga da CPU ligeiramente inferior para operações de leitura e escrita de cargas de trabalho com utilização de E/S muito intensiva

Tenha em consideração o seguinte quando selecionar o tipo e o formato de ficheiro de disco rígido virtual:

Ao utilizar o formato VHDX, pode utilizar um disco dinâmico, porque este oferece garantias de resiliência, para além de otimizações de espaço que estão associadas ao facto de o espaço ser alocado apenas quando existe necessidade de o fazer.
Também pode ser utilizado um disco fixo, independentemente do formato, quando o armazenamento no volume de alojamento não é monitorizado ativamente. Isto garante que existe espaço em disco suficiente quando o ficheiro VHD é expandido em tempo de execução.
Os pontos de verificação (anteriormente designados por instantâneos) de uma máquina virtual criam um disco rígido virtual de diferenciação para armazenar escritas nos discos. Ter apenas alguns pontos de verificação pode elevar a utilização da CPU de E/S de armazenamento, mas estes podem não afetar o desempenho de modo percetível (exceto em cargas de trabalho de servidor extremamente intensas em termos de E/S).

Contudo, ter uma grande cadeia de pontos de verificação pode afetar de modo percetível o desempenho, porque a leitura a partir de discos rígidos virtuais pode necessitar de verificação para os blocos pedidos em muitos discos de diferenciação. A manutenção de cadeias de pontos de verificação curtas é importante para manter o bom desempenho de E/S do disco.

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

Depois de definir os tipos de dados e os tipos de armazenamento que as máquinas virtuais irão armazenar, pode determinar o tipo de armazenamento e o tipo de formato de disco virtual a utilizar para cada tipo de dados.

Tarefa 4: Definir a estratégia de disponibilidade das máquinas virtuais

Embora os administradores dos recursos de infraestrutura sejam responsáveis pela disponibilidade dos recursos de infraestrutura, os administradores de máquinas virtuais são, em última análise, responsáveis pela disponibilidade das respetivas máquinas virtuais. Consequentemente, o administrador de máquinas virtuais tem de compreender as capacidades da infraestrutura para conceber a estratégia de disponibilidade apropriada para as máquinas virtuais.

As tabelas que se seguem analisam três estratégias de disponibilidade para máquinas virtuais que executam cargas de trabalho com as caracterizações definidas no Passo 1, Tarefa 2, acima. Normalmente, o administrador dos recursos de infraestrutura informa antecipadamente os administradores de máquinas virtuais quando são agendadas atividades com períodos de indisponibilidade planeados para a infraestrutura, de modo a que estes possam planear em conformidade. As três estratégias de disponibilidade são:

Sem monitorização de estado
Com monitorização de estado
Com monitorização de estado partilhado

Sem monitorização de estado

Opção	Considerações
Virtual Machine Live Migration (Migração em Direto de uma Máquina Virtual) ao nível do anfitrião	Se for necessário desligar um anfitrião no âmbito de uma manutenção planeada, as máquinas virtuais em execução podem ser migradas para um anfitrião operável sem período de indisponibilidade das máquinas virtuais. Para obter mais informações sobre as considerações de anfitrião, consulte o Tarefa 5: Definir a estratégia de disponibilidade do anfitrião de virtualização de servidor abaixo. Se as máquinas virtuais não estiverem armazenadas num armazenamento acessível por ambos os anfitriões, terá de mover o armazenamento de máquinas virtuais durante uma migração em direto. Se ocorrer uma falha inesperada num anfitrião, todas as máquinas virtuais em execução nesse anfitrião deixam de funcionar. É necessário executar a mesma carga de trabalho noutro anfitrião para iniciar as máquinas virtuais.
Clusters com balanceamento de carga (ao utilizar Balanceamento de Carga de Rede do Windows)	Requer que o administrador de máquinas virtuais tenha, pelo menos, duas máquinas virtuais que executem uma carga de trabalho idêntica alojada em diferentes anfitriões. O Balanceamento de Carga de Rede (Network Load Balancing, NLB) é configurado nas máquinas virtuais pelo administrador de máquinas virtuais. O NLB requer a atribuição de endereços IP estáticos aos adaptadores de rede. A atribuição de endereços DHCP não é suportada. O administrador de máquinas virtuais tem de trabalhar com o administrador dos recursos de infraestrutura para obter os endereços IP a utilizar no IP virtual de NLB e para criar a entrada DNS necessária. Ative o spoofing de MAC na rede virtual utilizada pelo NLB nos anfitriões. Este procedimento pode ser efetuado a partir das definições do Adaptador de Rede em cada máquina virtual que participe num cluster NLB como um nó. Pode criar clusters NLB, adicionar nós e atualizar configurações de cluster NLB sem reiniciar as máquinas virtuais. Todas as máquinas virtuais que participem no cluster NLB têm de estar na mesma sub-rede. Para garantir a disponibilidade da carga de trabalho (mesmo em caso de falha do anfitrião), o administrador dos recursos de infraestrutura de máquinas virtuais precisa de garantir que as máquinas virtuais estão a ser executadas em anfitriões diferentes.
Clusters com balanceamento de carga (ao utilizar um balanceador de carga de hardware)	Esta capacidade tem de ser fornecida ao nível da infraestrutura e os administradores dos recursos de infraestrutura têm de configurar os clusters com balanceamento de carga para as máquinas virtuais que precisem da mesma. Em alternativa, podem permitir que os administradores de máquinas virtuais o configurem através do portal de gestão do balanceador de carga de hardware. Requer que o administrador de máquinas virtuais tenha, pelo menos, duas máquinas virtuais que executem uma carga de trabalho idêntica alojada na infraestrutura. Consulte a documentação do produto do fornecedor de hardware para obter mais informações.

Com monitorização de estado

Opção	Considerações
Cluster Hyper-V	Requer a configuração de um cluster de ativação pós-falha. Requer armazenamento partilhado entre todos os nós no cluster para os ficheiros CSV. Pode ser armazenamento SAN ou uma partilha de ficheiros SMB 3.0. Quando o cluster deteta um problema num anfitrião ou o Hyper-V deteta um problema no armazenamento ou nas redes da máquina virtual, esta pode ser movida para outro anfitrião. A máquina virtual continua a ser executada durante a mudança. Se existir uma falha catastrófica de um anfitrião, as máquinas virtuais que estavam a ser executadas nesse anfitrião podem ser iniciadas noutros nós do cluster. É possível configurar as máquinas virtuais vitais para serem iniciadas automaticamente. Isto limita a quantidade de tempo de indisponibilidade na eventualidade de existir uma falha catastrófica do anfitrião. Corrija os anfitriões sem afetar as máquinas virtuais em execução com a Atualização com Suporte para Clusters. Configure a antiafinidade de máquinas virtuais para evitar a execução de máquinas virtuais no mesmo nó. Por exemplo, se estiver a executar dois servidores Web que fornecem serviços front-end para uma aplicação back-end, não é útil executá-los a ambos no mesmo nó. É possível colocar um nó no modo de manutenção e o serviço de cluster de ativação pós-falha irá mover as máquinas virtuais em execução para outro nó do cluster. A manutenção necessária pode ser executada quando não existem máquinas virtuais no nó. O cluster de ativação pós-falha não irá 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 existe capacidade suficiente nos outros nós do cluster Hyper-V para executar as máquinas virtuais existentes e continuar a manter os SLAs para os seus clientes.

Cluster Hyper-V

Requer a configuração de um cluster de ativação pós-falha.
Requer armazenamento partilhado entre todos os nós no cluster para os ficheiros CSV. Pode ser armazenamento SAN ou uma partilha de ficheiros SMB 3.0.
Quando o cluster deteta um problema num anfitrião ou o Hyper-V deteta um problema no armazenamento ou nas redes da máquina virtual, esta pode ser movida para outro anfitrião. A máquina virtual continua a ser executada durante a mudança.
Se existir uma falha catastrófica de um anfitrião, as máquinas virtuais que estavam a ser executadas nesse anfitrião podem ser iniciadas noutros nós do cluster. É possível configurar as máquinas virtuais vitais para serem iniciadas automaticamente. Isto limita a quantidade de tempo de indisponibilidade na eventualidade de existir uma falha catastrófica do anfitrião.
Corrija os anfitriões sem afetar as máquinas virtuais em execução com a Atualização com Suporte para Clusters.
Configure a antiafinidade de máquinas virtuais para evitar a execução de máquinas virtuais no mesmo nó. Por exemplo, se estiver a executar dois servidores Web que fornecem serviços front-end para uma aplicação back-end, não é útil executá-los a ambos no mesmo nó.
É possível colocar um nó no modo de manutenção e o serviço de cluster de ativação pós-falha irá mover as máquinas virtuais em execução para outro nó do cluster. A manutenção necessária pode ser executada quando não existem máquinas virtuais no nó.

O cluster de ativação pós-falha não irá 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 existe capacidade suficiente nos outros nós do cluster Hyper-V para executar as máquinas virtuais existentes e continuar a manter os SLAs para os seus clientes.

Com monitorização de estado partilhado

Ao executar cargas de trabalho com suporte para clusters, pode proporcionar uma camada adicional de disponibilidade ao ativar o clustering de convidados de máquinas virtuais. O clustering de convidados suporta elevada disponibilidade de cargas de trabalho na máquina virtual. O clustering de convidados oferece proteção à carga de trabalho que está a ser executada nas máquinas virtuais, mesmo que um anfitrião falhe no local onde a máquina virtual está a ser executada. Uma vez que a carga de trabalho foi protegida pelo Clustering de Ativação Pós-falha, a máquina virtual no outro nó pode assumir o controlo automaticamente.

Opção	Considerações
Clustering de Convidados de Máquinas Virtuais	Requer armazenamento partilhado que esteja acessível por duas ou mais máquinas virtuais ao mesmo tempo. Os tipos de ligações suportados incluem: iSCSI Canal de Fibra Virtual VHDX Partilhado Configure a antiafinidade de máquinas virtuais para evitar que ambas as máquinas virtuais sejam executadas no mesmo nó de cluster. O Azure não suporta o clustering de convidados de máquinas virtuais. As funcionalidades seguintes não são compatíveis com VHDX partilhado: Réplica do Hyper-V Redimensionamento do disco rígido virtual enquanto qualquer uma das máquinas virtuais configuradas estiver em execução Migração direta do armazenamento Cópias de segurança VSS ao nível do anfitrião. As cópias de segurança ao nível do convidado devem ser efetuadas através dos mesmos métodos que utilizaria num cluster executado em servidores físicos. Pontos de verificação de máquina virtual QoS de armazenamento

Clustering de Convidados de Máquinas Virtuais

Requer armazenamento partilhado que esteja acessível por duas ou mais máquinas virtuais ao mesmo tempo. Os tipos de ligações suportados incluem:
- iSCSI
- Canal de Fibra Virtual
- VHDX Partilhado
Configure a antiafinidade de máquinas virtuais para evitar que ambas as máquinas virtuais sejam executadas no mesmo nó de cluster.
O Azure não suporta o clustering de convidados de máquinas virtuais.
As funcionalidades seguintes não são compatíveis com VHDX partilhado:
- Réplica do Hyper-V
- Redimensionamento do disco rígido virtual enquanto qualquer uma das máquinas virtuais configuradas estiver em execução
- Migração direta do armazenamento
- Cópias de segurança VSS ao nível do anfitrião. As cópias de segurança ao nível do convidado devem ser efetuadas através dos mesmos métodos que utilizaria num cluster executado em servidores físicos.
- Pontos de verificação de máquina virtual
- QoS de armazenamento

Informações adicionais:

Deploy a Guest Cluster Using a Shared Virtual Hard Disk (Implementar um Cluster de Convidados com um Disco Rígido Virtual Partilhado)

Utilizar a Colocação de Convidados em Cluster para Elevada Disponibilidade

Recuperação após Desastre

Se ocorrer um desastre, com que rapidez consegue ter as cargas de trabalho operacionais, de modo a que possam servir os clientes? Em alguns casos, o tempo que tem à sua disposição pode ser de apenas alguns minutos.

A replicação de dados dos seus centros de dados principais para os seus centros de recuperação após desastre é necessária para garantir que os dados mais atualizados podem ser replicados com uma perda de dados aceitável devido a atrasos. Ao executar cargas de trabalho em máquinas virtuais, é possível replicar os discos rígidos virtuais e os ficheiros de configuração das máquinas virtuais do site primário para um site de réplica.

A tabela seguinte compara as opções de recuperação após desastre.

Opção	Considerações
Réplica do Hyper-V	Económica e não é necessário duplicar o hardware de armazenamento e de anfitrião nos locais de recuperação após desastre. Utilize as mesmas ferramentas de gestão para gerir a replicação e para gerir as máquinas virtuais. Intervalos de replicação configuráveis, para preencher os seus requisitos em termos de perda de dados. Configure endereços IP diferentes para serem utilizados no site de réplica. Impacto mínimo na infraestrutura de rede. Não suportado em máquinas virtuais com discos físicos (também designados por discos pass-through), armazenamento de Canal de Fibra virtual ou discos rígidos virtuais partilhados. A Réplica do Hyper-V não deve ser utilizada como substituição do armazenamento de cópias de segurança de dados nem da obtenção de dados. Se forem configurados pontos de recuperação adicionais, será necessário armazenamento adicional no site de réplica. A taxa de intervalo de replicação irá determinar a quantidade de perda de dados. Se for configurada uma máquina virtual com uma grande quantidade de alterações e um intervalo de replicação curto, é necessário armazenamento adicional.
Cópia de segurança	Utilize uma solução de cópias de segurança suportada pelo Hyper-V, como o System Center Data Protection Manager, para efetuar a cópia de segurança da máquina virtual completa. A perda de dados será determinada pela antiguidade da última cópia de segurança. Não é possível criar cópias de segurança das máquinas virtuais configuradas com um ficheiro VHDX partilhado ao nível do anfitrião. Instale um agente de cópia de segurança na máquina virtual e crie uma cópia de segurança dos dados a partir da máquina virtual.

Réplica do Hyper-V

Económica e não é necessário duplicar o hardware de armazenamento e de anfitrião nos locais de recuperação após desastre.
Utilize as mesmas ferramentas de gestão para gerir a replicação e para gerir as máquinas virtuais.
Intervalos de replicação configuráveis, para preencher os seus requisitos em termos de perda de dados.
Configure endereços IP diferentes para serem utilizados no site de réplica.
Impacto mínimo na infraestrutura de rede.
Não suportado em máquinas virtuais com discos físicos (também designados por discos pass-through), armazenamento de Canal de Fibra virtual ou discos rígidos virtuais partilhados.
A Réplica do Hyper-V não deve ser utilizada como substituição do armazenamento de cópias de segurança de dados nem da obtenção de dados.
Se forem configurados pontos de recuperação adicionais, será necessário armazenamento adicional no site de réplica.
A taxa de intervalo de replicação irá determinar a quantidade de perda de dados.
Se for configurada uma máquina virtual com uma grande quantidade de alterações e um intervalo de replicação curto, é necessário armazenamento adicional.

Cópia de segurança

Utilize uma solução de cópias de segurança suportada pelo Hyper-V, como o System Center Data Protection Manager, para efetuar a cópia de segurança da máquina virtual completa.
A perda de dados será determinada pela antiguidade da última cópia de segurança.
Não é possível criar cópias de segurança das máquinas virtuais configuradas com um ficheiro VHDX partilhado ao nível do anfitrião. Instale um agente de cópia de segurança na máquina virtual e crie uma cópia de segurança dos dados a partir da máquina virtual.

Notas:

Para gerir e automatizar centralmente a replicação ao executar o System Center 2012 R2 - Virtual Machine Manager, é necessário utilizar o Microsoft Azure Site Recovery.
Para replicar máquinas virtuais no Azure através do Microsoft Azure Site Recovery. Atualmente, a replicação de máquinas virtuais no Azure está no modo de pré-visualização.

Informações adicionais:

Microsoft Azure Site Recovery

Importante:

Utilize o Hyper-V Replica Capacity Planner (Planeador de Capacidade do Hyper-V) para compreender o impacto que a Réplica do Hyper-V terá na sua infraestrutura de rede, na utilização do processador nos servidores primário, de réplica e de réplica expandida, na utilização de memória nos servidores primário e de réplica e em E/S de disco nos servidores primário, de réplica e de réplica expandida que se baseiam nas suas máquinas virtuais existentes.
A carga de trabalho poderá ter uma solução de recuperação após desastre incorporada, 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:

Hyper-V Replica (Réplica do Hyper-V)

System Center Data Protection Manager

Tarefa 5: Definir os tipos de máquina virtual

Para suportar as cargas de trabalho no seu ambiente, poderá criar máquinas virtuais com requisitos exclusivos de recursos para fazer face às necessidades de todas as cargas de trabalho. Em alternativa, poderá adotar uma abordagem semelhante para os fornecedores públicos de serviços de alojamento de máquinas virtuais (também designados por Infraestrutura como Serviço (Infrastructure-as-a-Service, IaaS).

Consulte Virtual Machine and Cloud Service Sizes for Azure (Tamanhos de Máquinas Virtuais e Serviços em Nuvem para o Azure) para ver uma descrição das configurações de máquinas virtuais oferecidas pelos Serviços de Infraestrutura do Microsoft Azure. À data deste documento, o serviço suportava 13 configurações de máquina virtual, cada uma delas com diferentes combinações de espaço para processador, memória, armazenamento e IOP.

Decisão de design - as decisões que tomar em todas as tarefas deste passo podem ser introduzidas nas folhas de cálculo de configurações de máquina virtual.

Passo 3: Planear grupos de anfitriões de virtualização de servidor

Antes de definir anfitriões de servidor individuais, poderá ser útil definir primeiro os grupos de anfitriões. Os grupos de anfitriões são, simplesmente, uma coleção nomeada de servidores que estão agrupados para alcançar os objetivos comuns resumidos nas tarefas restantes deste passo.

Tarefa 1: Definir localizações físicas

É provável que vá agrupar e gerir recursos de hardware por localização física, pelo que deverá definir primeiro as localizações que vão conter os recursos de infraestrutura na sua organização.

Tarefa 2: Definir os tipos de grupos de anfitriões

Poderá criar grupos de anfitriões por diversas razões, como, por exemplo, para alojar cargas de trabalho com:

Caracterizações de cargas de trabalho específicas
Requisitos de recursos específicos
Requisitos específicos de qualidade de serviço

A imagem seguinte ilustra uma organização que criou cinco grupos de anfitriões em duas localizações.

Grupo de anfitriões

Figura 2:Exemplo de grupo de anfitriões

A organização criou os grupos de anfitriões pelas razões descritas na tabela seguinte.

Grupo de anfitriões	Razões para a criação
Carga de trabalho sem monitorização de estado e com monitorização de estado	Estas caracterizações de carga de trabalho são as mais comuns nesta organização, pelo que têm este tipo de grupo de anfitriões nas duas localizações. Estas cargas de trabalho têm um desempenho e requisitos de nível de serviço semelhantes.
Cargas de trabalho com monitorização de estado e sem monitorização de estado do departamento de contabilidade	Embora a configuração de hardware dos servidores neste grupo de anfitriões seja a mesma de outros grupos de anfitriões de cargas de trabalho sem monitorização de estado e com monitorização de estado no ambiente da organização, o departamento de contabilidade tem aplicações com requisitos de segurança mais elevados do que outros departamentos. Por consequência, foi criado um grupo de anfitriões dedicado para os mesmos, de modo a que pudessem ser protegidos de forma diferente dos outros grupos de anfitriões na infraestrutura.
Cargas de trabalho com monitorização de estado partilhado	As cargas de trabalho alojadas por este grupo de anfitriões precisam de armazenamento partilhado porque dependem do Clustering de Ativação Pós-falha no Windows Server para manterem a sua disponibilidade. Estas cargas de trabalho são alojadas por um grupo de anfitriões dedicado porque a configuração destas máquinas virtuais é diferente das outras máquinas virtuais na organização.
Cargas de trabalho com monitorização de estado de E/S elevada	Todos os anfitriões neste grupo de anfitriões estão ligados a redes de velocidade mais alta do que os anfitriões nos outros grupos de anfitriões.

Embora a organização pudesse ter abrangido localizações com os respetivos grupos de anfitriões, optou por manter todos os membros de cada grupo de anfitriões na mesma localização, para facilitar a gestão. Como pode ver neste exemplo, os grupos de anfitriões podem ser criados por diversas razões e essas razões variam de organização para organização. Quantos mais tipos de grupos de anfitriões criar na sua organização, mais complexa será a gestão do ambiente, o que, em última análise, aumenta o custo de alojar máquinas virtuais.

Sugestão: Quanto mais normalizado for o hardware de servidor num grupo de anfitriões, mais fácil será dimensionar e manter o grupo de anfitriões ao longo do tempo. Se determinar que pretende normalizar o hardware num grupo de anfitriões, pode adicionaros dados de configuração normalizados à folha de cálculo Grupos de anfitriões no documento Virtualization Fabric Design Considerations Worksheets (Folhas de Cálculo de Considerações de Design da Infraestrutura de Virtualização). Para obter mais informações sobre as considerações de hardware físico, consulte o Passo 4: Planear anfitriões de virtualização de servidor.

Tenha em conta que, atualmente, a maioria dos fornecedores de nuvem pública que alojam máquinas virtuais:

Apenas alojam máquinas virtuais que não necessitem de estado partilhado.
Muitas vezes, só têm um conjunto de métricas de qualidade de serviço, que providenciam a todos os clientes.
Não dedicam hardware específico a clientes específicos.

Recomendamos que comece com um tipo de grupo de anfitriões que contenha hardware idêntico e adicione apenas outros tipos de grupos de anfitriões porque a vantagem de o fazer prevalece sobre o custo.

Tarefa 3: Determinar se deve criar um cluster de membros do grupo de anfitriões

No passado, o Clustering de Ativação Pós-falha no Windows Server era utilizado apenas para aumentar a disponibilidade do servidor, mas desenvolveu-se para proporcionar significativamente mais funcionalidade. Considere as informações na tabela seguinte para decidir se deve criar um cluster dos membros do grupo de anfitriões.

Opção	Vantagens	Desvantagens
Os membros do grupo de anfitriões fazem parte de um cluster de ativação pós-falha	Se um dos anfitriões falhar, as máquinas virtuais que esse anfitrião alojar são reiniciadas automaticamente nos nós operacionais. As máquinas virtuais podem ser movidas para outro nó do cluster se o nó no qual estão em execução detetar um problema no nó ou na máquina virtual. Utilize a Atualização com Suporte para Clusters para atualizar facilmente os nós do cluster sem causar impacto nas máquinas virtuais em execução.	Os anfitriões requerem uma configuração específica para serem membros do cluster. Os anfitriões têm de ser membros de um domínio do Active Directory. O Clustering de Ativação Pós-falha requer requisitos de redes e armazenamento adicionais.
Os membros do grupo de anfitriões não fazem parte de um cluster de ativação pós-falha	Os anfitriões não requerem uma configuração específica do cluster. Os anfitriões não têm de ser membros de um domínio do Active Directory. Não é necessário armazenamento nem redes adicionais.	As máquinas virtuais em execução num anfitrião que falhe têm de ser movidas manualmente (ou pode utilizar alguma forma de automatização) para um anfitrião operacional e reiniciadas.

Decisão de design - as decisões que tomar em todas as tarefas deste passo podem ser introduzidas na folha de cálculo Definições.

Passo 4: Planear anfitriões de virtualização de servidor

Neste passo, vai definir os tipos de anfitriões necessários para alojar as máquinas virtuais que pretende executar na infraestrutura de virtualização. Deverá limitar o número de configurações de anfitrião, para uma única configuração em alguns casos, de modo a aliviar os custos de suporte e aprovisionamento. Além disso, a compra de equipamento indevido irá elevar os custos de implementação.

Cloud Platform System

A Microsoft utilizou a sua experiência na execução de alguns dos maiores centros de dados e serviços em nuvem para criar um sistema convergente integrado e totalmente validado de infraestrutura. O Cloud Platform System (CPS) combina a comprovada pilha de software Windows Server 2012 R2 da Microsoft, o System Center 2012 R2 e o Microsoft Azure Pack, com hardware de servidor de nuvem, armazenamento e redes da Dell. Enquanto bloco modular escalável para a sua nuvem, o CPS acelera a concretização dos objetivos e proporciona uma experiência consistente de utilização da nuvem.

O CPS proporciona um ambiente de nuvem multi-inquilino de gestão personalizada para máquinas virtuais Plataforma como Serviço, Windows e Linux e inclui pacotes de implementação otimizados para aplicações da Microsoft, como o SQL Server, o SharePoint e o Exchange. A integração da infraestrutura diminui o risco e a complexidade, ao mesmo tempo que acelera o tempo de implementação de meses para dias. O processo de suporte simplificado e a automatização de tarefas de rotina da infraestrutura também liberta recursos de TI, permitindo-lhes concentrar-se na inovação.

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

Fast Track

Em vez de conceber uma configuração de hardware (e software), pode comprar configurações pré-configuradas de hardware de entre vários parceiros de hardware através do programa Microsoft Private Cloud Fast Track.

O programa Fast Track é uma iniciativa conjunta entre a Microsoft e os seus parceiros de hardware, que visa disponibilizar soluções pré-configuradas e validadas que reduzem a complexidade e o risco de implementação de uma infraestrutura de virtualização, bem como as ferramentas para geri-la.

O programa Fast Track oferece soluções flexíveis e opções aos clientes numa gama de tecnologias de fornecedores de hardware. Utiliza as principais funcionalidades do sistema operativo Windows Server, da tecnologia Hyper-V e do Microsoft System Center para fornecer os blocos modulares de uma infraestrutura de nuvem privada como oferta de serviço.

Informações adicionais:

Site do Microsoft Private Cloud Fast Track

Tarefa 1: Definir a configuração informática

Nesta tarefa, vai determinar a quantidade de memória, o número de processadores e a versão do Windows Server necessários para cada anfitrião. O número de máquinas virtuais a executar num anfitrião será determinado pelos componentes de hardware abordados nesta secção.

Nota: para garantir que a sua solução é totalmente suportada, todo o hardware que comprar tem de trazer o logótipo "Certified for Windows Server" (Certificado para Windows Server) com a versão do Windows Server que está a executar.

O logótipo "Certified for Windows Server" demonstra que os sistemas de servidores cumprem a mais elevada fasquia técnica da Microsoft em termos de segurança, fiabilidade e capacidade de gestão. Com outros controladores e dispositivos certificados, pode suportar as funções, funcionalidades e interfaces para cargas de trabalho de Nuvem e Empresariais e para aplicações empresariais vitais.

Para obter a lista mais recente de hardware "Certified for Windows Server", consulte o Windows Server Catalog (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. Pode obter eficiência de tempo de execução adicional ao utilizar processadores que suportem tecnologias de Tradução de Endereços de Segundo Nível (Second Level Address Translation, SLAT), tais como EPT (Extended Page Tables) ou NPT (Nested Page Tables). O Hyper-V no Windows Server 2012 R2 suporta um máximo de 320 processadores lógicos.

Considerações:

As cargas de trabalho que não são intensivas para o processador devem ser configuradas para utilizar um processador virtual. Monitorize a utilização do processador anfitrião ao longo do tempo para garantir que alocou processadores para máxima eficácia.
As cargas de trabalho com um consumo intensivo da CPU devem ser atribuídas a dois ou mais processadores virtuais. Pode atribuir um máximo de 64 processadores virtuais a uma máquina virtual. O número de processadores virtuais reconhecidos pela máquina virtual depende do sistema operativo convidado. Por exemplo, o Windows Server 2008 com Service Pack 2 reconhece apenas quatro processadores virtuais.

Informações adicionais:

Hyper-V Overview (Descrição Geral do Hyper-V)

Performance Tuning for Hyper-V Servers (Otimização de Desempenho para Servidores Hyper-V)

Tarefa 1b: Definir a memória

O servidor físico necessita de memória suficiente para o anfitrião e as máquinas virtuais em execução. O anfitrião necessita de memória para executar a E/S de forma eficiente em nome das máquinas virtuais e operações, como, por exemplo, o ponto de verificação de máquinas virtuais. O Hyper-V assegura a existência de memória disponível suficiente para o anfitrião e permite que a memória restante seja atribuída às máquinas virtuais. As máquinas virtuais devem ser dimensionadas com base nas necessidades da carga esperada para cada máquina virtual.

O hipervisor virtualiza a memória física convidada para isolar as máquinas virtuais entre si e para fornecer espaço de memória contíguo baseado em zero para cada sistema operativo convidado, o mesmo que em sistemas não virtualizados. Para garantir que obtém o máximo desempenho, utilize hardware baseado em SLAT para minimizar o custo de desempenho da virtualização de memória.

Dimensione a memória da máquina virtual como faz normalmente para aplicações de servidor num computador físico. A quantidade de memória atribuída à máquina virtual deverá permitir que esta processe de forma razoável a carga esperada em horas normais e em horas de ponta, uma vez que uma memória insuficiente pode aumentar significativamente os tempos de resposta e a utilização da CPU ou de E/S.

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

A Memória Dinâmica permite obter números de consolidação mais elevados com fiabilidade melhorada para operações de reinício. Isto pode levar a custos mais baixos, sobretudo em ambientes com muitas máquinas virtuais inativas ou com pouca carga, como ambientes VDI agrupados. As alterações de configuração em tempo de execução da Memória Dinâmica podem reduzir o período de indisponibilidade e fornecer maior agilidade para responder a alterações de requisitos.

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

Informações adicionais:

Dynamic Memory Overview (Descrição Geral da Memória Dinâmica)

Descrição Geral da Arquitetura NUMA Virtual

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

Os conjuntos de funcionalidades do Windows Server Standard e do Windows Server Datacenter são exatamente os mesmos. O Windows Server Datacenter oferece um número ilimitado de máquinas virtuais. O Windows Server Standard está limitado a duas máquinas virtuais.

Foi adicionada ao Windows Server 2012 R2 a funcionalidade Ativação Automática de Máquina Virtual (Automatic Virtual Machine Activation, AVMA). A AVMA permite instalar máquinas virtuais num servidor devidamente ativado sem ser necessário gerir chaves de produto para cada máquina virtual, mesmo em ambientes desligados.

A AVMA requer que os sistemas operativos convidados executem o Windows Server 2012 R2 Datacenter, o Windows Server 2012 R2 Standard ou o Windows Server 2012 R2 Essentials. A tabela seguinte compara as edições.

Edição	Vantagens	Desvantagens
Standard	Inclui todas as funcionalidades do Windows Server Aceitável para ambientes não virtualizados ou ligeiramente virtualizados	Limitada a duas máquinas virtuais
Datacenter	Inclui todas as funcionalidades do Windows Server Permite 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 numa opção de instalação Server Core do Windows Server. A instalação Server Core reduz o espaço necessário no disco, a superfície de potenciais ataques e, sobretudo, os requisitos de manutenção. A instalação Server Core é gerida através da linha de comandos, do Windows PowerShell ou de administração remota.

É importante rever os termos de licenciamento de qualquer software que planeie utilizar.

Microsoft Hyper-V Server

O Microsoft Hyper-V Server proporciona uma solução de virtualização simples e fiável para ajudar as organizações a melhorar a utilização de servidores e a reduzir os custos. É um produto autónomo que contém apenas o hipervisor do Windows, um modelo de controlador do Windows Server e componentes de virtualização.

O Hyper-V Server pode ajustar-se aos ambientes de TI atuais dos clientes e tirar partido do aprovisionamento, dos processos de gestão e das ferramentas de suporte que já utilizam. Suporta a mesma lista de compatibilidade de hardware do que as edições correspondentes do Windows Server e pode ser integrado totalmente com o Microsoft System Center e as tecnologias Windows, como, por exemplo, o Windows Update, o Active Directory e o Clustering de Activação Pós-falha.

A transferência do Hyper-V Server é gratuita e a sua instalação já está ativada. No entanto, todos os sistemas operativos que estejam em execução numa máquina virtual alojada requerem uma licença adequada.

Informações adicionais:

Ativação Automática de Máquina Virtual

Microsoft Hyper-V Server

Manage Hyper-V Server Remotely (Gerir o Hyper-V Server Remotamente)

Tarefa 2: Definir a configuração de rede

No Passo 2, Tarefa 2 acima, abordámos as considerações de design para o funcionamento em rede da máquina virtual. Agora, vamos debater as considerações de redes para o anfitrião. Existem vários tipos de tráfego de rede a ter em consideração e a planear ao implementar o Hyper-V. Deve conceber a sua configuração de rede tendo os seguintes objetivos em mente:

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

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

Ao implementar um cluster Hyper-V, é necessário planear a utilização de diversos tipos de tráfego de rede. A tabela seguinte resume os tipos de tráfego.

Tipo de tráfego	Descrição
Gestão	Fornece conectividade entre o servidor que está a executar o Hyper-V e a funcionalidade de infraestrutura básica Utilizado para gerir o sistema operativo convidado do Hyper-V e as máquinas virtuais
Cluster e CSVs	Utilizados para a comunicação de clusters entre nós, como o redirecionamento de Volumes Partilhados de Cluster (CSV) e o heartbeat de cluster Apenas quando o Hyper-V tiver sido implementado com o Clustering de Ativação Pós-falha
Migração em direto	Utilizada para a migração em direto de máquinas virtuais e migração em direto sem partilha
Armazenamento	Utilizado para o tráfego SMB ou para o tráfego iSCSI
Réplica	Utilizada para o tráfego de replicação de máquinas virtuais através da funcionalidade Réplica do Hyper-V
Tráfego de máquina virtual (inquilino)	Utilizado para a conectividade de máquinas virtuais Normalmente, requer conectividade de rede externa para atender os pedidos dos clientes Nota: consulte o Passo 2: Planear a configuração das máquinas virtuais para obter uma lista dos tipos de tráfego de máquinas virtuais.
Cópia de segurança	Utilizada para criar cópias de segurança dos ficheiros de 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 máximos e mínimos de largura de banda e requisitos mínimos de latência. A seguir são apresentadas as estratégias que podem ser utilizadas para preencher diferentes requisitos de desempenho de rede.

QoS baseado em políticas

Ao implementar um cluster Hyper-V, é necessário um mínimo de seis padrões de tráfego ou redes. Cada rede necessita de redundância de rede. Para começar, estamos a falar de 12 adaptadores de rede no anfitrião. Pode instalar vários adaptadores de rede quaternos, mas, em determinado momento, vai ficar sem ranhuras no anfitrião.

O equipamento de rede está cada vez mais rápido. Não há muito tempo, os adaptadores de rede de 1 GB eram o modelo topo de gama. Os adaptadores de 10 GB nos servidores são cada vez mais comuns e os preços para suportar infraestruturas de 10 GB estão a tonar-se cada vez mais razoáveis.

A instalação de dois adaptadores de rede agrupados de 10 GB proporciona mais largura de banda do que dois adaptadores de 1 GB quaternos, requer menos portas de comutador e simplifica as necessidades de cablagem. À medida que converge mais tipos de tráfego de rede nos adaptadores de rede de 10 GB agrupados, o QoS baseado em políticas permite gerir o tráfego de rede para satisfazer adequadamente a necessidade da sua infraestrutura de virtualização.

Com o QoS baseado em políticas, pode especificar controlo de largura de banda de rede, tendo por base o tipo de aplicação, os utilizadores e os computadores. As políticas QoS permitem-lhe cumprir os requisitos de serviço de uma carga de trabalho ou de uma aplicação ao medir a largura de banda, detetar condições de rede variáveis (tais como congestionamento ou disponibilidade da largura de banda) e atribuir prioridades (ou limitações) ao tráfego de rede.

Para além da capacidade de impor largura de banda máxima, as políticas QoS no Windows Server 2012 R2 fornecem uma nova funcionalidade de gestão de largura de banda - largura de banda mínima. Ao contrário da largura de banda máxima, que corresponde a um limite máximo de largura de banda, a largura de banda mínima corresponde a um limite mínimo de largura de banda e atribui uma determinada quantidade de largura de banda a um tipo de tráfego específico. É possível implementar simultaneamente os limites mínimo e máximo de largura de banda.

Vantagens	Desvantagens
Gerido pela Política de Grupo Facilmente aplicado a VLANs, para fornecer definições de largura de banda apropriadas quando várias VLANs estão a ser executadas no adaptador de rede ou a utilizar o Agrupamento NIC O QoS baseado em políticas pode ser aplicado a tráfego IPsec	Não fornece gestão de largura de banda ao tráfego que está a utilizar um comutador virtual Os anfitriões Hyper-V têm de ser associados a um domínio As políticas QoS baseadas em software e as políticas QoS baseadas em hardware (DCB) não devem ser utilizadas ao mesmo tempo

Informações adicionais:

Quality of Server (QoS) Overview (Descrição Geral de Quality of Service [QoS])

Policy-based Quality of Service (Quality of Service baseado em políticas)

Data Center Bridging

O Data Center Bridging (DCB) oferece alocação de largura de banda baseada em hardware a um tipo específico de tráfego e melhora a fiabilidade do transporte Ethernet com a utilização de controlo de fluxo baseado em prioridades. Recomenda-se o DCB se FCoE e iSCSI forem utilizados.

Vantagens	Desvantagens
Suporte para Microsoft iSCSI Suporte para FCoE	São necessários investimentos em hardware, incluindo: Adaptadores Ethernet compatíveis com DCB Comutadores de hardware compatíveis com DCB Complexo de implementar e gerir Não oferece gestão de largura de banda para tráfego de comutador virtual As políticas QoS baseadas em software e as políticas DCB não devem ser utilizadas ao mesmo tempo

Informações adicionais:

Data Center Bridging (DCB) Overview (Descrição Geral do Data Center Bridging [DCB])

SMB Direto

O SMB Direto (SMB por acesso remoto direto à memória ou RDMA) é um protocolo de armazenamento no Windows Server 2012 R2. Permite transferências de dados de memória para memória entre o servidor e o armazenamento. Requer utilização mínima da CPU e utiliza adaptadores de rede com capacidade RDMA. Isto proporciona respostas extremamente rápidas a pedidos de rede e, como resultado, faz com que os tempos de resposta do armazenamento de ficheiros remoto fiquem ao mesmo nível do armazenamento de blocos ligado diretamente.

Vantagens	Desvantagens
Maior débito: tira partido do débito total das redes de alta velocidade, onde os adaptadores de rede coordenam a transferência de grandes quantidades de dados à velocidade de linha Baixa latência: proporciona tempos de resposta extremamente rápidos a pedidos de rede e, como resultado, faz com que o armazenamento de ficheiros remoto pareça estar ligado diretamente ao armazenamento de blocos Baixa utilização da CPU: Utiliza menos ciclos da CPU ao transferir dados através da rede, o que liberta mais ciclos da CPU para as máquinas virtuais A migração em direto pode ser configurada para utilizar o SMB Direto para migrações em direto mais rápidas. Ativado por predefinição no anfitrião O cliente SMB deteta e utiliza automaticamente várias ligações de rede, se for identificada uma configuração apropriada Configure a gestão de largura de banda SMB para definir limites para a migração em direto, máquinas virtuais e tráfego de armazenamento predefinido O SMB Multicanal não requer adaptadores de rede suportados por RDMA	Os adaptadores de rede com RDMA ativado não são compatíveis com Agrupamento NIC Requer a implementação de dois ou mais adaptadores de rede RDMA em cada anfitrião para fornecer elevada disponibilidade Atualmente limitado aos seguintes tipos de adaptadores de rede: iWARP Infiniband RoCE O RDMA com RoCE requer o DCB para controlo de fluxo.

Maior débito: tira partido do débito total das redes de alta velocidade, onde os adaptadores de rede coordenam a transferência de grandes quantidades de dados à velocidade de linha
Baixa latência: proporciona tempos de resposta extremamente rápidos a pedidos de rede e, como resultado, faz com que o armazenamento de ficheiros remoto pareça estar ligado diretamente ao armazenamento de blocos
Baixa utilização da CPU: Utiliza menos ciclos da CPU ao transferir dados através da rede, o que liberta mais ciclos da CPU para as máquinas virtuais
A migração em direto pode ser configurada para utilizar o SMB Direto para migrações em direto mais rápidas.
Ativado por predefinição no anfitrião
O cliente SMB deteta e utiliza automaticamente várias ligações de rede, se for identificada uma configuração apropriada
Configure a gestão de largura de banda SMB para definir limites para a migração em direto, máquinas virtuais e tráfego de armazenamento predefinido
O SMB Multicanal não requer adaptadores de rede suportados por RDMA

Os adaptadores de rede com RDMA ativado não são compatíveis com Agrupamento NIC
Requer a implementação de dois ou mais adaptadores de rede RDMA em cada anfitrião para fornecer elevada disponibilidade
Atualmente limitado aos seguintes tipos de adaptadores de rede:
- iWARP
- Infiniband
- RoCE
O RDMA com RoCE requer o DCB para controlo de fluxo.

Receive Segment Coalescing

O Receive segment coalescing (RSC) reduz a utilização da CPU para processamento de rede de entrada ao descarregar tarefas da CPU para um adaptador de rede com capacidade RSC.

Vantagens	Desvantagens
Melhora a escalabilidade dos servidores ao reduzir a sobrecarga no processamento de grandes quantidades de tráfego de rede de entrada Minimiza os ciclos da CPU despendidos no armazenamento de rede e nas migrações em direto	Requer um adaptador de rede com capacidade RSC Não proporciona um melhoramento significativo de cargas de trabalho intensivas em termos de envios Não é compatível com tráfego encriptado IPsec É aplicável ao tráfego do anfitrião. Para aplicar o RSC ao tráfego da máquina virtual, a máquina virtual tem de executar o Windows Server 2012 R2 e configurada com um adaptador de rede SR-IOV. Não está ativado por predefinição nos servidores atualizados para o Windows Server 2012 R2

Melhora a escalabilidade dos servidores ao reduzir a sobrecarga no processamento de grandes quantidades de tráfego de rede de entrada
Minimiza os ciclos da CPU despendidos no armazenamento de rede e nas migrações em direto

Requer um adaptador de rede com capacidade RSC
Não proporciona um melhoramento significativo de cargas de trabalho intensivas em termos de envios
Não é compatível com tráfego encriptado IPsec
É aplicável ao tráfego do anfitrião. Para aplicar o RSC ao tráfego da máquina virtual, a máquina virtual tem de executar o Windows Server 2012 R2 e configurada com um adaptador de rede SR-IOV.
Não está ativado por predefinição nos servidores atualizados para o Windows Server 2012 R2

Receive Side Scaling

O Receive-side scaling (RSS) permite que os adaptadores de rede distribuam a carga de processamento de rede do modo de kernel por vários núcleos do processador em diversos computadores núcleo. A distribuição deste processamento possibilita o suporte de cargas de tráfego de rede mais elevadas do que seria possível se apenas fosse utilizado um único núcleo. Para tal, o RSS distribui a carga de processamento de rede por muitos processadores e efetua ativamente o balanceamento de carga do tráfego terminado pelo Protocolo de Controlo de Transmissão (TCP).

Vantagens	Desvantagens
Distribui as interrupções de monitorização por vários processadores, para que não seja necessário um processador único para processar todas as interrupções de E/S, o que era comum nas versões anteriores do Windows Server. Funciona com Agrupamento NIC Funciona com tráfego UDP (User Datagram Protocol)	Requer um adaptador de rede com capacidade RSS Desativado se o adaptador de rede virtual estiver vinculado a um comutador virtual. Para adaptadores de rede vinculados a um comutador virtual., é utilizado o VMQ em vez do RSS.

SR-IOV

O Hyper-V suporta dispositivos de rede com capacidade SR-IOV e permite a atribuição direta de uma função virtual SR-IOV de um adaptador de rede físico a uma máquina virtual. Isto aumenta o débito de rede, reduz a latência de rede e reduz a sobrecarga da CPU do anfitrião necessária para processar o tráfego de rede.

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

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

O Agrupamento NIC, também designado por balanceamento de carga e ativação pós-falha (LBFO), permite a colocação de vários adaptadores de rede numa equipa para fins de agregação de largura de banda e ativação pós-falha de tráfego. Isto ajuda a manter a conectividade na eventualidade de uma falha nos componentes de rede.

Esta funcionalidade está disponível junto dos fornecedores de adaptadores de rede. Introduzido no Windows Server 2012, o Agrupamento NIC está incluído como uma funcionalidade no sistema operativo Windows Server.

O Agrupamento NIC é compatível com todas as capacidades de funcionamento em rede no Windows Server 2012 R2, com três exceções:

SR-IOV
RDMA
Autenticação 802.1X

Numa perspetiva de escalabilidade, no Windows Server 2012 R2, é possível adicionar um mínimo de um e um máximo de 32 adaptadores de rede a uma única equipa. Pode ser criado um número ilimitado de equipas num único anfitrião.

Informações adicionais:

Descrição Geral do Agrupamento NIC

Microsoft Virtual Academy: NIC Teaming in Windows Server 2012 (Microsoft Virtual Academy: Agrupamento NIC no Windows Server 2012)

NIC Teaming (NetLBFO) Cmdlets in Windows PowerShell (Cmdlets do Agrupamento NIC (NetLBFO) no Windows PowerShell)

Windows Server 2012 R2 NIC Teaming (LBFO) Deployment and Management (Implementação e Gestão de Agrupamento NIC (LBFO) no Windows Server 2012 R2)

Centro de Dados Convergido com Armazenamento do Servidor de Ficheiros

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 diferentes requisitos de segurança para funções, como, por exemplo, isolamento e encriptação. A tabela seguinte apresenta as estratégias que podem ser utilizadas para cumprir diversos requisitos de segurança.

Estratégia	Vantagens	Desvantagens
Encriptação (IPsec)	O tráfego está protegido enquanto atravessa a rede	Impacto no desempenho para encriptar e desencriptar o tráfego Complexo de configurar, gerir e resolver problemas As alterações de configuração IPsec incorretas podem provocar interrupções de rede ou fazer com que o tráfego não seja devidamente encriptado
Redes físicas separadas	A rede está fisicamente separada	Requer a instalação de adaptadores de rede adicionais no anfitrião Se a rede necessitar de elevada disponibilidade, são necessários dois ou mais adaptadores de rede para cada rede.
Rede local virtual (VLAN)	Utiliza um ID de VLAN atribuído para isolar o tráfego Suporte para Protocolo de Truncamento de VLAN Suporte para VLANs privadas Já utilizada por muitos clientes empresariais	Limitada a 4094 VLANs e a maioria dos comutadores suportam apenas 1000 VLANs Requer configuração adicional e gestão de equipamento de rede As VLANs não podem distribuir várias sub-redes Ethernet, o que limita o número de nós numa única VLAN e restringe o posicionamento de máquinas virtuais com base na localização física.

Tarefa 2e: Definir adaptadores de rede virtuais

Tendo conhecimento dos tipos de tráfego necessários para os anfitriões de servidor de virtualização, bem como das estratégias de desempenho, disponibilidade e segurança para o tráfego, poderá determinar o número de adaptadores de rede físicos necessários para cada anfitrião e os tipos de tráfego de rede que serão transmitidos através de cada adaptador.

Tarefa 2f: Definir os comutadores virtuais

Para ligar uma máquina virtual a uma rede, é necessário ligar o adaptador de rede a um comutador virtual de Hyper-V.

Podem ser criados três tipos de comutadores virtuais no Hyper-V:

Comutador virtual externo

Utilize um comutador virtual externo se pretender fornecer às máquinas virtuais acesso a uma rede física para comunicar com clientes e servidores localizados externamente. Este tipo de comutador virtual também permite que as máquinas virtuais no mesmo anfitrião comuniquem entre si. Este tipo de rede também pode estar disponível para ser utilizada pelo sistema operativo anfitrião, dependendo de como configurar as redes.

Importante: os adaptadores de rede físicos só podem estar vinculados a um comutador virtual de cada vez.
Comutador virtual interno

Utilize um comutador virtual interno se pretender permitir a comunicação entre máquinas virtuais no mesmo anfitrião e entre máquinas virtuais e o sistema operativo anfitrião. Geralmente, este tipo de comutador virtual é utilizado para criar um ambiente de teste no qual tem de se ligar às máquinas virtuais a partir do sistema operativo anfitrião. Os comutadores virtuais internos não estão vinculados a adaptadores de rede físicos. Consequentemente, as redes virtuais internas estão isoladas do tráfego de rede externo.
Comutador virtual privado

Utilize um comutador virtual privado se pretender permitir a comunicação apenas entre máquinas virtuais no mesmo anfitrião. Os comutadores virtuais privados não estão vinculados a adaptadores de rede físicos. Os comutadores virtuais privados estão isolados de todo o tráfego de rede externo no servidor de virtualização e de qualquer tráfego entre o sistema operativo anfitrião e a rede externa. Este tipo de rede é útil se precisar de criar um ambiente de rede isolado, como um domínio de teste isolado.

Nota: os comutadores virtuais privados e internos não beneficiam das funcionalidades de aceleração por hardware que estão disponíveis em máquinas virtuais ligadas a um comutador de rede externo.

Decisão de design - as decisões que tomar em todas as tarefas deste passo podem ser introduzidas nas folhas de cálculo Anfitriões de virtualização.

Sugestão: Os comutadores virtuais em diferentes anfitriões que ligam à mesma rede devem ter o mesmo nome. Isto elimina a confusão em relação a que comutador virtual uma máquina virtual deve estar ligada e simplifica a mudança de uma máquina virtual de um anfitrião para outro. O cmdlet Move-VM do Windows PowerShell irá falhar se não for encontrado o mesmo nome de comutador virtual no anfitrião de destino.

Tarefa 3: Definir a configuração do armazenamento

Para além do armazenamento necessário para o sistema operativo anfitrião, cada anfitrião precisa de acesso ao armazenamento no qual os ficheiros de configuração da máquina virtual e os discos rígidos virtuais estão armazenados. Esta tarefa foca-se no armazenamento das máquinas virtuais.

Tarefa 3a: Definir os tipos de dados

Abaixo, são apresentados os tipos de dados de exemplo que terá de considerar para os requisitos de armazenamento.

Tipos de dados	Localização de armazenamento do tipo de dados
Ficheiros do sistema operativo anfitrião	Normalmente, num disco rígido local
Ficheiro de página anfitriã e ficheiros de informação de falha de sistema no Windows	Normalmente, num disco rígido local
Estado partilhado do cluster de ativação pós-falha	Armazenamento de rede partilhado ou volume partilhado de cluster
Ficheiros de disco rígido virtual e ficheiro de configuração da máquina virtual	Normalmente, no armazenamento de rede partilhado ou no volume partilhado de cluster

O resto deste passo concentra-se no armazenamento necessário para as máquinas virtuais.

Tarefa 3b: Opções de armazenamento

As opções que se seguem estão disponíveis para armazenar os ficheiros de configuração de máquinas virtuais e os discos rígidos virtuais.

Opção 1: Armazenamento de ligação direta

O armazenamento de ligação direta refere-se ao sistema de armazenamento de um computador que está ligado diretamente ao servidor, em vez de estar ligado diretamente a uma rede. O armazenamento de ligação direta não está limitado apenas ao armazenamento interno. Também pode utilizar um bastidor de disco externo que contenha unidades de disco rígido, incluindo bastidores JBOD (just-a-bunch-of-disks) e bastidores ligados através de SAS ou de outro controlador de disco.

Vantagens	Desvantagens
Não requer uma rede de armazenamento E/S de disco rápida, para que os pedidos de armazenamento não percorram uma rede Pode ser armazenamento interno ou um bastidor de disco externo, incluindo JBODs Pode utilizar os JBOD com a tecnologia Espaços de Armazenamento para combinar todos os discos físicos num agrupamento de armazenamento e, em seguida, criar um ou mais discos virtuais (chamados Espaços de Armazenamento) a partir do espaço livre no agrupamento. Os JBODs são, normalmente, mais baratos e, muitas vezes, mais flexíveis e fáceis de gerir do que os bastidores RAID, porque utilizam os sistemas operativos Windows ou Windows Server para gerir o armazenamento, em vez de utilizarem adaptadores RAID dedicados.	Limitado em relação ao número de servidores que podem ser ligados ao bastidor de disco externo Apenas o armazenamento partilhado externo, como, por exemplo, SAS partilhado com Espaços de Armazenamento, fornece suporte para Clustering de Ativação Pós-falha

Não requer uma rede de armazenamento
E/S de disco rápida, para que os pedidos de armazenamento não percorram uma rede
Pode ser armazenamento interno ou um bastidor de disco externo, incluindo JBODs
Pode utilizar os JBOD com a tecnologia Espaços de Armazenamento para combinar todos os discos físicos num agrupamento de armazenamento e, em seguida, criar um ou mais discos virtuais (chamados Espaços de Armazenamento) a partir do espaço livre no agrupamento.
Os JBODs são, normalmente, mais baratos e, muitas vezes, mais flexíveis e fáceis de gerir do que os bastidores RAID, porque utilizam os sistemas operativos Windows ou Windows Server para gerir o armazenamento, em vez de utilizarem adaptadores RAID dedicados.

Limitado em relação ao número de servidores que podem ser ligados ao bastidor de disco externo
Apenas o armazenamento partilhado externo, como, por exemplo, SAS partilhado com Espaços de Armazenamento, fornece suporte para Clustering de Ativação Pós-falha

Opção 2: Armazenamento ligado à rede

Os dispositivos de armazenamento ligados à rede ligam o armazenamento a uma rede, onde o acesso aos mesmos é feito através de partilhas de ficheiros. Ao contrário do armazenamento de ligação direta, estes dispositivos não são ligados diretamente ao computador.

Os dispositivos de armazenamento ligados à rede suportam ligações Ethernet e, normalmente, permitem que o administrador efetue a gestão do espaço em disco, defina quotas de disco, forneça segurança e utilize tecnologias de pontos de verificação. Os dispositivos de armazenamento ligados à rede suportam vários protocolos. Estes incluem sistemas de ficheiros ligados à rede, o protocolo CIFS (Common Internet File Systems) e o protocolo SMB (Server Message Block).

Vantagens	Desvantagens
Mais simples de configurar do que o armazenamento SAN, necessitando de menos hardware de armazenamento dedicado Plug and Play Pode utilizar a rede Ethernet existente	O dispositivo de armazenamento ligado à rede tem de suportar SMB 3.0 — o protocolo CIFS não é suportado Não é ligado diretamente aos servidores de anfitrião que acedem ao armazenamento Mais lento do que outras opções Normalmente, necessita de uma rede dedicada para um desempenho ideal Funcionalidade e gestão limitadas O Hyper-V suporta dispositivos de armazenamento ligados à rede que suportem SMB 3.0. Os protocolos SMB 2.0 e CIFS não são suportados. Pode ou não suportar RDMA

Mais simples de configurar do que o armazenamento SAN, necessitando de menos hardware de armazenamento dedicado
Plug and Play
Pode utilizar a rede Ethernet existente

O dispositivo de armazenamento ligado à rede tem de suportar SMB 3.0 — o protocolo CIFS não é suportado
Não é ligado diretamente aos servidores de anfitrião que acedem ao armazenamento
Mais lento do que outras opções
Normalmente, necessita de uma rede dedicada para um desempenho ideal
Funcionalidade e gestão limitadas
O Hyper-V suporta dispositivos de armazenamento ligados à rede que suportem SMB 3.0. Os protocolos SMB 2.0 e CIFS não são suportados.
Pode ou não suportar RDMA

Opção 3: Rede de armazenamento

Uma rede de armazenamento (SAN) é uma rede dedicada que permite partilhar armazenamento. As SAN são constituídas por um dispositivo de armazenamento, a infraestrutura de rede de interligação (comutadores, adaptadores de barramento anfitrião e cablagem) e os servidores que estão ligados a essa rede. Os dispositivos SAN fornecem acesso rápido e contínuo a grandes quantidades de dados. O mecanismo de transferência de dados e de comunicação para uma determinada implementação é, geralmente, designado por recurso de infraestrutura de armazenamento.

As SAN utilizam uma rede independente e, regra geral, não estão acessíveis a outros dispositivos através da rede local. As SAN podem ser geridas através de SMI-S (Storage Management Initiative Specification), do protocolo SNMP (Simple Network Management Protocol) ou de um protocolo proprietário de gestão.

As SAN não fornecem abstração de ficheiros, apenas operações a nível de blocos. Os protocolos de SAN mais comuns são iSCSI, Canal de Fibra e FCoE (Fiber Channel over Ethernet). A norma SMI-S ou outro protocolo proprietário de gestão podem proporcionar capacidades adicionais, como zonas de disco, mapeamento de discos, máscara de LUN e gestão de falhas.

Vantagens	Desvantagens
As SAN utilizam uma rede independente, pelo que o impacto na rede de dados é limitado Fornecem acesso rápido e contínuo a grandes quantidades de dados Normalmente, oferecem funcionalidades adicionais, como replicação e proteção de dados Podem ser geridas entre várias equipas Suporte para Canal de Fibra Virtual, para proporcionar acesso direto a LUNs de armazenamento Suporte para clustering de convidados As máquinas virtuais que necessitem de acesso a volumes de dados superiores a 64 TB podem utilizar o Canal de Fibra Virtual para obter acesso direto a LUNs	Dispendiosas Requerem conhecimentos especializados para implementar, gerir e manter É necessário instalar os adaptadores de rede HBA ou FCoE em cada anfitrião. A migração de um cluster Hyper-V requer planeamento adicional e um período de indisponibilidade limitado. Para disponibilizar gestão de largura de banda para o tráfego FCoE, é necessária uma política QoS de hardware que utilize Datacenter Bridging. O tráfego FCoE não é encaminhável.

As SAN utilizam uma rede independente, pelo que o impacto na rede de dados é limitado
Fornecem acesso rápido e contínuo a grandes quantidades de dados
Normalmente, oferecem funcionalidades adicionais, como replicação e proteção de dados
Podem ser geridas entre várias equipas
Suporte para Canal de Fibra Virtual, para proporcionar acesso direto a LUNs de armazenamento
Suporte para clustering de convidados
As máquinas virtuais que necessitem de acesso a volumes de dados superiores a 64 TB podem utilizar o Canal de Fibra Virtual para obter acesso direto a LUNs

Dispendiosas
Requerem conhecimentos especializados para implementar, gerir e manter
É necessário instalar os adaptadores de rede HBA ou FCoE em cada anfitrião.
A migração de um cluster Hyper-V requer planeamento adicional e um período de indisponibilidade limitado.
Para disponibilizar gestão de largura de banda para o tráfego FCoE, é necessária uma política QoS de hardware que utilize Datacenter Bridging.
O tráfego FCoE não é encaminhável.

Opção 4: Partilhas de ficheiros Server Message Block 3.0

O Hyper-V pode armazenar ficheiros de máquinas virtuais, como, por exemplo, ficheiros de configuração, ficheiros de disco rígido virtual e pontos de verificação, em partilhas de ficheiros que utilizem o protocolo Server Message Block (SMB) 3.0. As partilhas de ficheiros encontram-se, normalmente, num servidor de ficheiros de escalamento horizontal, de modo a fornecer redundância. Ao executar um servidor de ficheiros de escalamento horizontal, se um nó estiver inativo, as partilhas de ficheiros continuam disponíveis a partir dos outros nós do servidor de ficheiros de escalamento horizontal.

Vantagens	Desvantagens
Opção para utilizar protocolos e redes existentes O SMB Multicanal fornece uma agregação de largura de banda e de tolerância a falhas se estiverem disponíveis vários caminhos entre o servidor que executa o Hyper-V e a partilha de ficheiros SMB 3.0. Pode utilizar os JBODs com a tecnologia Espaços de Armazenamento para combinar todos os discos físicos num agrupamento de armazenamento e, em seguida, criar um ou mais discos virtuais (chamados Espaços de Armazenamento) a partir do espaço livre no agrupamento. O SMB Multicanal pode ser utilizado para migrações de máquinas virtuais. Menos dispendiosas do que as implementações SAN Configurações de armazenamento flexíveis no servidor de ficheiros que executa o Windows Server Separam os serviços do Hyper-V dos serviços de armazenamento, o que lhe permite dimensionar cada serviço conforme necessário Garante flexibilidade ao atualizar para a versão seguinte ao executar um cluster Hyper-V. Pode atualizar os servidores que executam o Hyper-V ou os servidores de ficheiros de escalamento horizontal por qualquer ordem, sem período de indisponibilidade. É necessário capacidade suficiente no cluster para remover um ou dois nós para efetuar a atualização. O servidor de ficheiros de escalamento horizontal oferece suporte para VHDX partilhado A gestão de largura de banda SMB permite definir limites para a migração em direto, os discos rígidos virtuais e o tráfego de armazenamento predefinido. Suporte para encriptação de tráfego SMB com impacto mínimo no desempenho Permite poupar espaço em disco com a eliminação de duplicados de dados para implementações VDI Não requerem conhecimentos especializados para implementar, gerir e manter	O desempenho de E/S não é tão rápido como nas implementações SAN. A Eliminação de Duplicados de Dados não é suportada em ficheiros de máquinas virtuais em execução, exceto em implementações VDI.

Opção para utilizar protocolos e redes existentes
O SMB Multicanal fornece uma agregação de largura de banda e de tolerância a falhas se estiverem disponíveis vários caminhos entre o servidor que executa o Hyper-V e a partilha de ficheiros SMB 3.0.
Pode utilizar os JBODs com a tecnologia Espaços de Armazenamento para combinar todos os discos físicos num agrupamento de armazenamento e, em seguida, criar um ou mais discos virtuais (chamados Espaços de Armazenamento) a partir do espaço livre no agrupamento.
O SMB Multicanal pode ser utilizado para migrações de máquinas virtuais.
Menos dispendiosas do que as implementações SAN
Configurações de armazenamento flexíveis no servidor de ficheiros que executa o Windows Server
Separam os serviços do Hyper-V dos serviços de armazenamento, o que lhe permite dimensionar cada serviço conforme necessário
Garante flexibilidade ao atualizar para a versão seguinte ao executar um cluster Hyper-V. Pode atualizar os servidores que executam o Hyper-V ou os servidores de ficheiros de escalamento horizontal por qualquer ordem, sem período de indisponibilidade. É necessário capacidade suficiente no cluster para remover um ou dois nós para efetuar a atualização.
O servidor de ficheiros de escalamento horizontal oferece suporte para VHDX partilhado
A gestão de largura de banda SMB permite definir limites para a migração em direto, os discos rígidos virtuais e o tráfego de armazenamento predefinido.
Suporte para encriptação de tráfego SMB com impacto mínimo no desempenho
Permite poupar espaço em disco com a eliminação de duplicados de dados para implementações VDI
Não requerem conhecimentos especializados para implementar, gerir e manter

O desempenho de E/S não é tão rápido como nas implementações SAN.
A Eliminação de Duplicados de Dados não é suportada em ficheiros de máquinas virtuais em execução, exceto em implementações VDI.

SMB Direto

O SMB Direto funciona como parte das partilhas de ficheiros SMB. O SMB Direto requer adaptadores de rede e comutadores que suportem RDMA, de modo a proporcionar acesso de velocidade máxima e com baixa latência ao armazenamento. O SMB Direto permite que os servidores de ficheiros remotos se assemelhem a armazenamento local e a armazenamento de ligação direta. Para além das vantagens do SMB, o SMB Direto tem as seguintes vantagens e desvantagens.

Vantagens	Desvantagens
Funciona a velocidade máxima com baixa latência, utilizando muito pouca CPU Permite que um servidor de ficheiros de escalamento horizontal proporcione resiliência e desempenho de armazenamento, semelhante a uma SAN tradicional, ao utilizar soluções de armazenamento Microsoft e armazenamento de ligação direta partilhado pouco dispendioso. Fornece a opção mais rápida para migrações em direto e migrações de armazenamento	Não suportado com o Agrupamento NIC São necessários dois ou mais adaptadores de rede com RDMA ativado para ligações redundantes ao armazenamento.

Funciona a velocidade máxima com baixa latência, utilizando muito pouca CPU
Permite que um servidor de ficheiros de escalamento horizontal proporcione resiliência e desempenho de armazenamento, semelhante a uma SAN tradicional, ao utilizar soluções de armazenamento Microsoft e armazenamento de ligação direta partilhado pouco dispendioso.
Fornece a opção mais rápida para migrações em direto e migrações de armazenamento

Não suportado com o Agrupamento NIC
São necessários dois ou mais adaptadores de rede com RDMA ativado para ligações redundantes ao armazenamento.

Servidor de ficheiros de escalamento horizontal

Figura 3:Servidor de ficheiros de escalamento horizontal de exemplo que utiliza redes de convergência com RDMA

Informações adicionais:

Fornecer armazenamento rentável para cargas de trabalho do Hyper-V ao utilizar o Windows Server

Centro de Dados Convergido com Armazenamento do Servidor de Ficheiros

Deploy Hyper-V over SMB (Implementar o Hyper-V através de SMB)

Achieving over 1-Million IOPS from Hyper-V VMs in a Scale-Out File Server Cluster Using Windows Server 2012 R2 (Alcançar Mais de 1 Milhão de IOPS a partir de VMs do Hyper-V num Cluster de Servidores de Ficheiros de Escalamento Horizontal Utilizando o Windows Server 2012 R2)

Tarefa 3c: Definir os tipos de arquitetura da unidade física

O tipo de arquitetura da unidade física que selecionar para o armazenamento terá impacto no desempenho da sua solução de armazenamento. Para obter informações adicionais sobre os tipos de discos, consulte a Secção 7.1 do guia Infrastructure-as-a-Service Product Line Architecture (Arquitetura de Linha de Produto de Infraestrutura como Serviço).

Tarefa 3d: Definir o tipo de redes de armazenamento

Os tipos de controladores de armazenamento ou de controladores de redes de armazenamento que utilizar são determinados pela opção de armazenamento que selecionar para cada grupo de anfitriões. Para obter mais informações, consulte o Tarefa 3b: Opções de armazenamento.

Tarefa 3e: Determinar o tipo de armazenamento a utilizar para cada tipo de dados

Tendo conhecimento dos tipos de dados, poderá agora determinar que opção de armazenamento, controlador de armazenamento, controlador de redes de armazenamento e arquiteturas de disco físico melhor se adequam aos seus requisitos.

Decisão de design - as decisões que tomar nesta tarefa podem ser introduzidas na folha de cálculo Anfitriões de virtualização.

Informações adicionais:

Networking configurations for Hyper-V over SMB in Windows Server 2012 and Windows Server 2012 R2 (Configurações de redes para o Hyper-V através de SMB no Windows Server 2012 e no Windows Server 2012 R2)

Windows Server 2012 Hyper-V Component Architecture Poster and Companion References (Folheto e Referências Complementares da Arquitetura de Componentes do Windows Server 2012 Hyper-V)

Storage Technologies Overview (Descrição Geral das Tecnologias de Armazenamento)

Tarefa 4: Definir as unidades de escala do anfitrião de virtualização de servidores

A compra de servidores individuais requer aprovisionamento, instalação e configuração de cada servidor. As unidades de escala permitem comprar coleções de servidores (que, normalmente, contêm hardware idêntico). Estão pré-configuradas, o que lhe permite adicionar capacidade ao centro de dados ao acrescentar unidades de escala em vez de servidores individuais.

A imagem que se segue ilustra uma unidade de escala que podia ter sido comprada pré-configurada junto de vários fabricantes de hardware. Inclui um bastidor, uma fonte de alimentação ininterrupta (UPS), um par de comutadores de rede redundantes para os servidores contidos no bastidor e dez servidores.

Unidade de escala de anfitrião

Figura 4:Exemplo de uma unidade de escala de anfitrião de servidor de virtualização

A unidade de escala vem pré-configurada e pré-ligada por cabos à UPS e aos comutadores de rede. Basta adicioná-la a um centro de dados e ligá-la à corrente elétrica e à rede e ao armazenamento. Está, então, pronta para ser utilizada. Se os componentes individuais não tiverem sido adquiridos como uma unidade de escala, o comprador terá de montar e ligar todos os componentes.

Decisão de design - se optar por utilizar unidades de escala de anfitriões de virtualização de servidores, pode definir o hardware para as mesmas na folha de cálculo Unidades de escala de anfitrião.

Sugestão: Pode comprar unidades de escala pré-configuradas junto de diversos parceiros de hardware da Microsoft através do programa Microsoft Private Cloud Fast Track.

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

Os anfitriões de servidores de virtualização podem ficar indisponíveis por motivos planeados (como manutenção) ou motivos não planeados. Seguem-se algumas estratégias que podem ser utilizadas em ambos os casos.

Planeado

Pode utilizar a migração em direto para mover as máquinas virtuais de um anfitrião para outro. Este procedimento não requer qualquer período de indisponibilidade para as máquinas virtuais.

Não planeado

Este cenário depende dos tipos de caracterização de cargas de trabalho que o anfitrião está a alojar.

Para cargas de trabalho com monitorização de estado partilhado, utilize o Clustering de Ativação Pós-falha nas máquinas virtuais.
Para cargas de trabalho com monitorização de estado, execute como máquina virtual de elevada disponibilidade num cluster Hyper-V.
Para cargas de trabalho sem monitorização de estado, inicie novas instâncias manualmente ou através de algum meio automatizado.

Se estiver a utilizar o Clustering de Ativação Pós-falha no Windows Server com o Hyper-V, considere se deve utilizar as funcionalidades apresentadas na tabela seguinte. Para obter informações adicionais sobre cada funcionalidade, clique na hiperligação.

Funcionalidade	Considerações
Monitorização de aplicações do Hyper-V	Monitorize máquinas virtuais relativamente a falhas na rede e no armazenamento, que não são monitorizadas pelo serviço Clustering de Ativação Pós-falha.
Definições de prioridades da máquina virtual	Defina a prioridade da máquina virtual, com base na carga de trabalho. Pode atribuir as seguintes definições de prioridade a máquinas virtuais de elevada disponibilidade (também designadas por máquinas virtuais em cluster): Alta Média (predefinição) Baixa Sem Início Automático As funções em cluster com prioridade mais alta são iniciadas e colocadas em nós antes das funções com prioridade mais baixa. Se for atribuída a prioridade Sem Início Automático, a função não fica online automaticamente depois de falhar, o que mantém os recursos disponíveis para que possam ser iniciadas outras funções.
Antiafinidade das máquinas virtuais	Defina a antiafinidade das máquinas virtuais que não pretende que sejam executadas no mesmo nó num cluster Hyper-V. Pode aplicar-se a máquinas virtuais que forneçam serviço redundante ou que façam parte de um cluster de máquinas virtuais convidadas. Nota: as definições de antiafinidade são configuradas através do Windows PowerShell.
Drenagem automatizada de nós	O cluster drena automaticamente um nó (move as funções em cluster que estão em execução no nó para outro nó) antes de o colocar no modo de manutenção ou de efetuar outras alterações ao mesmo. As funções executam a reativação pós-falha para o nó original após as operações de manutenção. Os administradores podem drenar um nó com uma única ação no Gestor de Clusters de Ativação Pós-falha ou através do cmdlet Suspend-ClusterNode do Windows PowerShell. É possível especificar o nó de destino para as funções em cluster movidas. A Atualização com Suporte para Clusters utiliza a drenagem de nós no processo automatizado para aplicar atualizações de software aos nós de cluster.
Atualização com Suporte para Clusters	A Atualização com Suporte para Clusters permite atualizar nós num cluster sem causar impacto nas máquinas virtuais em execução nesse cluster. Durante o processo de atualização, tem de permanecer disponível um número suficiente de nós de cluster para processar a carga das máquinas virtuais em execução.
Preempção de máquinas virtuais com base na prioridade	Outro motivo para definir a prioridade das máquinas virtuais é o facto de o serviço Cluster poder colocar offline uma máquina virtual com prioridade mais baixa quando outra com prioridade alta não dispõe da memória suficiente e de outros recursos para ser iniciada. A preempção começa com a máquina virtual com a prioridade mais baixa e avança para as máquinas virtuais com prioridade mais alta. As máquinas virtuais interrompidas são reiniciadas mais tarde, por ordem de prioridade.

Nota: os clusters Hyper-V podem ter um máximo de 64 nós e 8.000 máquinas virtuais.

Passo 5: Planear conceitos de arquitetura da infraestrutura de virtualização

Este passo requer a definição de conceitos lógicos com os quais a arquitetura da infraestrutura será alinhada.

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

Os domínios de manutenção são coleções lógicas de servidores que são submetidos a manutenção em conjunto. A manutenção pode incluir atualizações de hardware ou software ou alterações de configuração. Normalmente, os domínios de manutenção distribuem grupos de anfitriões de cada tipo ou dentro de cada localização, embora não tenham de o fazer. O objetivo é evitar que a manutenção do servidor afete negativamente qualquer carga de trabalho dos consumidores.

Nota: este conceito aplica-se a componentes de armazenamento e de rede físicos.

Tarefa 2: Definir domínios físicos de falhas

Muitas vezes, os grupos de anfitriões de servidores de virtualização falham em conjunto, como consequência de um componente de infraestrutura partilhado com falhas, como, por exemplo, um comutador de rede ou uma fonte de alimentação ininterrupta (UPS). Os domínios físicos de falhas ajudam a apoiar a resiliência na infraestrutura de virtualização. É importante compreender de que modo é que um domínio de falhas afeta cada um dos grupos de anfitriões que definiu para a sua infraestrutura.

Nota: este conceito aplica-se a componentes de armazenamento e de rede físicos.

Considere o exemplo na imagem seguinte, que sobrepõe domínios físicos de falhas e de manutenção numa coleção de grupos de anfitriões num centro de dados.

Domínio de falhas

Figura 5:Exemplo de uma definição de domínio físico de falhas e de manutenção

Neste exemplo, cada bastidor de servidores está definido como um domínio físico de falhas numerado e separado. Isto acontece porque cada bastidor contém um comutador de rede na parte superior e uma UPS na parte inferior. Todos os servidores no bastidor dependem destes dois componentes e, se um deles falhar, todos os servidores no bastidor falham efetivamente.

Uma vez que todos os servidores no bastidor também são membros de grupos de anfitriões exclusivos, esta estrutura significaria que não existe mitigação em caso de falha de qualquer um dos domínios físicos de falhas. Para mitigar os problemas, poderia adicionar domínios físicos de falhas de cada tipo de grupo de anfitriões. Em ambientes mais pequenos, poderia adicionar, potencialmente, fontes de alimentação e comutadores redundantes em cada bastidor ou utilizar o Clustering de Ativação Pós-falha nos anfitriões de servidores de virtualização em todos os domínios físicos de falhas.

Na Figura 5, cada uma das caixas com linhas tracejadas coloridas define um domínio de manutenção (estão identificados como MD 1 até 5). Repare como cada um dos servidores no cluster com balanceamento de carga de máquinas virtuais está alojado num anfitrião de virtualização de servidor que está contido num domínio de manutenção separado e num domínio físico de falhas.

Isto permite que o administrador da infraestrutura desative todos os anfitriões de servidor de virtualização num domínio de manutenção sem afetar significativamente as aplicações que tenham vários servidores distribuídos por domínios de manutenção. Também significa que a aplicação que está a ser executada no cluster com balanceamento de carga não fica completamente indisponível se um domínio físico de falhas falhar.

Decisão de design - as decisões que tomar nas Tarefas 1 e 2 podem ser introduzidas na folha de cálculo Definições.

Tarefa 3: Definir a capacidade de reserva

A falha de servidores individuais na infraestrutura é inevitável. O design da infraestrutura tem de se adaptar a falhas de servidores individuais, do mesmo modo que se adapta a falhas de coleções de servidores em domínios de manutenção e de falhas. A ilustração seguinte é idêntica à Figura 5, mas utiliza o vermelho para identificar três servidores com falhas.

Servidores falhados

Figura 6:Servidores com falhas

Na Figura 6, os anfitriões de virtualização de servidor falharam nos seguintes grupos de anfitriões, domínios de manutenção e domínios físicos de falhas.

Grupo de anfitriões	Domínio físico de falhas	Domínio de manutenção
2	2	3
3	3	2
4	4	2

A aplicação que está a ser executada no cluster com balanceamento de carga continua disponível, mesmo apesar de o anfitrião no Domínio físico de falhas 2 ter falhado, mas a aplicação funcionará com menos um terço de capacidade.

Considere o que aconteceria se o anfitrião de virtualização de servidor que alojou uma das máquinas virtuais no Domínio físico de falhas 3 também falhasse ou se o Domínio de manutenção 2 fosse desativado para manutenção. Nestes casos, a capacidade da aplicação diminuiria em 2/3.

Poderá considerar que tal é inaceitável para a sua infraestrutura de virtualização. Para mitigar o impacto dos servidores com falhas, pode certificar-se de que cada um dos domínios físicos de falhas e dos domínios de manutenção tem capacidade de reserva suficiente, para que a capacidade nunca fique abaixo do nível aceitável que definir.

Para obter mais informações sobre o cálculo da capacidade de reserva, consulte Reserve Capacity (Capacidade de Reserva) no artigo Cloud Services Foundation Reference Architecture – Principles, Concepts, and Patterns (Arquitetura de Referência do Cloud Services Foundation – Princípios, Conceitos e Padrões).

Passo 6: Planear as características de capacidade inicial

Depois de concluir todas as tarefas deste documento, será capaz de determinar os custos iniciais para alojar máquinas virtuais e armazenamento na infraestrutura, para além dos níveis de qualidade de serviço iniciais que a infraestrutura pode atingir. No entanto, não conseguirá finalizar nenhuma destas tarefas enquanto não implementar as ferramentas de gestão de infraestrutura e os recursos humanos, que são abordados na secção Passos Seguintes deste documento.

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

Como administrador da infraestrutura, é provável que queira definir um contrato de nível de serviço (Service Level Agreement, SLA) que descreva em detalhe as métricas da qualidade de serviço que a infraestrutura irá cumprir. Os administradores das suas máquinas virtuais terão de ter esta informação, de modo a poderem planear de que forma irão utilizar a infraestrutura.

No mínimo, estas métricas incluirão uma métrica de disponibilidade, mas poderão incluir outras. Para ficar com uma ideia de uma linha de base quanto às métricas SLA da infraestrutura de virtualização, pode analisar as métricas disponibilizadas pelos fornecedores de nuvem pública, como o Microsoft Azure. Para o alojamento de máquinas virtuais, este SLA garante que, quando um cliente implementar duas ou mais instâncias de uma máquina virtual que execute a mesma carga de trabalho e as implementar em domínios de falhas e de atualização (referidos como “domínios de manutenção” neste documento) diferentes, pelo menos uma dessas 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. Idealmente, a sua infraestrutura de virtualização irá cumprir ou exceder os SLAs dos fornecedores de nuvem pública.

Tarefa 2: Definir os custos iniciais do alojamento de armazenamento e de máquinas virtuais

Tendo a infraestrutura concebida, também será capaz de calcular:

Os custos com hardware, espaço, energia e refrigeração da infraestrutura
A capacidade de alojamento da infraestrutura

Estas informações, juntamente com os seus outros custos, como, por exemplo, os custos das ferramentas de gestão da infraestrutura e dos recursos humanos, permitir-lhe-ão determinar os custos finais do alojamento de máquinas virtuais e de armazenamento.

Para ficar com uma ideia dos custos de linha de base relativos a máquinas virtuais e a armazenamento, pode analisar os custos de alojamento de fornecedores de nuvem pública, como o Microsoft Azure. Para obter mais informações, consulte os Detalhes dos Preços das Máquinas Virtuais.

Embora não seja sempre este o caso, é comum achar que os custos de alojamento são mais elevados do que os custos de fornecedores públicos, porque a sua infraestrutura será muito mais pequena do que as dos fornecedores públicos de grande dimensão, que conseguem obter descontos de volume em hardware, espaço nos centros de dados e energia.

Próximos passos

Depois de concluir todas as tarefas deste documento, terá um design de infraestrutura que preenche os requisitos da sua organização. Terá também uma definição das características do serviço inicial, que inclui os custos e as métricas de nível de serviço. Não será capaz de determinar os custos e as métricas de nível de serviço finais enquanto não souber os custos com recursos humanos nem os processos e ferramentas de gestão que irá utilizar na sua infraestrutura.

O Microsoft System Center 2012 disponibiliza um conjunto completo de funcionalidades para permitir o aprovisionamento, a monitorização e a manutenção da sua infraestrutura de virtualização. Para obter mais informações sobre como utilizar o System Center para a gestão de recursos de infraestrutura, leia os seguintes recursos:

System Center Technical Documentation Library (Biblioteca de Documentação Técnica do System Center)

Fabric Management Architecture Guide (Guia da Arquitetura de Gestão de Recursos de Infraestrutura)