InfoScale 7.4 introduces dynamic VVR tuning for both TCP & UDP protocol connections avoiding tuning of nmcom_max_connections & deprecated vol_vvr_force_connections tunables

book

Article ID: 100048720

calendar_today

Updated On:

Description

Description

 

Veritas Volume Replicator (VVR) uses UDP or TCP transport protocols to communicate between the Primary and Secondary VVR configured environments (servers).

These protocols are used to exchange data messages.


After a rlink disconnect, VVR 6.2.1 reverts back to auto-tuning the number of TCP connections during the reconnect operation.

Veritas empowered the user to force the nmcom_max_connections during VVR rlink reconnect operations, using 2 legacy tunable values:
 

   1. Set nmcom_max_connections to the desired value.
       
        Example:  vxtune nmcom_max_connections 16

The "nmcom_max_connections" specifies the number of TCP connections that should be used by a Primary when using the TCP protocol for replication.

This tunable only takes effect on a Primary using the TCP protocol.

The nmcom_max_connections tunable is a hidden parameter, is only shown via the vxtune command if specified explicitly.


    2. Set vol_vvr_force_connections to 1 to enable force of max tcp connections.

        Example:  vxtune vol_vvr_force_connections 1
 

NOTE: To disable the force max tcp connections tunable, set vol_vvr_force_connections to 0.


•    The current number of active connections can be verified using vxkprint utility:

# /etc/vx/diag.d/vxkprint | grep active_connections
active_connections=1


NOTE: The vol_vvr_force_connections is reset to after reboot, so active connections becomes dynamically changing based on RTT(Round Trip Time) instead of a defined fixed value.


To overcome a legacy issue whereby the number of  TCP connections changes following a system reboot, even when nmcom_max_connections tunable has been set.

The vol_vvr_force_connections became a tunable, enabling defined connections to remain persistent across reboots.


When defining the  'nmcom_max_connections', the 'vol_vvr_force_connection' tunable is enabled.
 


InfoScale 7.4 VVR Development:


With the InfoScale 7.4 product release, the design went a step further and now both TCP & UDP connections have become dynamic, without the need for manual tuning to achieve better performance.
 

InfoScale 7.4:        'vol_vvr_force_connection' tunable is NOT available in with the InfoScale 7.4 release.
    


NOTE: UDP also uses 16 multiple data structures, where all the data is transmitted in parallel to multiple network sockets and distributes the network load.


Product Version Differences:


-    VxVM (VVR) 6.2.1 servers, apply these tunables:
 

    # vxtune nmcom_max_connections 16
    # vxtune vol_vvr_force_connections 1

 

-    On InfoScale 7.4 servers, apply below tunable to enable specific testing:
 

    # vxtune nmcom_max_connections 16


    Resume replication


•    Note: 'vol_vvr_force_connections' is not available with the InfoScale 7.4 release. Hence we need to explicitly set 'nmcom_max_connections' to a non-default, using above steps, each time the system gets rebooted.

 

The code changes to persistently keep the nmcom_max_connections across reboot is NOT available in 7.4 release.
 

For testing purposes, customers can define 'nmcom_max_connections=16' after each reboot


The "-C" option can be used to change the tunables cross the cluster for the customer's CVR env.

# vxtune -C nmcom_max_connections 16
# vxtune -C vol_vvr_force_connections 1

 

 

 

Issue/Introduction

InfoScale 7.4 introduces dynamic VVR tuning for both TCP & UDP protocol connections avoiding tuning of nmcom_max_connections & deprecated vol_vvr_force_connections tunables