Administração do Windows

Introduzindo o Cluster de Failover do Windows Server 2008

Chuck Timon

 

Visão geral:

• Snap-in Gerenciamento de Cluster de Failover
• Novos recursos e aprimoramentos
• Funcionalidade de backup e restauração
• Migrando do Windows Server 2003

Conteúdo

Nova interface de gerenciamento
Processos de configuração aprimorados
Procedimento de validação incorporado
Novo modelo de quorum
Recursos de segurança aprimorados
Funcionalidade de sistema de rede expandida
Maior confiabilidade ao interagir com armazenamento
Processos de recuperação internos
Nova funcionalidade de backup e restauração
Migrando Clusters de Servidores do Windows Server 2003

Desde que o clustering foi introduzido no Windows NT 4.0 Enterprise Edition, os usuários reclamam que é muito difícil configurá-lo e muito pior mantê-lo. A administração de um cluster

exige que o administrador não apenas entenda o que é um clustering, mas também conheça as tecnologias de armazenamento e saiba como o serviço de cluster interage com as diversas soluções de armazenamento. Esse conjunto abrangente de habilidades necessário para colocar uma solução de alta disponibilidade em prática, e depois mantê-la, era difícil de encontrar em muitas organizações.

O clustering melhorou com os anos, mas ainda deixou muito a desejar quando a Microsoft começou a trabalhar no Windows Server® 2008. Com isso em mente, a equipe começou a recriar o clustering com o principal objetivo da simplicidade. No Windows Server 2008, o Microsoft® Cluster Services (MSCS) recebeu uma nova cara e agora é chamado de Cluster de Failover.

Isso não significa que simplicidade é a única coisa que a nova implementação do Cluster de Failover coloca em cena. Com os anos, a Microsoft aprendeu muitas lições, conforme as organizações forneceram comentários valiosos sobre o que gostariam de ver em uma solução de clustering atendida. A nova funcionalidade de Cluster de Failover trata de muitos dos principais problemas que os usuários relataram e também apresenta novos recursos interessantes que tornam essa proposta muito atraente. Assim, neste artigo, apresentarei alguns desses novos recursos interessantes que você encontrará no Cluster de Failover do Windows Server 2008.

Nova interface de gerenciamento

Depois de instalar o Cluster de Failover, a interface de gerenciamento de Cluster de Failover poderá ser acessada em Ferramentas Administrativas ou executando Cluadmin.msc. O snap-in Gerenciamento de Cluster de Failover, assim como outras interfaces de gerenciamento do Windows Server 2008, é um Microsoft Management Console (MMC) 3.0. Os veteranos em cluster, ao abrir o snap-in Gerenciamento de Cluster de Failover pela primeira vez, acharão que estão em um país estrangeiro sem nenhum mapa.

A nova interface é dividida em três painéis distintos, conforme mostrado na Figura 1. O painel esquerdo lista todos os Clusters de Failover do Windows Server 2008 em sua organização. O painel central fornece detalhes sobre a parte de uma configuração de cluster que você selecionou no painel esquerdo, e o painel direito mostra as ações que podem ser executadas.

Figura 1 Snap-in Gerenciamento de Cluster de Failover(clique na imagem para obter uma exibição ampliada)

Digamos, por exemplo, que você selecione Armazenamento no painel esquerdo. O painel central irá detalhar qual armazenamento foi provisionado no cluster e qual armazenamento, se houver, está disponível no momento. Como você pode ver na Figura 1, o cluster contém uma parte do armazenamento que oferece suporte a um disco testemunha, o armazenamento que foi provisionado para um Servidor de Arquivos e alguns armazenamentos disponíveis. O painel direito lista ações relevantes, como adicionar mais armazenamento. Observe que o snap-in Gerenciamento de Cluster de Failover não pode ser usado para administrar versões anteriores dos Serviços de Cluster da Microsoft.

Processos de configuração aprimorados

Configurar um Cluster de Failover é muito fácil. Muitas ações de configuração, reconfiguração e manutenção de um cluster possuem assistentes. Graças a eles, a administração não precisa mais se preocupar em saber se os recursos estão configurados corretamente ou se serão colocados online na ordem correta.

A Figura 2 mostra o Assistente para Alta Disponibilidade. Neste exemplo específico, um Servidor de Arquivos foi configurado. À esquerda, é possível ver a lista de etapas que o assistente apresentou ao administrador. Assim que o processo é concluído, uma página de resumo e um relatório são exibidos.

Figura 2 Assistente para Alta Disponibilidade (clique na imagem para obter uma exibição ampliada)

Procedimento de validação incorporado

Nas versões anteriores do Windows Server, que devemos considerar uma solução de cluster com suporte, as configurações de hardware tiveram de ser listadas como uma Solução de Cluster no Windows Server Catalog. Ele incluía clusters multissite, que foram listados separadamente na categoria Geographically Dispersed. A serem listados no catálogo, os fornecedores de hardware tiveram de executar um conjunto de testes do WHQL (Windows Hardware Quality Lab) e enviar os resultados à Microsoft. Foi uma proposta dispendiosa para o fornecedor, e o banco de dados do Windows Server Catalog era difícil de manter.

No Windows Server 2008, um processo de validação interno foi incluído no Cluster de Failover. Esse processo consiste em uma série de testes agrupados em quatro categorias principais, conforme mostrado na Figura 3.

Figura 3 Categorias do teste de validação de Cluster de Failover(clique na imagem para obter uma exibição ampliada)

Como você pode ver, a categoria Rede está expandida para mostrar os testes executados; cada categoria contém uma série de testes. A categoria Armazenamento, que talvez seja a mais crítica das quatro categorias, inclui testes que garantem que as soluções de armazenamento atendam aos novos requisitos que entraram em vigor para os Clusters de Failover do Windows Server 2008.

Especificamente, os fornecedores de hardware agora devem usar drivers baseados no driver Microsoft Storport e devem oferecer suporte às Reservas Persistentes SCSI-3. Além disso, os Módulos Específicos de Dispositivo de software de múltiplos caminhos, quando usados, devem se basear no padrão Microsoft MultiPath I\O.

Com a incorporação do processo de validação, o modelo de suporte foi alterado. Todo hardware deve ter um logotipo do Windows Server 2008 e todos os testes de validação devem ser aprovados. As únicas exceções são os clusters multissite que possuem dois compartimentos de armazenamento separados e distintos (um de cada lado) e a implementação de replicação contínua do Exchange Server 2007, que não usa nenhum armazenamento compartilhado.

Novo modelo de quorum

O Modelo de Quorum também foi alterado no Cluster de Failover do Windows Server 2008. Nos sistemas anteriores, quando um administrador ouvia a palavra quorum, imaginava um disco compartilhado no qual a configuração de cluster e alguns arquivos replicados residiam. Era um ponto único de falha no cluster. Se o disco de quorum falhasse, o serviço de cluster era encerrado e a alta disponibilidade era perdida.

Os Clusters de Servidores do Windows Server 2003 ofereciam um segundo tipo de quorum chamado Conjunto de Nós Principais. Esse tipo de quorum, em geral, era implementado em clusters multissite e não exigiam nenhum armazenamento compartilhado. O quorum Conjunto de Nós Principais consistia em um compartilhamento de arquivos que residia na unidade do sistema em cada nó de cluster. As conexões com esse tipo de quorum eram feitas por meio do protocolo SMB. Novamente, para que o cluster funcionasse, a maioria dos nós tinha de participar.

Depois, com a introdução da CCR (replicação contínua em cluster) do Exchange Server 2007, o recurso FSW (testemunha de compartilhamento de arquivos) foi adicionado aos Clusters de Servidores do Windows Server 2003. Ele permitia que um único nó de cluster CCR do Exchange 2007 (ou qualquer cluster multissite) continuasse a fornecer serviços enquanto uma conexão com o FSW resultasse na participação da maioria.

No Cluster de Failover do Windows Server 2008, o conceito de quorum agora significa consenso. O quorum, ou consenso, é alcançado obtendo votos suficientes para ativar o serviço do cluster. É possível obter votos suficientes de diversas maneiras, dependendo da configuração de quorum. Há quatro modos de quorum disponíveis em um Cluster de Failover do Windows Server 2008 e eles são mostrados na Figura 4. Dos quatro modelos listados, somente os dois primeiros (Maioria dos Nós e Maioria dos Nós e Discos) podem ser selecionados automaticamente durante o processo de criação de cluster. A seguinte lógica deve ser usada:

• Se um número ímpar de nós for configurado no cluster, selecione o modo Maioria dos Nós.
• Se um número par de nós for configurado no cluster e o armazenamento compartilhado estiver conectado e acessível, selecione Maioria dos Nós e Discos.

Figura 4 Modos de quorum no Assistente para Configurar Quorum do Cluster (clique na imagem para obter uma exibição ampliada)

Para selecionar um disco de testemunha do armazenamento disponível, selecione o primeiro disco contendo pelo menos 500 megabytes de tamanho e uma partição NTFS configurada. Os modos de quorum restantes só podem ser selecionados manualmente, executando o Assistente para Configurar Quorum do Cluster. A opção Maioria dos Nós e Compartilhamentos de Arquivos, em geral, é usada em uma configuração de cluster multissite ou em um cluster CCR do Exchange 2007. A última opção, o modo Sem Maioria: Somente Disco, é equivalente ao modelo de quorum compartilhado em clusters herdados. É um ponto único de falha e, se possível, não deve ser usada.

Há apenas dois tipos de recursos de testemunha, um disco físico e um compartilhamento de arquivo, que pode ser configurado no cluster para ajudar a alcançar o consenso.

Um disco de testemunha é uma parte do armazenamento que o serviço de cluster pode colocar online. Esse disco está localizado no Grupo Recursos Principais de Cluster com o Nome da Rede e os recursos de endereço IP associados. Quando o disco de testemunha é configurado, uma pasta Cluster é colocada no disco e uma cópia completa da configuração do cluster (um hive ou réplica do cluster) também é colocada no disco.

Um FSW é um compartilhamento de rede localizado, em uma situação ideal, em um servidor na rede que não faça parte do cluster. Uma conexão SMB é feita com o FSW, que mantém uma cópia do arquivo de log de testemunha contendo informações sobre versão para a configuração do cluster.

Só pode haver um recurso de testemunha configurado em um cluster. Esse recurso fornece um voto extra caso o cluster precise disso para alcançar o quorum. Em outras palavras, se faltar um voto (e portanto um nó) para o cluster alcançar um consenso, o recurso de testemunha será colocado online para que o quorum seja alcançado. Se faltar mais de um voto para o cluster alcançar o quorum, o recurso de testemunha será abandonado e o cluster permanecerá em um estado inativo, aguardando a junção de outro nó de cluster.

Recursos de segurança aprimorados

Os Clusters de Failover apresentam vários novos aprimoramentos de segurança. Talvez o mais significativo envolva a remoção do requisito de uma CSA (conta de serviço de cluster). Nas versões anteriores do Microsoft Cluster Service, uma conta de usuário de domínio era necessária durante o processo de configuração. Essa conta, que foi usada para iniciar o serviço de cluster, foi adicionada ao grupo de administradores locais em cada nó do cluster, obtendo os direitos de usuário local necessários para permitir que o serviço de cluster funcionasse corretamente. Como uma conta de usuário de domínio, a CSA estava sujeita a várias diretivas no nível de domínio que podiam ser aplicadas aos nós de cluster. Essas diretivas podiam afetar negativamente a alta disponibilidade causando uma falha no serviço de cluster.

O serviço de cluster agora é executado sob uma conta do sistema local com um conjunto específico de direitos no nó do cluster local que permite que ela funcione adequadamente. O contexto de segurança para o cluster foi transferido para o CNO (objeto de nome de cluster), que é o objeto do computador criado, por padrão, no contêiner Computadores do Active Directory® assim que o cluster é criado. Quando um cluster é criado com êxito e o CNO existe no Active Directory, a conta de usuário usada para instalar e configurar o cluster se torna desnecessária.

Os objetos de computador adicionais criados no Active Directory do contêiner Computadores são adicionados a um Cluster de Failover. Esses objetos, chamados de VCOs (objetos de computador virtual), se equiparam aos recursos Nome de Rede do cluster que é criado como parte dos CAPs (pontos de acesso do cliente) no cluster. O CNO, que é responsável por criar todos os VCOs em um cluster, é adicionado à SACL (lista de controle de acesso do sistema) para o objeto no Active Directory (consulte a Figura 5).

Figura 5 Segurança em um VCO no Active Directory (clique na imagem para obter uma exibição ampliada)

O CNO também assume a responsabilidade de sincronizar as senhas de domínio para todos os VCOs que ele criou. Esse processo é realizado de acordo com a diretiva de domínio configurada para a rotação de senha. Além disso, como o CNO é responsável por criar todos os objetos do computador associados aos VCOs em um cluster, o CNO (Conta de Computador) deve ter o direito no nível de domínio para criar objetos de computador no contêiner em que os VCOs são criados (por padrão, no contêiner Computadores).

Outra alteração é que o Kerberos agora é usado como o método de autenticação padrão. A existência de contas de computador no Active Directory permite esse recurso de segurança aprimorado. Mas o cluster possui a capacidade de usar a autenticação do protocolo NTLM sempre que um aplicativo que não pode usar Kerberos na autenticação precisa acessar os recursos de cluster.

A comunicação entre os nós de cluster que lidam diretamente com o processo de cluster também é mais segura. Toda a comunicação dentro do cluster é assinada por padrão. Usando a CLI (interface de linguagem comum) cluster.exe, essa propriedade do cluster pode ser alterada para que toda comunicação entre os nós seja criptografada para fornecer um nível de segurança adicional.

Funcionalidade de sistema de rede expandida

Os novos recursos de sistema de rede nos Clusters de Failover fornecem mais flexibilidade ao criar soluções de alta disponibilidade e recuperação de desastre. Ao mesmo tempo, esses novos aprimoramentos de sistema de rede fornecem uma conectividade mais confiável entre os nós no cluster.

Provavelmente, o recurso de cliente mais solicitado foi a capacidade de localizar nós de cluster em redes separadas. Agora isso é possível. O driver de rede de cluster foi completamente reescrito para fornecer uma comunicação tolerante a falhas altamente confiável entre os nós de um cluster, desde que cada nó esteja conectado a pelo menos duas redes separadas e roteadas de forma distinta.

O driver de rede de cluster constrói sua própria tabela de roteamento interno com base nas informações de conectividade fornecidas durante o processo de inicialização de cluster. Isso inclui as informações de conectividade local bem com as que são fornecidas no banco de dados de configuração de cluster (hive do registro de cluster).

Parte do processo de validação de cluster inclui um processo de descoberta de conectividade de rede. A capacidade de localizar nós de cluster em redes roteadas diferentes diminuiu os requisitos do sistema de rede para clusters multissite. Ela tornará sua implantação mais fácil e menos dispendiosa para as organizações. Além disso, ela usa o armazenamento iSCSI, uma solução de armazenamento atraente para uso em Clusters de Failover.

Os nós de cluster também podem obter informações do Endereço IP por meio do protocolo DHCP. Isso poderá diminuir o trabalho dos administradores de rede, caso aceitem o uso de endereçamento dinâmico para os servidores no seu ambiente.

A configuração de interfaces de rede de um nó de cluster determina as redes que usarão endereços IP estáticos ou dinâmicos. Mesmo que um recurso de endereço IP em um cluster seja obtido de um servidor DHCP, ele poderá ser alterado para um endereço IP no snap-in Gerenciamento de Cluster de Failover.

No passado, toda comunicação de cluster usava a difusão do protocolo UDP e, às vezes, multicast. A funcionalidade multicast foi descontinuada e as comunicações de cluster agora usam UDP unicast (3343 ainda é a porta comum usada pelos clusters da Microsoft). Muitos administradores de rede ficarão felizes ao ver que a difusão não é mais usada. A verdadeira compensação em um cluster, porém, tem a ver com os novos processos de mensagens que são internos do próprio serviço de cluster (isso, contudo, está além do escopo deste artigo). As comunicações dentro do cluster agora possuem características de comunicação TCP mais confiáveis, muito embora UDP seja usado como mecanismo de transporte.

Maior confiabilidade ao interagir com armazenamento

A forma como os Clusters de Failover interagem com o armazenamento é totalmente diferente. O driver de disco do cluster (clusdisk.sys) foi completamente reescrito e agora é um verdadeiro driver Plug and Play (PnP). Além disso, a forma como ele interage com o armazenamento mudou.

No Windows Server 2003, o driver de disco do cluster ficava em um caminho direto até o armazenamento. Mas, no Windows Server 2008, o driver de disco do cluster se comunica com o driver do gerenciador de partições (partmgr.sys) para interagir com o armazenamento. Essas duas abordagens são ilustradas na Figura 6.

Figura 6 Como a pilha do armazenamento foi alterada no Windows Server 2008 (clique na imagem para obter uma exibição ampliada)

O gerenciador de partições tem como responsabilidade principal proteger os recursos de disco do cluster. Todos os discos em um barramento de armazenamento compartilhado são colocados automaticamente em um estado offline assim que são mapeados para um nó de cluster. Isso permite que o armazenamento seja mapeado simultaneamente para todos os nós em um cluster antes mesmo que o cluster seja criado. Não é mais necessário que os nós sejam iniciados individualmente, os discos preparados em um nó e depois o nó desligado, outro nó iniciado, a configuração de disco verificada, e assim por diante.

Ainda há, contudo, os testes de armazenamento, que são executados como parte do processo de validação de cluster e exigem que os discos sejam inicializados. Isso pode ser feito em um dos nós do cluster antes que o processo de validação seja executado. Assim que o armazenamento é adicionado a um cluster, os discos mostram um status Reservado na interface de Gerenciamento de Disco e nunca ficam em um estado desprotegido.

Outra alteração tem a ver com os comandos SCSI. No Windows Server 2003, os comandos SCSI-2 Reserve\Release eram usados com o driver de disco de cluster gravando em setores no próprio disco. No Windows Server 2008, os comandos SCSI-3 PR (Reserva Persistente) são necessários. Os nós de cluster devem ser registrados antes de poder colocar uma reserva no armazenamento, e os nós de cluster periodicamente defendem suas reservas usando o Protocolo de Registro e Defesa.

Um dos testes de armazenamento no processo de validação verifica essa funcionalidade. Se a solução de armazenamento não oferecer suporte aos comandos SCSI-3 (PR) é porque não possui suporte em um Cluster de Failover.

Muitas organizações usam software de múltiplos caminhos para redundância ao se conectar ao armazenamento. É uma solução com suporte e até mesmo divulgada como prática recomendada. Entretanto, as soluções de software de múltiplos caminhos de terceiros, ou módulos específicos de dispositivo, devem ser reescritas usando o padrão Microsoft MultiPath I\O para obter suporte em um Cluster de Failover. Isso garante que todos os comandos SCSI-3 PR sejam enviados simultaneamente por todos caminhos até o armazenamento, quer os caminhos estejam ativos ou não. Essa funcionalidade também é verificada como parte do processo de validação.

Os aprimoramentos de armazenamento adicionais incluem um processo de disco de verificação aprimorado (chkdsk.exe), a funcionalidade interna de reparo de disco que antes fazia parte do Utilitário de Recuperação do Servidor de Cluster e discos de auto-recuperação. Nos Clusters de Failover, a assinatura do disco e o LUN ID são usados ao identificar um recurso de disco do cluster. Se um deles for alterado, a configuração de cluster será atualizada. Isso significa menos erros por causa de uma simples alteração de atributo em um recurso de disco físico resultando em ainda mais disponibilidade.

Processos de recuperação internos

O reparo de disco mencionado anteriormente, sem dúvida, é um dos recursos internos de recuperação. Outro recurso é o Reparo do Active Directory. Se o objeto de computador que representa o CNO for excluído, você não poderá mais criar os objetos de computador associados aos CAPs do cluster. Entretanto, o primeiro problema surgirá provavelmente quando os aplicativos de alta disponibilidade ou os usuários não ganharem acesso aos recursos fora do cluster porque um token de segurança não pode ser obtido.

A recuperação de um CNO excluído é um processo de duas etapas. Primeiro, você deve fazer um Administrador de Domínio recuperar o objeto de computador excluído do contêiner DeletedObjects no Active Directory. Então, depois que o objeto for restaurado e reabilitado, você deverá executar o processo Reparar Objeto do Active Directory no snap-in Gerenciamento de Cluster de Failover.

Nos Clusters de Servidores do Windows Server 2003, havia uma possibilidade de que o arquivo de configuração de cluster localizado no subdiretório %systemroot%\cluster se tornasse corrompido e tivesse de ser substituído. Nos Clusters de Failover, o recurso de auto-recuperação pode ajudar. Se o serviço de cluster for iniciado em um nó e o banco de dados de configuração for corrompido, um modelo de configuração mínima será carregado usando as informações contidas na chave de registro HKLM\System\CCS\Services\ClusSvc\Parameters. O nó tentará se unir a um cluster já formado e, se essa tentativa tiver êxito, uma cópia nova do hive do registro de cluster será enviada por push ao nó. Se um nó não puder se unir a um cluster, o serviço de cluster será encerrado.

Nova funcionalidade de backup e restauração

O Cluster de Failover vem com seu próprio gravador Serviço de Cópias de Sombra de Volume. Ele exerce uma função importante ao fazer backup e restaurar um banco de dados de clusters e os dados que residem nos recursos do disco físico. O backup da configuração de cluster é muito simples. Contanto que o estado do sistema faça parte de um backup, a configuração de cluster poderá ser restaurada. Mas observe que só será possível fazer backup de um cluster se ele tiver quorum. Isso garante que seja feito o backup da configuração de cluster mais atualizada.

Há dois tipos de restauração de cluster distintos: autoritativo e não-autoritativo. Uma restauração não-autoritativa usa o Backup do Windows Server ou um aplicativo de backup de terceiros para executar uma restauração de um backup selecionado. Uma restauração autoritativa de um nó de cluster, entretanto, só pode ser realizada usando o CLI (wbadmin.exe) de Backup do Windows Server.

Uma restauração autoritativa basicamente "volta no tempo" e usa a configuração de cluster existente quando o backup foi executado. Para realizar uma restauração autoritativa, o serviço de cluster é interrompido em todos os nós, exceto naquele no qual a restauração está sendo executada. Assim que a restauração é concluída e o serviço de cluster iniciado no nó restaurado, a configuração restaurada do cluster se torna a nova configuração de cluster definitiva. Assim, quando o serviço de cluster é reiniciado nos nós restantes do cluster, a configuração restaurada é enviada por push durante o processo de junção.

Esse procedimento pode economizar bastante tempo e dinheiro em alguns cenários. Suponha que você tem um cluster de impressão que hospeda vários recursos de spooler de impressão, cada um oferecendo suporte a 1.500 impressoras, e acidentalmente exclui um deles. Agora, um grande número de usuários não poderá imprimir. Em vez de adicionar manualmente todas as impressoras à configuração de cluster, é muito mais rápido realizar uma restauração autoritativa da configuração de cluster. Isso, é claro, se você tiver uma boa estratégia de backup e restauração.

Migrando Clusters de Servidores do Windows Server 2003

Devido a todas essas alterações de arquitetura no Cluster de Failover do Windows Server 2008, não há suporte para atualizações sem interrupção ou in-loco do Windows Server 2003. Ao atualizar clusters do Windows Server 2000 para o Windows Server 2003, muitas organizações deveriam remover sistematicamente cada nó no cluster, fazer uma instalação limpa do sistema operacional e, depois, adicionar o nó ao cluster. Essa abordagem não pode ser usada para migrar para o Windows Server 2008, pois os nós de cluster do Windows Server 2003 e do Windows Server 2008 não fazem parte do mesmo cluster.

Felizmente, para ajudar na migração, foi incluído um processo de migração baseado em assistente. Mas a migração para um Cluster de Failover do Windows Server 2008, ainda assim, exigirá um planejamento. Há três cenários de migração básicos:

• Usando os mesmos servidores e armazenamento.
• Usando os mesmos servidores, mas com novo armazenamento.
• Usando novos servidores e novo armazenamento.

Qualquer um desses cenários exige que o hardware seja certificado com o programa de logotipo do Windows Server 2008 e que o processo de validação do Cluster de Failover seja executado e todos os testes aprovados. Depois de concluir essas etapas, o processo de migração pode continuar.

Nem todos os recursos em um Cluster de Servidores do Windows Server 2003 podem ser migrados. Você pode migrar nomes de rede, endereços IP, discos físicos, compartilhamentos de arquivo, raízes DFS (compartilhamento de arquivo distribuído), DHCP e WINS. Você também pode migrar, até um limite, serviços, aplicativos e recursos de script genéricos.

Enquanto isso, aplicativos como o Microsoft Exchange e o SQL Server® possuem seus próprios procedimentos para migrar para um Cluster de Failover. As impressoras podem ser migradas para o Windows Server 2008 usando o snap-in Gerenciamento de Impressão (que é instalado com a Função de Servidor de Impressão) para primeiro exportar e depois importar impressoras para um servidor de impressão altamente disponível e recentemente configurado. Nenhum tipo de recurso de terceiros é qualificado para migração.

O processo de migração não migra nenhum dado. Ele envolve a migração das definições da configuração de cluster do Windows Server 2003 para o Windows Server 2008.

Todos os recursos migrados são colocados inicialmente em um estado offline quando o processo de migração é concluído. Isso é feito porque pode haver outras etapas necessárias. Portanto, é importante revisar o relatório de pós-migração para ver quais etapas adicionais (exclusivas da migração de dados se for para um novo armazenamento) são necessárias antes de colocar o cluster em serviço. Como exemplo, se um servidor DHCP for migrado, a Função de Servidor DHCP deverá ser instalada em todos os nós no cluster. Ao migrar um Servidor WINS, o recurso Servidor WINS deverá ser instalado em todos os nós no cluster.

Chuck Timon é engenheiro de escalonamento de suporte da Microsoft e oferece suporte a tecnologias de Cluster e Configuração. É autor do curso de Cluster de Failover do Windows Server 2008 e atualmente está desenvolvendo o curso sobre Hyper-V.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. É proibida a reprodução total ou parcial sem autorização.