I have been asked to implement a backup scenario for our company and I wanted to run a scenario by anyone who is kind enough to help.
We have serverA (production) and serverB (a replica of serverB). The servers are to be deployed across the country so we did not want to cluster them as the traffic is high. Both servers are to be SSL-enabled. This is for web traffic only.
My question is this:
Since we manage our own DNS, if I simply have the url for ServerA point to serverB (which has its own server ID, ssl cert,etc), will the change be seemless to the user? Will the URL show up as ServerA but in reality the user is connected to ServerB.
Thank you so much for the response. I’m still waiting back from a respone from our network admin but wouldn’t the dns be ok since we host it here? It is servera.company.com and serverb.company.com. I’m more curious about if domino would complain since the IP address in the address book entry would no longer match the network IP.
Well, you might be running your own DNS, but what about people accessing it from around the country? Are they all just intranet users, all using the same DNS?
Where in your Domino Directory do you use a fixed IP address (and for what reason)?
Thanks for your response! Our management is ok with a temporary DNS outage - this is just meant to be a stop-gap measure until we implement a full DR solution next year. Right now we have the network name of the server in the address book entry and I expect we’d have to change this if we went to the B server.
On your first comment regarding whether or not to cluster the “B” server, I think there may be reasons to revisit that decision, here are some thinking points:- Notes clustering is based on it’s robust replication technology and works just as well over a WAN as scheduled replication.
Clustering doesn’t in itself cause more replication traffic than scheduled replication, and in some situations could use less.
Cluster traffic will break up the traffic over the whole day whereas scheduled replication will queue up activity, so you may see less network contention using clustering.
If your network group can use QOS or some sort of provisioning to dedicate some of your WAN to port 1352 traffic, I’d suggest using cluster replication. You’ll be getting mail routing failover and client failover as well as keeping your backup server closer to the current dataset of your primary.
If there’s no QOS and you’re looking to do something like a once per night replication then of course you’re better off with scheduled replication linking the server, just keep mail routing in mind for your failover scenario.
In either case, make sure to enable port compression for both servers in order to realize the best throughput available.
In terms of the web server setup, yes you can set up the B server to accept the traffic for the URL, just remember to set up the site document for the B server to match the setup you have for A.
For the DNS change, set the TTL for your domain record to be as short as your network group will let you get away with. If your DNS record has a long TTL, then your users will be hitting a cached value for the URL when you’re trying to move them over to the new site and won’t get to the new site
You’ll also want to have support documentation ready on how to flush the DNS cache on a client PC. A good idea is to keep a separate URL in place for the secondary server for troubleshooting, if a user can’t get to servera.domain.com after your dns change, you’ll still be able to have them use serverb.domain.com rather than spend too much time on troubleshooting DNS.
Thank you sooooo much for your response! I did admin work for 3 years but haven’t done much with this kind of stuff. We absolutely have plans to set up clustering in the near future but management just wants a semi-hot backup set up for the time being. I had planned on getting caught up with this at Lotusphere next month.
We are currently not using site documents. Am I correct to assume that I’d need to set up a site doc for my current url of “serverA.company.com” and tell it that both servers host it? We still want all users to hit ServerA unless an emergency happens and we need to shift to serverB. An outage is acceptable to management at this point.
We have an ssl cert for serverA. Wouldn’t that same cert have to exist on ServerB if we’re going to do this and keep the same URL? I guess that kind ties in to #1.
In your experience, does clustering have a major drag on the server?
If your organization is going to view this setup as part of a DR or BC plan, I’d suggest trying to move your managers gently, but firmly, to a written definition of what they’re expecting to happen, with acceptable time frames. For example, if you decide not to go with clustering then new mail won’t be delivered to the backup replicas of mailboxes during a failover. Make sure you get in writing that that is understood and acceptable.
You don’t have to use site documents for what you’re discussing, but I’d recommend moving to them eventually since you gain a lot of new options which aren’t available with the basic HTTP settings.
For what you are describing, you should go ahead and use your ServerA SSL cert on ServerB. This isn’t specifically tied to the decision to use HTTP settings vs sites as (last that I knew) you could still only use one SSL cert per Domino server, but it will avoid your users having to deal with aa possible SSL mismatch security prompt when accessing ServerB at the ServerA URL.
Clustering has very real overhead, whether or not it makes your server “drag” or not depends on your existing performance situation. If performance is a limiting factor but you still want to take advantage of mail routing and Notes client failover, consider putting your servers in a cluster and then disabling clustering at the database level via the Cluster Directory (cldbdir.nsf).
Thanks again! Our server services only web traffic so much of the mail and client stuff won’t apply.
So in the very short term DR plan, it seems that the easiest way to move to the B server would be to have a spare notes.ini and serverID file on b that would make it easy to bring it up as A? Or would it really matter if we just changed the DNS to point to B and left B up and running as itself? Would web traffic notice the difference?
Sounds like I was overcomplicating things. Unless any of your applications are set up as mail-in DBs you won’t need to worry about mail.
You can set up ServerB and use scheduled replication to keep your applications in synch. Use the SSL cert currently in use on ServerA on ServerB as well, and when you need to just change over your DNS record.
Web users won’t know the difference, just make sure to check in with your application developers to make sure nothing has been hardcoded for ServerA.