Skip to main content
ONTAP MetroCluster
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Configurando o software MetroCluster no ONTAP

Colaboradores
PDFs

É necessário configurar cada nó na configuração do MetroCluster no ONTAP, incluindo as configurações no nível do nó e a configuração dos nós em dois locais. Você também deve implementar a relação MetroCluster entre os dois sites.

software de configuração de cluster e nó de alto nível do fluxo de trabalho
Passos

  1. Reúna os endereços IP necessários para os módulos do controlador antes de iniciar o processo de configuração.

  2. Preencha a Planilha de informações de rede IP para o local A..

Folha de cálculo de informações de rede IP para o local A

Você deve obter endereços IP e outras informações de rede para o primeiro site do MetroCluster (site A) do administrador da rede antes de configurar o sistema.

Site Um cluster de criação de informações

Quando você cria o cluster pela primeira vez, você precisa das seguintes informações:

Tipo de informação

Seus valores

Nome do cluster. Exemplo usado nesta informação: Site_A

Domínio DNS

Servidores de nomes DNS

Localização

Senha do administrador

Informações do nó do site A.

Para cada nó no cluster, é necessário um endereço IP de gerenciamento, uma máscara de rede e um gateway padrão.

Nó

Porta

Endereço IP

Máscara de rede

Gateway predefinido

Nó 1. Exemplo usado nesta informação: Controller_A_1

Nó 2. Não é necessário se estiver usando a configuração MetroCluster de dois nós (um nó em cada local).

Exemplo usado nesta informação: Controller_A_2

Crie um site LIFs e portas para peering de cluster

Para cada nó no cluster, você precisa dos endereços IP de duas LIFs entre clusters, incluindo uma máscara de rede e um gateway padrão. Os LIFs entre clusters são usados para fazer o peer dos clusters.

Nó

Porta

Endereço IP do LIF entre clusters

Máscara de rede

Gateway predefinido

Nó 1 IC LIF 1

Nó 1 IC LIF 2

Site A informações do servidor de tempo

É necessário sincronizar a hora, que requer um ou mais servidores de hora NTP.

Nó

Nome do host

Endereço IP

Máscara de rede

Gateway predefinido

Servidor NTP 1

Servidor NTP 2

Local A   Informação AutoSupport

Você deve configurar o AutoSupport em cada nó, o que requer as seguintes informações:

Tipo de informação

Seus valores

Do endereço de e-mail

Anfitriões de correio

Endereços IP ou nomes

Protocolo de transporte

HTTP, HTTPS OU SMTP

Servidor proxy

Endereços de e-mail do destinatário ou listas de distribuição

Mensagens completas

Mensagens concisas

Site A informações do SP

Você deve habilitar o acesso ao processador de serviço (SP) de cada nó para solução de problemas e manutenção. Isso requer as seguintes informações de rede para cada nó:

Nó

Endereço IP

Máscara de rede

Gateway predefinido

Nó 1

Folha de cálculo de informações de rede IP para o local B.

Você deve obter endereços IP e outras informações de rede para o segundo site da MetroCluster (site B) do administrador da rede antes de configurar o sistema.

Informações sobre a criação do cluster do local B.

Quando você cria o cluster pela primeira vez, você precisa das seguintes informações:

Tipo de informação

Seus valores

Nome do cluster. Exemplo usado nesta informação: Site_B

Domínio DNS

Servidores de nomes DNS

Localização

Senha do administrador

Informações do nó do local B.

Para cada nó no cluster, é necessário um endereço IP de gerenciamento, uma máscara de rede e um gateway padrão.

Nó

Porta

Endereço IP

Máscara de rede

Gateway predefinido

Nó 1. Exemplo usado nesta informação: Controller_B_1

Nó 2. Não é necessário para configurações de MetroCluster de dois nós (um nó em cada local).

Exemplo usado nesta informação: Controller_B_2

LIFs do local B e portas para peering de cluster

Para cada nó no cluster, você precisa dos endereços IP de duas LIFs entre clusters, incluindo uma máscara de rede e um gateway padrão. Os LIFs entre clusters são usados para fazer o peer dos clusters.

Nó

Porta

Endereço IP do LIF entre clusters

Máscara de rede

Gateway predefinido

Nó 1 IC LIF 1

Nó 1 IC LIF 2

Informações do servidor de hora local B.

É necessário sincronizar a hora, que requer um ou mais servidores de hora NTP.

Nó

Nome do host

Endereço IP

Máscara de rede

Gateway predefinido

Servidor NTP 1

Servidor NTP 2

Local B   Informação AutoSupport

Você deve configurar o AutoSupport em cada nó, o que requer as seguintes informações:

Tipo de informação

Seus valores

Do endereço de e-mail

Anfitriões de correio

Endereços IP ou nomes

Protocolo de transporte

HTTP, HTTPS OU SMTP

Servidor proxy

Endereços de e-mail do destinatário ou listas de distribuição

Mensagens completas

Mensagens concisas

Local B   Informação SP

Você deve habilitar o acesso ao processador de serviço (SP) de cada nó para solução de problemas e manutenção, o que requer as seguintes informações de rede para cada nó:

Nó

Endereço IP

Máscara de rede

Gateway predefinido

Nó 1 (controlador_B_1)

Semelhanças e diferenças entre configurações padrão de cluster e MetroCluster

A configuração dos nós em cada cluster em uma configuração MetroCluster é semelhante à dos nós em um cluster padrão.

A configuração do MetroCluster é baseada em dois clusters padrão. Fisicamente, a configuração deve ser simétrica, com cada nó tendo a mesma configuração de hardware e todos os componentes do MetroCluster devem ser cabeados e configurados. No entanto, a configuração básica de software para nós em uma configuração MetroCluster é a mesma para nós em um cluster padrão.

Etapa de configuração

Configuração padrão de cluster

Configuração do MetroCluster

Configurar LIFs de gerenciamento, cluster e dados em cada nó.

O mesmo em ambos os tipos de clusters

Configure o agregado raiz.

O mesmo em ambos os tipos de clusters

Configure o cluster em um nó no cluster.

O mesmo em ambos os tipos de clusters

Junte o outro nó ao cluster.

O mesmo em ambos os tipos de clusters

Crie um agregado de raiz espelhado.

Opcional

Obrigatório

Espreite os clusters.

Opcional

Obrigatório

Ative a configuração do MetroCluster.

Restaurando os padrões do sistema e configurando o tipo HBA em um módulo do controlador

Para garantir uma instalação bem-sucedida do MetroCluster, redefina e restaure padrões nos módulos do controlador.

Importante

Essa tarefa só é necessária para configurações Stretch usando bridges FC-para-SAS.

Passos

  1. No prompt Loader, retorne as variáveis ambientais à configuração padrão:

    set-defaults

  2. Inicialize o nó no modo Manutenção e, em seguida, configure as configurações para quaisquer HBAs no sistema:

    1. Arranque no modo de manutenção:

      boot_ontap maint

    2. Verifique as definições atuais das portas:

      ucadmin show

    3. Atualize as definições da porta conforme necessário.

    Se você tem este tipo de HBA e modo desejado…​

    Use este comando…​

    CNA FC

    ucadmin modify -m fc -t initiator adapter_name

    CNA Ethernet

    ucadmin modify -mode cna adapter_name

    Destino de FC

    fcadmin config -t target adapter_name

    Iniciador FC

    fcadmin config -t initiator adapter_name

  3. Sair do modo de manutenção:

    halt

    Depois de executar o comando, aguarde até que o nó pare no prompt DO Loader.

  4. Inicialize o nó novamente no modo Manutenção para permitir que as alterações de configuração entrem em vigor:

    boot_ontap maint

  5. Verifique as alterações feitas:

    Se você tem este tipo de HBA…​

    Use este comando…​

    CNA

    ucadmin show

    FC

    fcadmin show

  6. Sair do modo de manutenção:

    halt

    Depois de executar o comando, aguarde até que o nó pare no prompt DO Loader.

  7. Inicialize o nó no menu de inicialização:

    boot_ontap menu

    Depois de executar o comando, aguarde até que o menu de inicialização seja exibido.

  8. Limpe a configuração do nó digitando "wipeconfig" no prompt do menu de inicialização e pressione Enter.

    A tela a seguir mostra o prompt do menu de inicialização:

    Please choose one of the following:

     (1) Normal Boot.
     (2) Boot without /etc/rc.
     (3) Change password.
     (4) Clean configuration and initialize all disks.
     (5) Maintenance mode boot.
     (6) Update flash from backup config.
     (7) Install new software first.
     (8) Reboot node.
     (9) Configure Advanced Drive Partitioning.
     Selection (1-9)?  wipeconfig
 This option deletes critical system configuration, including cluster membership.
 Warning: do not run this option on a HA node that has been taken over.
 Are you sure you want to continue?: yes
 Rebooting to finish wipeconfig request.

Configurando portas FC-VI em uma placa quad-port X1132A-R6 em sistemas FAS8020

Se você estiver usando a placa quad-port X1132A-R6 em um sistema FAS8020, você pode entrar no modo de manutenção para configurar as portas 1a e 1b para uso de FC-VI e iniciador. Isso não é necessário nos sistemas MetroCluster recebidos de fábrica, nos quais as portas são definidas adequadamente para sua configuração.

Sobre esta tarefa

Esta tarefa deve ser executada no modo Manutenção.

Observação A conversão de uma porta FC para uma porta FC-VI com o comando uadministrador só é compatível com os sistemas FAS8020 e AFF 8020. A conversão de portas FC para portas FCVI não é compatível em nenhuma outra plataforma.
Passos

  1. Desative as portas:

    storage disable adapter 1a

    storage disable adapter 1b

    *> storage disable adapter 1a
Jun 03 02:17:57 [controller_B_1:fci.adapter.offlining:info]: Offlining Fibre Channel adapter 1a.
Host adapter 1a disable succeeded
Jun 03 02:17:57 [controller_B_1:fci.adapter.offline:info]: Fibre Channel adapter 1a is now offline.
*> storage disable adapter 1b
Jun 03 02:18:43 [controller_B_1:fci.adapter.offlining:info]: Offlining Fibre Channel adapter 1b.
Host adapter 1b disable succeeded
Jun 03 02:18:43 [controller_B_1:fci.adapter.offline:info]: Fibre Channel adapter 1b is now offline.
*>

  2. Verifique se as portas estão desativadas:

    ucadmin show

    *> ucadmin show
         Current  Current    Pending  Pending    Admin
Adapter  Mode     Type       Mode     Type       Status
-------  -------  ---------  -------  ---------  -------
  ...
  1a     fc       initiator  -        -          offline
  1b     fc       initiator  -        -          offline
  1c     fc       initiator  -        -          online
  1d     fc       initiator  -        -          online

  3. Defina as portas a e b para o modo FC-VI:

    ucadmin modify -adapter 1a -type fcvi

    O comando define o modo em ambas as portas no par de portas, 1a e 1b (mesmo que apenas 1a seja especificado no comando).

    *> ucadmin modify -t fcvi 1a
Jun 03 02:19:13 [controller_B_1:ucm.type.changed:info]: FC-4 type has changed to fcvi on adapter 1a. Reboot the controller for the changes to take effect.
Jun 03 02:19:13 [controller_B_1:ucm.type.changed:info]: FC-4 type has changed to fcvi on adapter 1b. Reboot the controller for the changes to take effect.

  4. Confirme se a alteração está pendente:

    ucadmin show

    *> ucadmin show
         Current  Current    Pending  Pending    Admin
Adapter  Mode     Type       Mode     Type       Status
-------  -------  ---------  -------  ---------  -------
  ...
  1a     fc       initiator  -        fcvi       offline
  1b     fc       initiator  -        fcvi       offline
  1c     fc       initiator  -        -          online
  1d     fc       initiator  -        -          online

  5. Desligue o controlador e reinicie-o no modo de manutenção.

  6. Confirme a alteração de configuração:

    ucadmin show local

    Node           Adapter  Mode     Type       Mode     Type       Status
------------   -------  -------  ---------  -------  ---------  -----------
...
controller_B_1
               1a       fc       fcvi       -        -          online
controller_B_1
               1b       fc       fcvi       -        -          online
controller_B_1
               1c       fc       initiator  -        -          online
controller_B_1
               1d       fc       initiator  -        -          online
6 entries were displayed.

Verificando a atribuição de discos no modo Manutenção em uma configuração de dois nós

Antes de iniciar totalmente o sistema no ONTAP, você pode opcionalmente inicializar o sistema no modo Manutenção e verificar a atribuição de disco nos nós. Os discos devem ser atribuídos para criar uma configuração totalmente simétrica, com os dois locais que possuem suas próprias gavetas de disco e fornecimento de dados, em que cada nó e cada pool têm um número igual de discos espelhados atribuídos a eles.

Antes de começar

O sistema tem de estar no modo de manutenção.

Sobre esta tarefa

Os novos sistemas MetroCluster têm atribuições de disco concluídas antes do envio.

A tabela a seguir mostra exemplos de atribuições de pool para uma configuração do MetroCluster. Os discos são atribuídos a pools por compartimento.

Compartimento de disco (exemplo nome)…​

No local…​

Pertence a…​

E é atribuído a esse nó…​

Compartimento de disco 1 (shelf_A_1_1)

Local A

Nó A 1

Piscina 0

Compartimento de disco 2 (shelf_A_1_3)

Compartimento de disco 3 (gaveta_B_1_1)

Nó B 1

Piscina 1

Compartimento de disco 4 (gaveta_B_1_3)

Compartimento de disco 9 (gaveta_B_1_2)

Local B

Nó B 1

Piscina 0

Compartimento de disco 10 (gaveta_B_1_4)

Compartimento de disco 11 (shelf_A_1_2)

Nó A 1

Se a configuração incluir DS460C compartimentos de disco, você deve atribuir manualmente os discos usando as seguintes diretrizes para cada gaveta de 12 discos:

Atribuir estes discos na gaveta…​

Para este nó e pool…​

1 - 6

Pool do nó local 0

7 - 12

Pool do parceiro DR 1

Esse padrão de atribuição de disco minimiza o efeito em um agregado se uma gaveta ficar offline.

Passos

  1. Se o seu sistema foi recebido de fábrica, confirme as atribuições de prateleira:

    disk show –v

  2. Se necessário, você pode atribuir explicitamente discos nas gavetas de disco conetadas ao pool apropriado

    disk assign

    Os compartimentos de disco no mesmo local que o nó são atribuídos ao pool 0 e os compartimentos de disco localizados no local do parceiro são atribuídos ao pool 1. Você deve atribuir um número igual de prateleiras a cada pool.

    1. Se você não tiver feito isso, inicialize cada sistema no modo Manutenção.

    2. No nó no local A, atribua sistematicamente as gavetas de disco locais ao pool 0 e às gavetas de disco remotas ao pool 1: Mais disk assign -shelf disk_shelf_name -p pool

      Se o nó_A_1 do controlador de storage tiver quatro compartimentos, você emitirá os seguintes comandos:

      *> disk assign -shelf shelf_A_1_1 -p 0
*> disk assign -shelf shelf_A_1_3 -p 0

*> disk assign -shelf shelf_A_1_2 -p 1
*> disk assign -shelf shelf_A_1_4 -p 1

    3. No nó do local remoto (local B), atribua sistematicamente suas gavetas de disco locais ao pool 0 e suas gavetas de disco remotas ao pool 1: Mais disk assign -shelf disk_shelf_name -p pool

      Se o nó_B_1 do controlador de storage tiver quatro compartimentos, você emitirá os seguintes comandos:

    *> disk assign -shelf shelf_B_1_2   -p 0
*> disk assign -shelf shelf_B_1_4  -p 0

*> disk assign -shelf shelf_B_1_1 -p 1
 *> disk assign -shelf shelf_B_1_3 -p 1

    1. Mostrar as IDs e os compartimentos do compartimento de disco para cada disco disk show –v

Verificando o estado de HA dos componentes

Em uma configuração Stretch MetroCluster que não está pré-configurada na fábrica, você deve verificar se o estado HA do controlador e do componente do chassi está definido como "mcc-2n" para que eles iniciem corretamente. Para sistemas recebidos de fábrica, esse valor é pré-configurado e você não precisa verificá-lo.

Antes de começar

O sistema tem de estar no modo de manutenção.

Passos

  1. No modo de manutenção, visualize o estado HA do módulo do controlador e do chassis:

    ha-config show

    O módulo do controlador e o chassi devem mostrar o valor "mcc-2n".

  2. Se o estado do sistema exibido do controlador não for "mcc-2n", defina o estado HA para o controlador:

    ha-config modify controller mcc-2n

  3. Se o estado do sistema exibido do chassi não for "mcc-2n", defina o estado HA para o chassi:

    ha-config modify chassis mcc-2n

    Parar o nó.

    Aguarde até que o nó volte ao prompt DO Loader.

  4. Repita estas etapas em cada nó na configuração do MetroCluster.

Configurando o ONTAP em uma configuração de MetroCluster de dois nós

Em uma configuração de MetroCluster de dois nós, em cada cluster, você deve inicializar o nó, sair do assistente de configuração de cluster e usar o cluster setup comando para configurar o nó em um cluster de nó único.

Antes de começar

Você não deve ter configurado o processador de serviço.

Sobre esta tarefa

Essa tarefa é para configurações de MetroCluster de dois nós que usam storage nativo do NetApp.

Essa tarefa deve ser executada em ambos os clusters na configuração do MetroCluster.

Para obter mais informações gerais sobre a configuração do ONTAP, consulte a. "Configuração do ONTAP"

Passos

  1. Ligue o primeiro nó.

    Observação Repita esta etapa no nó no local de recuperação de desastres (DR).

    O nó é inicializado e, em seguida, o assistente de Configuração de cluster é iniciado no console informando que o AutoSupport será ativado automaticamente.

    ::> Welcome to the cluster setup wizard.

You can enter the following commands at any time:
  "help" or "?" - if you want to have a question clarified,
  "back" - if you want to change previously answered questions, and
  "exit" or "quit" - if you want to quit the cluster setup wizard.
     Any changes you made before quitting will be saved.

You can return to cluster setup at any time by typing "cluster setup".
To accept a default or omit a question, do not enter a value.

This system will send event messages and periodic reports to NetApp Technical
Support. To disable this feature, enter
autosupport modify -support disable
within 24 hours.

Enabling AutoSupport can significantly speed problem determination and
resolution, should a problem occur on your system.
For further information on AutoSupport, see:
http://support.netapp.com/autosupport/

Type yes to confirm and continue {yes}: yes

Enter the node management interface port [e0M]:
Enter the node management interface IP address [10.101.01.01]:

Enter the node management interface netmask [101.010.101.0]:
Enter the node management interface default gateway [10.101.01.0]:



Do you want to create a new cluster or join an existing cluster? {create, join}:

  2. Criar um novo cluster:

    create

  3. Escolha se o nó deve ser usado como um cluster de nó único.

    Do you intend for this node to be used as a single node cluster? {yes, no} [yes]:

  4. Aceite o padrão do sistema "sim" pressionando Enter, ou insira seus próprios valores digitando "não" e, em seguida, pressionando Enter.

  5. Siga as instruções para concluir o assistente Configuração de cluster, pressione Enter para aceitar os valores padrão ou digitar seus próprios valores e pressione Enter.

    Os valores padrão são determinados automaticamente com base na sua plataforma e configuração de rede.

  6. Depois de concluir o assistente Cluster Setup e ele sair, verifique se o cluster está ativo e se o primeiro nó está em bom estado:

    cluster show

    O exemplo a seguir mostra um cluster no qual o primeiro nó (cluster1-01) está íntegro e qualificado para participar:

    cluster1::> cluster show
Node                  Health  Eligibility
--------------------- ------- ------------
cluster1-01           true    true

    Se for necessário alterar qualquer uma das configurações inseridas para o SVM admin ou nó SVM, você poderá acessar o assistente Configuração de cluster usando o cluster setup comando.

Configuração dos clusters em uma configuração do MetroCluster

É necessário fazer peer nos clusters, espelhar os agregados raiz, criar um agregado de dados espelhados e, em seguida, emitir o comando para implementar as operações do MetroCluster.

Peering dos clusters

Os clusters na configuração do MetroCluster precisam estar em um relacionamento de mesmo nível para que possam se comunicar uns com os outros e executar o espelhamento de dados essencial para a recuperação de desastres do MetroCluster.

Informações relacionadas

"Configuração expressa de peering de cluster e SVM"

"Considerações ao usar portas dedicadas"

"Considerações ao compartilhar portas de dados"

Configurando LIFs entre clusters

É necessário criar LIFs entre clusters nas portas usadas para comunicação entre os clusters de parceiros da MetroCluster. Você pode usar portas dedicadas ou portas que também têm tráfego de dados.

Configurando LIFs entre clusters em portas dedicadas

Você pode configurar LIFs entre clusters em portas dedicadas. Isso normalmente aumenta a largura de banda disponível para o tráfego de replicação.

Passos

  1. Liste as portas no cluster:

    network port show

    Para obter a sintaxe completa do comando, consulte a página man.

    O exemplo a seguir mostra as portas de rede em "'cluster01"":

    cluster01::> network port show
                                                             Speed (Mbps)
Node   Port      IPspace      Broadcast Domain Link   MTU    Admin/Oper
------ --------- ------------ ---------------- ----- ------- ------------
cluster01-01
       e0a       Cluster      Cluster          up     1500   auto/1000
       e0b       Cluster      Cluster          up     1500   auto/1000
       e0c       Default      Default          up     1500   auto/1000
       e0d       Default      Default          up     1500   auto/1000
       e0e       Default      Default          up     1500   auto/1000
       e0f       Default      Default          up     1500   auto/1000
cluster01-02
       e0a       Cluster      Cluster          up     1500   auto/1000
       e0b       Cluster      Cluster          up     1500   auto/1000
       e0c       Default      Default          up     1500   auto/1000
       e0d       Default      Default          up     1500   auto/1000
       e0e       Default      Default          up     1500   auto/1000
       e0f       Default      Default          up     1500   auto/1000

  2. Determine quais portas estão disponíveis para se dedicar à comunicação entre clusters:

    network interface show -fields home-port,curr-port

    Para obter a sintaxe completa do comando, consulte a página man.

    O exemplo a seguir mostra que os portos "'e0e'" e "'e0f'" não foram atribuídos LIFs:

    cluster01::> network interface show -fields home-port,curr-port
vserver lif                  home-port curr-port

Cluster cluster01-01_clus1   e0a       e0a
Cluster cluster01-01_clus2   e0b       e0b
Cluster cluster01-02_clus1   e0a       e0a
Cluster cluster01-02_clus2   e0b       e0b
cluster01
        cluster_mgmt         e0c       e0c
cluster01
        cluster01-01_mgmt1   e0c       e0c
cluster01
        cluster01-02_mgmt1   e0c       e0c

  3. Crie um grupo de failover para as portas dedicadas:

    network interface failover-groups create -vserver system_SVM -failover-group failover_group -targets physical_or_logical_ports

    O exemplo a seguir atribui as portas "'e0e"" e "'e0f" ao grupo de failover "'intercluster01" no SVM do sistema "'cluster01":

    cluster01::> network interface failover-groups create -vserver cluster01 -failover-group
intercluster01 -targets
cluster01-01:e0e,cluster01-01:e0f,cluster01-02:e0e,cluster01-02:e0f

  4. Verifique se o grupo de failover foi criado:

    network interface failover-groups show

    Para obter a sintaxe completa do comando, consulte a página man.

    cluster01::> network interface failover-groups show
                                  Failover
Vserver          Group            Targets
---------------- ---------------- --------------------------------------------
Cluster
                 Cluster
                                  cluster01-01:e0a, cluster01-01:e0b,
                                  cluster01-02:e0a, cluster01-02:e0b
cluster01
                 Default
                                  cluster01-01:e0c, cluster01-01:e0d,
                                  cluster01-02:e0c, cluster01-02:e0d,
                                  cluster01-01:e0e, cluster01-01:e0f
                                  cluster01-02:e0e, cluster01-02:e0f
                 intercluster01
                                  cluster01-01:e0e, cluster01-01:e0f
                                  cluster01-02:e0e, cluster01-02:e0f

  5. Crie LIFs entre clusters no sistema e atribua-os ao grupo de failover.

    Versão de ONTAP

    Comando

    ONTAP 9 F.6 e mais tarde

    network interface create -vserver system_SVM -lif LIF_name -service-policy default-intercluster -home-node node -home-port port -address port_IP -netmask netmask -failover-group failover_group

    ONTAP 9 F.5 e anteriores

    network interface create -vserver system_SVM -lif LIF_name -role intercluster -home-node node -home-port port -address port_IP -netmask netmask -failover-group failover_group

    Para obter a sintaxe completa do comando, consulte a página man.

    O exemplo a seguir cria LIFs entre clusters "'cluster01_icl01" e "'cluster01_icl02" no grupo de failover "'intercluster01":

    cluster01::> network interface create -vserver cluster01 -lif cluster01_icl01 -service-
policy default-intercluster -home-node cluster01-01 -home-port e0e -address 192.168.1.201
-netmask 255.255.255.0 -failover-group intercluster01

cluster01::> network interface create -vserver cluster01 -lif cluster01_icl02 -service-
policy default-intercluster -home-node cluster01-02 -home-port e0e -address 192.168.1.202
-netmask 255.255.255.0 -failover-group intercluster01

  6. Verifique se as LIFs entre clusters foram criadas:

    Versão de ONTAP

    Comando

    ONTAP 9 F.6 e mais tarde

    network interface show -service-policy default-intercluster

    ONTAP 9 F.5 e anteriores

    network interface show -role intercluster

    Para obter a sintaxe completa do comando, consulte a página man.

    cluster01::> network interface show -service-policy default-intercluster
            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
cluster01
            cluster01_icl01
                       up/up      192.168.1.201/24   cluster01-01  e0e     true
            cluster01_icl02
                       up/up      192.168.1.202/24   cluster01-02  e0f     true

  7. Verifique se as LIFs entre clusters são redundantes:

    Versão de ONTAP

    Comando

    ONTAP 9 F.6 e mais tarde

    network interface show -service-policy default-intercluster -failover

    Em ONTAP 9.5 e anteriores

    network interface show -role intercluster -failover

    Para obter a sintaxe completa do comando, consulte a página man.

    O exemplo a seguir mostra que os LIFs entre clusters "'cluster01_icl01" e "'cluster01_icl02" na porta SVM "'e0e" falharão para a porta "'e0f".

    cluster01::> network interface show -service-policy default-intercluster –failover
         Logical         Home                  Failover        Failover
Vserver  Interface       Node:Port             Policy          Group
-------- --------------- --------------------- --------------- --------
cluster01
         cluster01_icl01 cluster01-01:e0e   local-only      intercluster01
                            Failover Targets:  cluster01-01:e0e,
                                               cluster01-01:e0f
         cluster01_icl02 cluster01-02:e0e   local-only      intercluster01
                            Failover Targets:  cluster01-02:e0e,
                                               cluster01-02:e0f
Informações relacionadas

"Considerações ao usar portas dedicadas"

Configurando LIFs entre clusters em portas de dados compartilhados

Você pode configurar LIFs entre clusters em portas compartilhadas com a rede de dados. Isso reduz o número de portas de que você precisa para redes entre clusters.

Passos

  1. Liste as portas no cluster:

    network port show

    Para obter a sintaxe completa do comando, consulte a página man.

    O exemplo a seguir mostra as portas de rede em "'cluster01"":

    cluster01::> network port show
                                                             Speed (Mbps)
Node   Port      IPspace      Broadcast Domain Link   MTU    Admin/Oper
------ --------- ------------ ---------------- ----- ------- ------------
cluster01-01
       e0a       Cluster      Cluster          up     1500   auto/1000
       e0b       Cluster      Cluster          up     1500   auto/1000
       e0c       Default      Default          up     1500   auto/1000
       e0d       Default      Default          up     1500   auto/1000
cluster01-02
       e0a       Cluster      Cluster          up     1500   auto/1000
       e0b       Cluster      Cluster          up     1500   auto/1000
       e0c       Default      Default          up     1500   auto/1000
       e0d       Default      Default          up     1500   auto/1000

  2. Criar LIFs entre clusters no sistema:

    Versão de ONTAP

    Comando

    ONTAP 9 F.6 e mais tarde

    network interface create -vserver system_SVM -lif LIF_name -service-policy default-intercluster -home-node node -home-port port -address port_IP -netmask netmask

    ONTAP 9 F.5 e anteriores

    network interface create -vserver system_SVM -lif LIF_name -role intercluster -home-node node -home-port port -address port_IP -netmask netmask

    Para obter a sintaxe completa do comando, consulte a página man.

    O exemplo a seguir cria LIFs entre clusters "'cluster01_icl01" e "'cluster01_icl02":

    cluster01::> network interface create -vserver cluster01 -lif cluster01_icl01 -service-
policy default-intercluster -home-node cluster01-01 -home-port e0c -address 192.168.1.201
-netmask 255.255.255.0

cluster01::> network interface create -vserver cluster01 -lif cluster01_icl02 -service-
policy default-intercluster -home-node cluster01-02 -home-port e0c -address 192.168.1.202
-netmask 255.255.255.0

  3. Verifique se as LIFs entre clusters foram criadas:

    Versão de ONTAP

    Comando

    ONTAP 9 F.6 e mais tarde

    network interface show -service-policy default-intercluster

    ONTAP 9 F.5 e anteriores

    network interface show -role intercluster

    Para obter a sintaxe completa do comando, consulte a página man.

    cluster01::> network interface show -service-policy default-intercluster
            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
cluster01
            cluster01_icl01
                       up/up      192.168.1.201/24   cluster01-01  e0c     true
            cluster01_icl02
                       up/up      192.168.1.202/24   cluster01-02  e0c     true

  4. Verifique se as LIFs entre clusters são redundantes:

    Versão de ONTAP

    Comando

    ONTAP 9 F.6 e mais tarde

    network interface show –service-policy default-intercluster -failover

    ONTAP 9 F.5 e anteriores

    network interface show -role intercluster -failover

    Para obter a sintaxe completa do comando, consulte a página man.

    O exemplo a seguir mostra que os LIFs entre clusters "'cluster01_icl01" e "'cluster01_icl02" na porta "'e0c" falharão para a porta "'e0d".

    cluster01::> network interface show -service-policy default-intercluster –failover
         Logical         Home                  Failover        Failover
Vserver  Interface       Node:Port             Policy          Group
-------- --------------- --------------------- --------------- --------
cluster01
         cluster01_icl01 cluster01-01:e0c   local-only      192.168.1.201/24
                            Failover Targets: cluster01-01:e0c,
                                              cluster01-01:e0d
         cluster01_icl02 cluster01-02:e0c   local-only      192.168.1.201/24
                            Failover Targets: cluster01-02:e0c,
                                              cluster01-02:e0d
Informações relacionadas

"Considerações ao compartilhar portas de dados"

Criando um relacionamento de cluster peer

É necessário criar o relacionamento de peers de clusters entre os clusters do MetroCluster.

Criando um relacionamento de cluster peer

Você pode usar o cluster peer create comando para criar uma relação entre pares entre um cluster local e remoto. Após a criação da relação de pares, você pode executar cluster peer create no cluster remoto para autenticá-la no cluster local.

Antes de começar

  • Você precisa ter criado LIFs entre clusters em todos os nós nos clusters que estão sendo perados.

  • Os clusters precisam estar executando o ONTAP 9.3 ou posterior.

Passos

  1. No cluster de destino, crie uma relação de pares com o cluster de origem:

    cluster peer create -generate-passphrase -offer-expiration MM/DD/YYYY HH:MM:SS|1…​7days|1…​168hours -peer-addrs peer_LIF_IPs -ipspace ipspace

    Se você especificar ambos -generate-passphrase e -peer-addrs, somente o cluster cujos LIFs entre clusters são especificados em -peer-addrs poderá usar a senha gerada.

    Você pode ignorar a -ipspace opção se não estiver usando um IPspace personalizado. Para obter a sintaxe completa do comando, consulte a página man.

    O exemplo a seguir cria um relacionamento de peer de cluster em um cluster remoto não especificado:

    cluster02::> cluster peer create -generate-passphrase -offer-expiration 2days

                     Passphrase: UCa+6lRVICXeL/gq1WrK7ShR
                Expiration Time: 6/7/2017 08:16:10 EST
  Initial Allowed Vserver Peers: -
            Intercluster LIF IP: 192.140.112.101
              Peer Cluster Name: Clus_7ShR (temporary generated)

Warning: make a note of the passphrase - it cannot be displayed again.

  2. No cluster de origem, autentique o cluster de origem no cluster de destino:

    cluster peer create -peer-addrs peer_LIF_IPs -ipspace ipspace

    Para obter a sintaxe completa do comando, consulte a página man.

    O exemplo a seguir autentica o cluster local para o cluster remoto nos endereços IP 192.140.112.101 e 192.140.112.102 do LIF:

    cluster01::> cluster peer create -peer-addrs 192.140.112.101,192.140.112.102

Notice: Use a generated passphrase or choose a passphrase of 8 or more characters.
        To ensure the authenticity of the peering relationship, use a phrase or sequence of characters that would be hard to guess.

Enter the passphrase:
Confirm the passphrase:

Clusters cluster02 and cluster01 are peered.

    Digite a senha para o relacionamento de pares quando solicitado.

  3. Verifique se o relacionamento de pares de cluster foi criado:

    cluster peer show -instance

    cluster01::> cluster peer show -instance

                               Peer Cluster Name: cluster02
                   Remote Intercluster Addresses: 192.140.112.101, 192.140.112.102
              Availability of the Remote Cluster: Available
                             Remote Cluster Name: cluster2
                             Active IP Addresses: 192.140.112.101, 192.140.112.102
                           Cluster Serial Number: 1-80-123456
                  Address Family of Relationship: ipv4
            Authentication Status Administrative: no-authentication
               Authentication Status Operational: absent
                                Last Update Time: 02/05 21:05:41
                    IPspace for the Relationship: Default

  4. Verifique a conetividade e o status dos nós no relacionamento de pares:

    cluster peer health show

    cluster01::> cluster peer health show
Node       cluster-Name                Node-Name
             Ping-Status               RDB-Health Cluster-Health  Avail…
---------- --------------------------- ---------  --------------- --------
cluster01-01
           cluster02                   cluster02-01
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
                                       cluster02-02
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
cluster01-02
           cluster02                   cluster02-01
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
                                       cluster02-02
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
Criando um relacionamento de cluster peer (ONTAP 9.2 e anterior)

Você pode usar o cluster peer create comando para iniciar uma solicitação de um relacionamento de peering entre um cluster local e remoto. Depois que o relacionamento de pares tiver sido solicitado pelo cluster local, você pode executar cluster peer create no cluster remoto para aceitar o relacionamento.

Antes de começar

  • Você precisa ter criado LIFs entre clusters em todos os nós nos clusters que estão sendo perados.

  • Os administradores de cluster devem ter concordado com a frase-passe que cada cluster usará para se autenticar com o outro.

Passos

  1. No cluster de destino de proteção de dados, crie uma relação de mesmo nível com o cluster de origem de proteção de dados:

    cluster peer create -peer-addrs peer_LIF_IPs -ipspace ipspace

    Você pode ignorar a -ipspace opção se não estiver usando um IPspace personalizado. Para obter a sintaxe completa do comando, consulte a página man.

    O exemplo a seguir cria uma relação de peer de cluster com o cluster remoto nos endereços IP de LIF 192.168.2.201 e 192.168.2.202:

    cluster02::> cluster peer create -peer-addrs 192.168.2.201,192.168.2.202
Enter the passphrase:
Please enter the passphrase again:

    Digite a senha para o relacionamento de pares quando solicitado.

  2. No cluster de origem de proteção de dados, autentique o cluster de origem no cluster de destino:

    cluster peer create -peer-addrs peer_LIF_IPs -ipspace ipspace

    Para obter a sintaxe completa do comando, consulte a página man.

    O exemplo a seguir autentica o cluster local para o cluster remoto nos endereços IP 192.140.112.203 e 192.140.112.204 do LIF:

    cluster01::> cluster peer create -peer-addrs 192.168.2.203,192.168.2.204
Please confirm the passphrase:
Please confirm the passphrase again:

    Digite a senha para o relacionamento de pares quando solicitado.

  3. Verifique se o relacionamento de pares de cluster foi criado:

    cluster peer show –instance

    Para obter a sintaxe completa do comando, consulte a página man.

    cluster01::> cluster peer show –instance
Peer Cluster Name: cluster01
Remote Intercluster Addresses: 192.168.2.201,192.168.2.202
Availability: Available
Remote Cluster Name: cluster02
Active IP Addresses: 192.168.2.201,192.168.2.202
Cluster Serial Number: 1-80-000013

  4. Verifique a conetividade e o status dos nós no relacionamento de pares:

    cluster peer health show

    Para obter a sintaxe completa do comando, consulte a página man.

    cluster01::> cluster peer health show
Node       cluster-Name                Node-Name
             Ping-Status               RDB-Health Cluster-Health  Avail…
---------- --------------------------- ---------  --------------- --------
cluster01-01
           cluster02                   cluster02-01
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
                                       cluster02-02
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
cluster01-02
           cluster02                   cluster02-01
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
                                       cluster02-02
             Data: interface_reachable
             ICMP: interface_reachable true       true            true

Espelhamento dos agregados de raiz

É necessário espelhar os agregados raiz para fornecer proteção de dados.

Sobre esta tarefa

Por padrão, o agregado raiz é criado como agregado do tipo RAID-DP. Você pode alterar o agregado raiz de RAID-DP para o agregado do tipo RAID4. O comando a seguir modifica o agregado raiz para o agregado do tipo RAID4:

storage aggregate modify –aggregate aggr_name -raidtype raid4

Observação Em sistemas que não sejam ADP, o tipo RAID do agregado pode ser modificado do RAID-DP padrão para RAID4 antes ou depois que o agregado é espelhado.
Passos

  1. Espelhar o agregado raiz:

    storage aggregate mirror aggr_name

    O comando a seguir espelha o agregado raiz para "'controller_A_1":

    controller_A_1::> storage aggregate mirror aggr0_controller_A_1

    Isso reflete o agregado, por isso consiste em um Plex local e um Plex remoto localizado no local remoto de MetroCluster.

  2. Repita a etapa anterior para cada nó na configuração do MetroCluster.

Informações relacionadas

"Gerenciamento de storage lógico"

"Conceitos de ONTAP"

Criando um agregado de dados espelhados em cada nó

Você precisa criar um agregado de dados espelhados em cada nó no grupo de DR.

Antes de começar

  • Você deve saber quais unidades ou LUNs de array serão usados no novo agregado.

  • Se você tiver vários tipos de unidade no sistema (armazenamento heterogêneo), você deve entender como pode garantir que o tipo de unidade correto esteja selecionado.

Sobre esta tarefa

  • As unidades e LUNs de array são de propriedade de um nó específico. Quando você cria um agregado, todas as unidades nesse agregado precisam ser de propriedade do mesmo nó, que se torna o nó inicial desse agregado.

  • Os nomes agregados devem estar em conformidade com o esquema de nomenclatura que você determinou quando você planejou sua configuração do MetroCluster.

    "Gerenciamento de disco e agregado"

Passos

  1. Apresentar uma lista de peças sobresselentes disponíveis:

    storage disk show -spare -owner node_name

  2. Criar o agregado:

    storage aggregate create -mirror true

    Se você estiver conetado ao cluster na interface de gerenciamento de cluster, poderá criar um agregado em qualquer nó do cluster. Para garantir que o agregado seja criado em um nó específico, use o -node parâmetro ou especifique as unidades que são de propriedade desse nó.

    Você pode especificar as seguintes opções:

    • Nó inicial do agregado (ou seja, o nó que possui o agregado em operação normal)

    • Lista de unidades específicas ou LUNs de storage que devem ser adicionados ao agregado

    • Número de unidades a incluir

      Observação Na configuração mínima suportada, na qual um número limitado de unidades está disponível, você deve usar a opção force-small-Aggregate para permitir a criação de um agregado RAID-DP de três discos.

    • Estilo de checksum para usar para o agregado

    • Tipo de unidades a utilizar

    • Tamanho das unidades a utilizar

    • Velocidade de condução a utilizar

    • Tipo RAID para grupos RAID no agregado

    • Número máximo de unidades ou LUNs de storage que podem ser incluídos em um grupo RAID

    • Se unidades com RPM diferentes são permitidas para obter mais informações sobre essas opções, consulte a storage aggregate create página de manual.

      O comando a seguir cria um agregado espelhado com 10 discos:

    cluster_A::> storage aggregate create aggr1_node_A_1 -diskcount 10 -node node_A_1 -mirror true
[Job 15] Job is queued: Create aggr1_node_A_1.
[Job 15] The job is starting.
[Job 15] Job succeeded: DONE

  3. Verifique o grupo RAID e as unidades do seu novo agregado:

    storage aggregate show-status -aggregate aggregate-name

Criação de agregados de dados sem espelhamento

Você pode, opcionalmente, criar agregados de dados sem espelhamento para dados que não exigem o espelhamento redundante fornecido pelas configurações do MetroCluster.

Antes de começar

  • Você deve saber quais unidades ou LUNs de array serão usados no novo agregado.

  • Se você tiver vários tipos de unidade no sistema (armazenamento heterogêneo), você deve entender como pode verificar se o tipo de unidade correto está selecionado.

Exemplo 1. Sobre esta tarefa

ATENÇÃO: Nas configurações MetroCluster FC, os agregados sem espelhamento só estarão online após um switchover se os discos remotos no agregado estiverem acessíveis. Se os ISLs falharem, o nó local poderá não conseguir aceder aos dados nos discos remotos sem espelhamento. A falha de um agregado pode levar a uma reinicialização do nó local.

Observação Os agregados sem espelhamento devem ser locais para o nó que os possui.

  • As unidades e LUNs de array são de propriedade de um nó específico. Quando você cria um agregado, todas as unidades nesse agregado precisam ser de propriedade do mesmo nó, que se torna o nó inicial desse agregado.

  • Os nomes agregados devem estar em conformidade com o esquema de nomenclatura que você determinou quando você planejou sua configuração do MetroCluster.

  • O "Gerenciamento de discos e agregados" contém mais informações sobre o espelhamento de agregados.

Passos

  1. Apresentar uma lista de peças sobresselentes disponíveis:

    storage disk show -spare -owner node_name

  2. Criar o agregado:

    storage aggregate create

    Se você estiver conetado ao cluster na interface de gerenciamento de cluster, poderá criar um agregado em qualquer nó do cluster. Para verificar se o agregado é criado em um nó específico, você deve usar o -node parâmetro ou especificar unidades que são de propriedade desse nó.

    Você pode especificar as seguintes opções:

    • Nó inicial do agregado (ou seja, o nó que possui o agregado em operação normal)

    • Lista de unidades específicas ou LUNs de storage que devem ser adicionados ao agregado

    • Número de unidades a incluir

    • Estilo de checksum para usar para o agregado

    • Tipo de unidades a utilizar

    • Tamanho das unidades a utilizar

    • Velocidade de condução a utilizar

    • Tipo RAID para grupos RAID no agregado

    • Número máximo de unidades ou LUNs de storage que podem ser incluídos em um grupo RAID

    • Se unidades com RPM diferentes são permitidas para obter mais informações sobre essas opções, consulte a storage aggregate create página de manual.

      O comando a seguir cria um agregado sem espelhamento com 10 discos:

    controller_A_1::> storage aggregate create aggr1_controller_A_1 -diskcount 10 -node controller_A_1
[Job 15] Job is queued: Create aggr1_controller_A_1.
[Job 15] The job is starting.
[Job 15] Job succeeded: DONE

  3. Verifique o grupo RAID e as unidades do seu novo agregado:

    storage aggregate show-status -aggregate aggregate-name

Implementando a configuração do MetroCluster

Você deve executar o metrocluster configure comando para iniciar a proteção de dados em uma configuração do MetroCluster.

Antes de começar

  • Deve haver pelo menos dois agregados de dados espelhados não-raiz em cada cluster.

    Agregados de dados adicionais podem ser espelhados ou sem espelhamento.

    Verifique os tipos de agregados:

    storage aggregate show

    Observação Se você quiser usar um único agregado de dados espelhados, consulte "Configurar o software MCC no ONTAP" para obter instruções.

  • O estado ha-config dos controladores e chassis deve ser "mcc-2n".

Sobre esta tarefa

Você pode emitir o metrocluster configure comando uma vez, em qualquer um dos nós, para ativar a configuração do MetroCluster. Você não precisa emitir o comando em cada um dos sites ou nós, e não importa em qual nó ou site você escolher emitir o comando.

Passos

  1. Configure o MetroCluster no seguinte formato:

    Se a sua configuração do MetroCluster tiver…​

    Então faça isso…​

    Vários agregados de dados

    A partir do prompt de qualquer nó, configure o MetroCluster:

    metrocluster configure node-name

    Um único agregado de dados espelhados

    1. A partir do prompt de qualquer nó, altere para o nível de privilégio avançado:

      set -privilege advanced

      Você precisa responder com "'y'" quando for solicitado a continuar para o modo avançado e você vir o prompt do modo avançado (*>).

    2. Configure o MetroCluster com o -allow-with-one-aggregate true parâmetro:

      metrocluster configure -allow-with-one-aggregate true node-name

    3. Voltar para o nível de privilégio de administrador set -privilege admin
    Observação A prática recomendada é ter vários agregados de dados. Se o primeiro grupo de DR tiver apenas um agregado e quiser adicionar um grupo de DR com um agregado, mova o volume de metadados do agregado de dados único. Para obter mais informações sobre este procedimento, "Movimentação de um volume de metadados nas configurações do MetroCluster"consulte .

    O comando a seguir habilita a configuração do MetroCluster em todos os nós do grupo DR que contém "'controller_A_1":

    cluster_A::*> metrocluster configure -node-name controller_A_1

[Job 121] Job succeeded: Configure is successful.

  2. Verifique o status da rede no local A:

    network port show

    O exemplo a seguir mostra o uso da porta de rede:

    cluster_A::> network port show
                                                          Speed (Mbps)
Node   Port      IPspace   Broadcast Domain Link   MTU    Admin/Oper
------ --------- --------- ---------------- ----- ------- ------------
controller_A_1
       e0a       Cluster   Cluster          up     9000  auto/1000
       e0b       Cluster   Cluster          up     9000  auto/1000
       e0c       Default   Default          up     1500  auto/1000
       e0d       Default   Default          up     1500  auto/1000
       e0e       Default   Default          up     1500  auto/1000
       e0f       Default   Default          up     1500  auto/1000
       e0g       Default   Default          up     1500  auto/1000

7 entries were displayed.

  3. Verifique a configuração do MetroCluster de ambos os sites na configuração do MetroCluster.

    1. Verifique a configuração a partir do site A metrocluster show

      cluster_A::> metrocluster show

Cluster                   Entry Name          State
------------------------- ------------------- -----------
 Local: cluster_A         Configuration state configured
                          Mode                normal
                          AUSO Failure Domain auso-on-cluster-disaster
Remote: cluster_B         Configuration state configured
                          Mode                normal
                          AUSO Failure Domain auso-on-cluster-disaster

    2. Verifique a configuração a partir do local B metrocluster show

      cluster_B::> metrocluster show
Cluster                   Entry Name          State
------------------------- ------------------- -----------
 Local: cluster_B         Configuration state configured
                          Mode                normal
                          AUSO Failure Domain auso-on-cluster-disaster
Remote: cluster_A         Configuration state configured
                          Mode                normal
                          AUSO Failure Domain auso-on-cluster-disaster

Configuração de pontes FC para SAS para monitoramento de integridade

Em sistemas que executam versões do ONTAP anteriores a 9,8, se sua configuração incluir pontes FC para SAS, você deverá executar algumas etapas especiais de configuração para monitorar as pontes FC para SAS na configuração do MetroCluster.

  • Ferramentas de monitoramento SNMP de terceiros não são suportadas para bridges FibreBridge.

  • A partir do ONTAP 9.8, as bridges FC para SAS são monitoradas por meio de conexões na banda por padrão, e não é necessária configuração adicional.

Observação A partir de ONTAP 9.8, o storage bridge comando é substituído por system bridge. As etapas a seguir mostram o storage bridge comando, mas se você estiver executando o ONTAP 9.8 ou posterior, o system bridge comando é preferido.
Passos

  1. No prompt do cluster do ONTAP, adicione a ponte ao monitoramento de integridade:

    1. Adicione a ponte, usando o comando para sua versão do ONTAP:

      Versão de ONTAP

      Comando

      ONTAP 9 F.5 e mais tarde

      storage bridge add -address 0.0.0.0 -managed-by in-band -name bridge-name

      ONTAP 9 .4 e anteriores

      storage bridge add -address bridge-ip-address -name bridge-name

    2. Verifique se a ponte foi adicionada e está configurada corretamente:

      storage bridge show

      Pode levar até 15 minutos para refletir todos os dados por causa do intervalo de votação. O monitor de saúde do ONTAP pode entrar em Contato e monitorar a ponte se o valor na coluna "Status" for "ok", e outras informações, como o nome mundial (WWN), forem exibidas.

      O exemplo a seguir mostra que as bridges FC para SAS estão configuradas:

    controller_A_1::> storage bridge show

Bridge              Symbolic Name Is Monitored  Monitor Status  Vendor Model                Bridge WWN
------------------  ------------- ------------  --------------  ------ -----------------    ----------
ATTO_10.10.20.10  atto01        true          ok              Atto   FibreBridge 7500N   	20000010867038c0
ATTO_10.10.20.11  atto02        true          ok              Atto   FibreBridge 7500N   	20000010867033c0
ATTO_10.10.20.12  atto03        true          ok              Atto   FibreBridge 7500N   	20000010867030c0
ATTO_10.10.20.13  atto04        true          ok              Atto   FibreBridge 7500N   	2000001086703b80

4 entries were displayed

 controller_A_1::>

Verificar a configuração do MetroCluster

Você pode verificar se os componentes e as relações na configuração do MetroCluster estão funcionando corretamente. Você deve fazer uma verificação após a configuração inicial e depois de fazer quaisquer alterações na configuração do MetroCluster. Você também deve fazer uma verificação antes de um switchover negociado (planejado) ou de uma operação de switchback.

Se o metrocluster check run comando for emitido duas vezes dentro de um curto espaço de tempo em um ou em ambos os clusters, um conflito pode ocorrer e o comando pode não coletar todos os dados. Os comandos subsequentes metrocluster check show não mostram a saída esperada.

  1. Verificar a configuração:

    metrocluster check run

    O comando é executado como um trabalho em segundo plano e pode não ser concluído imediatamente.

    cluster_A::> metrocluster check run
The operation has been started and is running in the background. Wait for
it to complete and run "metrocluster check show" to view the results. To
check the status of the running metrocluster check operation, use the command,
"metrocluster operation history show -job-id 2245"
    cluster_A::> metrocluster check show

Component           Result
------------------- ---------
nodes               ok
lifs                ok
config-replication  ok
aggregates          ok
clusters            ok
connections         ok
volumes             ok
7 entries were displayed.

  2. Apresentar resultados mais detalhados:

    metrocluster check run

    metrocluster check aggregate show

    metrocluster check cluster show

    metrocluster check config-replication show

    metrocluster check lif show

    metrocluster check node show

    Os metrocluster check show comandos mostram os resultados do comando mais recente metrocluster check run. Você deve sempre executar o metrocluster check run comando antes de usar os metrocluster check show comandos para que as informações exibidas sejam atuais.

    O exemplo a seguir mostra a metrocluster check aggregate show saída do comando para uma configuração de MetroCluster de quatro nós saudável:

    cluster_A::> metrocluster check aggregate show

Last Checked On: 8/5/2014 00:42:58

Node                  Aggregate                  Check                      Result
---------------       --------------------       ---------------------      ---------
controller_A_1        controller_A_1_aggr0
                                                 mirroring-status           ok
                                                 disk-pool-allocation       ok
                                                 ownership-state            ok
                      controller_A_1_aggr1
                                                 mirroring-status           ok
                                                 disk-pool-allocation       ok
                                                 ownership-state            ok
                      controller_A_1_aggr2
                                                 mirroring-status           ok
                                                 disk-pool-allocation       ok
                                                 ownership-state            ok


controller_A_2        controller_A_2_aggr0
                                                 mirroring-status           ok
                                                 disk-pool-allocation       ok
                                                 ownership-state            ok
                      controller_A_2_aggr1
                                                 mirroring-status           ok
                                                 disk-pool-allocation       ok
                                                 ownership-state            ok
                      controller_A_2_aggr2
                                                 mirroring-status           ok
                                                 disk-pool-allocation       ok
                                                 ownership-state            ok

18 entries were displayed.

    O exemplo a seguir mostra a metrocluster check cluster show saída do comando para uma configuração de MetroCluster de quatro nós saudável. Isso indica que os clusters estão prontos para executar um switchover negociado, se necessário.

    Last Checked On: 9/13/2017 20:47:04

Cluster               Check                           Result
--------------------- ------------------------------- ---------
mccint-fas9000-0102
                      negotiated-switchover-ready     not-applicable
                      switchback-ready                not-applicable
                      job-schedules                   ok
                      licenses                        ok
                      periodic-check-enabled          ok
mccint-fas9000-0304
                      negotiated-switchover-ready     not-applicable
                      switchback-ready                not-applicable
                      job-schedules                   ok
                      licenses                        ok
                      periodic-check-enabled          ok
10 entries were displayed.
Informações relacionadas

"Gerenciamento de disco e agregado"

"Gerenciamento de rede e LIF"

Verificando erros de configuração do MetroCluster com o Config Advisor

Você pode acessar o site de suporte da NetApp e baixar a ferramenta Config Advisor para verificar se há erros de configuração comuns.

O Config Advisor é uma ferramenta de validação de configuração e verificação de integridade. Você pode implantá-lo em sites seguros e sites não seguros para coleta de dados e análise do sistema.

Observação O suporte para Config Advisor é limitado e está disponível apenas online.

  1. Vá para a página de download do Config Advisor e baixe a ferramenta.

    "NetApp Downloads: Config Advisor"

  2. Execute o Config Advisor, revise a saída da ferramenta e siga as recomendações na saída para resolver quaisquer problemas descobertos.

Verificando switchover, cura e switchback

Você deve verificar as operações de switchover, recuperação e switchback da configuração do MetroCluster.

  1. Use os procedimentos para comutação negociada, cura e switchback que são mencionados no "Execute switchover, cura e switchback".

Protegendo arquivos de backup de configuração

Você pode fornecer proteção adicional para os arquivos de backup de configuração de cluster especificando um URL remoto (HTTP ou FTP) onde os arquivos de backup de configuração serão carregados além dos locais padrão no cluster local.

  1. Defina o URL do destino remoto para os arquivos de backup de configuração:

    system configuration backup settings modify URL-of-destination

    O "Gerenciamento de clusters com a CLI" contém informações adicionais na seção Gerenciando backups de configuração.