OK… what am I missing here? I have 2 clustered Domino servers each running ICM. The ICMs are configured with icm.test.com, but each ICM has a unique IP address. The web servers (also host the ICMs) are on separate IPs and have domain names of web1.test.com and web2.test.com. I understand how the balancing/redirect would happen for web1 and web2 (that is handled by ICM) but am confused about how the balancing happens to the 2 ICMs. Same host/domain name but 2 IPs… is another load balancer required that sends the user’s HTTP request to the appropriate ICM? …please don’t tell me that DNS round robin is the option. Ugghhh… howe about a layer 4 switch? …if that is available (not sure - will ask network admin). Let’s assume the answer is no… small shop here and layer-4 is usually too many $$$. Ideas?
Subject: 2 ICMs, 2 IPs, 1 Domain…& DNS Round Robin (YUK!)
First, why do you have two ICM in a two server cluster? For your application, one ICM is fine. Actually I would set up a third server, just for the ICM and leave the two other servers to handle the application load. Since you have the ICM running on both of your server now, how would they determine, where to send http requests?
We are running a six servers cluster, the six servers is the ICM (7.0.2) just upgraded the app and the server version, and it is working great. DNS Round robbing is not your solution, if you have a high traffic site/app get yourself a CISCO IP Spr,. Or as I said before set up a third server to be the ICM by it self…
Subject: RE: 2 ICMs, 2 IPs, 1 Domain…& DNS Round Robin (YUK!)
Thanks for the feedback… the management team did not want a single point of failure. If you have 1 ICM and it fails, your web cluster is no longer accessible. Am I missing something? Based on discussions with various IBM folks, it seems performance can be better (if system resources are plentiful) when the ICMs reside within the cluster because it uses local CLDBDIR. We would need to use a sprayer or maybe layer-4 balancing at the router to distribute the load between the ICMs (same domain name… e.g. icm.test.com) and direct traffic to the alternate ICM should another fail. That said… if you don’t have 2 of everything (example) like 2 Domino servers -w- 2 ICMs, 2 sprayers or redundant routers, etc… what is the point? I have no doubt that a single ICM would handle the load. It just seems dangerous to have just 1 ICM… what is the point of having the Domino availability across “x” # of servers when it is all managed by 1 ICM?
Subject: Confusion… FQDN and Host in Internet section (& ICM)
OK… this could be the root of my confusion. Hoping someone can straighten me out…
We could be getting confused about the differences between the FQDN and the hostname on the internet protocol tab (HTTP section) and how it works with ICM. When ICM receives a request for abc.com, does it resolve to the FQDN or use what is in the HTTP section? In our case, the Domino servers are being accessed vie another internal website (Websphere)… user clicks button to logon to partner site (the Domino servers). My assumption is this login should be directed to the ICM and the ICM determines which server is best. Let’s assume that the servers are configured as follows:
server1:
FQDN is dom1.test.com
Internet Hostname (in HTTP section) is test.com
server2:
FQDN is dom2.test.com
Internet Hostname (in HTTP section) is test.com
If ICM redirects to server2, does it grab the FQDN (dom2.test.com) or thet one in HTTP section (test.com)? I’m assuming this shows in the browser and would thus require an SSL certificate for dom2.test.com. Is this right? Is there anyone to use ICM (e.g. icm.test.com) that redirects to servers using the test.com common across all servers? If so, how does it know to access the servers without the FQDN? …sounds like I’m answering my own question. 
Sounds like the browser would initially be directed to the ICM (icm.test.com) and the URL would change to either dom1.test.com or dom2.test.com. Can someone confirm this is correct? If so, we will need an additional SSL cert for dom2.test.com.
Thanks team!