.

Quando é esperado ter acesso ao Windows Server 2008 R2 RTM

Após os diversos anúncios da release final do Windows Server 2008 R2 e do Windows 7 na semana passada, a pergunta que se coloca é quando vai ser possível ter acesso aos bits das novas versões do Windows. Segundo a Microsoft eis as datas de disponibilização para os diversos tipos de parceiros:

Para parceiros & OEMs:

ISV (fornecedor de software independentes) e parceiros IHV (fornecedor de hardware independentes) poderão fazer download do Windows Server 2008 R2 RTM através do MSDN início em 14 de Agosto.

O MSDN irá disponibilizar, em inglês, francês, alemão, japonês, italiano e espanhol, em 14 de Agosto e irá distribuir nas restantes línguas, a começar em 21 de Agosto.

Microsoft Partner Program Gold/Certified Members serão capazes de fazer download da versão Windows Server 2008 R2 RTM através do Portal do Microsoft Partner Program (MPP) em 19 de Agosto.

Assinantes do Microsoft Action Pack poderá ser feito o download do Windows Server 2008 R2 a partir de 23 de Agosto.

Os Parceiros OEMs irão receber o RTM do Windows Server 2008 R2 em inglês e todos os pacotes de idiomas em 29 de Julho. As restantes línguas estarão disponíveis em torno de 11 de Agosto.

Para Clientes de Licenciamento de Volume:

Se for um cliente de licença de volume (VL) com uma licença de Software Assurance (SA) existente, poderá fazer download do RTM do Windows Server 2008 R2 em 19 de Agosto via Volume License Service Center (VLSC).

Clientes Volume License sem uma SA licença poderão adquirir o Windows Server 2008 R2 através do volume de licenciamento, a partir de 1 de Setembro.

Profissionais de TI:

Profissionais de TI com assinaturas do TechNet serão capazes de fazer download da versão Windows Server 2008 R2 RTM em inglês, francês, alemão, japonês, italiano e espanhol em 14 de Agosto e todas as restantes línguas, começa em 21 de Agosto.

Desenvolvedores:

Os desenvolvedores com assinaturas MSDN poderão fazer download da versão Windows Server 2008 R2 RTM em inglês, francês, alemão, japonês, italiano e espanhol em 14 de Agosto e todas as restantes línguas, começa em 21 de Agosto.

Para os entusiastas técnicos, curiosos e todos os outros:

A partir de 20 de Agosto, é possível fazer download da versão de avaliação de 180 dias do Windows Server 2008 R2 através do site do WINDOWS SERVER 2008 R2

Além disso, R2 do Windows Server 2008 irá estar disponível no canal de varejo a partir 14 de Setembro.

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

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.

Reserva de memória no Host com o Windows Server 2008 R2

Com um servidor standalone Windows Server 2008 R2 que corre o Hyper-V (qualquer host de Hyper-V não-cluster), a quantidade de memória reservada para um host (máquina física) é a memória não alocada para a VM guest (máquina virtual). Portanto, quando for criar as VMs pode determinar a quantidade de memória que será reserva para o host. Pode colocar quantas VM num determinado host, quanto o host e as VM guests poderem funcionar eficazmente. Pois VMs em estado shutdown, não entra na contagem de memória reservada do host.

Semelhante a um servidor standalone, a quantidade de memória física não reservada para as máquinas VM guests em um nó de cluster de failover é reservado pelo host. No entanto, como parte do cluster, um host pode muitas vezes receber VM guests de outros nós do cluster e mantê-las altamente disponíveis. Isto pode ser uma passagem iniciada pelo utilizador como uma live migration de uma VM de outro nó ou uma falha de recurso ou hardware que causaria o failover das VMs. Como resultado, o utilizador não tem mais controle sobre a memória reservada para o host. As VM guests do outro nó podem facilmente mover para um determinado nó e encher a sua memória. Isso deixaria a memória insuficiente para serviço de cluster, que é executado no host, para fornecer uma tolerância a falhas para a VM e nas operações de migração. Como resultado, a variável de ambiente de cluster RootMemoryReserved foi introduzida para assegurar que em cluster de hosts de VM, um montante mínimo de memória física é reservada para o host.

RootMemoryReserve

Apesar do nome, a variável RootMemoryReserved não garante literalmente que a partição raiz teria uma certa memória física reservada para si. Pelo contrário, especifica um tamanho de memória para o host do sistema operativo comparar quando o host de sistema operativo está prestes a iniciar uma VM (que foi movida para esse nó por acção do utilizador ou do recurso de failover). Se, em seguida, ao iniciar uma VM, o host a memória física restante do sistema operativo desça abaixo do limite especificado pelo RootMemoryReserved, a operação de início da VM falha.

Por exemplo, em um nó do cluster com 16 GB de memória física e o RootMemoryReserved definida a 1024 MB (1 GB). Se cada VM pode ficar com até 1 GB, o número máximo de VM que pode estar online são 15, pois o 1 GB de memória é reserva pelo host OS. Todas as tentativas de iniciar a 16ª VM traria o uso de memória física das VMs acima de 15 GB, o que causaria que a reserva de memória física para o host OS caísse para abaixo de 1 GB disponíveis. Assim, a operação de início da 16ª VM irá falhar.

O RootMemoryReserved é por padrão de 512 MB. Isso deve ser suficiente para o host de VM que não está executar qualquer operação que não gerir as VMs. Esta variável pode ser vista pelo cmdlet PowerShell

(get-cluster <cluster name>).RootMemoryReserved

Para alterar o RootMemoryReserved, para o tamanho desejado de memória reservada é atribuído com o cmdlet PowerShell acima mencionado. Use o seguinte cmdlet do PowerShell para definir RootMemoryReserved para 1024 MB (como exemplo):

(get-cluster <cluster name>).RootMemoryReserved=1024

Alterar o RootMemoryReserved não afecta quaisquer VMs que já estejam em execução. Por exemplo, em um nó com 16 GB de memória física, se RootMemoryReserved estiver definido como 512 MB e as VMs estão a ocupar mais de 15 GB de memória, isso deixaria o host, com menos de 1 GB de memória. Se por algum motivo, tais como o outro aplicativo em execução no host, provocar o sistema lento, a alteração do RootMemoryReserved para 2048 MB (2 GB) não vai automaticamente libertar memória física para o host. Neste cenário, a única maneira para libertar a memória física para o host é colocar uma das VMs em offline. Por conseguinte, é recomendável que o RootMemoryReserved desejado ser definido adequadamente antes de iniciar qualquer VMs online.

O valor máximo para o RootMemoryReserved é 4096 MB (4 GB). Qualquer alteração de um valor superior a 4 GB vai ser ignorado e o valor anterior iria ser utilizado. Também, RootMemoryReserved, como um parâmetro de cluster, aplica-se a todos os nós do cluster. O valor RootMemoryReserved deve ser usado para reservar a memória no host de VMs em todos os nós do cluster.

A variável RootMemoryReserved não limita a quantidade de memória que o host pode utilizar. O propósito dessa variável visa garantir que o host terá um montante mínimo de reserva de memória física para controlar as VMs. O host definitivamente pode usar muito mais memória do que o valor definido para o RootMemoryReserved. Portanto, o montante de memória física disponível para as VMs deverá ser igual ou inferior ao montante de memória não reservada para o RootMemoryReserved.

Como funciona o QSM – Quick Storage Migration

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

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

Comparação do QSM com o VMware Storage VMotion

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