Update: Understanding eDirectory and Clustering
Novell Cool Solutions: Tip
Digg This -
Updated: 27 Apr 2005
Comments by Geoffrey:
"NLDAP is clusterable, but you should also have replicas of eDirectory for the parts of the tree you want to search, on each cluster node where it could fail over. NLDAP can search on its local replica, but always at a performance penalty.
Also, the article suggests you can fail the IP address over, and just have each server run NLDAP. But the SSL Certificate used for secure LDAP will be different. So connections will not migrate and reconnect (unless the application or tool using LDAP is designed to do it)."
A reader recently asked for some insights on including replica servers in a cluster:
"We are planning on setting up a cluster this summer. Here is our environment: we have Netware 6.5 with four servers holding replicas. We also have campus servers, where each site has its own server for file storage and printing. Should we leave the replica servers "as is" or should we put the replicas in the cluster?"
And here are the responses from several of our Forum experts:
The important thing to understand about clustering is that in order for cluster failover to work efficiently, the nodes are intentionally less stable than the cluster as a whole. This is an important concept to understand when looking at cluster implementations, and how you design eDirectory around this.
Let me explain. NetWare includes functionality that allows it to suspend a running NLM that's crashed, without taking the server down. In a non-clustered environment, this is a good thing, because the server stays up and can continue to service requests for the non-failed services.
In a cluster environment, the node needs to go down hard. Otherwise, the cluster heartbeat doesn't drop, and the services don't fail over.
eDirectory, by its very nature, is not a cluster-enabled service. It provides fault tolerance through replication. (NLDAP, on the other hand, is a clusterable service, but you must fail the IP addresses over).
Cluster Container Object
There is a cluster container object that is used for the purposes of managing the cluster itself. This object needs to be available for every node in the cluster in order for certain things to work properly. Among other things, the membership of nodes in the cluster is tracked using something called a "panning ID," which is stored in this cluster container object.
As I understand it, the best practice is to replicate the cluster container (as a partition root) to each node in the cluster, or at least to a number of nodes in the cluster. Other partitions would be replicated as per usual, ensuring there is sufficient replication from the standpoint of the directory to provide connectivity/authentication should any particular node in the cluster go down.
In other words, apart from the cluster container object's requirements, eDirectory replication itself doesn't really need to be treated any differently in a clustered vs. non-clustered environment, because the service itself is inherently not cluster-aware.
1. You can treat cluster servers just like any other server as far as replica placement goes. However, make sure you have enough replicas to take in to consideration that an individual cluster server might go down more frequently than a non-clustered server.
2. When we upgraded from a group of 5.1 servers to a 6.x cluster, we just spread the replicas out across the cluster servers and it has all been working fine. Also, for more help setting up your cluster, be sure to check the cluster-services Novell Support Forum.
3. The cluster container itself has to be treated somewhat specially, but not because of eDirectory requirements - it's needed for the cluster's own operation.
4. There is a way to "cluster" clusters for multi-site redundancy. It's not cheap to do (you need to have multiple SANs), and because of the complexity, it may require a consulting services engagement from Novell.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com