Adaptec 412R User Guide - Page 141

SAN Configuration Not Supported, True LUN Sharing

Page 141 highlights

SAN Solution Strategies (DuraStor 7320SS only) SAN Configuration Not Supported In the active-active dual-port configuration with two independent hubs or the internal hubs, two single-ported hosts is not supported. The issue with this configuration is that if a controller fails, each host loses access to one of the LUNs. For example, if Controller 1 fails, Host 1 can no longer access LUN 2, because Port 2 on Controller 2 has changed from presenting its own LUNs to presenting Controller 1's LUNs. A need for this SAN configuration can arise if multiple single-ported hosts need access to LUNs from both controllers, and two hubs are desired to improve performance by decreasing loop access contention. Note that this SAN is only partially fault-tolerant because the hubs and controllers have redundant hardware, but the hosts do not. The problem with this configuration can be overcome by using a single switch at the cost of replacing the two hubs with a switch. If loop access contention is not an issue, then the single hub configuration works as well. True LUN Sharing When considering the presentation of LUNs for active-active controllers, a good question might be, "Why not just present all LUNs on all ports?" The answer is that LUN sharing greatly increases complexity and sacrifices performance. In order to do LUN sharing between two controllers, the following must happen: 1 Some common data sharing method must be developed so that access to resources shared by both controllers can be administered. Because of this arbitration for resources, the performance of both controllers suffers as compared to two controllers that must only control their own resources. 2 Read cache on one controller must be invalidated if the data is modified by a write to the other controller. 3 Writes to disk must be controlled to ensure that simultaneous updates to the same region do not occur by both controllers. 4 RAID utility functionality (parity verification and expansion, for example) must be controlled to ensure that collisions between utilities and data accesses on the two controllers don't occur. B-11

  • 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
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210

B-11
SAN Solution Strategies (DuraStor 7320SS only)
SAN Configuration Not Supported
In the active-active dual-port configuration with two independent
hubs or the internal hubs, two single-ported hosts is
not
supported.
The issue with this configuration is that if a controller fails, each
host loses access to one of the LUNs.
For example, if Controller 1 fails, Host 1 can no longer access
LUN 2, because Port 2 on Controller 2 has changed from presenting
its own LUNs to presenting Controller 1’s LUNs. A need for this
SAN configuration can arise if multiple single-ported hosts need
access to LUNs from both controllers, and two hubs are desired to
improve performance by decreasing loop access contention.
Note that this SAN is only partially fault-tolerant because the hubs
and controllers have redundant hardware, but the hosts do not.
The problem with this configuration can be overcome by using a
single switch at the cost of replacing the two hubs with a switch. If
loop access contention is not an issue, then the single hub
configuration works as well.
True LUN Sharing
When considering the presentation of LUNs for active-active
controllers, a good question might be, “Why not just present all
LUNs on all ports?” The answer is that LUN sharing greatly
increases complexity and sacrifices performance. In order to do
LUN sharing between two controllers, the following must happen:
1
Some common data sharing method must be developed so that
access to resources shared by both controllers can be
administered. Because of this arbitration for resources, the
performance of both controllers suffers as compared to two
controllers that must only control their own resources.
2
Read cache on one controller must be invalidated if the data is
modified by a write to the other controller.
3
Writes to disk must be controlled to ensure that simultaneous
updates to the same region do not occur by both controllers.
4
RAID utility functionality (parity verification and expansion,
for example) must be controlled to ensure that collisions
between utilities and data accesses on the two controllers don’t
occur.