IBM Domino - The absolute definition of elegance in architecture and operation
Mat Newman May 9 2017 23:12:53
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.
Feeds