Anthony Holmes 4 August 2009 11:29:16 PMAs well as Web Site documents, you can create IIOP Site documents. Just like Web Site documents they let you put in multiple Domino server names.
One of my customers thought that this implied that you can therefore create automatic failover for Domino IIOP. I did a bit of reading (and thinking) on this question, and have come to the conclusion that you need stuff outside Domino if you want Domino IIOP requests to have automatic failover.
This may be a slightly arcane topic, but if anybody has any suggestions/comments/corrections/things I've missed, please feel free to let me know. I'm coming at this from an administrator's perspective, so programmers might think I'm talking nonsense: or they might helpfully point out things I've gotten wrong. :-)
What is DIIOP?
DIIOP stands for Domino Internet Inter-Orb Protocol. It allows applications written in other languages/systems to communicate with Domino. (One of Domino's many open standards based interfaces.)
As the name suggests, it's a protocol. As such it can be compared with other protocols:
* HTTP (port 80)
* SMTP (port 25)
* NRPC (port 1352)
(DIIOP is usually - but not always - operating with port 63148.)
DIIOP is CORBA (Common Object Request Broker Architecture) over IIOP for Lotus Domino.
The Common Object Requesting Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG) that enables software components written in multiple computer languages and running on multiple computers to work together.
IIOP (Internet Inter-Orb Protocol) is the implementation of inter-orb protocols for TCP/IP. When CORBA was first developed there was no standard way for different CORBA software systems to talk across the network. IIOP is the standard developed to allow this communication.
So, DIIOP is the Domino related implementation of CORBA using IIOP for transport.
For the purposes of this discussion, I assume that there is a remote application making DIIOP calls to a Domino server. (It's also possible to use DIIOP with local sessions, but in that scenario, clustering/failover wouldn't be relevant.)
Why is it important to understand these components?
The reason why I've 'picked apart' the components of DIIOP is because it makes it clear where the 'network layer' is implemented: In IIOP.
What does this mean from a clustering perspective?
Domino is the end point in this communication.
If a program makes a CORBA syntax request using IIOP as the network layer, then that request arrives at Domino which translates it into language that the Domino server can interpret and respond to (by way of the DIIOP task running on the Domino server).
If the DIIOP task fails, or the Domino server fails (or even if the Domino Server's Operating System fails, or the Network Interface fails) then this too late in the chain. There's no way that Domino can notify a remote client. (If DIIOP failed, then it couldn't communicate a message to fail over somewhere else. If Domino failed, then DIIOP couldn't run. If the OS failed... you get the picture: these are the wrong places for failover to be implemented.)
Cluster Options: Client failover or Load Balancer
There are two places where failover could - in theory - be provided: at the client or via a load balancer.
I'll look at them in turn.
Notes and Domino provide clustering and failover, so it should be easy to provide the same capability for DIIOP, right? Almost, but not really.
Domino clustering keeps the data synchronised between two or more servers. DIIOP can take advantage of this: data will be up to date within a very short time on multiple servers.
The problem is that requests for that data come from a client: your Notes client. With DIIOP the request comes from your application.
With Notes clustering (using NRPC/1352) the Notes client has the intelligence to perform cluster failover. The Notes client has knowledge of which Domino servers are cluster mates and, if a primary cluster is unavailable, then cluster mates will be interrogated in turn. This information is stored in your desktop/location.)
With DIIOP the full Notes client isn't being used. (Note: When DIIOP is called it makes use of the notes.jar in the classpath. The Notes.jar is contained in a Domino server installation or a Notes client installation. However, the use of Notes.jar doesn't provide access to the full client cluster failover capabilities: these are only available when Notes with NRPC is being used.) As a result, even though the Notes client provides a cluster capability, it's not available to you when you are making DIIOP calls.
I imagine that it would be possible to build failover intelligence into an application:
If server1 fails to respond, then query server2.
(I don't know how easy it would be to do this programming. I suspect that even if my line of pseudocode could be written in a simple an reliable fashion, it might be necessary for it to be inserted into many, many places in an application. So I doubt that this would be an easy solution.)
With most non-Domino applications, continuous availability is provided via a Network Load Balancer.
An example of this is shown here:
In relation to the diagram, you'd place another HTTP server in front of your two Domino servers and run Load Balancer plug-in on that front end server. That would then pass requests through to your clustered Domino servers (which are shown by Application server Instance#1 and Application Server Instance #2). The High Availability Database and the RDBMS would, in this example, be represented by clustered Domino applications (so they'd be duplicated rather than the single instances shown on the diagram.)
Within the Domino Directory I assume that you'd set up an IIOP Site document that mentions the servers running the DIIOP task.
IIOP and HTTP
I understand that there are two ways to submit an IIOP call: either natively or via an HTTP request. In the first example, an application could be using DIIOP to work with a Domino server that runs the DIIOP task but doesn't run HTTP. In the second example your application submits the request via HTTP addressed to a hostname. I suspect it would be much simpler to configure a Network Load Balancer to fail over DIIOP requests that are being forward via HTTP.
Alternative Approach: Proactive monitoring of DIIOP
Standard Domino server probes can be configured to monitor the availability of the DIIOP task on a Domino server.
To do this you'd set up Task Status Event Generator and notification for the DIIOP Server task (to monitor when it was down or not responding)
Because of the architecture of DIIOP, it isn't possible for a Domino server to provide continuous failover for DIIOP on its own. Redundancy needs to either be built into the application or provided at the Network layer. Domino clustering will let you make multiple destination servers available to receive requests if you use either application failover or (probably preferably) use Network Load Balancing.
- Comments