matnewman.com

IBM Domino - The absolute definition of elegance in architecture and operation

Mat Newman  May 9 2017 23:12:53
Figure 1: a Data Centre


Today I had the pleasure of discussing an upcoming move of data-centre and Domino upgrade with a customer. They have a population of around 8,000 users, hosted on two clustered IBM Domino servers, utilising iNotes and sitting behind a proxy and load balancer, with a single Traveler server hosting their growing mobile population.

They are moving the location of their data-centre to a new purpose built facility, upgrading Domino to the latest version and Feature Pack, deploying some of their additional entitlements for the first time, and implementing a Traveler "High Availability" configuration. Obviously Traveler in HA is an absolute necessity in this modern era of mobile.

Oh. And they are truly a 24/7 operation. There is to be no down-time during the move. Zero. Nothing. Nada.

And did I mention that one of the requirements is to move from an existing IBM operating system to Linux?

And did I also mention that we are in a situation where the old foe is offering to do an implementation, migration, co-existence and go-live in a 5 month time-frame? For "Free"?

... Any-hoo

Out came the whiteboard makers and it was time to reiterate one of the true benefits of IBM Domino: It's architecture.

Possibly one of the most brilliant features of Domino is that it's configuration has nothing to do with OS, no dependency on registry entries or other Operating System integration, and the actual data is completely separate from the application, meaning a Domino application server on the latest software version easily copes with data created several versions ago. Seamlessly. Add to that, a Domino servers configuration is almost entirely confined to an .ini file, and the configuration databases located within it's "Data" directory. Regardless of OS type or version. Regardless of File system. It's beautiful in it's simplicity and durability.

So the discussion and project plan about the cut-over to a new Data-Centre, OS, Software Version and new capabilities went something like this:

Preparation:
  • Register the new HA Traveler servers in the Domain,
  • Configure The new Proxy/Load-Balancer,
  • Implement a new IBM Protector Server,
  • Set up and configure the new Traveler servers in HA, working with the existing servers, behind the new Proxy/Balancer,
  • Test the new Traveler server configuration, and
  • Install and configure the OS and Software for the soon-to-be-new Domino Servers.

Implementation part #1:
  • Change the network configuration to point to the new Proxy/Balancer/Traveler HA,
  • Wait a day to make sure everything is working,
  • Shut down 'Server B",
  • Copy it's data from the old SAN,
  • Move it's data to the new Data Centre and point the new "Server B"'s configuration to that data location,
  • Change the network configuration so that DNS points to "Server B"'s new location
  • Bring up the NEW "Server B"
  • (Contingency plan: If anything goes wrong, just change DNS again and turn on old "Server B", fix problem, proceed to next step)

Of course, at this point, "Server B" comes on line, connects to "Server A" and cluster replicates any of the data that has changed since the original "Server B" was shut down.

Implementation part #2:
  • Again, Wait a day (we're a conservative bunch!)
  • Shut down 'Server A",
  • Copy it's data from the old SAN,
  • Move it's data to the new Data Centre and point the new "Server A"'s configuration to that data location,
  • Change the network configuration so that DNS points to "Server A"'s new location
  • Bring up the NEW "Server A",
  • Wait a day,
  • (Contingency plan: If anything goes wrong, just change DNS again and turn on old "Server A", fix problem, proceed to next step)
  • Switch the inbound MX to point to the new Protector server.

Post Move Enhancements:
  • Performance tuning Domino to take advantage of the latest features,
  • Implement IBM Sametime,
  • Implement IBM Connections Files and Profiles,
  • Implement IBM Docs,
  • Enable IBM Verse on Premises for the users

Drive adoption with IBM's #NewWayToWork

Project complete.

Shave 4 months off the competitors time-line. Provide ZERO down-time.

We're conservatively estimating the "preparation" phase to last 4 weeks, and the Implementation phase of moving the existing Domino servers to the NEW data centre at 6 days (double the actual time to implement, because we're being conservative and allowing a day in between for contingency at each step of the cut-over.

The thing that makes this transition so simple - so elegant - is the fact that Domino separates OS and Application and Data. Oh, and Replication. What an absolutely magical thing that is in a Domino world. Bring up the new "Server B", which has all the data that the old "Server B" had when it was shut down, and it just pulls the changes from between those two points in time from the old "Server A". And then the same thing happens when the new "Server A" comes up.

And then there's Domino Clustering. Oh Domino. You are a thing of beauty. Downtime ... Zero!

This. Stuff. Just. Works!

IBM Domino - The absolute definition of elegance in architecture and operation.




Comments

1Eoin Meaney  05/30/2017 12:30:54  
IBM Domino - The absolute definition of elegance in architecture and operation

Hi Matt,

being able to copy the data directory from one server to another or just even individual databases is something I have found handy for years but then I came across the following post on Stephan Wissel's blog:

https://www.wissel.net/blog/2011/10/moving-a-nsf-from-one-server-to-another.html

I was scratching my head wondering *why* this would be a bad thing and then saw the exchange of comments between Don Mottolo and Stephan.

Interesting to hear that this is something you do and that it all worked out nicely.

2Jared Roberts  06/28/2017 9:21:59  
IBM Domino - The absolute definition of elegance in architecture and operation

I've also used the straight OS copy many times. It works fine in general - however - the comments posted on Stephan's blog are correct... by copying you also bring across everything that the nsf contains (stubs, whitespace, corruptions etc.) and if the source nsf is damaged - then target is also damaged!

If you or your customer has the capacity and/or budget it is definitely preferable to stand up new Domino servers and replicate the data across - but sometime that also means performing user moves and all associated tasks (again quite easy thanks to Domino being great at it) but it realistically depends on scope/budget/time.

I've often performed nsf copies (using robocopy or similar) then once the Domino server is moved/upgraded THEN perform all maintenance - the first being ODS upgrade (compact -C)... then the view builds, new indexes, compression etc.

Many ways to do it... backout/rollback strategy is the key to protect and/or recover data to a known state... and you need to CLEARLY document the known state before starting ;-)

3Subhradeep Biswas  07/03/2017 23:33:54  
IBM Domino - add signature in Lotus webmail ?

Hi ,

Can we add signature in Lotus webmail ?

Can we add signature at Server level ?

So that it will reflect to all users with a single effort. at Server level ?

4Tony Holder  07/22/2017 10:08:38  
IBM Domino - The absolute definition of elegance in architecture and operation

For signatures you need Crossware MailSignature.

Mat Newman

THE Notes (formerly IBM/Lotus Notes) Guy. Productivity Guru. Evangelist. IBM Champion for IBM Collaboration Solutions, 2011/2012/2013. Former IBMer. HCLite. Views are my own.

#GetProductive #GetHCLNotes

Mat Newman




Home  | 

Get Serious. Get Domino.