O objectivo deste post é descrever os problemas corrigidos no Microsoft Center Virtual Machine Manager 2008 pela actualização do System Center Virtual Machine Manager 2008 update (post anterior - Como obter a actualização do System Center Virtual Machine Manager 2008 para conversão de físico para virtual (P2V)).
Lista dos problemas corrigidos
· Utilize o System Center Virtual Machine Manager 2008 para executar uma conversão P2V (Fisico para virtual) offline. O computador com o System Center Virtual Machine Manager 2008 esta localizado numa sub-rede diferente do computador de origem. No entanto, os dois computadores estão configurados para utilizar um intervalo de endereço IP, como, por exemplo, 10.x.x.x. A conversão de P2V offline falha com a seguinte mensagem de erro:
Error (3133) Virtual Machine Manager could not connect to source computer servername.domainname.com after it restarted into Windows PE (temporary computer name is p2v-ldjj). Automatic restart to the original operating system is scheduled to occur within 15 minutes. Recommended Action If servername.domainname.com does not restart in 15 minutes, manually restart it back into the original operating system using the boot menu
· Ao converter uma máquina física para uma máquina virtual utilizando VMWare VirtualCenter. E se um dos discos do computador físico é superior a 256 gigabytes (GB). Adicionar o servidor VMWare VirtualCenter para o System Center Virtual Machine Manager 2008. Quando tenta criar uma máquina virtual, a operação falha com a seguinte mensagem de erro:
VMM Cannot find VirtualHardDisk object. Ensure the library object is valid, then try the operation again. ID: 801
NOTA: Se receber esta mensagem de erro antes de aplicar a actualização, pode utilizar o SQL Server Management Studio para executar um script de SQL Server na base de dados do VMM para corrigir este problema.
Para criar este script SQL, crie um novo ficheiro de .txt e, em seguida, cole o seguinte texto no novo ficheiro. Mude o depois de criar o ficheiro, nome para uma extensão de nome de ficheiro .SQL.
BEGIN TRANSACTION T1
DECLARE custom_cursor CURSOR FOR
SELECT VHDId, VDriveId from
dbo.tbl_WLC_VDrive WHERE [VHDId] NOT IN
(SELECT VHDId from dbo.tbl_WLC_VHD WHERE VHDID IS NOT NULL)
DECLARE @VHDId uniqueidentifier
DECLARE @VDriveId uniqueidentifier
OPEN custom_cursor
FETCH NEXT FROM custom_cursor INTO @VHDId, @VDriveId
WHILE(@@fetch_status = 0)
BEGIN
if(@VHDId is NOT NULL)
DELETE FROM dbo.tbl_WLC_VDrive
WHERE VDriveId = @VDriveId
FETCH NEXT FROM custom_cursor INTO @VHDId, @VDriveId
END
CLOSE custom_cursor
DEALLOCATE custom_cursor
COMMIT TRANSACTION T1
Nota: Pode fazer download da versão de Express do SQL Server Management Studio gratuitamente, para isso visite o seguinte Web site da Microsoft
Para executar o script de SQL Server, siga estes passos:
1. Inicie o SQL Server Management Studio e, em seguida, ligue-se ao servidor que esteja a executar a base de dados SQL Virtual Machine Manager.
2. No menu “ficheiro”, clique em Abrir e, em seguida, clique em ficheiro.
3. Navegue para a localização onde guardou o ficheiro de script do SQL Server.
4. Seleccione o ficheiro .SQL (que criou com o script acima) e, em seguida, clique em Abrir.
5. No menu de consulta, clique em executar.
6. Feche a janela de SQL Server Management Studio.
À 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 para a virtualização: reduzir os custos de infra-estrutura e aumentar a agilidade de TI. O próximo passo é usar a plataforma de virtualização como uma forma de habilitar ou aprimorar as estratégias de DR (Disaster Recovery - recuperação de desastre).
Por que a prontidão da DR é, de forma generalizada, um dos assuntos mais efervescentes no sector de TI? Estudos sugerem que as empresas perdem, em média, de US$ 80.000 a 90.000 por hora de inactividade, e que poucas empresas a sofrer uma perda de dados catastrófica alcançam uma sobrevida de longo prazo. Este post apresenta uma introdução à DR usando a plataforma de virtualização da Microsoft, uma análise detalhada das opções de backup e restauração existentes e algumas considerações sobre o Windows Server 2008 Hyper-V.
Noções básicas de planeamento da recuperação de desastre
A DR é o processo de restaurar serviços essenciais no caso de uma interrupção, e deve fazer parte do plano de continuidade de todas as empresas. Esse plano define como a empresa continuará a funcionar durante ou após um desastre, e constitui o fundamento de qualquer iniciativa de DR.
Alguns fornecedores afirmam que suas tecnologias de automatização de DR minimizam ou eliminam a necessidade de um plano detalhado e bem testado. Embora seja válido afirmar que a automatização pode reduzir o tempo de recuperação e diminuir a dependência da intervenção humana, vamos fazer uma pausa para um anúncio de utilidade pública: é impossível ter êxito na tentativa de atenuar um desastre contando somente com a tecnologia. As pessoas e os processos são sempre tão importantes quanto as tecnologias.
Na verdade, descobrirá que é praticamente impossível seleccionar as tecnologias certas, sem primeiro conhecer todas as restrições e os objectivos gerados pelo processo de planeamento de DR. Não vamos definir um plano completo de DR. Vamos, sim, enfatizar os elementos necessários para a escolha das tecnologias e implementações certas. Sendo assim, vamos descrever rapidamente alguns factores tecnológicos essenciais em um plano de DR.
Definições e priorização de serviços O que exactamente define todo o serviço que está tentando proteger e qual a sua importância para a organização? A Figura 1 mostra alguns exemplos de serviços de empresas que provavelmente seriam incluídos em qualquer plano de DR.
Figura 1 Exemplo de definições e priorização de serviços
Depois de definir os serviços, podemos começar a identificar os sistemas e as dependências a serem vinculados a que tipos de estratégias de DR. Talvez, depois de observar o conjunto completo de serviços e dependências, descubra que precisa adoptar alguns níveis diferentes de capacidade de DR, pois uma única solução de DR para todos os serviços essenciais seria muito cara e complexa.
SLAs (contratos de nível de serviço) Um SLA é um acordo ou contrato entre o provedor de serviço (TI) e o cliente (organização) que define as metas de disponibilidade para determinado serviço. Esses contratos podem ser extensos ou bastante directos. Por exemplo, "O sistema de email estará disponível 99,95% do tempo no horário comercial e 98% do tempo fora do horário comercial, excluindo-se as janelas de manutenção agendadas, com medição mensal." Em geral, os SLAs são divididos em camadas às quais podem ser atribuídos serviços de TI, com medição em um período predefinido.
OLAs (contratos de nível de operação) Os OLAs descrevem, basicamente, os contratos entre diferentes grupos de TI que actuam no suporte a um SLA, inclusive os tempos de processamento e resposta para o fornecimento dos serviços. Suponha que tem um site essencial com uma meta de SLA de 99,99%, mas um banco de dados do qual ele depende para obter conteúdo tem uma meta de disponibilidade de apenas 95%. O OLA ajuda a solucionar essas divergências e a alinhar as equipes de TI no sentido de uma meta comum.
RPOs/RTOs (objectivos de ponto de recuperação e tempo de recuperação) Um RTO define por quanto tempo um serviço pode ficar indisponível até que haja uma quebra de continuidade; já um RPO define o que a organização considera um nível aceitável de perda de dados. Então, se um serviço tem um SLA de 99%, com medição mensal, isso significa que o RTO é de 7 horas e 18 minutos. Se combinar isso com um RPO de, digamos, 24 horas, poderá definir técnicas e agendamentos de backup com precisão.
Politicas de retenção de dados As politicas de retenção de dados de uma organização especificam exactamente por quanto tempo é preciso manter os backups e onde devem ser armazenados. Em geral, elas são governadas por requisitos legais e normativos.
Categorização de dados Também se deve levar em conta a natureza dos dados. Se dividirmos os dados em categorias, vamos perceber rapidamente que nem todos exigem a aplicação do mesmo nível de DR. Por exemplo, um banco de dados único pode ter requisitos de disponibilidade diferentes daqueles encontrados em um Active Directory com vários controladores de domínio, cada um contendo uma réplica do directório. Da mesma forma, os dados de um servidor de arquivos têm procedimentos de restauração diferentes dos aplicáveis a dados de CRM.
Cenários de desastre É importante definir todos os cenários para os quais se deseja fazer um planeamento, pois cada um terá procedimentos de restauração, efeitos sobre os negócios e custos associados distintos. É útil observar todos os cenários possíveis e depois decidir em quais se deseja concentrar ao trabalhar no planeamento de DR para o seu ambiente:
· Perda de todo o local
· Perda de um único data center
· Perda de um sistema (sistema operacional ou falha de hardware)
· Perda de dados (exclusão ou corrupção de dados)
· Perda de uma dependência essencial
Logicamente, há vários aspectos diferentes a serem considerados na recuperação da perda do local inteiro, em oposição à perda de um único sistema. É provável que queira também definir limites de recuperação com base nos SLAs. Digamos, por exemplo, que todo o local está offline devido a uma grave interrupção na rede ISP. Se o SLA do serviço afectado for de 8 horas para a restauração do serviço e 48 horas para a restauração dos dados, talvez realize procedimentos de failover do serviço para o seu local de backup, mas não chegue a executar o processo de recuperação de dados, por prever um failback rápido para o local de produção.
Todo esse trabalho e ainda nem falamos de tecnologia! Não se deve subestimar a importância do planeamento. Uma implementação de DR sem um plano documentado é apenas uma "esperança de DR".
Recuperação de desastre e virtualização
Bem, agora que já estabelecemos as bases do planeamento de DR, o que muda com a virtualização? Muitas empresas relatam tempos de restauração de serviços de minutos com servidores virtualizados, em comparação com os dias ou as semanas necessárias no caso de servidores físicos. Como todo o sistema operacional do servidor passa a ser constituído apenas por um conjunto de arquivos, abstraído do hardware físico subjacente, surgem novas perspectivas, sob o ponto de vista da capacidade de recuperação.
A teoria predominante na actualidade é que algumas ou todas as metas de DR podem ser alcançadas com soluções de HA (alta disponibilidade). A ideia por trás disso é que, se tiver nós de cluster em locais físicos separados, com dados sincronizados entre os locais, o nó passivo poderá retomar as operações em caso de falha, e poderá recuperar-se praticamente em tempo real.
Isso é verdade. No entanto, convém lembrar os cenários de desastre definidos anteriormente, fica claro que essa não é a solução para todos eles. É preciso ter uma combinação de tecnologias que permita preparar-se para todos os cenários, e isso geralmente inclui algum tipo de backup regular. A HA não protege contra todas as interrupções possíveis e não elimina totalmente a necessidade de algum tipo de estratégia de backup.
A HA com Hyper-V exige um planeamento cuidadoso da camada de armazenamento, pois esse é um factor fundamental para possibilitar a capacidade de recuperação. Por exemplo, um cluster Hyper-V de 2 nós com armazenamento partilhado ainda tem o subsistema e os dados de armazenamento como ponto único de falha, mesmo que os nós do cluster estejam em data centers separados.
Contudo, saiba que o mesmo cluster Hyper-V de 2 nós com armazenamento não partilhado é capaz de resistir à perda de armazenamento ou de dados em qualquer um dos nós. Isso exige tecnologias de replicação para manter o armazenamento em sincronia e também introduz complexidades (veja a Figura 2).
Figura 2 Cluster Hyper-V multissite
Outro recurso é o Windows Server Catalog, que lista fornecedores de armazenamento com tecnologias de replicação certificadas para o Windows Server 2008.
Como se pode ver, há muitas configurações possíveis de HA e armazenamento que precisam ser levadas em consideração. Mais uma vez, é por isso que precisa ter os requisitos de negócios definidos e permitir que eles conduzam os requisitos técnicos, e não o contrário.
Conversão de físico para virtual
Sem dúvida, a virtualização oferece uma agilidade sem precedentes na recuperação. Mas e quanto aos sistemas físicos que não são bons candidatos à virtualização? O SCVMM (System Center Virtual Machine Manager) inclui a capacidade de realizar conversões P2V (de físico para virtual) de servidores Windows em execução, resultando em uma VM (máquina virtual) Hyper-V inicializável que é uma réplica exacta do servidor físico de origem. Agora, é possível replicar essa VM, assim como suas cópias virtualizadas, em várias partes de um campus ou de um país, obtendo tempos de recuperação semelhantes.
Essa abordagem é diferente da restauração tradicional, pois o local de recuperação não precisa mais ter o mesmo número ou tipo de sistemas físicos do local de produção. Então, é possível sobre utilizar o hardware de recuperação e dimensioná-lo conforme a necessidade, dependendo do impacto do desastre.
O SCVMM não inclui um agendador para conversões P2V. Porém, como a GUI é totalmente executada com base no Windows PowerShell, é fácil criar um script para isso usando o cmdlet New-P2V. Na verdade, todos os assistentes do SCVMM mostram o código usado para executar uma tarefa, e pode copiar o código de um P2V de teste no seu ambiente e modificá-lo para futuro uso automatizado. Abaixo mostra um exemplo de código; pode executar o assistente de P2V do SCVMM no seu ambiente para obter um script exclusivo e personalizável do Windows PowerShell.
Exemplo do código produzido pelo assistente de P2V do SCVMM
$Credential = get-credential
New-MachineConfig -VMMServer <VMM SERVER> -SourceComputerName "<SOURCE P2V SERVER>"
-Credential $Credential -RunAsynchronously
$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}
New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -SourceNetworkConnectionID "00:14:D1:3C:66:2F"
-PhysicalAddress "00:14:D1:3C:66:2F" -PhysicalAddressType Static -VirtualNetwork "External"
-MachineConfig $MachineConfig
$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}
New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -VolumeDeviceID "C" -Dynamic -IDE -Bus 0 -LUN 0 -MachineConfig $MachineConfig
$Credential = get-credential
$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}
New-P2V -Credential $Credential -VMMServer <VMM SERVER> -VMHost $VMHost -Path
"C:\ProgramData\Microsoft\Windows\Hyper-V" -Owner "DOMAIN\username" -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -Trigger -Name "<SOURCE P2V SERVER>" -MachineConfig
$MachineConfig -CPUCount 1 -MemoryMB 512 -RunAsSystem -StartAction NeverAutoTurnOnVM
-UseHardwareAssistedVirtualization $false -StopAction SaveVM
Snapshots de máquinas virtuais
Embora não seja tecnicamente um backup, um Snapshots de VM fornece um momento determinado ao qual se pode reverter o sistema, utilizando discos diferenciais e uma cópia do arquivo de configuração da VM. Se o desastre envolver a exclusão acidental de dados dentro da VM, isso poderá ser considerado um recurso de DR, pois a VM poderá ser revertida ao Snapshot, desfazendo os danos.
Fazendo backup do Hyper-V
Backups baseados em host Uma vantagem interessante da virtualização de servidores é a perspectiva de não precisar mais fazer backup individual dos sistemas virtualizados. Agora que esses sistemas são simples arquivos residentes no sistema de arquivos de um host, basta fazer backup dos arquivos e pronto, certo? Não exactamente. Por tratar-se de computadores activos constituídos por dados na memória, dados em disco, configurações de sistema e arquivos abertos, alguns aspectos precisam ser levados em conta. Então, como garantir a consistência dos dados de backup, diante de todas essas partes móveis?
Um aperfeiçoamento significativo na história do backup do Windows Server ocorreu com o Windows Server 2003 e o VSS, que fornece um conjunto padrão de APIs extensíveis usadas pelos gravadores VSS (ganchos em aplicativos e serviços que ajudam a fornecer cópias de sombra consistentes) para criar backups de arquivos e aplicativos abertos. Com a ajuda do serviço VSS, dos provedores e dos gravadores, o aplicativo de backup é capaz de gerar com rapidez a cópia de um momento específico de um volume. O aplicativo reconhece essa cópia e pode processá-la correctamente.
O Hyper-V vem com seu próprio gravador VSS, que permite aos fabricantes de software criar soluções interessantes de backup. O gravador possibilita aos aplicativos de backup obter backups VSS baseados em host de VMs em execução. Se o sistema operativo executado na VM tiver os Componentes de Integração do Hyper-V instalados, além do serviço VSS (disponível no Windows XP SP1 e no Windows Server 2003 e versões posteriores), o backup baseado em host ocorrerá como se fosse executado dentro do guest; o backup será realizado com a VM em execução e os dados serão consistentes (veja a Figura 3).
Figura 3 Backup VSS
No entanto, se o sistema operativo guest não oferecer suporte aos Componentes de Integração ou ao VSS, o processo de backup exigirá que a máquina guest seja colocada em estado salvo e que seja tirado um Snapshot VSS baseado em host dos arquivos de dados da VM, que poderá ser usado para a recuperação pontual. Os Snapshots VSS de estado salvo irão produzir algum tempo de inactividade da VM (em geral, isso se limita a um período de 5 a 10 minutos), com a realização de procedimentos completos de backup em fita a partir da cópia VSS dos dados.
Backups baseados em guest Em um ambiente físico, é preciso fazer backups individuais de servidores e aplicativos. Logicamente, esses backups podem continuar em um data center virtualizado. Nessa situação, deve-se ter em conta as mesmas considerações ao fazer backup de uma VM, como os requisitos de capacidade de rede para backups baseados em rede e o impacto sobre o desempenho do sistema durante a janela de backup. Com os backups baseados em guest, é possível optar por ter uma NIC física dedicada no host associada a uma rede virtual usada por todos os guests.
Backup do Windows Server
O WSB (Backup do Windows Server) compatível com VSS vem incluído no Windows Server 2008 e pode ser usado para realizar backups do Hyper-V baseados em host e em guest das suas VMs. Por ser totalmente compatível com VSS, o WSB pode realizar backups baseados em host das VMs em execução, o que é, logicamente, a opção preferencial.
Mas, se tiver VMs sem os Componentes de Integração instalados, o VSS não será usado. Nesse caso, poderá escolher entre algumas opções. Ainda será possível usar o WSB para fazer backup de uma VM sem os Componentes de Integração instalados. Isso significa que o estado da VM será salvo e, depois, o backup irá capturar os discos virtuais e os arquivos de configuração da VM.
Contudo, é possível que isso não seja desejável para um aplicativo como o Exchange, pois ele não reconhecerá que um backup foi executado, e os logs do aplicativo não serão truncados. Além disso, a VM terá um tempo de inactividade, que irá variar dependendo do tempo necessário para a realização do backup.
Como alternativa, é possível executar um backup dentro da VM como se ela fosse uma máquina física, utilizando o NTBackup ou o WSB, irá depender do sistema operativo da VM. Vejamos como usar o WSB em guests compatíveis que têm os Componentes de Integração instalados.
Fazendo backup de VMs com o WSB
O Hyper-V não regista automaticamente seu gravador VSS para uso com o WSB. Precisa adicionar manualmente a chave e o valor do Registo mostrados abaixo para que o WSB ofereça suporte a um backup do Hyper-V. Também é possível adicioná-los via linha de comando, desta forma:
reg add "HKLM\Software\Microsoft\windows nt\
currentversion\WindowsServerBackup\Application
Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}"
reg add "HKLM\Software\Microsoft\windows nt\
currentversion\WindowsServerBackup\Application
Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /v
"Application Identifier" /t REG_SZ /d Hyper-v
Isso não exige reinicialização, pois o WSB procura essa chave/valor no runtime do backup. O seguinte comando mostrará se a entrada foi definida:
reg query "HKLM\Software\Microsoft\windows nt\
currentversion\WindowsServerBackup\Application
Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /s
Como instalar o WSB
Clique em Iniciar | Gestão de Servidores. No painel esquerdo, clique em Recursos. Depois, clique em Adicionar Recursos no painel direito. Na página Seleccionar Recursos, expanda Recursos de Backup do Windows Server e marque as caixas de selecção Backup do Windows Server e Ferramentas da Linha de Comando. Agora, siga estas etapas para configurar seu backup:
1. Vá para Iniciar | Ferramentas Administrativas | Backup do Windows Server.
2. Se estiver fazendo backup de um host remoto, escolha Conectar a Outro Computador e digite o host Hyper-V.
3. Escolha Backup Único ou Agendamento de Backup.
4. Seleccione a configuração do backup — Servidor Completo ou Personalizado. Se você escolher Personalizado, certifique-se de obter todos os volumes contendo dados relacionados à VM da qual está fazendo backup, inclusive dados de configuração, discos virtuais e instantâneos da VM.
5. Escolha o local para armazenar o backup.
6. Escolha Backup Completo de VSS ou Backup de Cópia de VSS. Para backups baseados em host sem que nenhum outro backup esteja ocorrendo nas VMs, escolha Backup Completo de VSS.
7. Depois de confirmar os detalhes, seleccione Backup.
Considerações
· É preciso fazer backup de todos os volumes relacionados a uma VM. Isso inclui VHDs (discos rígidos virtuais), arquivos de configuração e Snapshots da VM.
· Se estiver criando um Agendamento de Backup, deverá usar um volume local dedicado, que será formatado e utilizado exclusivamente pelo WSB. Por outro lado, se estiver realizando uma tarefa de Backup Único, poderá armazenar o backup em um volume local não dedicado, em um dispositivo removível ou em uma partilha de rede.
· Se os Componentes de Integração não estiverem instalados na VM da qual estiver a fazer backup, o WSB salvará o estado da VM em execução para garantir a consistência dos dados de backup.
· Depois de concluído, o conjunto de backup será portátil e poderá ser usado com qualquer host Hyper-V.
Restaurando VMs com o WSB
Embora o WSB tenha a capacidade de restaurar arquivos individuais, esse recurso não utiliza o VSS e, portanto, pode resultar em uma restauração inconsistente, se a VM estiver em execução no momento do backup. Para fazer restaurações durante a execução das VMs, precisa de restaurar volumes inteiros.
Para fazer isso, é preciso ir para Iniciar | Ferramentas Administrativas | Backup do Windows Server e, no painel Acções, seleccionar Recuperar. Escolha o servidor do qual deseja recuperar dados (aquele onde estão localizados os dados do backup do WSB). Depois, escolha a data a partir da qual deseja restaurar os dados. Agora, pode seleccionar o tipo de recuperação.
Neste ponto, é preciso tomar uma decisão. Se precisa da VM inteira, inclusive de sua configuração, snapchots e discos virtuais (por exemplo, no caso de uma falha completa do host), seleccione Restaurar Aplicativo e depois Hyper-V, conforme mostrado na Figura 6. Nesse caso, não tem a opção de restaurar arquivos individuais. Será preciso restaurar tudo o que estiver incluído no conjunto de backup. Observe que isso não substituirá dados de configuração do Hyper-V e da VM existentes que tenham sido alterados desde o backup.
Figura 4 Restaurando um backup do Hyper-V
Se precisar apenas do VHD, e os dados de configuração e os instantâneos da VM estiverem íntegros, poderá seleccionar Arquivos e Pastas e escolher o arquivo de VHD individual de que precisa. Esse processo não utiliza o gravador VSS. Então, é preciso ter isso em conta ao fazer o backup da VM, salvar primeiro o estado.
Se sofreu uma perda total do sistema e dos dados e precisa recuperar o host Hyper-V propriamente dito, incluindo o sistema operativo Windows Server 2008 e todas as VMs executadas nele, faça uma reinicialização para o Ambiente de Recuperação do Windows e realize a restauração a partir dele. É possível fazer isso com o disco de instalação do Windows Server 2008 ou em uma partição de disco pré-configurada.
Data Protection Manager
Após análise das etapas e considerações sobre backup e restauração de hosts e guests Hyper-V usando o WSB, um recurso confiável, gratuito e interno, mas que não é uma solução de protecção de dados de nível empresarial. Quando o WSB sai de cena, entra o DPM (Data Protection Manager) 2007 SP1. O DPM SP1 dá suporte ao Hyper-V e traz alguns recursos interessantes:
· Um único console de gestão para todos os hosts e guests Hyper-V.
· Protecção contínua de dados, tirando Snapshots baseados em VSS em intervalos de até 15 minutos e capturando somente os bits alterados no processo.
· Reconhecimento de cluster Hyper-V, permite que o backup acompanhe a VM conforme ela se move entre os nós do cluster.
· Replicação de servidor DPM para servidor DPM.
· Suporte para mídia de disco e de fita (de disco para disco, de disco para fita ou de disco para disco e para fita).
· Recursos de backup e restauração em todo o espectro de dados, incluindo hosts e guests Hyper-V; backups VSS sem agente de guests em execução; suporte para restauração de VMs individuais; dados de cluster de failover; e os melhores recursos específicos de aplicativo da categoria para SQL Server, Exchange, SharePoint, Hyper-V e Virtual Server.
· Scripts pré e pós-backup.
Se utiliza actualmente uma solução de backup de terceiros, fique atento às actualizações do aplicativo. A maioria dos fornecedores está a empenhar para lançar (ou já lançou) no mercado soluções baseadas em host Hyper-V.
Backups com scripts
O WSB inclui uma interface de linha de comando, WBadmin.exe, além de um conjunto de cmdlets do Windows PowerShell para uso com scripts. Ao utilizá-los, aplicam-se as mesmas regras de backup descritas anteriormente, além da necessidade de registar manualmente o gravador VSS do Hyper-V no Registo.
A Figura 5 mostra alguns comandos de WBAdmin.
Como vemos, não há nada em WBAdmin para configurar a politica de backup propriamente dita, mas há um snap-in do Windows PowerShell para gerir essas configurações. Pode fazer um teste para verificar se esse snap-in está registado com o seguinte comando:
Get-PSSnapin -Registered
E pode usar o seguinte comando para carregar um snap-in chamado Windows.ServerBackup:
Add-PSSnapin windows.serverBackup
Quando ele estiver carregado, terá acesso aos cmdlets do Windows PowerShell para o WSB, conforme mostrado na Figura 8. Para obter uma descrição detalhada de cada cmdlet, execute este comando:
Get-Command -PSSnapin windows.serverBackup | select name | get-help –full
Figura 6 Os cmdlets do Backup do Windows Server
Há outro utilitário interno do Windows Server 2008 que também pode utilizar o gravador VSS do Hyper-V e que acrescenta um pouco de flexibilidade às suas opções de script. O DiskShadow.exe permite que uma cópia de sombra seja realizada e montada como uma unidade, o que possibilita aos administradores fazer um backup mais selectivo do que seria possível usando o WSB. E é importante que se lembre de que o DiskShadow não aceita entrada do pipeline do Windows PowerShell; em vez disso, ele exige que os comandos sejam passados por meio de um script, que pode ter uma aparência como esta:
Delete Shadows Volume C:
Set Context Persistent
Begin Backup
Writer Verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
Add Volume C: ALIAS MyShadow
Create
End Backup
Expose %MyShadow% X:
Exit
Este script primeiro exclui qualquer cópia de sombra existente da unidade C:, depois, garante que a cópia de sombra persistirá após a execução do DiskShadow. Em seguida, cria um bloco transaccional — se qualquer uma das etapas falhar, o processo inteiro falhará. Nesse bloco, o DiskShadow verifica se o gravador para o Hyper-V está carregado e adiciona a unidade C: à lista de unidades das quais será feito backup.
A unidade C: irá obter um GUID para identificá-la, e esse GUID será armazenado em uma variável de ambiente chamada "MyShadow". Quando esse procedimento for concluído, a cópia de sombra será criada.
O backup é exposto como unidade X: usando a variável de ambiente. É possível fazer muitas coisas com os dados em X:, e depois DiskShadow pode ser executado novamente com o comando Unexpose X: para remover a unidade.
Observe que a restauração de VMs Hyper-V com backup feito via DiskShadow é actualmente um processo manual (a VM precisa ser recriada, os Snapshots não são preservados, e assim por diante). Embora isso tenha algumas desvantagens evidentes, os dados são protegidos.
A intenção deste post é mostrar a lista de sistemas operativos servidor e cliente que são suportados numa máquina virtual Hyper-V em execução no Windows Server 2008.
Sistemas operativos de servidor suportados
O Windows Server 2008, x64 edições
Nota: Máquinas virtuais estão configuradas para utilizar um, dois ou quatro processadores virtuais.
· O Windows Server 2008 Standard
· Windows Server 2008 Enterprise
· Windows Datacenter Server 2008
· HPC do Windows Server 2008
· Web do Windows Server 2008
· O Windows Server 2008 Standard sem Hyper-V
· Windows Server 2008 Enterprise sem Hyper-V
· Windows Server 2008 Datacenter sem Hyper-V
· Windows Essential Business Server 2008
· O Windows Small Business Server 2008
O Windows Server 2008, x86 edições
Nota: Máquinas virtuais estão configuradas para utilizar um, dois ou quatro processadores virtuais.
· O Windows Server 2008 Standard (x86 Edition)
· Windows Server 2008 Enterprise (x86 Edition)
· Windows Server 2008 Datacenter (x86 Edition)
· Web do Windows Server 2008 (x86 Edition)
· O Windows Server 2008 Standard sem Hyper-V (x86 Edition)
· Windows Server 2008 Enterprise sem Hyper-V (x86 Edition)
· Windows Server 2008 Datacenter sem Hyper-V (x86 Edition)
Windows Server 2003, x86 edições
Nota: Máquinas virtuais estão configuradas para utilizar um ou dois processadores virtuais.
· Windows Server 2003 R2 Standard x86 Edition com Service Pack 2
· O Windows Server 2003 R2 Enterprise x86 Edition com Service Pack 2
· O Windows Server 2003 R2 Datacenter x86 Edition com Service Pack 2
· Windows Server 2003 Standard x86 Edition com Service Pack 2
· O Windows Server 2003 Enterprise x86 Edition com Service Pack 2
· O Windows Server 2003 Datacenter x86 Edition com Service Pack 2
· Windows Web de servidor 2003 Edition com Service Pack 2
O Windows Server 2003, x64 edições
Nota: Máquinas virtuais estão configuradas para utilizar um ou dois processadores virtuais.
· Windows Server 2003 R2 Standard x64 Edition com Service Pack 2
· O Windows Server 2003 R2 Enterprise x64 Edition com Service Pack 2
· O Windows Server 2003 R2 Datacenter x64 Edition com Service Pack 2
· Windows Server 2003 Standard x64 Edition com Service Pack 2
· O Windows Server 2003 Enterprise x64 Edition com Service Pack 2
· O Windows Server 2003 Datacenter x64 Edition com Service Pack 2
Microsoft Windows 2000 Server
Nota: Máquinas virtuais são configuradas para utilizar um processador virtual.
· Windows 2000 Server com o Service Pack 4
· Windows 2000 Advanced Server com Service Pack 4
Distribuições de Linux
Nota: Máquinas virtuais são configuradas para utilizar um processador virtual.
· Servidor de empresa de Linux SUSE 10 com o Service Pack 2 x86 Edition
· Servidor de empresa do Linux SUSE 10 com o Service Pack 2 x64 Edition
· Servidor de empresa de Linux SUSE 10 com o Service Pack 1 x86 Edition
· Servidor de empresa do Linux SUSE 10 com o Service Pack 1 x64 Edition
Sistemas operativos clientes suportados
Windows Vista, x86 edições
Nota: Máquinas virtuais estão configuradas para utilizar um ou dois processadores virtuais.
· Windows Vista Business x86 com Service Pack 1
· Windows Vista Enterprise x86 com Service Pack 1
· Windows Vista Ultimate x86 com Service Pack 1
Windows Vista, x64 edições
Nota: Máquinas virtuais estão configuradas para utilizar um ou dois processadores virtuais.
· Windows Vista Business x64 com o Service Pack 1
· Windows Vista Enterprise x64 com o Service Pack 1
· Windows Vista Ultimate x64 com o Service Pack 1
Windows XP Professional, x86 edições
· O Windows XP Professional x86 com Service Pack 3
Nota: Máquinas virtuais estão configuradas para utilizar um ou dois processadores virtuais.
· O Windows XP Professional x86 com Service Pack 2
Nota: Máquinas virtuais são configuradas para utilizar um processador virtual.
Windows XP Professional, x64 edições
Nota: Máquinas virtuais estão configuradas para utilizar um ou dois processadores virtuais.
· O Windows XP Professional x64 com o Service Pack 2