Cobertura especial: Windows Server 2008

Por dentro das alterações no kernel do Windows Server 2008

Mark Russinovich

 

Visão geral:

  • Gerenciamento de memória e o SMB 2.0
  • Auto-recuperação do NTFS, Arquitetura de Erro de Hardware do Windows e o verificador de driver
  • Escalabilidade com portas de conclusão de E/S, pools de threads e NUMA
  • Virtualização com o Hyper-V

O Windows Server 2008 é a versão mais recente da plataforma de servidores da Microsoft e inclui alterações no nível do sistema que abrangem toda e qualquer área funcional do sistema operacional, de gerenciamento de memória

a agendamento de threads, de sistema de redes a segurança, só para citar alguns.

Como o Windows Server® 2008 compartilha o kernel com o Windows Vista® SP1, ele possui muitos dos aprimoramentos que abordei em meus artigos anteriores da TechNet Magazine: "Dentro do kernel do Windows Vista", partes 1 a 3 (fevereiro, março e abril de 2007) e "Por dentro do UAC (Controle de Conta de Usuário) do Windows Vista" (junho de 2007). Apenas uma minoria dos recursos descritos nesses artigos são exclusivamente focados no cliente e não estão incluídos no Windows Server 2008, como SuperFetch, ReadyBoost, ReadyDrive, ReadyBoot e o MMCSS (Serviço Agendador de Classes de Multimídia).

Em vez de repetir a cobertura das importantes alterações no kernel introduzidas no Windows Vista que também estão no Windows Server 2008 (como priorização de E/S, a nova arquitetura de inicialização, BitLockerTM, integridade do código e níveis de integridade obrigatórios), vou me concentrar nas principais alterações que não abordei nesses artigos, como as relacionadas a confiabilidade, desempenho e escalabilidade, além da nova tecnologia de virtualização de computadores com hipervisor, o Hyper-VTM.

Além disso, assim como nos anteriores, o escopo deste artigo está restrito ao kernel do sistema operacional, Ntoskrnl.exe, e aos componentes do sistema estreitamente relacionados a ele. Ele não aborda alterações na instalação (Serviço Baseado em Componente e WIM – Windows® Imaging Format), no gerenciamento (aprimoramentos na Diretiva de Grupo e no Active Directory®), no monitoramento e diagnóstico geral (Infra-estrutura de Diagnóstico do Windows), no sistema de rede básico (implementação de TCP/IP e o novo firewall), no Núcleo do Servidor ou nas Funções do Servidor, por exemplo.

Trabalhando em sistemas multiprocessadores

Uma das alterações de baixo nível no sistema é que o Windows Server 2008 só inclui uma versão do kernel projetada para trabalhar em sistemas multiprocessadores. Antigamente, o Windows usava uma versão específica para uniprocessadores em computadores com uma única CPU porque essa versão podia alcançar um desempenho ligeiramente melhor omitindo o código de sincronização necessário apenas em ambientes multiprocessadores. Como o hardware ficou mais rápido, o benefício das otimizações em termos de desempenho se tornou insignificante, e a maioria dos sistemas de servidor atuais inclui mais de um processador, tornando a versão com uniprocessador desnecessária.

A Figura 1 mostra as variantes do kernel do Windows Server 2008, em que a versão usada em um sistema dependerá dos seguintes fatos: se esta é a versão de depuração (verificada) ou comercial do sistema operacional, se a instalação é de 32 ou 64 bits (Itanium, Intel 64 ou AMD64) e, caso seja uma instalação de 32 bits, se o sistema tem mais de 4 GB de memória física ou é compatível com Prevenção de Execução de Dados (DEP). Espera-se que o Windows Server 2008 seja o último sistema operacional Windows Server a oferecer uma versão de 32 bits.

Figure 1 Variantes do kernel do Windows Server 2008

Kernel 32 bits 64 bits
Multiprocessador Sim Sim
Multiprocessador verificado Sim Sim
PAE (Extensões do Endereço Físico) do multiprocessador Sim Não
PAE do multiprocessador verificada Sim Não

Cada versão do Windows Server busca melhorar o desempenho dos principais cenários de servidor, como serviço de arquivos, E/S de rede e gerenciamento de memória. Além disso, o Windows Server 2008 tem várias alterações e recursos recentes que permitem que o Windows tire proveito das novas arquiteturas de hardware, se adapte a redes de alta latência e remova gargalos que restringiam o desempenho em suas versões anteriores. Esta seção analisa os aprimoramentos no gerenciador de memória, o sistema de E/S e a introdução de um novo sistema de arquivos de rede, o SMB 2.0.

Gerenciamento de memória

Experimento: ver grandes E/Ss de disco

Você pode usar uma ferramenta de monitoramento do sistema de arquivos como o Sysinternals Process Monitor da TechNet (technet.microsoft.com/sysinternals/bb896645.aspx) para procurar grandes operações de E/S de arquivos em um sistema Windows Server 2008.

Há várias formas de gerar grandes E/Ss. Se você tiver um segundo sistema com o Windows Vista Service Pack 1 ou o Windows Server 2008, poderá executar o Process Monitor no servidor e monitorar cópias de arquivos no segundo sistema. Normalmente, também é possível gerar grandes E/Ss de arquivo de paginação por meio da execução de um programa que demande muita memória e faça com que o gerenciador de memória grave páginas no arquivo de paginação.

A Figura A mostra o Process Monitor após a execução de um programa desse tipo em um sistema Windows XP, com a opção Enable Advanced Output (Habilitar Saída Avançada) marcada no menu Options (Opções) do Process Monitor e um filtro definido para só mostrar gravações no arquivo de paginação, pagefile.sys. A coluna Detalhe mostra que o tamanho das gravações é de 64 KB.

Figura A

Figura A  (Clique na imagem para aumentar a exibição)

Quando você executar as mesmas etapas no Windows Server 2008, provavelmente verá algo semelhante ao exibido na Figura B, que mostra a maioria das gravações com cerca de 1 MB de tamanho.

Figura B

Figura B  (Clique na imagem para aumentar a exibição)

O gerenciador de memória inclui várias melhorias de desempenho no Windows Server 2008. Por exemplo, ele emite E/Ss de disco maiores e em menor quantidade do que no Windows Server 2003 ao buscar dados no arquivo de paginação ou executar E/Ss read-ahead em arquivos mapeados. As E/Ss de arquivo maiores são facilitadas por alterações no sistema de E/S que remove o limite de tamanho de 64 KB presente desde a primeira versão do Windows NT®.

Também é importante observar que as leituras de dados para read-ahead (leituras especulativas) a partir de arquivos mapeados pelo Gerenciador de Cache normalmente têm o dobro do tamanho no Windows Server 2008 em relação ao Windows Server 2003 e vão direto para a lista de espera (o cache de dados e o código do sistema). Esse comportamento ocorre em lugar da solicitação para que o Gerenciador de Cache mapeie a memória virtual e leia os dados no conjunto de trabalho do Sistema (memória atribuída ao Sistema pelo gerenciador de memória), o que pode fazer com que outros dados ou códigos em uso sejam removidos desnecessariamente do conjunto de trabalho.

O gerenciador de memória também executa E/Ss maiores durante a gravação de dados no arquivo de paginação. Enquanto o Windows Server 2003 costumava executar gravações até menores do que 64 KB, o gerenciador de memória no Windows Server 2008 normalmente emite gravações de 1 MB.

Além de melhorar o desempenho diminuindo o número de gravações no arquivo de paginação, as gravações maiores também minimizam a fragmentação dentro desse arquivo. Por sua vez, isso provoca uma redução no número de leituras e buscas em disco necessárias para reler várias páginas, já que, na maioria das vezes, elas não estão adjacentes.

O gerenciador de memória também tenta gravar outras páginas modificadas que estejam próximas à que está sendo gravada no espaço de endereço do processo proprietário. O destino é a área do arquivo de paginação onde outras páginas vizinhas já residem. Isso minimiza a fragmentação e pode melhorar o desempenho porque as páginas que possam vir a ser gravadas no arquivo de paginação já foram gravadas. Além disso, reduz o número de leituras de paginação necessárias para obter um intervalo de páginas de processo adjacentes. Veja a barra lateral "Experimento: ver grandes E/Ss de disco" para obter mais informações sobre o uso de grandes E/Ss no Gerenciador de Memória.

SMB 2.0

O protocolo de sistema de arquivos remoto SMB, também conhecido como CIFS (Common Internet File System), tem sido a base do serviço de arquivos do Windows desde que essa funcionalidade foi introduzida no Windows. Nos últimos anos, as limitações de design do SMB restringiram o desempenho desse serviço e a capacidade de aproveitar os novos recursos do sistema de arquivos local. Por exemplo, o tamanho máximo de buffer que pode ser transmitido em uma única mensagem é cerca de 60 KB, e o SMB 1.0 não reconhecia links simbólicos do lado do cliente NTFS adicionados no Windows Vista e no Windows Server 2008.

O Windows Vista e o Windows Server 2008 introduziram o SMB 2.0, que é um novo protocolo de serviço de arquivos remoto utilizado pelo Windows quando há suporte tanto no cliente como no servidor. Além de processar corretamente os links simbólicos do lado do cliente e outros aprimoramentos no NTFS, o SMB 2.0 usa o envio em lote para diminuir o número de mensagens trocadas entre um cliente e um servidor. O envio em lote pode melhorar a taxa de transferência em redes de alta latência como WANs (redes de longa distância) porque permite que mais dados estejam em trânsito ao mesmo tempo.

Enquanto o SMB 1.0 emitia E/Ss referentes a um único arquivo seqüencialmente, o SMB 2.0 implementa pipelining de E/S, permitindo a emissão de várias E/Ss simultâneas para o mesmo arquivo. Ele mede a quantidade de memória de servidor usada por um cliente para que as E/Ss pendentes determinem o detalhamento do pipeline.

Devido a melhorias no mecanismo de cópia de arquivos e às alterações no gerenciador de memória de E/S do Windows, no sistema de E/S e no ajuste automático da janela de recebimento do TCP/IP, o SMB 2.0 permite aprimoramentos significativos na taxa de transferência e redução no tempo de cópia de arquivos para grandes transferências. Como os dois sistemas operacionais implementam o SMB 2.0, a implantação de servidores de arquivos do Windows Server 2008 com clientes Windows Vista possibilita o uso do SMB 2.0 e a realização desses benefícios no desempenho.

Confiabilidade com a auto-recuperação do NTFS

Confiabilidade é um atributo de servidor fundamental, e o Windows Server 2008 oferece vários aprimoramentos que ajudam os administradores a manter o servidor funcionando sem problemas, como o reparo de consistência do NTFS online, uma nova infra-estrutura de relatório de erros de hardware e extensões para o Verificador de Driver.

Com os dispositivos de armazenamento atuais de vários terabytes, colocar um volume offline para fazer uma verificação de consistência pode resultar em uma interrupção de muitas horas no serviço. Reconhecendo que muitas corrupções de disco estão localizadas em um único arquivo ou em uma parte dos metadados, o Windows Server 2008 implementa um novo recurso de auto-recuperação do NTFS para reparar danos enquanto um volume permanece online.

Quando o NTFS detecta a corrupção, ele impede o acesso ao(s) arquivo(s) danificado(s) e cria um thread de trabalho do sistema que executa correções parecidas com Chkdsk nas estruturas de dados corrompidas, permitindo acessar os arquivos reparados quando terminar. O acesso a outros arquivos continua normal durante essa operação, minimizando interrupções no serviço.

Infra-estrutura WHEA

A infra-estrutura WHEA (Arquitetura de Erro de Hardware do Windows) incluída no Windows Server 2008 promete simplificar o gerenciamento de falhas de hardware e permitir respostas pró-ativas a erros não-fatais. As garantias do tempo de atividade nos servidores costumam ser rígidas, por isso é fundamental identificar e responder a erros em tempo hábil nesse tipo de sistema.

A análise de panes enviada à Microsoft via OCA (Análise Online de Pane do Windows) mostra que, em termos gerais, 10% das panes no sistema operacional ocorrem em resposta a uma falha de hardware, mas tem sido difícil ou impossível determinar a causa principal delas, pois o hardware não fornece informações de erro suficientes para captura em uma pane. Além disso, antes do Windows Server 2008, o Windows não fornecia suporte interno para monitorar a integridade de dispositivos nem implementava correção ou notificação de falha iminente. O motivo é que os dispositivos de hardware não usam um formato de erro comum nem fornecem suporte a software de gerenciamento de erros.

A WHEA oferece um mecanismo unificado para descoberta e relatório de origens de erro referentes a dispositivos de plataforma, inclusive processadores, memória, caches e barramentos como PCI e PCI Express. Ela faz isso implementando a arquitetura mostrada na Figura 2, na qual o núcleo é uma API do kernel chamada pelas origens de erro para relatar erros. A API requer que todos os erros sejam formatados de modo comum e registra os erros em log usando eventos ETW (Rastreamento de Eventos para Windows). Os erros fatais são registrados em log após uma reinicialização.

Figura 2 Infra-estrutura de relatório de erros WHEA

Figura 2** Infra-estrutura de relatório de erros WHEA **(Clique na imagem para aumentar a exibição)

O ETW foi introduzido no Windows 2000, e o uso da WHEA do ETW torna fácil para fabricantes de hardware e fornecedores de software desenvolverem aplicativos para o gerenciamento de diagnósticos de dispositivos que consumam eventos WHEA. Se um evento for grave o bastante para acarretar uma pane no sistema, a WHEA garantirá que o registro do erro fatal seja armazenado no arquivo de despejo de memória para que os administradores possam determinar a causa principal da pane.

Outra peça-chave da WHEA é o PSHED (Driver de Erro de Hardware Específico da Plataforma), localizado em %Systemroot%\System32\Pshed.dll. O kernel se vincula ao PSHED e faz a interface com a plataforma e o hardware do firmware, servindo basicamente como camada de conversão entre as notificações de erro e a API de relatório de erros da WHEA. A Microsoft fornece um PSHED para cada arquitetura de plataforma (x86, x64, Itanium), e o PSHED expõe um modelo de plug-in para que fabricantes e fornecedores de hardware possam substituir os comportamentos padrão pelos especificados em suas plataformas.

Finalmente, os componentes do sistema que fazem interface com outras origens de erro – como drivers de dispositivo, a HAL (Camada de Abstração de Hardware) e o kernel – podem implementar LLHELs (Manipuladores de Erros de Hardware de Baixo Nível) que inicialmente manipulam uma condição de erro. O trabalho de um LLHEL é extrair informações de erro do dispositivo, notificar o PSHED para permitir que ele colete outras informações de erro da plataforma e depois chamar a API de relatório de erros da WHEA do kernel.

Verificador de Driver

O Verificador de Driver, uma ferramenta eficiente para rastrear drivers de dispositivo com bugs e hardwares com falhas, foi incluída em cada cópia do Windows desde o Windows 2000. Geralmente, os administradores configuram o Verificador de Driver (%Systemroot%\System32\Verifier.exe) para monitorar atentamente o comportamento dos drivers de dispositivo suspeitos de provocar panes no sistema. O Verificador de Driver captura operações de driver ilegais para que um arquivo de despejo de memória aponte diretamente para a parte culpada.

Uma desvantagem das implementações anteriores do Verificador de Driver é que a maioria das alterações na configuração requerem reinicialização do sistema, algo que está longe de ser o desejado em um servidor de produção. A implementação do Verificador de Driver do Windows Server 2008 aprimora o processo ao eliminar o requisito de reinício para as verificações mais úteis, possibilitando que o problema de um servidor seja solucionado sem que seja necessário reiniciá-lo.

Além disso, o Verificador de Driver apresenta três novas verificações, que podem ser vistas na Figura 3. As verificações de segurança garantem que os drivers de dispositivo definam permissões seguras nos objetos usados para fazer a interface com aplicativos. Forçar solicitações de E/S pendentes testa a resiliência de um driver para operações de E/S assíncronas concluídas imediatamente, e não após um atraso. E Verificações diversas procura drivers que estejam liberando incorretamente recursos em uso, usando incorretamente APIs de registro da WMI (Instrumentação de Gerenciamento do Windows) e vazando identificadores de recurso.

Figura 3 Verificador de Driver com opções do Windows Server 2008 marcadas

Figura 3** Verificador de Driver com opções do Windows Server 2008 marcadas **(Clique na imagem para aumentar a exibição)

Escalabilidade

A escalabilidade refere-se à capacidade de um aplicativo ou sistema operacional utilizar com eficácia vários processadores e grandes quantidades de memória. Cada versão do Windows melhora a escalabilidade minimizando ou eliminando o uso de bloqueios que reduzam o paralelismo em multiprocessadores, e o Windows Server 2008 não é exceção a essa tendência.

Uma melhoria relativamente pequena mas significativa está no código que executa a expiração de timer, o qual não adquire mais o bloqueio de distribuidor, que é um bloqueio de agendador do sistema inteiro usado por todas as operações de sincronização de nível baixo. A redução resultante na sobrecarga de sincronização da CPU permite que os sistemas do Terminal Server do Windows Server 2008 ofereçam suporte a, aproximadamente, 30% mais usuários simultâneos do que o Windows Server 2003.

Outros aprimoramentos de escalabilidade no Windows Server 2008 incluem aperfeiçoamentos na porta de conclusão, uma nova implementação de pool de threads, uso mais eficaz de hardware NUMA (Acesso Não-uniforme à Memória) e particionamento dinâmico do sistema.

Melhoria na manipulação de portas de conclusão de E/S

A maioria dos aplicativos de servidor do Windows escaláveis (como o IIS, o SQL Server® e o Exchange Server) se baseia em uma API de sincronização do Windows chamada porta de conclusão para minimizar a alternância entre vários threads de execução ao executar operações de E/S. Eles fazem isso primeiro associando notificações de novas chegadas de solicitações, como conexões do cliente servidor Web, a uma porta de conclusão e indicando um determinado pool de threads para esperar as notificações. Quando chega uma solicitação, o Windows agenda um thread, que normalmente executa então outras operações de E/S, como ler uma página da Web no disco e enviá-la ao cliente para concluir a solicitação.

Para que o mesmo thread possa voltar a esperar mais solicitações do cliente o mais rápido possível, o thread emite E/Ss de modo assíncrono e associa conclusões de E/S à porta de conclusão. Em seguida, ele volta a esperar na porta de conclusão, que agendará o thread quando uma nova solicitação chegar ou uma das E/Ss for concluída. Dessa forma, o mesmo thread permanece ativo em uma CPU, processando alternadamente solicitações do cliente e esperando na porta de conclusão.

Uma desvantagem da implementação de portas de conclusão nas versões anteriores do Windows é que, quando uma E/S era concluída, o sistema de E/S fazia com que o thread que emitiu a E/S executasse imediatamente uma parte do processamento de conclusão, não importa o que ele estivesse fazendo. Se outros threads estivessem ativos, isso costumava fazer com que o agendador admitisse preempção de um thread ativo e alternasse o contexto para o emissor.

O Windows Server 2008 evita essas alternâncias de contexto delegando o processamento de conclusão ao próximo thread a esperar na porta de conclusão à qual a E/S está associada. Assim, mesmo no caso de um thread diferente ser o próximo a esperar na porta de conclusão, ele realizará o processamento de conclusão antes de executar outro código, e o agendador não precisará alternar para o thread emissor. Essa redução nas alternâncias de contexto pode melhorar consideravelmente a escalabilidade de aplicativos de servidor muito carregados.

Pools de thread mais eficientes

A gravação de aplicativos que aproveitam várias CPUs pode ser difícil, por isso o Windows XP introduziu pools de threads de trabalho, uma API associada e de infra-estrutura que abstrai os detalhes da execução de pequenas unidades de trabalho através de CPUs. Um aplicativo especifica os itens de trabalho para a API do pool de threads, que os executa em um dos diversos threads criados e gerenciados para cada CPU no sistema.

O objetivo do pool de threads é reduzir as alternâncias de contexto usando os mesmos threads para executar vários itens de trabalho sucessivamente. Quando isso não é possível porque um dos threads está ocupado realizando outro trabalho, ele executa o item de trabalho usando um thread diferente em outra CPU.

A implementação do pool de threads do Windows Server 2008 faz melhor uso das CPUs indiretamente – porque se beneficia dos aprimoramentos na porta de conclusão – e diretamente, por meio da otimização do gerenciamento de threads para que os threads de trabalho venham e voltem dinamicamente quando necessário para manipular a carga de trabalho de um aplicativo. Além disso, o núcleo da infra-estrutura foi movido para o modo de kernel, diminuindo o número de chamadas do sistema feitas por aplicativos que usam a API. Finalmente, a nova API facilita a execução pelos aplicativos de certas operações, como a anulação de unidades de trabalho em fila durante o encerramento do aplicativo.

Otimizações NUMA

O Windows Server 2003 introduziu otimizações para computadores NUMA no gerenciador de memória e no agendador de threads, mas o Windows Server 2008 adiciona otimizações NUMA no gerenciador de E/S e estende as otimizações NUMA do gerenciador de memória.

Os sistemas NUMA normalmente são sistemas multiprocessadores em que a memória tem latência diferente, dependendo de qual processador a acessa (consulte a Figura 4). A memória é dividida em nós, nos quais as latências entre CPUs e nós podem variar e cada CPU é considerada parte de um nó ao qual tem o acesso mais rápido.

Figura 4 Exemplo de sistema NUMA

Figura 4** Exemplo de sistema NUMA **(Clique na imagem para aumentar a exibição)

Os sistemas NUMA, especialmente aqueles com mais de oito CPUs, costumam ser mais econômicos e apresentar melhor desempenho do que os sistemas de acesso uniforme à memória. Embora um sistema desse tipo deva disponibilizar memória igualmente para todas as CPUs, um sistema NUMA pode implementar tanto interconexões de alta velocidade para memória conectada diretamente a uma CPU como conexões de alta latência mais baratas para CPUs e memória que estejam mais separadas.

Para dimensionar um sistema NUMA com eficiência, um aplicativo ou sistema operacional deve reconhecer a topologia de nós para que a computação seja executada próximo à memória que contém o código e os dados da computação. Por exemplo, o agendador do Windows atribui a cada thread um processador supostamente ideal, que é a CPU na qual o agendador tenta sempre executar o thread. Isso torna mais provável que os dados colocados pelo thread no cache da CPU estejam disponíveis para o thread toda vez que for executado.

No Windows Server 2003, o agendador expande esse conceito considerando o nó que contém o processador ideal como sendo o nó ideal do thread e tenta agendar o thread em outra CPU no nó ideal quando o processador ideal está ocupado executando um thread diferente. O gerenciador de memória do Windows Server 2003 também passa a reconhecer NUMA e, quando possível, direciona as alocações de memória de um thread para a memória do nó em que o thread está sendo executado.

No Windows Server 2008, o gerenciador de memória divide os buffers de memória não paginada do kernel (memória usada pelo kernel e pelos drivers de dispositivo para armazenar dados certamente permanecerão na RAM) pelos nós para que as alocações venham da memória no nó em que a alocação se originou. Caso a alocação requeira uma nova página da tabela de paginação para satisfazê-la, as PTEs (entradas da tabela de paginação do sistema) são alocadas a partir do nó do qual a alocação se originou, e não de qualquer nó, como ocorre no Windows Server 2003.

No Windows Server 2003, quando um thread fazia uma alocação de memória, o gerenciador de memória preferia o nó em que o thread estava sendo executado no momento da alocação. Se o thread estivesse momentaneamente agendado em um nó não-ideal, qualquer alocação executada durante esse tempo viria desse nó. Dessa forma, quando o thread viesse a ser executado no nó ideal, não estaria tão perto quanto poderia dos dados ou do código armazenados na memória alocada.

Para resolver isso, o gerenciador de memória do Windows Server 2008 dá preferência ao nó ideal de um thread para todas as alocações desse thread, mesmo quando o thread está sendo executado perto de um nó diferente. O gerenciador de memória também compreende automaticamente as latências entre processadores e nós. Portanto, se o nó ideal não tem memória disponível, seu próximo passo é verificar o nó mais perto do nó ideal. Além disso, o gerenciador de memória migra páginas em sua lista de espera para o nó ideal de um thread quando esse thread faz referência a código ou dados.

Os aplicativos que queiram controlar a localização de suas alocações podem usar as novas APIs de memória NUMA, que permitem especificar um nó preferencial para alocações de memória, além de exibições e objetos de mapeamento de arquivos. Para uma alocação relacionada a um mapeamento de arquivos, o gerenciador de memória verifica se a operação de mapeamento ou o objeto de mapeamento de arquivos especifica um nó. Caso nenhum dos dois tenha, ele vai para o nó ideal do thread.

Antes do Windows Server 2008, a DPC (chamada de procedimento deferida) associada e de interrupção relativa a uma E/S de rede ou de armazenamento podia ser executada em qualquer CPU, inclusive nas de um nó diferente daquele no qual a E/S foi iniciada. Com isso, era possível que os dados lidos ou gravados na operação de E/S ficassem na memória de um nó diferente daquele no qual os dados foram acessados.

Para evitar isso, o sistema de E/S do Windows Server 2008 direciona a execução de DPCs para uma CPU no nó que iniciou a E/S, e os sistemas que possuem dispositivos com suporte ao barramento PCI MSI-X (uma extensão do Message Signaled Interrupt padrão) podem localizar também a conclusão de E/S usando drivers de dispositivo que aproveitam APIs do Windows Server 2008 para direcionar uma interrupção de E/S para o processador que iniciou a E/S.

Particionamento dinâmico

Uma das maneiras de um sistema ser mais escalonável é dar suporte à adição dinâmica de recursos de hardware como CPUs e memória. Esse mesmo suporte também poderá tornar o sistema mais disponível quando esses recursos puderem ser substituídos sem que seja necessário reinicializá-lo.

O Windows Server 2003 possuía inclusão de memória a quente, permitindo que os servidores com suporte à memória dinâmica usassem a RAM quando adicionada por um administrador. O Windows Server 2008 estende o suporte à memória dinâmica possibilitando a substituição da memória.

A RAM que se torna mais dependente de correções de ECC (código de correção de erros) está arriscada a falhar totalmente, pois, em um servidor com suporte para substituição a quente, o Windows Server 2008 pode migrar dados imperceptivelmente de bancos de memória com falha e para substitutos. Para fazer isso, primeiro ele migra dados que estão sob controle do sistema operacional, depois encerra dispositivos de hardware movendo-os para um estado de baixa energia, migra o resto dos dados da memória e reinicializa os dispositivos para continuar a operação normal.

O Windows Server 2008 também oferece suporte à inclusão e à substituição a quente de processadores. Para uma substituição a quente, o hardware deve aceitar o conceito de CPUs sobressalentes, que podem ser colocadas online ou adicionadas dinamicamente quando uma CPU existente gerar indicações de falha, algo disponível atualmente apenas em sistemas de alta tecnologia. O agendador do Windows Server 2008 diminui a atividade na CPU em falha e migra o trabalho para a substituta. Depois disso, a CPU em falha pode ser removida e substituída por uma sobressalente.

O suporte do Windows Server 2008 à adição de processadores a quente permite que um administrador atualize os recursos de processamento de um servidor sem tempo de inatividade. Entretanto, o agendador e os sistemas de E/S só disponibilizarão uma nova CPU para aplicativos e drivers de dispositivo que solicitem notificação da chegada da CPU através de novas APIs porque alguns aplicativos pressupõem que o número de CPUs é fixo para uma sessão de inicialização. Por exemplo, um aplicativo pode alocar uma matriz de filas de trabalho correspondentes a cada CPU, na qual um thread usa a fila associada à CPU em que está sendo executado. Se o agendador colocar um dos threads do aplicativo em uma nova CPU, ele faria referência a uma fila não existente, o que pode corromper os dados do aplicativo e até danificar o aplicativo.

A capacidade de adicionar CPU é uma característica de aplicativos da Microsoft baseados em servidor como o SQL Server e o Exchange Server, assim como de vários processos básicos do Windows, inclusive o processo do Sistema, o Gerenciador de Sessão (%SystemRoot%\System32\Smss.exe,) e os processos de Host de Serviços Genérico (%Systemroot%\System32\Svchost.exe). Outros processos também podem solicitar notificação da chegada de nova CPU usando uma API do Windows. Quando uma nova CPU chega, o Windows notifica os drivers de dispositivo sobre a chegada iminente, inicia a CPU e notifica os aplicativos e os drivers de dispositivo gravados a fim de que aloquem estruturas de dados para rastrear atividades na nova CPU, se necessário.

Virtualização de computadores

Antes do Windows Server 2008, os produtos de virtualização da Microsoft, como o Virtual Server 2005, foram implementados com o uso de virtualização hospedada, como mostra a Figura 5. Na virtualização hospedada, as máquinas virtuais são implementadas por um VMM (Monitor de Máquina Virtual) que é executado junto com um sistema operacional host, normalmente como um driver de dispositivo. O VMM se baseia nos drivers de dispositivo e no gerenciamento de recursos do sistema operacional host e, quando esse sistema agenda sua execução, ele fraciona o tempo da CPU entre máquinas virtuais (VMs) ativas.

Figura 5 Virtualização de computadores hospedados

Figura 5** Virtualização de computadores hospedados **(Clique na imagem para aumentar a exibição)

O Hyper-V, apelidado de "Viridian", é implementado pela virtualização com o hipervisor. O hipervisor tem controle total sobre os recursos de hardware, e até o sistema operacional Windows Server 2008 que inicializa o sistema operacional – e através do qual você controla VMs – está basicamente sendo executado em uma máquina virtual, como mostra a Figura 6.

Figura 6 Arquitetura do Hyper-V

Figura 6** Arquitetura do Hyper-V **(Clique na imagem para aumentar a exibição)

O hipervisor pode particionar o sistema em várias VMs e trata a instância de inicialização do Windows Server 2008 como a partição mestre (ou raiz), permitindo que ela direcione o acesso a dispositivos de hardware como o disco, adaptadores de rede e processador gráfico. O hipervisor espera que a raiz realize o gerenciamento de energia e responda a eventos de hardware Plug and Play. Ele intercepta a E/S de dispositivo de hardware iniciada em uma partição filho e a roteia para a raiz, que usa os drivers de dispositivo padrão do Windows Server 2008 para obter acesso ao hardware. Dessa forma, os servidores que executam o Hyper-V podem aproveitar o suporte do Windows para dispositivos de hardware.

Quando você configura o Windows Server 2008 com a função de servidor Hyper-V, o Windows define a configuração hypervisorimagelaunchtypeboot do BCD (Banco de Dados de Configuração de Inicialização) como automática e configura o driver de dispositivo Hvboot.sys para antecipar o processo de inicialização. Se a opção estiver configurada, Hvboot.sys irá preparar o sistema para virtualização e depois carregar %Systemroot%\System32\Hvax64.exe ou %Systemroot%\System32\Hvix64.exe na memória, dependendo se o sistema implementa extensões de virtualização de CPU AMD-V ou Intel VT, respectivamente.

Depois de carregado, o hipervisor usa as extensões de virtualização para inserir a si próprio no Windows Server 2008. Aplicativos de modo de usuário usam o nível de privilégio Ring 3 do processador x64, enquanto código de modo de kernel é executado em Ring 0. Assim, o hipervisor opera no nível de privilégio conceitual Ring menos 1, já que pode controlar o ambiente de execução de código executado em Ring 0.

Quando você usa o console de gerenciamento do Hyper-V para criar ou iniciar uma partição filho, ele se comunica com o hipervisor por meio do driver %Systemroot%\System32\Drivers\Winhv.sys, que utiliza a API Hypercall publicamente documentada para direcionar o hipervisor e criar uma nova partição com características de execução e tamanho de memória física especificados. O Serviço VM (%Systemroot%\System32\Vmms.exe) dentro da raiz é o que cria um Processo de Trabalho VM (%Systemroot%\System32\Vmwp.exe) para cada partição filho gerenciar o estado do filho.

Uma forma pela qual o Windows melhora o desempenho de sistemas operacionais VM secundários é que tanto o Windows Server 2008 como o Windows Vista implementam esclarecimentos, que são seqüências de código ativadas apenas quando o sistema operacional está sendo executado em um hipervisor que implementa a API Hypercall da Microsoft. Ao solicitar serviços do hipervisor diretamente, a VM filho evita a sobrecarga no código de virtualização que resultaria caso o hipervisor tivesse de adivinhar a intenção do sistema operacional secundário.

Por exemplo, um sistema operacional convidado que não implemente esclarecimentos para spinlocks (os quais executam sincronização de multiprocessador de baixo nível) simplesmente transferiria um loop estreito à espera da liberação de um spinlock por outro processador virtual. A transferência poderia obstruir uma das CPUs de hardware até que o hipervisor agendasse o segundo processador virtual. Nos sistemas operacionais esclarecidos, o código de spinlock notifica o hipervisor através de uma Hypercall quando normalmente seria transferido, para que o hipervisor possa agendar imediatamente outro processador virtual e reduzir o desperdício no uso da CPU.

Outra maneira de o Windows Server 2008 melhorar o desempenho de VMs é acelerar o acesso de VMs a dispositivos. O desempenho é aprimorado por meio da instalação de uma coleção de componentes, coletivamente chamados de "componentes de integração de VM", no sistema operacional secundário.

Se você executar uma VM sem instalar os componentes de integração, o sistema operacional secundário configurará drivers de dispositivo de hardware para os dispositivos emulados apresentados pelo hipervisor. O hipervisor deve intervir quando um driver de dispositivo tenta tocar em um recurso de hardware para informar a partição Raiz, que executa a E/S de dispositivo usando drivers de dispositivo do Windows em nome do sistema operacional de VM secundário. Como uma única operação de E/S de nível alto (a leitura de um disco, por exemplo) pode envolver muitos acessos distintos a hardware, ela pode causar muitas transições (chamadas de interceptações) no hipervisor e na partição raiz.

O Windows Server 2008 minimiza as interceptações com três componentes: o Driver de Barramento de Máquina Virtual (%Systemroot%\System32\Drivers\Vmbus.sys), Clientes de Serviço Virtual (VSCs) e Provedores de Serviço Virtual (VSPs). Quando você instala componentes de integração em uma VM com um sistema operacional compatível, os VSCs assumem a função de drivers de dispositivo e usam os serviços do driver Vmbus.sys na VM filho para enviar solicitações de E/S de nível alto ao Driver de Barramento de Máquina Virtual na partição Raiz através da Hypercall e dos serviços de compartilhamento de memória do hipervisor. Na partição raiz, Vmbus.sys encaminha a solicitação ao VSP correspondente, que inicia então as solicitações padrão de E/S do Windows através dos drivers de dispositivo da raiz.

Como você pode ver, o Windows Server 2008 desempenha um papel fundamental na estratégia de virtualização de computadores da Microsoft com sua introdução à virtualização baseada no hipervisor Hyper-V. Procure mais informações sobre esses e outros recursos na próxima edição do meu livro, Microsoft Windows Internals, cuja publicação está prevista ainda para este ano.

Mark Russinovich é um colega da área técnica da Microsoft na divisão de plataforma e serviços. Ele é co-autor do livro Microsoft Windows Internals (Microsoft Press, 2004) e palestrante assíduo em conferências de desenvolvedores e de TI, como o Microsoft TechEd e a Conferência para Desenvolvedores Profissionais,. Mark ingressou na Microsoft com a recente aquisição da empresa de que foi co-fundador, a Winternals Software. Ele também criou a Sysinternals, através da qual publicou muitos utilitários populares, como Process Explorer, Filemon e Regmon.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..