Novell Cluster Services is a server clustering system that ensures high availability and manageability of critical network resources including data (file systems), applications, and services. It is a multinode clustering product for Linux that is LDAP enabled via Novell eDirectory and supports failover, failback, and migration (load balancing) of individually managed cluster resources.
Connection Magazine: Tech Talk #3 - Over and Over and Over and Over This is an excellent article about NCS. It covers some of the issues with running mixed NetWare/Linux NCS cluster.
Connection Magazine: Tech Talk #5 - Backup Backup A good overview of NCS. Has a section on clustering GroupWise.
Linux OES Product Documentation: OES Cluster Services 1.8 Administration Guide for Linux
NetWare OES Product Documentation: OES Cluster Services 1.8 Administration Guide for NetWare
NetWare OES Product Documentation: Novell Cluster Services 1.8 Resource Configuration Guide
NetWare 6.5 Product Documentation: Novell Cluster Services
NetWare 6 Product Documentation: Novell Cluster Services
NetWare 5.1 Product Documentation: Novell Cluster Services
Novell Documentation: GroupWise 6 Introduction to GroupWise 6 and Novell Cluster Services
Connection Magazine: Tech Talk #6 - Nuts About Clusters Article about GroupWise High Availability Service.
Cool Solution: Novell Cluster Services Primer for GroupWise Administrators
Novell Documentation: ZENworks 6.5 Introduction to Novell Cluster Services and ZENworks Server Management
Novell Documentation: ZENworks for Servers 3 Introduction to Novell Cluster Services and ZENworks for Servers
iSCSI and SLP
Use of iSCSI implies TCP/IP and dual-homed servers. If you properly architect your iSCSI network, you'll have it completely segregated and inaccessible by your client workstations. However, blocking port 524 traffic via ACL, or hiding the network via routing rules is not enough.
NetWare will still present all of its addresses via SLP by default, even if some of them are unreachable. This can cause lengthy delays in service location, drive mappings, etc. To avoid problems with name resolution and login performance, be sure to use the NCP EXCLUDE IP ADDRESS and SLP EXCLUDE IP ADDRESS parameters. Populate them with the IP addresses of the iSCSI network interfaces, to keep clients and other servers on your LAN/WAN from trying to communicate with them on the network you've designated for iSCSI traffic only.
External Link: Clustering iFolder
AppNote: Using DFS in a Clustered Environment
It is pretty straight forward to cluster NLDAP. Here is a quick summary of how it is done.
1) Setup cluster
2) Put an eDir replica on each node that will host the LDAP resource.
3) Create a LDAP resource which adds/dels the secondary IP address the clients will use to connect to.
4) Make sure NLDAP is loaded. You can either do this in the resource script or at startup. It is common to start NLDAP at server boot then also check that it is running in the resource script and starts it if it is not.
5) Optional - load/unload a health monitor in the resource scripts. The NCS sdk has a sample health monitor for LDAP. It can be found here. You can compile and use this directly or use this as a template and create one that uses SSL.
6) Create the certificates. (If you are using SSL/TLS)
6a) If you are generating your own certificates. Just create one for each server which has the same IP/DNS name as the cluster resource you created. eDir certificates are Key Material Objects (KMO). The default certificate that NLDAP uses a certificat that is for the DNS name of the physical server. Since the client doesn't know the physical server's name it won't accept a certificate from it as valid. So create a new KMO for each server which will host the LDAP resource. When you create it use the custom creation method. Then change the CN in the subject name to match what the client thinks it will be connecting to. Since certificates are tied to a server you will have to do this for each one. Then go to the LDAP Server object for each server and switch its Server Certificate to be the new one that you created. Then when you client request a cert it will get one with name that it is expecting in it. If your clients will be using an IP address to connect set the CN to the IP address. If it will be using a DNS name then put the DNS name as the CN. If you are using ConsoleOne you will have to escape the . (periods) but you don't have to in iManager.
6b) If you bought a certificate from a CA. Then to save some money you can just reuse it. To do this you will have to back it up then restore it on the other nodes.
Since the eDir PID files are in a fixed location on NetWare it isn't possible to cluster eDirectory. However this was changed for Linux. eDirectory can use PID files from anywhere. Therefore it should now be possible to cluster eDirectory on Linux. It should be like any other resource. Simply put the PID files on the shared storage and create a cluster resource that 1) binds an IP 2) mounts the shared volume 3) starts eDir using the PIDs off of the shared volume.