Taking on the challenge of High Availability (HA), whether on-premise or in the cloud can be a complex process where excellent planning and patience come forefront in avoiding common errors for SAP (Systems Applications and Products). As SAP software can boost our organisation’s efficiency and productivity by automating repetitive tasks and managing financials, it’s essential to avoid some common errors when we bring a HA solution into the frame. Let’s have a look at some of these mistakes and see how we can avoid them:

 

Complexity and cost

Clustering can be complex and can sometimes lower availability, as in some cases they are not needed. They are assumed they are needed when in reality, they can cost more than the downtime they prevent.

Be sure that the HA solution costs less than the downtime it limits, otherwise, money is being wasted. This would mean planning business costs effectively. For example, what is the cost on average of planned/unplanned downtime needed to maintain the system?

Take a close look at the hardware currently at your disposal. Perhaps your server is of good quality with many redundant components linked to redundant storage and network infrastructure – which could be all you need for what you want to achieve. A cluster could add unnecessarily to your bill.

For example, although Hyper-V Failover Clustering can give you one single solution for your entire organisation, its big weakness is that you need some planned downtime to maintain the OS. This planned downtime could potentially lead to possible OS faults and then eventually unplanned downtime.

 

Failure to test the Failover

A Failover test is essential. If this is not done, then any risks associated with the failure of an application or system go unnoticed and Failover measures cannot be taken. This would at least involve a complete understanding of the different types of tools that can support reliability testing and a simulation of failure conditions, which leads nicely to the next point…

 

Lack of knowledge

New technology means adopting new skills among our staff members. If there is a lack of understanding or confidence with how HA technology works, then the team won’t be able to deal with any emergencies.

Ensuring that everyone is swinging from the same branch when it comes to using it is essential. Assume that all are beginners to HA. Yes, there are those that have the experience, but every situation is unique and can pose different problems.

So, it’s a good idea to get all employees up to speed on when it comes to the processes that need to be followed during downtime, particularly before going live.

 

Retaining HA just for production

One serious mistake is when organisations have HA within a production environment only. But, in fact, it costs more in the end. Why is that?

Quality assurance environments should match the production environment exactly, otherwise, complications may arise. It would be difficult, if not impossible to plan production downtime in a realistic environment, resulting in maintenance windows overrunning. In addition to being unable to test the patching of databases’ effect on a cluster, you wouldn’t be able to test major SAP upgrades without testing it on the cluster first.

Finally, cluster technology needs cluster training. When there is no environment for this to take place, new engineers will lack the confidence needed in operating the HA environment.

Note: All images courtesy of pexels.com and dataversity.net

 

 

 

Categories:

No responses yet

    Leave a Reply

    Your email address will not be published. Required fields are marked *