October 2008 October 2008
Virtualização: Uma introdução ao Hyper-V no Windows Server 2008
A introdução do Hyper-V torna a virtualização uma solução ainda mais atraente para ambientes de TI. Obtenha uma visão geral do mercado de virtualização atual e veja como o Hyper-V aumenta a capacidade de gerenciamento, a confiabilidade e a segurança da virtualização Rajiv Arunkundram
Virtualização: Gerencie os ambientes virtuais com o VMM 2008
O System Center Virtual Machine Manager fornece uma interface consolidada para gerenciar toda a infra-estrutura virtual. A versão mais recente agrega suporte ao Hyper-V do Windows Server 2008, bem como a máquinas virtuais VMware. Explore os novos recursos e obtenha uma visão geral do uso do VMM para centralizar as tarefas de gerenciamento. Edwin Yuen
Virtualização: Introdução a Microsoft Application Virtualization
A Microsoft Application Virtualization (App-V) permite apresentar desktops virtualizados a sistemas clientes em toda a organização. Isso simplifica o gerenciamento do sistema e libera os funcionários dos desktops. Observe atentamente como funciona a App-V e saiba como é possível implantá-la na organização. Anthony Kinney
Virtualização: Obtendo alta disponibilidade para o Hyper-V
Consolidar servidores em menos máquinas físicas traz diversas vantagens, mas é muito importante que você planeje a alta disponibilidade dos seus sistemas. Aqui, você encontra um guia de utilização do cluster de failover do Windows Server 2008 para conferir alta disponibilidade a suas máquinas virtuais Hyper-V. Steven Ekren
Virtualização: Backup e recuperação de desastre para a virtualização de servidores
A virtualização introduz alterações importantes na recuperação de desastres. Aqui, você encontra uma explicação de como a plataforma de virtualização da Microsoft se inclui no seu plano de recuperação de desastre, além de uma análise detalhada das opções de backup e restauração e de algumas considerações sobre o Windows Server 2008 Hyper-V. Adam Fazio
Virtualização: Ferramentas essenciais para planejar a infra-estrutura virtual
A infra-estrutura está pronta para virtualização? O Microsoft Assessment and Planning Toolkit, uma ferramenta de avaliação da infra-estrutura em toda a rede, pode ajudar a compreender melhor a infra-estrutura de TI e determinar se os sistemas estão prontos para a atualização ou a migração para várias tecnologias, inclusive a virtualização. Jay Sauls and Baldwin Ng
Columns
Do editor: é um mundo virtual(izado): | Cartas: com a palavra, os leitores: | Caixa de ferramentas: Novos produtos para profissionais de TI:
P+R SQL: Logs de transações grandes, quando usar Reparar e muito mais : Nesta edição, Paul Randal responde a perguntas sobre o backup e a restauração, observa as diferenças entre o envio de logs e o espelhamento de banco de dados, além de explicar por que a função Reparar só deve ser usada como último recurso.Paul S. Randal | Utilitário em destaque: Ferramenta de manutenção de máquina virtual offline: As máquinas virtuais armazenadas offline não recebem automaticamente as atualizações necessárias para mantê-las seguras e compatíveis. Isso, por sua vez, pode oferecer risco a todo o ambiente de TI. Saiba como a Ferramenta de manutenção de máquina virtual offline permite automatizar o processo de atualização das máquinas virtuais.Peter Skjøtt Larsen and Suveen Kumar Reddy Vuppala | Windows PowerShell: O poder dos perfis: Já desejou que o Windows PowerShell fosse iniciado com um ambiente de trabalho ajustado às suas necessidades? Don Jones demonstra como é possível usar perfis para personalizar o shell do Windows PowerShell.Don Jones
Ei, Equipe de Scripts!: Famosas últimas palavras: A Equipe de Scripts discute Sócrates e revisita o assunto das consultas a um arquivo XML. Só que, desta vez, o arquivo XML é estruturado de forma que, em vez de usar nós filho, valores adicionais de propriedades são configurados como atributos.The Microsoft Scripting Guys | Os arquivos da área de trabalho: Personalizando serviços de implantação do Windows: Wes Miller se aprofunda nos serviços de implantação do Windows, mostrando como você pode personalizar e configurar o WDS para atender às necessidades da sua organização.Wes Miller | Security Watch: Revisitando as 10 leis imutáveis da segurança, parte 1: Lá se vão cerca de 8 anos desde que 10 leis imutáveis da segurança foram publicadas pela primeira vez, e muito mudou de lá para cá. Neste mês, Jesper Johansson dá início a uma série de três partes nas quais ele analisa as leis sob a perspectiva atual para saber se elas ainda se aplicam.Jesper M. Johansson
Anotações de campo: Código de barra colorido de alta capacidade: Gavin Jancke desenvolveu um novo código de barra, usando cores e triângulos, que possui uma capacidade de dados muito maior do que os tradicionais códigos de barra em preto-e-branco. Dê uma olhada mais de perto nesses códigos de barra de alta capacidade.Gavin Jancke | Segredos do Windows: Mais trabalho com menos inteligência?: Raymond Chen observa a relação inclinada que os bugs têm com os erros e explica por que é importante que os programadores sofram, bem como apresentem resultados.Raymond Chen


Virtualização
Uma introdução ao Hyper-V no Windows Server 2008
Rajiv Arunkundram
Visão geral:
  • O que é virtualização?
  • Três arquiteturas de virtualização
  • Hipervisor com microkernel X monolítico
  • O que faz o Hyper-V

Sumário
O mercado de virtualização de servidor
Como funciona a virtualização de servidor
Tipos de solução em virtualização
Hipervisor do Windows
A partição pai
Arquitetura de compartilhamento de dispositivo
Componentes de integração
O conjunto de recursos do Hyper-V
Escalabilidade
Alta disponibilidade
Segurança
Capacidade de gerenciamento
Conclusão
Ultimamente, tem se falado muito sobre virtualização, e grande parte da discussão é especificamente a respeito da virtualização de servidor. Trata-se de uma das tendências mais interessantes do setor e a que apresenta o potencial, nos próximos anos, de mudar o paradigma de como os sistemas de TI são implantados. Mas a virtualização de servidor irá não apenas alterar a forma como os administradores de TI e arquitetos pensam os servidores e a utilização do sistema, mas também afetar os processos e as ferramentas usadas para gerenciar o que certamente se tornará um ambiente cada vez mais dinâmico.
Na verdade, a virtualização já está por aí há um bom tempo, mas a tecnologia ainda está em evolução. Na realidade, a própria palavra ainda tem significados diferentes para pessoas diferentes. No entanto, em termos mais amplos, virtualização diz respeito à abstração de uma camada da pilha de tecnologias da próxima camada como o armazenamento em servidores ou o sistema operacional nos aplicativos. Por sua vez, a abstração de camadas diferentes permite a consolidação e uma capacidade maior de gerenciamento.
Como conceito, a virtualização se aplica a armazenamento, redes, servidores, aplicativos e acesso. Quando você observa armazenamento e redes, o objetivo da virtualização é agregar um conjunto de dispositivos diferentes de forma que o pool de recursos seja semelhante a e aja como uma entidade única. Por exemplo, é possível configurar uma solução em armazenamento de 40 TB em lugar de um conjunto de 20 dispositivos de armazenamento de 2 TB. Mas, com outros componentes, a virtualização age no sentido contrário, ajudando a fazer com que seja exibido um único sistema, muito embora haja vários. O exemplo mais comum disso é a virtualização de servidor, em que você hospeda várias instâncias de sistema operacional e ambientes em um único servidor.
A Microsoft abordou a virtualização em vários níveis diferentes, passando do desktop para o data center com soluções para virtualização de servidor, virtualização de aplicativo, virtualização de apresentação e virtualização de desktop. O thread comum a todas elas é a parte de gerenciamento do Microsoft System Center. Neste artigo, estou me concentrando no componente de virtualização de servidor e, mais especificamente, em como o Hyper-V, um recurso chave do Windows Server 2008, entra na equação de um data center dinâmico.

O mercado de virtualização de servidor
Primeiro, acho que valeria a pena observar o que existe no ambiente atual e para onde o mercado geral está voltado. Dependendo da pesquisa que você lê, alguns analistas estimam que entre 5 e 9 por cento de todos os servidores físicos vendidos atualmente estão sendo usados como hosts de virtualização. Você pode considerar essa uma boa parte dos sistemas em um mercado em que chegam mais de nove milhões de servidores físicos todos os anos. Mas uma coisa é certa: ainda existe uma enorme oportunidade de mercado à medida que mais clientes se sentem confortáveis com a virtualização e desejam empregá-la.
É importante observar onde a virtualização está sendo adotada. Os clientes corporativos estiveram certamente à frente com o teste, sendo os primeiros a adotá-la. No entanto, existem pequenas e médias empresas que também estão implantando a virtualização. A adoção da virtualização chega a vários tipos diferentes de cargas de trabalho, de aplicativos de negócios e de gerenciamento até a Web e o email.
E por que toda essa repercussão da virtualização agora? Existem alguns fatores, dentre os quais está o tempo. Alguns fatores-chave do setor aconteceram simultaneamente, ajudando a impulsionar a maior adoção da virtualização. Entre esses fatores do setor estão a migração para a computação em 64 bits, os processadores com vários núcleos e até mesmo o incentivo à computação sustentável para melhorar a utilização do sistema.
Os sistemas estão ficando muito maiores e exigem uma tecnologia como a virtualização para que toda a eficiência do sistema seja usada. E embora seja verdade que a tecnologia básica (e a lei de Moore) tenha sido constante em termos de produção de maior capacidade de processamento do que os sistemas podem usar, agora também estamos mais conscientes do impacto ambiental, dos requisitos de energia e dos custos de resfriamento.
Todos esses fatores, somados à simples justificativa do retorno do investimento (ROI) de adoção da virtualização, devem, juntos, agilizar a adoção da virtualização em pequenas e médias empresas. E nós, os profissionais de TI, podemos esperar que todos os principais nomes continuem investindo nessa tecnologia durante os próximos anos e melhorando os recursos e a funcionalidade.

Como funciona a virtualização de servidor
Em termos gerais, a virtualização de servidor permite pegar um único dispositivo físico e instalar (e executar simultaneamente) dois ou mais ambientes de sistema operacional potencialmente diferentes e ter identidades diferentes, pilhas de aplicativos etc. Hyper-V é uma tecnologia de virtualização baseada em hipervisor de 64 bits, da próxima geração, que oferece recursos de plataforma confiáveis e escalonáveis. Com o System Center, ele oferece um conjunto único de ferramentas de gerenciamento integradas para recursos físicos e virtuais.
Tudo isso funciona para reduzir custos, aumentar a utilização, otimizar a infra-estrutura e permitir à empresa provisionar novos servidores rapidamente. Para poder ajudá-lo a compreender melhor como o Hyper-V está arquitetado, quero primeiro observar os tipos diferentes de solução em virtualização.

Tipos de solução em virtualização
Basicamente, existem três arquiteturas gerais usadas na virtualização de servidor, como mostra a Figura 1. As diferenças fundamentais dizem respeito à relação entre a camada de virtualização e o hardware físico. Com “camada de virtualização” me refiro à camada de software chamada de monitor de máquina virtual (VMM, não confundir com Virtual Machine Manager). É essa camada que fornece a possibilidade de criar várias instâncias isoladas que compartilham os mesmos recursos de hardware subjacentes.
Figura 1 As três arquiteturas de virtualização (Clique na imagem para ampliá-la)
A arquitetura Tipo-2 VMM é exemplificada por Máquinas Virtuais Java. Aqui, o objetivo da virtualização é criar um ambiente de tempo de execução no qual o processo possa executar um conjunto de instruções sem depender do sistema host. Nesse caso, o isolamento se destina aos processos diferentes e permite que um único aplicativo seja executado em sistemas operacionais diferentes sem que haja preocupação com as dependências do sistema operacional. A virtualização de servidor não se encaixa nessa categoria.
Tipo-1 VMM e Hybrid VMMs são as duas abordagens mais comumente encontradas dentre as mais usadas hoje em dia. Hybrid VMM é um estágio em que o VMM é executado com o sistema operacional host e ajuda a criar máquinas virtuais acima. Exemplos de Hybrid VMM são o Microsoft Virtual Server, o Microsoft Virtual PC, o VMware Workstation e o VMware Player. Você deve observar que, embora esses tipos de solução sejam excelentes para um cenário de cliente em que você é o único executando máquinas virtuais em parte do tempo, os VMMs geram uma sobrecarga considerável e, por isso, não são apropriados a cargas de trabalho que exigem muitos recursos.
Em uma arquitetura Tipo-1 VMM, a camada do VMM é executada diretamente acima do hardware. Ela costuma ser chamada de camada do hipervisor. Essa arquitetura foi projetada originalmente na década de 60 pela IBM para sistemas de mainframe e foi recentemente disponibilizada nas plataformas x86/x64 com várias soluções, inclusive o Hyper-V do Windows Server 2008.
Há soluções disponíveis em que o hipervisor é uma parte incorporada do firmware. No entanto, trata-se apenas de uma opção de empacotamento e que não altera, de fato, a tecnologia subjacente.
Como você pode ver em Tipo-1 VMMs, existem basicamente duas formas de arquitetar as soluções em hipervisor: com microkernel e monolítica. Essas duas abordagens, como mostra a Figura 2, são Tipo-1 VMMs efetivos que apresentam o hipervisor instalado diretamente no hardware físico.
Figura 2 As duas formas de arquitetar soluções em hipervisor (Clique na imagem para ampliá-la)
A abordagem de hipervisor monolítico hospeda o hipervisor/VMM em uma única camada que também inclui a maioria dos componentes obrigatórios como, por exemplo, o kernel, os drivers de dispositivo e a pilha de E/S. Trata-se da abordagem usada por soluções como, por exemplo, o VMware ESX e os sistemas de mainframe tradicionais.
A abordagem com microkernel usa um hipervisor especializado, muito fino, que só executa as tarefas principais de garantia do isolamento da partição e de gerenciamento da memória. Essa camada não inclui a pilha de E/S ou os drivers do dispositivo. Trata-se da abordagem usada pelo Hyper-V. Nessa arquitetura, a pilha de virtualização e os drivers de dispositivo específicos do hardware estão localizados em uma partição especializada, chamada de partição pai.

Hipervisor do Windows
A garantia da existência de uma clara separação entre vários sistemas operacionais é feita com a criação de processadores virtuais, memória, temporizadores e controladores de interrupção. Os sistemas operacionais usam esses recursos virtuais da mesma forma que usariam seus equivalentes físicos.
O hipervisor do Windows, parte do Hyper-V, realiza as seguintes tarefas:
  • Cria partições lógicas.
  • Gerencia a memória e o agendamento do processador para sistemas operacionais convidados.
  • Fornece mecanismos para virtualizar a entrada/saída e se comunicar em meio às partições.
  • Impõe regras de acesso à memória.
  • Impõe uma diretiva de uso da CPU.
  • Expõe uma interface programática simples conhecida como hiperchamada.
Por usar a abordagem com microkernel, o hipervisor do Windows é bem pequeno – menos de 1 MB. Essa superfície mínima ajuda a aumentar a segurança geral do sistema.
Um dos requisitos para executar o Hyper-V é que você tenha um sistema x64 com tecnologias Intel VT ou AMD-V. A tecnologia x64 permite acessar um espaço de endereçamento maior e oferecer suporte a sistemas com mais memória e, assim, permite mais máquinas virtuais em um único sistema de host. Intel VT e AMD-V são soluções em virtualização assistidas por hardware que fornecem uma camada ultraprivilegiada na arquitetura em anel que ajuda a manter o ambiente de execução do hipervisor separado do restante do sistema. Elas também permitem ao Hyper-V executar um sistema operacional convidado não-modificado sem incorrer em perdas significativas de desempenho da emulação.

A partição pai
O Hyper-V consiste em uma partição pai, essencialmente uma máquina virtual com acesso especial ou privilegiado. Trata-se da única máquina virtual com acesso direto aos recursos de hardware. Todas as demais máquinas virtuais, conhecidas como partições convidadas, passam pela partição pai para ter acesso ao dispositivo.
A existência da partição pai é bem transparente. Ao começar a instalar o Hyper-V, a primeira coisa que você deve fazer é instalar o Windows Server 2008 x64 Edition no sistema físico. Em seguida, é preciso ir até o Gerenciador do Servidor, habilitar a função Hyper-V e reiniciar o sistema. Após a reinicialização do sistema, o hipervisor do Windows é carregado primeiro e, em seguida, o restante da pilha é convertido na partição pai.
A partição pai tem a propriedade do teclado, do mouse, do monitor de vídeo e dos demais dispositivos conectados ao servidor host. Ela não tem controle direto sobre os temporizadores e os controladores de interrupção usados pelo hipervisor.
A partição pai contém um provedor de Instrumentação de Gerenciamento do Windows (WMI) para facilitar o gerenciamento de todos os aspectos do ambiente virtualizado, bem como uma pilha de virtualização que realiza tarefas relacionadas a hardware em nome das partições filho. Além disso, os drivers de qualquer fornecedor independente de hardware (IHV) necessários ao hardware de sistema host estão na partição pai e todos os drivers criados para o Windows Server 2008 edições x64 também funcionarão na partição pai.

Arquitetura de compartilhamento de dispositivo
Um dos componentes arquitetônicos inovadores do Hyper-V é a nova arquitetura de compartilhamento de dispositivo que oferece suporte a dispositivos emulados e sintéticos em cada sistema operacional. A emulação de dispositivo é muito útil para oferecer suporte a sistemas operacionais anteriores com drivers de dispositivo projetados para gerações de hardware anteriores. Por exemplo, o Hyper-V inclui uma emulação do adaptador de rede Intel 21140, que era chamado de DEC 21140 no momento em que muitos sistemas operacionais anteriores eram lançados.
Em geral, a emulação de dispositivo é lenta, não pode ser estendida facilmente, além de não ser bem dimensionada. Mas, ela continua importante porque permite executar grande parte dos sistemas operacionais x86 no Hyper-V. Como a virtualização agora está migrando de uma tecnologia segmentada unicamente de teste e desenvolvimento para uma tecnologia essencial destinada a ambientes de produção, o usuários exigem um melhor desempenho para que consigam executar cargas de trabalho maiores. Os dispositivos emulados não atendem mais a essas demandas cada vez maiores.
Uma solução alternativa a esse problema é usar dispositivos sintéticos Hyper-V. Sintéticos são dispositivos virtuais mapeados diretamente para dispositivos físicos. Diferentemente dos dispositivos emulados, os sintéticos não emulam hardware herdado. Com o modelo de compartilhamento do hardware Hyper-V, os sistemas operacionais interagem diretamente com dispositivos sintéticos que talvez não tenham equivalentes físicos. Esses sistemas operacionais usam clientes de serviço virtual (VSCs), que funcionam como drivers de dispositivo no sistema operacional convidado.
Em vez de acessar o hardware físico diretamente, os VSCs usam o VMBus, um barramento na memória de alta velocidade, para acessar provedores de serviço virtuais (VSPs) na partição pai. Em seguida, os VSPs da partição pai conseguem acessar o hardware físico subjacente, conforme ilustra a Figura 3. Um dos principais benefícios dos dispositivos sintéticos é que seu desempenho em relação ao VMBus está mais próximo do desempenho dos dispositivos de hardware não-virtualizados.
Figura 3 VSCs usam o VMBus para acessar VSPs, que conseguem acessar o hardware físico subjacente (Clique na imagem para ampliá-la)

Componentes de integração
O Hyper-V foi criado para fornecer limites definidos entre várias instâncias em execução em um computador. Para habilitar a interação entre os sistemas operacionais convidado e host e fornecer uma funcionalidade adicional a sistemas operacionais convidados para os quais há suporte, o Hyper-V fornece componentes de integração.
Os componentes de integração do Hyper-V oferecem suporte aos seguintes recursos:
  • Sincronização de hora
  • Serviço de Cópias de Sombra de Volume (VSS)
  • Funcionalidade de pulsação
  • Desligamento convidado
  • Troca do par de valores chave (usada para acessar o Registro de um sistema operacional convidado)
  • Identificação do sistema operacional
O conjunto de recursos do Hyper-V
Não é preciso dizer que, quanto mais próxima a plataforma de virtualização chega do funcionamento como o servidor físico, mais fácil fica para as organizações implantar e contar com cargas de trabalho virtuais. Na minha opinião, existem quatro áreas principais nas quais é possível exibir recursos diferentes da plataforma de virtualização.
Atualmente, a maioria das soluções em virtualização baseadas em hipervisor é muito semelhante em termos de recursos e funcionalidade. À medida que avançarmos, coisas como o custo total de propriedade (TCO) e a facilidade de uso serão os principais diferenciais. E as soluções em gerenciamento verão investimentos contínuos e desenvolvimento para nos aproximar ainda mais da visão de um ambiente de TI dinâmico, em que a infra-estrutura é flexível o suficiente para se adaptar às necessidades da empresa e os modelos e as políticas ajudam a aumentar a automação e o gerenciamento.

Escalabilidade
Usando a arquitetura de hipervisor com microkernel, o Hyper-V apresenta uma sobrecarga de CPU muito baixa, deixando muito espaço para virtualizar as cargas de trabalho. Permitindo que máquinas virtuais usufruam os recursos eficientes e o hardware como, por exemplo, a tecnologia com vários núcleos, o melhor acesso a disco e mais memória, o Hyper-V aumenta a escalabilidade e o desempenho da plataforma de virtualização.
Combinado ao demais recursos do Windows Server 2008, o Hyper-V permite a você consolidar a maioria das cargas de trabalho – inclusive cargas de trabalho de 32 e 64 bits – em um único sistema. Além disso, ele pode ajudá-lo a equilibrar a adoção da tecnologia de 64 bits com o suporte contínuo a cargas de trabalho de 32 bits já usadas em todo o ambiente.
O fato de o Hyper-V exigir um sistema host de 64 bits com virtualização assistida por hardware ajuda a garantir que o sistema host tenha acesso a um pool maior de recursos da memória. O Hyper-V pode oferecer suporte a até 1 TB de memória no host e até 64 GB de memória por máquina virtual. Essa é a chave para aqueles que pretendem virtualizar cargas de trabalho que usam muita memória como, por exemplo, o Exchange Server e o SQL Server.
O Hyper-V também oferece suporte a até 16 processadores lógicos no sistema host, o que o torna escalonável diante da maioria dos sistemas com dois e quatro soquetes e vários núcleos. Também é possível criar uma máquina virtual com até quatro processadores virtuais para oferecer suporte a cargas de trabalho que exigem ou usufruem recursos de vários processadores.
A consolidação de servidores por meio do Hyper-V também permite que esses servidores usem um suporte ao sistema de rede eficiente, inclusive VLAN, conversão de endereço de rede (NAT) e diretivas de Proteção de Acesso à Rede (NAP) (quarentena). E, sendo um recurso do Windows Server 2008, o Hyper-V funciona bem com outros recursos do Windows Server como, por exemplo, BitLocker e Windows PowerShell.

Alta disponibilidade
Alta disponibilidade é um cenário em que o Hyper-V e os recursos de clustering do host funcionam juntos para ajudar a atender às necessidades de continuidade dos negócios e de recuperação de desastre. A continuidade dos negócios é a possibilidade de minimizar o tempo de inatividade programado e não-programado. Isso inclui o tempo que se perde com funções de rotina como, por exemplo, manutenção e backup, bem como interrupções imprevistas.
A recuperação de desastre é um componente importante da continuidade dos negócios. Desastres naturais, ataques mal-intencionados e até mesmo problemas de configuração simples como, por exemplo, conflitos de software podem prejudicar serviços e aplicativos até que os administradores resolvam os problemas e restaurem os dados. Uma estratégia confiável de negócios e de recuperação de desastre deve oferecer uma perda de dados mínima e recursos de gerenciamento remoto eficientes.
Ao observar a alta disponibilidade, você deve considerar três categorias diferentes: tempo de inatividade planejado, tempo de inatividade não-planejado e backups. A proteção contra o tempo de inatividade planejado costuma ser necessária para ajudar a migrar as máquinas virtuais do sistema host, de forma que seja possível realizar a manutenção do hardware ou aplicar patches ao sistema host ou à plataforma de virtualização (que pode exigir uma reinicialização).
A maioria das organizações tem janelas de manutenção planejadas, e o que você está procurando fazer aqui, de fato, é minimizar ou eliminar o período em que as máquinas virtuais não estarão disponíveis enquanto o sistema host estiver inativo para manutenção. Com o recurso Quick Migration, é possível migrar rapidamente uma máquina virtual em execução de um nó físico para outro em questão de segundos. Por isso, você pode manter as máquinas virtuais disponíveis para produção enquanto realiza a manutenção no host original. Uma vez concluída a manutenção, é possível usar a Quick Migration para restaurar o sistema original das máquinas virtuais.
Não planejado é o tempo de inatividade imprevisto. Ele pode ser uma catástrofe natural ou tão simples quanto alguém desconectar acidentalmente um cabo de alimentação e desligar um servidor. Embora isso possa parecer improvável, ao longo dos anos, conheci alguns administradores durante a Tech•Ed, VMworld, e em outras conferências que me contaram histórias sobre como um servidor foi desligado acidentalmente por um colega.
Com o Hyper-V, é possível definir um cluster host para os sistemas host diferentes e configurar todas as máquinas virtuais como recursos do cluster com failover para um sistema diferente em caso de falha de um dos hosts. Enquanto isso, o recurso de clustering multissite do Windows Server 2008 permitirá configurar um cluster dispersado geograficamente de forma que, caso o data center principal falhe, você tem a possibilidade de recuperar as máquinas virtuais diferentes usando um data center remoto.
Isso também é útil para proteger todas as filiais. Uma das vantagens do suporte ao tempo de inatividade não planejado com o Hyper-V é que ele desconhece o sistema operacional convidado, o que significa ser possível estender os benefícios de alta disponibilidade até máquinas virtuais Linux e versões anteriores do Windows Server para proteger e recuperar esses sistemas de maneira semelhante.
Ao observar o tempo de inatividade não-planejado, é importante notar que a recuperação se equivale a desligar o sistema e reiniciá-lo, o que significa que você perderá todas as informações sobre o estado. Isso pode ou não ser um problema, dependendo da carga de trabalho em execução na máquina virtual. Por isso é importante observar o backup no contexto da alta disponibilidade.
O Hyper-V permite fazer backups de todas as máquinas virtuais ou usar o VSS para fazer backups consistentes de todas as máquinas virtuais que reconhecem o VSS enquanto estão em execução. Com o VSS, é possível configurar os backups para que ocorram em intervalos definidos sem que haja impacto sobre a disponibilidade da carga de trabalho da produção, ao mesmo tempo em que exista a garantia de um plano de backup contínuo que possa ajudá-lo a recuperar facilmente o estado em caso de um tempo de inatividade não-planejado. Para obter mais informações sobre soluções em alta disponibilidade com o Hyper-V, consulte o artigo "Obtendo alta disponibilidade para o Hyper-V" de Steven Ekren nesta edição da TechNet Magazine (technet.microsoft.com/magazine/cc837977).

A arquitetura de hipervisor com microkernel foi projetada para minimizar a superfície de ataque e aumentar a segurança, especialmente quando o Hyper-V é implementado como uma função Server Core. Server Core é uma opção de instalação do Windows Server 2008. O hipervisor não contém drivers de dispositivo ou códigos de terceiros, o que favorece uma base mais estável, fina e segura para a execução de máquinas virtuais. O Hyper-V também proporciona uma segurança eficiente com base em funções usando a integração com o Active Directory. Além disso, o Hyper-V permite que as máquinas virtuais se beneficiem dos recursos de segurança em nível de hardware como, por exemplo, o bit desabilitar execução (NX), o que ajuda a aumentar ainda mais a segurança das máquinas virtuais.
O Hyper-V passou pelo Security Development Lifecycle (SDL), assim como os demais componentes do Windows Server, e houve ampla modelagem e análise para garantir que o Hyper-V fosse uma plataforma de virtualização altamente segura. Ao implantar o Hyper-V, não se esqueça de seguir as práticas recomendadas para implantar o Windows Server 2008 e também as do Hyper-V. Inclua o Active Directory, bem como soluções em antivírus e antimalware como parte do plano. E use recursos de administração delegados para garantir que você use os privilégios de acesso administrativos de maneira apropriada aos hosts do Hyper-V.

Capacidade de Gerenciamento
É fácil deixar um pequeno problema de expansão do servidor e chegar a uma grande expansão de máquina virtual. Trata-se de um risco devido à facilidade de implantação de máquinas virtuais. E com a mobilidade cada vez maior das máquinas virtuais, você também tem a responsabilidade de saber com exatidão onde as máquinas virtuais diferentes estão em execução, acompanhando os contextos de segurança etc.
Felizmente, com o Hyper-V você não precisa criar uma infra-estrutura de gerenciamento separada para o ambiente virtual. Ele se integra às ferramentas de gerenciamento Microsoft, System Center Virtual Machine Manager e Microsoft System Center Operations Manager, bem como a ferramentas de gerenciamento de terceiros. Isso permite gerenciar todos os recursos físicos e virtuais em um só console. Para obter detalhes sobre o System Center Virtual Machine Manager 2008, consulte o artigo de Edwin Yuen, "Gerencie os ambientes virtuais com o VMM 2008", nesta edição da TechNet Magazine (technet.microsoft.com/magazine/cc836456). Enquanto isso, o suporte ao Windows PowerShell facilita a automatização das tarefas.
O Hyper-V também fornece máquinas virtuais com uma possibilidade única de usar o hardware disponível. Como todos os drivers certificados pelo Windows Hardware Quality Lab (WHQL) podem ser executados na partição pai, o Hyper-V proporciona maior compatibilidade para drivers e dispositivos, o que facilita o gerenciamento de drivers diferentes que estejam em execução no ambiente.

Conclusão
Como mencionei anteriormente, o gerenciamento será uma área chave de desenvolvimento e diferenciação. Você certamente verá muita atividade nessa área nos próximos anos. De maneira geral, esse é um momento interessante porque a virtualização consegue um papel base. Caso ainda não tenha testado o Hyper-V ou simplesmente queira mais informações, vá até microsoft.com/Hyper-V.
Rajiv Arunkundram é gerente de produto sênior na Microsoft, voltado para a virtualização do servidor na divisão de Marketing do Windows Server. A principal responsabilidade de Rajiv é trabalhar com clientes e parceiros para ajudá-los a compreender a estratégia de virtualização e as soluções da Microsoft de uma perspectiva técnica e comercial.


Virtualização
Gerencie os ambientes virtuais com o VMM 2008
Edwin Yuen

Este artigo baseia-se em uma versão de pré-lançamento do Virtual Machine Manager 2008. Todas as informações deste artigo estão sujeitas a alterações.
Visão geral:
  • Suporte a VMs VMware
  • Script e automação baseados no Windows PowerShell
  • Gerenciamento consolidado, centralizado
  • Procedimentos de instalação

Sumário
Uma introdução ao Virtual Machine Manager 2008
Integração ao System Center
Instalação do Virtual Machine Manager 2008
Adicionando hosts ESX VMware
Migração de VMotion
Conclusão
No ano passado, a Microsoft apresentou o System Center Virtual Machine Manager 2007, que fornece uma interface consolidada para gerenciar uma infra-estrutura virtual com o Microsoft Virtual Server 2005 em execução. Agora, para coincidir com o lançamento do novo hipervisor Hyper-V do Windows Server 2008, foi lançada uma nova versão do Virtual Machine Manager (VMM). O System Center Virtual Machine Manager 2008 não apenas gerencia as instalações do Microsoft Virtual Server 2005 e do Hyper-V do Windows Server 2008, mas também oferece suporte estendido a servidores VMware Infrastructure 3 (ESX/ESXi). Com o VMM, agora você conta com uma interface de gerenciamento integrada que funciona com toda a infra-estrutura virtual, inclusive os sistemas Microsoft e VMware.
O VMM oferece suporte a todas as tarefas de virtualização tradicionais como, por exemplo, implantações rápidas de máquina virtual (VM) em modelos e VMs pré-configurados, conversões de físico em virtual (P2V), biblioteca centralizada de objetos de infra-estrutura virtual e até mesmo conversões de virtual em virtual (V2V) de máquinas virtuais VMware (arquivos de configuração VMX mais discos virtuais VMDK) em VMs Hyper-V. Além disso, a integração do VMM com o restante da família System Center relega o gerenciamento de sistemas físicos e virtuais a um simples painel.
Neste artigo, examinarei o VMM 2008 e os novos recursos que ele oferece a administradores de TI. Em seguida, observarei os requisitos e as etapas envolvidas em uma instalação do VMM. Por fim, observarei mais atentamente como usar alguns dos novos recursos do VMM 2008.

Uma introdução ao Virtual Machine Manager 2008
O System Center Virtual Machine Manager 2008 é um aplicativo autônomo que fornece gerenciamento centralizado, empresarial, de máquinas virtuais que estejam executando servidores Microsoft Virtual Server 2005 R2 SP1, Windows Server 2008 Hyper-V, Microsoft Hyper-V Server 2008 e VMware Infrastructure 3 (ESX/ESXi). Com os demais produtos do System Center, o VMM fornece gerenciamento de infra-estrutura física e virtual de ponta a ponta. A Figura 1 mostra o layout arquitetônico do Virtual Machine Manager.
Figura 1 Arquitetura do System Center Virtual Machine Manager 2008(Clique na imagem para ampliá-la)
Assim como os familiarizados com o VMM 2007 observarão, há muito mais interfaces com o sistema VMM no VMM 2008 (consulte a Figura 1). As caixas no canto superior esquerdo representam o VMM 2008; as caixas no canto inferior direito representam o System Center Operations Manager 2007, e os sistemas gerenciados e as interfaces são mostrados abaixo. As caixas vermelhas indicam os servidores de gerenciamento, as caixas azuis mostram as entradas de sistema e as verdes são os sistemas host gerenciados com os objetos gerenciados mostrados em amarelo.
A caixa vermelha no canto superior esquerdo representa o serviço de servidor do Virtual Machine Manager 2008. Acima dela estão as interfaces diferentes do serviço; o Administrator Console, a interface do Windows PowerShell e o portal da Web de auto-atendimento com acesso de usuário delegado. O Windows PowerShell é a base de todo o acesso ao servidor VMM. Como o VMM Admin Console se baseia inteiramente no Windows PowerShell, é possível criar scripts do Windows PowerShell executados pelo serviço do servidor VMM. Por isso, a API pública do VMM 2008 é o Windows PowerShell, e qualquer programa pode aproveitar o VMM usando o Windows PowerShell. Um grande exemplo disso é a integração do XenDesktop Desktop Delivery Controller da Citrix ao Virtual Machine Manager, inteiramente realizada por meio do Windows PowerShell.
Como suporte ao VMM existe um banco de dados do SQL Server 2005 ou do SQL Server 2008, uma instalação completa ou SQL Server Express Edition caso não haja nenhum outro banco de dados disponível. Embora o diagrama mostre o Operations Manager e o Virtual Machine Manager apontando para o SQL Server, os dois programas não compartilham um banco de dados. Eles apenas são executados na mesma versão do SQL Server. A integração real entre o Virtual Machine Manager e o Operations Manager se dá por meio de um conector disponível no VMM. Esse conector permite ao VMM e ao OpsMgr compartilhar dados, o que passa informações de virtualização para o OpsMgr e leva dados do OpsMgr para o VMM, tendo em vista as ações.
A parte inferior do diagrama mostra os hosts gerenciados. O VMM 2008 continua gerenciando os hosts de máquina virtual do Virtual Server 2005 R2 SP1 e um compartilhamento de biblioteca centralizado, como fazia no VMM 2007. Deve-se observar que, no VMM, o compartilhamento de biblioteca não é um armazenamento de arquivos especial ou servidor. Trata-se apenas de um compartilhamento de arquivos do Windows gerenciado pelo VMM. É possível gerenciar a biblioteca por meio do VMM ou copiar e excluir facilmente os arquivos do compartilhamento de arquivos e deixar que o VMM descubra as alterações. Você também pode ter várias bibliotecas, o que é útil para conjuntos delegados de servidores e para servidores em escritórios remotos.
A novidade do VMM 2008 é a possibilidade de gerenciar os hipervisores Hyper-V e ESX. O gerenciamento dos hosts do Hyper-V é feito por meio do Gerenciamento Remoto do Windows (WinRM) e pela interface da Instrumentação de Gerenciamento do Windows (WMI). Na verdade, quando um host do Hyper-V potencial é adicionado, caso a função do Hyper-V não esteja habilitada no Windows Server 2008, o VMM pode habilitá-la automaticamente para o administrador. Esse recurso também está disponível a hosts do Virtual Server potenciais para sistemas Windows Server 2003.
O gerenciamento dos hosts VMware VI3 ESX é, na verdade, feito por meio de um servidor VMware VirtualCenter. O VMM 2008 apresenta interface com o VirtualCenter por meio da API de Web Services do VirtualCenter. Por isso, um servidor VirtualCenter é obrigatório para o gerenciamento do VMware, e a maioria das instalações corporativas do VMware terá pelo menos um servidor VirtualCenter. A exclusividade do VMM 2008 é a possibilidade de gerenciar vários servidores VirtualCenter. O VMM pode adicionar vários servidores VirtualCenter, o que permite a um administrador agregar toda a infra-estrutura do Vmware e fornecer uma exibição corporativa única que não era possível até então.
Por ser parte da família de produtos System Center, o VMM usa a interface do System Center ou no estilo do Outlook no Administrator Console. O VMM Administrator Console não é um snap-in do MMC; trata-se de um aplicativo totalmente novo, desenvolvido usando o Microsoft .NET Framework e incorporado ao Windows PowerShell 1.0. Na verdade, como observado anteriormente, qualquer ação realizada no Administrator Console chama o comando do Windows PowerShell associado, logo, a interface do usuário usa, na realidade, o Windows PowerShell. Qualquer comando ou função executada no Administrator Console pode ser executado na linha de comando do Windows PowerShell.
Cada assistente do Administrator Console também conta com um botão Exibir Script que pode mostrar o script do Windows PowerShell associado do comando prestes a ser executado – um grande começo para saber como o Windows PowerShell se relaciona com o VMM. Nova no VMM 2008, a ação Exibir Script agora abre esses scripts no Bloco de Notas, logo, é possível editá-los facilmente no VMM. Também é possível salvar facilmente os scripts editados, que podem ser reutilizados na biblioteca do VMM – outro recurso novo do VMM 2008. Os cmdlets do VMM 2007 foram atualizados para o VMM 2008, inclusive o suporte a servidores do VMware. Como os mesmos cmdlets funcionam em todas as plataformas de virtualização, cmdlets como New-VM funcionam em sistemas Microsoft e VMware. Assim, os administradores de TI usam um dos cmdlets para gerenciar os hosts do Virtual Server, do Hyper-V e do VMware ESX.
O Virtual Machine Manager 2008 foi desenvolvido para fornecer três benefícios importantes aos administradores de TI:
  • Maximizar recursos
  • Obter maior agilidade
  • Aproveitar habilidades existentes
Vários recursos e funções favorecem esses benefícios. Primeiramente, o VMM ajuda a maximizar os recursos integrando o gerenciamento de toda a infra-estrutura virtual, independentemente do hipervisor. Integrando os sistemas Microsoft e VMware, o VMM 2008 fornece uma única exibição de todos os hosts e máquinas virtuais, como mostrado na Figura 2, além de permitir aos administradores filtrar e exibir os sistemas por parâmetros como, por exemplo, host, sistema operacional, proprietário, data da adição etc.
Figura 2 O VMM Console mostra gerenciamento de Microsoft e VMware integrado ( Clique na imagem para ampliá-la)
O VMM também ajuda a maximizar os recursos do sistema por meio de uma consolidação de servidor simples com conversões como, por exemplo, P2V e V2V. P2V permite consolidar as máquinas físicas existentes em máquinas virtuais sem que seja necessário reinstalá-las. Isso é especialmente útil durante a conversão de máquinas com pouca utilização de hardware, pois é possível maximizar os recursos reunindo várias máquinas pouco utilizadas em uma única parte de hardware físico. P2V é um recurso integrado do VMM e não exige software ou servidores adicionais. No VMM 2008, foi adicionado o suporte a um número maior de sistemas físicos, inclusive Windows Vista, Windows Server 2008 e hosts x64. A funcionalidade P2V do VMM é um ótimo complemento para ferramentas de planejamento como, por exemplo, a ferramenta Microsoft Assessment and Planning (MAP) (abordada no artigo de Baldwin Ng e Jay Sauls nesta edição da TechNet Magazine), que ajuda a identificar candidatos à consolidação do servidor.
Caso você já tenha máquinas virtuais no formato VMDK do VMware, o VMM permite usar V2V para converter os VMDKs existentes no formato VHD. Trata-se de um processo offline – a VM VMware deve ser desligada enquanto o processo V2V converte o arquivo VMDK real em um VHD. Também é possível converter uma VM VMware em execução usando a função P2V. Isso pode ser um pouco confuso, mas é importante lembrar que máquinas virtuais são máquinas inicialmente, depois virtuais. Como todos os demais sistemas vêem as VMs como máquinas em execução, o mesmo acontecerá com a funcionalidade P2V do VMM, que permite converter uma VM em execução em qualquer software de virtualização em um VHD Microsoft.
O VMM dá mais agilidade aos administradores de TI por meio de vários recursos. Um dos principais recursos habilitados pelo VMM é a migração das VMs de um host para outro, o que pode ajudar a manter a alta disponibilidade e a otimização do servidor. Com hosts Hyper-V, o VMM 2008 oferece suporte a Quick Migration, que pode mover uma VM entre hosts Hyper-V com apenas alguns segundos de tempo de inatividade. Isso exige um cluster do Windows Server 2008 e um armazenamento compartilhado, mas o VMM ajuda a facilitar o gerenciamento e a configuração.
Com um host VMware ESX, o VMM 2008 também oferece suporte a VMware VMotion, o recurso VMware que migra VMs sem que haja tempo de inatividade perceptível ao usuário. Hosts VMware ESX compatíveis com VMotion são obrigatórios, como um cluster e um back-end SAN como Quick Migration. Posteriormente neste artigo, apresentarei um VMotion usando o VMM 2008.
Por fim, o VMM 2008 pode migrar uma VM Virtual Server 2005 existente para um host Hyper-V, realizando automaticamente todas as atualizações e conversões necessárias à migração.
Como parte de qualquer implantação VM (inclusive as migrações descritas acima) iniciada por meio de conversões ou novas implantações, o VMM usa um processo chamado Intelligent Placement para implantar as VMs nos hosts. Ele também usa o Intelligent Placement para consultar todos os hosts de máquina virtual gerenciados, recupera vários parâmetros da disponibilidade de recursos desses hosts e, em seguida, retorna uma lista ponderada dos hosts recomendados para implantação da VM. Como se pode ver na Figura 3, o Intelligent Placement oferece suporte a hosts Microsoft e VMware, além das configurações de armazenamento. O Intelligent Placement no VMM 2008 reconhece tanto a plataforma quanto a configuração. Por isso, ele só recomendará hosts que se adaptem à plataforma host correta; apenas hosts agrupados em caso de necessidade de alta disponibilidade e apenas hosts compatíveis com x64 para VMs x64.
Figura 3 Intelligent Placement analisa todos os hosts disponíveis (Clique na imagem para ampliá-la)

Integração ao System Center
Um dos principais recursos do VMM 2008 é a integração com o System Center Operations Manager 2007. Embora o VMM 2007 apresentasse uma certa integração com o Operations Manager, o VMM 2008 inclui um conector de produto para o Operations Manager que aumenta muito a funcionalidade da integração. Por meio da integração com o Operations Manager, o VMM fornece relatórios de gerenciador de operações consolidadas no console administrativo, bem como por meio de um recurso chamado Performance and Resource Optimization (PRO).
O PRO permite que o VMM 2008 crie alertas chamados PRO Tips e até mesmo recursos de ação automatizada com base em parâmetros de monitoramento no Operations Manager. A Figura 4 mostra algumas dicas PRO de exemplo. Quando o pacote de gerenciamento habilitado para PRO (pacote PRO) está sendo usado, o VMM 2008 pode realizar ações automatizadas como, por exemplo, migrações de VMs e criação de novas VMs com base em parâmetros de desempenho baseados em host, hipervisor, hardware e até mesmo desempenho.
Figura 4 As dicas PRO fornecem alertas e recursos para problemas na infra-estrutura virtual (Clique na imagem para ampliá-la)

Instalação do Virtual Machine Manager 2008
Para realizar a instalação de um System Center VMM 2008, existem vários pré-requisitos e alguns requisitos novos. Primeiro, o servidor VMM 2008 exige o Windows Server 2008 x64. O servidor não será instalado no Windows Server 2003 ou nas versões x86 do Windows Server 2008. O Admin Console e os demais componentes ainda podem ser instalados no Windows Server 2003 e no Windows XP ou Windows Vista (no caso do console), com os mesmos requisitos e procedimentos de instalação do VMM 2007.
Segundo, o VMM 2008 exige uma instalação em um domínio do Active Directory, tendo em vista o modelo de segurança. O VMM 2008 oferece suporte ao gerenciamento dos hosts da rede de perímetro (sem junção ao domínio), inclusive os sistemas que não estão no domínio P2V, novo no VMM 2008. Uma das vantagens de usar o Windows Server 2008 como plataforma de instalação é que muitos dos pré-requisitos do VMM (como, por exemplo, .NET Framework 3.0, WinRM e Windows PowerShell 1.0) já são internos. Por fim, o VMM 2008 exige o Kit de Instalação Automatizada do Windows (WAIK) 3.0, muito embora o instalador do VMM 2008 inclua os arquivos de instalação.
Embora recomende que, em um ambiente de produção, cada componente de VMM seja instalado em um servidor de produção em separado, abordarei uma instalação com um único servidor. O hardware recomendado para a instalação de um servidor VMM é um servidor baseado em x64 a 2,8 GHz ou superior com, pelo menos, 2 GB de RAM. Como essa é uma instalação de servidor único com um banco de dados SQL local, são necessários 7 GB de espaço no disco rígido. Observe que, se fosse usado um banco de dados remoto, seria necessário apenas 1 GB para a instalação do VMM propriamente dita. Mais 80 GB de espaço em disco são recomendáveis para a instalação da biblioteca local.
Conforme mencionado anteriormente, o VMM é executado em uma instalação do Windows Server 2008 x64. Entre outros requisitos de software estão .NET Framework 3.0, Windows PowerShell 1.0, WinRM e IIS 6.0 ou posterior para o portal de auto-atendimento. O Microsoft MSXML 6.0 Parser também é obrigatório, embora faça parte do .NET Framework 3.0.
Ao iniciar a instalação do VMM, você terá cinco opções: o Virtual Machine Manager Server, o Administrator Console, o Self-Service Portal e o Local Agent, bem como uma opção para configurar o pacote de gerenciamento Operations Manager. Como mencionei, instalarei todos os componentes em uma única máquina, começando pelo VMM Server. Assim que a instalação for iniciada, as primeiras telas verificarão os pré-requisitos do sistema.
Além dos requisitos mencionados anteriormente, a máquina deve estar em um domínio. A instalação do servidor VMM habilitará automaticamente as funções internas, o que elimina a necessidade de habilitá-las manualmente.
Uma vez iniciado o instalador, recomendo usar a opção do Windows Update para verificar se o VMM 2008 está atualizado. Em seguida, o instalador examinará as opções, principalmente as relacionadas à instalação do banco de dados SQL. Tendo em vista esse exemplo, usarei o SQL Server 2005 Express Edition.
Em seguida, o assistente solicita a você identificar o local da biblioteca centralizada. Ele pode ser um diretório local do servidor VMM (e será criado um compartilhamento para esse diretório) ou um compartilhamento de arquivos já existente. O local padrão é C:\ProgramData\Virtual Machine Manager Library Files.
As atribuições de porta são as próximas. Aqui configuro a porta da conexão do Administrator Console para o serviço do servidor VMM básico (8100, por padrão), a porta usada pelo WinRM para realizar as funções de gerenciamento (80, por padrão) e a porta usada pelo Serviço de transferência inteligente de plano de fundo (BITS) para migrar arquivos para os hosts de máquina virtual (443, por padrão). Depois de especificar essas informações, uma tela de resumo é apresentada e a instalação do servidor deve ser concluída.
Em seguida, instalarei o Administrator Console, que tem pré-requisitos de sistema semelhantes aos do servidor VMM. A única opção de configuração disponível diferente do diretório de instalação é confirmar as portas de comunicação a serem usadas para se conectar ao serviço do servidor VMM. Essa porta deve ser 8100, conforme configurada na instalação do servidor VMM.
Ao final da instalação, você tem as opções de criar um atalho de desktop para o Administrator Console e de abrir o console ao fechar a instalação. É uma boa idéia para selecionar ambas. Na primeira vez em que abrir o Administrator Console, você será solicitado a se conectar ao servidor. Com a instalação de servidor único, o localhost na porta 8100 está correto e basta pressionar Enter para iniciar o console.
Por fim, instalarei o portal de auto-atendimento. Os pré-requisitos para isso são IS 6.0 ou 7.0, .NET Framework 3.0 e Windows PowerShell 1.0. (O Windows PowerShell é necessário porque o portal de auto-atendimento é apenas outra interface dos serviços VMM básicos, que usam o Windows PowerShell.) Para o Windows Server 2008, você precisa habilitar a função do IIS antes de iniciar a instalação do VMM 2008. Ao fazer isso, verifique se os seguintes serviços de função do IIS estão habilitados:
  • Recursos HTTP comuns (Conteúdo Estático, Documento Padrão, Pesquisa no Diretório, Erros de HTTP)
  • Desenvolvimento de Aplicativo (ASP.NET, Extensibilidade do .NET, Extensões ISAPI, Filtros ISAPI)
  • Segurança (Filtragem de Solicitações)
  • Compatibilidade com Gerenciamento do IIS 6.0
Se esses serviços de função forem habilitados, a instalação passará na verificação de pré-requisito e a instalação continuará. Durante a instalação, as opções de configuração lidam apenas com as portas usadas pelo portal de auto-atendimento. A primeira, a porta de conexão com o serviço WMM básico, é 8100, a mesma do Administrator Console. A segunda é a porta na qual o portal será executado. A porta padrão é a 80, mas em muitas configurações, ela talvez já esteja sendo usada, e o instalador VMM avisará você se esse for o caso. Se necessário, altere a porta para outra que esteja aberta como, por exemplo, 8080. Em seguida, o instalador criará um site chamado Microsoft System Center Virtual Machine Manager 2008 Self-Service Portal Home. A configuração pode ser alterada no Server Manager.
Quando a instalação do IIS estiver concluída, basta abrir o site indo até localhost:8080 no Internet Explorer. Caso seja solicitada autenticação durante a abertura do site, isso acontece por conta das configurações de segurança do Internet Explorer. O portal de auto-atendimento deve ser executado no contexto de intranet no Internet Explorer; você talvez precise adicionar o servidor VMM à lista de sites de intranet no Internet Explorer. Depois que essas configurações forem concluídas, você estará pronto para criar e usar VMs habilitadas para o auto-atendimento no VMM 2008.

Adicionando hosts ESX VMware
Embora haja muitos recursos novos no VMM 2008, sem dúvida o mais aguardado é a adição do suporte ao gerenciamento de host ESX VMware. Com esse suporte, agora o VMM é capaz de gerenciar a infra-estrutura virtual da maioria dos departamentos de TI corporativos.
O processo de adição dos hosts ESX ao Virtual Machine Manager 2008 é bem simples. Como observei anteriormente, o VMM 2008 gerencia hosts VMware por meio de um servidor VirtualCenter cuja versão deve ser 2.0.1 ou 2.5. Para adicionar os servidores VMware ESX ao console de gerenciamento, basta adicionar o servidor VirtualCenter usando a ação Add VMware VirtualCenter Server localizada no canto superior direito do painel Actions.
Após a inicialização do assistente, digite o nome de computador do servidor VirtualCenter com a conta administrativa do servidor VirtualCenter. O VMM adicionará os hosts ESX, inclusive a estrutura do grupo de hosts existente do VirtualCenter, à interface do VMM. Essa tarefa talvez demore alguns minutos, mas é possível monitorar o progresso no menu Jobs do VMM.
Quando todos os servidores forem importados, você deve conseguir ver a mesma estrutura de servidor do host VMware ESX no VMM como a vê no VirtualCenter. Para adicionar outro servidor VirtualCenter, bastaria repetir o processo. Depois que a estrutura do host é adicionada ao VMM, é possível adicionar servidores que não sejam VMware à mesma estrutura do grupo. Obviamente, o servidores que não forem VMware não serão mostrados no VirtualCenter.
Muito embora o VMM 2008 use o VirtualCenter para gerenciar hosts ESX, ele precisa ser capaz de acessar diretamente os próprios hosts ESX para determinadas funções como, por exemplo, V2V, salvar estado e clonar VMs em hosts ESX. Por isso, após a adição do servidor VirtualCenter ao VMM, os hosts serão mostrados como OK (limitados). Para habilitar o gerenciamento completo, vá até a página Properties dos hosts ESX individuais no VMM e forneça as credenciais de host apropriadas para gerenciar diretamente os servidores.

Migração de VMotion
Sempre que o gerenciamento do VMware no Virtual Machine Manager 2008 é abordado, normalmente a pergunta feita é se o VMM pode executar as funções do VMotion e as demais do VirtualCenter. E como o VMM usa o VirtualCenter no gerenciamento do VMware, a resposta para essa dúvida é sim!
Funcionalmente, o VMM trata o VMotion como qualquer outra migração. Para iniciar VMotion, primeiro selecione a VM que deseja migrar e, em seguida, a opção de migração da máquina virtual no painel Actions no lado direito do VMM. Quando terminar, o VMM abre a janela do Intelligent Placement dessa VM e apresenta os hosts de destino potenciais, com um tipo de transferência Live, como mostra a Figura 5. O Intelligent Placement pode ajudar a selecionar os hosts de destino certos para as VMs. Observe que se trata do mesmo processo de execução de Quick Migration usando hosts Hyper-V.
Figura 5 VMotion usando Intelligent Placement (Clique na imagem para ampliá-la)
Selecione o host de destino da VM – nesse caso, trata-se do servidor chamado cqaesxi003.contoso.com e clique em Next. A janela de resumo final, mostrada na Figura 6, exibirá a ação solicitada.
Figura 6 Janela de resumo do VMotion (Clique na imagem para ampliá-la)
Conforme mencionado anteriormente, todos os assistentes no VMM contam com um botão Exibir Script que pode mostrar o script do Windows PowerShell de um trabalho no Bloco de Notas. Isso nos dá a oportunidade de ver como o Windows PowerShell no VMM 2008 funciona com o VMware. Eis o script desta ação:
$VM = Get-VM -VMMServer localhost -Name "MyVM" |
  where {$_.VMHost.Name -eq "cqaesxi003.contoso.com"}
$VMHost = Get-VMHost -VMMServer localhost |   where {$_.Name -eq "cqaesxi003.contoso.com"}
Move-VM -VM $VM -VMHost $VMHost –RunAsynchronously
Três comandos simples executam o VMotion no sistema. No meu exemplo, estou migrando o VM MyVM do servidor VMware cqaesxi003.contoso.com para o servidor cqaesxi001.contoso.com. O primeiro comando é identificar a máquina virtual a ser migrada por meio do VMotion. Como se pode ver, nessa linha de comando, atribuo o valor da máquina virtual à variável $VM:
$VM = Get-VM -VMMServer localhost -Name "MyVM" |
  where {$_.VMHost.Name -eq " cqaesxi003.contoso.com"}
O segundo comando é identificar o sistema host ESX de destino da VM. Nessa linha, atribuo a variável $VMHost ao host ESX cqaesxi003.contoso.com:
$VMHost = Get-VMHost -VMMServer localhost | where
  {$_.Name -eq " cqaesxi003.contoso.com"}
Por fim, uso o comando Move-VM para efetivamente migrar a VM. Eis a linha de comando completa e os parâmetros de Move-VM:
Move-VM [-VM] [<String VM>] -VMHost [<String Host>]
  [-JobGroup <Guid>] [-JobVariable <String>] [-Path
  <String>] [-PROTipID] [-RunAsynchronously]
  [-StartVMOnTarget <Boolean>] [-UseLAN <Boolean>]
  [<CommonParameters>]
Acompanhando a filosofia de gerenciamento heterogênea do Virtual Machine Manager, é possível ver que o comando não é específico do fornecedor ou do software. Para concluir VMotion, emita este comando:
Move-VM -VM $VM -VMHost $VMHost –RunAsynchronously
Isso informa ao VMM para executar Move-VM na VM em $VM, migrando para o sistema host em $VMHost e para executar o trabalho de maneira assíncrona. Após a inicialização do trabalho, todo o processo pode ser monitorado na janela Jobs do VMM. Mais uma vez, esse mesmo comando básico pode ser executado para Quick Migrations em clusters Hyper-V e até mesmo para hosts que não sejam clusters, usando uma transferência baseada em LAN.
Como se pode ver, o System Center Virtual Machine Manager 2008 estendeu os ótimos recursos e funções do Virtual Machine Manager 2007 com plataformas de gerenciamento e novos recursos. Examinando o processo de instalação e alguns dos recursos, espero ter mostrado como é simples o gerenciamento de vários hipervisores no VMM 2008.
O VMM 2008 foi projetado para ser o software de gerenciamento consolidado para virtualização, unificando sistemas físicos e virtuais da Microsoft e VMware. Com essa nova versão do Virtual Machine Manager, os administradores do VMware, do Microsoft Virtual Server 2005 e do novo Hyper-V podem todos usufruir uma ferramenta única, uma interface de script única e, o mais importante, um processo de gerenciamento único para a infra-estrutura virtual.

Edwin Yuen é o gerente técnico de produtos na divisão Windows Enterprise Management do System Center Virtual Machine Manager. Edwin ingressou na Microsoft com a aquisição em julho de 2006 da Softricity. Edwin também tem 13 anos de experiência em consultoria técnica em âmbito comercial e federal. Ele tem formação em engenharia elétrica pela Johns Hopkins University.


Virtualização
Introdução a Microsoft Application Virtualization
Anthony Kinney

Este artigo se baseia em uma versão de pré-lançamento da App-V. Todas as informações deste artigo estão sujeitas a alterações.
Visão geral:
  • Arquitetura da App-V
  • Gerenciando aplicativos virtuais
  • Usando o seqüenciador da App-V
  • Integrando a App-V ao Gerenciador de Configurações

Sumário
A arquitetura da App-V
Como funciona toda a infra-estrutura da App-V
Atualizando aplicativos virtuais
Seqüenciamento
Versão 4.5
A Microsoft Application Virtualization (ou App-V) é uma querida plataforma minha. A App-V era conhecida como SoftGrid, e cheguei à Microsoft por meio da aquisição da empresa que criou a SoftGrid, chamada Softricity. Estou muito entusiasmado por ter a oportunidade de escrever este artigo para a TechNet Magazine agora, porque muita coisa mudou desde a aquisição.
A melhor forma de abordar a App-V é primeiro falar sobre os desafios enfrentados por profissionais de TI em termos de gerenciamento corporativo. Atualmente, o desktop de negócios se pauta por aplicativos. Antes da instalação de um aplicativo, ele deve passar por um longo teste de regressão para garantir que seja capaz de coexistir com os demais aplicativos instalados no sistema sem que haja impacto na possibilidade de execução apropriada. Em seguida, o aplicativo deve passar por uma série de processos de implantação antes de chegar à produção. E como um aplicativo só está disponível, essencialmente, onde está instalado, os usuários estão vinculados a computadores específicos. Isso complica ainda mais projetos complexos, embora críticos como, por exemplo, migrações de sistema operacional e aplicativo, atualizações de segurança e planejamento de recuperação de desastre.
A App-V muda tudo isso. Em vez de ser uma série complexa de etapas demoradas que esgotam recursos, a administração de desktop se torna um processo mais simples, automatizado com a App-V. É possível implantar, corrigir, atualizar e encerrar aplicativos mais facilmente e com melhores resultados.
Com a App-V, um usuário pode se sentar em qualquer desktop e acessar seus aplicativos. Os aplicativos são oferecidos sob demanda, mas executados como se estivessem instalados localmente. Por isso, não há necessidade de instalar os componentes do aplicativo ou alterar o dispositivo host.
Esse uso da virtualização poderia alterar drasticamente a forma como os profissionais de TI gerenciam desktops. Por outro lado, deixar de alterar o dispositivo host e executar os aplicativos virtualizados apresenta inúmeras vantagens, inclusive:
  • menos conflitos de aplicativo
  • atualizações de aplicativo mais rápidas e fáceis
  • a possibilidade de executar várias versões do mesmo aplicativo lado a lado
  • Aplicativos flexíveis que acompanham usuários online e offline
  • Redução do teste de regressão entre aplicativos

A arquitetura da App-V
Agora observemos o que está acontecendo realmente nos bastidores da plataforma App-V. A plataforma consiste em poucos componentes principais: um seqüenciador, um banco de dados, clientes, um servidor de gerenciamento, um servidor de streaming e um console de gerenciamento (consulte a Figura 1).
Figura 1 Layout de um ambiente da App-V (Clique na imagem para ampliá-la)
No núcleo do sistema App-V está o cliente App-V. Existem dois tipos de cliente que podem ser usados: o cliente do Terminal Server e o cliente de desktop. Em ambos os casos, o cliente deve ser instalado em cada desktop e Terminal Server no qual você pretende implantar os aplicativos virtuais. O cliente ocupa, relativamente, pouco espaço em disco. Ele instala um driver e apresenta um componente de runtime do usuário visível mostrado como um indicador na bandeja.
O cliente obtém uma lista dos aplicativos virtuais do App-V Management Server e exibe os aplicativos virtuais disponíveis. Ele trata a inicialização desses aplicativos (quando iniciado pelo usuário) e o gerenciamento do cache do lado do cliente. O cliente também é responsável por gerenciar a criação do ambiente de runtime virtual e garantir que cada ambiente seja executado na bolha virtual própria. Esse ambiente virtual inclui vários componentes, inclusive um Registro virtual, um sistema de arquivos virtual e um gerenciador de serviços virtual.
Existem três opções de implantação de infra-estrutura disponíveis na App-V 4.5: infra-estrutura completa, infra-estrutura leve e modo autônomo. Quando você implanta uma infra-estrutura completa, o back-end inclui o App-V Management Server e o App-V Streaming Server (trata-se de um componente novo que abordarei brevemente). O App-V Management Server hospeda e oferece os aplicativos virtuais centralizados, bem como atualiza os aplicativos virtuais quando patches ou atualizações são aplicados.
Esse servidor de gerenciamento depende do SQL Server para hospedar o banco de dados da App-V, que contém a configuração e as definições de aplicativos virtuais. Você deve usar grupos do Active Directory como a ferramenta de gerenciamento centralizada para provisionar e controlar permissões para aplicativos virtuais.
Para gerenciar as definições e a configuração, a plataforma App-V fornece um Web service do Microsoft .NET Framework que pode ser carregado no mesmo servidor, desde que o IIS esteja instalado. Esse Web service funciona como um elo entre o App-V Management Console – um snap-in do Console de Gerenciamento Microsoft (MMC) – e o banco de dados da App-V. Os administradores podem usar o console para publicar e gerenciar aplicativos virtuais, atribuir grupos do Active Directory e controlar configurações do servidor, bem como executar relatórios de uso dos aplicativos virtualizados (consulte a Figura 2).
Figura 2 Console de gerenciamento (Clique na imagem para ampliá-la)
A infra-estrutura leve inclui o servidor de streaming da App-V, que habilita recursos de streaming como, por exemplo, atualização de pacote/ativo. Essa opção não exige o Active Directory ou o SQL Server; ela não tem nenhum serviço de configuração de desktop e não conta com recursos de licenciamento e medição. No entanto, a infra-estrutura leve não permite que recursos de streaming sejam adicionados ao System Center Configuration Manager (SCCM) e a outras soluções em implantação de software corporativo (ESD) de terceiros.
No modo autônomo, o seqüenciador da App-V pode criar um arquivo MSI que automatiza a adição do aplicativo virtual (consulte a Figura 3). O arquivo MSI contém metadados que permitem a qualquer sistema ESD reconhecê-lo e controlar o aplicativo virtualizado. Esse modo exige que o cliente acesse o modo autônomo, que só permite atualizações baseadas em MSI dos aplicativos virtuais, e o streaming não é permitido no modo autônomo. Esse modo dá às organizações a possibilidade de usar os recursos de isolamento da App-V.
Figura 3 Seqüenciador da App-V (Clique na imagem para ampliá-la)
Os arquivos MSI são muito flexíveis; eles podem ser executados de maneira totalmente autônoma com apenas um cliente App-V, não exigindo nenhum componente de servidor. Isso significa que eles podem ser implantados manualmente, com um disco ou por meio de ferramentas de implantação tradicionais.
Na App-V 4.5, HTTP e HTTPS agora são protocolos com suporte para streaming. Isso possibilita um melhor desempenho do streaming, com um protocolo adotado mais amplamente, em especial do streaming em ambientes de rede de longa distância (WAN) e na Internet.

Como funciona toda a infra-estrutura da App-V
Um usuário faz logon em um dispositivo que apresenta um dos clientes (serviços de terminal da App-V ou cliente de desktop) instalados, e o cliente envia uma solicitação para o servidor a fim de obter uma lista de aplicativos atribuídos ao usuário atual. O servidor se comunica com o Active Directory para determinar de quais grupos o usuário é membro e, em seguida, retorna a lista dos aplicativos para o cliente. O cliente começa a criar anúncios para os aplicativos virtuais atribuídos a esse usuário em especial.
Nesse processo de publicação, várias ações são realizadas:
  • os arquivos de configuração são copiados
  • os ícones da área de trabalho são criados
  • os links Enviar Para são criados
  • as pastas no menu Iniciar são criadas
  • os tipos de arquivo são configurados
Esse processo é muito rápido e, o que é mais importante, garante que o ambiente seja exatamente como o usuário espera, sem nenhuma alteração visual. Os aplicativos virtuais funcionam como se estivem instalados localmente, mas, é claro, não alteram a máquina host. Os ícones, em vez de apontar para executáveis que residam no diretório de arquivos de programa, apontam para o cliente da App-V, que depende de um arquivo de inicialização (um arquivo OSD) para a configuração.
É importante observar que esse processo tem um impacto mínimo sobre a rede porque, diferentemente das implantações de software tradicionais, nada é instalado. Isso tem benefícios enormes, especialmente em ambientes de usuário móveis, porque os aplicativos estão disponíveis para o usuário, mas nada é efetivamente oferecido até a inicialização de um aplicativo. Esse método de anúncio também é o que fornece os recursos de aplicativo sob demanda e móveis da App-V.
Quando o usuário inicia um aplicativo virtual, o cliente lê um arquivo de configuração OSD, armazenado na máquina local. Isso informa ao cliente qual protocolo usar durante a comunicação com o servidor de gerenciamento da App-V e em qual servidor o aplicativo reside.
O servidor apropriado responde ao cliente transmitindo o limite de inicialização inicial, normalmente entre 20 e 40 por cento de todo o aplicativo. Após a transmissão de todo o limite de inicialização (mais uma vez, apenas de 20 a 40 por cento do aplicativo), o aplicativo virtual está pronto para ser executado.
A transmissão é, de fato, um dos principais elementos da mudança de paradigma introduzida com a App-V. Ela pode enviar o suficiente de um aplicativo de forma que ele possa ser executado sem desperdiçar uma parte importante da largura de banda da rede. Todos os dados passados para o cliente residem em um arquivo de cache local no dispositivo e qualquer inicialização subseqüente do aplicativo acontece no cache local, o que elimina tráfego de rede adicional.
Após a conclusão da transmissão do aplicativo virtual, o cliente cria um ambiente isolado que impede o aplicativo de alterar a máquina local (em outras palavras, o aplicativo não apresenta superfície do cliente). No entanto, o cliente permite ao aplicativo virtual acessar o sistema de arquivos local ao salvar e editar arquivos, além de também permitir a interação do aplicativo com serviços locais (como, por exemplo, a impressão), desde que o usuário tenha os privilégios apropriados no sistema local. Mas qualquer alteração feita por um aplicativo virtual nos arquivos do sistema local e no Registro é redirecionada para o ambiente virtualizado para que o dispositivo host permaneça inalterado.
Quando o aplicativo está em execução, todos os recursos que não foram usados anteriormente são fornecidos conforme necessário e armazenados em cache tendo em vista o uso subseqüente. A vantagem disso é que apenas os componentes exigidos pelo usuário são carregados durante a primeira inicialização, e os recursos que não são necessários não consomem recursos de rede. (A nova versão fornece algumas melhorias no cache do lado do cliente que possibilitam um uso mais inteligente do cache e streaming em segundo plano.)
Considere o Microsoft Office Word, por exemplo. Praticamente todos os usuários usam verificador ortográfico (caramba, não poderia ter escrito este artigo sem ele!); por isso, ele faria parte da primeira inicialização. Mas e o recurso Ajuda do Word? Nem tantos usuários usam esse recurso e, por isso, ele não precisaria ser oferecido durante a primeira inicialização. Na verdade, ele seria enviado para um usuário na primeira vez em que fosse acessado.
Quando o usuário termina e fecha o aplicativo, o cliente desativa o ambiente virtual e armazena todas as configurações do usuário em um local específico do usuário para que o ambiente possa ser mantido e recriado durante a próxima inicialização. Qualquer porcentagem do aplicativo virtual transmitida permanece no cache local, sendo disponibilizada na próxima inicialização. E caso outro usuário faça logon no mesmo sistema host e inicie o mesmo aplicativo virtual, o novo usuário aproveita o aplicativo já armazenado no cache.
Para remover os anúncios de aplicativo virtual, basta remover o usuário do grupo do Active Directory. E para desinstalar completamente o aplicativo virtual de um desktop, basta limpar o cache. Como o aplicativo jamais foi, de fato, instalado localmente, não há avisos incômodos perguntando "Deseja remover este componente compartilhado?".
Observe que, mesmo que um aplicativo virtual seja armazenado em cache, isso não significa que todos os usuários tenham acesso a ele. Diferentemente dos aplicativos instalados localmente em que os usuários podem simplesmente pesquisar ou procurar executáveis para os quais não tenham direitos, não existem representações visuais ou físicas de que o aplicativo virtual exista, a menos que o usuário tenha recebido direitos explícitos por meio dos grupos do Active Directory.

Atualizando aplicativos virtuais
A atualização é feita usando o seqüenciador. Depois de ser revisado para incluir uma atualização, um aplicativo é colocado no servidor de gerenciamento da App-V ao lado da versão anterior. Em seguida, o servidor notifica o cliente, durante a próxima inicialização, que foi feita uma alteração. Caso a versão anterior ainda esteja sendo usada, o usuário continua tendo acesso a essa versão até que o aplicativo virtual seja fechado. Durante a próxima inicialização, as deltas que constituem a atualização são transmitidas para o cliente e carregadas no cache, o que resulta em uma versão atualizada do aplicativo.
Digamos que haja mil usuários executando o Word 2000. Como precisa atualizar o Word 2000 (word2K.sft) para o Word 2000 SP3, a administradora copia o arquivo word2K.sft para a estação de seqüenciamento e seleciona Open for Package Upgrade no seqüenciador. Selecionando Open for Package Upgrade, a administradora começa a trabalhar usando o estado do pacote mais recente. Em seguida, ela pode copiar DLLs, executar atualizações ou patches no aplicativo virtual a fim de atualizá-lo para Word 2000 SP3. Depois, a administradora salva esse pacote atualizado.
O seqüenciador atribui automaticamente um novo nome de arquivo, word2K_2.sft, para impedir nomes de arquivo duplicados e indicar a versão do seqüenciamento. Esse novo pacote é colocado no mesmo diretório do pacote anterior no servidor de gerenciamento da App-V de forma que o Word 2000 (word2K.sft) e o Word 2000 SP3 (word2K_2.sft) acabem residindo no mesmo diretório. Em seguida, a administradora usa o console de gerenciamento da App-V para vincular esses dois arquivos SFT.
No lado do cliente, os usuários que tenham uma sessão ativa do Word 2000 sem o SP3 aberto continuam funcionando normalmente. Os usuários que iniciarem uma nova sessão do aplicativo depois que a administradora terminar essa vinculação receberão uma mensagem de que foi detectada uma alteração. Em seguida, o cliente começa a transmitir apenas as alterações delta entre word2K.sft e word2K_2.sft, atualizando automaticamente o aplicativo para o Word 2000 SP3.
Por conta da natureza dinâmica dos aplicativos virtuais, a reversão também é bem fácil. Basta retornar ao console de gerenciamento da App-V e remover a versão recém-adicionada. Isso faz com que o cliente seja revertido para a versão anterior durante a reinicialização. Para garantir que não haja crossover dos dados do pacote, o cliente limpa automaticamente o cache e retransmite o arquivo STF apropriado. Trata-se de um compromisso justo quando você considera o que deve ser feito para reverter uma atualização de aplicativo instalada fisicamente usando ferramentas de implantação de software mais tradicionais.

Para obter os benefícios da App-V, você deve criar pacotes de aplicativos virtuais. É aí que entra em cena o seqüenciador da App-V. Todo conhecimento e experiência que você tem em script e criação de pacotes para ferramentas de implantação de software tradicionais facilitará a transição para o seqüenciamento. (Devo ressaltar aqui que o seqüenciamento poderia estar em todo um artigo.)
A maior parte das soluções em implantação de software depende de scripts que capturam a forma como um aplicativo se instala e, em seguida, duplica o processo em outras máquinas, eliminando a necessidade de visitar todas as máquinas para instalar ou atualizar aplicativos. Após a instalação do aplicativo, as ferramentas de implantação de software comuns deixam de lado o pacote. Em seguida, você deve instalar todas as dependências das quais o aplicativo pode depender, executar outros scripts ou executar etapas manuais para configurar o aplicativo de acordo com as necessidades.
A alteração fundamental na App-V é que o processo de seqüenciamento gera uma imagem de um aplicativo já instalado, completo com dependências e configurações. Ela pode ser "executada" pelo cliente da App-V sem alterar o dispositivo em que está sendo executada.
O seqüenciador gera vários arquivos, sendo o mais importante deles o STF, que contém todos os ativos do aplicativo, as dependências e as informações de configuração. Em alguns casos, ele pode conter vários aplicativos. Não é de surpreender que esse arquivo seja bem grande. Há algumas opções de compactação, mas um bom conhecimento do desempenho da rede e do dispositivo é essencial. O arquivo de ícone (.ico) criado pelo seqüenciador é usado para anunciar o aplicativo virtual de forma que ele funcione como se estivesse instalado localmente.
O arquivo OSD também é muito importante, e as opções são inúmeras. Por padrão, trata-se de um arquivo baseado em XML usado para informar ao cliente da App-V como iniciar o aplicativo virtual. O arquivo OSD também pode ser modificado para configurar e controlar como o aplicativo virtual é iniciado e executado. Sugiro que você leia o Sequencing Admin Guide e o documento Sequencing Best Practices para se familiarizar com as propriedades e os valores disponíveis no arquivo OSD.
Por fim, o novo arquivo manifest.xml contém informações de configuração baseadas em pacote e podem ser usadas para integração com soluções ESD de terceiros e implantações de MSI. O seqüenciador também pode gerar um arquivo MSI para o pacote de aplicativo virtual. Ele pode ser usado para carregar os aplicativos virtuais em clientes autônomos (sem servidor) e por meio de um sistema ESD.
O próprio seqüenciador é uma ferramenta baseada em assistente que orienta você, o gerenciador, em meio ao processo de instalação de um aplicativo e transformação em um aplicativo virtual (consulte a Figura 4). A primeira etapa permite configurar propriedades padrão para o pacote. Entre essas propriedades, armazenadas no arquivo OSD, estão o nome do pacote e os comentários. Algumas das configurações avançadas permitem especificar o servidor de transmissão, o diretório de conteúdo e a quais sistemas operacionais o pacote oferece suporte.
Figura 4 O assistente de seqüenciamento (Clique na imagem para ampliá-la)
A segunda etapa é instalar, configurar e testar o aplicativo. Durante a instalação, o seqüenciador captura todas as alterações feitas no sistema local, inclusive no sistema de arquivos, no Registro e no sistema. Também existem alguns utilitários nesse assistente que permitem, por exemplo, a integração com o Windows Update.
A próxima etapa é configurar as associações do tipo de arquivo e especificar onde os atalhos devem ser colocados. Entre locais padrão estão o menu Iniciar, a área de trabalho e a barra de início rápido, mas também é possível criar locais personalizados.
Em seguida, você precisa iniciar o aplicativo e configurar o limite da primeira inicialização. Trata-se da etapa em que a App-V determina a parte inicial do aplicativo que precisa ser apresentada ao cliente para permitir a inicialização do aplicativo.
Para configurar esse código inicial (conhecido normalmente como bloco de recurso 1, ou FB1), basta iniciar o aplicativo e usar os recursos mais comuns exigidos pelos clientes. Por exemplo, inicie o Word e, em seguida, o verificador ortográfico. Qualquer DLL, arquivo ou chave do Registro chamado pelo aplicativo durante essa fase é designado automaticamente como parte do FB1. Todos os arquivos, as configurações ou os componentes não usados a essa altura são adicionados ao FB2. Em seguida, quando o aplicativo for usado, o cliente receberá um mapa do arquivo STF que indica onde o FB1 começa e termina e onde estão os demais arquivos no FB2 para que o cliente possa recuperá-los quando exigidos pelo aplicativo.
A etapa final do processo de seqüenciamento é garantir que tudo esteja configurado corretamente. O seqüenciador exibe a caixa de diálogo mostrada na Figura 5, que representa o SFT e permite fazer todas as adições finais ou alterações no pacote.
Figura 5 Confirmando e ajustando um pacote final (Clique na imagem para ampliá-la)

Versão 4.5
Após dois anos de criação, a App-V 4.5 está pronta para ser lançada neste ano. Trata-se da primeira versão Microsoft do produto a ser lançada, e a promessa é de elevar a virtualização de aplicativo introduzindo várias melhorias importantes como, por exemplo, a interação do aplicativo virtual dinâmico, a escalabilidade estendida e o melhor alinhamento com os requisitos de internalização e segurança Microsoft.
A interação do aplicativo virtual dinâmico permite que aplicativos virtualizados interajam entre si. Essa interação é conhecida como Dynamic Suite Composition (DSC). A DSC não substitui a possibilidade de adicionar vários aplicativos ao mesmo pacote. Na verdade, ela oferece uma forma de integrar dependências, middleware e plug-ins compartilhados entre aplicativos virtuais.
Os administradores podem especificar quais aplicativos virtualizados podem interagir entre si. Por exemplo, vamos supor que você tenha cinco aplicativos Web que exijam a mesma versão Java. Na App-V 4.1, você teria que adicionar essa mesma versão Java a todos os cinco pacotes separados. E vamos supor que a versão Java precisasse de um patch. O administrador teria que corrigir os cinco pacotes diferentes. Usando a DSC, o Java pode ser empacotado uma vez e, em seguida, configurado como um pacote a ser usado por todos os cinco aplicativos Web. Dessa forma, o patch Java exigiria que o administrador corrigisse o pacote Java apenas uma vez.
O mesmo cenário se aplica a middleware e plug-ins. Pretendo blogar outros cenários de caso de uso na medida em que a Microsoft se aproximar do lançamento e finalizar todas as adições mais recentes.
Melhorias feitas na escalabilidade envolvem transmissão e infra-estrutura de back-end. Os componentes de back-end foram modificados para oferecer melhor suporte a cenários de clustering e failover, e a transmissão está mais amigável a WAN e LAN. As melhorias vêm de várias adições principais.
A primeira é o Streaming Server Component, que possibilita o streaming sem a necessidade de uma infra-estrutura de back-end do Active Directory do SQL Server. Você ainda tem os grandes benefícios de uma entrega sob demanda e da atualização centralizada de pacotes, mas sem os grandes requisitos de back-end. Isso será muito usado em cenários de filial e na integração com soluções em ESD de terceiros.
O cliente da App-V também recebeu algumas melhorias. Por exemplo, agora o cliente armazena todas as informações de uso localmente de forma que elas possam ser controladas, independentemente do sistema cliente estar dentro ou fora da rede. O cache do cliente também foi expandido e melhorado tendo em vista um melhor desempenho em cenários com espaço em disco limitado. Agora também existe suporte ao seqüenciamento de aplicativos que não estejam em inglês, executando a App-V em sistemas operacionais que não estejam em inglês e a localização em vários outros idiomas.

Integrando a App-V ao Gerenciador de Configurações
Várias melhorias e novos recursos da App-V 4.5 foram projetados para integrar a App-V ao SCCM 2007 R2. Como já abordei, a virtualização e o streaming oferecem alguns recursos para fornecer aplicativos que as ferramentas de implantação de software tradicionais não conseguem. Não estou querendo dizer que a App-V substituirá essas ferramentas, e sim que pode complementar e estendê-las.
Com essa integração, você tem toda a escalabilidade, os relatórios, o reconhecimento de dispositivo e os recursos WAN do SCCM com todos os recursos de streaming e isolamento da App-V. Eis algumas das áreas que aproveitam a integração dessas duas tecnologias:
Entrega do aplicativo A integração do SCCM R2 oferece suporte a todos os recursos de entrega sob demanda, aplicativos móveis, limites de inicialização inicial e implantação de aplicativos sem alterar PCs clientes.
Atualizações Os Pontos de Distribuição (DPs) do SCCM podem implantar apenas as alterações delta dos aplicativos virtuais quando os pacotes são atualizados. Isso introduz a possibilidade centralizada de reverter aplicativos virtualizados para versões anteriores com um único clique.
Gerenciamento A versão R2 introduziu um novo assistente de anúncio de aplicativo virtual que permite aos administradores implantar aplicativos virtualizados, bem como pacotes de software tradicionais e anúncios em um único console.
Empacotamento Não há necessidade de empacotar novamente os aplicativos ao integrar a App-V com o SCCM. A seqüência inicial de um aplicativo precisa ser feita usando a seqüência da App-V fora do SCCM, mas os administradores têm a possibilidade de atualizar os pacotes existentes usando o SCCM.
Licenciamento Os aplicativos virtuais podem ser controlados em termos de licenciamento e medição usando as ferramentas existentes no SCCM.
BITS O SCCM oferece um novo método para implantar aplicativos virtualizados no App-V usando o protocolo BITS, padrão do setor. Muito embora os DPs do SCCM possam transmitir, há casos em que o streaming não é o método ideal para implantar aplicativos virtualizados. Ao implantar usando SCCM, você tem duas opções. É possível usar o streaming padrão ou os recursos de Qualidade de Serviço (QoS) do BITS para implantação de maneira muito mais controlada. Isso também é útil em cenários nos quais você gostaria de pré-carregar o cache antes da inicialização do aplicativo virtual pelos usuários.
Implantações em máquina O SCCM fornece a possibilidade de implantar aplicativos virtualizados em máquinas específicas, bem como de continuar oferecendo suporte à abordagem de destino baseada no usuário da plataforma App-V. Isso pode ser benéfico quando você implanta aplicativos virtuais em laptops, quiosques e máquinas de laboratório. Isso também é útil para ajudar no controle de licença quando o software pode ser licenciado por dispositivo, e não por usuários nomeados.
Escalabilidade A necessidade de implantar duas ferramentas separadas com muita sobreposição é uma preocupação comum. Integrando a escalabilidade e os benefícios de WAN do SCCM aos de isolamento e streaming da APP-V, é possível usar o SCCM existente, que fornece uma única ferramenta para tratar o gerenciamento e a implantação sem que seja necessário adicionar mais complexidade.

Anthony Kinney é profissional de vendas técnico responsável pelo Microsoft Desktop Optimization Pack. Anthony ingressou na Microsoft em 2006 com a aquisição da Softricity. Ainda na Softricity, Anthony escreveu e projetou o primeiro programa de treinamento em SoftGrid (agora App-V). Entre em contato com ele pelo email Anthony.kinney@microsoft.com.


Virtualização
Obtendo alta disponibilidade para o Hyper-V
Steven Ekren
Visão geral:
  • Consolidando servidores com o uso do Hyper-V
  • Garantindo a alta disponibilidade das máquinas virtuais
  • Configurando um failover do Windows Server 2008

Sumário
Alta disponibilidade
Hosts e convidados
Disponibilidade dos convidados
Conferindo alta disponibilidade às VMs
Pré-requisitos
Guia passo a passo de HA
Considerações
A virtualização de servidores está pronta para causar um forte impacto nos departamentos corporativos de TI, e o Hyper-V com o Windows Server 2008 pode transformar isso em realidade. A consolidação dos servidores em menos máquinas físicas traz grandes vantagens no que se refere à economia de recursos e custos, mas é preciso levar em conta dois fatores essenciais durante o processo de planejamento. Os usuários têm expectativas cada vez maiores em relação à disponibilidade de software, o que inclui os aplicativos de LOB (linha de negócios) e ferramentas como as plataformas de mensagens e de colaboração. Além disso, problemas ou falhas nos servidores podem ter um impacto consideravelmente maior sobre as operações. O Windows Server 2008 e o Hyper-V fornecem soluções que podem ser implementadas para proporcionar HA (alta disponibilidade) às VMs (máquinas virtuais), e também às cargas de trabalho hospedadas nas VMs.

Alta disponibilidade
Disponibilidade significa que os usuários podem acessar um sistema para fazer seu trabalho. Com a alta disponibilidade, há uma expectativa considerável de que os usuários sempre poderão acessar o sistema, pois ele foi projetado e implementado de forma a garantir a continuidade operacional.
A alta disponibilidade para o Hyper-V é obtida com o uso do recurso de cluster de failover do Windows Server 2008. O tempo de inatividade, seja ele planejado ou não, exerce impacto sobre a alta disponibilidade, e o cluster de failover é capaz de aumentar muito a disponibilidade das máquinas virtuais nessas duas categorias.
As máquinas virtuais podem ser gerenciadas pelo cluster de failover, que, por sua vez, pode ser usado nas máquinas virtuais para monitorar e mover as cargas de trabalho hospedadas na VM. Descreverei em mais detalhes esses dois cenários de configuração, mas a maior parte deste artigo tratará do gerenciamento de máquinas virtuais. No entanto, antes de começar, convém consultar a barra lateral "Termos úteis do Hyper-V".

Hosts e convidados
Como há vários sistemas operacionais em execução em um sistema Hyper-V, pode ser uma tarefa desafiadora definir com clareza qual é a camada ou o sistema operacional em discussão. Eu uso o termo "convidado" para referir-me ao sistema operacional e ao ambiente em uma VM Hyper-V executados em uma partição filho. Utilizo o termo "host" para indicar a máquina física, que é gerenciada pelo sistema operacional na partição pai do Hyper-V.
A disponibilidade do host soluciona os problemas causados pelo cenário de "colocar todos os ovos em uma só cesta", que pode ser produzido pela consolidação de servidores. O cluster de failover do Windows Server 2008 pode ser configurado na partição pai (host) do Hyper-V, de forma que as partições filho (máquinas virtuais ou convidados) do Hyper-V possam ter sua integridade monitorada e ser movidas entre os nós do cluster. Essa configuração tem as seguintes vantagens essenciais:
  • Se a máquina física na qual o Hyper-V e a VM são executados precisar ser atualizada, alterada ou reinicializada, as VMs poderão ser movidas para outros nós do cluster. É possível mover de volta as VMs assim que a máquina física retornar ao serviço.
  • Se a máquina física na qual o Hyper-V e as VMs são executados falhar (por exemplo, devido a uma falha na placa-mãe) ou apresentar uma degradação significativa, os outros membros do cluster de failover do Windows assumirão a propriedade das VMs e as colocarão online automaticamente.
  • Se a VM falhar, poderá ser reiniciada no mesmo servidor Hyper-V ou movida para outro. Como essa situação é detectada pelo cluster de failover do Windows, ele adotará automaticamente as etapas de recuperação, com base nas configurações das propriedades de recursos da VM. O tempo de inatividade é minimizado devido à automação da detecção e da recuperação.
A Figura 1 representa o que pode ocorrer nesse tipo de situação. A princípio, VM2 reside no Host A. Depois, VM2 é movida para o Host B. Observe que o nó que possui o armazenamento SAN LUN 2 é transferido do Host A para o Host B durante a movimentação. Para garantir que a solução de alta disponibilidade atenda às suas necessidades de disponibilidade, avalie cuidadosamente onde as VMs serão colocadas. É preciso pensar tanto em capacidade quanto em desempenho.
Figura 1 Uma máquina virtual e a mudança de seu armazenamento para um novo host (clique na imagem para ampliá-la)
A capacidade dos nós deve ser suficiente para hospedar todas as VMs e para permitir que um número "X" de nós falhe ou seja retirado da participação ativa no cluster. "X" representa o número de nós cuja perda você deseja que o cluster seja capaz de tolerar, mantendo a capacidade de hospedar todas as VMs. Em sua decisão quanto à capacidade, você pode optar por ter alguns nós que não hospedem VMs regularmente, mantendo-os em reserva. Como alternativa, é possível distribuir as VMs por todos os nós, garantindo que cada nó tenha capacidade extra suficiente para assumir corretamente a propriedade das VMs e iniciá-las, caso um número "X" de nós apresente falha.
Por motivos relacionados ao desempenho cotidiano, talvez seja interessante distribuir as VMs por todos os nós do cluster. Se houver nós mantidos em reserva, sem hospedar nenhuma VM, os nós que hospedam as VMs terão mais recursos em uso, e isso poderá reduzir o desempenho das VMs e da partição de gerenciamento. Distribuir as VMs pelos nós reduz a carga de cada um e pode resultar em melhor desempenho para as VMs e as partições de gerenciamento. No entanto, pode tornar mais complexo o planejamento de capacidade. Softwares de gerenciamento como o System Center Virtual Machine Manager 2008 podem ajudá-lo, fornecendo cálculos de capacidade para falha de nós e posicionamento de VMs.

Disponibilidade dos convidados
A disponibilidade dos convidados se concentra em conferir alta disponibilidade a uma carga de trabalho executada em uma VM. As cargas de trabalho geralmente incluem servidores de arquivos e de impressão, IIS e aplicativos de LOB. A análise das necessidades e das soluções de alta disponibilidade para as cargas de trabalho em VMs é muito semelhante àquela realizada em servidores autônomos. A solução dependerá da carga de trabalho específica.
Algumas cargas de trabalho podem alcançar a alta disponibilidade por meio do Windows NLB (balanceamento de carga de rede), que permite que vários servidores façam parte de um pool com um nome de rede comum. Os clientes fazem uma solicitação de conexão usando esse nome de rede virtual, e a conexão é estabelecida com um dos nós no cluster NLB. Um cenário que tipicamente utiliza clusters NLB é a criação de farms da Web com IIS, sendo que cada sistema individual tem IIS com as mesmas páginas da Web e acesso aos mesmos dados. O NLB fornece o balanceamento de carga, e também a capacidade de remover a associação de servidores para manutenção ou em caso de problema com o servidor, proporcionando assim um nível de alta disponibilidade. Se uma VM Hyper-V estiver executando o Windows Server 2008 (ou uma versão anterior do Windows Server que inclua NLB), o convidado poderá ser membro de um cluster NLB com outros convidados no mesmo ou em outro(s) host(s) Hyper-V.
Os convidados que executam o Windows Server 2008 podem usar o recurso de cluster de failover do Windows para fornecer alta disponibilidade a suas cargas de trabalho. O uso do cluster de failover do Windows em um convidado (cluster de convidado) tem várias vantagens:
Monitoramento de integridade da carga de trabalho O cluster de failover do Windows tem um monitor de recursos que faz chamadas para a DLL de recursos associada ao cluster. Cada recurso conta com um monitoramento de integridade que testa o aplicativo ou o serviço gerenciado por ele para garantir que esteja funcionando corretamente. Essas verificações são normalmente chamadas de isAlive/looksAlive. Se apresentar falha em uma dessas chamadas, o recurso propriamente dito falhará. Dependendo da configuração de suas propriedades, talvez o recurso tente reiniciar o serviço ou o aplicativo, ou talvez seja movido para outro nó no cluster de failover do Windows.
Manutenção de máquinas virtuais Se a configuração da VM precisar ser alterada, ou então se o sistema operacional ou o software precisar ser atualizado ou alterado, a carga de trabalho poderá ser movida para outro nó do cluster, e a VM poderá ser desligada ou atualizada com uma interrupção mínima para os usuários finais.
Manutenção de máquinas host Se a máquina física que hospeda uma VM Hyper-V precisar de manutenção ou de atualizações de software, e os outros membros do cluster de failover do Windows estiverem localizados em outros hosts Hyper-V, a carga de trabalho na VM poderá ser movida para outro nó do cluster, e a VM poderá ser desligada para acomodar as alterações ou as reinicializações do servidor físico.
Falha de máquina virtual ou host Se houver falha do host Hyper-V físico ou da máquina virtual convidada, os outros nós do cluster de failover do Windows detectarão que o membro do cluster não está mais respondendo nem participando do cluster, e os nós restantes colocarão online os aplicativos ou os serviços que eram executados na VM com falha.

Termos úteis do Hyper-V
A seguir, você encontra uma lista de termos que ajudam a definir os componentes ou as funções de um sistema Hyper-V de alta disponibilidade (cluster de host).
Partição pai Todos os sistemas operacionais executados em um servidor de hipervisor têm recursos de hardware alocados que incluem RAM, CPU e outros componentes de sistema. No Hyper-V, a partição que gerencia a configuração dos recursos do hipervisor e do sistema geralmente é chamada de partição pai. Quando a função Hyper-V é configurada e o servidor, reinicializado, a instalação do Windows Server 2008 que constituía o sistema operacional nativo do sistema torna-se o sistema operacional da partição pai do servidor Hyper-V.
Partição filho Um ambiente isolado em um servidor Hyper-V, configurado para manter um sistema operacional convidado e fornecer recursos de hardware para esse sistema operacional.
Host Hyper-V O servidor físico que hospeda o Hyper-V e o sistema operacional executado na partição pai.
Máquina virtual Hyper-V As informações de configuração e os dados do Hyper-V usados para inicializar e executar uma partição filho do Hyper-V. Isso inclui as informações de configuração necessárias para criar a partição filho e os arquivos VHD ou os discos de passagem contendo seus dados.
Disco de passagem Um dispositivo de armazenamento exposto no Gerenciamento de Disco como um disco físico designado para uso exclusivo de um convidado Hyper-V. O convidado Hyper-V monta o disco e o utiliza como um dispositivo de armazenamento conectado localmente.
VHD (disco rígido virtual) Um arquivo ao qual se conecta uma partição filho Hyper-V, exposto ao sistema operacional como um dispositivo de armazenamento (disco). O arquivo .vhd se localiza em um dispositivo de armazenamento montado pela partição pai, e pode ser um dispositivo de armazenamento com conexão direta ou um armazenamento com o qual se faz conexão via SAN, NAS ou SMB.
Conferindo alta disponibilidade às VMs
É muito simples configurar uma máquina virtual para ter alta disponibilidade utilizando o Assistente de Função de HA, no Gerenciamento de Cluster de Failover. As máquinas virtuais Hyper-V têm vários componentes essenciais que precisam ser levados em conta no gerenciamento de alta disponibilidade. Vejamos alguns conceitos importantes e pré-requisitos gerais.
Nós de cluster de failover Cada servidor físico que faz parte de um cluster de failover é chamado de nó. Nos clusters de host, o serviço de cluster de failover é executado no Windows Server 2008, na partição pai do sistema Hyper-V. Isso permite que as VMs executadas em partições filho dos mesmos servidores físicos sejam configuradas como máquinas virtuais de alta disponibilidade. As máquinas virtuais configuradas para HA serão mostradas como recursos no console de Gerenciamento de Cluster de Failover.
Armazenamento de HA As máquinas virtuais de alta disponibilidade podem ser configuradas par usar VHDs (discos rígidos virtuais), discos de passagem e discos diferenciais. Para habilitar a movimentação de máquinas virtuais entre nós do cluster de failover, é preciso haver armazenamento (que apareça na forma de discos no Gerenciamento de Disco) acessível por qualquer nó que possa hospedar a VM e gerenciado pelo serviço de cluster de failover. Os discos de passagem devem ser adicionados ao cluster de failover como recursos de disco, e os arquivos VHD devem estar em discos adicionados ao cluster de failover como recursos de disco.
Recurso de máquina virtual É um tipo de recurso do cluster de failover que representa a máquina virtual. Quando o recurso de máquina virtual é colocado online, uma partição filho é criada pelo Hyper-V e o sistema operacional na máquina virtual é iniciado. A função offline do recurso de máquina virtual remove a VM do Hyper-V no nó onde ela era hospedada, e a partição filho é removida do host Hyper-V. Se a máquina virtual for desligada, interrompida ou colocada em estado salvo, esse recurso será colocado em estado offline.
Recurso de configuração de máquina virtual É um tipo de recurso do cluster de failover usado para gerenciar as informações de configuração de uma VM. Há um recurso de configuração de máquina virtual para cada máquina virtual. Uma propriedade desse recurso contém o caminho para o arquivo de configuração contendo todas as informações necessárias para adicionar a máquina virtual ao host Hyper-V. O acesso ao arquivo de configuração é necessário para que uma máquina virtual seja iniciada. Como a configuração é gerenciada por um recurso separado, a configuração do recurso de uma VM pode ser modificada, mesmo com a VM offline.
Grupo de serviços e aplicativos de máquina virtual Para que um serviço ou aplicativo tenha alta disponibilidade por meio do cluster de failover, é preciso que vários recursos estejam hospedados no mesmo nó do cluster de failover. Para garantir que esses recursos estejam sempre no mesmo nó e que interajam corretamente, eles são colocados em um grupo chamado pelo cluster de failover do Windows Server 2008 de "Serviços ou Aplicativos". O recurso de máquina virtual e o recurso de configuração de máquina virtual de uma VM estão sempre no mesmo grupo de Serviços ou Aplicativos. Também pode haver um ou mais recursos de disco físico (ou outro tipo de armazenamento) contendo VHDs, arquivos de configuração ou discos de passagem em um grupo de Serviços ou Aplicativos.
Dependências de recursos É importante garantir que o recurso de configuração de máquina virtual seja colocado online antes que o recurso de máquina virtual seja colocado online (iniciado), e que o recurso de configuração de máquina virtual seja colocado offline depois que o recurso de máquina virtual seja colocado offline (interrompido). Configurar as propriedades do recurso de máquina virtual de forma a torná-lo dependente do recurso de configuração de máquina virtual garante essa ordem online/offline. Se houver um recurso de armazenamento contendo o arquivo do recurso de configuração de máquina virtual ou o recurso de máquina virtual, será preciso tornar o recurso dependente desse(s) recurso(s) de armazenamento. Por exemplo, se a máquina virtual usar arquivos VHD no disco G: e no disco H:, o recurso de máquina virtual deverá ser dependente do recurso do arquivo de configuração, do recurso do disco G: e do recurso do disco H:.

Pré-requisitos
Eis aqui os três pré-requisitos para conferir alta disponibilidade às máquinas virtuais Hyper-V usando o recurso de cluster de failover do Windows Server 2008:
  1. O recurso de cluster de failover do Windows Server 2008 deve ser configurado para cada nó do cluster. Para obter mais informações sobre como configurar e gerenciar clusters de failover, consulte a barra lateral "Recursos do Hyper-V".
  2. A função Hyper-V precisa estar instalada. As atualizações do Hyper-V precisam estar instaladas, e a função, configurada para cada nó do cluster de failover (mais uma vez, consulte a barra lateral "Recursos do Hyper-V"). O Hyper-V tem um pacote de atualização que instala os componentes do servidor Hyper-V, e outro que instala o console de gerenciamento do Hyper-V. Quando a atualização dos componentes do servidor Hyper-V estiver instalada, a função poderá ser adicionada com o Gerenciador de Servidores ou o ServerManagerCMD.
  3. Você precisa ter armazenamento compartilhado disponível para as máquinas virtuais. O armazenamento pode ser gerenciado pelo cluster de failover como um tipo de recurso de disco físico interno, ou então você pode usar uma solução de terceiros para gerenciar o armazenamento compartilhado. É claro que a solução de terceiros precisa oferecer suporte aos clusters de failover do Windows Server 2008.

Guia passo a passo de HA
Agora, vejamos como uma solução de alta disponibilidade é configurada. O primeiro passo é configurar uma máquina virtual. Em um dos nós do cluster de failover com a função Hyper-V instalada, configure uma máquina virtual usando o Gerenciador Hyper-V (veja a Figura 2). Pode ser uma nova VM configurada manualmente, ou então uma VM preexistente importada. Os VHDs precisam estar localizados em um disco gerenciado pelo cluster de failover do Windows Server 2008 e que esteja online no nó onde a VM está sendo configurada.
Figura 2 Configurando uma máquina virtual (clique na imagem para ampliá-la)
Agora, coloque a máquina virtual no estado interrompido desligando-a, desativando-a ou salvando seu estado. Somente as máquinas virtuais no estado interrompido podem ser configuradas para gerenciamento pelo cluster de failover.
Abra o console do Gerenciamento de Cluster de Failover (mostrado na Figura 3) em qualquer servidor que esteja executando a função de cluster de failover do Windows Server 2008, ou então em um cliente Windows Vista executando as RSAT (Ferramentas de Administração de Servidor Remoto). Conecte-se ao cluster de failover escolhendo a ação Gerenciar um Cluster… e depois selecionando um nó ou o nome do cluster, ou então selecionando a opção para conectar-se ao cluster no nó em que o console é executado.
Figura 3 Uma máquina virtual no Gerenciamento de Cluster de Failover (clique na imagem para ampliá-la)
No console do Gerenciamento de Cluster de Failover, selecione a ação Configurar um Serviço ou Aplicativo... Isso abrirá o Assistente de Alta Disponibilidade, que o orientará na configuração de serviços, aplicativos ou máquinas virtuais a serem gerenciados pelo cluster de failover. Na página Selecionar Serviço ou Aplicativo do assistente, escolha Máquina Virtual e depois selecione Avançar.
A página Selecionar Máquina Virtual exibirá todas as máquinas virtuais configuradas em qualquer nó do cluster de failover. Selecione uma máquina virtual e depois, Avançar. A página de Confirmação do assistente exibirá possíveis avisos ou erros. Nesta etapa, a configuração da máquina virtual é verificada, para garantir que possa ser configurada como um recurso de HA e que os nós possam hospedá-la. Selecione Avançar para adicionar a máquina virtual ao cluster de failover como um recurso de alta disponibilidade.
A página de Resumo traz informações sobre os resultados da adição da máquina virtual como um recurso de alta disponibilidade, inclusive possíveis avisos. O botão Exibir Relatório… mostra os detalhes das tarefas realizadas para conferir alta disponibilidade à máquina virtual, além de possíveis avisos ou erros. Por fim, selecione Concluir para fechar o Assistente de Alta Disponibilidade.
Como mostra a janela na Figura 3, o console do Gerenciamento de Cluster de Failover lista um objeto com o nome padrão de Virtual Machine(x) no painel esquerdo, sob o nome do cluster e em Serviços ou Aplicativos. Escolha a máquina virtual nessa estrutura de árvore, e os recursos que fazem parte do grupo de Serviços ou Aplicativos serão mostrados no painel central do console. Se qualquer outra máquina virtual tivesse seus arquivos no mesmo armazenamento da VM escolhida, também seria adicionada ao grupo. Serão mostrados os recursos de máquina virtual e de configuração de máquina virtual referentes a cada máquina virtual colocada no grupo.
O painel de informações do grupo de Serviços ou Aplicativos exibe as informações de Status, Alertas, Proprietários Preferenciais e Proprietário Atual do grupo. O nó Proprietário é aquele onde a máquina virtual está configurada ou em execução no momento. Selecione a ação Mover Máquinas Virtuais para Outro Nó para fazer com que a máquina virtual seja colocada offline e depois volte a ficar online em outro nó. Em geral, é prática recomendada mover uma VM para cada nó que possa hospedá-la no cluster de failover para verificar se a movimentação tem êxito e se a VM é iniciada e executada.

Recursos do Hyper-V
  • Descrição da atualização para a versão de lançamento da tecnologia Hyper-V para Windows Server 2008
  • Guia passo a passo do Hyper-V: testando o Hyper-V e os clusters de failover
  • Apresentando o cluster de failover do Windows Server 2008 (Chuck Timon, TechNet Magazine, julho de 2008)
  • O host NLB não apresenta a convergência esperada nas máquinas virtuais Hyper-V do Windows Server 2008
  • Webcasts de cluster do Win2008
  • A política de suporte da Microsoft para os clusters de failover do Windows Server 2008
Considerações
Eis alguns pontos fundamentais que é preciso ter em mente ao configurar máquinas virtuais para alta disponibilidade:
Armazenamento Se as máquinas virtuais tiverem arquivos VHD no mesmo disco compartilhado, ainda que estejam localizados em diferentes volumes do mesmo disco, eles serão colocados no mesmo grupo de Serviços ou Aplicativos. Uma das vantagens do compartilhamento de disco é permitir melhor utilização do espaço de armazenamento compartilhado disponível.
No entanto, o aspecto negativo é que, sempre que uma máquina virtual for movida, seja devido à recuperação automática de um problema na máquina virtual ou por opção do administrador, todas as máquinas virtuais do grupo serão movidas.
Letras de unidade e GUIDs É possível criar volumes sem letras de unidade atribuídas. As máquinas virtuais podem usar esses volumes, e eles podem ser gerenciados pelo cluster de failover. Se um recurso de disco tem volumes que usam GUIDs em vez de letras de unidade, o GUID será mostrado no Gerenciamento de Cluster. Ao criar máquinas virtuais e especificar o caminho para os VHDs, é muito importante verificar se o GUID no caminho corresponde ao GUID mostrado no Gerenciamento de Cluster para o volume. Caso não corresponda, talvez a máquina virtual não seja iniciada corretamente (online) em outros nós do cluster de failover.
Há várias situações nas quais é possível que os GUIDs não correspondam. Se um volume foi colocado online em nós antes que eles fossem adicionados como um recurso de disco gerenciado pelo cluster de failover, talvez o volume tenha um GUID diferente em cada nó. Também é possível que um volume tenha vários GUIDs em um único nó. Quando um disco é adicionado a um cluster de failover como recurso de disco físico, os GUIDs do volume em uso no nó em que os discos estão online são anotados nas propriedades do recurso de disco.
Os GUIDs dos volumes serão adicionados a um nó quando o recurso de disco for colocado online. Isso garante que o GUID específico anotado pelo cluster de failover para o volume seja um caminho válido em qualquer nó que coloque o disco online. O nó pode ter outros GUIDs associados ao mesmo volume. Por isso, um usuário poderia encontrar um GUID válido para o volume naquele nó, mas que não fosse o mesmo GUID que tem o uso com o volume nos outros nós garantido pelo cluster de failover. O sintoma desse problema é que um recurso de máquina virtual, geralmente o de Configuração, falha ao ser colocado online e exibe uma mensagem de erro indicando que o caminho é inválido. O caminho na mensagem de erro mostra o GUID que não é aquele gerenciado pelo cluster para o volume.
Pontos de montagem Os volumes montados em uma pasta em outro volume, em vez de ter uma letra de unidade atribuída ou um GUID utilizado, são válidos para uso com o Hyper-V e os clusters de failover. Como o volume montado e o volume que hospeda o ponto de montagem precisam estar no mesmo nó do cluster de failover, você precisa ter todos os discos que fazem parte do ponto de montagem no mesmo grupo de Serviços ou Aplicativos do cluster de failover.
Se os volumes estiverem nos mesmos discos, isso logicamente não será um problema. Porém, certamente será um problema se os volumes estiverem em discos diferentes. Embora seja evidente, convém mencionar que o volume montado e o host do ponto de montagem precisam ser armazenamento compartilhado configurado para ser gerenciado pelo cluster de failover.
Discos diferenciais Todos os arquivos VHD que fazem parte de discos diferenciais precisam estar em armazenamento compartilhado no mesmo grupo de Serviços ou Aplicativos da VM que utiliza os discos diferenciais. Em sua configuração mais simples, um disco diferencial envolve dois VHDs. Um VHD é o pai e contém um conjunto de dados usados como base. O outro VHD é um filho associado ao pai.
Quando é usado pela primeira vez, o disco diferencial aparece apenas como pai. Se houver dados localizados no pai, serão lidos a partir desse VHD. Todas as gravações ocorrem no VHD filho. Se houver dados localizados no filho, uma leitura desses dados fará referência ao VHD filho.
Se, por algum motivo, uma VM for configurada de forma que o VHD filho esteja no armazenamento compartilhado, mas o VHD pai não esteja no armazenamento compartilhado no mesmo grupo, ou então esteja em um dispositivo de armazenamento com conexão direta, a VM falhará ao ser iniciada (online) se for movida para outro nó. O Assistente de Alta Disponibilidade verificará se isso está configurado corretamente na VM e emitirá uma mensagem de erro se detectar o problema, mas convém observar esse requisito se a configuração da VM for alterada.

Steven Ekren é gerente sênior de programa da equipe de cluster de failover e alta disponibilidade do Windows Server. Steven atuou por 12 anos no Suporte da Microsoft, onde auxiliou clientes corporativos a implementar e solucionar problemas em clusters de failover do Windows Server e em tecnologias de virtualização incluindo o Windows Hyper-V, o System Center Virtual Machine Manager, o Microsoft Virtual Server e o Microsoft Virtual PC.


Virtualização
Backup e recuperação de desastre para a virtualização de servidores
Adam Fazio
Visão geral:
  • Considerações sobre o planejamento da recuperação de desastre
  • Soluções de alta disponibilidade para a recuperação de desastre
  • Backup e restauração com o Windows Server Backup

Sumário
Planejamento da recuperação de desastre 101
Recuperação de desastre e virtualização
Conversão de físico para virtual
Instantâneos de máquinas virtuais
Fazendo backup do Hyper-V
Backup do Windows Server
Fazendo backup de VMs com o WSB
Considerações
Restaurando VMs com o WSB
Data Protection Manager
Backups com scripts
DiskShadow
Conclusão
À medida que a tecnologia de virtualização de servidores evolui e sua adoção no setor 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 (recuperação de desastre).
Por que a prontidão da DR é, de forma generalizada, um dos assuntos mais efervescentes no setor de TI? Estudos sugerem que as empresas perdem, em média, de US$ 80.000 a 90.000 por hora de inatividade, e que poucas empresas a sofrer uma perda de dados catastrófica alcançam uma sobrevida de longo prazo. Este artigo 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 planejamento 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 automação de DR minimizam ou eliminam a necessidade de um plano detalhado e bem testado. Embora seja válido afirmar que a automação pode reduzir o tempo de recuperação e diminuir a dependência da intervenção humana, façamos 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, você descobrirá que é praticamente impossível selecionar as tecnologias certas, sem primeiro conhecer todas as restrições e os objetivos gerados pelo processo de planejamento de DR. Está fora do escopo deste artigo definir um plano completo de DR. Pretendo, sim, enfatizar os elementos necessários para a escolha das tecnologias e implementações certas. Então, descreverei rapidamente alguns fatores tecnológicos essenciais em um plano de DR.
Definições e priorização de serviços O que exatamente define todo o serviço que você está tentando proteger e qual a sua importância para a organização? A Figura 1 mostra 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
Serviço | Componentes principais | Dependências | Uso comercial | SLA
Site público | Balanceador de carga de rede, três servidores Web, dois servidores de banco de dados | DNS, rede, firewall, diretório, armazenamento SAN (rede de área de armazenamento) | Compra de produtos e acompanhamento de pedidos; comércio eletrônico; portal de atendimento ao cliente; informações sobre a empresa | 99,99%
Sistema financeiro | Dois servidores de banco de dados, um servidor de aplicativos | DNS, rede | Registro da receita da empresa, conforme exigido por leis e normas | 99,99%
Sistema de email | Três servidores de email, um servidor Web | DNS, rede, firewall, diretório | Comunicações da empresa, atendimento ao cliente | 99,5%
Depois de definir os serviços, você pode 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, você descubra que precisa adotar 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 diretos. 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 atuam no suporte a um SLA, inclusive os tempos de processamento e resposta para o fornecimento dos serviços. Suponha que você 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 (objetivos 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 você combinar isso com um RPO de, digamos, 24 horas, poderá definir técnicas e agendamentos de backup com precisão.
Diretivas de retenção de dados As diretivas de retenção de dados de uma organização especificam exatamente 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 Você também deve levar em conta a natureza dos dados. Se dividir seus dados em categorias, 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 diretó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 você deseja fazer um planejamento, 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 você deseja se concentrar ao trabalhar no planejamento 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 você queira também definir limites de recuperação com base nos seus 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 afetado for de 8 horas para a restauração do serviço e 48 horas para a restauração dos dados, talvez você 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.
Uau! Todo esse trabalho e ainda nem falamos de tecnologia! Não se deve subestimar a importância do planejamento. 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 planejamento 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 atualidade é que algumas ou todas as metas de DR podem ser alcançadas com soluções de HA (alta disponibilidade). A idéia por trás disso é que, se você 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 você poderá recuperar-se praticamente em tempo real.
Isso é verdade. No entanto, lembrando 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 a você 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 planejamento cuidadoso da camada de armazenamento, pois esse é um fator fundamental para possibilitar a capacidade de recuperação. Por exemplo, um cluster Hyper-V de 2 nós com armazenamento compartilhado 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 compartilhado é 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 (clique na imagem para ampliá-la)
Há alguns desenvolvimentos muito interessantes na área de replicação e sincronização de dados, mas não são recursos fornecidos atualmente pela Microsoft. Vale a pena conhecer os parceiros apresentados na página de clustering multissite do Windows Server 2008 (microsoft.com/windowsserver2008/en/us/clustering-multisite.aspx). Outro recurso é o Windows Server Catalog (consulte windowsservercatalog.com), que lista fornecedores de armazenamento com tecnologias de replicação certificadas para o Windows Server 2008.
Como você 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 você precisa ter seus 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 exata 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 bare-metal 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 sobreutilizar 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 você pode copiar o código de um P2V de teste no seu ambiente e modificá-lo para futuro uso automatizado. A Figura 3 mostra um exemplo de código; você pode executar o assistente de P2V do SCVMM no seu ambiente para obter um script exclusivo e personalizável do Windows PowerShell.
Figura 3 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

Instantâneos de máquinas virtuais
Embora não seja tecnicamente um backup, um instantâneo de VM fornece um momento determinado ao qual você pode reverter o sistema, usando 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 instantâneo, desfazendo os danos (mais tarde, veremos os instantâneos do VSS, Serviço de Cópias de Sombra de Volume).

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 exatamente. Por tratar-se de computadores ativos 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 advento do 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 corretamente.
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 operacional 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 convidado; o backup será realizado com a VM em execução e os dados serão consistentes (veja a Figura 4).
Figura 4 Backup VSS (clique na imagem para ampliá-la)
No entanto, se o sistema operacional convidado não oferecer suporte aos Componentes de Integração ou ao VSS, o processo de backup exigirá que a máquina convidada seja colocada em estado salvo e que seja tirado um instantâneo VSS baseado em host dos arquivos de dados da VM, que poderá ser usado para a recuperação pontual. Os instantâneos VSS de estado salvo produzirão algum tempo de inatividade 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 convidado 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 levar 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 convidado, é possível optar por ter uma NIC física dedicada no host associada a uma rede virtual usada por todos os convidados.

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 convidado 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 você tiver VMs sem os Componentes de Integração instalados, o VSS não será usado. Nesse caso, você 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 inatividade, 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, usando o NTBackup ou o WSB, dependendo do sistema operacional da VM. Vejamos como usar o WSB em convidados compatíveis que têm os Componentes de Integração instalados.

Fazendo backup de VMs com o WSB
O Hyper-V não registra automaticamente seu gravador VSS para uso com o WSB. Você precisa adicionar manualmente a chave e o valor do Registro mostrados na Figura 5 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
Figura 5 Chave e valor para registrar o gravador VSS do Hyper-V
Caminho | Chave ou valor do Registro | Tipo
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\ {66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE} | Chave | n/d
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}\Application Identifier | Valor | REG_SZ (Hyper-V, por exemplo)
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
Veja como instalar o WSB. Clique em Iniciar | Gerenciador de Servidores. No painel esquerdo, clique em Recursos. Depois, clique em Adicionar Recursos no painel direito. Na página Selecionar Recursos, expanda Recursos de Backup do Windows Server e marque as caixas de seleçã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. Selecione 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, selecione Backup.
Considerações
  • Você precisa fazer backup de todos os volumes relacionados a uma VM. Isso inclui VHDs (discos rígidos virtuais), arquivos de configuração e instantâneos da VM.
  • Se estiver criando um Agendamento de Backup, você 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, você poderá armazenar o backup em um volume local não dedicado, em um dispositivo removível ou em um compartilhamento de rede.
  • Se os Componentes de Integração não estiverem instalados na VM da qual você estiver fazendo 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, você precisa restaurar volumes inteiros.
Para fazer isso, é preciso ir para Iniciar | Ferramentas Administrativas | Backup do Windows Server e, no painel Ações, selecionar 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, você pode selecionar o tipo de recuperação.
Neste ponto, é preciso tomar uma decisão. Se você precisa da VM inteira, inclusive de sua configuração, instantâneos e discos virtuais (por exemplo, no caso de uma falha completa do host), selecione Restaurar Aplicativo e depois Hyper-V, conforme mostrado na Figura 6. Nesse caso, você 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 6 Restaurando um backup do Hyper-V (clique na imagem para ampliá-la)
Se você precisar apenas do VHD, e os dados de configuração e os instantâneos da VM estiverem íntegros, poderá selecionar 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 mente ao fazer o backup da VM, salvando primeiro seu estado.
Se você sofreu uma perda total do sistema e dos dados e precisa recuperar o host Hyper-V propriamente dito, incluindo o sistema operacional 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
Fizemos uma análise das etapas e considerações sobre backup e restauração de hosts e convidados Hyper-V usando o WSB, um recurso confiável, gratuito e interno, mas que não é uma solução de proteção de dados de nível empresarial. Quando o WSB sai de cena, entra o DPM (Data Protection Manager) 2007 SP1. Com lançamento programado para o final de 2008, o DPM SP1 dará suporte ao Hyper-V e trará alguns recursos interessantes:
  • Um único console de gerenciamento para todos os hosts e convidados Hyper-V.
  • Proteção contínua de dados, tirando instantâneos baseados em VSS em intervalos de até 15 minutos e capturando somente os bits alterados no processo.
  • Reconhecimento de cluster Hyper-V, permitindo 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 convidados Hyper-V; backups VSS sem agente de convidados 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 você utiliza atualmente uma solução de backup de terceiros, fique atento às atualizações do aplicativo. A maioria dos fornecedores está se empenhando para lançar 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 registrar manualmente o gravador VSS do Hyper-V no Registro.
A Figura 7 mostra alguns comandos de WBAdmin. Para obter a documentação completa de WBAdmin, consulte go.microsoft.com/fwlink/?LinkId=124380. Como você pode ver, não há nada em WBAdmin para configurar a diretiva de backup propriamente dita, mas há um snap-in do Windows PowerShell para gerenciar essas configurações. Você pode fazer um teste para verificar se esse snap-in está registrado com o seguinte comando:
Get-PSSnapin -Registered
Figura 7 Comandos de WBAdmin
Comandos de WBAdmin | Descrição
ENABLE BACKUP | Habilita ou modifica um backup diário agendado.
DISABLE BACKUP | Desabilita backups diários agendados em execução.
START BACKUP | Executa um backup.
STOP JOB | Interrompe o backup ou a recuperação em execução no momento.
GET VERSIONS | Lista detalhes de backups recuperáveis a partir de um local específico.
GET ITEMS | Lista os itens contidos no backup.
START RECOVERY | Executa uma recuperação.
GET STATUS | Emite um relatório sobre o status da função em execução no momento.
GET DISKS | Lista os discos online no momento.
START SYSTEMSTATERECOVERY | Executa uma recuperação de estado do sistema.
START SYSTEMSTATEBACKUP | Executa um backup de estado do sistema.
DELETE SYSTEMSTATEBACKUP | Exclui um ou mais backups de estado do sistema.
E você pode usar o seguinte comando para carregar um snap-in chamado Windows.ServerBackup:
Add-PSSnapin windows.serverBackup
Quando ele estiver carregado, você 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 8 Os cmdlets do Backup do Windows Server
Cmdlet | Descrição
Add-WBBackupTarget | Adiciona um destino de backup à diretiva de backup.
Add-WBVolume | Adiciona um volume à diretiva de backup.
Get-WBBackupTarget | Obtém destinos de backup de uma diretiva.
Get-WBDisk | Obtém todos os discos.
Get-WBPolicy | Obtém a diretiva de backup atual.
Get-WBSchedule | Obtém o agendamento de backup na diretiva.
Get-WBSummary | Obtém o histórico e o resumo de backups.
Get-WBVolume | Obtém todos os volumes.
New-WBBackupTarget | Cria um novo destino de backup.
New-WBPolicy | Cria uma nova diretiva vazia.
Remove-WBBackupTarget | Remove um destino de backup da diretiva.
Remove-WBPolicy | Exclui a diretiva de backup.
Remove-WBVolume | Remove um volume da diretiva.
Set-WBPolicy | Salva o objeto WBPolicy para criar um backup agendado.
Set-WBSchedule | Define o agendamento da diretiva de backup.

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 seletivo do que seria possível usando o WSB. E é importante que você 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
Esse 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 transacional — 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 é atualmente um processo manual (a VM precisa ser recriada, os instantâneos não são preservados, e assim por diante). Embora isso tenha algumas desvantagens evidentes, os dados são protegidos.
Conclusão
A DR pode ser um processo árduo, que parece nunca terminar. Mas a virtualização de servidores traz novas possibilidades, devido às tecnologias e também ao ponto de entrada resultante de menor custo. A Microsoft fornece não apenas a virtualização, mas todo um ecossistema. Juntos, a plataforma de virtualização de servidores e a família System Center oferecem soluções mais abrangentes para os desafios de complexidade crescente enfrentados pelas organizações, o que inclui a DR.
Gostaria de agradecer a James O'Neill por sua contribuição para este artigo.

Adam Fazio atua nos Serviços de Consultoria Microsoft há mais de 2 anos e agora se dedica às práticas para o setor público dos EUA. Ele presta serviços no setor de TI há mais de dez anos, tendo trabalhado em diversos projetos de infra-estrutura e operações de data center para empresas emergentes de Internet na lista Fortune 100. Atualmente, é chefe de escalonamento técnico no Programa Global de Implantação Rápida de Virtualização da Microsoft.


Virtualização
Ferramentas essenciais para planejar a infra-estrutura virtual
Jay Sauls e Baldwin Ng
Visão geral:
  • Contendo custos
  • Inventariando computadores
  • Determinando a utilização da CPU, de E/S em disco e da rede

Sumário
Destaques da ferramenta
Descubra o que você possui
Determine as utilizações atuais
Recomendações sobre posicionamento do servidor
Configuração da máquina virtual
Restrições de posicionamento
Considerando suas opções
Requisitos
Conclusão
A virtualização não é uma tecnologia nova, mas agora está explodindo em várias novas áreas, muito além da virtualização de plataforma original desenvolvida pela IBM nos anos 60. A razão principal para esse rápido crescimento é o potencial que as tecnologias de virtualização possuem para ajudar a conter custos no data center e em operações de TI. Com os custos com energia crescendo e o apetite cada vez maior para mais serviços de TI por diferentes partes da sua organização, você pode estar lutando para acompanhar o crescimento do servidor enquanto controla os custos operacionais. A virtualização pode ajudar. E a Microsoft e outros fabricantes de software têm desenvolvido novas tecnologias, incluindo a virtualização de servidores, desktops e aplicativos, que tornará os recursos virtuais mais amplamente disponíveis.
Neste artigo, examinamos um conjunto de ferramentas que pode ajudá-lo com seus projetos de virtualização — o MAP (Microsoft Assessment and Planning) Toolkit, que é membro da família de Aceleradores de Solução da Microsoft. O que são Aceleradores de Solução? Simplificando, são ferramentas de automação e a orientação de que você precisa para quase todos os projetos de TI. Os Aceleradores de Solução são recursos autoritativos gratuitos que o ajudam, de modo proativo, a planejar, entregar e operar sua infra-estrutura de TI — de desktops a servidores, do físico ao virtual.
Projetados em colaboração com especialistas da indústria e testado em ambientes de clientes reais, os Aceleradores de Solução oferecem simplesmente o nível certo de orientação prescritiva e a automação para atingir um alto desempenho e criar uma infra-estrutura de TI entre os produtos — tudo sem ter que reinventar a roda. Esses recursos se concentram em preocupações principais de empresas de todos os tamanhos, como avaliação e planejamento de infra-estrutura, virtualização, comunicação e colaboração e segurança e conformidade.

Destaques da ferramenta
A recém-lançada MAP Toolkit 3.1 (consulte a Figura 1) é uma ferramenta de avaliação de infra-estrutura de rede projetada para ajudá-lo a rapidamente obter uma compreensão de linha de base de seus servidores e desktops, incluindo se eles estão prontos para atualização ou migração para tecnologias como Hyper-V, Microsoft Application Virtualization, Windows Server 2008, Windows Vista, Office 2007 e SQL Server.
Figura 1 Microsoft Assessment and Planning Toolkit 3.1 (clique na imagem para ampliá-la)
Como a Figura 2 mostra, o MAP gera automaticamente relatórios e propostas de avaliação de prontidão, poupando-o de muito trabalho que você, por outro lado, teria que fazer sozinho. O MAP Toolkit 3.1 suporta cenários de servidor e desktop, incluindo a avaliação de desktops para atualização ao Windows Vista e o planejamento para a distribuição do Microsoft Application Virtualization.
Figura 2 Exemplo de proposta de migração gerada automaticamente (clique na imagem para ampliá-la)
Para planejamento de virtualização de servidor, três recursos principais da ferramenta podem ajudá-lo a determinar quais de suas máquinas físicas são boas candidatas: inventário de servidor, coleta de métrica de desempenho e recomendações de posicionamento de virtualização. Vamos examinar um cenário que mostra como você pode usar esses recursos para criar uma imagem detalhada do seu ambiente atual e planejar para a transição à virtualização.

Descubra o que você possui
Várias empresas grandes possuem alguma forma de infra-estrutura de gerenciamento de servidor em vigor, como o System Center Operations Manager. Alguns ambientes são menos ativamente gerenciados. Se estiver trabalhando em um ambiente onde você realmente não tem certeza sobre quais servidores estão instalados ou o que eles estão executando, o recurso de inventário de servidor pode ajudá-lo rapidamente a pintar uma imagem clara. O inventário de servidor pode detectar máquinas no seu ambiente usando o Active Directory, a verificação de intervalo de endereço IP ou, simplesmente, importando uma lista de máquinas de um arquivo simples. Como mostra a Figura 3, você também pode usar vários métodos de detecção juntos (Active Directory e verificação de endereço IP, por exemplo) para encontrar máquinas que deveriam estar no Active Directory, mas não estão.
Figura 3 Escolhendo o método de detecção do computador (clique na imagem para ampliá-la)
À medida que as máquinas são detectadas, o MAP Toolkit 3.1 tenta se conectar a cada uma e recuperar mais de 50 classes de dados pelo WMI (instrumentação de gerenciamento do Windows). Vários tipos diferentes de relatórios podem ser gerados com base nesses dados. Para consolidação de servidor com virtualização, estamos mais interessados nos relatórios criados quando você seleciona serviços e funções específicas de migração para o Windows Server 2008.
Mesmo se você não estiver fazendo uma migração para o Windows Server 2008 nesse momento, os dois relatórios que esse cenário cria são valiosos para determinar o tipo de hardware no seu ambiente (incluindo tipo e velocidade do processado, tamanhos de disco e memória instalada), bem como que funções de software você atribuiu para cada servidor (servidores DNS, controladores de domínio e Serviços de Terminal).
Esses relatórios são fornecidos a você como pastas de trabalho do Microsoft Excel, então é fácil usar as ferramentas de classificação e filtragem no Excel para identificar exatamente que máquinas no seu ambiente seriam boas candidatas para virtualização.
Os relatórios de inventário de servidor fornecem dados sobre vários atributos que você pode considerar ao escolher servidores para virtualizar. Como exemplo, talvez você queira garantir que os computadores que está virtualizando estejam em execução em um sistema operacional suportado pela plataforma de virtualização Hyper-V. Na pasta de trabalho WS2008HardwareAssessment do Excel criada pelo processo de inventário de servidor, na guia Inventário de Servidor, você pode examinar as colunas Sistema Operacional Atual e Service Pack para encontrar qualquer sistema que precise ser atualizado.

Determine as utilizações atuais
A próxima etapa para encontrar os candidatos à virtualização é medir de quanto está sendo a utilização das máquinas físicas. O Assistente de Métrica de Desempenho no MAP Toolkit 3.1 (consulte a Figura 4) grava contadores de desempenho de uma lista de máquinas que você identificou como candidatas à virtualização. A utilização da CPU, de E/S em disco e da rede são todas capturadas para uma revisão posterior.
Figura 4 O Assistente de Métrica de Desempenho (clique na imagem para ampliá-la)
Essa parte da ferramenta foi projetada para observar máquinas por um período razoavelmente longo de tempo (até um mês), o que fornece um pouco de flexibilidade para escolher como usá-la. Se já possui uma boa idéia de quando ocorrem as utilizações mais altas no seu ambiente (por exemplo, você pode ter uma janela de processamento em lote semanal), você pode configurar o assistente para ser executado por apenas algumas horas bem aproximadamente naquele horário. No entanto, se não tiver certeza de quando suas utilizações mais altas ocorrem ou se gostaria de observar várias máquinas que possuem horários de uso de pico diferentes, você pode configurar o assistente para ser executado durante vários dias ou semanas para gravar dados dos seus computadores. Isso permite que a ferramenta identifique automaticamente as utilizações de pico de um conjunto maior de dados.
Usando as informações do seu inventário anterior, acesse os recursos de classificação e filtragem do Excel para criar uma lista de máquinas que gostaria de monitorar. O Assistente de Métrica de Desempenho aceitará essa lista como um arquivo simples, com um nome de máquina por linha. Copie a lista de nomes de máquina do Excel para um novo arquivo de texto em branco no Bloco de Notas e, em seguida, salve-o. Quando solicitado, importe esse arquivo para o assistente e defina a hora de término do período de coleta da métrica de desempenho. O assistente entrará no modo de coleta de dados e reunirá contadores de desempenho das máquinas especificadas a cada cinco minutos.
Quando o Assistente de Métrica de Desempenho for concluído, ele criará um relatório detalhado do Excel listando todas as máquinas observadas e toda a métrica de desempenho para diferentes categorias de utilização: CPU, disco físico, disco lógico e rede. Usando essas informações, você pode refinar ainda mais sua lista de candidatas a considerar para a virtualização.
Você pode ter como objetivo máquinas com utilização extremamente baixa e procurar consolidar várias delas como máquinas virtuais (VMs) em um único host ou você pode combinar essas informações com os dados de inventário para encontrar máquinas que possuem serviços de missão crítica que precisam de alta disponibilidade. A virtualização pode ser usada para fornecer recursos de recuperação de desastres aprimorados para ambientes de alta disponibilidade. Após sua análise ser feita, você pode continuar com a etapa final de gerar recomendações de posicionamento de máquina virtual.

Recomendações sobre posicionamento do servidor
O Assistente de Consolidação e Virtualização de Servidor permite que você especifique a configuração de uma máquina de host de virtualização hipotética em termos de CPU, rede, subsistema de disco e memória. Usando os dados de desempenho coletados pelo Assistente de Métrica de Desempenho, o Assistente de Consolidação e Virtualização de Servidor computa um bom mapeamento de convidadas de VM para hosts de VM, garantindo que cada host seja bem utilizado sem arriscar a utilização em excesso durante o uso de pico.
Quando o Assistente de Consolidação e Virtualização de Servidor é concluído, ele produz uma planilha detalhada do Excel com o mapeamento proposto de VMs convidadas a hosts físicos. Para cada VM e host, o relatório mostra a projeção de utilização de E/S em disco, de E/S em rede e de CPU. Como VMs convidadas são adicionadas a máquinas de host físicas durante o processo de adequação, novas máquinas de host são alocadas à medida que hosts anteriores atingem a capacidade. Para cada novo host, é exibida uma mensagem que indica por que um novo host precisava ser alocado.
Se vários dos seus hosts recebessem a mesma mensagem, você poderia considerar a reexecução do Assistente de Posicionamento com uma configuração de host diferente para tentar aumentar o número de convidados atribuídos a cada host. Por exemplo, se vários dos seus hosts exibem a mensagem de que atingiram o limite de memória, você poderia tentar reexecutar o assistente e especificar uma quantia maior de RAM para a configuração do host. Isso deve aumentar o número de convidados que podem ser atribuídos a cada host.

Configuração de máquina virtual
Cada página no Assistente de Consolidação e Virtualização de Servidor permite que você configure um componente principal da configuração do computador hipotética que será usada para modelar a capacidade do computador host de VM. Os modelos são fornecidos para Virtual Server 2005 R2 e Hyper-V, e será perguntado a você qual tecnologia de virtualização você deseja usar na primeira página do assistente (consulte a Figura 5).
Figura 5 Selecionando a tecnologia de virtualização a usar para recomendações de posicionamento (clique na imagem para ampliá-la)
Modelos para várias famílias de CPUs da AMD e Intel são fornecidos na página de configuração da CPU. Se um modelo para sua CPU exata não estiver disponível, escolha a correspondência mais próxima. Você pode configurar a contagem de processadores físicos, núcleos e hyperthreads por núcleo nessa página. Observe que se escolher Hyper-V como sua plataforma de virtualização, apenas CPUs de 64 bits estarão disponíveis para escolha (consulte a Figura 6).
Figura 6 Configuração de CPU de host (clique na imagem para ampliá-la)
A terceira página do assistente permite que você configure um subsistema de disco, em termos de número de unidades de disco e tecnologia RAID, para computar tanto o espaço em disco total disponível no host, como um valor para a taxa de transferência do subsistema de disco. O valor da taxa de transferência é fornecido automaticamente com base na tecnologia de interface e na velocidade escolhida de RPM (Monitor de Desempenho e Confiança) do disco.
No MAP Toolkit 3.1, o suporte direto para modelar soluções de disco SAN (rede de área de armazenamento) e NAS (armazenamento anexado à rede) não é fornecido. Para uma aproximação grosseira, escolha a tecnologia de disco SCSI e configure um nível RAID similar à sua configuração de SAN, com discos de velocidade semelhante. Essa aproximação deve ser próxima o suficiente para ajudá-lo a fazer seu planejamento inicial.

Restrições de posicionamento
À medida que computadores convidados virtualizados são mapeados a hosts físicos, seis fatores são levados em consideração para avaliar se um convidado se ajustará ou não à capacidade restante de um computador host:
  • Utilização da CPU
  • Utilização de E/S de rede
  • Utilização de E/S de subsistema de disco
  • Memória
  • Espaço em disco
  • Suporte a sistema operacional convidado na tecnologia de virtualização especificada
A utilização da CPU, da rede e do subsistema de disco são razoavelmente diretas. As utilizações medidas na candidata convidada à virtualização física são convertidas em uma utilização equivalente no computador host de virtualização, que é então adicionada à utilização existente do host. Se a utilização total resultante de todos os convidados atribuída a esse host para aquele recurso for menor do que o limite, o convidado é atribuído ao host. Caso contrário, o convidado não será colocado e outros convidados são experimentados, para ver se um pode se ajustar.
Como exemplo, suponha que você tenha coletado uma métrica de desempenho sobre um computador com uma CPU de Pentium 4 de 1,2 GHz que mostrou uma utilização da CPU de 32%. Se você configura um host de virtualização com uma CPU Intel Xeon série 5300 quad-core, a utilização de CPU original medida do possível computador convidado será extrapolada para uma utilização projetada equivalente no computador host. Essa nova utilização será menor do que o valor original medido devido à arquitetura de CPU mais recente, à velocidade de clock de CPU diferente e à adição de mais núcleos.
Por outro lado, se você configurou um computador host com uma CPU menos eficiente do que a do convidado, a utilização projetada será maior depois de extrapolada para o host. Em qualquer um dos casos, a nova utilização extrapolada da CPU será usada para calcular o uso geral do computador host à medida que os convidados são atribuídos a ela.
Vale a pena discutir rapidamente apenas como a utilização de memória e o espaço em disco são decididos. A quantia total de memória física instalada em cada possível convidado de virtualização é reservada na máquina host. Além disso, uma quantia pequena de memória (512 MB) é reservada para o host em si. Quando a memória no host for esgotada devido à atribuição de convidados mais a sobrecarga de host, mais nenhum convidado de virtualização será colocado nesse computador host.
O espaço em disco é tratado do mesmo modo: a quantia total de espaço em disco físico em cada possível convidado de virtualização é reservada na máquina host. Além disso, 50 GB de espaço em disco são reservados para uso pelo host de virtualização. Depois que o uso de disco total de todos os convidados atribuídos ao host, mais o espaço reservado para o host em si atingirem o tamanho especificado na configuração do host, nenhum outro convidado poderá ser atribuído.
Com base na plataforma de virtualização escolhida, serão feitas verificações para garantir que o sistema operacional em execução no computador convidado seja realmente suportado pela plataforma de virtualização. Por exemplo, sistemas operacionais de 64 bits não são suportados como convidados no Virtual Server 2005 R2, então eles não serão posicionados se você escolher essa como sua tecnologia de virtualização.

Considerando suas opções
Executando o Assistente de Consolidação e Virtualização de Servidor várias vezes, será fácil comparar os resultados de diferentes escolhas de hardware para a máquina virtual de virtualização. Cada vez que você executa o assistente, pode escolher diferentes opções de CPU, disco e memória para encontrar a solução que será a melhor para o seu ambiente.
Preste atenção na coluna Last Placement Failed Reason (Razão da Falha do Último Posicionamento) na guia Consolidation Recommendations (Recomendações de Consolidação) da pasta de trabalho do Excel de consolidação do servidor. Essas razões fornecerão a você pistas sobre por que mais máquinas convidadas não puderam ser posicionadas em um determinado host. Se vários hosts estiverem exibindo a mesma razão, como a de que a utilização de memória do convidado excede a memória disponível no host, aumentar a quantia de memória na configuração do host pode reduzir o número total de hosts necessários.

Requisitos
Uma das vantagens do MAP Toolkit 3.1 é que ele não requer a instalação de nenhum software nos computadores que estão sendo inventariados. Todas as operações são conduzidas remotamente. No entanto, existem alguns fatores que devem ser levados em conta para que tudo funcione adequadamente.
Para que o Assistente de Inventário e o Assistente de Métrica de Desempenho concluam seus trabalhos, algumas portas TCP devem ser abertas no computador de destino e devem estar acessíveis do computador onde o MAP Toolkit está instalado. O Guia de Introdução entra em detalhes sobre os requisitos; em resumo, as portas para autenticação, o DCOM e o WMI devem ser abertos nos computadores que estão sendo inventariados. Se existir algum firewall instalado na rede entre o computador que executa o MAP Toolkit 3.1 e os destinos de inventário, esses firewalls devem ser configurados para permitir que esse tráfego também seja transmitido.
O MAP Toolkit 3.1 é projetado para ambientes de inventário de até 100 mil computadores e para coletar métricas de desempenho de até 3 mil computadores de cada vez. Por padrão, essa ferramenta instalará uma instância privada de SQL Server 2005 Express Edition. Devido à limitação do tamanho do arquivo de banco de dados de 4 GB no SQL Server Express, essa configuração permite apenas que você faça o inventário de aproximadamente 20 mil computadores antes de atingir o limite de tamanho de arquivo imposto pelo SQL Server Express. Para trabalhar com mais computadores durante o inventário, existem alguns padrões que devem ser modificados.
Para trabalhar com ambientes maiores, você terá que usar uma versão completa do SQL Server, como o SQL Server 2005 Standard Edition. Antes de instalar o MAP Toolkit, instale uma nova instância do SQL Server 2005 e nomeie a instância como "MAPS". Em seguida, execute o instalador do MAP Toolkit como o faria normalmente no mesmo computador. O MAP Toolkit requer uma instância local do SQL Server e o instalador irá detectar automaticamente uma instância "MAPS" local do servidor do banco de dados e irá se instalar nela, em vez de instalar o SQL Server Express Edition.
Para ambientes ainda maiores, você pode utilizar o recurso de dimensionamento, que permite a vários computadores auxiliares com o MAP Toolkit instalado executarem um grande inventário cooperativamente e armazenar todos os dados coletados em um único banco de dados central. Essa configuração também requer o uso do SQL Server Standard Edition para evitar o limite de tamanho de arquivo de 4 GB.
Consulte o Guia de Introdução para obter detalhes sobre como instalar essa ferramenta nessa configuração e editar as seqüências de caracteres de conexão de banco de dados adequadamente para esse modo. O recurso de dimensionamento também pode ser usado para colocar o SQL Server em uma máquina que não seja a máquina em que o MAP Toolkit está instalado.

Conclusão
Os Aceleradores de Solução, como o Microsoft Assessment and Planning Toolkit, fazem o trabalho pesado para seus projetos de TI no seu lugar. O MAP Toolkit poupou a vários usuários centenas de horas de tempo de planejamento de TI para implantações de Hyper-V. Você está pronto para experimentar?
Se deseja experimentar, você pode baixar o Microsoft Assessment and Planning Toolkit gratuitamente em microsoft.com/map ou pode obter outros Aceleradores de Solução de Virtualização no site microsoft.com/vsa. Também o estimulamos a visitar o blog da equipe do MAP Toolkit em blogs.technet.com/mapblog para você descobrir mais dicas e vídeos de demonstração.

Jay Sauls é gerente de programas sênior no grupo de Aceleradores de Solução da Microsoft, onde trabalha no projeto e na implementação de ferramentas, como Windows Vista Hardware Assessment e Microsoft Assessment and Planning Toolkit. Anteriormente, Jay trabalhou em outras equipes de produto da Microsoft, incluindo Microsoft Commerce Server, Microsoft BizTalk e System Center Capacity Planner.

Baldwin Ng é gerente de produto sênior na equipe principal de engenharia dos Aceleradores de Solução da Microsoft. Seus projetos atuais incluem o Microsoft Assessment and Planning Toolkit e os Aceleradores de Solução da Microsoft. Baldwin tem mais de 16 anos de experiência em desenvolvimento e gerenciamento de produtos em TI, comércio eletrônico e serviços de Internet sem fio, trabalhando na Microsoft, Corbis e Alltel. Ele escreve freqüentemente no blog blogs.technet.com/MAPBLOG.


Do editor É um mundo virtual(izado)
Joshua Hoffman

A virtualização não é nada de novo. Talvez essa não seja a forma mais entusiástica de começar o editorial deste mês, mas é verdade. O conceito de virtualização — separar um sistema operacional dos recursos de hardware subjacentes — já existe desde 1967, com a introdução do sistema operacional CP/CMS da IBM. Mas, embora o conceito já esteja bem estabelecido, muita coisa mudou nos últimos 40 anos.
Em 2008, estamos prestes a alcançar o ápice da virtualização de computadores. Quando a necessidade de reduzir custos, simplificar o gerenciamento e estabelecer práticas de computação sustentáveis convergiu para processadores mais poderosos, com vários núcleos, e para uma nova tecnologia de hipervisores, chegou a hora de a virtualização assumir um papel de destaque. É esse o tema desta edição da TechNet Magazine. Aqui, você encontrará artigos analisando em detalhes a nova e interessante plataforma Hyper-V no Windows Server 2008, ferramentas para gerenciar um ambiente virtual, técnicas para implantar aplicativos virtuais e muito mais.
De um ponto de vista mais pessoal, eu gostaria de expressar, em nome de toda a equipe da TechNet Magazine, nossa gratidão aos editores colaboradores Greg Stemp e Jean Ross, da infame Equipe de Scripts da Microsoft. Talvez vocês fiquem chocados ao saber que a Equipe de Scripts da Microsoft não é, na verdade, formada por homenzinhos de jaleco com cabeças maiores do que o normal, perambulando pelos corredores da Microsoft com um tubo de ensaio em uma das mãos e um script na outra. Em vez disso, nos últimos três anos, Greg e Jean têm escrito a coluna Ei, Equipe de Scripts! da TechNet Magazine, obtendo um sucesso estrondoso. Ei, Equipe de Scripts!, além de tornar-se a coluna mais popular que publicamos, ganhou vários prêmios, e já perdemos a conta dos elogios e emails dos leitores que tem recebido.
É por esses e vários outros motivos (entre os quais o fato de gostarmos muito deles) que nós, da TechNet Magazine, temos a triste tarefa de dizer adeus a Greg e Jean este mês. Como costuma acontecer aos melhores profissionais, Greg e Jean vão em busca de melhores oportunidades. Mas, felizmente, eles continuarão a percorrer os corredores de Redmond, empregando seu talento em benefício dos clientes da Microsoft. Desejamos a eles muito boa sorte, e esperamos que suas palavras voltem a enriquecer nossas páginas algum dia.
Enquanto isso, Dean Tsaltas, um respeitável discípulo da Equipe de Scripts, concordou em assumir provisoriamente a coluna, enquanto buscamos a nova geração da Equipe de Scripts. Dean dará início à sua participação no mês que vem, desvendando os segredos da Instrumentação de Gerenciamento do Windows. Você não pode perder! — Joshua Hoffman

Meus agradecimentos aos seguintes especialistas técnicos da Microsoft: Karri Alexion-Tiernan, Carmen Asher, Scott Culp, Steve Ekren, Trina Gorman, Michael Michael, Mike Mitchell, Michael Murgolo, Rob Polly, Dan Reger, Jez Sadler, Bill Scheidel, Bryon Surace e Jim Truher.


Cartas Com a palavra, os leitores

Gerenciamento de banco de dados SQL
Parabéns pelo artigo “SQL Server: Principais dicas para uma manutenção eficiente do banco de dados", da edição de agosto de 2008 (disponível em technet.microsoft.com/magazine/cc671165). Finalmente, um artigo na seção de SQL direcionado a nós, "DBAs involuntários", que simplesmente precisam se certificar de que um aplicativo chamado SQL Server está em execução e seu backup está sendo feito.
E logo na página seguinte, vocês o acompanham pelo artigo "Administração do Windows: Avaliando o desempenho do seu servidor" (technet.microsoft.com/magazine/cc718984). Isso foi demais! Eu rasguei esses artigos da revista para guardar em um lugar seguro — algo que simplesmente não podemos fazer com revistas digitais. Irei consultar esses dois artigos freqüentemente. Continuem com o ótimo trabalho.
Ficamos felizes em saber que você gostou desses dois artigos. Sempre gostamos de ouvir que nosso conteúdo é útil. Mas, embora nunca iremos recusar um elogio caloroso, por favor, não pare por aí! Fique à vontade em nos escrever sobre qualquer outro tópico que você gostaria que fosse abordado em edições futuras. Estamos sempre esperando comentários de nossos leitores.
– Joshua Hoffman, Editor-chefe

ImageX e Windows PE
Obrigado pela coluna sobre implantar sistemas operacionais antigos com o ImageX e o Windows PE ("Inicialização dupla com o Windows XP e o Windows PE 2.0", de fevereiro de 2008, technet.microsoft.com/magazine/cc194422). Eu descobri o potencial dessas ferramentas ano passado e comecei a fazer experimentos com elas para substituir a ferramenta de imagens que minha empresa usa (Acronis Snap Deploy). Coloquei tudo em funcionamento exatamente como eu precisava para trabalhar aproximadamente seis meses atrás e ela é agora, na verdade, a única ferramenta de imagens que usamos.
Então, eu li o artigo e observei a dica sobre como adicionar a opção /n52 do bootsect.exe. Eu nunca havia ouvido falar dessa opção antes. A única coisa que fazemos antes de aplicar as imagens é limpar o disco rígido usando o DiskPart com o script incluído (commands.txt). Ainda não enfrentamos nenhum problema, mas isso poderia se apresentar como um problema no futuro?
No começo, esse comando era necessário. Mas fui informado por um membro da equipe, depois que esse artigo foi veiculado, de que ele não é mais necessário, uma vez que o código de inicialização _now_ possui uma lógica interna para tentar procurar o novo código do gerenciador de inicialização de estilo e, se não encontrado, ele tenta o NTLDR antes de falhar. Então, ele pode ser totalmente omitido sem problemas.
— Wes Miller, colunista, Os arquivos da área de trabalho

Ambiente de imagem de teste
Li a coluna "Os arquivos da área de trabalho" sobre como implementar imagens usando a ferramenta ImageX e como habilitar o recurso de multicast pelo WDS (Serviços de Implantação do Windows) ("Inicialização dupla com o Windows XP e o Windows PE 2.0"). Desejo montar um ambiente de teste e gostaria de saber exatamente que ferramentas são necessárias. Devo instalar o Windows Server 2008 para uma implementação multicast? E, além disso, para imagens espelhadas, é necessário utilizar o ImageX para a instalação do Deployment 4 ou o WAIK (Kit de Instalação Automatizada do Windows) e o WDS?
Para utilizar multicast usando o WDS, você precisa ter o Windows Server 2008 instalado. Os componentes de multicast não estão (e não estarão) disponíveis para o Windows Server 2003.
O Deployment 4 não é necessário para que se utilize multicast. Para usá-lo, você precisa obter o Windows Server 2008, bem como a versão lançada do WAIK para Windows Server 2008. Essa versão do WAIK é a primeira que contém as partes necessárias para multicast do Windows PE.
— Wes Miller

Multicast do WDS
Tentei usar o ImageX para clonar imagens para e de computadores. Logo enfrentei um problema: o ImageX não suporta transmissões multicast. Quero fazer o mesmo usando servidores WDS com transmissões multicast. É possível? Parece que o comando Wdsmcast pode cuidar disso. Como um cliente do WDS pode informar a um servidor do WDS que imagem baixar?
Realmente, o ImageX não pode sozinho lidar com o multicast. Você precisa usar o Wdsmcast (no WAIK do Windows Server 2008) para especificar a que transmissão conectar (após tê-las iniciado no servidor). O white paper "Utilizando o servidor de transporte" possui informações apropriadas sobre como conectar usando o Wdsmcast (technet.microsoft.com/library/cc725964). Leia a seção "Como conectar um servidor cliente a um namespace usando o Wdsmcast.exe".
— Wes Miller

Fale conosco Você tem algo a dizer? Envie um email para tnmag@microsoft.com ou visite o fórum do nosso blog em blogs.technet.com/tnmag.


Toolbox Novos produtos para profissionais de TI
Greg Steen

Todos os preços foram confirmados em 19 de agosto de 2008 e estão sujeitos à alteração. As opiniões expressas nesta coluna são exclusivas do autor e não necessariamente refletem as opiniões da Microsoft.

Leve seus aplicativos com você
PortableApps.com
PortableApps.com
Como profissional de TI, é provável que você já tenha se visto passando muito de uma máquina para outra. E quando isso acontece, também é bem possível que você já tenha se pegado querendo o conjunto padrão de aplicativos e documentos ao seu alcance. Uma forma interessante de atender a essas necessidades é começando por uma plataforma de inicialização como a fornecida pelo PortableApps.com. No site, você encontrará a plataforma gratuita e de código aberto PortableApps.com, bem como muitos aplicativos portáteis que podem ser executados apenas em uma unidade flash USB, cartão de memória, disco rígido portátil ou player de música digital.
Também existe um PortableApps.com Suite. Esse download prático inclui um pacote dos aplicativos portáteis disponíveis, além da plataforma base, tudo em um único instalador. Existem duas versões do pacote. O Suite Light inclui Mozilla Firefox, Thunderbird e Sunbird, além do antivírus ClamWin, Pidgin para o sistema de mensagens instantâneas, o leitor de PDFs Sumatra, o gerenciador de senhas KeePass, o processador de texto AbiWord, um player de áudio e alguns jogos simples. O Suite Standard inclui todos esses aplicativos, bem como o pacote OpenOffice.org, que contém Writer, Calc, Impress, Base e Draw.
Além disso, há muitos outros aplicativos de código aberto que foram "portabilizados" no site, inclusive FileZilla para FTP, PuTTY para telnet e SSH, WinSCP para SFTP e SCP, PNotes e Task Coach para listas rápidas, 7-Zip para arquivamento, um prompt de comando, Eraser para remoção de arquivos, InfraRecorder para gravação de CDs/DVDs, WinDirStat para visualização do conteúdo de um disco, winMd5Sum para verificação de arquivos e WinMerge para diferenças entre arquivos e diretórios. (Os leitores assíduos da minha coluna Toolbox devem perceber que abordei vários desses aplicativos em edições anteriores.)
Também existe uma comunidade de usuários muito ativa, que está trabalhando em versões portáveis de utilitários de rede como, por exemplo, WinPCap e Wireshark. (Essas duas ferramentas podem, de fato, ajudar em tarefas administrativas e de solução de problemas.) Até mesmo os fóruns se constituem em um local específico para sugerir aplicativos a serem portabilizados.
Esses aplicativos são autônomos no dispositivo de armazenamento usado. Caso gravem no Registro ou exijam um acesso "fora do disco", eles devem restaurar o estado anterior à execução de tudo durante a saída. Além disso, é possível executar os aplicativos sem a plataforma PortableApps.com – eles estão disponíveis encapsulados em instaladores próprios para fazerem exatamente isso. Mas, deixando isso de lado, é bem provável que você queira usar os recursos da plataforma mesmo assim, e o pacote é um ótimo local para iniciar um ambiente personalizado que possa ser levado consigo.
A plataforma PortableApps.com está definida para a execução automática. Por isso, ao inserir a unidade flash USB ou portátil na máquina host do Windows, você terá a opção de executar o aplicativo da plataforma. Uma vez iniciada a plataforma, um ícone é exibido na bandeja do sistema. Clicar nesse ícone abre um menu pop-up semelhante ao menu Iniciar do Windows. Esse iniciador de aplicativos fornece links rápidos para todos os aplicativos portáteis com links para pastas de documentos na unidade portátil, um indicador de quanto espaço há na unidade, um utilitário de backup para os documentos na unidade, uma ferramenta de pesquisa e um link para instalar novos aplicativos portáteis. É possível personalizar essa interface e escolher um dos mais de 30 idiomas de interface.
Depois de testar a plataforma por um certo tempo, você talvez se interesse pela maneira com que pode modificar um aplicativo a fim de portabilizá-lo. O site também conta com um fórum Portable App Development ativo para ajudá-lo. Levando todas as coisas em consideração, trata-se de um conjunto muito interessante de ferramentas em um pacote portátil.

Preço: gratuito.
PortableApps permite levar as ferramentas consigo

Solucionar problemas de sistemas remotos
TeamViewer
teamviewer.com
Quando se está solucionando problemas de aplicativos, apresentando demonstrações e tutoriais de produtos ou apenas tentando compreender a dúvida de um usuário, não há nada melhor do que consultar a máquina em questão. Mas, na maioria das vezes, isso simplesmente não é possível. A segunda melhor coisa é usar uma ferramenta que ajuda a "estar lá", sem estar lá de fato. O TeamViewer, da TeamViewer GmbH, faz exatamente isso.
Esse utilitário apresenta um processo de instalação simples, que permite se conectar rapidamente a uma máquina remota. Existem quatro modos básicos de operação para os quais o TeamViewer oferece suporte. Há Remote Support, que permite controlar a máquina remota de forma que seja possível solucionar problemas, auxiliar em operações e na manutenção e orientar o usuário em meio a uma atividade. Também há Presentation, que permite exibir a área de trabalho no sistema do usuário remoto de forma que seja possível demonstrar uma atividade ou fazer uma apresentação. Outro modo é File Transfer, que permite transferir arquivos entre as duas máquinas sem efetivamente compartilhar as áreas de trabalho. E, por fim, VPN, que permite criar uma rede virtual privada instantânea entre você e a máquina host (esse modo usa a opção de instalação do adaptador TeamViewer VPN).
Em termos de segurança, o aplicativo usa uma troca de chaves RSA e a codificação de sessão AES de 256 bits. A troca de chaves garante que nenhum "intermediário" (inclusive os servidores de roteamento TeamViewer) fareje o fluxo de dados. Além disso, quando você se conecta a uma sessão Supporter (o termo usado para aquele que hospeda a sessão), uma identificação da sessão e a senha são geradas, e o usuário remoto deve digitá-las para se conectar. Caso você queira se conectar a uma máquina em que não haja um humano na outra extremidade (para gerenciar servidores, por exemplo), o TeamViewer oferece a opção de ser instalado como um serviço do sistema de forma que seja possível transferir facilmente arquivos, usar recursos de controle remoto, criar uma VPN ou até mesmo reiniciar a máquina remota.
Outro recurso interessante, especialmente caso você pretenda usar o aplicativo em suporte ou apresentações, é o módulo TeamViewer QuickSupport (ou Customer). Trata-se de um executável relativamente pequeno que, para ser executado, não exige a instalação de nenhum software ou direitos de instalação na máquina remota. O usuário final tem apenas que clicar duas vezes no arquivo exe e digitar a identificação da sessão e a senha e, em seguida, é possível conectar prontamente a sessão à máquina.
O TeamViewer conta com algumas opções de configuração muito úteis. É possível otimizar o número de cores compartilhadas no monitor, remover o papel de parede remoto do monitor ou optar por manter o Aero Glass do Windows Vista habilitado. Além disso, você pode ajustar a configuração geral de qualidade/velocidade das sessões. Também é possível controlar se você deve permitir vários recursos, inclusive controle remoto, transferência de arquivos, conexões VPN, teclado remoto e entrada de mouse, alternância de controle entre os hosts local e remoto e exibição da tela remota.
É possível gravar sessões para fins de reprodução ou auditoria posteriores. E caso não queira passar pelos servidores do TeamViewer, talvez por conta da configuração de segurança, você pode optar pelo uso de conexões LAN para o roteamento do TeamViewer.
A edição Premium, que oferece suporte a instalações Supporter ilimitadas, também inclui uma edição Portable que pode ser colocada em um CD ou em uma unidade flash USB de forma que você possa carregar a ferramenta consigo. A edição Premium também inclui o TeamViewer Manager, que registra em log os detalhes da sessão e permite armazenar detalhes do parceiro, recursos esses úteis para controle, relatórios e fatura dos clientes. O TeamViewer também está disponível para Mac OS X, além de oferecer suporte ao acesso em várias plataformas de forma que seja possível continuar usando a máquina Windows durante a conexão com um Mac.

Preço: gratuito para uso não comercial. A edição Business começa a US$ 699 para a instalação com um Supporter. A edição Premium custa US$ 1.399 e permite instalações ilimitadas de Supporter.
Conecte-se a um sistema remoto usando TeamViewer

Resenha de livro
End-to-End Network Security: Defense-in-Depth
Atualmente, a segurança de rede incorpora várias camadas de tecnologias proativas para reduzir a exposição a incidentes e limitar o potencial de violações dentro e fora da infra-estrutura de rede. End-to-End Network Security: Defense-in-Depth (Cisco Press, 2007), de Omar Santos, pode ajudar a navegar nas complexidades cada vez maiores da defesa de rede.
Embora seja, por motivos óbvios, parcial em relação à Cisco, esse livro ainda assim fornece um bom volume de informações de segurança generalizadas, o que faz dele uma ótima referência para qualquer profissional de rede ou administrador de sistema interessado na segurança da infra-estrutura.
O livro começa com uma visão geral das tecnologias de segurança de rede, desde firewalls e VPNs até sistemas de detecção/prevenção de intrusões e gerenciamento de identidades. Em seguida, ele detalha uma metodologia de seis etapas para tratar incidentes de segurança: preparação, identificação (das ameaças de segurança), classificação (das ameaças de segurança), controle, reação e postmortem.
O livro prossegue abordando uma estrutura de segurança proativa que usa vários dispositivos e ferramentas, inclusive IDS/IPS, NAC, AAA, SNMP, Syslog e VLANs. Em seguida, ele passa à abordagem de defesa aprofundada da Cisco, abrangendo redes sem fio, telefonia IP, segurança do data center e segurança de IPv6, principalmente porque ela pertence às soluções da Cisco para essas áreas de segurança de rede. O livro termina com três estudos de caso que abordam soluções em segurança para pequenas, médias e grandes empresas do mundo real.

Preço: US$ 49,50 (para venda direta).

Investigar identificações de dispositivo
PCIDatabase.com
PCIDatabase.com
Sempre tenta atualizar um sistema e acaba com um ou dois dispositivos desconhecidos cujas descrições não informam nada além de "Dispositivo PCI", e você não tem idéia de como obter um driver ou imagina qual dispositivo seja sem retirar o revestimento da máquina e procurá-lo com uma lanterna? Ou talvez você tenha tentado descobrir o chipset subjacente de um dispositivo conhecido. Bem, um serviço gratuito que pode ajustar é PCIDatabase.com.
Esse banco de dados com o suporte do usuário permite procurar por fornecedores e nomes de dispositivo, além de identificações, para localizar mais informações. Basta abrir o Gerenciador de Dispositivos, clicar com o botão direito do mouse no dispositivo em questão e selecionar Propriedades, escolher a guia Detalhes e, em seguida, selecionar a propriedade de identificação do hardware. Aqui você verá um conjunto de cadeias de caracteres que contêm alguns valores hexadecimais antecedidos por "VEN_" (para fornecedor) e "DEV_" (para dispositivo).
O site fornece links para vários recursos úteis a fim de ajudar a descobrir se há algum driver disponível para o dispositivo procurado (e, obviamente, não se esqueça de verificar o site do fabricante).
Outro recurso interessante que é possível encontrar em PCIDatabase.com: se procurar um determinado fornecedor, você chegará a uma página que lista o endereço da sede, os números de telefone, os sites aplicáveis, os contatos, a identificação hexadecimal do fornecedor para dispositivos PCI e uma listagem de todos os dispositivos conhecidos pelo site. E como o site tem o suporte do usuário, ele também o incentiva a adicionar informações à combinação.

Preço: gratuito.
Obtenha informações do fornecedor e do dispositivo em PCIDatabase.com (Clique na imagem para ampliá-la)

Auditoria e inventário de ativos
CCS Network Inventory
crowcanyon.com
Ser capaz de descobrir o que as máquinas clientes têm instalado sem sair da mesa pode economizar muito tempo. E, sejamos sinceros: controlar esses ativos com o passar do tempo faz parte do trabalho. A Crow Canyon Systems pode ajudá-lo a fazer essas coisas com a solução CCS Network Inventory.
O aplicativo é uma ferramenta de inventário e auditoria sem agente que verifica a LAN em busca de estações de trabalho – obtendo informações de hardware, software, serviço e usuário. Como a CCS Network Inventory não usa um agente remoto, o contexto da execução precisa de RPC, do serviço Pesquisador de Computadores, do serviço Registro Remoto, do compartilhamento de arquivo e impressora e do acesso ao compartilhamento ADMIN$ das máquinas que você deseja inventariar (assim como a maioria dos demais produtos de inventário sem agente).
O aplicativo permite usar credenciais alternativas para as consultas, o que é útil quando o exame abrange vários domínios. Após a instalação do aplicativo, é possível verificar um intervalo de endereços IP, usar a descoberta de rede do Windows, importar uma lista de máquinas ou especificar manualmente uma lista de estações de trabalho do Windows a serem inventariadas.
Em termos do quê a CCS Network Inventory audita, ela coleta detalhes do software: quais são os aplicativos instalados, quais hotfixes foram aplicados, qual sistema operacional e service pack estão instalados na máquina e até mesmo quais fontes estão instaladas. Em termos de configuração da máquina, é possível ver quais são os serviços e os demais processos em execução, quais são as pastas compartilhadas, os mapeamentos de unidade, as variáveis de ambiente, as contas de usuário, as tarefas agendadas, os comandos de inicialização e quais são os protocolos de rede em execução. E quanto ao hardware, é possível ver os detalhes dos monitores conectados, impressoras, discos rígidos (tamanhos e partições), informações das unidades de CD e de DVD, processadores, memória etc. Além disso, você pode configurar exames personalizados de valores do Registro, contagens de arquivo (por exemplo, quem tem mais MP3s) e espaço livre nas unidades.
Todas essas informações são armazenadas no banco de dados personalizado do aplicativo, podendo ser usadas para criar relatórios. A CCS Network Inventory fornece alguns relatórios internos para visualizar e transportar os dados para fins de auditoria e relatório. Caso os relatórios internos e as informações de consulta não incluam exatamente aquilo de que você precisa, é possível usar a ferramenta SQL Query Builder interna, que permite escrever e executar uma consulta mais detalhada ou específica com base nos dados.
Com o passar do tempo, costuma ser uma boa idéia fazer instantâneos do ambiente de forma que seja possível ver as alterações. A CCS Network Inventory permite ver essas alterações comparando duas instâncias dos bancos de dados de informações. Por exemplo, é possível comparar o exame atual com um feito há um ano para ver quantas estações de trabalho passaram para o Windows Vista, quantas tiveram componentes de hardware atualizados no ano anterior ou quais usuários continuaram executando software sem suporte mesmo depois de você ter os avisado.
No momento da redação deste artigo, a CCS Network Inventory não oferece suporte completo ao Windows 2008 Server, embora ofereça a outros modelos do Windows até o Windows Vista.

Preço: a partir de US$ 235 para até 25 nós.
Gerencie ativos remotos usando a CCS Network Inventory

Escreva para a Toolbox Se você tiver uma ferramenta ou um utilitário favorito que queira apresentar aqui, escreva para o autor em tntools@microsoft.com.

Greg Steen é profissional de tecnologia, empresário e entusiasta. Ele está sempre em busca de novas ferramentas para facilitar as operações, o controle de qualidade e o desenvolvimento para os profissionais de TI.


P+R SQL Logs de transações grandes, quando usar Reparar e muito mais
Paul S. Randal

P Notei um comportamento estranho com backups que espero que você possa me explicar. Periodicamente, fazemos o backup de nosso banco de dados de produção de 62 GB para atualizar os dados usados por nossos desenvolvedores de aplicativos. Sempre excluímos a cópia antiga antes de restaurar a nova. A cópia restaurada é do mesmo tamanho do banco de dados de produção e os dados parecem os mesmos, mas o processo de restauração leva um tempo bem maior do que o processo de backup. O que está havendo? Por que se leva muito mais tempo para restaurar do que para fazer o backup?
R Realmente não há nada estranho acontecendo. Dependendo das suas circunstâncias, esse geralmente é um comportamento esperado. A diferença no tempo necessário para um backup em relação a uma restauração provém das etapas que cada processo deve executar.
Fazer o backup de um banco de dados compreende duas etapas. Basicamente, é simplesmente fazer E/Ss de leitura no banco de dados e E/Ss de gravação no dispositivo de backup:
Etapa 1 do backup Leia todos os dados alocados nos arquivos de dados e grave-os no dispositivo de backup.
Etapa 2 do backup Leia algum log de transação e grave-o nos dispositivos de backup.
A quantia exata do log de transação necessária pode variar muito, mas é realmente a quantia necessária para poder recuperar o banco de dados restaurado para um momento consistente. (Eu forneci uma explicação mais aprofundada sobre isso em uma postagem do blog, disponível em sqlskills.com/blogs/paul/2008/01/31/MoreOnHowMuchTransactionLogAFullBackupIncludes.aspx.)
Restaurar um banco de dados, por outro lado, pode abranger até quatro etapas. E o trabalho envolvido é mais complicado do que apenas ler e gravar E/Ss:
Etapa 1 da restauração Se os arquivos do banco de dados não existem, crie-os.
Etapa 2 da restauração Leia todos os dados e o log de transação do backup e grave-os nos arquivos relevantes do banco de dados.
Etapa 3 da restauração Execute a fase REDO de recuperação no log de transação.
Etapa 4 da restauração Execute a fase UNDO de recuperação no log de transação.
O tempo total decorrido para ambas as etapas do backup deve ser aproximadamente o mesmo que o tempo necessário para a Etapa 2 da restauração (supondo que ele possui hardware similar e um servidor sem atividade do usuário). A etapa 1 da restauração pode levar um tempo longo se os arquivos de dados forem grandes e precisarem ser inicializados com zero (que é o comportamento no SQL Server 2000 e o comportamento padrão no SQL Server 2005).
Para impedir isso, não exclua os arquivos existentes antes de iniciar a restauração. Ou, como alternativa, habilite a inicialização instantânea para que os arquivos sejam criados muito rapidamente (mais informações sobre isso podem ser encontradas em msdn.microsoft.com/library/ms175935.aspx).
As etapas 3 e 4 da restauração estão executando a recuperação no banco de dados restaurado para torná-la transacionalmente consistente; esse é o mesmo processo pelo qual um banco de dados passaria durante a recuperação contra panes. A duração de tempo que a recuperação levará depende da quantia de log de transação que precisa ser processada. Por exemplo, se houvesse uma transação ativa de muito longa duração no momento em que o backup foi feito, todo o log de transação para aquela transação estaria no backup e teria que ser revertido.

P Estou tentando escolher entre o envio de log e o espelhamento do banco de dados para fornecer uma cópia redundante do nosso banco de dados de produção. Estou preocupado com a quantia de logs de transação que precisará ser enviada entre os servidores, especialmente para as operações de recompilação de índice que fazemos todas as noites. Ouvi dizer que o espelhamento envia os verdadeiros comandos de recompilação em vez do log de transação e as recompilações são feitas no espelho. Isso é verdade? Isso deveria tornar o espelhamento uma solução melhor do que, até mesmo, o envio de log com o modelo de recuperação BULK_LOGGED, certo?
R O que você ouviu não é verdade. O espelhamento do banco de dados funciona pelo envio dos registros de log de transação reais do banco de dados principal ao servidor de espelhamento, onde eles são “reproduzidos novamente” no banco de dados de espelhamento. Não existe nenhuma conversão ou filtragem de tipo algum acontecendo, nem qualquer tipo de interceptação de comandos T-SQL para um banco de dados espelhado.
O espelhamento de banco de dados suporta apenas o modelo de recuperação FULL, o que significa que uma operação de recompilação de índice sempre será totalmente registrada. Dependendo do tamanho dos índices em questão, isso poderia significar uma quantia relevante de log de transação sendo gerado e, sucessivamente, um grande arquivo de log no banco de dados principal e uma largura de banda de rede considerável para envio dos registros de log ao espelho.
Você pode pensar no espelhamento do banco de dados como envio de log em tempo real (na verdade, esse era um nome usado para o recurso no início durante o desenvolvimento do SQL Server 2005). No envio de log, os backups do log de transação do banco de dados primário são enviados regularmente ao servidor secundário e são restaurados no banco de dados secundário.
O envio de log suporta os modelos de recuperação FULL e BULK_LOGGED. Para uma operação de recompilação de índice em um banco de dados com envio de log com o modelo de recuperação FULL, a mesma quantia de log de transação será gerada como a quantia gerada para um banco de dados espelhado. No entanto, no cenário de banco de dados com envio de log, os dados são enviados ao banco de dados redundante em um backup de log (ou uma série de backups de log), em vez de como um fluxo contínuo.
Se o modelo de recuperação BULK_LOGGED for usado no banco de dados com envio de log enquanto a recompilação de índice for feita, apenas uma quantia mínima de log de transação será gerada. No entanto, o próximo backup de log de transação também irá conter todas as extensões de arquivos de dados que foram alteradas pela operação de recompilação de índice minimamente registrada. Isso significa que os backups de log que abrangem a recompilação de índice no modelo de recuperação BULK_LOGGED serão quase que exatamente do mesmo tamanho daqueles que abrangem a recompilação de índice no modelo de recuperação FULL.
Então, a quantia de informação que precisa ser enviada ao banco de dados redundante é quase exatamente a mesma que para uma recompilação de índice em um banco de dados espelhado e em um banco de dados com envio de log. A diferença real é de como as informações são enviadas — continuamente ou em lotes.
Existem vários outros fatores a considerar ao escolher entre essas duas abordagens (muitos fatores para se discutir em apenas uma edição do P+R SQL). Você deveria ver como todos esses fatores se correspondem aos seus requisitos (como limite de perda de dados aceitável e tempo de inatividade permitido) antes de tomar uma decisão.

P Estou executando o SQL Server 2005 e um dos meus bancos de dados possui um log de transação que simplesmente continua aumentando. O banco de dados está no modo de recuperação completo e estou fazendo backups de log de transação. Eu tinha a impressão de que isso deveria impedir o log de transação de aumentar. O que exatamente está dando errado aqui?
R Você tem razão em achar que fazer backups de log de transação no modo de recuperação completo é importante. No entanto, existem outros fatores que podem contribuir com o aumento do log de transação. Tudo se resume ao que está exigindo que o log de transação seja necessário (ou ativo). Outros fatores comuns (com exceção de uma falta de backups de log de transação) que podem causar seu problema incluem a replicação, o espelhamento do banco de dados e uma transação ativa.
A replicação funciona pela leitura assíncrona dos seus registros de log de transação e, em seguida, pelo carregamento das transações a replicar em um banco de dados de distribuição separado. Qualquer registro de log de transação que ainda não tenha sido lido pela tarefa do leitor de log de replicação não pode ser liberado. Se sua carga de trabalho gerar muitos registros de log de transação e você tiver definido um intervalo grande para a freqüência com a qual o leitor de log de replicação será executado, muitos registros poderão ser acumulados e fazer com que o log de transação aumente.
Se estiver executando o espelhamento de banco de dados assíncrono, pode haver uma lista de pendências de registros de log de transação não enviada do principal ao espelho (chamada de fila SEND do espelhamento do banco de dados). Os registros do log de transação não podem ser liberados até terem sido enviados com sucesso. Com uma alta taxa de geração de registro de log de transação e largura de banda limitada na rede (ou outros problemas de hardware), a lista de pendências pode aumentar muito e fazer com que o log de transação aumente.
Finalmente, se um usuário inicia uma transação explícita (como usar uma instrução BEGIN TRAN) e, em seguida, faz uma modificação de algum tipo (como uma instrução DDL ou uma ação de inserir/atualizar/excluir), os registros de log de transação gerados precisarão ser mantidos até que o usuário confirme ou reverta a transação. Isso significa que qualquer registro de log de transação subseqüente gerado por outras transações também não pode ser liberado, uma vez que o log de transação não pode ser liberado de modo seletivo. Se esse usuário, por exemplo, for embora sem concluir a transação, o log de transação continuará aumentando quanto mais registros de log de transação forem gerados, mas não poderá ser liberado.
Você pode descobrir por que o log de transação não pode ser liberado consultando o modo de exibição de catálogo do sistema sys.databases e examinando a coluna log_reuse_wait_desc, desta forma:
SELECT name AS [Database],
  log_reuse_wait_desc AS [Reason]
FROM master.sys.databases;
Se a causa vier a ser uma transação ativa, você poderá usar a instrução DBCC OPENTRAN para obter mais informações sobre a transação:
DBCC OPENTRAN ('dbname')

P Ouvi dizer que REPAIR_ALLOW_DATA_LOSS deve ser usado apenas como um último recurso para recuperar da corrupção; a restauração de backups deve ser usada em seu lugar. Você pode explicar por que o "reparo para o SQL Server 2005" não deve ser usado e por que ele está no produto, considerando o quanto ele é "perigoso"?
R Primeiramente, eu realmente escrevi reparo para o SQL Server 2005. O problema com REPAIR_ALLOW_DATA_LOSS (que eu chamarei apenas de reparo daqui em diante) é que ele não é claro sobre como funciona. O nome da opção de reparo foi escolhido para explicar que executá-la poderia levar à perda de dados do banco de dados. A maneira com a qual o recurso normalmente repara uma estrutura de banco de dados corrompida é excluir a estrutura corrompida e, em seguida, corrigir todo o resto no banco de dados que consultou ou foi consultado pela estrutura excluída. O reparo realmente pretende ser um último recurso para deixar o banco de dados estruturalmente consistente — seu foco não é salvar dados do usuário. O reparo não sai do seu caminho para excluir dados do usuário, mas ele também não sai do seu caminho para salvar dados do usuário.
Isso pode parecer como um modo irresponsável de conduzir reparos, mas quando a opção de recuperação precisa ser usada, ela fornece o método mais rápido e confiável para corrigir a corrupção. A velocidade é de importância suprema em uma situação de recuperação de desastres e a precisão é absolutamente necessária. É quase impossível planejar algoritmos de reparo mais complexos que podem ser comprovados por funcionarem de modo rápido e correto em todos os casos. Existem alguns algoritmos complexos no código de reparo para resolver o caso em que dois índices possuem a mesma página ou extensão alocada, por exemplo, mas, na maioria das vezes, o algoritmo é de reparo e correção.
Ainda assim, existem alguns problemas com o reparo sobre os quais você deve estar ciente:
  • O reparo não considera restrições de chave estrangeira ao excluir estruturas corrompidas, então ele pode excluir registros de uma tabela que possua uma relação de chave estrangeira com outra tabela. Não há como determinar se isso ocorreu sem a execução de DBCC CHECKCONSTRAINTS após executar o reparo.
  • O reparo não considera (e não pode considerar) nenhuma lógica de negócios inerente ou relação de dados definidas no nível do aplicativo que poderia ser quebrada por algum dado que estivesse sendo excluído. Novamente, não há como determinar se algo está quebrado sem executar qualquer verificação de consistência personalizada que esteja incorporada no aplicativo.
  • Algumas operações de reparo não podem ser replicadas. Executar o reparo em um editor ou nó em uma topologia ponto a ponto pode introduzir inconsistências dentro da topologia, o que deve ser corrigido manualmente.
Por essas razões, é sempre uma boa idéia recuperar da corrupção usando um backup em vez de executar a opção de reparo. Mas o reparo é oferecido no produto porque sempre existe a possibilidade de se entrar em uma situação na qual seu banco de dados está corrompido, não existe backup e você precisa de alguma maneira de colocar o banco de dados online rapidamente.

P Acabei de mudar para uma nova empresa como DBA e sou responsável por vários aplicativos e seus bancos de dados back-end. Um dos aplicativos tem um desempenho muito fraco ao fazer atualizações. Fiz uma investigação e descobri que as tabelas usadas pelo aplicativo possuem um número enorme de índices em cada uma. Após fazer umas perguntas, parece que o DBA anterior tinha o hábito de adicionar um índice da coluna de cada tabela, além de algumas combinações. Não acredito que todos esses índices são necessários — como posso saber quais posso ignorar com segurança? Nós usamos o SQL Server 2005.
R O grande número de índices é bem provavelmente o fator que mais contribui pelo fraco desempenho, como você supõe. Sempre que uma linha é inserida, atualizada ou excluída da tabela, as operações correspondentes precisam ser feitas em cada índice não agrupado. Isso acrescenta muita sobrecarga em termos de E/Ss, utilização da CPU e geração de log de transação.
No SQL Server 2000, a única maneira de determinar quais índices estavam sendo usados era usar a criação de perfis e examinar planos de consulta. Com o SQL Server 2005, existe uma nova DMV (exibição de gerenciamento dinâmico) que controla o uso do índice — sys.dm_db_index_usage_stats.
Essa DMV registra todas as vezes que um índice foi usado (e como ele foi usado), desde quando o banco de dados ao qual ele faz parte foi iniciado. As estatísticas para todos os bancos de dados são perdidas quando o SQL Server é desligado e as estatísticas para um único banco de dados são perdidas quando ele é fechado ou desconectado. A idéia é que se um índice não aparece na saída, significa que ele não foi usado desde quando o banco de dados foi iniciado.
Uma abordagem simples para controlar o uso do índice com o tempo é tirar instantâneos periódicos da saída da DMV e, em seguida, comparar os instantâneos. Uma coisa que várias pessoas deixam escapar é que você deve controlar o uso do índice em um ciclo de negócios inteiro. Se você apenas tirou um instantâneo para um único dia, poderá encontrar vários índices que não são usados. Mas se esses índices forem usados, digamos, para ajudar os relatórios de final de mês a executarem magnitudes com mais rapidez, os índices provavelmente não devem ser removidos. Se um índice realmente não tiver sido usado por um ciclo de negócios inteiro, provavelmente você poderá ignorá-lo e recuperar espaço e desempenho.
Para obter alguns códigos simples que você pode usar para tirar instantâneos periódicos da DMV, consulte a postagem do meu blog em sqlskills.com/blogs/paul/2007/10/05/IndexesFromEveryAngleHowCanYouTellIfAnIndexIsBeingUsed.aspx.

Paul S. Randal é diretor administrativo da SQLskills.com e MVP do SQL Server. Paul escreveu o DBCC CHECKDB/repair para SQL Server 2005 e foi responsável pelo mecanismo de armazenamento principal durante o desenvolvimento do SQL Server 2008. Especialista em recuperação de desastres, alta disponibilidade e manutenção de banco de dados, Paul é apresentador regular de conferências. Ele bloga em SQLskills.com/blogs/paul.


Utilitário em destaque Ferramenta de manutenção de máquina virtual offline
Peter Skjøtt Larsen e Suveen Kumar Reddy Vuppala

Sumário
Pesadelo de segurança
Nos bastidores
Infra-estrutura de manutenção
Usando a ferramenta
Em breve
Virtualizar a carga de trabalho de um computador simplesmente significa usar uma máquina virtual (VM) para soltar a carga de trabalho do hardware subjacente. Departamentos de TI modernos consideram as VMs úteis em várias situações, incluindo:
Alternância de cargas de trabalho Você pode usar facilmente as VMs para aumentar ou diminuir a largura de banda da carga de trabalho de várias configurações, à medida que sua demanda de uso for alterada, sem ter que fazer uma alteração de hardware correspondente.
Desenvolvimento e teste de aplicativos É possível criar várias VMs que representam cada configuração que um aplicativo deve suportar sem precisar de hardware dedicado.
Atualizações de software Você pode usar as VMs para colocar online a versão nova de um pacote de software enquanto coloca offline a versão anterior — tudo no mesmo hardware.
Distribuição de software As VMs podem ser usadas como uma unidade de distribuição para um aplicativo de linha de negócios que possua uma combinação consistente de software em um pacote pré-testado.

Pesadelo de segurança
Uma das vantagens de usar as VMs é que você pode armazená-las em um estado offline como imagens de VM. Então, quando você precisar delas, poderá "acordar" essas VMs e implantá-las muito mais rapidamente do que o hardware equivalente.
Manter um número cada vez maior de ambientes de computação aguardando offline apresenta um desafio de manutenção, no entanto. Vários mecanismos de atualização de software contam com sistemas para ficar online a fim de verificar atualizações ou receber atualizações automaticamente.
Quando uma VM não está online, ela é apenas um arquivo em um computador, então não pode interagir com nenhum mecanismo de atualização. Uma VM que tenha sido colocada online após estar offline por alguns meses, assim, pode se tornar uma ameaça à rede ou a rede poderia ameaçá-la.
Não é simplesmente uma questão de perder atualizações do sistema operacional. Aplicativos desatualizados ou perfis de vírus podem tornar a VM vulnerável ou fora de conformidade com os padrões da empresa.
Para ajudar os clientes a resolver o desafio de manter as VMs offline atualizadas, a equipe do Microsoft Solution Accelerator criou a Ferramenta de manutenção de máquina virtual offline. Essa ferramenta funciona com System Center Configuration Manager (SCCM) 2007, Windows Server Update Services (WSUS) 3.0 e System Center Virtual Machine Manager (VMM) 2007 para orquestrar a atualização de VMs armazenadas. A Figura 1 mostra um processamento conceitual da ferramenta e como ela se conecta a vários componentes externos.
Figura 1 Como funciona a ferramenta de manutenção de máquina virtual offline (clique na imagem para ampliá-la)
Para tornar as VMs disponíveis para atualizações, a ferramenta usa o VMM para implantá-las temporariamente em hosts de manutenção. Como uma configuração de host de manutenção normalmente possui a CPU e memória necessárias para executar várias VMs ao mesmo tempo, a ferramenta pode gerenciar VMs em lotes.
Assim que as VMs estiverem ativas nos hosts de manutenção, o SCCM ou WSUS podem fornecer a elas as atualizações necessárias. Após as atualizações terem sido aplicadas, a ferramenta usa o VMM para retornar as VMs ao seu estado offline. (Observe que a ferramenta suporta apenas as VMs gerenciadas pelo VMM.)

Nos bastidores
A Ferramenta de manutenção de máquina virtual offline usa o Windows Workflow Foundation (WF) para orquestrar o processo de atualização de uma VM. O processo possui vários pontos de decisão, começando com a escolha do sistema de gerenciamento de atualização apropriado, a seleção do próximo host de manutenção disponível adequado para a VM, a verificação de que a atualização ocorreu e, finalmente, o tratamento de exceções.
Usar uma solução baseada no Windows WF ofereceu à equipe de desenvolvimento uma grande flexibilidade para alterar e desenvolver o processo. Ela também oferece aos usuários uma solução eficiente que pode ser ajustada para atender a necessidades específicas. Em momentos críticos do processo, etapas incorporadas pré e pós-fluxo de trabalho fornecem oportunidades para personalização.
A ferramenta usa o Windows PowerShell para implementar tarefas individuais abaixo do nível do fluxo de trabalho, que se une com precisão à API do Windows PowerShell oferecida pelo VMM. E a interface de usuário baseada em Microsoft .NET Framework parece com produtos do System Center, então usuários novos devem se sentir em casa.

Infra-estrutura de manutenção
Um dos princípios básicos da infra-estrutura de manutenção é configurar a segurança da rede para proteger as VMs de danos durante o processo de atualização. Na versão 1.0 da ferramenta, isso é realizado usando uma VPN (rede virtual privada) à qual o VMM e o sistema de atualização apropriado (WSUS ou SCCM) se conectam. A infra-estrutura mais apropriada para uma biblioteca VMM é uma SAN (rede de área de armazenamento) conectada a Fibre Channel, que fornece o meio para a transferência rápida de imagens de VM aos hosts de manutenção.
Todas as VMs devem ser membros do mesmo domínio, um que use Active Directory e DNS. Servidores separados podem ser dedicados ao VMM, WSUS, SCCM e à biblioteca do VMM, mas combinações de servidores virtuais também podem ser usadas para ambientes menores. Não é preciso dizer que os hosts de manutenção devem ser servidores físicos.

Usando a ferramenta
Após ter configurado a infra-estrutura de manutenção, você precisa verificar se certas configurações estão corretas antes que a ferramenta possa ser iniciada. Verifique se o VMM está gerenciando todas as VMs apropriadas, se cada VM possui o cliente de atualização adequado instalado e se os pacotes de atualização necessários estão configurados no WSUS ou SCCM. Verificar se os grupos de hosts de manutenção estão configurados no VMM é opcional.
Quando estiver pronto, inicie a Ferramenta de manutenção de máquina virtual offline, que possui várias etapas de configuração próprias. Você terá que designar o servidor do VMM e o servidor do WSUS ou SCCM apropriados e, em seguida, especificar que grupo de hosts de manutenção usar (se os hosts de manutenção estiverem agrupados) e quais hosts de manutenção daquele grupo usar (consulte a Figura 2). Você pode querer configurar grupos de VMs a serem gerenciados, mas isso é opcional.
Figura 2 Configuração da ferramenta de manutenção de máquina virtual offline (clique na imagem para ampliá-la)
Após ter configurado a ferramenta, você cria os trabalhos de manutenção. Um trabalho de manutenção contém todas as informações que a ferramenta usa para gerenciar VMs específicas, incluindo se será usado o WSUS ou SCCM para atualizações; locais do servidor do VMM e do servidor do WSUS ou SCCM; identidades das VMs a serem gerenciadas; tipo (e identidade, conforme apropriado) da rede a ser usada para o processo; identidades dos hosts de manutenção a serem usados; credenciais da conta necessárias para acessar as VMs, o servidor do VMM e o servidor do WSUS ou SCCM; e, finalmente, o cronograma para executar o trabalho de manutenção (executar imediatamente ou em data e hora específicas).
Se você especificar data e hora para o trabalho de manutenção, o Agendador de Tarefas do Windows determinará quando iniciar. Enquanto o trabalho de manutenção é executado, a Ferramenta de manutenção de máquina virtual offline segue essa seqüência para cada VM:
  • Selecionar a próxima VM da biblioteca do VMM.
  • Consultar o VMM sobre o host de manutenção mais apropriado.
  • Implantar a VM no host de manutenção.
  • Verificar se a VM se conecta à rede correta.
  • Iniciar a VM.
  • Verificar se o cliente de atualização apropriado está instalado na VM.
  • Disparar o processo de atualização.
  • Aguardar o processo de atualização ser concluído.
  • Desligar a VM.
  • Armazenar a VM de volta na biblioteca do VMM.
O tempo que leva para atualizar uma biblioteca de VMs irá variar muito, dependendo do número e da capacidade dos hosts de manutenção, da velocidade de acesso do armazenamento da biblioteca do VMM e da natureza das atualizações.

Em breve
Você deve observar que a versão atual (1.0) da Ferramenta de manutenção de máquina virtual offline não suporta NAP (proteção de acesso à rede), que é uma maneira realmente atraente de proteger VMs da rede. Além disso, ela não suporta a tecnologia Hyper-V do Windows Server 2008 ou o uso do Windows Server 2008 como um sistema operacional cliente.
Versões mais novas do SCCM, WSUS e VMM estarão disponíveis em breve, e a versão 2.0 da Ferramenta de manutenção de máquina virtual offline fornecerá suporte a elas, bem como para Hyper-V e o uso do Windows Server 2008 no cliente. A ferramenta também irá suportar NAP para isolamento de rede. Você pode baixar a Ferramenta de manutenção de máquina virtual offline em technet.microsoft.com/cc501231.

Peter SkjØtt Larsen é gerente de produtos sênior na Microsoft. Antes de entrar na Microsoft, Peter estava envolvido na arquitetura e no desenvolvimento de sistemas de software operacionais de telecomunicações e na padronização e no desenvolvimento de serviços sem fio.
Suveen Kumar Reddy Vuppala é engenheiro de desenvolvimento de software sênior na Microsoft. Ele estava envolvido anteriormente no projeto e no desenvolvimento de ferramentas de monitoramento em tempo real e, nos últimos sete anos, em soluções de implantação para a Microsoft.


Windows PowerShell O poder dos perfis
Don Jones

Sumário
Shells, hosts e perfis
Usando seu perfil
Fazendo um console personalizado
Mais truques sobre perfis
Cuidado com os perfis!
Se você lê essa coluna regularmente, já sabe que o Windows PowerShell suporta um sistema de perfis. Eles são essencialmente scripts do shell, com uma extensão de nome de arquivo .ps1, executada automaticamente quando o shell é executado. Eles fornecem uma maneira excelente de definir aliases personalizados, por exemplo. Você pode fazer com que, a cada vez que o shell for executado, o perfil define automaticamente seus aliases, tornando-os disponíveis sempre que você estiver usando o shell.
O shell define os quatro perfis diferentes a seguir:
  • Um que se aplica a todos os shells e todos os usuários do computador.
  • Um que se aplica a todos os usuários, mas apenas ao shell do Microsoft PowerShell.
  • Um que se aplica ao usuário atual e a todos os shells.
  • Um que se aplica ao usuário atual e apenas ao shell do Microsoft PowerShell.
O conceito de "todos os shells" pode ser um pouco confuso. A terminologia está enraizada em alguns conceitos de desenvolvimento antigos do Windows PowerShell que realmente não conseguiam chegar ao produto final. Hoje, o termo "todos os hosts" provavelmente seriam mais apropriados.

Vídeo
Assista à demonstração de Don Jones sobre como é possível criar perfis para personalizar o shell do Windows PowerShell.

Shells, hosts e perfis
Sabe, o Windows PowerShell em si é um conjunto de assemblies do Microsoft .NET Framework. Gosto de me referir a essa parte do shell como o mecanismo do Windows PowerShell porque ela contém a funcionalidade que você geralmente considera como sendo o Windows PowerShell. Não existe uma maneira interna para os humanos interagirem com esse mecanismo, no entanto. Para você realmente usar o shell, o mecanismo deve ser carregado por um aplicativo de hospedagem (ou host).
O aplicativo powershell.exe que você provavelmente usou para executar é um host desse tipo. O aplicativo gpowershell.exe incluído com o CTP (Community Technology Preview) do Windows PowerShell 2.0 é outro host. Essa relação entre hosts e shells não é tão simples quanto eu a tornei aqui, mas minha explicação simplificada abrange o comportamento que você verá.
É importante entender que se você está interagindo com o shell por uma interface de linha de comando baseada em texto, você provavelmente está usando o host powershell.exe. Isso se aplica mesmo se você tiver iniciado o shell usando um atalho instalado por outro aplicativo, como o Shell de Gerenciamento do Exchange. O Shell de Gerenciamento do Exchange não é um aplicativo de hospedagem ou shell diferente. Em vez disso, ele é meramente o host powershell.exe normal iniciado usando um atalho que especifica um conjunto de snap-ins e scripts a serem pré-carregados. Esses snap-ins são o que permitem ao Exchange a funcionalidade de gerenciamento dentro do shell. Mas você ainda está usando o mesmo shell.
Os locais (no Windows Vista) dos perfis para o host powershell.exe são os seguintes:
  • %windir%\system32\WindowsPowerShell\v1.0\profile.ps1 Esse é para todos os usuários do computador e para todos os shells.
  • %windir%\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1 Esse é para todos os usuários do computador, mas é apenas para o shell do Microsoft.PowerShell.
  • %UserProfile%\Documents\WindowsPowerShell\profile.ps1 Esse é apenas para o usuário atual e todos os shells.
  • %UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 Esse é apenas para o usuário atual e apenas para o shell do Microsoft.PowerShell.
Esses perfis não são criados por padrão. Eles apenas existem se você criá-los.
Cada aplicativo de hospedagem é responsável por carregar e executar o perfil correto. Se um determinado aplicativo de hospedagem "decide" não carregar nenhum perfil, ele, na verdade, não precisa. A execução do perfil não é feita pelo mecanismo do Windows PowerShell automaticamente.
A maneira mais fácil de controlar tudo isso é simplesmente abrir o shell, digitar $profile e pressionar Enter. Isso fornecerá a você todo o caminho que o shell está tentando usar como o que eu considero o perfil "primário" (é o perfil específico do shell por usuário). Você pode então criar ou modificar esse script e ele será executado a cada vez que o shell for iniciado.

Usando seu perfil
Um uso comum para um perfil é definir aliases personalizados, como sugeri anteriormente. Ou você pode adicionar PSDrives personalizados (são unidades essencialmente mapeadas que existem inteiramente no Windows PowerShell). Um uso menos comum é criar um tipo de supershell que possa fazer qualquer tarefa de gerenciamento que você possa precisar, com base nos produtos de software que você está usando no seu ambiente. Para explicar realmente o conceito do supershell, preciso primeiro fornecer um pouco de informações básicas.
O grupo de produtos da Microsoft que cria o Windows PowerShell é responsável por várias das outras principais tecnologias de gerenciamento, incluindo o MMC (console de gerenciamento da Microsoft). O MMC fornece uma boa analogia para exatamente como o Windows PowerShell funciona. Quando você executa o mmc.exe, começa com um console em branco que não é bom para muita coisa. Você adiciona os snap-ins do MMC para criar um console funcional.
Depois de configurar seu console da maneira desejada, você salva o console em um arquivo com uma extensão de nome de arquivo .msc. Esse arquivo de console salvo permite que você recarregue rapidamente seu console personalizado a qualquer momento.
Em vez de fazer consoles MMC personalizados, vários administradores apenas contam com os consoles que estão instalados com os produtos que eles gerenciam. O Exchange Server, por exemplo, cria um console que contém apenas o snap-in do Exchange Server. Usuários e Computadores do Active Directory é outro console pré-criado que contém um único snap-in.
O Windows PowerShell funciona quase que da mesma maneira. O ícone do Shell de Gerenciamento do Exchange instalado com as ferramentas de gerenciamento do Exchange Server 2007 é na verdade um atalho para o powershell.exe com instruções para carregar um arquivo de console. Os arquivos de console do shell possuem uma extensão de nome de arquivo .psc1 e contêm uma lista de snap-ins para pré-carregar (muito como um arquivo .msc contém uma lista de snap-ins que o MMC pré-carrega para você). No entanto, você não fica preso usando esses consoles de shell pré-criados. Você pode criar um console personalizado — assim como pode com o MMC — e usá-lo para realizar todas as suas tarefas de gerenciamento. Os perfis representam um papel principal em tornar isso possível.

Fazendo um console personalizado
Para fazer um console personalizado, você deve começar encontrando os nomes completos de cada snap-in com o qual deseja trabalhar. Verifique se todas as ferramentas de gerenciamento necessárias estão instaladas no seu computador. Em seguida, no Windows PowerShell, execute Get-PSSnapin –registered. Isso listará todos os snap-ins disponíveis registrados, embora não carregados. Em seguida, crie ou edite o perfil do Windows PowerShell apropriado. Adicione os comandos Add-PSSnapin para carregar cada snap-in que você deseja que esteja disponível sempre. Isso pode incluir snap-ins para Exchange Server, produtos System Center e snap-ins de terceiros, como as Extensões de Comunidade do PowerShell. Em seguida, salve seu perfil (lembre-se de assinar digitalmente o perfil se sua política de execução do Windows PowerShell exigir) e feche o shell. Reabra o shell e ele carregará automaticamente todos os snap-ins listados no seu perfil.
Outra técnica é carregar todos os seus snap-ins no shell (usando Add-PSSnapin e os nomes dos snap-ins) e, em seguida, executar Export-Console para criar um arquivo de console .psc1 que contenha todos os snap-ins que você está usando no momento. Você pode então usar esse arquivo de console .psc1 para criar um novo atalho do Windows PowerShell que especifica o parâmetro PSConsoleFile e seu arquivo .psc1 personalizado. Esse atalho usaria então seu console, carregando todos os snap-ins especificados automaticamente.

Mais truques sobre perfis
Eu uso meu perfil do Windows PowerShell para executar várias outras tarefas úteis cada vez que o shell é iniciado. Veja um pouco do que acontece quando o shell é iniciado no meu sistema:
  1. Eu executo Get-Credential para minha conta de Administrador de Domínio, armazenando os resultados em uma variável chamada $cred. Isso disponibiliza $cred por todo o shell. Posso então transmiti-lo ao parâmetro –credential de vários cmdlets, como o cmdlet Get-WmiObject. Como $cred armazena a senha, posso usar esses cmdlets sem ser solicitado por uma senha.
  2. Executo Cd C:\ para que o shell seja iniciado na raiz da unidade C: do computador.
  3. Executo New-Alias de Out-File para criar um alias chamado "of". Isso para que eu possa usar "of" em vez de "Out-File". Eu uso muito isso, então ter um alias curto definido é muito prático.
Tento criar uma chave de teste na unidade HKLM: do shell, que representa a parte HKEY_LOCAL_MACHINE do Registro. Se um erro ocorrer, eu sei que o shell foi iniciado sem privilégios elevados. Eu normalmente exijo privilégios elevados para o trabalho que faço e essa é apenas uma maneira rápida para que eu saiba de antemão se possuo privilégios elevados antes de mergulhar em um trabalho sério.
Eu defino uma função personalizada chamada Ping-Address que aceita o nome de um computador ou endereço IP e retorna um valor de True ou False, dependendo se é possível alcançar o computador com ping. Uso muito essa função no meu trabalho, então, deixá-la definida no meu perfil a disponibiliza globalmente no meu shell.

Cmdlet do mês: Get-WmiObject
O observador astuto pode notar que estou falando de um cmdlet que apresentei antes, mas quero deixá-los com um recurso interessante que ele oferece. Muitas vezes, vejo os administradores tentarem recuperar informações do WMI (Instrumentação de Gerenciamento do Windows) de vários computadores, cujos nomes estão listados em um arquivo de texto, usando esta técnica:
Get-Content c:\computers.txt | ForEach-Object
  { Get-WmiObject Win32_Service –comp $_ }
Embora essa técnica funcione, você não precisa realmente dela porque Get-WmiObject pode aceitar uma matriz de nomes de computadores para o parâmetro –computerName. Para atingir o mesmo efeito, você pode apenas usar isto:
Get-WmiObject Win32_Service –comp (Get-Content
  c:\computers.txt)
Colocar o comando Get-Content em parênteses força o shell a executar o comando e colocar os resultados — uma matriz de nomes de computadores — no parâmetro –computerName.
Cuidado com os perfis!
Tenha em mente que o powershell.exe não é o único aplicativo que carrega os perfis Microsoft.PowerShell ou os perfis all-shells. Vários IDEs (ambientes de desenvolvimento integrado) que fornecem suporte a Windows PowerShell — incluindo PrimalScript da SAPIEN Technologies, PowerGUI da Quest Software e PowerShell Plus da ShellTools — também carregam esses mesmos perfis para fornecer uma experiência paralela ao host powershell.exe.
Um grande perfil que carrega muitos snap-ins pode fazer com que esses aplicativos sejam iniciados mais lentamente, porque existem muitas instruções para o mecanismo do Windows PowerShell executar antes que ele fique pronto para o aplicativo de hospedagem. Na verdade, mesmo o powershell.exe pode levar um tempo para ser inicializado se você tiver um script de perfil muito grande para executar.
Snap-ins que definem cmdlets com os mesmos nomes também podem causar colisões. Por exemplo, se dois snap-ins definem um cmdlet chamado Get-User, o Windows PowerShell não irá executar nenhum cmdlet até que você use o nome totalmente qualificado do cmdlet para especificar qual você deseja. Esse nome totalmente qualificado pode ficar feio, uma vez que nomes de snap-in podem ser bem longos. Quando me deparo com esse problema, eu normalmente apenas desisto da idéia de ter esses dois snap-ins carregados simultaneamente. Em vez disso, carregarei apenas o que eu uso mais no meu perfil e, em seguida, usarei como shell "fresco", separado quando eu precisar carregar e usar o outro snap-in.
Os perfis do Windows PowerShell podem proporcionar muita conveniência extra para o shell. Mas tenha em mente que se eles forem editados de modo mal-intencionado por um malware, os perfis poderão também causar muitos danos. Você pode proteger seu perfil assinando-o digitalmente e configurando o Windows PowerShell para usar sua política de execução AllSigned ou modificar as permissões do arquivo NTFS nos seus perfis — todos eles — para que sua conta de usuário normal não possa modificá-los.

Don Jones é autor de Windows PowerShell: TFM and VBScript, WMI, and ADSI Unleashed (Liberando o potencial de TFM e VBScript, WMI e ADSI). Para entrar em contato com ele, visite o site da Web PowerShellCommunity.org.


Ei, Equipe de Scripts! Famosas últimas palavras
A Equipe de Scripts da Microsoft

O famoso filósofo grego Sócrates (que morreu no ano 399 a. C., pouco antes do nascimento do Editor de Scripts), é conhecido por ter dito que "Uma vida sem exame não merece ser vivida." A maioria das pessoas já ouviu esse ditado. Pode parecer incrível mas, como a Equipe de Scripts descobriu recentemente, Sócrates nunca disse que "Uma vida sem exame não merece ser vivida". Ao que parece, isso foi uma tradução equivocada feita por um escriba medieval há centenas de anos. Na verdade, Sócrates disse: "Um arquivo XML sem exame não merece ser criado".
Afinal, um ditado filosófico que realmente faz sentido! O XML tem se tornado cada vez mais popular na atualidade; uma rápida pesquisa em um dos computadores de teste da Equipe de Scripts descobriu mais de 500 arquivos XML usados por vários sistemas ou aplicativos.
Nem é preciso dizer que uma enorme quantidade de dados muito importantes é armazenada agora no formato XML. E não há nenhum problema nisso. A menos, é claro, que os dados não sejam examinados. E, infelizmente, em geral é isso o que ocorre, por um simples motivo: a maioria das pessoas nem imagina como examinar um arquivo XML. Especialmente, as pessoas não têm idéia de como consultar e pesquisar esse tipo de arquivo.
Observação Se você não está bem informado sobre os filósofos gregos, Sócrates foi um grande defensor da prática de sair por aí falando sobre as coisas, mas era muito menos entusiasta quanto a sair por aí fazendo coisas. Na verdade, sua esposa, Xantipa, o chamava de "ocioso inútil". Percebe-se por que a Equipe de Scripts tem uma predileção especial por Sócrates.
Claro que alguns leitores devem estar pensando: “Espere um pouco: a Equipe de Scripts não abordou a pesquisa em um arquivo XML em uma coluna anterior ("Perseguindo carros… e XML", em technet.microsoft.com/magazine/cc162506)? Nesse caso, por que estão revisitando esse assunto agora? Será que a Equipe de Scripts é tão preguiçosa a ponto de escrever a mesma coluna várias vezes?"
Acredite ou não, somos ainda mais preguiçosos. Mas esse não é nosso motivo principal para revisitar o assunto. Na coluna anterior, falamos sobre o trabalho com um arquivo XML estruturado como o código na Figura 1, com cada valor de propriedade representando um único nó do arquivo.
Figura 1. Arquivo XML somente com nós
<?xml version='1.0'?>
  <INVENTORY>
    <COMPUTER>
      <os>Windows XP</os>
      <department>Human Resources
      </department>
      <name>atl-ws-001</name>
    </COMPUTER>
    <COMPUTER>
      <os>Windows XP</os>
      <department>Finance</department>
      <name>atl-ws-002</name>
    </COMPUTER>
    <COMPUTER>
      <os>Windows Vista</os>
      <department>Finance</department>
      <name>atl-ws-003</name>
    </COMPUTER>
  </INVENTORY>
Muito bem, exceto pelo fato — que as pessoas rapidamente identificaram e sobre o qual nos escreveram — de que essa não é a única forma na qual é possível estruturar arquivos XML. No exemplo anterior, cada computador no arquivo tem seu próprio nó; cada um desses nós, por sua vez, tem determinado número de nós filho (os, department e name). Contudo, também é possível construir um arquivo XML em que os nós individuais não tenham nós filho. Em vez disso, valores adicionais de propriedades são configurados como atributos. Como no arquivo mostrado na Figura 2.
Figura 2. Arquivo XML com atributos
<?xml version='1.0'?>
  <HARDWARE>
      <COMPUTER os="Windows XP" department="Human Resources">atl-ws-001</COMPUTER>
      <COMPUTER os="Windows XP" department="Finance">atl-ws-002</COMPUTER>
      <COMPUTER os="Windows Server 2003" department="IT">atl-fs-003</COMPUTER>
      <COMPUTER os="Windows Vista" department="IT">atl-ws-004</COMPUTER>
      <COMPUTER os="Windows Vista" department="Human Resources">atl-ws-005</COMPUTER>
      <COMPUTER os="Windows Vista" department="Finance">atl-ws-006</COMPUTER>
      <COMPUTER os="Windows XP" department="Sales">atl-ws-007</COMPUTER>
      <COMPUTER os="Windows Server 2008" department="IT">atl-fs-008</COMPUTER>
      <COMPUTER os="Windows XP" department="Human Resources">atl-ws-009</COMPUTER>
      <COMPUTER os="Windows Vista" department="Sales">atl-ws-010</COMPUTER>
  </HARDWARE>
Isso é um problema? Na verdade, sim. O script que mostramos há muito tempo, em uma edição distante, não funciona com um arquivo XML estruturado como aquele mostrado na Figura 2. Simplesmente não dá resultado. E isso é definitivamente um problema, porque muitos de vocês precisam ler esse tipo de arquivo XML.
Tudo o que vocês precisaram fazer foi perguntar. Bem... Além de esperar um ano e meio até que finalmente resolvêssemos tratar do assunto.
Antes de prosseguir, vamos analisar melhor nosso arquivo XML. Neste caso, temos um arquivo com o nó principal chamado HARDWARE; cada computador individual existe como nó filho de HARDWARE. Além disso, cada um desses nós tem dois atributos: os (usado para armazenar o nome do sistema operacional instalado no computador) e department (usado para armazenar o nome do departamento proprietário do computador).
Suponha, por exemplo, que quiséssemos obter uma lista de todos os computadores executando Windows XP. É possível fazer isso usando um script? Claro que sim:
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("HARDWARE.xml")

Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER[@os='Windows XP']")

For Each objNode in colNodes
  Wscript.Echo objNode.Text
Next
Vejamos o que temos aqui. Para começar, criamos uma instância do objeto Microsoft.XMLDOM; como o nome já diz, esse é o objeto que nos permite trabalhar com arquivos XML. Depois de criar o objeto, precisamos definir a propriedade Async como False. Isso permite ao script saber que desejamos carregar o documento de forma síncrona, em vez de assíncrona. Qual a importância disso para o script? Na verdade, nenhuma. Afinal, os scripts (assim como os membros da Equipe de Scripts) são objetos inanimados.
Mas isso é importante para você. Se carregássemos o documento de forma assíncrona, o script continuaria em execução, mesmo que o documento não estivesse totalmente carregado. Isso não seria nada bom: imagine os problemas que poderiam ocorrer se você tentasse realizar uma tarefa em um documento que ainda não existisse. Carregar um arquivo XML de forma síncrona garante que ele será totalmente carregado antes que o script prossiga.
Por uma incrível coincidência, chegamos ao ponto em que devemos carregar nosso arquivo XML. Fazemos isso chamando o método Load e abrindo o arquivo C:\Scripts\HARDWARE.xml, o que nos traz a esta linha de código:
Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER[@os='Windows XP']")
O que estamos fazendo aqui é usar o método SelectNodes para consultar o arquivo XML e informar ao script quais nós XML queremos recuperar. Observe a sintaxe, que é, sem dúvida, um pouco fora do comum.
Para começar, precisamos especificar o caminho no arquivo XML. Nosso arquivo XML tem um nó de nível superior chamado HARDWARE, seguido por uma série de nós de segundo nível chamados COMPUTER. Cada um desses nós de segundo nível representa um único registro em nosso arquivo de dados XML. Por isso, nossa consulta selectNodes começa assim:
//HARDWARE/COMPUTER
Neste ponto, encontramos a seguinte construção:
[@os='Windows XP']
Essa parte da consulta é semelhante a uma cláusula WHERE em uma consulta SQL padrão. Com o SQL, poderíamos usar uma consulta ao banco de dados semelhante a essa para recuperar uma lista de todos os computadores executando o sistema operacional XP:
SELECT Name FROM Hardware
    WHERE OS = 'Windows XP'
Com o método SelectNodes, estamos fazendo algo semelhante: estamos pedindo para obter uma lista de todos os computadores nos quais o atributo os (@os) é igual a Windows XP. E, para indicar que se trata de uma cláusula WHERE, colocamos toda a cláusula entre colchetes.
Observação Esse tipo de consulta é conhecido como XPath. Para saber mais sobre o XPath, consulte msdn.microsoft.com/library/ms256115.aspx.
Como dissemos, é um pouco estranho, mas funciona. E se quiséssemos obter uma lista de todos os computadores pertencentes ao departamento Finance? Não seria difícil. Nossa chamada para selectNodes teria esta aparência:
Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER" & _
   "[@department='Finance']")
Mais uma vez, a cláusula WHERE é colocada entre colchetes, o nome do atributo (department) é precedido pelo sinal de arroba (@), e então indicamos o valor no qual estamos interessados.
Simples, não é?
Depois de chamarmos o método selectNodes, podemos recuperar os nomes dos computadores simplesmente fazendo um loop pela coleção de valores retornados e recuperando a propriedade Text, conforme mostrado a seguir:
For Each objNode in colNodes
  Wscript.Echo objNode.Text
Next
Que tipo de informação podemos esperar obter? Para dizer a verdade, esperamos obter informações como estas:
atl-ws-001
atl-ws-002
atl-ws-007
atl-ws-009
Ou seja, os nomes de todos os computadores ainda executando Windows XP.
Aliás, você não está limitado a recuperar apenas o nome do computador. Como o nome do computador é o valor "padrão" para cada nó, isso é simplesmente o que obtemos ao fazer referência à propriedade Text.
Como alternativa, seria possível especificar exatamente quais valores de atributos gostaríamos que fossem retornados. Observe, por exemplo, este loop For Each modificado:
For Each objNode in colNodes
    Wscript.Echo objNode.Text
    Wscript.Echo objNode.Attributes. _
      getNamedItem("department").Text
    Wscript.Echo
Next
Como você pode ver, ainda estamos recuperando no loop o valor da propriedade Text. No entanto, incluímos também esta linha de código:
Wscript.Echo objNode.Attributes. _
  getNamedItem("department").Text
Nesse caso, usamos o método getNamedItem para recuperar o valor do atributo department; depois, recuperamos a propriedade Text para esse atributo. Assim, podemos especificar os valores de atributos que queremos (ou não) recuperar e exibir na tela (observe também que adicionamos um comando Wscript.Echo para colocar uma linha em branco entre os registros). Ao executarmos esse script, devemos obter o seguinte:
atl-ws-001
Human Resources

atl-ws-002
Finance

atl-ws-007
Sales

atl-ws-009
Human Resources
E, se você quiser, poderá escrever consultas mais complexas. Suponha, por exemplo, que você queira uma lista de todos os computadores executando Windows XP ou Windows Vista. No SQL, você faria isso escrevendo uma consulta OR. Adivinhe! Você deve fazer exatamente o mesmo para consultar um arquivo XML:
Set colNodes=xmlDoc.selectNodes _
    ("//HARDWARE/COMPUTER" & _
     "[@os='Windows XP' or " & _
     "@os='Windows Vista']")
Viu o que fizemos aqui? Entre um único par de colchetes, fornecemos dois critérios: @os='Windows XP' ou @os='Windows Vista'. Basta fazer isso para recuperar um relatório parecido com o da Figura 3.
Figura 3. Resultado da consulta OR
atl-ws-001
Human Resources

atl-ws-002
Finance

atl-ws-004
IT

atl-ws-005
Human Resources

atl-ws-006
Finance

atl-ws-007
Sales

atl-ws-009
Human Resources

atl-ws-010
Sales
Se você verificar o arquivo XML, perceberá que os computadores executando Windows XP ou Windows Vista estão incluídos na saída; já os computadores executando Windows Server 2003 ou Windows Server 2008, não. Nem deveriam estar.
Alguma dúvida? Você gostaria de escrever uma consulta mais restrita, que retornasse somente os computadores executando Windows XP e pertencentes ao departamento Finance? Como você já deve imaginar, isso é fácil. Basta escrever uma consulta AND desta forma:
Set colNodes=xmlDoc.selectNodes _
    ("//HARDWARE/COMPUTER" & _
     "[@os='Windows XP' and " & _
     "@department='Finance']")
Isso retornará o seguinte conjunto de dados:
atl-ws-002
Finance
Por que há apenas um item no relatório? Isso mesmo: porque o departamento Finance tem um único computador executando Windows XP.
Esperamos ter ajudado todos vocês a lidar com esse tipo específico de arquivo XML. Se, no fim das contas, ainda houver outro tipo de arquivo XML escondido por aí, bem... Boa sorte.
Por termos começado a coluna deste mês com um ditado famoso, imaginamos que seria adequado encerrá-la no mesmo tom. Então, gostaríamos de terminar com as palavras do Kaiser Guilherme II, pelas quais a Equipe de Scripts tem grande apreço: "Por meio deste, renuncio perpetuamente às reivindicações ao trono da Prússia, bem como ao trono do Império Alemão, a ele conectado".
O desafio de script do Dr. Scripto
O desafio mensal que testa não apenas sua habilidade de resolver quebra-cabeças, mas também de criar scripts.

Outubro de 2008: palavras cruzadas de VBScript
Para resolver este quebra-cabeça, basta preencher cada linha com o nome de uma função do VBScript. Quando terminar, coloque as letras nos quadrados azuis na ordem correta para descobrir o nome de mais uma função.

RESPOSTA:
O desafio de script do Dr. Scripto
Resposta: outubro de 2008: palavras cruzadas de VBScript

A Equipe de Scripts — Greg Stemp e Jean Ross — trabalha na Microsoft.


Os arquivos da área de trabalho Personalizando serviços de implantação do Windows
Wes Miller

Sumário
Substituindo o que você possui
Examinando a pilha
Programa de inicialização de rede
Provedor PXE do WDS
TFTP Daemon
Armazenamento de dados de configuração da inicialização
Windows PE
Servidor de transporte
Multicast personalizado
Conclusão
Por três meses, tenho me aprofundado no WDS (Windows Deployment Services) — suas origens, uma visão geral, um exame mais próximo de alguns tópicos avançados como WDSUtil e multicast. Neste capítulo final da série, vamos dar uma olhada em onde e como você pode personalizar e configurar o WDS para atender às necessidades da sua organização. A maioria das ferramentas da Microsoft é projetada com alguma quantia de configurabilidade. Mas é quando o pneu tocar a estrada que você normalmente descobrirá se as ferramentas atenderão às suas necessidades ou, com mais freqüência, que elas exigem alguns ajustes para funcionar nos seus cenários.

Substituindo o que você possui
Uma pergunta que os leitores me fazem com freqüência ultimamente é: "Eu tenho x (uma tecnologia de implantação existente). O WDS funcionará para mim e ele possui recurso de paridade com x?". Com a desaprovação do ADS (Serviços Automatizados de Implantação), uma área de interesse particular é: "Como posso executar uma implantação rápida de alto volume ou o reprovisionamento de servidores — o WDS pode fazer isso por mim?".
Embora o WDS não tenha sido projetado como uma substituição 1:1 para o ADS — e, de fato, faltam nele alguns componentes principais para que seja considerado um substituto real —, com um pouco de trabalho você pode fazer com que o WDS substitua o ADS. Da mesma forma, se algum aspecto do WDS não estiver funcionando para você do modo em que ele está, você descobrirá que muitos de seus componentes podem ser substituídos — com graus variáveis de complexidade e engenharia. Vamos dar uma olhada na implantação por WDS e examinar as partes que você pode desejar personalizar e como você poderia fazer isso.

Examinando a pilha
A Figura 1 mostra os componentes do processo de implantação do WDS. Cada uma dessas etapas pode ser personalizada até um determinado nível. Eu codifiquei por cores cada etapa para refletir o que acredito ser a complexidade (geralmente as habilidades de desenvolvimento) envolvida na substituição ou personalização dela. Quanto mais escuro for o azul, mais difícil provavelmente será para personalizar aquela etapa.
Figura 1 Complexidade de personalização do WDS
A dificuldade em personalizar cada etapa realmente, é claro, depende das habilidades da sua equipe (desenvolvimento ou script) e sua compreensão do WDS, do WIM (Windows Imaging Format), do Active Directory ou de qualquer outra tecnologia que você queira integrar, como SQL ou ADSI. Vamos examinar cada uma dessas etapas, pensando nas maneiras em que você pode querer personalizá-las e os métodos que podem ser usados.

Programa de inicialização de rede
É duvidoso que você precise criar um NBP (programa de inicialização de rede) personalizado para substituir os fornecidos com o WDS, mas é possível. O WDS inclui NBPs para uso com sistemas sem periféricos (geralmente servidores) ou sistemas que você pode ou não solicitar por F12, e assim por diante. Esses NBPs podem ser pré-configurados no Active Directory usando o WDSUtil, ou você pode substituir Startrom.com pelo NBP que deseja usar para todos os sistemas que não estejam pré-configurados (por exemplo, se todos os seus sistemas forem sem periféricos ou se você nunca desejar solicitar por F12).
Infelizmente, não existe muita documentação disponível sobre como criar seu próprio NBP (consulte msdn.microsoft.com/library/bb870970.aspx para obter algumas informações). Um NBP é um executável de 16 bits muito pequeno com fortes limitações e requer habilidades de programação específicas. Eu geralmente recomendo o uso de NBPs existentes fornecidos com o WDS, a menos que você esteja tentando atender a um requisito muito específico e você possua uma equipe de desenvolvimento com as habilidades apropriadas.

Provedor PXE do WDS
Com o RIS (serviços de instalação remota), comentários comuns que recebíamos dos clientes eram sobre o desejo de usar um armazenamento de dados que não fosse o Active Directory para informações do sistema do cliente — com mais freqüência, SQL Server. Com o WDS, o design inclui uma infra-estrutura conectável para provedores PXE (ambiente Pre-Boot eXecution). Isso significa que com o trabalho de desenvolvimento, você poderia usar outro armazenamento de apoio, além do Active Directory para informações PXE.
O WDS vem com seu próprio provedor que usa o Active Directory; o SCCM (System Center Configuration Manager) agora se conecta também ao WDS e implementa um provedor seu. A documentação sobre como escrever seu próprio provedor é muito escassa e não existem muitos códigos de exemplo disponíveis (embora o Windows SDK forneça alguma documentação e alguns exemplos), então a tarefa não é para os humildes. A menos que você tenha requisitos muito específicos para esse aspecto do processo de inicialização, eu novamente recomendaria não tentar um provedor PXE personalizado.

TFTP Daemon
Às vezes, os clientes investiram em seu próprio TFTPD (Daemon de protocolo de transferência de arquivos simples) antes que o WDS surgisse. Como os servidores PXE não funcionam bem juntos, isso muitas vezes significa se estabelecer em apenas um.
Na minha experiência, isso normalmente significa adotar um TFTPD existente, tipicamente baseado em Linux, e persuadi-lo a inicializar outros SOs. Com a infra-estrutura original usada pelo RIS você não poderia fazer isso. Mas quando a inicialização de RAMDisk virou norma, você poderia, e ainda é possível fazer isso usando imagens de inicialização baseadas no WDS.
Uma coisa a se ter em mente é que você está vagando por uma área tecnicamente não-suportada com relação à Microsoft e uma que muito provavelmente poderá causar problemas difíceis de se diagnosticar. Além disso, com o TFTPD aprimorado no WDS, você pode muito bem estar se distanciando de um melhor desempenho. Idealmente, recomendo que você use o TFTPD do WDS existente e tente usar tempos limite, pré-configurações e/ou bordas da rede do PXE para definir que clientes são inicializados de qual servidor PXE, em vez de tentar desviar um servidor existente para que se ajuste.

Armazenamento de dados de configuração da inicialização
Com o RIS, nunca foi possível, no nível da inicialização, especificar o que deveria ser inicializado, você sempre precisava passar pelo OS Chooser e selecionar uma opção (configuração, Windows PE —ambiente de pré-instalação do Windows — ou inteiramente outra coisa). O WDS, uma vez que ele usa um carregador completo para inicialização de rede, também suporta a personalização do armazenamento BCD (dados de configuração da inicialização) fornecida a clientes. O BCD padrão para cada arquitetura reside em RemoteInstall\Boot\<arch>\Default.bcd, onde <arch> é a arquitetura específica do sistema que está sendo inicializado.
Você pode personalizar esse BCD para cada cliente e o cliente o usará para inicializar. Você poderia, por exemplo, configurar uma entrada BCD para iniciar a configuração, outra para executar o WinRE (ambiente de recuperação do Windows) e ainda outra para executar um teste de memória — ou você poderia ter uma entrada de configuração totalmente automatizada como padrão e uma manual (ou experiência de configuração personalizada) como uma opção selecionada pelo usuário. (Para obter mais informações, vá para "How to Modify the BCD Store Using Bcdedit" — Como modificar o armazenamento BCD usando Bcdedit — em go.microsoft.com/fwlink/?LinkId=115267.)

É claro que a maior parte da tarefa pesada do WDS ocorre no Windows PE — então ajustar o Windows PE para atender às suas necessidades pode ser uma área crítica de foco para uma experiência personalizada. O WDS, por padrão, fornece um modelo padronizado para configuração, que inclui a experiência de configuração completa. Às vezes, as necessidades da sua implantação podem significar que isso não funcionará para você. Nesse caso, você pode criar sua própria imagem de inicialização do Windows PE. Vamos começar do início.
Além de usar o BCD para indicar que imagem usar, você também pode especificar a imagem personalizando o MAO (objeto de conta da máquina) para um computador no Active Directory. No RIS, um atributo de MAO específico armazenava cada item (que arquivo Startrom e Unattend — SIF — usar). Com o WDS, eles são armazenados como pares de nome-valor na entrada netBootMirrorDataFile. Por exemplo, a imagem de inicialização e o arquivo Unattend a ser usado por um determinado computador são armazenados nessa entrada. A forma das entradas é uma lista delimitada por ponto-e-vírgula de pares de nome-valor. As entradas para modificar a imagem de inicialização e o arquivo Unattend são BootImage e UnattendFilePath, respectivamente.
É claro que você poderá descobrir que deseja abandonar completamente a experiência de configuração existente e apenas criar a sua própria. Talvez você precise de mais configurabilidade, mais automação ou uma compilação automatizada pelo SQL Server. Você pode querer fazer como alguns clientes fizeram com o RIS e o Windows PE no início e compilar seu próprio front-end para configuração. As principais tarefas que você precisa realizar, independentemente da experiência de configuração escrita, são:
  • Descobrir qualquer informação por máquina ou por usuário. Essas informações podem ser obtidas da entrada do usuário ou do SQL Server ou de um arquivo de texto, por exemplo.
  • Copiar e aplicar uma imagem de configuração para o sistema do cliente. Essa tarefa pode ser realizada usando a configuração diretamente, usando ImageX para aplicar uma imagem de um compartilhamento de rede ou por multicast (simplesmente copie a imagem e aplique-a via ImageX).
  • Fornecer um arquivo Unattend (como Unattend.xml ou sysprep.inf, dependendo da versão do Windows que está sendo implantada) para a configuração ser concluída.
  • Automatizar qualquer etapa de migração pós-configuração que você deseje executar (ou qualquer etapa para aplicar funções no caso do Windows Server 2008).
O ADS iniciou o conceito de seqüências de tarefas que permite a etapas reprodutíveis serem atribuídas a um ou mais computadores. Como o ADS não foi projetado ou suportado para o uso com o Windows XP, você não poderia usá-lo para implantar o sistema operacional. Mas a seqüência de tarefas do ADS é realmente apenas de scripts estruturados e você pode executar as mesmas etapas usando um processo de configuração personalizado.
Sou fã do Microsoft SQL Server há algum tempo (desde a versão SQL Server 6.5), então meu instinto é criar tal estrutura usando o SQL. É claro que você precisa adicionar a funcionalidade do SQL à sua compilação do Windows PE para fazer isso. Além disso, você poderia escrever sua própria GUI — um HTA (aplicativo HTML) ou executável compilado — ou usar o WSH (Windows Script Host) para executar uma experiência de configuração apenas de linha de comando minimalista. O HTA ou WSH também precisariam ser adicionados ao Windows PE para que fossem utilizados.
A complexidade em projetar sua própria experiência de configuração completamente depende das suas habilidades e sua imaginação. Tenho visto sistemas bem elegantes definidos apenas pelo uso de SQL e WSH ou HTA — que são habilidades relativamente fáceis para alguém aprender. É muito importante, no entanto, ter em mente as restrições mencionadas em colunas anteriores:
  • O Windows PE não apresenta o subsistema WOW (Windows no Windows), então você precisa compilar uma vez para cada arquitetura que pretende suportar.
  • Você não pode usar o Visual Basic 6.0 se precisa implantar o Windows PE via x64 ou IA64.
  • Você pode usar o Visual Studio 2005 ou 2008 para compilar aplicativos, mas deve compilar um aplicativo do Visual C++ não-gerenciado, uma vez que o Microsoft .NET Framework — qualquer versão — não é suportado no Windows PE.
  • Sem um .NET Framework, você também não pode usar o Windows PowerShell para automação.
Você pode, é claro, usar um utilitário de imagens de terceiros via WDS também, se quiser escrever sua própria experiência de configuração. Embora eu ache que os formatos WIM e ImageX possam atender à maioria dos cenários de implantação, podem existir certos requisitos que sua ferramenta de imagens existente atende para você.
Da mesma forma, certos cenários podem exigir um particionamento personalizado — você pode estar implantando o Windows Vista com BitLocker, ou compilando sistemas do Windows XP e armazenamento dados de perfis em um segundo volume, ou talvez você esteja implantando um sistema do Windows Server e deseje criar um volume separado no mesmo disco para registro. Qualquer uma dessas opções requer automação de DiskPart, que, como nas versões anteriores, pode ser feita pela alimentação de um script (qualquer formato de arquivo) no DiskPart que contenha os comandos que você deseja executar e termine com exit (sair) — para encerrar o DiskPart.
Criar sua própria experiência de configuração não é para os medrosos, uma vez que você está basicamente recompilando o executável de configuração (ou pelo menos espelhando sua funcionalidade) e pode haver muito a se projetar e compilar. Mas tudo se reduz a quanta funcionalidade você deseja compilar nele por padrão e em que você está compilando (HTA ou WSH ou uma linguagem de programação compilada).

Servidor de transporte
Se não estiver usando a maior parte da funcionalidade nativa no WDS (como o Active Directory) ou estiver projetando sua própria solução personalizada completa, o servidor de transporte pode atender suas necessidades e não apresentar requisitos que você não deseja. A tabela da Figura 2 (reproduzida de "Utilizando o servidor de transporte" em go.microsoft.com/fwlink/?LinkID=115298) descreve o que está incluído como parte da função do servidor de transporte do WDS.
Figura 2 Servidor de implantação versus Servidor de transporte
 | Servidor de implantação | Servidor de transporte
Requisitos do servidor | Requer ADDS (serviços de domínio do Active Directory), DHCP (protocolo de configuração de host dinâmico) e DNS (sistema de nome de domínio) no ambiente. | Não requer outros servidores no ambiente.
PXE | Suporta inicialização PXE com o provedor de PXE padrão. | Um provedor de PXE não está instalado, então você deve criar um provedor de PXE personalizado.
Servidor de imagem | Inclui o servidor de imagem dos serviços de implantação do Windows. | Não inclui o servidor de imagem dos serviços de implantação do Windows.
Método de transmissão | Permite unicast e multicast. | Permite apenas multicast.
Ferramentas de gerenciamento | É gerenciado usando o snap-in MMC dos serviços de implantação do Windows ou a ferramenta de linha de comando WDSUTIL. | É gerenciado apenas pela ferramenta de linha de comando WDSUTIL.
Aplicativo no computador do cliente | Usa o cliente dos serviços de implantação do Windows (que é basicamente Setup.exe e arquivos de suporte), Wdsmcast.exe (incluído no Windows AIK) ou um aplicativo de multicast personalizado. | Usa apenas Wdsmcast.exe ou um aplicativo personalizado.
Quando digo que o servidor de transporte é um item complicado a implementar, não é a função em si que é difícil; essa, é claro, é facilmente implantada (veja a Figura 3). É a implementação da configuração personalizada ao redor do servidor de transporte que requer trabalho. Usar a função de servidor de transporte remove com eficiência a maior parte da facilidade de uso incorporada ao WDS como uma função.
Figura 3 O servidor de transporte pode ser útil para cenários de implantação personalizados (clique na imagem para ampliá-la)

Multicast personalizado
Esteja você usando ou não a função de servidor de transporte — mas especialmente se estiver — há um ótimo exemplo a ser feito usando multicast se você estiver fazendo uma implantação de vários sistemas. O ADS apresenta um recurso de multicast muito eficiente, que você pode duplicar usando o WDS com multicast. O WDS apresenta em si o multicast, mas se você estiver compilando sua própria solução personalizada, poderá aproveitar o multicast usando WDSMCast, como mencionei mês passado (veja a Figura 4). Lembre-se de que você precisa transferir o(s) arquivo(s) de imagem a ser(em) implantado(s) e, em seguida, eles devem ser aplicados. Geralmente, isso significa que você precisa de espaço em disco local suficiente para a imagem ser armazenada e, em seguida, aplicada.
Figura 4 Executando o WDSMCast (clique na imagem para ampliá-la)

Conclusão
O WDS proporciona uma eficiência significativa em si só — provavelmente suficiente para várias organizações atenderem suas necessidades. Mas se você estiver procurando compilar sua própria solução que vá além dos limites do WDS, poderá certamente fazê-lo — você é limitado apenas pela sua imaginação, seu cronograma e suas habilidades.

Wes Miller é gerente sênior de produto técnico da CoreTrace (CoreTrace.com), em Austin, no Texas. Anteriormente, ele trabalhou na Winternals Software e como gerente de programa da Microsoft. Entre em contato com ele pelo email technet@getwired.com.


Security Watch Revisitando as 10 leis imutáveis da segurança, parte 1
Jesper M. Johansson

Em 2000, Scott Culp publicou um ensaio chamado "10 leis imutáveis da segurança". É um dos melhores ensaios que eu já li sobre segurança. As informações que ele apresentou continuam fundamentais para todo trabalho em segurança de informações e eu recomendo que você o confira (e até mesmo imprima), se ainda não o tiver feito. Você pode encontrá-lo em microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx.
O ensaio foi recebido com respostas variáveis. Algumas pessoas comentaram de modo sarcástico que era uma maneira de a Microsoft evitar corrigir aquilo que era percebido como vários problemas sérios. Outros o consideraram um dos textos mais básicos sobre segurança e o plagiaram à vontade devido à sua importância absoluta. Algumas das minhas respostas favoritas, no entanto, eram aquelas nas quais as pessoas foram inspiradas a criar suas próprias listas, como a que está disponível em edgeblog.net/2006/10-new-immutable-laws-of-it-security.
Nos oito anos, desde que esse ensaio foi publicado, muito aconteceu no campo da segurança. Praticamente todos os principais worms foram “lançados”. Entramos em um estado de guerra de informações (com crime organizado, entidades políticas e assim por diante). Uma variedade de palavras e expressões se tornou parte de um vocabulário comum, incluindo phishing, pharming, botnet, spyware e falsificação de solicitação entre sites. Temos alguns dos rootkits mais sofisticados já criados em execução no Windows. Temos novas versões de sistemas operacionais dedicadas, em grande parte, à segurança e outros sistemas operacionais onde a segurança ainda é amplamente ignorada.
A engenharia social se desenvolveu em uma ameaça maior. Violações de dados, como quando um importante varejista expôs 94 milhões de números de cartões de crédito, se tornaram notícias bem conhecidas (e, ainda, as pessoas continuam comprando em tais lojas). Os governos dos EUA e do Reino Unido, em conjunto, conseguiram guardar em lugares errados informações secretas sobre uma porcentagem significativa dos habitantes do mundo ocidental (e, ainda, as pessoas arquivam informações secretas com esses governos). E uma quantidade enorme do espetáculo da segurança entrou em nossas vidas — e em nossos aeroportos.
Acho que chegou a hora de dar uma outra olhada nas leis. Supondo que todas as alterações que vimos surgiram a primeira parte deste século, podemos ainda alegar que essas leis são imutáveis? Se forem — se sobreviveram nos últimos 8 anos — é provavelmente seguro dizer que elas irão sobreviver nos próximos 10.
Nessa série de três partes, examinarei de forma crítica cada uma dessas 10 leis. Neste mês, falarei das leis de 1 a 3. Na edição do próximo mês, irei examinar as leis de 4 a 7. E na última parte, irei examinar as leis de 8 a 10 e oferecer um assunto adicional para se pensar, além de comentários que parecem razoáveis, levando-se em consideração o que ocorreu desde que as leis foram originalmente escritas em 2000.
Lei 1: Se uma pessoa mal-intencionada conseguir persuadi-lo a executar um programa em seu computador, o computador não é mais seu.
Essa lei afirma, efetivamente, que qualquer software que você execute no computador pode controlar esse computador. Quando as leis imutáveis surgiram pela primeira vez, os sistemas operacionais atuais da Microsoft eram o Windows 98, Windows Me e Windows NT 4.0. Hoje, temos o Windows Vista e o Windows Server 2008.
No Windows 98 e Windows Me, qualquer software que você executava tinha controle total sobre o computador. O Windows NT 4.0 possuía um modelo de segurança subjacente muito sólido, mas se você o executasse como Administrador, você, efetivamente, fazia o downgrade de seu modelo de isolamento para o do Windows 98 e Windows Me. Era possível executar o Windows NT 4.0 como não-administrador, mas era bem penoso e pouquíssimas organizações o faziam (você provavelmente conseguiria contar o número total de organizações que faziam isso sem tirar seus sapatos).
Digamos que você executasse o Windows NT 4.0 como não-administrador. Então, a Lei 1 se aplicava mesmo quando foi escrita? A resposta é sim. Primeiro, o Windows NT 4.0 tinha um grande número de brechas significativas. Por exemplo, havia permissões que poderiam ter sido mais rígidas, particularmente em objetos do kernel e no Registro. Também existiam vários tipos de ataques que ainda não haviam sido descobertos, mas que os especialistas esperavam que fossem emergir. Por exemplo, em 1999, as pessoas não haviam percebido que ter processos em execução como usuários elevados na área de trabalho interativa poderia comprometer o computador. Somente em 2002, quando Chris Paget publicou seu white paper sobre ataques shatter, "Explorando a API Win32", que isso se tornou um conhecimento básico (seclists.org/bugtraq/2002/Aug/0102.html).
A Microsoft havia previsto os ataques shatter quando a Lei 1 foi esboçada? Na verdade não. A Microsoft simplesmente reconheceu um simples fato: existem pouquíssimos limites de segurança verdadeiros que podem impedir que um aplicativo em execução em um computador assuma o comando desse computador.
O Windows Vista e Windows Server 2008 são duas gerações removidas do Windows NT 4.0. Eles invalidaram a Lei 1? Existe algum outro sistema operacional que o fez? Depende. Certamente, existem limites de segurança mais sólidos nos novos sistemas operacionais e existiam alguns sistemas operacionais experimentais em 2000 que possuíam limites de segurança adequados. No entanto, ainda existem apenas alguns desses limites. Por exemplo, a segurança de acesso ao código no Microsoft .NET Framework é um limite de segurança. Ela é projetada especificamente para impedir que o código em execução na área de segurança afete o sistema operacional subjacente.
O Iframes no Internet Explorer proporciona outro limite de segurança. Mas o Iframes não afeta o acesso ao sistema operacional em si, apenas o acesso entre partes de conteúdo em uma página da Web. O Modo Protegido no Internet Explorer, mostrado na Figura 1, é um limite de segurança de nível de sistema operacional. Seu objetivo é impedir que códigos executados em um navegador afetem o sistema operacional subjacente — sem a ação do usuário. Existem alguns outros, como contas de usuário padrão, que devem impedir que uma conta de usuário afete o sistema operacional subjacente ou qualquer outro usuário.
Figura 1 O Internet Explorer 7 usa um limite de segurança chamado Modo Protegido (clique na imagem para ampliá-la)
É extremamente importante entender o que significa o termo "limite de segurança". Ele não significa que existe uma parede inviolável com garantia de fornecimento de um isolamento impermeável e indefinido. O que o termo realmente significa é que o fornecedor de software, a Microsoft por exemplo, é responsável por corrigir qualquer violação desse limite por meio de um patch de segurança. O software sempre terá bugs e, sem dúvida, continuaremos descobrindo mais violações que os fornecedores de software continuarão consertando. Com o tempo, eles devem melhorar seu software para impedir essas vulnerabilidades, em primeiro lugar. Isso pode ser considerado como confirmação de que a Lei 1 ainda é válida.
Existe uma parte mais crucial que preciso considerar, no entanto. Você pode ter observado anteriormente a expressão "sem a ação do usuário". A Lei 1 não é, na verdade, sobre limitações ou vulnerabilidades no software. Ela é, realmente, sobre vulnerabilidades nas pessoas! A expressão-chave é "persuadi-lo". Se uma pessoa mal-intencionada conseguir persuadi-lo a executar um programa, ele provavelmente conseguirá persuadi-lo a fazê-lo em um contexto que, intencionalmente, dá ao programa privilégios elevados.
Mesmo se você não possuir privilégios administrativos, pode não importar. Você, como usuário padrão, ainda tem acesso a muitas informações interessantes: seus arquivos de banco, cartas de amor, fotos, vídeos e dados confidenciais da empresa. Todos esses dados são potencialmente interessantes para um invasor e todos eles podem ser lidos sem qualquer privilégio elevado. Em termos das informações que você gerencia no seu computador, executar um programa mal-intencionado entrega tudo o que você faz ao invasor. Portanto, se você define "seu computador" como "os dados que você gerencia no seu computador", você pode ignorar qualquer discussão sobre privilégio e simplesmente concluir que a Lei 1 se aplica.
Mesmo sem discutir minuciosamente a definição de seu computador, a Lei 1 ainda parece ter resistido ao teste do tempo. A finalidade da Lei 1 é estabelecer o fato que você, como operador de um computador, deve assumir a responsabilidade pelo software que executa nesse computador. Se você instala um driver mal-intencionado ou um codec de vídeo perigoso, você entregou o controle completo desse computador a um criminoso!
Embora os fornecedores de software possam fazer muitas coisas para impedir um comprometimento acidental, que é, na verdade, ao que se resumem os limites de segurança, a execução intencional de software mal-intencionado irá geralmente superar todas essas medidas de proteção. É por isso que a educação do usuário é crucial, além de garantir que os usuários não tenham permissão de executar tarefas administrativas. Portanto, é seguro dizer que a Lei 1 se aplica hoje, mas possivelmente com uma leve modificação na definição de seu computador.
Lei 2: Se uma pessoa mal-intencionada conseguir alterar o sistema operacional em seu computador, o computador não é mais seu.
À primeira vista, essa lei parece bem direta. Obviamente, se a pessoa mal-intencionada conseguir alterar o sistema operacional em seu computador, você não pode mais confiar no computador. Mas o que se entende por sistema operacional mudou, à medida que as necessidades de computação se desenvolveram. Vários anos atrás, escrevi uma definição do termo “sistema operacional” para a enciclopédia de gerenciamento Blackwell (managementencyclopedia.com). A definição dizia algo sobre um sistema operacional gerenciando acesso a dispositivos de entrada e saída, acesso a hardware e essas coisas. Bem, nunca recebi uma cópia da enciclopédia e meu envio original foi perdido na história, mas estou certo de que não mencionei que um sistema operacional inclui paciência, um sistema de entrada para tablet e transcodificadores de vídeo.
Como a computação tem aumentado e ficado cada vez mais complexa, os sistemas operacionais cresceram para suportar muito mais recursos. Complicando ainda mais a questão, os OEMs muitas vezes incluem sua própria variedade de softwares adicionais — que normalmente varia de um pouco útil a totalmente prejudicial. E alguns desses softwares adicionais duplicam funcionalidades já existentes no sistema operacional principal.
Por exemplo, uma instalação padrão do Windows Server 2008 Enterprise Edition possui uma superfície de disco de mais de 5 gigabytes. O Windows Vista Ultimate Edition inclui mais de 58.000 arquivos, compreendendo mais de 10 gigabytes. E há mais do que apenas arquivos formando o sistema operacional. Existem configurações, milhares delas; e existem daemons ou serviços.
Todo e qualquer item desses faz parte do sistema operacional. É um termo coletivo que inclui todos os arquivos, todas as definições de configuração e todos os serviços, bem como todos os objetos de runtime — semáforos, pipes nomeados, pontos de extremidade RPC — criados pelos arquivos e configurações. Mesmo as construções altamente abstratas, como o tempo do sistema e certos tipos de dados, como conteúdo de log de evento, devem ser considerados como parte do sistema operacional.
Dado como o sistema operacional cresceu e se desenvolveu, modificar qualquer um desses arquivos realmente faz com que o computador não seja mais confiável? A resposta direta é não. Por exemplo, o Windows Vista vem equipado com edlin.exe, o antigo editor de linha do MS-DOS. Não posso dizer com certeza, mas eu apostaria um moca triplo grande que o edlin.exe apenas foi invocado duas vezes em todas as cópias instaladas do Windows Vista desde que o sistema operacional foi lançado. As duas vezes foram aproximadamente três minutos atrás, quando eu estava tentando lembrar a sintaxe. Se alguém modifica edlin.exe ou algum outro arquivo que ninguém nunca usa, realmente significa que ele não é mais o seu computador?
O arquivo edlin.exe é, indiscutivelmente, parte do sistema operacional, mas se ninguém jamais executar o arquivo, como uma modificação nele irá resultar no comprometimento do seu computador? A resposta, é claro, é que não irá. Modificar uma parte do sistema operacional que nunca é usada não comprometerá seu computador. E existem várias partes do sistema operacional que nunca são usadas.
A resposta indireta, no entanto, é sim. Você não pode simplesmente observar se alguém executa um arquivo para ver se a modificação pode resultar em um comprometimento do seu computador. O problema é mais sutil que esse. Dê uma olhada na ACL (lista de controle de acesso) para edlin.exe, exibida na Figura 2.
Figura 2 A ACL para edlin.exe é muito restritiva (clique na imagem para ampliá-la)
A ACL para edlin.exe é muito restritiva. Apenas o serviço TrustedInstaller possui direitos para modificar esse executável. Isso é muito importante: significa que existe um efeito indireto para uma pessoa mal-intencionada modificar esse arquivo no seu computador. O ato de modificar o edlin.exe significa que não é mais o seu computador. É o fato de que o usuário mal-intencionado possui a habilidade de modificar o edlin.exe que é chave aqui. Se a pessoa mal-intencionada consegue modificar esse arquivo, ela poderá modificar qualquer arquivo, o que significa que você não pode mais confiar em nada do computador.
O sistema operacional irá se proteger. Os serviços são protegidos de modificação não autorizada. As configurações são protegidas de modificação não autorizada. Os arquivos no disco são protegidos contra modificação não autorizada. Até mesmo os semáforos e os pontos de extremidade RPC usados pelo sistema operacional são protegidos contra modificação não autorizada. Se um invasor conseguir modificar qualquer um desses objetos protegidos, ele poderá modificar todos eles e, muito possivelmente, já o fez.
Esse é um ponto crítico. Com várias das leis imutáveis, não é o ato de fazer algo que significa que seu computador está comprometido. O que importa somente é que alguém possui a capacidade de fazer algo. Esse é um ponto que não deve passar despercebido. Em todos os aspectos da segurança do computador, você sempre deve se lembrar de que a capacidade é, freqüentemente, muito mais importante do que a ação realmente executada.
Se um computador está exposto à Internet e fica sem correções durante meses, ele ainda é confiável? Não. Esse computador deve ser considerado comprometido. Você simplesmente não pode confiar em nada em um sistema que poderia ter sido comprometido. (Eu disse exatamente isso cinco anos atrás no meu artigo "Socorro! Meu computador foi atacado. E agora, o que eu faço?" disponível em technet.microsoft.com/library/cc512587.) Se estiver lidando com um adversário habilidoso, um sistema comprometido pode nem mesmo mostrar sinais de que está comprometido. O sistema pode parecer perfeitamente normal.
Sem dúvidas, a Lei 2 ainda se aplica. Se um invasor tem a habilidade de modificar qualquer objeto protegido no seu computador, ele não é mais seu computador. Apenas lembre-se, é a capacidade de modificar esses objetos que importa, e não se ele realmente foi atacado.
Lei 3: Se uma pessoa mal-intencionada tiver acesso físico irrestrito ao seu computador, o computador não é mais seu.
Essa lei foi crucial em 2000. Um grande número de pessoas não entendia completamente o que era possível fazer com o acesso físico a um sistema. Na verdade, até mesmo algumas agências do governo que deveriam saber muito mais falharam em compreender esse ponto fundamental. Naquele momento, a orientação de segurança recomendava configurar a opção Permitir encerramento sem logon como desabilitada. Isso faz com que o botão Desligar… na tela de logon fique esmaecido. A teoria por trás disso era que para desligar o computador, o usuário precisa primeiro fazer o logon para que houvesse um registro de auditoria de quem desligou o sistema.
Esse é um estudo de caso em um pensamento com falhas. Para ter acesso ao botão Desligar… na tela de logon, você realmente precisa sentar no console. E se você está sentado no console e realmente deseja desligar o computador, pode normalmente usar aquele grande botão redondo na frente do computador — ou até mesmo o cabo de alimentação. Sistema desligado. Sem trilha de auditoria.
O Windows 2000 inclui uma configuração de segurança chamada “permitir desencaixe sem fazer logon” e essa opção ainda está disponível no Windows Vista, como exibido na Figura 3. O princípio era o mesmo. Para desencaixar um laptop de sua base de encaixe, é necessário primeiro fazer logon no sistema.
Figura 3 Por que você não furtaria o computador e o encaixe? (clique na imagem para ampliá-la)
O valor de segurança real dessa configuração é extremamente duvidoso. Eu acho que a teoria era que se simplesmente qualquer pessoa pudesse ir até o laptop e desencaixá-lo, alguém poderia facilmente roubar o computador. Bem, não que eu algum dia roubaria um laptop, mas se eu fosse fazê-lo, essa medida preventiva não me deteria. Eu provavelmente agarraria o laptop e a base de encaixe juntos como um único pacote. Quer saber? Eu também roubaria o cabo de rede e o cabo de alimentação. Isso é que é um ajuste de segurança insignificante!
O problema do acesso físico realmente tocou em um ponto vulnerável quando Petter Nordahl-Hagen criou sua Senha Offline do NT e o Editor do Registro. Sua criação foi simplesmente um disco de inicialização do Linux com um driver de sistema de arquivos NTFS experimental que permitia acesso de leitura e gravação a um volume NTFS. O software no disco de inicialização montaria o Registro na máquina local e escreveria uma nova senha para a conta do Administrador no hive do SAM (gerenciamento de ativos de software). Tudo o que você precisava era acesso físico ao sistema e um ou dois minutos.
Ferramentas como essa são exatamente o porquê de a Lei 3 ter sido escrita, em primeiro lugar. Na verdade, a ferramenta de Nordahl-Hagen foi usada em várias demos. Infelizmente, o caso nunca conseguir chegar à maioria dos públicos. Eu pessoalmente usei a ferramenta em algumas demos, mas parei de usá-la após ficar cansado por me perguntarem: "Como podemos ter certeza de que nenhum dos nossos usuários conhece ferramentas como essa?" e "O que a Microsoft está fazendo para corrigir esse problema?". Uma parte alarmantemente grande da indústria de TI não queria aceitar ou entender que o acesso físico superaria tudo.
Naquele ambiente, a Lei 3 era uma instrução muito importante. Ainda assim, os críticos a atacaram sem piedade. Ela foi ridicularizada como uma tentativa da Microsoft de evitar ter que corrigir qualquer problema que poderia, até mesmo da maneira mais remota, ser vinculado ao acesso físico. A Lei 3 foi na verdade usada em vários casos para ignorar relatórios de vulnerabilidade, incluindo o golpe da Senha Offline do NT e do Editor do Registro. No entanto, bloquear os invasores que possuem acesso físico ao sistema apenas é realmente possível de uma maneira: garantindo que eles não consigam chegar a lugar algum.
É aqui que reside a possível fenda na armadura de Lei 3. Desde que as leis foram escritas, a tecnologia de criptografia de disco completa se tornou uma solução viável. Com criptografia de disco rígido completa, ou com um termo mais correto, criptografia de volume total, um volume inteiro (conhecido como partição nos outros sistemas operacionais) pode ser criptografado. Então, se todo o volume de inicialização (em outras palavras, o volume com o sistema operacional nele) está criptografado, a pergunta que precisamos fazer é: a Lei 3 ainda se aplica?
A resposta é um firme provavelmente. Primeiro, as chaves de descriptografia precisam ser armazenadas em algum lugar. O local mais simples para colocar as chaves, e a opção padrão no BitLocker, é em um chip Trusted Platforms Module no computador. Fazendo isso, o computador será inicializado de modo autônomo. Depois que o computador for iniciado, um invasor engenhoso e bem fundamentado com controle físico permanente sobre o computador poderá atacá-lo de várias maneiras. Como o computador pode ser conectado agora a uma rede arbitrária, podem existir maneiras relacionadas à rede de atacar o sistema.
O invasor pode, por exemplo, ler ou gravar memória por meio de um dispositivo DMA (acesso direto à memória), como uma unidade flash USB. Depois que o computador estiver em execução, encerram-se todas as apostas quando se trata de um invasor com acesso físico àquele computador.
Se as chaves não forem armazenadas no computador em si, o ataque então dependerá se o invasor pode obter ou adivinhar as chaves. Se um código PIN for usado para inicializar o computador, o invasor pode provavelmente adivinhar o código com relativamente pouco esforço. Se as chaves forem armazenadas ou derivadas de um dispositivo de hardware separado, como uma unidade flash USB ou um fob de senha única, o invasor deverá ter acesso a esse dispositivo separado. Certamente existem maneiras de se obter essas teclas ou tornar a vida mais desconfortável para a pessoa com acesso a elas, embora o esforço necessário seja provavelmente um pouco maior.
Você também poderia interpretar a Lei 3 de uma maneira levemente diferente: "Se o invasor possui acesso físico ao seu computador, é provável que o computador tenha sido roubado e, portanto, é improvável que você consiga recuperá-lo." Dessa perspectiva, ele realmente não é mais o seu computador. E de outra perspectiva, pode não importar ao invasor se ele pode acessar os dados no seu computador ou não. No entanto, esse realmente não é do que trata o espírito da Lei 3. Ele significava que o invasor tinha acesso aos dados no seu computador e não apenas ao computador em si.
Com tudo considerado, a Lei 3 ainda se aplica. É verdade que certas tecnologias disponíveis hoje percorrem um longo caminho em direção a parar vários invasores com acesso físico e, portanto, minimizar o número de invasores capazes de acessar dados em um computador que emprega uma medida de segurança. Isso dito, os recursos do invasor sempre definem quanto o invasor realmente pode atingir e novas tecnologias resolvem várias das 10 leis imutáveis — até uma parte. Mas o acesso físico ainda oferece maneiras, embora mais complexas, de entrar em um sistema.
Até agora, as leis imutáveis de segurança estão se provando bastante resistentes, em relação a avanços tecnológicos e ao tempo. Das 3 primeiras, a Lei 3 está no plano mais instável, ainda assim, até mesmo ela se aplica em alguns casos. Ela é, no entanto, a que possui as mitigações eficientes e mais prontamente disponíveis no lugar. Voltarei nas duas próximas edições da TechNet Magazine para continuar essa discussão e determinar se as Leis de 4 a 10 ainda não imutáveis.

Jesper M. Johansson é arquiteto de software e trabalha na segurança de software, além de ser editor colaborador da TechNet Magazine. Ele é Ph.D. em sistemas de informações sobre gerenciamento, tem mais de 20 anos de experiência em segurança e é MVP (Most Valuable Professional) da Microsoft em segurança corporativa. Seu livro mais recente é o Windows Server 2008 Security Resource Kit.


Anotações de campo Código de barra colorido de alta capacidade
Gavin Jancke

Estamos todos tão familiarizados com códigos de barra que eles muitas vezes passam despercebidos — são quase onipresentes na vida diária, aparecendo em todos os lugares de embalagens de produtos a etiquetas de transporte. Os códigos barra originais unidimensionais que apareceram na indústria do varejo em 1974 compreendiam barras verticais de larguras variáveis e armazenavam um número de 12 dígitos. Os códigos de barra se desenvolveram à medida que a eficiência da computação aumentou e códigos de barra bidimensionais em preto-e branco (códigos de matriz) foram desenvolvidos no final dos anos 80, marcando o aumento na densidade de dados de apenas alguns dígitos a algumas centenas de bytes.
Em 2003, comecei a trabalhar em uma placa de identificação biométrica à prova de falsificações como um projeto para a Divisão de Pesquisa da Microsoft. Eu precisava armazenar não apenas o texto criptográfico, como nome e idade, mas também modelos de escaneamento da íris ou leitura de impressão digital. Para armazenar todos os dados necessários, o código de barra existente em preto-e-branco teria sido maior que a própria placa de identificação, então claramente uma nova abordagem era necessária.
Eu precisava determinar como armazenar mais de um bit de informações por símbolo, o que era o padrão para códigos de barra bidimensionais em preto-e-branco. Usando cores, em vez do preto-e-branco, eu poderia aumentar isso para dois ou três bits de dados usando quatro e oito cores, respectivamente.
Também experimentei com as formas de símbolos para ver se elas poderiam ser empacotadas juntas mais firmemente sem comprometer seu registro ao serem escaneadas. Inicialmente, hexágonos pareciam uma boa possibilidade, mas as formas se fundiam e o computador não conseguia discerni-las de modo claro o suficiente.
Finalmente, eu me decidi por triângulos porque eles se cruzam de modo organizado em um espaço compactado, mas mantêm sua identidade como formas distintas. Ao usar linhas de triângulos em várias cores, eu poderia aumentar o recurso de densidade em 3D.
Havia muitas variáveis com as quais argumentar. Um dos maiores desafios de se trabalhar com cores é a variação nas especificações de impressão e nas condições de iluminação. Embora as cores possam ser facilmente discerníveis para o olho humano (pelo menos para os que não são daltônicos), elas não são tão claramente discerníveis para um computador.
Usei várias abordagens diferentes para garantir que o software poderia ler as cores com precisão. Criei uma paleta muito pequena, quase imperceptível no código de barras que continha as cores de referência que existiam no código de barras real. Isso proporcionou um mecanismo de calibração que especificava exatamente o que constitui um determinado vermelho, por exemplo. Também tentei técnicas mais avançadas, como algoritmos de agrupamento de cores simples e personalizadas que aproveitam a teoria de espaço de cores para categorizar as cores em conjuntos. As duas abordagens funcionam igualmente bem e se complementam.
Um dos meus objetivos para esse projeto era escrever um programa que permitiria a telefones celulares lerem os códigos de barra. Com os celulares, deve-se considerar a iluminação ruim e as lentes fora de foco, fixas, de tamanho focal. Um desafio adicional era executar toda essa visão do computador em CPUs de celulares relativamente lentas, baseadas em inteiros. Então a equipe precisava apresentar uma teoria um tanto sólida sobre como detectar o código de barra na imagem, tocando o menor número possível de pixels. O escaneamento precisava funcionar dentro de um intervalo de qualidades de leitura, como painéis LCD claros em foco a impressão física fora de foco com pouca iluminação.
O algoritmo final decodifica as imagens do código de barra em quadros de vídeo de câmera em tempo real mais rapidamente do que a taxa de quadros real — aproximadamente 10 ms em uma CPU de 200 Mhz. Em uma imagem, o menor número de pixels que um código de barra pode ter para a menor carga de dados, e ainda ser detectado, é de aproximadamente 45 pixels quadrados.
Todo esse trabalho, sob condições variáveis, levou mais de dois anos para ser refinado. Essa tecnologia foi recentemente licenciada a terceiros e, no final desse ano, haverá alguns aplicativos interessantes provenientes dela.
Gavin Jancke, diretor de engenharia da Divisão de Pesquisa da Microsoft, conduz as equipes de Grupo de Desenvolvimento Avançado e Experiência da Web. Anteriormente, ele trabalhou como engenheiro de suporte a produtos, engenheiro de software do SQL Server e trabalhou na equipe de consultoria técnica-executiva do Bill Gates.


Segredos do Windows Trabalhe mais, com menos inteligência
Raymond Chen

Para os desenvolvedores de software, um dos grandes benefícios do Relatório de Erros do Windows é que eles podem obter informações do mundo real sobre as falhas dos seus programas. Esses relatórios de erros estão disponíveis a qualquer fornecedor de software que se registre online em winqual.microsoft.com. Certamente, é possível executar todos os tipos de testes nos laboratórios, mas sempre existe uma lacuna entre as condições do laboratório e as condições do mundo real. Isso pode resultar em bugs que jamais aparecem no teste, mas que enlouquecem os clientes.
Há alguns anos, um programador me contou uma história de que tinha recebido uma tarefa da equipe de confiabilidade do produto. A equipe queria corrigir os principais motivos de falhas e paradas de um determinado componente. Depois de alguma negociação, ambas as partes chegaram a um objetivo de reduzir o número desses tipos de falhas pela metade. Ela queria corrigir bugs responsáveis por pelo menos 50 por cento das falhas e das paradas nesse componente, conforme medição feita pelo Relatório de Erros do Windows.
Todos nós sabemos que as falhas não estão distribuídas de maneira uniforme. Algumas são raras, outras são comuns e ainda existem as inesperadas (em termos relativos). Engenharia é um jogo de compromissos; dados recursos limitados (tempo, dinheiro, idéias), você precisa dedicá-los onde eles terão o melhor efeito. Como o objetivo aqui era reduzir o número de falhas e paradas, a abordagem apropriada era estudar as falhas mais comuns informadas pelo Relatório de Erros do Windows, compreender as causas principais e, em seguida, tentar corrigir essas falhas comuns.
O Relatório de Erros do Windows fornece informações do mundo real sobre falhas de programas (Clique na imagem para ampliá-la)
Quando o programador pesquisa os dados da falha, fica claro que cinco falhas e paradas específicas foram responsáveis por mais de 60 por cento dos relatórios. Se pudesse corrigir os bugs que estavam causando essas cinco falhas, o programador reduziria 2,5 vezes o número de falhas e paradas, bem acima das 2 vezes desejadas.
A análise dos dados do Relatório de Erros do Windows feita pela própria Microsoft mostra que o princípio de Pareto é, surpreendentemente, uma ótima regra prática para falhas e paradas do Windows; cerca de 20 por cento dos bugs causam 80 por cento das falhas. O mesmo estudo revelou um resultado ainda mais surpreendente: apenas 1 por cento dos bugs causa 50 por cento dos erros. Nem todos os bugs são criados da mesma forma, mas conhecer o grau de incidência da distribuição ajuda muito a manter os olhos abertos.
Depois de estudar essas cinco falhas mais atentamente, o programador conseguiu perceber que todas elas tinham a mesma causa principal. As falhas e as paradas eram apenas manifestações diferentes do mesmo bug subjacente. Assim, ele desenvolveu e testou uma correção e, com o pessoal do controle de qualidade, deu os primeiros passos para incluí-la no próximo patch. Com a correção desse único bug, a taxa teórica de falhas do componente caiu instantaneamente 2,5 vezes. A missão foi cumprida com uma única correção bem simples do código.
Quando ouvi essa história, fiquei surpreso pela curva de distribuição do erro do componente ser ainda mais acentuada do que a do Windows. Bem mais da metade de todas as falhas e paradas foi causada por um único bug. Trata-se do tipo de informação no código que não é possível sem que os dados sejam coletados por algo como o Relatório de Erros do Windows.
Você pensaria: a equipe de confiabilidade ficou maravilhada ao atingir o objetivo tão rapidamente. A meta estabelecida foi superada em apenas duas semanas com uma única correção. Na verdade, ela ficou furiosa.
"Isso é inaceitável – esperávamos que isso demorasse dois meses. Foi muito fácil!" Aparentemente, ela queria que o programador trabalhasse mais, com menos inteligência.
O site do Raymond Chen, The Old New Thing, e o livro homônimo tratam do histórico do Windows e da programação Win32. Vinte por cento das suas roupas são responsáveis por oitenta por cento da sua lavanderia.