Skip to main content

NetApp_Insight_2020.png 

NetApp Knowledgebase

What is the LIF Choice order for Cluster Aware backups in NDMP?

Views:
479
Visibility:
Public
Votes:
1
Category:
data-ontap-8
Specialty:
dp
Last Updated:

 

Applies to

  • ONTAP 8 7-mode
  • NDMP
  • DMA (Backup Application)

Answer

There are two types of communication that are used by NDMP Backups configured with CAB: Control and Data connection.< Control

  • The initial connection made by the DMA (Backup Application), used to negotiate backup settings, parameters, CAB configuration.  Within NDMP logs this is the following communication
    • DMA < S or DMA > S
    • S < BKUP
    • This communication always uses the interface which the DMA selects. I.E The DMA targets an NDMP host for backup using a specific IP address. As long as the port is configured to listen for NDMP requests on port 10000, then this can be established.

​​User-added image

  • Whether the port is able to listen for this communication depends on the SVM which owns this LIF, and if the same SVM has NDMP enabled:

Data Connection:

  • This is the connection established for the purpose of sending the Backup Data (Data which is Dumped), to a remote address specified by the DMA during the initial Control Communication: This is the following within NDMP logs:

Wed Dec 21 2016 10:10:32 +00:00 [kern_ndmpd:info:5123] [46049]  DEBUG: DMA>>S V4 sequence=10 (0xa)
Wed Dec 21 2016 10:10:32 +00:00 [kern_ndmpd:info:5123] [46049]  DEBUG:      Time_stamp=0x585a5525 (Dec 21 10:10:45 2016)
Wed Dec 21 2016 10:10:32 +00:00 [kern_ndmpd:info:5123] [46049]  DEBUG:      message type=0 (NDMP4_MESSAGE_REQUEST)
Wed Dec 21 2016 10:10:32 +00:00 [kern_ndmpd:info:5123] [46049]  DEBUG:      message_code=0x40a (NDMP4_DATA_CONNECT)
Wed Dec 21 2016 10:10:32 +00:00 [kern_ndmpd:info:5123] [46049]  DEBUG:      reply_sequence=0 (0x0)
Wed Dec 21 2016 10:10:32 +00:00 [kern_ndmpd:info:5123] [46049]  DEBUG:      error_code=0 (NDMP4_NO_ERR)
Wed Dec 21 2016 10:10:32 +00:00 [kern_ndmpd:info:5123] [46049]  DEBUG:      addr_type=1 (NDMP4_ADDR_TCP)
Wed Dec 21 2016 10:10:32 +00:00 [kern_ndmpd:info:5123] [46049]  DEBUG:      tcp_addr len=1 (0x1)
Wed Dec 21 2016 10:10:32 +00:00 [kern_ndmpd:info:5123] [46049]  DEBUG:      tcp_addr[0] ip_addr=0xc0a8002a [192.168.0.42]
Wed Dec 21 2016 10:10:32 +00:00 [kern_ndmpd:info:5123] [46049]  DEBUG:      tcp_addr[0] port=4477
Wed Dec 21 2016 10:10:32 +00:00 [kern_ndmpd:info:5123] [46049]  DEBUG:      tcp_addr[0] addr_env_len=0 (0x0)

Note: The LIF used by the DMA to setup the initial control communication is not always the LIF used for the Data Connection.

What Data LIF will be used for this DATA_CONNECT operation?

  • The Interface used for the Data Connection cannot be explicitly set, but can be isolated to a specific set of interfaces which are possible. This creates some challenges and should be understood to best isolate & guarantee the desired interface is used:
    • Based on the SVM you initially communicate with for the Control communication, you will use this SVM's interfaces based on the corresponding preferred-interface-role:

cm2520-ams::> vserver services ndmp show -vserver cm2520-ams -fields preferred-interface-role

vserver    preferred-interface-role

---------- -----------------------------------

cm2520-ams intercluster,cluster-mgmt,node-mgmt

The order defined here is the order in which interfaces owned by the corresponding SVM will be used.

  1. Intercluster
  2. If intercluster fails or does not exist, use cluster-mgmt,
  3. if cluster-mgmt fails or does not exist, use node-mgmt
  • When control communication goes initially through a Data SVM , there are only two possible interfaces for the Data Connection: Data, Intercluster

cm2520-ams::> vserver services ndmp show -vserver iscsi -fields preferred-interface-role

vserver preferred-interface-role

------- ------------------------

iscsi   intercluster,data

  • Because CAB checks for volume affinity (which node the volume resides in), CAB will always use interfaces which are also on the same Node. If the preferred interface does not exist within the node, the next preferred interface is chosen.

Special Cases: Multiple Interfaces available to choose from with Preferred interface role choice:

  • Based on the Preferred Interface Role chosen, there may often be more than one interface available of that particular role, on that particular node. For Example, with data Interfaces:

User-added image

User-added image


Problem: It might be desirable to use  'iscsi_ndmp_admin' on port e0e for NDMP communication.

The order at which the interface is selected cannot be configured, but we do know which interface will be used first based on the current port used by the LIF &  the output of 'ifconfig -a'.  The order at which the interface is used depends on the order in which the interface appears in the node-run output of 'ifconfig -a'.

cm2520-ams::> node run -node cm2520-ams-02 ifconfig -a

User-added image
  • Because e0c appears before e0e, the LIF's   iscsi_lif_n2 &   iscsi_nfs will be used first for DATA_CONNECT. DATA_CONNECT MUST FAIL on these first two LIF's for the 3rd LIF  iscsi_ndmp_admin'' to be used. As all these LIF's reside within the same SUBNET, the likely hood is that the first or second would be successful. Sharing the subnet & interface could intrude on existing production data connections.

Note: It is best practice to separate Backup traffic from Production traffic within different subnets, this to prevent congestion, interference, and in this case wrong LIF choice.

How can this be solved?

  • Configuring the existing LIF 'iscsi_ndmp_admin' and BKUP destination within an isolated subnet, which cannot be reached by the first two interfaces. This would ensure the desired interface is used.
  • Moving the existing LIF 'iscsi_ndmp_admin' to port e0a would ensure this LIF is chosen first during the DATA_CONNECT.
  • It may be better to utilized Intercluster LIF's to reduce the number of LIF's which may be attempted during the Backup. If existing InterCluste LIF's cannot reach the Backup destination because of networking limitations, configuring new InterCluster Lif's within new IPSpaces may be required. When new InterCluster Lif's are configured in a new IPSpace, existing Cluster Peering will not be affected.

In this case, if e0a is used by an new or existing InterCluster LIF within a new or existing IPSpace, it would be picked first if the SVM was configured to look for InterCluster Lif's first:
User-added image

Additional Information

N/A