Quando a descoberta de nó ativo está habilitada (padrão) no ambiente do PlateSpin, a migração de um cluster do Windows é realizada por meio de replicações incrementais das mudanças no nó ativo direcionadas a um cluster virtual de um nó. Se você desabilitar a descoberta do nó ativo, cada nó de um cluster do Windows poderá ser descoberto e migrado como um nó independente.
Antes de você configurar os clusters do Windows para migração, verifique se o seu ambiente atende aos pré-requisitos e se você conhece as condições para migrar cargas de trabalho do cluster.
O escopo de suporte para migração do cluster está sujeito às condições descritas na Tabela 25-1. Ao configurar a migração para clusters em seu ambiente do PlateSpin, considere estes requisitos.
Tabela 25-1 Requisitos de Migração do Cluster
|
Requisito |
Descrição |
|---|---|
|
Descobrir o nó ativo como um Cluster do Windows |
A configuração global do PlateSpin DiscoverActiveNodeAsWindowsCluster determina se os clusters do Windows são migrados como clusters ou máquinas independentes separadas:
Consulte a Seção 25.2, Configurando a descoberta de nó ativo do Windows. |
|
Valores de pesquisa de nome de recurso |
A configuração global do PlateSpin MicrosoftClusterIPAddressNames determina os nomes de recurso de cluster que podem ser descobertos em seu ambiente do PlateSpin. Você deve configurar valores de pesquisa que ajudam a diferenciar o nome do recurso compartilhado de Endereço IP do Cluster do nome de outros recursos de endereço IP no cluster. Consulte a Seção 25.4, Adicionando valores de pesquisa de nome de recurso. |
|
Modo de Cluster do Windows |
A configuração global do PlateSpin WindowsClusterMode determina o método de transferência de dados com base em blocos para replicações incrementais:
Consulte o seguinte: |
|
Endereço IP ou nome de host do nó ativo |
Você deve especificar o nome de host ou endereço IP do nó ativo do cluster ao executar uma operação Add Workload. Devido às mudanças de segurança feitas pela Microsoft, os clusters do Windows não podem mais ser descobertos usando o nome do cluster virtual (ou seja, o endereço IP do cluster compartilhado). |
|
Nome de host resolvível |
O Servidor do PlateSpin deve ser capaz de resolver o nome de host de cada um dos nós no cluster por seu endereço IP. NOTA:As pesquisas DNS diretas e inversas são necessárias para resolver o nome de host por endereço IP. |
|
Recurso de quorum |
O recurso de quorum do cluster deve ser colocalizado no nó com o grupo de recursos do cluster (serviço) que está sendo migrado. |
|
Semelhança de nós do cluster |
No modo de Cluster do Windows padrão, a sincronização sem driver poderá continuar de qualquer nó que se tornar ativo, se os nós forem semelhantes. Se eles não corresponderem, as replicações poderão ocorrer apenas no nó ativo descoberto originalmente. Consulte Semelhança de nó de cluster. |
|
PowerShell 2.0 |
O Windows PowerShell 2.0 deve ser instalado em cada nó do cluster. |
A transferência com base em blocos para clusters funciona de forma diferente do que para servidores independentes. A replicação inicial faz uma cópia completa (total) ou usa um método de sincronização sem driver executado no nó ativo do cluster. As replicações incrementais seguintes podem usar um método sem driver ou o método com base em driver para a transferência de dados com base em blocos.
NOTA:O PlateSpin Migrate não suporta a transferência com base no arquivo para clusters.
A configuração global do PlateSpin WindowsClusterMode determina o método de transferência de dados com base em blocos para replicações incrementais:
Padrão: Sincronização sem driver usando uma replicação baseada em MD5 no nó atualmente ativo.
SingleNodeBBT: Sincronização com base em driver usando um driver BBT instalado no nó ativo originalmente descoberto.
Ambos os métodos suportam a replicação no nível de blocos do armazenamento local e do armazenamento compartilhado em SANs Fibre Channel e iSCSI.
A Tabela 25-2 descreve e compara os dois métodos.
Tabela 25-2 Comparação entre os métodos de transferência de dados com base em blocos para replicação incremental
|
Consideração |
BBT Padrão |
BBT de Nó Único |
|---|---|---|
|
Método de transferência de dados |
Usa a sincronização sem driver com uma replicação baseada em MD5 no nó ativo no momento. |
Usa um driver BBT instalado no nó ativo descoberto originalmente. |
|
Desempenho |
Replicações incrementais potencialmente lentas. |
Melhora significativamente o desempenho das replicações incrementais. |
|
Clusters do Windows Suportados |
Funciona com qualquer cluster do Windows Server suportado. |
Funciona com clusters do Windows Server 2008 R2 e posteriores. Outros clusters do Windows suportados usam o método de sincronização sem driver para replicação. |
|
Drivers |
|
|
|
Primeira replicação incremental |
Usa a sincronização sem driver no nó ativo. |
Usará a transferência com base em blocos e driver no nó ativo descoberto originalmente se uma replicação completa for concluída após a instalação do driver BBT. Do contrário, usará a sincronização sem driver no nó ativo descoberto originalmente. |
|
Replicação incremental subsequente |
Usa a sincronização sem driver no nó ativo. |
Usa a transferência com base em blocos e driver no nó ativo descoberto originalmente. Se um cluster alternar os nós, o método de sincronização sem driver será usado para a primeira replicação incremental depois que o nó ativo originalmente voltar a ser ativo. Consulte Impacto do failover de nó de cluster na replicação. |
A Tabela 25-3 descreve o impacto do failover de nó de cluster na replicação e as ações necessárias para o administrador do Migrate.
Tabela 25-3 Impacto do Failover de Nó de Cluster na Replicação
|
Failover ou Failback de Nó de Cluster |
BBT Padrão |
BBT de Nó Único |
|---|---|---|
|
O failover de nó de cluster ocorre durante a primeira replicação completa |
Há uma falha na replicação. A primeira replicação completa deve ser concluída com êxito sem um failover de nó de cluster.
|
|
|
O failover de nó de cluster ocorre durante uma replicação completa subsequente ou uma replicação incremental subsequente |
O comando de replicação é interrompido, e uma mensagem é exibida indicando que a replicação precisa ser executada novamente. Se o perfil do novo nó ativo for semelhante ao do nó ativo com falha, o contrato de migração permanecerá válido.
Se o perfil do novo nó ativo não for semelhante ao do nó ativo com falha, o contrato de migração será válido apenas no nó originalmente ativo.
|
O comando de replicação é interrompido, e uma mensagem é exibida indicando que a replicação precisa ser executada novamente. O contrato de migração é válido apenas no nó ativo descoberto originalmente.
Esta primeira replicação incremental após um evento de failover/failback de cluster usa automaticamente a sincronização sem driver. As replicações incrementais subsequentes usarão o driver com base em blocos conforme especificado pelo BBT de nó único. |
|
O failover de nó de cluster ocorre entre as replicações |
Se o perfil do novo nó ativo for semelhante ao do nó ativo com falha, o contrato de migração continuará conforme programado para a próxima replicação incremental. Do contrário, haverá falha no próximo comando de replicação incremental. Se houver falha em uma replicação incremental programada:
|
Haverá falha na replicação incremental se o nó ativo alternar entre as replicações.
Esta primeira replicação incremental após um evento de failover/failback de cluster usa automaticamente a sincronização sem driver. As replicações incrementais subsequentes usarão o driver com base em blocos conforme especificado pelo BBT de nó único. |
No Modo de Cluster do Windows padrão, os nós de cluster devem ter perfis semelhantes para evitar interrupções no processo de replicação. Os perfis dos nós de cluster serão considerados semelhantes se todas as condições a seguir forem atendidas:
Os números de série para volumes locais dos nós (volume de Sistema e volume de Sistema Reservado) devem ser os mesmos em cada nó do cluster.
NOTA:Use o utilitário Volume Manager para mudar os números de série do volume local para que correspondam a cada nó do cluster. Consulte Sincronizando números de série no armazenamento local do nó do cluster.
Se os volumes locais em cada nó do cluster tiverem números de série diferentes, você não poderá executar uma replicação após um failover de nó de cluster. Por exemplo, durante um failover de nó de cluster, há uma falha no Nó ativo 1, e o software de cluster torna o Nó 2 ativo. Se as unidades locais nos dois nós tiverem números de série diferentes, haverá falha no próximo comando de replicação para a carga de trabalho.
Os nós devem ter o mesmo número de volumes.
Cada volume deve ser exatamente do mesmo tamanho em cada nó.
Os nós devem ter um número idêntico de conexões de rede.
Para configurar a migração para um cluster do Windows, siga o workflow de migração de carga de trabalho normal. Forneça o nome de host ou endereço IP do nó ativo do cluster.
O PlateSpin Migrate suporta o uso de discos RDM (Raw Device Mapping – Mapeamento de Dispositivos Brutos) compartilhados (FC SAN) em VMs de destino para a migração semiautomatizada de um Cluster de Failover do Windows Server (WSFC) para VMware, em que cada nó de VM de destino reside em um host diferente em um Cluster do VMware. Consulte Migração avançada do cluster do Windows para VMs VMware com discos RDM.