32
BCC 1.2.1: Administration Guide for OES 2 SP2 Linux
no
vd
ocx
(e
n)
7 Ja
nua
ry 201
0
Use a minimum of two mirror connections between storage environments over different fabrics
and wide area networks.
Make sure the distance between storage subsystems is within the limitations of the fabric used
given the amount of data, how the data is mirrored, and how long applications can wait for
acknowledgement. Also make sure to consider support for asynchronous versus synchronous
connections.
3.5 Storage Design Guidelines
Use the guidelines in this section to design the shared storage solution for each of the peer clusters in
the business continuity cluster.
Use a LUN device as the failover unit for each BCC-enabled cluster resource. Multiple pools
per LUN are possible, but are not recommended. A LUN cannot be concurrently accessed by
servers belonging to different clusters. This means that all resources on a given LUN can be
active in a given cluster at any given time. For maximum flexibility, we recommend that you
create only one cluster resource per LUN.
We recommend that you use only one LUN per pool, and only one volume per pool. If you use
multiple LUNs for a given shared NSS pool, all LUNs must fail over together.
Data must be mirrored between data centers by using host-based mirroring or storage-based
mirroring. Storage-based mirroring is recommended.
When using host-based mirroring, make sure that the mirrored partitions are accessible for the
nodes of only one of the BCC peer clusters at any given time. If you use multiple LUNs for a
given pool, each segment must be mirrored individually. In large environments, it might be
difficult to determine the mirror state of all mirrored partitions at one time. You must also make
sure that all segments of the resource fail over together.
3.6 eDirectory Design Guidelines
Your Novell eDirectory solution for each of the peer clusters in the business continuity cluster must
consider the following configuration elements. Make sure your approach is consistent across all peer
clusters.
Section 3.6.1, “Object Location,” on page 32
Section 3.6.2, “Cluster Context,” on page 33
Section 3.6.3, “Partitioning and Replication,” on page 33
Section 3.6.4, “Objects Created by the BCC Drivers for Identity Manager,” on page 33
Section 3.6.5, “Landing Zone,” on page 33
Section 3.6.6, “Naming Conventions for BCC-Enabled Resources,” on page 34
3.6.1 Object Location
Cluster nodes and Cluster objects can exist anywhere in the eDirectory tree. The virtual server
object, cluster pool object, and cluster volume object are automatically created in the eDirectory
context of the server where the cluster resource is created and cluster-enabled. You should create
cluster resources on the master node of the cluster.
Содержание BUSINESS CONTINUITY CLUSTERING 1.2.1 - ADMINISTRATION
Страница 4: ...4 BCC 1 2 1 Administration Guide for OES 2 SP2 Linux novdocx en 7 January 2010...
Страница 36: ...36 BCC 1 2 1 Administration Guide for OES 2 SP2 Linux novdocx en 7 January 2010...
Страница 56: ...56 BCC 1 2 1 Administration Guide for OES 2 SP2 Linux novdocx en 7 January 2010...
Страница 64: ...64 BCC 1 2 1 Administration Guide for OES 2 SP2 Linux novdocx en 7 January 2010...
Страница 70: ...70 BCC 1 2 1 Administration Guide for OES 2 SP2 Linux novdocx en 7 January 2010...
Страница 132: ...132 BCC 1 2 1 Administration Guide for OES 2 SP2 Linux novdocx en 7 January 2010...
Страница 146: ...146 BCC 1 2 1 Administration Guide for OES 2 SP2 Linux novdocx en 7 January 2010...
Страница 152: ...152 BCC 1 2 1 Administration Guide for OES 2 SP2 Linux novdocx en 7 January 2010...
Страница 166: ...166 BCC 1 2 1 Administration Guide for OES 2 SP2 Linux novdocx en 7 January 2010...
Страница 174: ...174 BCC 1 2 1 Administration Guide for OES 2 SP2 Linux novdocx en 7 January 2010...
Страница 176: ...176 BCC 1 2 1 Administration Guide for OES 2 SP2 Linux novdocx en 7 January 2010...
Страница 184: ...184 BCC 1 2 1 Administration Guide for OES 2 SP2 Linux novdocx en 7 January 2010...