HP 3PAR StoreServ 7450 4-node HP 3PAR Command Line Interface Administrator& - Page 162

Maximum Number of QoS Rules per VV, QoS on a Subset of VVset Volumes, Application Interoperability

Page 162 highlights

Lowering the QoS cap will result in higher I/O response times and reduced throughput on the host, and eventually queue-full errors are returned by the array to the host. NOTE: Response time is the average measured time that it takes the array to process an I/O request. On HP 3PAR StoreServ Storage systems, response time may be reported as "service time." Response time is measured in milliseconds. On the other hand, a lowered QoS cap for one workload will free I/O resources on the host, which in turn may reduce memory and CPU cycle consumption to the benefit of other workloads. HP 3PAR Priority Optimization can control host-side resources, obviating the need to define QoS and metrics in a workload manager tool on the host. However, host-side and storage system QoS rules can be combined for tighter control, or when memory and CPU cycle consumption management is required on the host. Maximum Number of QoS Rules per VV A given VV can be part of a large number of VVsets. HP does not recommend application of multiple QoS rules to the same VV. For this reason, QoS rules can be defined on a maximum of eight VVsets that contain a particular VV. The lowest value for IOPS and bandwidth, for a VVset that hosts a VV, imposes its limits on the I/O traffic to and from the VV. QoS on a Subset of VVset Volumes By default, a QoS rule on a VVset governs all volumes in the set; but only a subset of the volumes in the VVset might need a QoS rule. In this situation, create a second VVset that contains only the volumes that need a QoS rule, and then define the rule. The volumes in the second VVset do not need to be exported for the QoS rule to take action. If the System rule is defined, it takes action on all VVsets for which a QoS rule has not been defined. If at least one volume of the VVset has a QoS rule defined in another VVset, the named QoS rule takes precedence over the System rule, even if the named QoS rule has a lower value for IOPS or bandwidth. Application Interoperability HP 3PAR Priority Optimization sets and manages QoS rules defined on I/O traffic that enters and leaves an HP 3PAR StoreServ meaning on the front-end host ports of the array. Software products for HP 3PAR StoreServ storage systems, such as Dynamic Optimization (DO), Adaptive Optimization (AO), Virtual and Physical Copy, HP 3PAR System Reporter, the Thin Provisioning Suite, and the Recovery Manager packages work on data in the backend. This means they are all compatible and operate transparently to HP 3PAR Priority Optimization. HP 3PAR Peer Motion traffic over the Peer ports can be the subject of a QoS rule on the source HP 3PAR StoreServ Storage system. Databases All database software vendors recommend that you separate data files, index files, and transactional and archive logs on separate volumes. The write capability and location of the online transaction logs are most important as the entire performance of the database depends on the writes to these logs. For this reason a QoS rule on the volumes containing the online transaction logs should be carefully dimensioned to not inhibit the performance of the database. QoS rules on the I/O performance of the database volumes will take care of runaway queries that consume lots of IOPS and bandwidth. Databases at many customers are a considered mission-critical application and putting a QoS rule on them should never inhibit their normal operation. Microsoft Exchange Microsoft Exchange Server is a scalable, commercial mail server that supports thousands of users per instance. As a general practice, it is recommended that the mailbox database files and the log files be separated onto different volumes. The databases can be spread over multiple volumes as well. Using a QoS rule, to limit the IOPS and/or bandwidth to the volume sets for the mail 162 HP Priority Optimization

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204

Lowering the QoS cap will result in higher I/O response times and reduced throughput on the host,
and eventually queue-full errors are returned by the array to the host.
NOTE:
Response time is the average measured time that it takes the array to process an I/O
request. On HP 3PAR StoreServ Storage systems, response time may be reported as “service time.”
Response time is measured in milliseconds.
On the other hand, a lowered QoS cap for one workload will free I/O resources on the host,
which in turn may reduce memory and CPU cycle consumption to the benefit of other workloads.
HP 3PAR Priority Optimization can control host-side resources, obviating the need to define QoS
and metrics in a workload manager tool on the host. However, host-side and storage system QoS
rules can be combined for tighter control, or when memory and CPU cycle consumption management
is required on the host.
Maximum Number of QoS Rules per VV
A given VV can be part of a large number of VVsets. HP does not recommend application of
multiple QoS rules to the same VV. For this reason, QoS rules can be defined on a maximum of
eight VVsets that contain a particular VV. The lowest value for IOPS and bandwidth, for a VVset
that hosts a VV, imposes its limits on the I/O traffic to and from the VV.
QoS on a Subset of VVset Volumes
By default, a QoS rule on a VVset governs all volumes in the set; but only a subset of the volumes
in the VVset might need a QoS rule. In this situation, create a second VVset that contains only the
volumes that need a QoS rule, and then define the rule. The volumes in the second VVset do not
need to be exported for the QoS rule to take action.
If the
System
rule is defined, it takes action on all VVsets for which a QoS rule has not been
defined. If at least one volume of the VVset has a QoS rule defined in another VVset, the named
QoS rule takes precedence over the
System
rule, even if the named QoS rule has a lower value
for IOPS or bandwidth.
Application Interoperability
HP 3PAR Priority Optimization sets and manages QoS rules defined on I/O traffic that enters and
leaves an HP 3PAR StoreServ meaning on the front-end host ports of the array. Software products
for HP 3PAR StoreServ storage systems, such as Dynamic Optimization (DO), Adaptive Optimization
(AO), Virtual and Physical Copy, HP 3PAR System Reporter, the Thin Provisioning Suite, and the
Recovery Manager packages work on data in the backend. This means they are all compatible
and operate transparently to HP 3PAR Priority Optimization. HP 3PAR Peer Motion traffic over the
Peer ports can be the subject of a QoS rule on the source HP 3PAR StoreServ Storage system.
Databases
All database software vendors recommend that you separate data files, index files, and transactional
and archive logs on separate volumes. The write capability and location of the online transaction
logs are most important as the entire performance of the database depends on the writes to these
logs. For this reason a QoS rule on the volumes containing the online transaction logs should be
carefully dimensioned to not inhibit the performance of the database. QoS rules on the I/O
performance of the database volumes will take care of runaway queries that consume lots of IOPS
and bandwidth. Databases at many customers are a considered mission-critical application and
putting a QoS rule on them should never inhibit their normal operation.
Microsoft Exchange
Microsoft Exchange Server is a scalable, commercial mail server that supports thousands of users
per instance. As a general practice, it is recommended that the mailbox database files and the
log files be separated onto different volumes. The databases can be spread over multiple volumes
as well. Using a QoS rule, to limit the IOPS and/or bandwidth to the volume sets for the mail
162
HP Priority Optimization