. : Snapshots

Considerações sobre a virtualização de controladores de domínio

Marcos David Nogueira — Fri, 23 Jul 2010 16:36:00 GMT

Este post descreve algumas considerações de como implementar controladores de domínio em máquinas virtuais. Há várias práticas comuns de máquina virtual que deve evitar ao implementar controladores de domínio. Também há considerações especais para sincronização de data/hora e armazenamento.

Práticas de implementação de virtualização a serem evitadas

As plataformas de virtualização, como o Hyper-V, oferecem uma série de recursos convenientes que tornam a gestão, a manutenção, o backup e a migração de computadores mais fáceis. No entanto, há algumas práticas e recursos comuns de implementações que não devem ser usadas em controladores de domínio virtuais. A seguinte lista descreve essas mesmas práticas a serem evitadas ao implementar controladores de domínio:

· Não implemente VHDs (discos rígidos virtuais) diferenciais em uma máquina virtual que esteja configurada como um controlador de domínio. Isso torna a reversão para uma versão anterior muito fácil, e também reduz o desempenho.

· Não clone a instalação de um sistema operativo sem usar o Sysprep.exe, pois o SID (identificador de segurança) do computador não será actualizado.

· Para ajudar a evitar uma possível situação de reversão do USN (número de sequência de actualização), não use cópias de um arquivo VHD que represente um controlador de domínio já implementado para implementar controladores de domínio adicionais. Os próximos três itens nessa lista também são recomendados para ajudar a evitar uma possível reversão do USN.

· Não use o recurso Exportar do Hyper-V para exportar uma máquina virtual que esteja a executar como controlador de domínio.

NOTA A execução do Sysprep em um controlador de domínio danifica a instalação do AD DS. Use Sysprep antes de instalar a função AD DS para gerar um novo SID para essa instalação.

Migração física para virtual

O System Center Virtual Machine Manager (VMM) 2008 R2 fornece a gestão unificada de máquinas físicas (hosts) e virtuais (guests). Também fornece o recurso para migrar uma máquina física para uma máquina virtual. Esse processo é conhecido como conversão de máquina física em virtual (conversão P2V). Durante o processo de conversão P2V, a nova máquina virtual e o controlador de domínio físico que está a ser migrado não devem estar ligados ao mesmo tempo para evitar uma situação de reversão do USN.

Deve executar a conversão P2V usando o modo offline para que os dados do directório estejam consistentes quando o controlador de domínio for ligado novamente. A opção de modo offline é oferecida e recomendada no Assistente Convert Physical Server. Para obter uma descrição da diferença entre os modos online e offline, consulte o post relacionado com a conversão P2V: Conversão P2V no System Center Virtual Machine Manager (SCVMM). Durante a conversão P2V, a máquina virtual não deve estar conectada à rede. A NIC (placa de interface de rede) da máquina virtual deve ser habilitada somente depois que o processo de conversão P2V é concluído e verificado. Neste ponto, a máquina de origem física deve estar desligada. Não coloque a máquina de origem física de volta na rede antes de formatar o disco rígido.

NOTA Para evitar problemas com a replicação do Active Directory, verifique se apenas uma instância (física ou virtual) de um controlador de domínio específico existe em uma determinada rede a qualquer momento.

Utilizar a migração P2V para criar ambientes de teste

Pode usar a migração P2V no VMM para criar ambientes de teste. Pode migrar controladores de domínio de produção, de máquinas físicas para máquinas virtuais para criar um ambiente de teste sem reduzir permanentemente os controladores de domínio de produção. No entanto, o ambiente de teste deverá estar em uma rede diferente do ambiente de produção, para não existirem duas instâncias do mesmo controlador de domínio. Tome muito cuidado ao criar ambientes de teste com a migração P2V para evitar reversões de USN que podem afectar seus ambientes de teste e produção. Este é um método que pode usar para criar ambientes de teste com P2V.

Um controlador de domínio em produção de cada domínio é migrado para uma máquina virtual de teste usando P2V de acordo com as directrizes informadas na seção Migração física para virtual. As máquinas de produção físicas e as máquinas virtuais de teste deverão estar em redes diferentes quando ficarem online novamente. Para evitar reversões de USN no ambiente de teste, todos os controladores de domínio a serem migrados de máquinas físicas para virtuais devem ficar offline. (Pode fazer isso, ao parar o serviço ntds ou reiniciar o computador no DSRM (Modo de Restauração dos Serviços de Directório).) Depois que os controladores de domínios estiverem offline, nenhuma nova actualização deverão ser introduzidos ao ambiente. Os computadores devem permanecer offline durante a migração P2V; nenhum dos computadores deve ficar online até que todos os computadores tenham sido migrados totalmente.

Os controladores de domínio de teste subsequentes devem ser promovidos como réplicas no ambiente de teste.

Serviço de data/hora

Nas máquinas virtuais configuradas como controladores de domínio, desabilite a sincronização de data/hora com o host por meio dos Serviços de Integração. Em vez disso, aceite a sincronização padrão de data/hora da hierarquia de domínios do serviço de tempo do Windows (W32time).

A sincronização de data/hora do host torna possível que os sistemas operativos convidados sincronizem seus relógios do sistema com o relógio do sistema operativo host. Como os controladores de domínio têm seu próprio mecanismo de sincronização de data/hora, a sincronização de data/hora do host deve ser desabilitada nas máquinas virtuais configuradas como controladores de domínio. Se os controladores de domínio sincronizarem a data/hora de sua própria origem e também sincronizarem a data/hora do host, a data/hora do controlador de domínio mudará frequentemente. Como muitas tarefas do controlador de domínio estão vinculadas à hora do sistema, um salto na hora do sistema poderá fazer com que objectos persistentes sejam deixados no directório e a replicação seja interrompida.

Pode desabilitar a sincronização de data/hora do host nas configurações da máquina virtual, na secção Integration Services do Gestor do Hyper-V, ao desmarcar a caixa de selecção Time Synchronization.

Armazenamento

Para optimizar o desempenho da máquina virtual do controlador de domínio, pode usar as seguintes recomendações para armazenar arquivos do sistema operativo, do Active Directory e do VHD:

· Armazenamento do Guest Armazene o arquivo de base de dados do Active Directory (Ntds.dit), os arquivos de log e os arquivos SYSVOL em um disco virtual separado dos arquivos do sistema operativo. Os Componentes de Integração devem ser instalados para que drivers sintéticos possam ser usados na interface IDE (Integrated Drive Electronics), em vez da emulação. Os discos virtuais SCSI e IDE são executados na mesma velocidade quando usam drivers sintéticos.

· Armazenamento do host de arquivos VHD Recomendações: As recomendações do armazenamento do host abordam o armazenamento de arquivos VHD. Para obter um máximo desempenho, não armazene arquivos VHD em um disco que seja usado frequentemente por outros serviços ou aplicativos, como o disco do sistema no qual o sistema operativo Windows host está instalado. Armazene cada arquivo VHD em uma partição separada do sistema operativo host e de quaisquer outros arquivos VHD. A configuração ideal é armazenar cada arquivo VHD em uma unidade de disco física separada.

· VHD fixo versus discos pass-through Há muitas maneiras de configurar o armazenamento para máquinas virtuais. Quando os arquivos VHD são usados, os VHDs de tamanho fixo são mais eficientes que os VHDs dinâmicos, porque a memória dos VHDs de tamanho fixo é alocada quando eles são criados. Os discos de passagem, que as máquinas virtuais podem usar para aceder a mídia de armazenamento físico, estão ainda mais optimizados para desempenho. Os discos pass-through são essencialmente discos físicos ou LUNs (números de unidade lógica) conectados a uma máquina virtual. Os discos pass-through não oferecem suporte ao recurso de snapshot. Por isso, eles são a configuração de disco rígido preferencial, pois o uso de snapshot com controladores de domínio não é nada recomendável.

Para reduzir a chance de corrupção de dados do Active Directory, use os controladores SCSI ou desabilite o armazenamento de gravação em cache nas unidades ATA/IDE:

· Use unidades físicas SCSI (em oposição às unidades IDE/ATA) nos servidores Hyper-V que hospedam controladores de domínio virtuais. Se não puder usar unidades SCSI, verifique se o armazenamento de gravação em cache está desabilitado nas unidades ATA/IDE que hospedam controladores de domínio virtuais.

· Use controladores SCSI virtuais em qualquer máquina virtual que funciona como um controlador de domínio. Se não puder usar controladores SCSI virtuais, verifique se o armazenamento de gravação em cache está desabilitado nas unidades IDE virtuais das máquinas virtuais que funcionam como controladores de domínio. Pode ver o tipo de controladores de disco que são instalados na caixa de diálogo Configurações do Virtual Machine Manager.

Como lidar com VMs e as quebras canal de segurança (secure channel) ao fazer snapshots.

Marcos David Nogueira — Fri, 06 Nov 2009 21:06:00 GMT

Com a virtualização cada vez mais presente, a utilizações de cenários de teste utilizando o Hyper-V aumenta de uma forma significativa. Durante esses testes, a utilização de snapshots o tempo todo para proteger dos erros/teste e das falhas de alterações, é cada vez mais frequente. É um recurso fantástico, mas por vezes pode o colocar em problemas.

Em um mundo perfeito, quando estiver trabalhar com um cenário de teste que inclui um controlador de domínio e vários membros do domínio, ao necessitar de fazer um snapshot das máquinas virtuais, teria de fazer snapshot de todas as VMs utilizadas no cenário do ensaio e teria de fazê-lo, exactamente o mesmo tempo. Isto significa que todas as VMs iria ser salvas em uma configuração ideal.

O problema com esse mundo perfeito é que talvez queira uma única máquina para executar um teste e, em seguida, ser capaz de fazer rollback. Mas se não fizer snapshots de todas as VMs ao mesmo tempo, corre o risco de uma das máquinas virtuais alterar a sua senha de canal seguro (secure channel) durante o período de teste. Quando for reverter as alterações durante a sessão, e tentar fazer login, irá receber uma mensagem de erro dizendo que o relacionamento de confiança com o controlador de domínio está quebrado. A única opção é remover e adicionar novamente o computador ao domínio.

Existe uma solução para este problema. Pode desabilitar a conta do computador de alterar sua senha do canal seguro (secure channel), ou pode alterar a janela de alteração de senha para algo mais do que o padrão 30 dias. Ao fazê-lo eliminará o problema de não poder fazer logon. Agora, claro que gostaria de fazer isso em um ambiente de produção, mas não sem compreender totalmente as alterações e os riscos de segurança que advêm.

Para fazer a alteração, abra o editor da GPO (pode ser através do GPMC - Group Policy Management Console) e vá para

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

Habilite a opção Domain Member: Disable machine account password changes ou edite a opção Domain Member: Maximum machine account password age e aumente o valor do padrão de 30 dias para um novo valor maior (até ao máximo de 999 dias)

Fazer uma destas opções deve impedi-lo de obter a mensagem de terrível que o canal seguro (secure channel) é quebrado.

Upgrade do Windows Server 2008 R2 a partir do Windows Server 2008 com Hyper-V

Marcos David Nogueira — Fri, 04 Sep 2009 09:55:00 GMT

Este guia pretende descrever métodos que pode ser utilizado para fazer upgrade para o Windows Server 2008 R2 a partir de uma instalação do Windows Server 2008 que tem a função Hyper-V activada.

Nota Este guia aplica-se ao processo de upgrade do Windows Server 2008 RTM e do Windows Server 2008 Service Pack 2 (SP2).

Para migrar máquinas virtuais para o novo cluster, tem de ser utilizado o método 2 ou o método 3.

Método 1

Efectuar a actualização directa da partição principal do Windows Server 2008 para o Windows Server 2008 R2.

Nota Durante a actualização, o relatório de compatibilidade informará que tem de remover a função Hyper-V utilizando o Server Manager antes de continuar com a actualização. Não é necessário. No entanto, antes de continuar com a actualização, tenha em atenção ao seguinte:

· Todas as máquinas virtuais têm de ser encerradas antes da actualização. A funcionalidade de Saved States é incompatível entre o Windows Server 2008 e Windows Server 2008 R2. Se a partição principal for actualizada com quaisquer máquinas virtuais em um estado Saved, deve clique com o botão direito do rato na máquina virtual e, em seguida, clique em Discard saved state para activar a máquina virtual.

· Uma vez que a funcionalidade de Snapshot utiliza a funcionalidade de Saved State, snapshots não são totalmente compatíveis entre o Windows Server 2008 e Windows Server 2008 R2. As máquinas virtuais irão iniciar com êxito se o snapshot que existe for aplicado, antes da actualização, na máquina virtual enquanto esta tiver encerrada. Isto é indicado no Hyper-V Manager pela seta verde em snapshot que aponta para Now.

Para activar a máquina virtual com outro snapshot, siga estes passos:

Nota Os seguintes passos supõe que tem que continuar a utilizar todos os snapshots configurados para a máquina virtual. Se já não necessitar dos snapshots, pode eliminar os snapshots utilizando o Hyper-V Manager e, em seguida, encerrar a máquina virtual para os dados serem gravados com os do disco rígido virtual principal.

1. No Hyper-V Manager, clique com o botão direito do rato no snapshot que pretende aplicar e, em seguida, clique em Take Snapshot and Apply. Esta acção irá fazer um novo snapshot do snapshot actualmente aplicado. Este novo snapshot agora será compatível com Windows Server 2008 R2. Se seleccionar esta opção, quaisquer alterações que pode ter efectuado para o estado da máquina virtual da desde o último início serão guardados.

2. Depois do novo snapshot estar feito, a máquina virtual entra em saved state. Clique com o botão direito do rato na máquina virtual e clique em Delete saved state.

3. Active a máquina virtual.

4. Quando a máquina virtual tiver sido iniciada, repita estes passos até haver um snapshot restante.

5. Quando chegou o último snapshot, tire um snapshot de novo para capturar o estado actual da máquina virtual para ter um snapshot compatível com o Windows Server 2008 R2.

· Após o upgrade, actualize o Integration Services. Para o fazer, abra a janela Virtual Machine Connection e, em seguida, clique em Insert Integration Services Setup Disk no menu Action.

Método 2

Exportar uma máquina virtual a partir de um servidor de Windows Server 2008 que tenha o Hyper-V activado e, em seguida, importá-los num servidor que tem o Windows Server 2008 R2 com Hyper-V activado.

Nota A máquina virtual tem de ser encerrada antes de exportá-la. Se exportar a máquina virtual com um estado saved, não pode restaurar a máquina virtual no Windows Server 2008 R2. Para iniciar a máquina virtual depois de importar para o Windows Server 2008 R2, tem de eliminar o estado saved antes de poder activar na máquina virtual.

Se a máquina virtual tiver snapshots, estes snapshots têm de ser aplicados antes da exportação ou utilizar os passos do método 1 para recuperar e recriar os snapshots.

Depois de importar a máquina virtual, actualize o Integration Services. Para o fazer, abra a janela Virtual Machine Connection e, em seguida, clique em Insert Integration Services Setup Disk no menu Action.

Método 3

Para utilizar software de cópia de segurança que utilize o Hyper-V VSS Writer, faça backup da máquina virtual que está em execução no Windows Server 2008 e, em seguida, restaure no Windows Server 2008 R2.

Depois de restaurar a máquina virtual, actualize o Integration Services. Para o fazer, abra a janela Virtual Machine Connection e, em seguida, clique em Insert Integration Services Setup Disk no menu Action.

Snapshots de Máquina Virtual no Windows Server 2008 Hyper-v

Marcos David Nogueira — Wed, 15 Jul 2009 15:38:00 GMT

Os Snapshots de uma máquina virtual são ficheiros baseados no estado, nos dados do disco e na configuração da máquina virtual num determinado ponto no tempo. Pode-se tirar vários Snapshots de uma máquina virtual, mesmo que a VM esteja online. Em seguida, pode reverter a máquina virtual a qualquer dos Estados anteriores aplicando-se um snapshot à máquina virtual.

Para ter um snapshots, pode utilizar Hyper-V Manager ou Virtual Machine Connection. Todas as outras tarefas que pode executar com Snapshots, como aplicar ou excluir um snapshots ou exibir a lista de todos os Snapshots para uma máquina virtual específica, estão disponíveis através do Hyper-V Manager. Também pode inspeccionar ou editar os ficheiros .avhd, bem como determinar em qual snapshots um ficheiro de .avhd está associado.

NOTA Não edite um disco rígido virtual quando é utilizado por uma máquina virtual com Snapshots.

Considerações sobre Snapshots de máquina virtual

Os Snapshots podem ajudar a aumentar a eficiência em muitas configurações onde pode precisar de recriar diferentes ambientes e reproduzir várias condições nesses ambientes. Alguns exemplos incluem o desenvolvimento de software e teste, serviços de suporte técnico e desenvolvimento de currículos de formação.

Entretanto, o mesmo poder e flexibilidade que torna esses Snapshots, úteis e eficazes em determinadas configurações podem causar consequências indesejadas e potencialmente graves em outras configurações. Estas consequências incluem os riscos inerentes à perda de dados involuntária se os Snapshots não forem geridos apropriadamente. Por exemplo, se editar um disco rígido virtual ligado a uma máquina virtual com Snapshots, poderá ocorrer na perca de informação.

Umas das configurações mais apropriadas para o uso dos Snapshots são no desenvolvimento e teste de actividades, incluindo a utilização da máquina virtual como um servidor de teste para testar as actualizações e hotfixes antes de implantá-los para servidores de produção. Não é nada recomendável utilizar Snapshots em máquinas virtuais que prestam serviços sensíveis no tempo, tais como serviços do Active Directory, ou quando o desempenho ou a disponibilidade de espaço de armazenamento é crítica.

Além disso, deve considerar o seguinte antes de utilizar os Snapshots:

· Fazer um snapshots reduz o desempenho da máquina virtual, enquanto o snapshots é criado. Não deve usar esses Snapshots em máquinas virtuais que prestam serviços em um ambiente de produção.

· Não é recomendável o uso Snapshots em máquinas virtuais que estão configuradas com discos rígidos virtuais fixos, isto porque reduzem os benefícios de desempenho que podem de alguma forma adquirir ao utilizar discos rígidos virtuais fixos.

· Os Snapshots exigem espaço de armazenamento adequados. Os Snapshots são armazenados como ficheiros de .avhd no mesmo local no disco rígido virtual. Vários Snapshots podem rapidamente consumir uma grande quantidade de espaço de armazenamento. Quando usa Hyper-V Manager para excluir um snapshots, o snapshots é removido da árvore do snapshots, mas o ficheiro .avhd não é excluído até desligar a máquina virtual.

NOTA Não exclua ficheiros .avhd directamente do local de armazenamento.

· Os Snapshots de uma máquina virtual não são os mesmos como os Snapshots criados pelo VSS (volume sombra Copy Services). Snapshots da máquina virtual podem ser uma maneira útil para criar cópias de segurança temporárias de uma máquina virtual, mas não um substituto para uma solução de backup permanente.

Como funciona o QSM – Quick Storage Migration

Marcos David Nogueira — Tue, 07 Jul 2009 13:11:00 GMT

O QSM usa tecnologias da plataforma nativas do Windows: Hyper-V e BITS. No que diz respeito ao QSM, existe 2 cenários em que pode ser muito interessante:

Cenário 1 migração de armazenamento da VM (VM Storage Migration): A VM permanece no mesmo servidor e o armazenamento da VM é que vai migrar para um outro armazenamento.

1. Na console do SCVMM, está agora disponível uma nova acção rotulada de migração de armazenamento (Migrate Storage), conforme mostra a figura 1.

Figura 1 - Opções na consola do SCVMM, quando se secciona com o botão direito numa VM.

2. Quando o utilizador clica com o botão direito do rato em uma máquina virtual em execução e selecciona a acção de migração de armazenamento (Migrate Storage), é apresentado um assistente. O utilizador fornece o caminho para o novo local a ser utilizado pela VM. Se todos os ficheiros de VMs (configuração e ficheiros VHD) estão a ser colocados em um único local o utilizador tem somente de fornecer o "caminho de máquina virtual". Se um ou mais ficheiros VHD para a VM precisam de ser colocado em um local separado, o utilizador pode alterar explicitamente a localização de cada VHD seleccionando na lista em "discos" e clica no botão "procurar" próxima para especificar o caminho do VHD (Figura 2).

Figura 2 - Assistente Migrate Virtual Machine, onde selecciona o caminho da VM.

3.       O SCVMM faz um snapshot automático no Hyper-V da máquina virtual em execução. Essa operação vai criar um disco diferenciado para cada VHD ligado à VM. Todas as operações de gravação de disco a partir desse momento para a frente entram o disco diferenciado. O VHD base original já não está a ser mudado porque está no Estado de leitura.
4.       Com o VHD base em um Estado só de leitura, o SCVMM começa a transferir o ficheiro do local de origem para o local de destino usando BITS. Isto representa o grosso dos dados que precisa de ser transferido e a VM permanece em execução durante essa transferência. Além disso, QSM não depende de tipos de armazenamento, e o utilizador está livre para seleccionar qualquer destino de armazenamento que está acessível para o host Hyper-V.
5.       Uma vez o VHD base é transferida, a máquina virtual é colocada em "Estado de Saved".
6.       Em "Estado de Saved", o SCVMM pode transferir o disco diferenciado criado pelo snapshot automático e memória associado com o "Estado de Saved" para o local de destino para a VM.
7.       Depois de todos os ficheiros serem transferidos, o SCVMM exporta e, em seguida, reimporta a máquina virtual no mesmo host Hyper-V com as alterações necessárias na configuração.
8.       O snapshot automático criado na etapa 3 é mesclado de volta com a VHDs Base.
9.       A Máquina virtual é reiniciada do Estado salvo
10.    O job é completo.

O diagrama abaixo ilustra as etapas realizadas pelo QSM em um host Hyper-V R2.

Cenário 2 VM Migration (Relocação de VM): A VM é movida para um novo servidor e o armazenamento da VM também migra para um outro armazenamento.

1. Na console do SCVMM, o utilizador clica com o botão direito do rato numa máquina virtual em execução e selecciona a acção de migrar (Migrate) (Figura 3), o assistente é apresentado para ajudar com a migração. A ação de migrar, inicia a migração de uma VM de um host para outro host. Como parte da migração de VMs, todos os ficheiros de VMs são movidos para armazenamento que acompanha o host de destino. Tecnologia de armazenamento de migração aprimora a experiência, o que permite a passagem para uma máquina virtual em execução e limita o tempo de downtime da VM para apenas a janela de tempo necessário para mover os ficheiros no estado salvar Estado.

Figura 3 - Opções na consola do SCVMM, quando se selecciona com o botão direito numa VM.

2. O utilizador selecciona primeiro o host de destino baseado na classificação de estrelas apresentada pela Posicionamento inteligente (Intelligent Placement). O utilizador fornece, em seguida, a pasta de destino para o ficheiro de configuração e os discos virtuais associados. Por padrão, o assistente colocará todos os discos no mesmo local do ficheiro de configuração. Depois de concluir o assistente, é apresentado o job de migração.

Figura 4 - Assistente de migração. Através do Posicionamento Inteligente pode-se escolher o host.

3.       O SCVMM cria uma máquina virtual de espaço reservado no host de destino. A máquina virtual não está ligada portanto não há nenhuma necessidade de reserva de recursos de CPU ou memória neste momento. Posicionamento inteligente tem já contabilizado o impacto no host de destino da VM a ser migrada.
4.       O SCVMM faz um snapshot automático no Hyper-V da máquina virtual em execução. Essa operação vai criar um disco diferenciado para cada VHD ligado à VM. Todas as operações de gravação de disco a partir desse momento para a frente entram o disco diferenciado. O VHD base original já não está a ser mudado porque está no Estado de leitura.
5.       Com o VHD base em um Estado só de leitura, o SCVMM começa a transferir o ficheiro do local de origem para o local de destino usando BITS. Isto representa o grosso dos dados que precisa de ser transferido e a VM permanece em execução durante essa transferência. Além disso, QSM não depende de tipos de armazenamento, e o utilizador está livre para seleccionar qualquer destino de armazenamento que está acessível para o host Hyper-V.
6.       Uma vez que os VHDs base são transferidos, a máquina virtual é colocada em Estado de Saved. Em "Estado de Saved", o SCVMM pode transferir o disco diferenciado criado pelo snapshot automático e memória associado com o "Estado de Saved" para o local de destino para a VM.
7.       Depois de todos os ficheiros serem transferidos, o SCVMM exporta e, em seguida, reimporta a máquina virtual no mesmo host Hyper-V com as alterações necessárias na configuração.
8.       O snapshot automático criado na etapa 4 é mesclado de volta com a VHDs Base.
9.       A Máquina virtual é reiniciada do Estado salvo
10.    O job é completo.

Quick Storage Migration no System Center Virtual Machine Manager 2008 R2

Marcos David Nogueira — Thu, 02 Jul 2009 22:44:00 GMT

Foi lançado recentemente o Release Candidate para o System Center Virtual Machine Manager 2008 R2. Um dos recursos mais previsível do SCVMM 2008 R2 é o Quick Storage Migration (QSM) que permite a migração de armazenamento da VM de um local para outro. Por exemplo, suponha que tem máquinas virtuais em uma SAN (SAN 1). A locação de espaço esgota e decide fazer um upgrade para uma nova SAN (SAN 2) com maior capacidade, melhor desempenho e recursos adicionais. O Quick Storage Migration permite mover-se a máquina virtual que reside na SAN 1 para de SAN 2. Esta tecnologia está amplamente disponível nesta versão do SCVMM, e não apenas para as empresas maiores.

O QSM baseia-se no Windows Server 2008 R2 Hyper-V e no BITS (BACKGROUND Intelligent Transfer Service). O QSM pode mover os discos virtuais de uma máquina virtual em execução independentemente dos protocolos de armazenamento (iSCSI, FC) ou tipo de armazenamento (local, DAS, SAN), com um tempo de inactividade mínimo.

O QSM é uma das muitas tecnologias de migração suportadas pelo portfólio do Virtual Machine Manager

Tipo de migração de VM

Plataformas em que está disponível

Tecnologia usada para transferência

Tempo de inactividade esperada para a VM

Live Migration

· Hyper-V
(2008 R2)

· ESX 3.0, 3.5

· Cluster do Windows Server 2008 failover

· Hyper-V

· vMotion para ESX

Nenhum

· Sem interrupção de serviço enquanto máquina virtual é movida

Quick Migration

· Hyper-V

· Cluster do Windows Server 2008 failover

· Hyper-V

Em 1 minuto na maioria dos casos

· VM é posta em Salvar-Estado enquanto é movido de um nó de cluster para outro utilizando o mecanismo de failover de cluster

SAN Migration

· Virtual Server

· Hyper-V

· Windows Server 2008 Hyper-V e provedores de hardware de Virtual Disk Service (VDS)

· N-Port Identification Virtualization (NPIV) no Emulex e nos HBAs QLogic Fibre Channel

· iSCSI no EMC, no HP, no Hitachi, no NetApp, nos arrays do EquiLogic

Em 1 minuto na maioria dos casos

· VM é posta em Salvar-Estado enquanto é movido de um host de máquina virtual para outro utilizando o desmascarar e mascarar as operações a nível de SAN

Migração com base de rede

(aka LAN migration)

· Virtual Server

· Hyper-V

· ESX

· BITS para Virtual Server e Hyper-V

· sFTP para ESX

Minutos para horas (W2K8, W2K3 hosts)

· VM precisa de estar no estado parada ou salva durante a vigência da transferência

Em 1 minuto na maioria dos casos (W2K8 R2)

· VM pode permanecer em execução para quase toda a vigência da transferência dos discos virtuais de um local do armazenamento para outro

· VM é colocada no estado de salvar para num breve intervalo poder migrar o estado da memória e associar os discos diferenciais.

Tipo de migração de armazenamento

Plataformas em que está disponível

Tecnologia usada para transferência

Tempo de inactividade esperado

Storage vMotion

· ESX 3.5

· Storage vMotion

Nenhum

· Sem interrupção de serviço perceptível enquanto os discos virtuais associados à máquina virtual são movidos de um local de armazenamento para outro

Quick Storage Migration

· Hyper-V
(2008 R2)

· BITS e Hyper-V

Em 1 minuto na maioria dos casos (W2K8 R2)

· VM pode permanecer em execução para quase toda a vigência da transferência dos discos virtuais de um local do armazenamento para outro

· VM é colocada no estado de salvar para num breve intervalo poder migrar o estado da memória e associar os discos diferenciais.

Comparação do QSM com o VMware Storage VMotion

	VMM 2008 R2 + Windows Server 2008 R2 Hyper-V	VMware (vCenter 2.5 + ESX 3.5)
Migração de máquinas virtuais em dois hosts com armazenamento independente	Suporta	Não suportado
Migração de máquinas virtuais com snapshots	Suporta	Não suportado
Migração da máquina virtual com discos virtuais	Suporta	Suporta (em modo persistente)
Exige recursos suficientes para apoiar duas instâncias das máquinas virtuais que são executadas concorrentemente	Não obrigatório	Necessário
Licença adicional necessária	Nenhuma	Licença de VMotion
Número de migrações simultâneas permitidas	10	4
Migrações de armazenamento suportadas na console do administrador	Sim (QSM e Storage vMotion)	N.o
Migrações de armazenamento suportadas no CLI	Sim (QSM e Storage vMotion)	Sim
Protocolo agnóstico	Sim	Sim
Suporte para as migrações de VMs e armazenamento entre hosts com processadores diferentes versões (mesmo fabricante)	Sim (ao usar o modo de compatibilidade de processador do Hyper-V R2 para aumentar o número de hosts compatíveis)	Não aplicável

Sobre o modo de compatibilidade de processador

Para aumentar a mobilidade de uma máquina virtual em execução em hosts com versões de processador diferente (da mesma família de processador), Windows Server 2008 R2 Hyper-V oferece o modo de compatibilidade do processador. Este recurso máscara as diferenças de recurso de processador entre os hosts de origem e destino. Com isso habilitado, pode migrar uma máquina virtual de um host com processadores Pentium 4 VT para um host com processadores de Nehalem. Modo de compatibilidade de processador faz não exigir recursos de processador avançadas como a migração Intel VT Flex ou a migração AMD-V Extended. Pode ter mais detalhes num post anterior - Mais novidades no Windows Server Hyper-V 2008 R2

Conversão P2V no System Center Virtual Machine Manager (SCVMM)

Marcos David Nogueira — Fri, 05 Jun 2009 14:02:00 GMT

System Center Virtual Machine Manager (SCVMM) permite que converta computadores físicos existentes em máquinas virtuais através de um processo conhecido como conversão físico-para-virtual (P2V). O VMM simplifica a conversão P2V ao fornecer um assistente baseado em tarefas para automatizar muito o processo de conversão. Uma vez que o processo de P2V é totalmente programável, pode iniciar em grande escala conversões de P2V, através da linha de comando do Windows PowerShell.

Quais computadores físicos se pode converter?
Os requisitos para computadores de origem física dependem se estiva a executar um P2V online ou offline.

Conversões On-line vs Offline.
A tabela seguinte lista algumas das diferenças entre as conversões de P2V online e offline.

*Categoria*	*P2V online*	*P2V offline*
Disponibilidade de computador de origem	O computador de origem continua a realizar operações normais durante a conversão.	O computador de origem é colocado offline durante a conversão.
Processo	VMM cria uma cópia dos volumes locais NTFS e de dados das aplicações de VSS-aware. O VMM aproveita o copiar pelo serviço Volume Shadow Copy Service (VSS) para garantir que os dados são um backup consistentemente enquanto o servidor continua a ter solicitações do utilizador. O VMM usa o snapshot somente leitura para criar um VHD.	Reinicia o computador de origem para o Windows Preinstallation Environment (Windows PE), e, em seguida, o VMM clona o volume para um VHD. Por último, o VMM reinicia o computador de origem para o sistema operativo original.
Compatibilidade	P2V online é o padrão para os sistemas operativos na maior parte dos computadores físicos.	P2V offline é a única opção para conversão de Windows 2000 Server, o único método para migrar fielmente volumes FAT e o método recomendado para conversão de controladores de domínio.
Vantagens	Computador de origem está disponível em toda a conversão.	P2V offline pode ser a forma mais confiável de assegurar a consistência dos dados e é a única opção em certas situações (veja acima).

NOTA Com a conversão P2V online e offline, o VMM temporariamente instala um agente no computador de origem física para ser convertido.

Requisitos para a máquina de origem
Para executar uma conversão de P2V, o computador de origem:

Deve ter pelo menos 512 MB de RAM.
Deve ter uma configuração avançada e BIOS ACPI (interface de energia) – O Vista WinPE não irá instalar sobre uma configuração não-BIOS ACPI.
Deve ser acessível por VMM e o computador host.
Não pode estar em uma rede de perímetro (também conhecido como um DMZ, zona desmilitarizada e sub-rede filtrada) onde as definições de IPsec ou firewalls proíbem comunicação.
Deve conter uma das seguintes sistemas operacionais com suporte:
- O Windows Server 2008 (32 bits)
- O Windows Server 2008 (64 bits)
- Windows Server 2003 (32 bits) SP1 ou posterior
- Windows Server 2003 (64 bits) SP1 ou posterior
- Windows 2000 Server SP4 ou posterior (offline P2V apenas)
- Windows 2000 Advanced Server SP4 ou posterior (offline P2V apenas)
- Windows XP (32 bits) SP2 ou posterior
- Windows XP (64 bits) SP2 ou posterior
- Windows Vista (32 bits) SP1 ou posterior
- Windows Vista (64 bits) SP1 ou posterior

NOTA O VMM não suporta Conversão P2V em computadores de origem que corram o Windows NT Server 4.0. No entanto, pode usar o Microsoft Virtual Server 2005 Migration Toolkit (VSMT) ou soluções de terceiros para conversão de computadores que executam o Windows NT Server 4.0.

Requisitos para o servidor de host de destino
No VMM, um host é um computador físico no qual pode implementar uma ou mais máquinas virtuais. Para executar P2V, precisa de um host em que coloque a imagem do computador de origem.

Requisitos para o servidor host incluem:

Windows Server 2008 com Hyper-V ou Virtual Server 2005 R2 SP1 (ou posterior)
Windows Server 2003 com o Virtual Server 2005 R2 SP1 (ou mais tarde)
Não pode estar em uma rede de perímetro (também conhecido como um DMZ, zona desmilitarizada e sub-rede filtrada) onde as definições de IPsec ou firewalls proíbem comunicação.
Pelo menos mais 256 MB de RAM para a máquina virtual

Por padrão, a quantidade da memória reservada para o host de destino é 256 MB. Esta quantidade é além da memória necessária para cada máquina virtual no host. No Assistente para conversão do servidor físico, se o host não tiver memória suficiente, irá receber um erro de posicionamento.

Decidir quais computadores para converter
Para executar com êxito uma conversão P2V, deve ser capaz de identificar cargas de trabalho físicas adequadas para a consolidação no ambiente virtualizado. Esta analise irá ajudar a identificar quais computadores são bons candidatos para a conversão.

Identificar candidatos à virtualização
Se tiver implementado Microsoft System Center Operations Manager 2007, o VMM pode ajudá-lo identificar os servidores físicos certos para consolidação baseada na análise directa dos contadores de desempenho do computador de destino ou dados de histórico de desempenho armazenados na base de dados do Operations Manager.

O relatório de candidatos à virtualização irá ajudar a identificar computadores subaproveitados exibindo valores médios para um conjunto de contadores de desempenho comummente para CPU, memória, uso do disco, configurações de hardware, incluindo a velocidade do processador, número de processadores e RAM total. Para usar o relatório de candidatos à virtualização, deve implementar o System Center VMM 2008 Management Pack.

Prioridade dos candidatos à virtualização
Ao identificar os melhores candidatos para a conversão de P2V, considere converter esses tipos de computadores, na ordem de preferência:

Computadores subaproveitados não críticos ao negócio. Iniciar com os computadores menos utilizados que não sejam críticos para o negócio, pode aprender o processo de P2V com relativamente baixo risco. A nível de servidores os servidores Web podem fazer bons candidatos.
Computadores com hardware sem suporte ou desactualizados que precisa ser substituídos.
Computadores com baixo nível de utilização que estão a hospedar aplicativos internamente menos críticos.
Computadores com utilização superior que estão a hospedar aplicativos menos críticos.
Os restantes computadores subaproveitados.
Em geral, aplicações comerciais-críticas, tais como servidores de email e base de dados que são altamente utilizados, só devem ser virtualizadas para a plataforma Hyper-V no sistema operacional Windows Server 2008 (64 bits).

Como efectuar uma conversão de P2V
Durante uma conversão de P2V, imagens de disco dos discos rígidos no computador de origem são empacotadas em discos rígidos virtuais (ficheiros .vhd) e, em seguida, dispostas a garantir que o sistema operativo irá funcionará no ambiente virtualizado no host de destino.

Antes de começar
A lista a seguir inclui tarefas que deve executar antes de iniciar a conversão de P2V:

A primeira fase de uma conversão de P2V é a configuração de hardware do computador de origem de vistoria. Certifique-se que o cache de patch contém todos os drivers necessários e ficheiros de sistema para apoiar as unidades emuladas pelo software de virtualização de destino. Se quaisquer controladores estiverem a faltar, irá receberá mensagens de erro específico indicando onde obter os drivers necessários.

NOTA Pode usar o cmdlet Add-patches para fazer download manualmente dos patches disponíveis para o VMM.
Setores defeituosos no disco não podem ser transferidos durante uma conversão de P2V. Para evitar perda de dados, corra uma ferramenta de manutenção de disco, tais como o CHKDSK, no computador fonte para detectar e corrigir quaisquer erros de sistema de ficheiros.
Para ajudar a minimizar o tempo necessário para a fase de imagem, corra uma desfragmentação de disco nos discos rígidos do computador de origem. Além disso, garanta que tenha uma conexão de rede rápida entre o computador de origem e o host.
Use discos rígidos virtuais dinâmicos (VHD) para economizar espaço em disco no host de destino. Por exemplo, se converter 5 GB de dados em um disco rígido de 40 GB, VMM criará um dinamicamente expansão 40 GB VHD que ocupa cerca de 5 GB de espaço em disco e pode expandir até 40 GB. O tamanho real depende de fragmentação do volume original mais alguma sobrecarga de formato VHD.

NOTA Não é possível encolher o tamanho de um disco.
Para P2V online só: Certifique-se de que todos os aplicativos críticos em execução no computador de origem tenham escritores VSS-aware ou que estão parados.
Para offline P2V só: Esteja preparado para fornecer drivers de NIC e de armazenamento em massa que são compatíveis com o Windows Vista. VMM avaliará o computador físico de origem e irá comparar com os controladores incluídos no Windows PE 2.0 e fornece instruções sobre adicionar drivers no computador de origem.

O Assistente Conversão de Servidor Físico

Pode usar o Assistente de conversão do servidor físico para criar uma nova máquina virtual de um computador de origem física.

NOTA Pode fornecer o endereço IPv4 ou IPv6 em vez de nomes de computador ao Assistente de conversão do servidor físico ou a partir da linha de comando.
Depois de concluída a conversão P2V, remova qualquer utilitário desnecessário de fornecedor de hardware e controladores da máquina virtual.

NOTA O Assistente para converter servidor físico invoca o cmdlet New-P2V. Algumas opções de conversão só estão disponíveis a partir da linha de comando.

Executar P2V na linha de comando
Pode executar uma conversão de P2V a partir do Windows PowerShell utilizando o cmdlet New-P2V. Para obter um script básico que pode personalizar, execute o Assistente para converter máquina virtual a partir o VMM Administrator Console e clique no botão View Script.

Para obter mais informações sobre como usar o cmdlet New-P2V digite Get-Help New-P2V no Windows PowerShell.

O processo de P2V
O processo de conversão de P2V captura uma imagem do disco de origem e modifica o sistema operativo e controladores para torná-las compatíveis, ao fazer a emulação do hardware, com o Hyper-V ou Virtual Server. Conversões Online e offline P2V usam dois processos distintos:

Conversão online
Conversão online não requer uma reinicialização do computador de origem. O VMM usa o VSS (serviço de cópia de sombra de volume) para criar uma imagem da máquina de origem que é coerente a nível de aplicação e, em seguida, cria uma máquina virtual análoga. O processo de conversão online consiste em cinco etapas (Figura 2):

Instalação do agente no computador de origem
Recuperar a configuração de hardware
Imagens
Fixação
Criando a máquina virtual

Figura 2 – Processo de conversão P2V online

1.       Virtual Machine Manager instala o agente de P2V no computador de origem para reunir a configuração de hardware e software. Depois de concluída a conversão, o agente é removido.

Importante O agente VMM Windows Installer cria uma excepção de firewall para administração remota (serviço de RemoteAdmin) e a porta SSL (Secure Sockets Layer). Estas excepções são removidas quando o agente VMM é removido no final do processo de P2V. O padrão de porta de HTTPs é TCP 443.
2.       VMM reúne informação sobre o hardware do computador e configuração de software, do seguinte modo:
     2.1.     O agente VMM reúne informações sobre hardware, software, serviços, hotfixes e o layout de disco (sistema de ficheiros, tipo de volume). O agente VMM exporta esta informação para o base de dados do VMM como um ficheiro de configuração de máquina em formato XML.
     2.2.     VMM determina se a máquina de origem pode ser virtualizada. VMM confirma que o sistema operativo é suportado e que a configuração física pode ser feita compatível com o software de virtualização de destino. VMM verifica que os arquivos necessários estão presentes no cache de patch e faz downloads de qualquer patches ausentes no directório de importação de patch no servidor VMM.
3.       Fase de imagens:
     3.1.     Uma imagem de VSS (serviço de cópia de sombra de volume) é capturada para cada volume seleccionado que é coerente a nível de aplicação. Se um formato VHD destino dinâmico for seleccionado, esse processo captura dados só, e não o espaço vazio.
     3.2.     Dados são transmitidos directamente a partir do computador de origem para o host VMM utilizando o BITS (BACKGROUND Intelligent Transfer Service). O cliente de BITS é apenas no host de destino, e não no computador físico de origem.
     3.3.     Cada volume físico torna-se um disco rígido virtual separado.
4.       A correcção em uma fase. VMM prepara o sistema operativo e os discos rígidos virtuais para a criação de máquina virtual.
5.       Fase da criação da máquina virtual:
     5.1.     VMM cria a máquina virtual.
     5.2.     VMM atribui virtuais discos rígidos, adaptadores de rede, CD-ROM e a memória.

Conversão offline
P2V offline é a maneira mais fiável para assegurar a consistência dos dados, pois cria uma cópia exacta do computador de origem, enquanto ele não está em uso. Além disso, P2V offline é a única opção para converter o Windows 2000 Server, controladores de domínio e volumes de não-NTFS. Ao contrário de conversões online, o utilizador deve fornecer quaisquer drivers ausentes se o Windows PE não suportar o computador de origem. A conversão offline consiste em quatro etapas:

1.       Instalação do agente. Virtual Machine Manager instala o agente VMM no computador de origem.
2.       O agente VMM instala uma imagem do Windows PE no computador de origem, modifica o registo de inicialização e reinicia no Windows PE em vez do sistema operacional básico.
3.       VMM começa streaming discos físicos. Não há nenhum snapshots neste processo.
4.       O restante do processo de é semelhante da fase de corrigir e da fase de criar uma máquina virtual numa conversão P2V online.

Failover Cluster de Hyper-V

Marcos David Nogueira — Tue, 02 Jun 2009 20:33:00 GMT

Com a combinação de perfeita da tecnologia, pode-se aumentar a disponibilidade dos servidores. Converter os servidores físicos em virtuais, imediatamente obtemos recursos adicionais que pode torná-los menos prováveis de ir a baixo e é muito mais fácil os trazer de volta quando é utilizamos as devidas tecnologias, como:

Snapshots permite que volte no tempo de quando uma actualização de software ou configuração rebentar com a configuração de um servidor íntegro.
Virtual hard disks consolidar milhares de ficheiros que compõem um servidor Windows em um único arquivo para backups, que melhora significativamente a contabilidade desses backups.
Suporte de volume VSS (Volume Shadow Copy Service - serviço de cópias de sombra), que está disponível nativamente no Hyper-V, significa que aplicativos possam retornar de uma restauração com zero perda dos dados e imediatamente pronto para utilizar.
Recursos de migração melhora as actividades de tempo de inactividade planeado, ao fornecer um mecanismo para realocar o processamento de máquinas virtuais a novos hosts com pouca ou nenhuma interrupção no serviço.
Clusters de failover significa que a perda de um host virtual move automaticamente máquinas virtuais para novos locais onde eles podem continuar a fazer o seu trabalho.

A parte mais difícil em tudo isto é descobrir exactamente quais tecnologias que se precise implementar — e quais se podem arcar. Há uma relação directa entre os níveis de redundância que pode implementar em um ambiente de TI e o custo. Tendo isso em mente, ao adicionar uma tecnologia como cluster de failover do Windows Server 2008 à tecnologia Hyper-V pode ter prejudicial devido à complexidade percebida. Ainda assim é possível implementar, não necessariamente uma altamente confiável, mas uma "razoavelmente confiável" virtualização por um menor custo do que poderia pensar.

Para esse fim, podemos explorar uma solução muito simples que integra essas duas tecnologias. Esteja ciente de que esta implementação não dê imediatamente os mais altos níveis de disponibilidade, mas é uma solução mais simples, que pode implementar hoje. Depois de compreender as noções básicas, existem mais algumas maneiras de adicionar ainda mais, com custo adicional e com uma complexidade maior, é claro. Cabe ao orçamento que tem disponível, ser o guia.

Cluster Hyper-V
Implementar a redundância com tecnologia Hyper-V envolve fazer o cluster de serviços em dois ou mais servidores. Cada computador deve ter instalado uma versão x64 do Windows Server 2008 Enterprise Edition, e cada um deve incluir um mínimo de duas placas de rede por servidor além de uma ou mais placas de rede para iSCSI. Neste exemplo muito simples, pode utilizar a rede para conectar esses dois servidores a um terceiro servidor ou dispositivo que hospeda um conjunto de discos partilhados iSCSI. iSCSI é usado aqui porque é fácil de configurar, requer pouco ou nenhum equipamento adicional ou formação especializada e pode ser executado na sua rede existente.

Nesses discos irá armazenar os ficheiros para as máquinas virtuais para que possam ser acedidos directamente por ambos os hosts. Conforme mostrado na Figura 1, duas placas de rede conectadas a cada servidor e duas redes diferentes (uma para rede privada cluster, o outra para a rede de produção), enquanto o terceiro se conecta aos discos do iSCSI. Neste exemplo, as conexões iSCSI estão em redes diferentes do tráfego de produção. Separar o tráfego iSCSI do tráfego de rede normal é importante proteger o tráfego de cada tipo do congestionamento da rede do outro.

Figura 1 - no mínimo, seis conexões de rede necessárias para iniciar um cluster.

A primeira etapa da preparação no ambiente é validar se os servidores na verdade podem executar a função Hyper-V. O Hyper-V tem três requisitos de hardware:

O servidor deve ser capaz de executar a versão x64 do sistema operativo do Windows.
Processador do servidor deve estar equipado com hardware prevenção de execução de dados (DEP - Data Execution Prevention).
Recursos de processador do servidor devem incluem as extensões de virtualização.

Esses três requisitos são todos os determinados pelos recursos de processador disponíveis no servidor, e há duas maneiras para determinar se os servidores atendem a essas necessidades. Em qualquer servidor adquirido de um fornecedor de hardware, pode sempre verificar se o servidor e o modelo se encontra no Catálogo do Windows Server.

Se o servidor não estiver na lista ou é de design próprio, poderá fazer download da Ferramenta Securable test tool. Esta pequena ferramenta testa recursos do processador contra esses três requisitos. Se o comprimento de bit máximo é de 64 e os relatórios da ferramenta dizem Sim para ambos hardware DEP e para hardware de virtualização, então tem o que precisa.

A próxima etapa no processo é criar dois discos que estão expostos na rede por meio de iSCSI. O primeiro disco será 512 MB de tamanho para o disco de testemunha, enquanto o segundo disco será de um tamanho necessário para a instalação completa de uma máquina virtual. As etapas exatas para isso serão diferentes, pois depende de qual produto irá usar para hospedar os discos. Se o ambiente tiver iSCSI hardware no local, basta criar e expor dois novos discos por meio da interface. Se não tiver iSCSI por hardware, o software de destino iSCSI existe na Internet em que pode instalar em um servidor à parte no ambiente para essa finalidade.

Se precisar de usar iSCSI baseados em software, convém examinar cuidadosamente os recursos disponíveis. O Microsoft cluster requer iSCSI para oferecer suporte a SCSI Primary Commands-3, especificamente o suporte de reservas persistentes. A maioria dos softwares para custo iSCSI actualmente suporta esse recurso, mas há muito pouco suporte para pacotes de software em open source.

Um pacote de software barato e fácil de usar é o StarWind iSCSI Target da Rocket Division. Irá precisar usar uma das versões pagas para o cluster porque com a versão free do Personal Edition, não oferece suporte para ligar vários servidores no mesmo disco. Existem outras opções, mas no momento não há nenhum download freeware da Microsoft que pode ajudá-lo.

Depois de criado e exposto esses dois discos para a rede por meio de iSCSI, execute a seguintes etapas em cada computador que irá fazer parte do cluster para se conectar aos discos:

Vá para Administrative Tools | iSCSI Initiator. Na sua primeira tentativa de ligação para a ferramenta, irá ser solicitado duas vezes para habilitar o serviço Microsoft iSCSI e desbloquear a conexão da firewall. Escolha Sim para ambos para iniciar a console.
Para localizar os discos, vá até à tab Discovery e clique em Add Portal. No painel de resultados, digite o endereço IP para o disco iSCSI e clique no botão Avançado. Em seguida, altere o adaptador local para Microsoft iSCSI adaptador. De seguida, altere o IP de origem para o endereço IP para a placa de rede que seleccionou para sua conexão de disco. Firewalls podem impedir o iniciador de aceder o destino se um erro na conexão ocorrer neste ponto.
Se tiver êxito na ligação aos discos pela rede, irá ver o nome de cada disco na guia destinos. A próxima etapa é fazer logon em cada disco. Para fazer isso, clique no disco e seleccione logon. No painel de resultados, marque a caixa Automatically restore this connection when the computer starts e clique no botão Avançado. Novamente, configure o adaptador local para Microsoft iSCSI adaptador, o IP de origem para o endereço IP da placa de rede correto e o portal de destino para o endereço IP e porta para o dispositivo iSCSI. Repita essa etapa para cada disco. Um logon bem-sucedido irá ter aparência semelhante à Figura 2.
Na guia Favorite Targets, clique no botão Actualizar. Os nomes de disco devem constar da lista de destinos favoritos.
Na guia Volumes and Devices, clique no botão configuração automática. Se tudo foi feito correctamente a esse ponto, irá ver as referências a cada disco aparecem na caixa.

A Figura 2 uma conexão bem-sucedida em discos de iSCSI

Após a ligação para os discos, irá precisar inicializar e formatá-los para torná-los pronto para serem utilizados. Pode fazer isso em Server Manager sob o Storage | Disk Management. Esse processo deve ser executado em cada computador, mas deve ser feito somente quando o outro computador é desligado. Faça isso agora e inicie o Disk Management. Agora, clique com o botão direito do rato em cada disco e coloque o disco on-line. Em seguida, clique com o botão direito do rato novamente e inicializar o disco. Por fim, clique com o botão direito do rato uma terceira vez para criar um novo volume simples, formatar o disco como NTFS e atribuir a ele uma letra de unidade. Neste exemplo, será atribuído a letra Q: para a unidade de quorum e F: para a unidade para nossa máquina virtual.

Desligue o primeiro computador e inicie o segundo. No segundo computador, verifique se o disco está atribuído na mesma letra de unidade como foi atribuído no primeiro computador. Quando isso for concluído, os dois computadores podem ser activados. Os discos agora estão prontos para o cluster.

A próxima etapa neste processo é instalar a função de Hyper-V computador bem como o recurso de cluster de failover. Pode fazer ambas no Server Manager. Antes de se instalar qualquer função ou recurso, actualize o servidor. Instalar esses componentes requer uma reinicialização.

Duas etapas ainda permanecem. Primeiro, validar o cluster, navegue para Administrative Tools | Failover Cluster Manager. Clique no link para validar a configuração. Esta etapa garante que tudo o que configurou está correcto para se preparar para a criação de cluster. Se a configuração passar nos testes de validação, clique no link para criar o cluster. O assistente irá pedir os nomes de membros de cluster bem como um endereço IP a ser usado para comunicação do cluster. Esse endereço será um endereço IP não usado na rede e não deve ser qualquer um dos endereços IP que utilizou para este ponto neste procedimento. Conclua o Assistente para criar o cluster.

Trabalhar com cluster Hyper-V
Quando utiliza a tecnologia Hyper-V sozinha e sem o System Center Virtual Machine Manager, o processo de gestão dos hosts de cluster virtuais ocorre em dois locais. Criar e trabalhar com máquinas virtuais no Hyper-V Manager. A configuração de ambos os próprios clusters e os recursos de cluster necessários é feita de dentro do Failover Cluster Manager.

Para criar uma nova máquina virtual, abra o Hyper-V Manager e seleccione New | Virtual Machine. Responda às perguntas ao assistente e certifique-se de que armazene os ficheiros de disco da máquina virtual na unidade F:. Todos os ficheiros associados a uma máquina virtual de cluster devem sempre ser armazenados em discos partilhados. Depois de criar a máquina virtual, desligue-a e inicie o Failover Cluster Manager. A próxima etapa é configurar os recursos necessários para o cluster de máquina virtual. Clique com o botão direito do mouse serviços e aplicativos e selecione Configure a Service or Application. Seleccione o item virtual machine no menu e clique em Avançar. A janela irá ficar semelhante à Figura 3. Seleccione a máquina que deseja estar no cluster. Não irá conseguir seleccionar as máquinas que está ligado ou que os ficheiros do disco não são armazenados em unidades compartilhadas. Conclua o assistente para concluir este processo.

A Figura 3 seleccionar uma máquina deve ser feito com reconhecimento de cluster

Agora tem uma máquina virtual que é o reconhecida pelo cluster, e este VM agora irá beneficiar de alta disponibilidade fornecida pelo cluster de failover do Windows Server 2008. Isto significa que, se o coordenador da máquina virtual for desligado ou se a VM apresentar problemas, reiniciará automaticamente propriamente dito no outro nó do cluster. a Figura 4 mostra um exemplo de como a máquina virtual aparece no Failover Cluster Manager.

A Figura 4 uma máquina virtual hospedada no Failover Cluster Manager

Se precisar executar a manutenção no host de cluster, pode agora também rapidamente migrar nessa máquina virtual para o outro host, ao clicar na respectiva instância em serviços e aplicativos e seleccione Move this service or application to another node. No mesmo local, as propriedades deste grupo da máquina virtual fornecem um local para instruir o cluster quais os nós que são preferenciais para hospedar o computador. Em clusters de failover do Windows, um proprietário preferencial corresponde a nós de cluster em que prefere que a VM para ser hospedado no caso de um failover. Essa opção tem impacto em clusters com mais de dois nós mas pode ser uma maneira de manualmente ter balanceamento de carga de máquinas virtuais em vários nós.

Aumentar a disponibilidade
Essas etapas são apresentadas para mostrar como é fácil adicionar extra disponibilidade para os servidores. Se tiver dois servidores do Windows Server 2008 Enterprise Edition em torno de qualquer dispositivo iSCSI (seja por hardware ou por software), com apenas algumas etapas poderá criar um cluster básico do Windows para oferecer suporte a alta disponibilidade.

Além disso, conforme já mencionado, isso é apenas a primeira etapa. Há outras camadas da tecnologia que provavelmente poderá desejar adicionar a arquitectura para obter ainda mais disponibilidade. Cada camada adiciona um pouco mais resiliência ao ambiente — mas também adiciona um pouco mais de custo e complexidade. Dependente das necessidades e do orçamento, considere os seguintes tópicos como possíveis complementos:

Equipamento de servidor O uso de equipamento que não esteja listado no Catálogo do Windows pode afectar a capacidade de suporte e pode não atender às melhores necessidades das máquinas virtuais. Mover para o equipamento de testado e suportado de servidor irá garantir suporte completo no caso de um problema.

Redundância de placa de rede Com o mínimo de três placas de rede ligadas em cada nó de cluster aos discos e redes, a perda de qualquer uma (placa de rede) pode significar na perda do servidor como um nó de cluster. Assim, adicionar mais placas de rede para vários caminhos redundância iSCSI ou rede deve ser a primeira opção para obter mais hardware.

Redundância do caminho de rede O uso de iSCSI em toda a rede de produção pode ter um impacto significativo sobre o seu desempenho. O inverso também é verdadeiro, bem como tráfego de rede tradicional pode ter um impacto na conexão de um nó de cluster para o disco. Isolar o tráfego de iSCSI para seu próprio caminho de rede isola esse tráfego a seu próprio segmento de rede, garante com isso a disponibilidade completa como alteração de condições de rede.

Utilizar hardware iSCSI Embora o software de destino iSCSI funcione, pode representar um problema. A perda do servidor que hospeda os discos de iSCSI significa a perda de todo o cluster. Como servidores exigem reinicializações de tempos em tempos, com base em hardware iSCSI tende a garantir níveis superiores de disponibilidade.

Redundância do iSCSI Se usar hardware ou software para a conexão iSCSI, ainda é um ponto único de falha se não for feita redundância. Procure soluções que fornecem redundância para os discos iSCSI.

System Center Virtual Machine Manager Usar Hyper-V sozinho em vários sistemas pode ser um desafio. Há muito a ser configurado e muitas etapas envolvem intervenção manual. Adicionar recursos extra de gestão obtidos por meio do System Center Virtual Machine Manager torna o processo de gestão de ambiente de virtualização muito mais fácil, que reduz a possibilidade de erros e tempo de inactividade.

Nós de cluster adicionais O Windows Server 2008 Enterprise Edition x64 pode oferece suporte a até 16 nós em um cluster de failover. Adicionar nós extras a um cluster requer executar as etapas descritas aqui em um servidor adicional e adicionar esse servidor para o cluster. Assim que tiver esse servidor adicional, tem outro local em que máquinas virtuais podem levantar quando houver problemas. Isso é especialmente útil quando considera como a perda de um único nó pode afectar o desempenho da máquina virtual. Por exemplo, se armazenar quatro máquinas virtuais em cada nó de cluster de um cluster de dois nós, a perda de um nó move todas as máquinas virtuais oito para um único nó. Ao colocar várias VM em um servidor afecta o desempenho de todas as máquinas virtuais.

Clusters de vários sites Clusters de failover tradicionais são criados para proteger contra a perda de um host, mas não são comportam bem em caso de um desastre. Para proteger contra a perca de cada nó de cluster ao mesmo tempo, considere a criação de um geocluster. Uma tarefa muito mais complexa, geoclusters abrange sub-redes e aproveita a tecnologia de replicação para manter os armazenamentos de dados em sincronia. Com um geocluster, se perder um site inteiro, as máquinas virtuais automaticamente irão migrar para o outro site com apenas uma interrupção pequena (claro que depende da largura de banda entre os sites e o tamanho da Vm).

Estas opções adicionam mais custo ao ambiente e muitos adicionam significativos níveis de complexidade. Mas todos eles fazem uma arquitectura altamente disponíveis.

Porquê aplicar um snapshot num controlador domínio numa VM pode ter problemas?

Marcos David Nogueira — Fri, 29 May 2009 12:05:00 GMT

Esta é uma questão bastante comum para na comunidade de TI.

Imagine que tem uma VM que está associada a um domínio e está a funcionar perfeitamente. Faz um snapshot, para assim pode restaurar a VM a este ponto mágico de workingness, a qualquer momento. Quando precisar de acionar esta VM e para testar algo, precisa reverter para o snapshot e iniciar a VM. Logo após aparece uma mensagem a dizer que o domínio não confia mais na sua estação de trabalho (virtual). O que é que aconteceu? Não foram feitas alterações no snapshot! Por isso que ele é chamado de snapshot! Por isso que isto dá erro?

Bem, tem razão. Não foram feitas alterações no snapshot, e isso é parte do problema.

Faz parte das políticas de domínio (por padrão) do Active Directory para um membro de domínio alterar a password da conta agora e sempre. Sem dúvida tem que alterar a password para a conta de utilizador ocasionalmente, portanto, isso não deveria ser uma surpresa. O que pode ser uma surpresa é que a mesma coisa acontece para contas de computador. Eis a razão – os computadores têm contas, também.

Agora então (por padrão, a cada 30 dias, mas o valor é configurável através de politica de domínio), a estação de trabalho vai negociar uma nova password com o domínio. Tudo acontece nos bastidores, sem o seu conhecimento.

Salvo, se tiver uma VM ingressada no domínio com snapshots tirados ao mesmo tempo (servidor e cliente).

O problema surge porque a estação de trabalho – em algum momento – negoceia uma nova password com o domínio e regista-a para uso futuro. Em seguida, o snapshot foi aplicado, e desta forma activou a VM a "viajar de tempo". Esta VM do passado foi levada para o futuro e não tem conhecimento de tudo o que aconteceu no intermédio. Portanto, a Vm pensa que a antiga password é ainda está actualizada. E ele tenta utilizar essa mesma password. E o domínio ao verificar que a password é diferente, nega o acesso.

Por que razão o Hyper-V deixa isso acontecer?

Não é apenas o Hyper-V. Isso acontece o tempo todo para qualquer VM em qualquer tecnologia de virtualização (desde que tenha a possibilidade de fazer snapshot e poder aplica-lo). A mesma coisa vai acontecer em qualquer situação onde tenha que "convencer" o Windows que a password da conta do computador é algo que não é (como restaurar um snapshot ou qualquer outro tipo de backup).

O que pode se pode fazer sobre este problema?

Existem três possibilidades.

1. Se puder, mudar a política de domínio padrão ou obtenha uma excepção criada para sua conta(s) de computador(es). Isso não é a melhor opção porque abre um buraco de segurança (pequeno como podem ser).

2. Logon numa conta de administrador local no sistema e retirar do domínio. Em seguida, voltá-lo a colocar no domínio. A conta do computador irá obter uma nova password, e esta actualizada, que a estação de trabalho conhece. Alternativamente, poderá utilizar o NETDOM.EXE para redefinir a senha da conta do computador. Pode sempre automatizar este mesmo processo, se precisar.

3. Sysprep na VM e criar um arquivo autónomo que irá configurá-la de acordo com o que pretende, que poderá ser ingressar automaticamente no domínio, por exemplo. Uma vez que a máquina utilize o sysprep, pode fazer um snapshot e sempre restaurar para aquele ponto, daqui por diante.

Utilização da VMC to Hyper-V Import Tool

Marcos David Nogueira — Tue, 05 May 2009 12:54:00 GMT

Com o lançamento do Hyper-V no Windows Server 2008 e a versão recente do Hyper-V Server 2008, está a ser cada vez mais utilizado a tecnologia Hyper-V, para testar e em implementações tanto em desenvolvimento como em...(read more)

Backup e Disaster Recovery para a virtualização de servidores

Marcos David Nogueira — Sat, 28 Mar 2009 00:13:00 GMT

À medida que a tecnologia de virtualização de servidores evolui e sua adopção no sector aumenta, as organizações percebem benefícios que vão muito além da justificativa mais popular...(read more)

O Workarround para ultrapassar as limitações do Hyper-V VSS Writer

Marcos David Nogueira — Mon, 09 Mar 2009 16:30:00 GMT

Enquanto o Hyper-V VSS Writer fornece um significativa flexibilidade aos Backups Admins na habilidade de fazer backup às VMs de uma forma em que a aplicação continue consistente, enquanto corre aplicações backup na máquina...(read more)