One of the questions we get all of the time when talking with customers about running their SAP HANA in the Cloud is: “What do I do when I need to upgrade, and how much downtime should I expect?”
This is a great question because it really gives us the opportunity to talk about one of the biggest benefits of IBM Cloud as opposed to another providers’ on-premises or hosted solution—and that benefit is seemingly infinite capacity.
In the dark old days, when you wanted to upgrade the hardware that ran your ERP, you were committing to a serious planned outage because there was just no way to keep your ERP running when you added or changed RAM, added more internal storage, or upgraded your processor.
Nowadays, in the new world of cloud, that’s simply not the case. Since IBM Cloud owns and operates the hardware, all that’s involved in growing out your ecosystem is the following five actions:
Failover and cancel
And no, I didn’t forget to add “downtime” to the list. Because it’s a non-issue.
Migrating SAP HANA environments instead of upgrading
What do I mean by that?
Imagine this scenario: A fairly standard ERP cluster running your HANA landscape, two production 2TB RAM servers with HANA System Replication running as a highly-available pair, with a third disaster recovery 2TB RAM server running in an isolated environment.
Figure 1: Production servers and a disaster recovery server running in an isolated environment
Steps for migrating SAP HANA Environments
You now want to know if your landscape upgrade will be stable, right? And that it’ll have the same uptime, resiliency, and performance as your old landscape, right? Of course, naturally.
You start with the DR server. That way you’ll have an isolated environment to test your new production system and you’ll still have your production HA paired up and running to keep your business paired up and running.
You order and configure the new DR server. In this case, we’re moving from a 2TB server configuration to a 4TB server configuration.
You sync the old DR server with the new one. Once that sync is up and running via HSR (or your synchronization solution of choice), you…
Failover to the new DR server as your primary. Once you’re happy with your new server’s stability you cancel the old DR server.
Then you just repeat these steps, one at a time, with both of the servers running in your production HA pair.