Mscom64bitarchitecture Twp

Microsoft.com muda para a versão x64 do Windows Como o Microsoft.com atualizou seus servidores Web para a plataforma de hardware e software baseada em x64

Documento técnico Publicado em: fevereiro de 2006

SUMÁRIO Resumo executivo .........................................................................................................3 Introdução .........................................................................................................4 Migração do Microsoft.com para servidores Web de 64 bits .........................................................................................................6 Desafios históricos na plataforma de 32 bits (x86) 6 Benefícios potenciais das versões de 64 bits do Windows 8 Estratégia de adoção e abordagem 10 Vantagens 13 Práticas recomendadas ......................................................................................................... 16 Conclusão ......................................................................................................... 18 Para obter mais informações ......................................................................................................... 19 Apêndice a ......................................................................................................... 20 Visão geral da arquitetura do Microsoft.com 20

Situação O Windows Server 2003 e o IIS 6.0 permitiram à equipe de operações do Microsoft.com obter resultados de disponibilidade incomparáveis. No entanto, as limitações de memória virtual do sistema operacional de 32 bits estavam afetando cada vez mais a disponibilidade e o desempenho do servidor individual, bem como reduzindo a capacidade da equipe de solucionar problemas e depurar aplicativos Web.

Solução A equipe de operações do Microsoft.com decidiu tornar-se uma das primeiras a adotar uma versão de 64 bits do Windows Server 2003 projetada especificamente para servidores baseados na plataforma x64. Mudar para a plataforma x64 aumentou bastante as alocações de memória virtual. Os registros de 32 bits nos chips x64 e o ambiente de emulação de 32 bits na versão de 64 bits do Windows Server 2003 tornaram a migração da plataforma praticamente perfeita.

Vantagens • Maior disponibilidade dos sites Microsoft.com;

• Desempenho significativamente melhor dos servidores Web do Microsoft.com; • Tempo de resposta do usuário final imensamente aprimorado; • Solução de problemas e depuração mais fáceis dos aplicativos Web; • Redução dos custos de hardware.

Produtos e tecnologias • Servidores baseados no AMD Opteron x64;

• Versão baseada no Windows Server 2003 x64;

• IIS 6.0; • ASP.NET e .NET Framework versões 1.1 e 2.0;

• Ambiente de emulação WoW64; • NLB.

RESUMO

EXECUTIVO

Em março de 2004, cerca de um ano antes do lançamento oficial do Microsoft® Windows Server™ 2003 x64 Edition, o Microsoft.com decidiu avaliar os benefícios da implementação de servidores com plataforma de hardware baseada em x64 executando versões de pré-lançamento desse sistema operacional na produção de servidores Web do www.microsoft.com. Em abril de 2005, 100% dos servidores Web de produção do Microsoft.com estavam sendo executados em plataformas de hardware e de sistema operacional baseadas em x64. A limitação de espaço de endereço de memória virtual própria das versões de 32 bits do Microsoft Windows® fazia com que a equipe de operações do Microsoft.com enfrentasse desafios quanto à estabilidade do aplicativo e à solução de problemas. Com as versões de 64 bits do Windows, o espaço de endereço de memória virtual de um aplicativo aumentou bastante. O recurso crucial combinado com a capacidade de executar facilmente aplicativos de 32 bits com alto nível de desempenho resolveu o maior problema do site Microsoft.com: contenção de memória. A plataforma de hardware baseada em x64 pode executar nativamente o código de 32 bits basicamente com os mesmos níveis de desempenho que um hardware de 32 bits configurado de maneira semelhante. Além disso, o ambiente de 32 bits na versão x64 do Windows também permite a execução de aplicativos de 32 bits sem qualquer modificação do código, o que torna a migração da plataforma praticamente perfeita. A atualização final da plataforma para a versão x64 do Windows aumentou drasticamente o tempo médio entre a reciclagem do aplicativo e do serviço da Web nos servidores Web do Microsoft.com, aumentando, assim, a disponibilidade geral do site. O mais impressionante é que a carga da CPU nos servidores caiu 50% e os tempos de resposta de página de alguns aplicativos estão até 15 vezes mais rápidos. A finalidade deste documento é compartilhar considerações e experiências de arquitetura, design e implantação com base na solução de servidor Web baseado em x64 do Microsoft.com, a fim de demonstrar o valor dos atuais produtos da Microsoft em relação a sites altamente disponíveis e de alto desempenho. Este documento aborda resumidamente a evolução da plataforma Web no Microsoft.com, os desafios encontrados pela equipe de operações com a plataforma de 32 bits e que foram resolvidos com a plataforma baseada em x64, a estratégia de migração e de implantação e a arquitetura da infra-estrutura final. Este documento pressupõe que os leitores sejam responsáveis por decisões técnicas e já estejam familiarizados com as tecnologias de servidor Web do Windows Server 2003, como os Serviços de informações da Internet (IIS) versão 6.0, o Microsoft ASP.NET e o Microsoft .NET Framework, e com as tecnologias associadas, como NLB (Balanceamento de Carga de Rede) e Microsoft SQL Server™ 2000. Uma organização pode utilizar vários dos princípios e das técnicas descritos neste documento para planejar a atualização de uma plataforma Web. Da mesma forma, uma organização pode aplicar as considerações de design de uma infra-estrutura de servidor Web baseada em x64 a praticamente qualquer ambiente de TI de escala empresarial. No entanto, este documento baseia-se na experiência e nas recomendações da equipe de operações do Microsoft.com como uma das primeiras a adotar a plataforma. Ele não serve como um manual de procedimentos. Cada ambiente empresarial tem circunstâncias exclusivas; portanto, cada organização deve adotar os planos e as lições aprendidas neste documento de forma a atender às suas necessidades específicas. Observação: por razões de segurança, os exemplos de nomes de florestas, domínios, recursos internos, organizações e nomes de arquivos de segurança desenvolvidos internamente usados neste documento não representam nomes de recursos reais usados dentro da Microsoft e são apenas para fins ilustrativos.

Microsoft.com muda para a versão x64 do Windows

Página 3

INTRODUÇÃO O site corporativo da Microsoft, o Microsoft.com, é um dos maiores e mais visitados sites da Internet, ocupando o quarto ou quinto lugar entre os sites mais visitados em um único dia. O Microsoft.com está espalhado por três data centers e consiste em milhares de servidores, usa mais de 1.000 bancos de dados e oferece suporte a milhares de aplicativos Web. O www.microsoft.com tem, em média, mais de 13 milhões de usuários exclusivos e 70 milhões de páginas exibidas por dia. Esses usuários usam em média 10.000 conexões por segundo e mantêm uma média de 300.000 conexões simultâneas com um total de 80 servidores Web. O Microsoft.com também usa parceiros de entrega de conteúdo na rede para ampliar seu alcance e sua disponibilidade, bem como melhorar o desempenho por meio do balanceamento de carga e do armazenamento de conteúdo em cache globalmente. Além de oferecer suporte a milhares de servidores de produção, a equipe de operações oferece suporte a centenas de servidores que não são de produção em vários ambientes que vão do desenvolvimento à pré-produção ou armazenamento temporário, bem como dezenas de servidores de infra-estrutura que dão suporte ao site. Como mostrado na tabela a seguir, o alcance do Microsoft.com em relação ao público total de Internet nos Estados Unidos ultrapassa o de todos os sites corporativos e continua a crescer em uma taxa de 6,9% desde setembro de 2004. Tabela 1. Classificação do alcance dos sites corporativos Classificaçã o

Empresa

Usuários exclusivos

Porcentagem de alcance

1

Microsoft

54 milhões

36,3

29

Apple

13 milhões

8,9

31

Netscape

12,9 milhões

8,7

183

Sony

4,2 milhões

2,8

334

IBM

2,6 milhões

1,8

469

Sun

2 milhões

1,4

A missão da equipe de operações responsável pelo Microsoft.com é conseguir o mais alto nível de disponibilidade na Internet e, ao mesmo tempo, apresentar as tecnologias da Microsoft. A equipe de operações também tem como estratégia ser uma das primeiras a adotar os vários produtos da Microsoft e a fornecer comentários valiosos para os grupos dos produtos, compartilhando suas práticas recomendadas com clientes da empresa.

Microsoft.com muda para a versão x64 do Windows

Página 4

Nos últimos três anos, o Microsoft.com classificou-se em primeiro lugar na Internet no que diz respeito à disponibilidade do site, conforme os resultados medidos pela Keynote, a empresa mundialmente líder em serviços de gerenciamento de desempenho de e-business. Por meio de seu serviço de monitoramento Keynote Global 35, a Keynote mede a disponibilidade verificando se uma página inteira e todos os seus componentes estão disponíveis em intervalos regulares em 35 locais espalhados pelo mundo. Se uma única imagem da página não estiver disponível em qualquer local de teste, a Keynote considerará uma falha do site naquele intervalo. A tabela a seguir mostra o Microsoft.com em comparação com outros sites do mercado que têm uma classificação alta e que também são monitorados pelo serviço Keynote Global 35. Para obter mais informações sobre o serviço de monitoramento Keynote Global 35, consulte o estudo de caso do IT Showcase sobre monitoramento e solução de problemas do Microsoft.com, em http://www.microsoft.com/technet/itsolutions/msit/ (em inglês). Tabela 2. Classificações de disponibilidade de sites Classificaç ão

Site

Porcentagem de disponibilidad e

1

Microsoft.com

99,82

2

Windows Update

99,81

3

Google

99,71

4

IBM

99,70

5

AOL

99,69

6

Dell

98,63

8

Oracle

84,06

Embora o site do Microsoft.com tenha crescido continuamente, experimentando níveis sem precedentes de disponibilidade e desempenho em plataforma de hardware e sistema operacional de 32 bits, as limitações de memória próprias da plataforma de 32 bits geravam para a equipe de operações grandes desafios. Esses desafios exigiam intervenção freqüente e dificultavam a solução de problemas e a depuração de aplicativos Web para a equipe de operações.

Microsoft.com muda para a versão x64 do Windows

Página 5

MIGRAÇÃO 64 BITS

DO

MICROSOFT.COM

PARA SERVIDORES

WEB

DE

Devido ao aumento no espaço de endereçamento de memória virtual, a equipe de operações do Microsoft.com estava interessada em avaliar os possíveis benefícios de se executar os servidores Web do www.microsoft.com em uma versão de 64 bits do Windows.

Desafios históricos na plataforma de 32 bits (x86) A equipe de operações do Microsoft.com monitora e analisa rotineiramente uma ampla matriz de métricas de desempenho do site todo, bem como dos servidores individuais que dão suporte ao site. Naturalmente, o maior afunilamento que a equipe de operações identificou no desempenho de servidor na plataforma x86 foi a contenção de memória nos servidores Web. Nas versões de 32 bits do Windows, o espaço total de endereço de memória virtual é de 4 GB. Por padrão, o sistema operacional reserva 2 GB desse espaço para os processos do modo kernel e limita os aplicativos aos 2 GB restantes de espaço de endereço de memória virtual. Quando o espaço de memória virtual de um aplicativo torna-se excessivamente comprometido ou fragmentado, o aplicativo pode apresentar erros ou degradação do desempenho e pode parar de funcionar corretamente. No IIS 6.0, quando essa situação ocorre, o pool de aplicativos deve ser reciclado para devolver os níveis de desempenho normais ao aplicativo. Nos aplicativos Microsoft .NET, o CLR (Common Language Runtime) aloca memória em grandes blocos contíguos dentro do espaço de endereço de memória virtual. O CLR gerencia a fragmentação em seu heap por meio de um processo chamado de coleta de lixo, que compacta periodicamente sua região da memória para manter a memória livre no heap como um bloco contínuo. A fragmentação de memória ocorre com o tempo, pois o CLR aloca e libera memória continuamente, deixando os inicialmente grandes blocos contíguos de memória livre divididos em vários blocos menores. A memória fora do heap de CLR gerenciado está sujeita a esse tipo de fragmentação. Com o consumo de memória continuamente crescente devido aos vazamentos, o alto número de assemblies carregados e o uso excessivo de cache do ASP .NET, a memória virtual utilizável do CLR é significativamente reduzida. À medida que o uso de memória continua a crescer e, especialmente, à medida que se aproxima do limite utilizável, o coletor de lixo tem que trabalhar mais para atender às solicitações de alocação. Como o coletor de lixo é executado em um nível elevado de prioridade de thread, e à medida que vários aplicativos no mesmo servidor alcançam seus limites de memória virtual, as atividades excessivas do coletor de lixo poderão resultar na falta de resposta do servidor inteiro por períodos prolongados que aumentarão com o tempo. É possível configurar versões de 32 bits do Windows para alocar 3 GB de memória para aplicativos usando a opção /3GB no arquivo boot.ini. No entanto, essa ação reduz a quantidade de memória alocada para os processos do modo kernel. No caso de servidores Web com tráfego intenso, os resultados dessa ação podem ser desastrosos. Os servidores Web com tráfego intenso criam e mantêm milhares de conexões de rede TCP simultâneas, sendo que cada uma exige uma alocação dos recursos de memória do kernel. Embora usar a opção /3GB forneça um adicional de 1 GB de memória virtual aos aplicativos, isso limita os processos do modo kernel, como o gerenciamento de conexões TCP, a 1 GB de memória virtual. Especificamente, a equipe de operações observou que a pilha da rede falhava freqüentemente ao usar a opção /3GB, especialmente em situações de ataque de solicitações de conexão TCP, conhecidas como ataques de SYN.

Microsoft.com muda para a versão x64 do Windows

Página 6

No Microsoft Windows 2000 e no IIS versão 5.0, todos os sites e aplicativos Web eram executados em um único ambiente de aplicativo compartilhado com uma única alocação de 2 GB de espaço de endereço de memória virtual. Isso significava que qualquer aplicativo sozinho e com desempenho insatisfatório poderia, por sua vez, fazer com que outros aplicativos tivessem um desempenho insatisfatório ou causar a paralisação de todo o serviço da Web de um servidor. A solução para essa situação era reciclar o IIS ou reiniciar o servidor para iniciar com uma nova alocação de memória virtual de 2 GB. Essa ação tinha como conseqüência indesejada a remoção do servidor Web de serviço durante a reciclagem, e ela liberava qualquer cache estabelecido anteriormente por qualquer aplicativo do servidor. O Windows Server 2003 e o IIS 6.0 introduziram a capacidade de o administrador da Web criar pools de aplicativos personalizados, além do pool de aplicativos padrão, para sites. Cada pool de aplicativos gera threads de trabalho dedicados em sua própria alocação isolada de espaço de endereço de memória virtual. Com o uso de pools de aplicativos, os aplicativos podem ser segregados individualmente ou consolidados em agrupamentos lógicos. Por exemplo, um aplicativo crítico pode ser colocado em seu próprio pool de aplicativos para limitar a possibilidade de outro aplicativo afetar negativamente o seu desempenho. Por outro lado, um aplicativo cujo desempenho é reconhecidamente insatisfatório pode ser colocado em um pool de aplicativos dedicados para limitar a possibilidade de ele afetar negativamente o desempenho de outro aplicativo. Quando um pool de aplicativos específico não estiver funcionando corretamente ou alcançar o limite especificado para uma reinicialização forçada, somente esse aplicativo ou grupo de aplicativos individual será colocado off-line e reiniciado. O mais importante é que a ação de reciclagem do pool de aplicativos é executada pelo sistema operacional de uma forma bastante eficiente. Por exemplo, antes de o pool de aplicativos ser colocado off-line, as solicitações são enfileiradas enquanto é criada uma instância de um novo processo desse pool de aplicativos para atender a todas as solicitações subseqüentes, assim que ele estiver on-line. Observação: os pools de aplicativos podem ser configurados pelos administradores para que sejam reiniciados com base em intervalos de tempo ou em limites de uso de memória. A configuração padrão é a reinicialização automática do pool de aplicativos a cada 12 horas. A equipe de operações do Microsoft.com prefere usar uma configuração de limite de memória virtual de 2 GB, em vez de intervalos de tempo. Há um limite prático para o número de pools de aplicativos que devem ser criados em um determinado servidor Web. No Microsoft.com, foi determinado que o número ideal de pools de aplicativos em um servidor de 32 bits é 12. A equipe de operações do Microsoft.com considera confiável o código dos aplicativos que passaram por um SDLC (Software Development Life Cycle) completo. Todos os outros aplicativos, incluindo vários de organizações parceiras, são considerados código não confiável. A equipe de operações do Microsoft.com separa código confiável de não confiável agrupando os códigos semelhantes em pools de aplicativos. Alguns aplicativos críticos ou com problemas conhecidos, como vazamentos de memória, podem receber um pool de aplicativos dedicado. No entanto, depois de alcançar o número ideal de pools de aplicativos em um servidor, o luxo de isolar um aplicativo em seu próprio pool não era mais uma opção, pois a maioria dos aplicativos está nos pools de aplicativos compartilhados. Em geral, os aplicativos mais problemáticos estão no pool de aplicativos não confiáveis, mas, se um aplicativo causar a falha de outros no pool de não confiáveis, ele será banido do site até ser corrigido pelos desenvolvedores.

Microsoft.com muda para a versão x64 do Windows

Página 7

Observação: os desenvolvedores de aplicativos Web podem usar a recém-lançada Debug Diagnostic Tool, incluída no IIS Diagnostic Toolkit, juntamente com uma ferramenta de teste de carga de aplicativos, como o Application Center Test incluído no Microsoft Visual Studio® .NET, para auxiliá-los no diagnóstico de vazamentos de memória no IIS. Embora a capacidade de criar pools de aplicativos independentes com proteção de memória isolada tenha representando um imenso benefício para o Microsoft.com, cada pool de aplicativos individual ainda está sujeito à limitação de memória virtual de 2 GB, e os intervalos de reciclagem de memória se tornaram cada vez mais curtos. Vários aplicativos ou grupos de aplicativos simplesmente exigem uma memória virtual superior a 2 GB para funcionar em um nível de desempenho ideal por um período prolongado. Com um limite de memória de 2 GB, pode ser extremamente difícil determinar se um aplicativo realmente exige mais de 2 GB para funcionar normalmente com o passar do tempo ou se o aplicativo tem um vazamento de memória. Mesmo com a capacidade de configurar limites para reinicializações automáticas do pool de aplicativos, se elas estiverem ocorrendo com freqüência, isso poderá causar um problema de desempenho significativo em um servidor. Com a maior demanda de recursos dos complexos aplicativos ASP .NET, alguns dos pools de aplicativos do Microsoft.com estavam reciclando praticamente a cada cinco minutos. Observação: quando um pool de aplicativos é reiniciado, ele precisa reconstruir os elementos de cache dos aplicativos. Geralmente, isso tem um impacto significativo no desempenho. Os administradores podem configurar o comportamento de reinicialização do pool de aplicativos para tornar órfão o processo antigo a fim de que ele possa ser depurado, mas esse método também tem implicações de desempenho e pode exigir que o administrador coloque o servidor off-line temporariamente. Com centenas de aplicativos cada vez mais complexos sendo executados nos servidores Web do Microsoft.com, os desafios relacionados à limitação de memória virtual continuavam a aumentar.

Benefícios potenciais das versões de 64 bits do Windows Uma das principais diferenças entre as versões de 32 bits e as versões de 64 bits do Windows é um endereçamento de espaço de memória virtual imensamente maior proporcionado pelos bits adicionais. O Windows para a plataforma baseada em x64 usa 43 bits de endereçamento de espaço de memória virtual, o que oferece ao kernel 8 terabytes de memória endereçável e deixa mais 8 terabytes para processos de modo de usuário de 64 bits. Como o sistema operacional não precisa mais compartilhar o espaço de endereçamento de 32 bits com as operações do modo kernel, o espaço de endereço de memória virtual de um aplicativo de 32 bits também aumenta de 2 para 4 GB, que é o espaço total disponível de endereço de memória de 32 bits. Esses aumentos de memória disponível resultam na remoção prática de uma limitação de memória de modo geral nos aplicativos de 64 bits, bem como em benefícios potencialmente significativos para aplicativos de 32 bits. A tabela a seguir resume as diferenças nas limitações de memória entre as versões de 32 e 64 bits do Windows.

Microsoft.com muda para a versão x64 do Windows

Página 8

Tabela 3. Limites gerais de memória Situação

32 bits

64 bits

Espaço total de endereço virtual (baseado em um único processo)

4 GB

16 terabytes

Espaço de endereço virtual por processo de 32 bits

2 GB

2 GB

Espaço de endereço virtual por processo de 32 bits (com a opção /3GB)

3 GB

N/A

Espaço de endereço virtual por processo de 32 bits (com a opção /LARGEADDRESSAWARE)

N/A

4 GB

Espaço de endereço virtual por processo de 64 bits

N/A

8 terabytes

Observação: para que um aplicativo de 32 bits aproveite o espaço de endereçamento maior de 4 GB, o sinalizador /LARGEADDRESSAWARE deverá ser fornecido ao compilador quando um aplicativo for compilado. O IIS 6.0 é configurado com esse sinalizador por padrão quando instruído a executar processos de trabalho no ambiente Microsoft Windows32-bit-On-Windows-64-bit ou WoW64. A Microsoft introduziu uma versão de 64 bits do Windows no Windows 2000 em 2001. A primeira versão foi criada para ser executada especificamente na plataforma de hardware Intel Itanium, também conhecida como Itanium. Embora o sistema operacional de 64 bits e a versão subseqüente do Windows Server 2003 para Itanium tenham proporcionado um limite de espaço de endereço de memória virtual imensamente maior para os aplicativos, a plataforma é praticamente voltada e adequada para aplicativos de 64 bits. Como vários dos aplicativos de hoje baseados no Windows Server, os aplicativos Web do Microsoft.com foram criados para serem executados em ambientes de 32 bits. Em geral, os aplicativos de 32 bits na plataforma Itanium não têm o mesmo desempenho apresentado em plataformas nativas de 32 bits. Além disso, o hardware Itanium pode exigir um investimento significativo em comparação com os servidores da plataforma x86. Desde o lançamento da plataforma Itanium, a Intel e a AMD desenvolveram CPUs mais econômicas de 64 bits com base em registros de 32 bits e extensões de 64 bits, conhecidas como plataforma baseada em x64. A Intel chama esse chip de EM64T. Esse design permite a implantação de sistema operacional de 32 ou 64 bits em um servidor baseado em x64. Além disso, para a versão x64 do Windows Server 2003, os aplicativos de 32 bits são executados no ambiente WoW64, o qual permite que sejam executados nativamente usando os registros de 32 bits com impacto imperceptível no desempenho. Na verdade, os aplicativos de 32 bits executados no WoW64 e as versões de 32 bits do Windows executadas no hardware baseado em x64 normalmente superam o desempenho de um servidor de 32 bits com configuração semelhante. A equipe de operações do Microsoft.com não observou impacto negativo no desempenho ao executar aplicativos de 32 bits no hardware baseado em x64. A capacidade de executar um sistema operacional de 64 bits e superar as limitações de memória virtual de um sistema operacional de 32 bits, bem como oferecer um desempenho melhor ou igual aos aplicativos de 32 bits sem modificações no código, é bastante promissora. Combinados com o custo potencialmente mais baixo do hardware, o hardware e o sistema operacional baseados em x64 podem oferecer melhor desempenho por um preço mais baixo.

Microsoft.com muda para a versão x64 do Windows

Página 9

Diante dos possíveis benefícios, em março de 2004, cerca de um ano antes do lançamento oficial da versão baseada em x64 do Windows Server 2003 no mercado, a equipe de operações do Microsoft.com decidiu avaliar os benefícios da implementação de servidores desenvolvidos na plataforma de hardware baseada em x64 conduzindo testes de verificação do conceito (VDC) e, em seguida, executando versões de pré-lançamento desse sistema operacional nos servidores de produção do Microsoft.com.

Estratégia de adoção e abordagem Antes de fazer o teste completo da nova plataforma, era importante que a equipe de operações desenvolvesse uma configuração padrão para um servidor baseado em x64 semelhante à configuração existente para os servidores de 32 bits.

Como o Microsoft.com iniciou a mudança para a plataforma x64 O site www.microsoft.com é atendido por 80 servidores Web identicamente configurados em 10 clusters de carga balanceada com 8 servidores cada usando NLB. Com esse alto nível de redundância, a equipe de operações pode adicionar um servidor a um cluster NLB específico, bem como remover um servidor, sem afetar a disponibilidade ou o desempenho geral do site. Ao configurar um servidor baseado em x64 com conteúdo, aplicativos e configurações idênticos aos dos servidores existentes, a equipe de operações pode adicionar um novo servidor a um cluster de produção existente e monitorar o seu desempenho. Observação: geralmente, os administradores criam um cluster NLB de carga IP balanceada com todos os membros do cluster atendendo ativamente às solicitações de um grupo de servidores configurados de forma idêntica e com conteúdo e dados relativamente estáticos. Ao contrário dos clusters de failover que usam o Serviço de Cluster da Microsoft, não há exigência nem necessidade de armazenamento compartilhado entre os servidores em um cluster NLB. A equipe de operações do Microsoft.com baseia todos os servidores do site em uma imagem padrão do sistema operacional e os configura como servidores Web, aplicando scripts de configuração que permitem à equipe criar e configurar todos da mesma maneira. Para obter mais informações sobre as configurações de servidor do Microsoft.com, consulte a observação do IT Showcase sobre as configurações de servidor padrão de TI do Microsoft.com em http://www.microsoft.com/technet/itsolutions/msit/ (em inglês). Para avaliar um servidor baseado em x64, a equipe de operações criou uma compilação padrão de servidor Web, incluindo o sistema operacional de base e uma configuração de servidor Web em script. A compilação 1171 do sistema operacional baseado em x64 foi a primeira versão que a equipe de operações selecionou para implantação. A equipe de operações executou então um teste de VDC usando o hardware fornecido pela AMD e a compilação de servidor padrão recém-criada. A equipe de operações configurou o servidor de VDC conforme descrito na tabela a seguir.

Microsoft.com muda para a versão x64 do Windows

Página 10

Tabela 4. Configuração do servidor de teste baseado em x64 Componente Processador RAM Espaço na unidade

Configuração Quatro CPUs AMD64 Opteron de 1,6 GHz 8 GB 50 GB (sistema operacional), 136 GB (dados), 50 GB (logs)

Rede

Gigabit Fiber (front-end), cobre de 100 MB (back-end)

Sistema operacional

Windows Server 2003 x64 Edition (compilação 1171)

A configuração do sistema operacional de base inclui todas as ferramentas e os aplicativos do sistema necessários à implantação no data center. A versão baseada em x64 do Windows exige drivers específicos para os dispositivos de hardware e qualquer ferramenta ou aplicativo que inclua acesso de modo kernel (como antivírus). A equipe de operações teve que adquirir e testar os drivers apropriados para confirmar a funcionalidade. Depois que a imagem do sistema operacional de base estava configurada e estável, a equipe de operações testou incrementalmente vários aplicativos na nova plataforma no laboratório de teste. Esse teste envolveu tempo e esforços consideráveis, pois cada servidor Web do Microsoft.com configurado de forma idêntica hospeda 350 raízes virtuais, 190 aplicativos Web do IIS e 12 pools de aplicativos. Simultaneamente à VDC, a equipe de operações do Microsoft.com adquiriu um hardware baseado em x64 para substituir os servidores de 32 bits. Como descrito na seção anterior, a plataforma baseada em x64 pode ser executada em versões de 32 ou 64 bits do Windows. Inicialmente, a equipe de operações criou os novos servidores baseados em x64 com as configurações padrão de servidor Web do sistema operacional de 32 bits e os implantou na produção. Nesse ponto, a equipe de operações também alterou a arquitetura dos clusters NLB aumentando o número de servidores de seis para oito em cada cluster. Após a conclusão do teste de laboratório de VDC, a equipe de operações adicionou o servidor VDC a um dos clusters NLB de produção. A equipe de operações observou o servidor enquanto processava o tráfego ativo como validação final necessária a fim de partir para uma migração completa para a plataforma baseada em x64. Em seguida, a equipe atualizou servidores Web adicionais, um de cada vez, nesse cluster NLB, até que todo o cluster estivesse sendo executado em 64 bits. Geralmente, a equipe de operações faz atualizações em todos os servidores de um determinado cluster NLB simultaneamente. Um serviço global de balanceamento de carga permite que clusters NLB inteiros sejam temporariamente removidos do serviço durante as atividades de atualização de servidor. Esse processo de atualização de todos os servidores de uma só vez em um cluster NLB foi repetido pela equipe de operações nos demais clusters, até que todos os servidores Web de um data center estivessem executando versões de 64 bits do Windows. O processo foi repetido então no data center seguinte até que todos os servidores Web do www.microsoft.com estivessem executando versões de 64 bits do Windows.

Microsoft.com muda para a versão x64 do Windows

Página 11

Os clusters NLB poderiam ser migrados para a nova compilação padrão baseada em x64 um de cada vez, pois os servidores de produção já estavam sendo executados no hardware baseado em x64. Essa abordagem de migração permitiu uma migração tranqüila e em fases que não afetou a capacidade nem o desempenho da produção. Essa abordagem em fases também permitiu uma estratégia de reversão em um nível granular. Se um servidor individual encontrasse problemas, a equipe de operações poderia removê-lo rapidamente do cluster e, em seguida, recompilá-lo como um servidor de 32 ou de 64 bits.

Experiência de transição Uma das maiores preocupações da equipe de operações do Microsoft.com antes do início do projeto foi a quantidade de trabalho necessário para modificar aplicativos e componentes a fim de que funcionassem corretamente no sistema operacional baseado em x64. A equipe de operações percebeu rapidamente que, se configurado corretamente, o ambiente de emulação WoW64 eliminaria a necessidade de qualquer modificação. Especificamente, a equipe de operações não precisou tocar em uma única linha do código nem recompilar qualquer um dos componentes ou aplicativos a seguir:

•

Filtros ISAPI de 32 bits

•

Componentes COM (Component Object Model) antigos

•

Aplicativos do Microsoft ASP.NET versão 1.1

A equipe de operações também verificou que o desempenho dos aplicativos de 32 bits era praticamente igual nas duas plataformas, devido aos registros de 32 bits nas CPUs baseadas em x64.

Hospedagem lado a lado dos aplicativos de 32 e 64 bits Embora a equipe de operações possa migrar as plataformas de hardware e de sistema operacional completamente para 64 bits, ainda há várias dependências nos componentes de aplicativos de 32 bits que exigem do IIS a execução de processos de trabalho de 32 bits no WoW64. Vários dos aplicativos são criados no ASP .NET 1.1, que usa o Microsoft .NET Framework versão 1.1, e essa versão não é compatível com 64 bits. Da mesma forma, as extensões e os filtros ISAPI, juntamente com componentes COM personalizados e mais antigos que foram compilados ao longo dos anos, exigem processos de 32 bits. Portanto, a equipe de operações precisava configurar o IIS para executar processos de trabalho dos pools de aplicativos no ambiente WoW64 de 32 bits. Para obter instruções sobre como configurar uma chave de metabase do IIS que instrua o IIS a usar processos de trabalho de 32 bits, em vez dos processos de trabalho nativos de 64 bits, consulte o artigo “Windows Server 2003 SP1 enables WOW64 compatibility for 32-bit Web applications in IIS 6.0” da Base de Dados de Conhecimento, em http://support.microsoft.com/?id=895976 (em inglês). Por padrão, o IIS é configurado para aproveitar todo o espaço de endereçamento de 4 GB para pools de aplicativos ao operar no modo de 32 bits. Quando o IIS é configurado para ser executado no modo de 32 bits, todos os processos são executados nesse modo. A Microsoft não oferece suporte à execução de aplicativos de 32 e 64 bits juntos em pools de aplicativos do IIS no mesmo servidor físico. Agora é possível desenvolver aplicativos no Microsoft ASP .NET versão 2.0, que usa o Microsoft NET Framework versão 2.0 compatível com 64 bits. Para atender a esses aplicativos Web nativos de 64 bits, seria necessária uma configuração de servidor Web separada para executar o IIS em 64 bits nativos para hospedar esses aplicativos.

Microsoft.com muda para a versão x64 do Windows

Página 12

Observação: o IIS versão 7.0 fornecerá um método com suporte para executar processos de trabalho de 32 e 64 bits simultaneamente no mesmo servidor.

Vantagens A equipe de operações do Microsoft.com encontrou várias vantagens na migração para a plataforma x64. As vantagens imediatas foram melhorias significativas no desempenho do servidor Web individual e do site de forma geral.

Benefícios no desempenho A equipe de operações do Microsoft.com observou dois importantes benefícios no desempenho graças à migração do servidor Web do Microsoft.com para a plataforma baseada em x64. O primeiro benefício foi uma queda significativa na utilização da CPU devido à reciclagem menos freqüente ou inexistente do pool de aplicativos. A equipe de operações também observou que os pools de aplicativos não precisariam mais reciclar ou reciclariam com uma freqüência de semanas, em vez de minutos. As implicações disso no desempenho foram significativas. O gráfico do Monitor de Desempenho a seguir mostra uma queda de cerca de 50% no uso da CPU.

Figura 1. Utilização do processador de servidor de 64 bits

Microsoft.com muda para a versão x64 do Windows

Página 13

Figura 2. Utilização do processador de servidor de 32 bits Além da queda de 50% na utilização da CPU, os servidores de 32 bits experimentaram picos notáveis nos quais as CPUs eram 100% utilizadas por períodos de tempo toleráveis. A equipe de operações determinou que um pico ocorria quando um ou mais pools de aplicativos eram executados fora da memória virtual e reciclados. Nos servidores baseados em x64, esses picos não existem, pois os pools de aplicativos não são mais executados fora da memória. O segundo importante benefício no desempenho, e talvez o mais importante, foi o aumento significativo nos tempos de resposta dos aplicativos. Esse benefício leva diretamente a uma melhor experiência do usuário final. Como os servidores não precisam mais enfileirar nem manter conexões abertas para a reciclagem ou para aplicativos de desempenho insatisfatório próximo ao limite de memória virtual de 2 GB, os servidores podem responder de maneira mais rápida e mais condizente com as solicitações, como mostrado na tabela a seguir. Tabela 5. Tempos de resposta do x86 versus x64 Tipo de solicitação

Solicitações/ s de 32 bits

Tempo de reposta de 32 bits (milissegundos)

Solicitações/ s de 64 bits

Tempo de reposta de 64 bits (milissegundos)

ASP

7,85

244

7,41

53

ISAPI

110,85

248

125,43

18

Estático

41,9

135

31,01

3

Estático (em cache)

47,11

1

54,51

1

Microsoft.com muda para a versão x64 do Windows

Página 14

A equipe de operações observou os maiores aumentos de tempo de resposta para os que eram, historicamente, os aplicativos de pior desempenho. Os benefícios no desempenho desses aplicativos foram substanciais, como mostrado na tabela a seguir. Tabela 6. Aplicativos de pior desempenho Aplicativo

32 bits (segundos)

64 bits (segundos)

Benefício no desempenho

Aplicativo 1

79,3

5,1

15,5 X

Aplicativo 2

53,5

4,7

11,3 X

Aplicativo 3

49,4

2,8

17,7 X

Aplicativo 4

47,7

2,7

17,4 X

Aplicativo 5

44,8

2,6

17,4 X

Observação: o Microsoft Server Performance Advisor (SPA) que a equipe de operações do Microsoft.com usou para gerar esses números está disponível para download gratuito no site, em http://www.microsoft.com/downloads/details.aspx?FamilyID=61a41d78-e4aa-47b9901b-cf85da075a73&DisplayLang=en.

Consolidação do hardware É fácil concluir que há uma grande possibilidade de consolidação de servidor Web juntamente com uma migração para a plataforma baseada em x64. Teoricamente, o Microsoft.com poderia reduzir seu número de servidores Web em 50%. No entanto, a equipe de operações optou por não reduzir o número de servidores Web, pois queria que os servidores funcionassem com níveis de utilização mais baixos e mais consistentes e também desejava manter a capacidade adicional para acompanhar o crescimento contínuo do site. Essa capacidade adicional também proporciona redundância total do data center sem aumentar o número de servidores. Antes de mudar para a plataforma baseada em x64, uma falta de energia no data center inteiro resultaria em queda no desempenho durante sua duração. Na plataforma baseada em x64, o desempenho do site permanecerá relativamente estável no caso de falta de energia em um único data center.

Comportamentos do aplicativo Web Com um espaço de endereçamento de 2 GB, era extremamente difícil diferenciar um aplicativo com vazamento de memória de um aplicativo que estava simplesmente usando uma grande quantidade de memória como parte do comportamento normal, como para o armazenamento em cache. Com o aumento da memória virtual disponível para 4 GB, o uso de memória da última categoria de aplicativos geralmente alcança uma estabilidade entre 2 e 3 GB. Essa memória virtual adicional facilita a identificação de um aplicativo com vazamento de memória, pois seu uso de memória continuará a subir até o limite de 4 GB. Uma equipe de TI pode observar o aplicativo por períodos de tempo maiores, o que auxilia na eventual depuração do aplicativo. A plataforma baseada em x64 também possibilita criar mais pools de aplicativos, o que leva a um maior isolamento de código e conteúdo entre vários aplicativos Web. No futuro, os aplicativos criados no ASP.NET 2.0 serão ainda melhores quanto à confiabilidade e ao desempenho, pois podem endereçar 8 terabytes de memória virtual e podem ser executados no ambiente de sistema operacional nativo de 64 bits. O ASP.NET e o .NET Framework 2.0 também oferecem recursos avançados de diagnóstico e depuração.

Microsoft.com muda para a versão x64 do Windows

Página 15

PRÁTICAS

RECOMENDADAS

A prática recomendada mais óbvia e importante que o esforço de migração de servidor Web baseado em x64 do Microsoft.com revelou é migrar servidores Web de alto volume para a plataforma de hardware e software baseada em x64. Qualquer organização que esteja pensando em fazer essa migração deve realizar uma VDC para confirmar os benefícios no desempenho e identificar qualquer dependência de migração de código. Para isso, a equipe de operações do Microsoft.com recomenda as práticas recomendadas a seguir com base em sua experiência.

Verificação das dependências de terceiros Uma organização deve conhecer todas as dependências de terceiros e a disponibilidade das versões de aplicativos e drivers compatíveis com x64. Como parte da migração de qualquer plataforma, uma organização deve verificar e garantir a compatibilidade de qualquer dependência de terceiros no ambiente com o sistema operacional baseado em x64. Qualquer componente que exija um driver de modo kernel precisa ter um driver compatível com x64, pois os drivers de modo kernel de 32 bits não podem ser usados no sistema operacional baseado em x64. Algumas das dependências que a equipe de operações encontrou foram as seguintes:

•

Software antivírus

•

Software de backup

•

Software de geração de imagens e implantação

•

Ferramentas administrativas comuns que usam drivers de filtro, como Filemon e Regmon

Comportamento dos scripts Uma organização deve compreender plenamente suas dependências de scripts para saber qual host de script usar em determinadas circunstâncias. Os scripts que dependem de objetos COM de 32 bits exigirão versões de host de script cscript ou wscript de 32 bits localizadas na pasta %systemroot%\SysWow64. A organização deve fazer referência específica a esse caminho ao iniciar o host de scritp. Caso contrário, as versões padrão de 64 bits dos hosts de script serão iniciadas. Uma alternativa é alterar os hosts de script padrão para versões de 32 bits. Os scripts que usam hosts de script de 32 bits também precisam estar cientes dos comportamentos de redirecionamento do WoW64, como abordado na seção a seguir.

Comportamentos de redirecionamento de sistema de arquivos e Registro do WoW64 Uma organização deve familiarizar-se com os comportamentos de redirecionamento do WoW64 que ocorrem no Registro e no sistema de arquivos. Esses comportamentos de redirecionamento foram criados para ajudar os processos de 32 bits a funcionarem no ambiente de 64 bits.

Microsoft.com muda para a versão x64 do Windows

Página 16

Redirecionamento de sistema de arquivos No sistema operacional baseado em x64, sempre que um processo de 32 bits tenta acessar %systemroot%\system32, a camada do WoW64 redireciona-o automaticamente para %systemroot%\syswow64, que contém todos os binários do Windows de 32 bits. Isso evita que um processo de 32 bits tente carregar um binário de 64 bits. Redirecionamento do Registro Assim como no redirecionamento de sistema de arquivos, o mesmo comportamento ocorre ao acessar o Registro. Qualquer processo de 32 bits que tente ler ou gravar em HKEY_LOCAL_MACHINE\Software será redirecionado para HKEY_LOCAL_MACHINE\Software\Wow6432Node\. Esse comportamento permite que configurações separadas sejam mantidas em processos de 32 e 64 bits. Qualquer configuração ou chave personalizada definida nesse nó talvez precise ser incluída em ambas as chaves, pois um processo de 32 bits será redirecionado para essa nova ramificação.

Microsoft.com muda para a versão x64 do Windows

Página 17

CONCLUSÃO O Microsoft.com é um dos mais visitados e mais disponíveis sites da Internet. Embora tenha crescido continuamente na plataforma de 32 bits e apresentado níveis incomparáveis de disponibilidade e desempenho, as limitações de memória próprias da plataforma de 32 bits representavam um desafio específico para a equipe de operações. Esses desafios exigiam intervenção freqüente e tornavam difícil a solução de problemas e a depuração de aplicativos Web. A estratégia da equipe de operações do Microsoft.com de ser uma das primeiras a adotar as tecnologias da Microsoft tornou fácil a decisão de avaliar os benefícios de aumentar os limites de memória virtual implementando servidores criados em hardware e software baseados em x64. O projeto começou com uma verificação do conceito e progrediu rapidamente para a execução de versões de pré-lançamento do sistema operacional Windows baseado em x64 nos servidores de produção do Microsoft.com. Com a migração perfeita dos aplicativos de 32 bits que foi possível graças aos principais recursos do hardware e do sistema operacional baseados em x64, a equipe de operações pôde alcançar pleno sucesso na migração no momento em que a Microsoft lançou a versão x64 do Windows. Após a conclusão da transição para a plataforma baseada em x64, as limitações de memória que a equipe de operações enfrentou por anos desapareceram. As vantagens resultantes da eliminação dos problemas de contenção de memória permitirão ao Microsoft.com continuar a definir o padrão de disponibilidade do mercado e, ao mesmo tempo, aumentar bastante o desempenho atual e a capacidade futura do usuário final. A nova plataforma também possibilita a próxima leva de aplicativos Web de 64 bits criados em ASP.NET 2.0 pelo intermédio do .NET Framework 2.0 compatível com 64 bits. Espera-se que o desempenho desses aplicativos executados em um ambiente nativo de 64 bits seja ainda melhor que o dos aplicativos de 32 bits executados na plataforma x64. A principal finalidade deste documento é compartilhar práticas recomendadas e as lições aprendidas pela equipe de operações do Microsoft.com. No entanto, no caso de servidores Web com tráfego intenso, a lição mais evidente deste documento é que uma migração para a plataforma x64 pode gerar vantagens incríveis com um caminho de migração tranqüilo, fornecendo, ao mesmo tempo, uma possibilidade significativa de redução imediata de custos de hardware e de operações.

Microsoft.com muda para a versão x64 do Windows

Página 18

PARA

OBTER MAIS INFORMAÇÕES

Para obter mais informações sobre os produtos e serviços da Microsoft nos EUA, ligue para (800) 426-9400. No Canadá, ligue para o Microsoft Canada Information Centre - telefone (800) 563-9048. No Brasil, entre em contato com a Microsoft Informática Ltda., pelo telefone (11) 5853-2345. Para acessar informações na Internet, vá para: http://www.microsoft.com/brasil/ http://www.microsoft.com/technet/itshowcase As informações contidas neste documento representam o ponto de vista da Microsoft Corporation em relação aos assuntos abordados na data da publicação. Como a Microsoft deve responder às mudanças nas condições de mercado, este material não deve ser interpretado como um compromisso por parte da Microsoft e a Microsoft não poderá garantir a precisão de qualquer informação apresentada após a data da publicação. Este informe oficial é fornecido apenas para fins informativos. A MICROSOFT NÃO OFERECE QUAISQUER GARANTIAS, EXPLÍCITAS, IMPLÍCITAS OU ESTATUTÁRIAS NESTE DOCUMENTO. O cumprimento de todas as leis pertinentes de direitos autorais é de responsabilidade do usuário. Sem limitações à proteção de direitos autorais, nenhuma parte deste documento poderá ser reproduzida, armazenada ou colocada em um sistema de recuperação, transmitida de nenhuma forma nem por nenhum meio (eletrônico, mecânico, por fotocópia, gravação ou qualquer outro), ou para qualquer finalidade, sem a permissão expressa, por escrito, da Microsoft Corporation. A Microsoft pode deter as patentes, as solicitações de patentes, as marcas comerciais, os direitos autorais ou outras propriedades intelectuais pertinentes ao objeto deste documento. Salvo expressamente disposto em qualquer contrato de licença escrito da Microsoft, o fornecimento deste documento não confere a você qualquer licença em relação a essas patentes, marcas comerciais, direitos autorais ou outras propriedades intelectuais. © 2006 Microsoft Corporation. Todos os direitos reservados. Microsoft, SQL Server, Visual Studio, Windows e Windows Server são marcas registradas ou marcas comerciais da Microsoft Corporation nos Estados Unidos e/ou em outros países. Todas as outras marcas comerciais pertencem a seus respectivos proprietários.

Microsoft.com muda para a versão x64 do Windows

Página 19

APÊNDICE

A

Visão geral da arquitetura do Microsoft.com Esta seção oferece uma visão geral de alto nível da arquitetura do site Microsoft.com. Migrar os servidores Web para versões de 64 bits do Windows não exigiu nenhuma alteração na arquitetura, mas os recursos altamente redundantes da arquitetura permitiram uma migração tranqüila e uma capacidade granular de implantação e reversão. Os quatro princípios a seguir orientam o design do Microsoft.com:

•

Resiliência em toda parte

•

Manter a simplicidade

•

Configuração automatizada

•

Monitoramento com eventos que permitem ação

Resiliência em toda parte Para alcançar os mais altos níveis de disponibilidade e desempenho, a arquitetura do Microsoft.com deve ser resiliente ou redundante em cada etapa do caminho. As camadas de redundância começam com as redes de entrega de conteúdo e seguem até os componentes de servidor. Balanceamento global de carga e armazenamento em cache Os serviços Akamai FirstPoint e SAVVIS ITM oferecem funcionalidade de ponta de armazenamento de conteúdo em cache e balanceamento de carga global para que a carga seja igualmente compartilhada entre os data centers. O armazenamento em cache foi adicionado recentemente com base na latência significativa que o serviço de monitoramento Keynote Global 35 detectou em algumas localidades internacionais. O armazenamento em cache aumenta a disponibilidade para os usuários finais, mesmo quando o site já está altamente disponível nos data centers. A carga de tráfego para um data center específico é incrementalmente aumentada ou reduzida conforme necessário quando um cluster de servidores inteiro é removido do serviço em paralisações planejadas ou não do servidor ou da rede. Vários data centers Vários data centers proporcionam balanceamento de carga e resiliência para manter a continuidade dos negócios com a capacidade de direcionar o tráfego para outro data center durante manutenções na rede ou outras paralisações e mantendo, ao mesmo tempo, a disponibilidade total do site. Rede redundante O Microsoft.com não usa firewalls. Em vez disso, a equipe de operações de rede configura roteadores redundantes para que deixem passar apenas o tráfego dos protocolos HTTP e HTTPS. Nos data centers, a equipe de operações de rede configura todos os componentes da rede, como roteadores e opções, com opções de rede de alta disponibilidade, como o protocolo HSRP (Hot Standby Router Protocol).

Microsoft.com muda para a versão x64 do Windows

Página 20

Clusters NLB no servidor Web O NLB oferece balanceamento de carga e failover n+1 aos servidores Web e é incluído como parte de várias versões do Windows Server 2003. No Microsoft.com, há geralmente oito servidores Web por cluster NLB e todos atendem às solicitações ativamente. Com a mudança para as versões de 64 bits do Windows, há uma capacidade ampla no cluster que permite à equipe de operações remover um ou dois servidores se necessário, sem impacto no desempenho geral do cluster. Em cada data center, há vários clusters NLB em diferentes segmentos da rede local (LAN) para fornecer redundância entre clusters locais. Clusters do SQL Server O Microsoft.com também usa o NLB como meio de fornecer alta disponibilidade e balanceamento de carga aos servidores de banco de dados SQL Server 2000 e SQL Server 2005. O envio de log entre dois servidores em um cluster NLB e entre data centers é o principal método de redundância, pois os dados não são considerados essenciais para o site e alguma quantidade de perda de dados é aceitável. O envio de log é um método barato de alta disponibilidade, pois os servidores são completamente independentes e podem estar localizados em qualquer lugar sem a necessidade de tecnologias complexas de replicação da rede de área de armazenamento (redes SAN). Hardware do servidor O Microsoft.com adotou como padrão os modelos HP Proliant DL585 nos servidores Web baseados em x64 com quatro CPUs AMD de 2,2 GHz e 16 GB de RAM. Esses servidores de classe empresarial têm vários componentes redundantes, incluindo fontes de alimentação, adaptadores de rede e ventiladores de resfriamento. Além disso, têm capacidade para armazenamento em disco RAID (Redundant Array of Independent Disks) e configurações de RAM.

Manter a simplicidade O tamanho do Microsoft.com torna a arquitetura e as operações altamente complexas. Com tantos componentes de hardware e software, é importante simplificar a arquitetura o máximo possível. A criação de um único modelo de hospedagem da imagem do servidor Web, onde todos os servidores são idênticos e podem atender a qualquer aplicativo do site, permite uma arquitetura altamente simples e reproduzível.

Configuração automatizada Nos servidores Web do Microsoft.com, em particular, é fundamental que todos os servidores compartilhem a mesma configuração. Os usuários finais devem ter a mesma experiência e ver o mesmo conteúdo, independentemente do servidor ou dos servidores reais que estejam atendendo às solicitações. Para manter os 80 servidores Web do Microsoft.com idênticos, a equipe de operações desenvolveu um processo de compilação e configuração de servidor automatizado, bem como um processo de atualização automatizado. Para obter mais informações sobre as configurações de servidor do Microsoft.com, consulte a observação do IT Showcase sobre as configurações de servidor padrão de TI do Microsoft.com em http://www.microsoft.com/technet/itsolutions/msit/ (em inglês).

Microsoft.com muda para a versão x64 do Windows

Página 21

Monitoramento com eventos que permitem ação Assim como as configurações de servidor, o monitoramento de componentes individuais e do site Microsoft.com como um todo é uma tarefa árdua. Com milhares de componentes e centenas de aplicativos para monitorar, os eventos gerados para a equipe de suporte devem ser significativos e permitir ações. Para obter mais informações sobre o serviço de monitoramento e solução de problemas no Microsoft.com, consulte o estudo de caso do IT Showcase, Monitoring and Troubleshooting Microsoft.com, em http://www.microsoft.com/technet/itsolutions/msit/ (em inglês).

Microsoft.com muda para a versão x64 do Windows

Página 22