I want to make sure we’re understanding this 100%. Does the browser hit the ICM 1st then redirect to best server? I was reading some help docs that made it sound like the web server was hit then redirects URL to ICM. That seems like too many steps… guess it would technically hit the web server if ICM is running on 1 of the clustered servers. Does the URL change if redirecting to server 1 or 2? e.g. server 1’s FQDN in server doc is abc.test.com and server 2’s is 123.test.com. If the incoming URL is test.com/test.nsf and ICM determines that server 1 is the best option, does the URL get changed to abc.test.com/test.nsf? If so, it seems that you would need 2 SSL certs (one for 123.test.com and the other for abc.test.com). Was wondering if there is a way to use ICM -w- 2 servers but keep the same URL (test.com) and use common SSL. Guess this would be a challenge since test.com has to resolve to some IP! Sounds like 2 SSL certs are required… any thoughts? Sounds like using 2 ICMs outside (e.g. on a couple free blades) might be more beneficial… seems like ICM + standard clustering could be an overload.
Subject: ICM & FQDN (URL Changes & SSL)
I’ve only used ip sprayers in front of http servers… but from what I’ve read about it - the initial http connection goes to the ICM, and then it’s redirected to one of the actual cluster members – so there would be different dns names in the picture, and thus different ssl certs.
Depending on your licensing agreement with your SSL vendor - you may need licenses for each server anyway. For example, I have 4 domino http servers behind a load balancer hosting the same dns name - all using the same ssl keyring, but we still had to buy 4 licenses from Verisign.
Subject: RE: ICM & FQDN (URL Changes & SSL)
Thanks Erik… makes sense to me. I think the customer has created some “hard links” vs. relative paths in the web apps. We know this is not good practice but reality at some places. I’m assuming if the user accesses a hard link to test.com, it will just send the request to the ICM and it resolves based on FQDN. I guess it shouldn’t be an issue. In these cases, should the hostname in the server doc (internet tab) = the FQDN or can it still be test.com?