Considerações ao usar o ONTAP em uma configuração do MetroCluster
Sugerir alterações
PDFs
Ao usar o ONTAP em uma configuração do MetroCluster, você deve estar ciente de certas considerações sobre licenciamento, peering para clusters fora da configuração do MetroCluster, execução de operações de volume, operações NVFAIL e outras operações do ONTAP.
A configuração do ONTAP dos dois clusters, incluindo a rede, deve ser idêntica, porque o recurso MetroCluster depende da capacidade de um cluster de servir dados de forma otimizada para seu parceiro no caso de um switchover.
Considerações sobre licenciamento
-
Ambos os sites devem ser licenciados para os mesmos recursos licenciados pelo site.
-
Todos os nós devem ser licenciados para os mesmos recursos de bloqueio de nó.
Consideração de SnapMirror
-
A recuperação de desastres do SnapMirror SVM só é compatível com configurações do MetroCluster executando versões do ONTAP 9.5 ou posterior.
Operações do MetroCluster no Gerenciador de sistemas do ONTAP
Dependendo da versão do ONTAP, algumas operações específicas do MetroCluster podem ser executadas usando o Gerenciador de sistemas do ONTAP.
Para saber mais, consulte "Gerencie sites do MetroCluster com o Gerenciador de sistemas"a documentação.
Suporte FlexCache em uma configuração MetroCluster
A partir do ONTAP 9.7, os volumes FlexCache são compatíveis com configurações do MetroCluster. Você deve estar ciente dos requisitos para a repetibilidade manual após operações de comutação ou switchback.
Repetibilidade da SVM após o switchover quando a origem e o cache do FlexCache estão no mesmo local do MetroCluster
Após um switchover negociado ou não planejado, qualquer relacionamento de peering SVM FlexCache no cluster deve ser configurado manualmente.
Por exemplo, svms VS1 (cache) e VS2 (origem) estão no site_A. Esses SVMs são peered.
Após o switchover, os svms VS1-MC e VS2-mc são ativados no local do parceiro (site_B). Eles devem ser repelidos manualmente para que o FlexCache funcione usando o comando vserver peer repeer.
Repetibilidade da SVM após switchover ou switchback quando um destino FlexCache está em um terceiro cluster e no modo desconetado
Para relacionamentos do FlexCache com um cluster fora da configuração do MetroCluster, o peering deve ser sempre reconfigurado manualmente após um switchover, se os clusters envolvidos estiverem no modo desconetado durante o switchover.
Por exemplo:
-
Um fim do FlexCache (cache_1 no VS1) reside no MetroCluster site_A tem um fim do FlexCache
-
A outra extremidade do FlexCache (origin_1 no VS2) reside no site_C (não na configuração do MetroCluster)
Quando o switchover é acionado, e se o site_A e o site_C não estiverem conetados, você deve repelir manualmente os SVMs no site_B (o cluster de switchover) e site_C usando o comando vserver peer repetier após o switchover.
Quando o switchback é executado, você deve repelir novamente os SVMs no site_A (o cluster original) e site_C.
Suporte FabricPool em configurações MetroCluster
A partir do ONTAP 9.7, as configurações do MetroCluster são compatíveis com camadas de storage FabricPool.
Para obter informações gerais sobre como usar o FabricPools, "Gerenciamento de disco e camada (agregado)" consulte .
Considerações ao usar FabricPools
-
Os clusters precisam ter licenças FabricPool com limites de capacidade correspondentes.
-
Os clusters devem ter IPspaces com nomes correspondentes.
Esse pode ser o espaço IPspace padrão ou um espaço IP criado por um administrador. Este espaço IPspace será usado para configurações de armazenamento de objetos FabricPool.
-
Para o espaço IPspace selecionado, cada cluster deve ter um LIF entre clusters definido que possa alcançar o armazenamento de objetos externo
Configurando um agregado para uso em um FabricPool espelhado
|
Antes de configurar o agregado, você deve configurar armazenamentos de objetos conforme descrito em "Configurando armazenamentos de objetos para FabricPool em uma configuração MetroCluster" em "Gerenciamento de disco e agregado". |
Para configurar um agregado para uso em um FabricPool:
-
Crie o agregado ou selecione um agregado existente.
-
Espelhe o agregado como um agregado espelhado típico na configuração do MetroCluster.
-
Crie o espelho FabricPool com o agregado, conforme descrito em "Gerenciamento de disco e agregado"
-
Anexe um armazenamento de objetos primário.
Este armazenamento de objetos está fisicamente mais perto do cluster.
-
Adicione um armazenamento de objetos espelhados.
Este armazenamento de objetos está fisicamente mais distante do cluster do que o armazenamento de objetos primário.
-
Suporte FlexGroup em configurações MetroCluster
A partir do ONTAP 9.6, as configurações do MetroCluster são compatíveis com volumes FlexGroup.
Programações de trabalhos em uma configuração MetroCluster
No ONTAP 9.3 e posterior, as programações de tarefas criadas pelo usuário são replicadas automaticamente entre clusters em uma configuração do MetroCluster. Se você criar, modificar ou excluir um agendamento de trabalho em um cluster, o mesmo agendamento será criado automaticamente no cluster de parceiros, usando o CRS (Configuration Replication Service).
|
|
As programações criadas pelo sistema não são replicadas e você deve executar manualmente a mesma operação no cluster de parceiros para que as programações de tarefas em ambos os clusters sejam idênticas. |
Peering de cluster do site MetroCluster para um terceiro cluster
Como a configuração de peering não é replicada, se você identificar um dos clusters na configuração do MetroCluster para um terceiro cluster fora dessa configuração, você também deverá configurar o peering no cluster do MetroCluster parceiro. Isso é para que o peering possa ser mantido se ocorrer um switchover.
O cluster que não é MetroCluster deve estar executando o ONTAP 8,3 ou posterior. Caso contrário, o peering é perdido se ocorrer um switchover, mesmo que o peering tenha sido configurado em ambos os parceiros da MetroCluster.
Replicação de configuração de cliente LDAP em uma configuração MetroCluster
Uma configuração de cliente LDAP criada em uma máquina virtual de storage (SVM) em um cluster local é replicada para os dados de parceiros SVM no cluster remoto. Por exemplo, se a configuração do cliente LDAP for criada no SVM admin no cluster local, ela será replicada para todos os SVMs de dados administrativos no cluster remoto. Esse recurso do MetroCluster é intencional para que a configuração do cliente LDAP esteja ativa em todos os SVMs de parceiros no cluster remoto.
Diretrizes de criação de LIF e rede para configurações do MetroCluster
Você deve estar ciente de como LIFs são criados e replicados em uma configuração do MetroCluster. Você também deve saber sobre o requisito de consistência para que você possa tomar as decisões adequadas ao configurar sua rede.
Requisitos de replicação de objeto IPspace e configuração de sub-rede
Você deve estar ciente dos requisitos para replicar objetos IPspace no cluster de parceiros e para configurar sub-redes e IPv6 em uma configuração do MetroCluster.
Replicação IPspace
Você deve considerar as diretrizes a seguir enquanto replica objetos IPspace para o cluster de parceiros:
-
Os nomes de IPspace dos dois locais devem corresponder.
-
Os objetos IPspace devem ser replicados manualmente para o cluster do parceiro.
Quaisquer máquinas virtuais de armazenamento (SVMs) que sejam criadas e atribuídas a um IPspace antes que o IPspace seja replicado não serão replicadas para o cluster de parceiros.
Configuração de sub-rede
Você deve considerar as seguintes diretrizes ao configurar sub-redes em uma configuração do MetroCluster:
-
Ambos os clusters da configuração do MetroCluster devem ter uma sub-rede no mesmo espaço IPspace com o mesmo nome de sub-rede, sub-rede, domínio de broadcast e gateway.
-
Os intervalos de IP dos dois clusters devem ser diferentes.
No exemplo a seguir, os intervalos de IP são diferentes:
cluster_A::> network subnet show IPspace: Default Subnet Broadcast Avail/ Name Subnet Domain Gateway Total Ranges --------- ---------------- --------- ------------ ------- --------------- subnet1 192.168.2.0/24 Default 192.168.2.1 10/10 192.168.2.11-192.168.2.20 cluster_B::> network subnet show IPspace: Default Subnet Broadcast Avail/ Name Subnet Domain Gateway Total Ranges --------- ---------------- --------- ------------ -------- --------------- subnet1 192.168.2.0/24 Default 192.168.2.1 10/10 192.168.2.21-192.168.2.30
Configuração IPv6
Se o IPv6 estiver configurado em um site, o IPv6 também deve ser configurado no outro site.
"Requisitos para criação de LIF em uma configuração MetroCluster"
Requisitos para criação de LIF em uma configuração MetroCluster
Você deve estar ciente dos requisitos para criar LIFs ao configurar sua rede em uma configuração do MetroCluster.
Você deve considerar as seguintes diretrizes ao criar LIFs:
-
Fibre Channel: Você precisa usar VSAN esticada ou tecidos esticados
-
IP/iSCSI: Você deve usar a rede estendida da camada 2
-
Broadcasts ARP: Você deve habilitar broadcasts ARP entre os dois clusters
-
LIFs duplicadas: Você não deve criar vários LIFs com o mesmo endereço IP (LIFs duplicadas) em um espaço IPspace
-
Configurações NFS e SAN: Você precisa usar diferentes máquinas virtuais de storage (SVMs) para agregados sem espelhamento e espelhados
-
Você deve criar um objeto de sub-rede antes de criar um LIF. Um objeto de sub-rede permite que o ONTAP determine destinos de failover no cluster de destino porque tem um domínio de broadcast associado.
Verifique a criação de LIF
Você pode confirmar a criação bem-sucedida de um LIF em uma configuração MetroCluster executando o comando MetroCluster check lif show. Se você encontrar algum problema ao criar o LIF, você pode usar o comando MetroCluster check lif repair-placement para corrigir os problemas.
"Requisitos de replicação de objeto IPspace e configuração de sub-rede"
Requisitos e problemas de replicação e posicionamento de LIF
Você deve estar ciente dos requisitos de replicação do LIF em uma configuração do MetroCluster. Você também deve saber como um LIF replicado é colocado em um cluster de parceiros e estar ciente dos problemas que ocorrem quando a replicação LIF ou o posicionamento de LIF falha.
Replicação de LIFs para o cluster de parceiros
Quando você cria um LIF em um cluster em uma configuração do MetroCluster, o LIF é replicado no cluster de parceiros. LIFs não são colocados em uma base de nome individual. Para disponibilidade de LIFs após uma operação de switchover, o processo de colocação de LIF verifica se as portas são capazes de hospedar o LIF com base em verificações de acessibilidade e atributos de porta.
O sistema deve atender às seguintes condições para colocar as LIFs replicadas no cluster de parceiros:
Condição |
Tipo de LIF: FC |
Tipo de LIF: IP/iSCSI |
Identificação do nó |
O ONTAP tenta colocar o LIF replicado no parceiro de recuperação de desastres (DR) do nó no qual ele foi criado. Se o parceiro de DR não estiver disponível, o parceiro auxiliar de DR será usado para colocação. |
O ONTAP tenta colocar o LIF replicado no parceiro de DR do nó no qual ele foi criado. Se o parceiro de DR não estiver disponível, o parceiro auxiliar de DR será usado para colocação. |
Identificação da porta |
O ONTAP identifica as portas de destino FC conectadas no cluster de DR. |
As portas no cluster de DR que estão no mesmo IPspace que o LIF de origem são selecionadas para uma verificação de acessibilidade.se não houver portas no cluster de DR no mesmo IPspace, o LIF não pode ser colocado. Todas as portas no cluster de DR que já estão hospedando um LIF no mesmo espaço IPspace e sub-rede são marcadas automaticamente como alcançáveis e podem ser usadas para o posicionamento. Essas portas não estão incluídas na verificação de acessibilidade. |
Verificação de acessibilidade |
A acessibilidade é determinada verificando a conetividade da malha de origem WWN nas portas do cluster de DR. Se a mesma malha não estiver presente no local de DR, o LIF é colocado em uma porta aleatória no parceiro de DR. |
A acessibilidade é determinada pela resposta a um broadcast ARP (Address Resolution Protocol) de cada porta identificada anteriormente no cluster DR para o endereço IP de origem do LIF a ser colocado.para que as verificações de acessibilidade tenham êxito, as emissões ARP devem ser permitidas entre os dois clusters. Cada porta que recebe uma resposta do LIF de origem será marcada como possível para o posicionamento. |
Seleção da porta |
O ONTAP categoriza as portas com base em atributos como tipo e velocidade do adaptador e, em seguida, seleciona as portas com atributos correspondentes.se não forem encontradas portas com atributos correspondentes, o LIF é colocado em uma porta conetada aleatória no parceiro DR. |
A partir das portas marcadas como alcançáveis durante a verificação de acessibilidade, o ONTAP prefere as portas que estão no domínio de broadcast associado à sub-rede do LIF. Se não houver portas de rede disponíveis no cluster de DR que estão no domínio de broadcast associado à sub-rede do LIF, o ONTAP seleciona as portas que têm acessibilidade para o LIF de origem. Se não houver portas com acessibilidade ao LIF de origem, uma porta será selecionada do domínio de broadcast associado à sub-rede do LIF de origem e, se nenhum domínio de broadcast existir, uma porta aleatória será selecionada. O ONTAP categoriza as portas com base em atributos como tipo de adaptador, tipo de interface e velocidade e, em seguida, seleciona as portas com atributos correspondentes. |
Colocação de LIF |
A partir das portas alcançáveis, o ONTAP seleciona a porta menos carregada para colocação. |
A partir das portas selecionadas, o ONTAP seleciona a porta menos carregada para colocação. |
Colocação de LIFs replicadas quando o nó do parceiro de DR está inativo
Quando um iSCSI ou FC LIF é criado em um nó cujo parceiro de DR foi assumido, o LIF replicado é colocado no nó do parceiro auxiliar de DR. Após uma operação subsequente de giveback, os LIFs não são movidos automaticamente para o parceiro DR. Isso pode levar a que os LIFs se concentrem em um único nó no cluster de parceiros. Durante uma operação de switchover do MetroCluster, tentativas subsequentes de mapear LUNs pertencentes à máquina virtual de storage (SVM) falham.
Você deve executar o metrocluster check lif show comando após uma operação de aquisição ou operação de giveback para verificar se o posicionamento de LIF está correto. Se existirem erros, pode executar o metrocluster check lif repair-placement comando para resolver os problemas.
Erros de colocação de LIF
Os erros de colocação de LIF que são exibidos pelo metrocluster check lif show comando são retidos após uma operação de comutação. Se o network interface modify comando , network interface rename ou network interface delete for emitido para um LIF com um erro de posicionamento, o erro será removido e não aparecerá na saída do metrocluster check lif show comando.
Falha de replicação de LIF
Você também pode verificar se a replicação do LIF foi bem-sucedida usando o metrocluster check lif show comando. Uma mensagem EMS é exibida se a replicação LIF falhar.
Você pode corrigir uma falha de replicação executando o metrocluster check lif repair-placement comando para qualquer LIF que não consiga encontrar uma porta correta. Você deve resolver quaisquer falhas de replicação de LIF o mais rápido possível para verificar a disponibilidade de LIF durante uma operação de switchover de MetroCluster.
|
|
Mesmo que o SVM de origem esteja inativo, o posicionamento de LIF pode continuar normalmente se houver um LIF pertencente a um SVM diferente em uma porta com o mesmo espaço IPspace e rede no SVM de destino. |
"Requisitos de replicação de objeto IPspace e configuração de sub-rede"
Criação de volume em um agregado raiz
O sistema não permite a criação de novos volumes no agregado raiz (um agregado com uma política de HA do CFO) de um nó em uma configuração do MetroCluster.
Devido a essa restrição, os agregados de raiz não podem ser adicionados a um SVM usando o vserver add-aggregates comando.
Recuperação de desastres do SVM em uma configuração de MetroCluster
A partir do ONTAP 9.5, as máquinas virtuais de storage ativo (SVMs) em uma configuração do MetroCluster podem ser usadas como fontes com o recurso de recuperação de desastres do SnapMirror SVM. O SVM de destino deve estar no terceiro cluster fora da configuração do MetroCluster.
A partir do ONTAP 9.11,1, ambos os locais em uma configuração do MetroCluster podem ser a origem de uma relação de SVM DR com um cluster de destino FAS ou AFF, conforme mostrado na imagem a seguir.
Você deve estar ciente dos seguintes requisitos e limitações de uso de SVMs com recuperação de desastres do SnapMirror:
-
Somente um SVM ativo em uma configuração do MetroCluster pode ser a fonte de uma relação de recuperação de desastres do SVM.
Uma fonte pode ser uma SVM de origem sincronizada antes do switchover ou um SVM de destino de sincronização após o switchover.
-
Quando uma configuração do MetroCluster está em um estado estável, o SVM de destino de sincronização do MetroCluster não pode ser a fonte de uma relação de recuperação de desastres do SVM, já que os volumes não estão online.
A imagem a seguir mostra o comportamento de recuperação de desastres do SVM em um estado estável:
-
Quando o SVM de origem sincronizada é a fonte de uma relação SVM DR, as informações de origem no relacionamento de SVM DR são replicadas para o parceiro MetroCluster.
Isso permite que as atualizações do SVM DR continuem após um switchover, conforme mostrado na imagem a seguir:
-
Durante os processos de switchover e switchback, a replicação para o destino SVM DR pode falhar.
No entanto, após a conclusão do processo de comutação ou switchback, as próximas atualizações agendadas do SVM DR serão bem-sucedidas.
Consulte ""replicando a configuração do SVM"" em "Proteção de dados" para obter detalhes sobre como configurar uma relação de SVM DR.
Ressincronização da SVM em um local de recuperação de desastre
Durante a ressincronização, a fonte de recuperação de desastres (DR) de máquinas virtuais de storage (SVMs) na configuração MetroCluster é restaurada a partir do SVM de destino no local que não é MetroCluster.
Durante a ressincronização, o SVM de origem (cluster_A) atua temporariamente como SVM de destino, conforme mostrado na imagem a seguir:
Se um switchover não planejado ocorrer durante a ressincronização
Switchovers não planejados que ocorrem durante a ressincronização interromperão a transferência de ressincronização. Se ocorrer um switchover não planejado, as seguintes condições são verdadeiras:
-
O SVM de destino no local do MetroCluster (que era uma fonte SVM antes da ressincronização) permanece como um SVM de destino. O SVM no cluster de parceiros continuará mantendo seu subtipo e inativo.
-
A relação do SnapMirror deve ser recriada manualmente com o SVM de destino de sincronização como destino.
-
A relação SnapMirror não aparece na saída do show do SnapMirror após um switchover no local sobrevivente, a menos que uma operação de criação do SnapMirror seja executada.
Execução do switchback após um switchover não planejado durante a ressincronização
Para executar com sucesso o processo de switchback, a relação de ressincronização deve ser quebrada e excluída. O switchback não é permitido se houver algum SVMs de destino de DR do SnapMirror na configuração do MetroCluster ou se o cluster tiver um SVM de subtipo "dp-destination".
A saída para o comando storage Aggregate plex show é indeterminada após um switchover do MetroCluster
Quando você executa o comando storage Aggregate plex show após um switchover do MetroCluster, o status de plex0 do agregado de raiz comutada é indeterminado e é exibido como falhou. Durante este tempo, a raiz comutada não é atualizada. O estado real deste Plex só pode ser determinado após a fase de cicatrização do MetroCluster.
Modificação de volumes para definir o sinalizador NVFAIL em caso de comutação
Você pode modificar um volume para que o sinalizador NVFAIL seja definido no volume em caso de um switchover MetroCluster. O sinalizador NVFAIL faz com que o volume seja vedado de qualquer modificação. Isso é necessário para volumes que precisam ser tratados como se as gravações confirmadas no volume fossem perdidas após o switchover.
|
|
Nas versões do ONTAP anteriores a 9,0, o sinalizador NVFAIL é usado para cada switchover. No ONTAP 9.0 e versões posteriores, o switchover não planejado (USO) é usado. |
-
Ative a configuração do MetroCluster para ativar o NVFAIL no switchover definindo o
vol -dr-force-nvfailparâmetro como On:vol modify -vserver vserver-name -volume volume-name -dr-force-nvfail on