Dell EqualLogic PS6210XS EqualLogic Group Manager Administrator s Guide PS Ser - Page 286

About Single-Step Failback to Primary, Directory AD / Lightweight Directory Access Protocol LDAP

Page 286 highlights

The configuration of your environment determines how you change the configuration. For example, if the source cluster uses Active Directory (AD) / Lightweight Directory Access Protocol (LDAP), the destination cluster must use the same AD/LDAP. This setup ensures all user information is retained in the new configuration. • Change the Domain Name System (DNS) server to point to the destination cluster instead of the source cluster. You should make the change on the DNS server used to resolve NAS cluster virtual IPs (VIPs), if any. • If the NAS cluster has not already been joined to AD or LDAP/NIS, connect them now. During the cluster activation period, client connections might fail and need to be reestablished. However, the change should be transparent to the client as long as they continue to use the same fully qualified domain name (FQDN) to reach the Server Message Block (SMB) share or Network File System (NFS) export. NOTE: Restoring volume configuration on the destination cluster is not supported between major revisions (such as version 2 > version 3). About Single-Step Failback to Primary You can use the single-step failback to primary process as part of the disaster-recovery process. To prepare for disaster recovery, a primary (source) container is configured to replicate data to a replica container. Clients have readwrite access only to the source container. When the source container becomes unavailable, you can perform a failover by temporarily promoting the replica container, defining a new replication partnership between the source container and the recovery container, and giving clients read-write permissions to the recovery container. The last version of data replicated to the replica container (now the recovery container) is written to the source container. When the source container is available again after the failover, you perform a failback, which writes to the source container any additional changes made by the clients on the recovery container while the failover was in place, and demotes the recovery container to a replica container. The replication partnership is redefined between the source container and the replica container, and clients are given read-write permissions to the source container again. For example: Container A is a source container with which clients interact directly. Container A has a replication partnership with container B, a replica container. If container A must be taken offline for maintenance, container B is temporarily promoted to a recovery container, a new replication partnership is defined between container A and container B, and clients interact directly only with container B. When container A is available after maintenance, all of the latest updates from clients are replicated from container B to container A, then container B is demoted to a replica container and clients resume interacting directly only with container A. If the source container is no longer available, establish a replication relationship between the replica container and a new source container, manually perform replication from the replica container to the new source container, then demote the recovery container to a replica container. The single-step failback process performs the replication and failback operations with minimal user interaction. When you perform a single-step failback operation (after failing over) without performing a manual replication, the following actions occur: 1. Data is replicated from the recovery container to the source container. 2. The recovery container is demoted to a replica container. 3. A replication partnership is redefined between the source container and the demoted replica container, and the source container resumes replicating to the replica container. CAUTION: To ensure that no data is lost, verify that clients cannot write to the recovery container during the singlestep failback process. Perform Single-Step Failback to Primary Single-step failback to primary performs data replication and failback with minimal user interaction. Before you can perform this task: • You must be logged in as group administrator on the group that contains the recovery container. • You must know the Group Manager account user name and password for the group that contains the source container. • You must have temporarily promoted the replica container to a recovery container. 286 About Data Recovery

  • 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
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • 246
  • 247
  • 248
  • 249
  • 250
  • 251
  • 252
  • 253
  • 254
  • 255
  • 256
  • 257
  • 258
  • 259
  • 260
  • 261
  • 262
  • 263
  • 264
  • 265
  • 266
  • 267
  • 268
  • 269
  • 270
  • 271
  • 272
  • 273
  • 274
  • 275
  • 276
  • 277
  • 278
  • 279
  • 280
  • 281
  • 282
  • 283
  • 284
  • 285
  • 286
  • 287
  • 288
  • 289
  • 290
  • 291
  • 292
  • 293
  • 294
  • 295
  • 296
  • 297
  • 298
  • 299
  • 300
  • 301
  • 302
  • 303
  • 304
  • 305
  • 306
  • 307
  • 308
  • 309
  • 310
  • 311
  • 312
  • 313
  • 314
  • 315
  • 316
  • 317
  • 318
  • 319
  • 320
  • 321
  • 322
  • 323
  • 324
  • 325
  • 326
  • 327
  • 328
  • 329
  • 330
  • 331
  • 332
  • 333
  • 334
  • 335
  • 336
  • 337
  • 338
  • 339
  • 340
  • 341
  • 342
  • 343
  • 344
  • 345
  • 346
  • 347
  • 348
  • 349
  • 350
  • 351
  • 352
  • 353
  • 354
  • 355

The
configuration
of your environment determines how you change the
configuration.
For example, if the source cluster uses Active
Directory (AD) / Lightweight Directory Access Protocol (LDAP), the destination cluster must use the same AD/LDAP. This setup
ensures all user information is retained in the new
configuration.
Change the Domain Name System (DNS) server to point to the destination cluster instead of the source cluster. You should
make the change on the DNS server used to resolve NAS cluster virtual IPs (VIPs), if any.
If the NAS cluster has not already been joined to AD or LDAP/NIS, connect them now.
During the cluster activation period, client connections might fail and need to be reestablished. However, the change should be
transparent to the client as long as they continue to use the same fully
qualified
domain name (FQDN) to reach the Server Message
Block (SMB) share or Network File System (NFS) export.
NOTE: Restoring volume
configuration
on the destination cluster is not supported between major revisions (such as
version 2 > version 3).
About Single-Step Failback to Primary
You can use the single-step failback to primary process as part of the disaster-recovery process.
To prepare for disaster recovery, a primary (source) container is
configured
to replicate data to a replica container. Clients have read-
write access only to the source container. When the source container becomes unavailable, you can perform a
failover
by temporarily
promoting the replica container,
defining
a new replication partnership between the source container and the recovery container, and
giving clients read-write permissions to the recovery container.
The last version of data replicated to the replica container (now the recovery container) is written to the source container. When the
source container is available again after the failover, you perform a
failback
, which writes to the source container any additional
changes made by the clients on the recovery container while the failover was in place, and demotes the recovery container to a
replica container. The replication partnership is
redefined
between the source container and the replica container, and clients are
given read-write permissions to the source container again.
For example: Container A is a source container with which clients interact directly. Container A has a replication partnership with
container B, a replica container. If container A must be taken
offline
for maintenance, container B is temporarily promoted to a
recovery container, a new replication partnership is
defined
between container A and container B, and clients interact directly only
with container B. When container A is available after maintenance, all of the latest updates from clients are replicated from container
B to container A, then container B is demoted to a replica container and clients resume interacting directly only with container A.
If the source container is no longer available, establish a replication relationship between the replica container and a new source
container, manually perform replication from the replica container to the new source container, then demote the recovery container
to a replica container.
The single-step failback process performs the replication and failback operations with minimal user interaction. When you perform a
single-step failback operation (after failing over) without performing a manual replication, the following actions occur:
1.
Data is replicated from the recovery container to the source container.
2.
The recovery container is demoted to a replica container.
3.
A replication partnership is
redefined
between the source container and the demoted replica container, and the source
container resumes replicating to the replica container.
CAUTION: To ensure that no data is lost, verify that clients cannot write to the recovery container during the single-
step failback process.
Perform Single-Step Failback to Primary
Single-step failback to primary performs data replication and failback with minimal user interaction.
Before you can perform this task:
You must be logged in as group administrator on the group that contains the recovery container.
You must know the Group Manager account user name and password for the group that contains the source container.
You must have temporarily promoted the replica container to a recovery container.
286
About Data Recovery