November 2

V7000: gmmaxhostdelay max_host_delay

 

The SVC chcluster command has a (new) option:

gmmaxhostdelay max_host_delay

Specifies the maximum time delay, in milliseconds, above which the Global Mirror link tolerance timer starts counting down. This threshold value determines the additional impact that Global Mirror operations can add to the response times of the Global Mirror source VDisks (volumes). You can use this parameter to increase the threshold from the default value of 5 milliseconds.
The Global Mirror code is designed to detect if it potentially causing performance impacts to the SVC cluster.
If it detects certain conditions, it will start to log 1920 errors and suspend relationships to prevent performance impacts.
While this may be preferable to causing host delays, dealing with 1920 errors and suspended pairs is also not desirable.
This tuneable was added in 5.1.0.6 code to effectively allow you to make GM more willing to wait a little longer before starting to log the 1920 errors. You would only change it if you were getting 1920s and analysis of the TPC stats (esp internode latency) indicates having a slightly higher value (say 20ms) would allow the SVC to ride these small blips out.

By: Anthony

Category: SAN | Comments Off on V7000: gmmaxhostdelay max_host_delay
October 13

V7000: chcluster command options

 

The chcluster command modifies the attributes of an existing clustered system. You can enter this command any time after a clustered system has been created. All the parameters that are associated with this command are optional. However, you must specify one or more parameters with this command.

Syntax

Read syntax diagram

Skip visual syntax diagram
>>- chcluster -- --+-------------------------+-- --------------->
                   '- -name -- cluster_name -'      

>--+--------------------------+-- --+----------------------+---->
   '- -speed -- fabric_speed -'     '- -alias -- id_alias -'   

>-- --+---------------------------------+-- -------------------->
      '- -invemailinterval -- interval -'      

>--+--------------------------------------+-- ------------------>
   '- -gmlinktolerance -- link_tolerance -'      

>--+-------------------------------------+-- ------------------->
   '- -gmmaxhostdelay -- max_host_delay -'      

>--+-------------------------------------------------------------+-->
   '- -gminterdelaysimulation -- inter_cluster_delay_simulation -'   

>--+-------------------------------------------------------------+-->
   '- -gmintradelaysimulation -- intra_cluster_delay_simulation -'   

>-- --+---------------------------------+-- -------------------->
      '- -ntpip -- ipv4_ntp_ip_address -'      

>--+-----------------------------------+-- --------------------->
   '- -ntpip_6 -- ipv6_ntp_ip_address -'      

>--+---------------------------------+-------------------------->
   '- -isnsip -- sns_server_address -'   

>-- --+----------------------------------------+---------------->
      '- -isnsip_6 -- ipv6_sns_server_address -'   

>--+----------------------------------------------------+------->
   '- -relationshipbandwidthlimit -- bandwidth_in_mbps -'   

>--+-----------------------------+------------------------------>
   '- -iscsiauthmethod--+-none-+-'   
                        '-chap-'     

>--+-----------------------------+-----------------------------><
   +- -chapsecret-- chap_secret -+   
   '- -nochapsecret--------------'

Parameters

-name cluster_name
(Optional) Specifies a new name for the clustered system.

Important: The iSCSI Qualified Name (IQN) for each node is generated using the clustered system and node names. If you are using the iSCSI protocol, changing either name also changes the IQN of all of the nodes in the clustered system and might require reconfiguration of all iSCSI-attached hosts.
-speed fabric_speed
(Optional) Specifies the speed of the fabric to which this clustered system is attached. Valid values are 1 or 2 (GB).

Attention: Changing the speed on a running clustered system breaks I/O service to the attached hosts. Before changing the fabric speed, stop I/O from active hosts and force these hosts to flush any cached data by unmounting volumes (for UNIX host types) or by removing drive letters (for Windows host types). Some hosts might need to be rebooted to detect the new fabric speed.
-alias id_alias
(Optional) Specifies an alternate name that does not change the basic ID for the clustered system, but does influence the VDisk_UID of every vdiskhostmap, both existing and new. These objects appear to have been created for a clustered system whose ID matches the alias. Therefore, changing the clustered system alias causes loss of host volume access, until each host rescans for volumes presented by the clustered system.
-invemailinterval interval
(Optional) Specifies the interval at which inventory emails are sent to the designated email recipients. The interval range is 0 to 15. The interval is measured in days. Setting the value to 0 turns the inventory email notification function off.
-gmlinktolerance link_tolerance
(Optional) Specifies the length of time, in seconds, for which an inadequate intercluster link is tolerated for a Global Mirror operation. The parameter accepts values from 10 to 400 seconds in steps of 10 seconds. The default is 300 seconds. You can disable the link tolerance by entering a value of zero (0) for this parameter.
-gmmaxhostdelay max_host_delay
(Optional) Specifies the maximum time delay, in milliseconds, above which the Global Mirror link tolerance timer starts counting down. This threshold value determines the additional impact that Global Mirror operations can add to the response times of the Global Mirror source volumes. You can use this parameter to increase the threshold from the default value of 5 milliseconds.
-gminterdelaysimulation inter_cluster_delay_simulation
(Optional) Specifies the intercluster delay simulation, which simulates the Global Mirror round trip delay between two clusters, in milliseconds. The default is 0; the valid range is 0 to 100 milliseconds.
-gmintradelaysimulation intra_cluster_delay_simulation
(Optional) Specifies the intracluster delay simulation, which simulates the Global Mirror round trip delay in milliseconds. The default is 0; the valid range is 0 to 100 milliseconds.
-ntpip ipv4_ntp_ip_address
(Optional) Specifies the IPv4 address for the Network Time Protocol (NTP) server. Configuring an NTP server address causes the clustered system to immediately start using that NTP server as its time source. To stop using the NTP server as a time source, invoke the -ntpipparameter with a zero address, as follows:

chcluster -ntpip 0.0.0.0
-ntpip_6 ipv6_ntp_ip_address
Note: An IPv6 prefix and gateway must be set for the clustered system before running this command.

(Optional) Specifies the IPv6 address for the NTP server. Configuring an NTP server address causes the clustered system to immediately start using that NTP server as its time source. To stop using the NTP server as a time source, invoke the -ntpip_6 parameter with a zero address, as follows:

chcluster -ntpip_6 0::0
-isnsip sns_server_address
(Optional) Specifies the IPv4 address for the iSCSI storage name service (SNS). To stop using the configured IPv4 iSCSI SNS server, invoke the -isnsip parameter with a zero address, as follows:

chcluster -isnsip 0.0.0.0
-isnsip_6 ipv6_sns_server_address
(Optional) Specifies the IPv6 address for the iSCSI SNS. To stop using the configured IPv6 iSCSI SNS server, invoke the -isnsip_6 parameter with a zero address, as follows:

chcluster -isnsip_6 0::0
-relationshipbandwidthlimit bandwidth_in_mbps
(Optional) Specifies the new background copy bandwidth in megabytes per second (MBps), from 1 – 1000. The default is 25 MBps. This parameter operates clustered system-wide and defines the maximum background copy bandwidth that any relationship can adopt. The existing background copy bandwidth settings defined on a partnership continue to operate, with the lower of the partnership and volume rates attempted.

Note: Do not set this value higher than the default without establishing that the higher bandwidth can be sustained.
-iscsiauthmethod none | chap
(Optional) Sets the authentication method for the iSCSI communications of the clustered system. The iscsiauthmethod value can be none or chap.
-chapsecret chap_secret
(Optional) Sets the Challenge Handshake Authentication Protocol (CHAP) secret to be used to authenticate the clustered system via iSCSI. This parameter is required if the iscsiauthmethod chap parameter is specified. The specified CHAP secret cannot begin or end with a space.
-nochapsecret
(Optional) Clears any previously set CHAP secret for iSCSI authentication. This parameter is not allowed if the chapsecret parameter is specified.

Description

This command modifies specific features of a clustered system. Multiple features can be changed by issuing a single command.

Using the -ntpip or -ntpip_6 parameter allows the clustered system to use an NTP server as an outside time source. The clustered system adjusts the system clock of the configuration node according to time values from the NTP server. The clocks of the other nodes are updated from the configuration node’s clock. In the NTP mode, the setclustertime command is disabled.

All command parameters are optional; however, you must specify at least one parameter.

Use the chclusterip command to modify the clustered system IP address and service IP address.

An invocation example

chcluster -ntpip 9.20.165.16

The resulting output

No feedback
Category: SAN | Comments Off on V7000: chcluster command options
October 13

V7000: Link Tolerance Settings for Mirroring

 

The following setting should probably only be change when copying data between two V7000’s or SVC’s in the same Datacenter.
This is especially true if the two SANs are less than 3 “hops” away. The default setting is for 5 minutes.  A setting of serveral hours is potentially more appropriate  when copying data with in the same datacenter.  A setting of “0” is the same as turning of link tolerance

svctask chcluster -gmlinktolerance <seconds>  to change the ‘link tolerance’ setting.

-gmlinktolerance link_tolerance
(Optional) Specifies the length of time, in seconds, for which an inadequate intercluster link is tolerated for a Global Mirror operation. The parameter accepts values from 10 to 400 seconds in steps of 10 seconds. The default is 300 seconds. You can disable the link tolerance by entering a value of zero (0) for this parameter.

You can use the following parameters to provide the best protection against horrible vmware timeout management:
link tolerance =20
max hostdelay =8

To display the chcluster configuration type:
svcinfo lscluster

To see a more in depth list type the following:
svcinfo lscluster -delim : systemname

Category: SAN | Comments Off on V7000: Link Tolerance Settings for Mirroring
October 12

V7000: Background copy bandwidth impact on foreground I/O latency

Background copy bandwidth impact on foreground I/O latency
The background copy bandwidth determines the rate at which the background copy for Metro Mirror or Global Mirror Copy Services are attempted.
The background copy bandwidth can affect foreground I/O latency in one of three ways:
•    If the background copy bandwidth is set too high for the intercluster link capacity, the following results can occur:
o    The intercluster link is not able to process the background copy I/Os fast enough, and the I/Os can back up (accumulate).
o    For Metro Mirror, there is a delay in the synchronous secondary writes of foreground I/Os.
o    For Global Mirror, the work is backlogged, which delays the processing of writes and causes the relationship to stop.
o    The foreground I/O latency increases as detected by applications.
•    If the background copy bandwidth is set too high for the storage at the primary site, background copy read I/Os overload the primary storage and delay foreground I/Os.
•    If the background copy bandwidth is set too high for the storage at the secondary site, background copy writes at the secondary overload the secondary storage and again delay the synchronous secondary writes of foreground I/Os.
o    For Global Mirror, the work is backlogged and again the relationship is stopped
To set the background copy bandwidth optimally, you must consider all three resources (the primary storage, the intercluster link bandwidth, and the secondary storage). Provision the most restrictive of these three resources between the background copy bandwidth and the peak foreground I/O workload. You must also consider concurrent host I/O because if other write operations arrive at the primary cluster for copy to the remote site, these write operations can be delayed by a high level of background copy and the hosts at the primary site receive poor write-operation response times.
The provisioning for optimal bandwidth for the background copy can also be calculated by determining how much background copy can be allowed before performance of host I/O becomes unacceptable. The background copy bandwidth can be decreased slightly to accommodate peaks in workload and provide a safety margin for host I/O.
Example
If the bandwidth setting at the primary site for the secondary cluster is set to 200 MBps (megabytes per second) and the relationships are not synchronized, the Storwize V7000 attempts to resynchronize the relationships at a maximum rate of 200 MBps with a 25 MBps restriction for each individual relationship. The Storwize V7000 cannot resynchronize the relationship if the throughput is restricted. The following can restrict throughput:
•    The read response time of backend storage at the primary cluster
•    The write response time of the backend storage at the secondary site
•    Intercluster link latency

Category: SAN | Comments Off on V7000: Background copy bandwidth impact on foreground I/O latency
October 12

V7000: Modifying Metro Mirror and Global Mirror partnerships using the CLI – Change Bandwidth

Modifying Metro Mirror and Global Mirror partnerships using the CLI
You can use the command-line interface (CLI) to modify Metro Mirror and Global Mirror partnerships.
Perform the following steps to modify Metro Mirror and Global Mirror partnerships:
1.        To modify Metro Mirror and Global Mirror partnerships, run the svctask chpartnership command. For example, enter:
svctask chpartnership -bandwidth bandwidth_in_mbps remote_cluster_id
where bandwidth_in_mbps is the new bandwidth (in megabytes per second) from the local cluster to the remote cluster, and remote_cluster_id is the ID of the remote cluster.
– Background bandwidth copy rates can also be changed in the GUI under Copy Servers -> Partnerships.
2.        Run the svctask chpartnership command from the remote cluster. For example, enter:
svctask chpartnership -bandwidth bandwidth_in_mbps local_cluster_id
where bandwidth_in_mbps is the new bandwidth (in megabytes per second) from the remote cluster to the local cluster, and local_cluster_id is the ID of the local cluster.

Category: SAN | Comments Off on V7000: Modifying Metro Mirror and Global Mirror partnerships using the CLI – Change Bandwidth