Best Practices para Exchange 2010 no Hyper-V
Este documento disponibilizado no domingo pela Microsoft é útil não só em casos de Exchange mas como em qualquer outro projeto de virtualização com Hyper-V.
O documento foca nas melhores práticas de implementação do Exchange 2010 no Hyper-V mas adicionalmente explica as tecnologias envolvidas e o porque da recomendação.
Por exemplo, explica cada tipo de disco que o Hyper-V suporta (DAS, iSCSI, eSATA, etc) e considera qual o melhor a ser utilizado e recomendações como termos mais de uma placa de rede no caso de iSCSI, performance de discos virtuais fixos versus dinamicos, etc.
Mas como o documento é focado em Exchange, achei algumas recomendações muito interessantes, principalmente o resumo que ele apresenta com os itens:
- Snapshots, differencing/delta disks
- Virtual processor/physical processor core ratios greater than 2:1
- Applications running on the root virtual machine (excluding antivirus, backup, management software, and so on).
Do meio do documento para frente ele passa a descrever um cenário de exemplo e mostrar os cáculos envolvidos pela carga do cliente e como seria o sizing, incluindo DAG e recomendações sobre como usar da melhor forma.
Resumindo, leitura imperdível!!!!!!
Faça o download em http://www.microsoft.com/downloads/en/details.aspx?FamilyID=8647c69d-6c2c-40ca-977e-18c2379b07ad
Oracle VirtualBox chega na versão 4.0
Dia 22/12 a Oracle liberou a versão 4.0 do VirtualBox, na minha opinião o melhor gerenciador de VMs para utilizar em clientes. Se quiser saber os motivos, veja o post Utilizando VMs de 64 bits.
As novidades se concentram em muitos aspectos internos, porem a interface se aproximou mais do Hyper-V e do VMWare mostrando snapshots do estado da máquina:
Outra interessante função que fazia muita falta é o recurso de chamar uma VM diretamente por um atalho, como fazemos com o Windows Virtual PC (do Windows 7), que agora é possivel:
Para ver as alterações e baixar o software clique aqui http://www.virtualbox.org/wiki/Changelog
Documentação de Implementação do App-V 4.6
Apesar de já estar em uma versão avançada, o App-V ainda é desconhecido de muitos profissionais. Porem, trata-se de uma ferramenta para virtualização, mas ao invés de hosts virtualiza aplicações. O seu nome anterior do produto era SoftGrid que foi comprado pela Microsoft.
MODELOS DE IMPLEMENTAÇÃO
Basicamente, o App-V permite que aplicações sejam “sequenciadas” e gera-se um pacote com a aplicação, extensão osd.
Note que a aplicação é instalada no papel do servidor “Sequenciador” no (item 1) que gera o pacote que é distribuído pelo System Center ou pelo próprio App-V Server (item 3) para os usuários que tem as aplicações publicadas por regras no AD administradas pelo console do App-V (item 2).
Também é possível não usar uma estrutura tão complexa como a acima e apenas um servidor que sequencia e distribui a aplicação, mas note que neste diagrama usa-se tanto estações quanto o Terminal Services ou RDS (Remote Desktop Service) do Windows 2008.
A vantagem de usar o RDS/TS para publicar a aplicação é que os usuários não precisaram ter a aplicação instalada no farm, por exemplo, criando um ambiente muito mais versátil quando utiliza-se este modelo.
A aplicação pode ser enviada para o cliente tanto pelo protocolo proprietário (RTPS/S) como HTTP. Veja no final a referencia para utilizar HTTP no processo de publicação e distribuição dos pacotes.
VANTAGENS E FUNCIONAMENTO
As vantagens do App-V começam no fato de não ter a instalação individual do pacote nas maquinas. Com isso não precisamos publicar um msi no AD ou no SCCM. A aplicação é copiada na maquina do usuário pelo cliente do App-V na primeira execução e extraído dinamicamente quando da execução.
Como a aplicação sequenciada nada mais é do que um cliente witness que monitora uma instalação e copia no osd todas as alterações criadas pelo instalador, o papel do cliente do App-V é fazer as cópias virtuais dos arquivos (dll, exe, bin, etc.) para os diretórios virtuais correspondentes e também as chaves de registry de forma virtual no registro do Windows.
Um exemplo prático seria a instalação de 3 diferentes versões do Office (2003, 2007 e 2010) na MESMA MAQUINA:
- No servidor de sequenciamento do App-V instalamos as 3 versões separadamente criando os 3 pacotes de arquivos, contendo os binários, chaves de registry e outros arquivos da aplicação
- Utilizando o console do App-V designamos as 3 versões do Office para um usuário
- O cliente do App-V baixa os 3 pacotes individualmente (osd e arquivos auxiliares) para um diretório de conteúdo temporário
- O cliente App-V cria os 3 atalhos na estação para as versões individuais, sem que a aplicação esteja fisicamente instalada
- Ao clicar no ícone de cada versão o cliente do App-V explode o osd e cria as chaves de registry e copia os arquivos da aplicação, porem em uma camada virtual
- A aplicação é executada e ao final esta camada virtual é destruída
Este modelo de uso permitirá que ao executar uma aplicação o usuário não tenha “restos” de seus binários no sistema operacional, permitindo compatibilizar aplicações mais novas com as mais antigas.
Outra vantagem indiscutível é a atualização, já que ao sequenciar um service pack ou hotfix o cliente não irá baixar o pacote inteiro, mas sim apenas as atualizações. Além, claro, que ao atualizar no servidor os clientes automaticamente estarão atualizado.
QUEM TEM DIREITO AO App-V
O App-V não é vendido separadamente em formato FPP (caixinha) como outros produtos. Na versão anterior que se chama SoftGrid fazia parte do pacote MDOP que era composto por outros aplicativos.
Agora o App-V é vendido como parte do pacote Microsoft Desktop Optimization Pack, como ferramenta Microsoft Application Virtualization for Terminal Services ou para assinantes do MSDN.
INFORMAÇÕES ADICIONAIS
Hot site do produto: http://www.microsoft.com/systemcenter/appv/default.mspx
Documento de implementação com RDS/TS: App-V Remote Desktop Services.docx (119,87 kb)
Publicando e distribuindo por HTTP: http://blogs.technet.com/b/appv/archive/2010/12/02/guide-to-configuring-microsoft-app-v-to-both-publish-and-stream-via-http.aspx
Atualizado 26/10/2010: Hyper-V com Windows 2008 R2 Service Pack 1 Beta
Atualizado: Liberado o Release Candidate em 26/10/2010: http://www.microsoft.com/windowsserver2008/en/us/sp1.aspx
Hoje consegui instalar o Service Pack Beta 1 do Windows Server 2008 R2 e achei bem interessante as mudanças no Hyper-V (Dynamic Memory), como já estava anunciado (http://technet.microsoft.com/en-us/evalcenter/ff183870.aspx).
Como pode ser visto na imagem acima, você pode escolher memória estática (fixa) ou dinâmica.
O interessante são as possibilidades de indicar quanto a memória irá ser incrementada baseada na prioridade da máquina em relação a outras máquinas virtuais (VM) no mesmo servidor. No slider Memory Priority você indicará como as máquinas ao ser inicializada poderão alocar memória do Hyper-V.
NOTA: É importante frisar que para a memória ser dinâmica EM EXECUÇÃO é necessário que as VMs com Windows 2008 R2 e Windows 7 estejam também com o SP1 Beta. Em outras VMs as maquinas alocarão memória conforme forem sendo iniciadas.
Sequenciando as VMs no Hyper-V
No nosso ambiente instalamos um servidor Dell e as cinco VMs antes distribuidas em 3 maquinas físicas foram consolidadas. Porem, nossos Domain Controllers são duas VMs e notamos o problema da falta de um DC no momento do startup das outras VMs, principalmente a do Exchange, quando o servidor é atualizado pelo WUA, por exemplo ou em caso de pane na host.
Como resolver isso?
Solução 1
A maquina fisica ser o Domain Controller e hospedar os FSMOs.
A desvantagem deste método é que a recomendação padrão é que a maquina do Hyper-V seja dedicada a esta função, e que nem driver de video ela tenha (Problemas com o driver Intel Graphics Media Integrated HD e o Hyper-V). Tanto esta solução quanto a abaixo não eram viáveis porque o cliente mantem uma segunda maquina em outro local fisico com as VMs copiadas para apenas atualizar o BD do SQL em caso de pane do servidor ou do prédio, e sincronizar AD neste caso seria inviável.
Solução 2
Colocar um servidor fisico hospedando o AD.
Não é víável para este cliente porque sua intenção foi comprar um servidor bi-processado, fontes redundantes e storage dedicado, alem de um poderoso no-break para 1h30m de operação. Colocar mais um servidor seria contra o projeto apresentado, até porque no ambiente também existe um servidor System Center Data Protection Manager (DPM) que não pode ser DC. Com isso, precisamos limitar o ambiente a 3 maquinas físicas (servidor Hyper-V, DPM e TMG).
Solução 3 
Sequenciar as VMs, fazendo com que a DC que hospeda o FSMO fosse a primeira.
Esta se tornou a opção ideal, não incluiria mais uma maquina a ser gerenciada e permitiria fazer o restore de emergencia rapidamente no caso de pane do servidor.
Porem, note que este processo é invertido. Não se diz qual máquina irá ligar na frente, mas sim coloca-se um delay nas maquinas que dependem. Isso pode ser feito nas configurações de cada VM que dependa de outra maquina e alterar as configurações “Automatic Start Action”, como mostrado abaixo:
NOTA: Esta solução é adequada para casos de reinicio do servidor onde as VMs foram salvas e irão reiniciar automaticamente e não se aplicam ao startup manual, obviamente.