HP MSA 1040 HP MSA 1040 SMU Reference Guide (762784-001, March 2014) - Page 17

Related topics, About spares - manual

Page 17 highlights

When you create a vdisk you can use the default chunk size or one that better suits your application. The chunk size is the amount of contiguous data that is written to a disk before moving to the next disk. After a vdisk is created its chunk size cannot be changed. For example, if the host is writing data in 16-KB transfers, that size would be a good choice for random transfers because one host read would generate the read of exactly one disk in the volume. That means if the requests are random-like, then the requests would be spread evenly over all of the disks, which is good for performance. If you have 16-KB accesses from the host and a 64-KB block size, then some of the hosts accesses would hit the same disk; each chunk contains four possible 16-KB groups of data that the host might want to read, which is not an optimal solution. Alternatively, if the host accesses were 128 KB, then each host read would have to access two disks in the vdisk. For random patterns, that ties up twice as many disks. When you create a vdisk you can also create volumes within it. A volume is a logical subdivision of a vdisk, and can be mapped to controller host ports for access by hosts. The storage system presents only volumes, not vdisks, to hosts. You can create vdisks with or without volumes by using the Provisioning Wizard, or you can create vdisks manually. TIP: Best practices for creating vdisks include: • To maximize capacity, use disks of similar size. • For greatest reliability, use disks of the same size and rotational speed. • For storage configurations using many disks, create a few vdisks each containing many disks instead of many vdisks each containing a few disks. • To maximize capacity and disk usage (but not performance), you can create vdisks larger than 2 TB and divide them into multiple volumes each having a capacity of 2 TB or less. This increases the usable capacity of storage configurations by reducing the total number of parity disks required when using parity-protected RAID levels. This differs from using a volume larger than 2 TB, which requires specific support by the host operating system, I/O adapter, and application. • For maximum use of a dual-controller system's resources, each controller should own a similar number of vdisks. • Set the chunk size to match the transfer block size of the host application. Related topics • "About RAID levels" (page 26) • "About spares" (page 17) • "About volumes" (page 18) • Vdisk topics in "Provisioning the system" (page 59) • "Configuring a vdisk" (page 54) • "Verifying a vdisk" (page 87) • "Scrubbing a vdisk" (page 88) • Viewing information about a vdisk (page 100), all vdisks (page 99), or the system (page 93) • "Removing a vdisk from quarantine" (page 88) About spares A controller automatically reconstructs a fault-tolerant vdisk (RAID 1, 3, 5, 6, 10, 50) when one or more of its disks fails and a compatible spare disk is available. A compatible disk has enough capacity to replace the failed disk and is the same type (enterprise SAS or midline SAS). There are three types of spares: • Dedicated spare. Reserved for use by a specific vdisk to replace a failed disk. Most secure way to provide spares for vdisks but expensive to reserve a spare for each vdisk. • Global spare. Reserved for use by any fault-tolerant vdisk to replace a failed disk. • Dynamic spare. An available compatible disk that is automatically assigned to replace a failed disk in a fault-tolerant vdisk. When a disk fails, the system looks for a dedicated spare first. If it does not find a dedicated spare, it looks for a global spare. If it does not find a compatible global spare and the dynamic spares option is enabled, it takes any available compatible disk. If no compatible disk is available, reconstruction cannot start. System concepts 17

  • 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

System concepts
17
When you create a vdisk you can use the default chunk size or one that better suits your application. The chunk size
is the amount of contiguous data that is written to a disk before moving to the next disk. After a vdisk is created its
chunk size cannot be changed. For example, if the host is writing data in 16-KB transfers, that size would be a good
choice for random transfers because one host read would generate the read of exactly one disk in the volume. That
means if the requests are random-like, then the requests would be spread evenly over all of the disks, which is good
for performance. If you have 16-KB accesses from the host and a 64-KB block size, then some of the hosts accesses
would hit the same disk; each chunk contains four possible 16-KB groups of data that the host might want to read,
which is not an optimal solution. Alternatively, if the host accesses were 128 KB, then each host read would have to
access two disks in the vdisk. For random patterns, that ties up twice as many disks.
When you create a vdisk you can also create volumes within it. A volume is a logical subdivision of a vdisk, and can
be mapped to controller host ports for access by hosts. The storage system presents only volumes, not vdisks, to hosts.
You can create vdisks with or without volumes by using the Provisioning Wizard, or you can create vdisks manually.
TIP:
Best practices for creating vdisks include:
To maximize capacity, use disks of similar size.
For greatest reliability, use disks of the same size and rotational speed.
For storage configurations using many disks, create a few vdisks each containing many disks instead of many
vdisks each containing a few disks.
To maximize capacity and disk usage (but not performance), you can create vdisks larger than 2 TB and divide
them into multiple volumes each having a capacity of 2 TB or less. This increases the usable capacity of storage
configurations by reducing the total number of parity disks required when using parity-protected RAID levels. This
differs from using a
volume
larger than 2 TB, which requires specific support by the host operating system, I/O
adapter, and application.
For maximum use of a dual-controller system’s resources, each controller should own a similar number of vdisks.
Set the chunk size to match the transfer block size of the host application.
Related topics
"About RAID levels" (page 26)
"About spares" (page 17)
"About volumes" (page 18)
Vdisk topics in
"Provisioning the system" (page 59)
"Configuring a vdisk" (page 54)
"Verifying a vdisk" (page 87)
"Scrubbing a vdisk" (page 88)
Viewing information about a vdisk (
page 100
), all vdisks (
page 99
), or the system (
page 93
)
"Removing a vdisk from quarantine" (page 88)
About spares
A controller automatically reconstructs a fault-tolerant vdisk (RAID 1, 3, 5, 6, 10, 50) when one or more of its disks
fails and a compatible spare disk is available. A compatible disk has enough capacity to replace the failed disk and
is the same type (enterprise SAS or midline SAS).
There are three types of spares:
Dedicated spare
. Reserved for use by a specific vdisk to replace a failed disk. Most secure way to provide spares
for vdisks but expensive to reserve a spare for each vdisk.
Global spare
. Reserved for use by any fault-tolerant vdisk to replace a failed disk.
Dynamic spare
. An available compatible disk that is automatically assigned to replace a failed disk in a
fault-tolerant vdisk.
When a disk fails, the system looks for a dedicated spare first. If it does not find a dedicated spare, it looks for a
global spare. If it does not find a compatible global spare and the dynamic spares option is enabled, it takes any
available compatible disk. If no compatible disk is available, reconstruction cannot start.