|July 15, 2020||
SIOS Protection Suite for Linux Version 9.5 is Here!
We are proud to announce the availability of SIOS Protection Suite for Linux version 9.5. This product introduces advanced automation and application-aware monitoring making it the most comprehensive, out-of-the-box SAP S/4HANA clustering software in the industry.
We know what a hassle it is to try to manually build an SAP S/4HANA cluster, making sure that all of the HANA services will failover to the right locations and start up in the right order. Hours of scripting, testing, and aggravation. And the stakes are high. Getting it wrong can mean failover doesn’t happen or worse – downtime, data loss, lots of aggravated users calling.
That’s why we added intelligent application availability for two-node SAP S/4HANA database configurations that are using HANA System replication (HSR). We’ve built this release to take the hassle and risk out of building and managing a cluster.
SIOS Protection Suite v9.5 Automates and Monitors
Starting from easy, wizard-driven configuration that actually validates your input. No hours of manual scripting… or searching for a mistaken keystroke when things don’t go right.
It monitors all the processes in the HANA stack from the application to the hardware, servers, and network – not just checking that the server is operational like other clustering software.
And unlike other clustering solutions that trigger a failover for everything, if SIOS Protection Suite detects an issue, it automatically takes the appropriate recovery action – whether that’s simply restarting a service, recovering on the node that is in service or orchestrating a failover to a secondary node.
Speaking of failover orchestration, it will automatically ensure that SAP-specific best practices are maintained throughout. For example, it makes sure that on failover or switchover, ASCS is never on a server with the primary application or on the same server with the ERS.
If the wizard-driven configuration isn’t easy enough, we also added a new command-line interface (CLI) cloning feature that lets you deploy a SIOS cluster simply by importing the CLI instructions for configuration. You can also export the CLI instructions of an existing cluster to create a clone of it.
Now with SIOS Protection Suite for Linux, you can create a high availability cluster quickly and easily to protect any application. This includes SQL Server, Oracle, SAP and S/4HANA, from downtime and disasters.
Reproduced with permission from SIOS
|July 14, 2020||
EC2 Monitoring Best Practices: Using SIOS AppKeeper to Protect NGINX Webservers on Amazon EC2
|July 12, 2020||
What is Amazon CloudWatch?
What you can do with CloudWatch and some hurdles to consider
With AWS boasting a dominant share of the cloud market, many companies are migrating their on-premises systems to the cloud with Amazon AWS. So, how should a system running in the AWS environment be managed?
In this blog post, we will introduce the features of Amazon CloudWatch, a monitoring service provided by AWS, as well as the challenges of implementing it and how to solve them.
Using Amazon CloudWatch to closely monitor your AWS environment
To ensure that you have a stable cloud environment, it is important to detect anomalies (“system impairments”) quickly and respond in a timely manner. Monitoring becomes an important and necessary task for any organization moving to the cloud. This is no different than if you were managing on-premises applications and infrastructure. So, how should you monitor in an AWS environment? One choice is to use Amazon CloudWatch, which monitors CPU, memory, and disk usage and notifies you when a predetermined threshold is exceeded. Plus, you can set up your own metrics to monitor various items such as application logs.
The best part about Amazon CloudWatch is that it’s a service provided by AWS itself. It has a high affinity with Amazon EC2 and other AWS services, so it can quickly respond to frequent functional extensions and specification changes, and can easily support AWS Auto Scaling, which automatically increases or decreases resources according to the load. Amazon CloudWatch provides precise monitoring tailored to each environment’s unique circumstances.
Amazon CloudWatch implementation challenges
While Amazon CloudWatch is an ideal fit for organizations with experienced cloud engineers and DevOps teams, there are some things the average users should be aware of.
Amazon CloudWatch is effective for monitoring an organization’s AWS environment, but it requires a certain level of skill and knowledge to configure and deploy. Especially when you set your own metrics, are setting up alerts, or taking into account Auto Scaling, the complexity increases. For example, If you’re setting up monitoring, it’s easy, but if you’re setting up email, rebooting, AutoScaling, etc., depending on the resource situation, it can be difficult.
If you want to automate the recovery process with instructions such as “restart the server when an error occurs”, you must first create a recovery scenario with an AWS Lambda script that provides a detailed description of the conditions and actions to be taken. How familiar is your team with AWS Lambda?
The principal advantage of Amazon CloudWatch is that you can monitor your environment closely, but in order to do that, you must properly design in advance for each system what items to monitor and when, threshold values, etc. These design tasks can take a lot of time. Of course, your mission-critical systems need to be closely monitored in this way, but this level of detail and sophistication is not appropriate for all systems. For some, such as internal websites or WordPress servers, you will want to minimize your operating and labor costs. In such cases, we would like to suggest you consider a tool that can be more easily operated and managed.
SIOS AppKeeper for monitoring operating systems and application services running on AWS
For non-mission critical applications, we would like to recommend SIOS AppKeeper from SIOS Technology. AppKeeper is easy to install and configure and monitors the services (processes) of the application running on the EC2 instances. AppKeeper automatically restarts the service when an error is detected and reboots the instance if necessary. Even users moving to the cloud for the first time can set up AppKeeper to monitor their EC2 instances and recover automatically, without needing to have sophisticated scripting skills.
With AppKeeper, there is no need to select individual services to be monitored. You simply start by selecting the EC2 instances to be monitored and what actions you would like to be taken automatically. You can always get more specific about which services to monitor and how, but AppKeeper is designed to be easy to configure out of the box. When an error is detected or automatically restored from, a log of the failure is recorded and stored so that the cause of the failure can be investigated later.
Rather than using Amazon CloudWatch to closely monitor everything in your AWS environment, we recommend that you take inventory of your environment based on your SLAs and recovery requirements, and use SIOS AppKeeper to monitor systems and applications where you want to reduce your operational overhead.
Stay tuned for a future blog post where we will go into greater detail comparing how to set up CloudWatch and AppKeeper to perform the same functions.
|July 8, 2020||
Test/QA Systems are a Critical Part of Enterprise Availability
“I could kiss you,” that’s what a friend blurted out to me nearly three decades ago as she ran towards me. She had dropped her reeds for her saxophone on the way to one of the biggest band competitions in our region. I didn’t know whose they were, but when I saw the pack of reeds on the seat on the bus I picked them up and took them with me to the warm-up area. Three minutes into her warm-up, her 1st reed cracked and she panicked as she reached into empty pockets for replacements. When I piped up that I had found them, she blurted out, “I could kiss you right now.”
As the VP of Customer Experience at SIOS Technology Corp. I have the unique and distinct pleasure of working with a number of enterprise customers and partners at different phases of the availability spectrum. Sometimes I have the opportunity of working with end customers for issue resolution, mitigation, and improvements. At other times our teams are actively working with partners and customers to architect and implement enterprise availability to protect their systems from downtime. A recent customer experience reminded me of something that happened nearly 30 years ago when my friend blurted out, “I could kiss you.”
My team and I were on a customer call. The call began with the usual pleasantries, introductions, and an overview of the customer’s enterprise environment. Thirty minutes into the call, things were going so well. Their architecture was solid, thoughtful, and well documented. Their team was knowledgeable, technically sound, and experienced. But then, the customer intimated that due to cost savings they would not be planning to maintain a dedicated test/quality system. I took a deep breath. Actually it was more of an exhale like the rush of air from a gut punch. I prepared to respond, but before I could a voice broke through. “The number one cause of downtime is lack of process,” exclaimed the Partner Rep Architect on the call with us. After a brief banter, the customer agreed to maintain a test/QA system and I nearly blurted out, “I could kiss you!”
On the front lines of many Enterprise deployments (new systems, data center migrations, and system updates) my teams in Support and Services have seen dozens of issues that could have been mediated by utilizing a test system/cluster.
A test/quality system is an invaluable part of an HA strategy to avoid downtime. Common tasks associated with maintaining an enterprise deployment such as patches, updates, and configuration changes come with risk. Enormous risk.
Commonly identified risks of testing in production include several serious and potentially catastrophic issues:
If a customer attempts to apply risky changes in production, the result can be quite damaging. On top of those listed above, there is an increased risk of downtime, corruption of application installations, and in some cases irreversible damage. Take the case of Customer X (a high profile SAP Enterprise shop in the manufacturing industry).
When patches are applied to a test/QA or sandbox system, patches and critical fixes can be managed and verified to reduce loss of productivity and unplanned downtime. Testing applications in a production-like environment allows you to identify unforeseen problems and correct the issues before they adversely impact your operations. Pre-production design and testing eliminate costly business disruption, improve your customer experience and protect your brand.
Using a test QA System to Improve Production Availability and Processes
Here are the basics that using a test/QA system, can provide for improving your production availability and processes. A controlled environment, that is similar (it must resemble production as close as possible) to the production environment, provides the ability to:
If you have a Test/QA environment for deploying your critical enterprise availability software, I could kiss you right now. Having this environment gives your team the ability “to test, validate and verify(2)” architecture, business requirements, user scenarios, and general integration with a system or set of systems that most closely resembles the production environment- you know the one that makes the money. Of course, you will still have to schedule windows to maintain your production systems and perform testing on them as well, but after a safe buffer step has been completed in between.
— Cassius Rhue, VP, Customer Experience
|July 7, 2020||
Case Study: AWS EC2 Monitoring Solution relieved a global manufacturing company from stress as it moved to the cloud.