SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

Reducing downtime for WordPress sites hosted on Amazon EC2

by Leave a Comment

 

 

Reducing downtime for WordPress sites hosted on Amazon EC2

Going from ignorance to bliss with SIOS AppKeeper

WordPress is an open-source content management system (CMS) used by millions of companies to create websites, blogs, or apps.  According to estimates, there are over 75 million websites today that use WordPress and many companies are beginning to host their WordPress instances on Amazon EC2. Users love WordPress for its flexibility and the ease with which you can create and modify layouts.  If you are using WordPress for your website, then you are in good company.

With so many users relying on WordPress to power their websites, you can imagine that there is a rich set of third-party tools (plugins and services) designed to meet the needs of those users.  Some of these plugins are to add security functionality, such as scanners to probe for vulnerabilities.  Because more plugins can lead to more vulnerabilities.

Trust, but verify.  Why monitoring WordPress uptime matters.

Deploying a website or application running on WordPress without monitoring it properly would be like leaving your car running outside with the keys in it.  You’ll want to protect your investment.  For companies managing WordPress sites (or any applications, for that matter), there are three primary reasons to monitor:

  1. To understand the visitors and optimize their experience;
  2. To monitor the speed of the site and ensure that it meets expected service level agreements (SLAs); and
  3. To ensure that you maximize uptime.  Downtime can mean (serious) lost revenue for any e-commerce sites running on WordPress.

You believe your WordPress site is working properly, but you really want to know what is going on.  The goal of monitoring should be to know quickly what is going on and why, allowing you to respond quickly to any issues.

There is a wide range of tools available to help WordPress users monitor their sites.  Some are very focused on WordPress, such as ManageWP and JetPack, while others are industry-standard solutions that apply to many different CMSs and applications.  Some go “deep” and are focused on one element of monitoring, such as Google Analytics and its focus on visitor analytics, while others try to go “broad” and address all three key aspects of monitoring.  What you decide to use depends on your budget, your requirements, and your technical capabilities.

Here at SIOS, we believe that the best of breed approach makes sense.  We focus on monitoring applications and ensuring that our customers’ experience as little downtime as possible with those applications.  Many of our customers are using SIOS AppKeeper today to monitor and protect their WordPress sites running on Amazon EC2.

SIOS AppKeeper – simple but powerful monitoring and automated remediation for WordPress sites

Many WordPress monitoring solutions (from free plugins to low-cost freemium services) will tell you when your WordPress site is down.  And depending on the sophistication (and cost) of your monitoring solution, it may tell you why your WordPress site is down.  But will it help you reduce downtime and automatically restart your services or reboot your instances when downtime is experienced?

Many companies host their WordPress sites on Amazon EC2 using either Apache or NGINX webservers.  SIOS AppKeeper is a SaaS service that can be configured to automatically discover WordPress sites or applications running on Amazon EC2 instances and their services, and then automatically take any number of actions if and when downtime is experienced.  So instead of only getting alerts that something is wrong, you get notified that something happened and was automatically addressed.

Downtime matters.  If you are running an e-commerce site using WordPress, then downtime will result in lost revenue.  How much revenue?  Simply divide your annual revenues by 365 days and 24 hours (Annual revenue/365/24) to understand your revenue per hour.  In 2013 Google experienced a 5-minute outage that cost them $545,000 in revenue. Now, you may not be Google, but you certainly do want to eliminate downtime wherever possible.

Now imagine what happens when you receive an alert that your WordPress site is down.  Are you ready to respond immediately?  Do you know what should be addressed to get your WordPress site back up and running?  According to our customer research, the average customer using only three Amazon EC2 instances experiences downtime at least once a month.

SIOS AppKeeper monitors Amazon EC2 and alerts you to any downtime AND takes action to remediate the situation, by either restarting your Amazon EC2 services or rebooting your instances.

AppKeeper addresses over 85% of our customers’ Amazon EC2 downtime issues automatically.  This means that you get notified that a failure was identified and addressed, without you having to drop everything or lose any significant revenue.

Today hundreds of companies rely on AppKeeper to keep their cloud environments running. We invite you to check out the video below see how easy it is to install and use AppKeeper.

Video: Installing AppKeeper and recovering from AWS EC2 failures Demo

And if you like what you see, please feel free to sign up for a free 14-day trial of AppKeeper. AppKeeper starts at only US$40 per instance per month.

Reproduced with permission from SIOS

Migrating to the cloud? Here’s how your DevOps priorities should change when you move to Amazon EC2

by Leave a Comment

 

 

Migrating to the cloud? Here’s how your DevOps priorities should change when you move to Amazon EC2

A majority of companies migrating to the cloud, or creating “cloud-native” applications, are doing so with Amazon Web Services (AWS).  AWS offers a lot of cost and functionality advantages.  Companies who have adopted industry-standard developer operations (“DevOps”) best practices for monitoring and managing their on-premise environments often ask themselves how they adapt to their new cloud environments and applications.

How will DevOps priorities change when you move from on-premise applications to Amazon EC2?  Here’s an explanation of the differences between the two and what you should keep in mind.

DevOps priorities in the cloud?  The same. But different.

We often hear customers say that operations will be easier when they move to AWS. We caution them that moving to the cloud (or even AWS) does not mean that they no longer need to monitor and manage their applications.

Companies moving to Amazon AWS can take advantage of lower costs and manpower resources when it comes to hardware procurement, provisioning, and maintenance.  But you need to take into account that when you decide to host applications on Amazon EC2 that anything above the Operating System layer is your responsibility.

When it comes to backup/availability guarantee/security measures, etc. for your Amazon EC2 environments, the priorities are the same as if they were on-premise applications. And Amazon provides some native tools and functionality.  But you need to decide if they are the right fit for requirements.

Security, Backup… What do you need to know when managing Amazon AWS environments?

 

So what are some of the AWS-specific considerations you need to keep in mind as you move to Amazon EC2?  And what are the right tools for you?  The time you invest upfront in designing your applications and how you will deploy and manage them will pay off.

Your first consideration should be how you will secure your Amazon EC2 applications.  Network design, such as “which ports to open” and “from where to allow access” must be considered in the same way as for your on-premise applications.  These can be configured in AWS using security groups and network ACLs (access control lists).

You can use the AWS Trusted Advisor functionality*, which automatically examines your AWS environment and points out whether or not it is set to the recommended settings, making it possible to check your company’s AWS environment for security issues.  We recommend checking with the AWS Trusted Advisor both at the time of implementation and periodically.

Another essential aspect of security is the management of authentication and access privileges.  AWS consolidates all of these into AWS Identity and Access Management (AWS IAM).  In addition to controlling who can access which EC2 instances, you can also use AWS IAM to set up access permissions from EC2 instances to other resources (such as DBs), etc.  Once you have migrated to AWS, the first thing you need to do is to set up the accounts and access restrictions properly in AWS IAM.

The next consideration is “how will I backup my applications on Amazon EC2?”  Amazon EC2 provides the ability to take snapshots, which allows you to do so.  In addition, using “Amazon Data Lifecycle Manager” makes it easy to set up periodic snapshots, as well as incremental backups.  Snapshot files are stored on the Amazon S3 storage service.  You are charged according to their capacity, so you need to be aware of the amount of data you have and set up such settings as “reduce the capacity by incremental backups” and “delete from old data.”

“Availability” needs to be considered in advance. The key is to operate the system in accordance with the priority level of the system.

The last consideration is availability.  With Amazon EC2 applications, as well as those that are on-premise, you should consider the level of availability required based on cost and system importance. However, if you use Amazon’s Multi-AZ deployment functionality, you can specify a redundant configuration between different data centers.  However, using Multi-AZ costs more than using a single-AZ configuration (although not as much as if you had redundant on-premise systems).  When designing your applications you need to consider whether Multi-AZ is required and how much you should invest in availability. Using SIOS clustering software allows you to create a clustering environment that fails over across availability zones and regions for maximum DR protection.

If you aren’t investing in failover, then you should at least be monitoring your applications and planning how to recover them when downtime is experienced.  You can use Amazon CloudWatch to easily monitor general items such as CPU, memory, and disks, and you can also program the Amazon EC2 Auto Recovery function to automatically recover instances when an error occurs in the EC2.

If your application is mission-critical, then you will want to invest in high availability protection that delivers at least 99.99% uptime. Get in touch with SIOS availability experts to make sure your application’s uptime is secured.

Reproduced with permission from SIOS

Expand Your High Availability Metrics

by Leave a Comment

Expand Your High Availability Metrics

In the technology field, we love data. We love data about data and all the metrics and measures that our tools can bring. We’ve created industries around analytics, products that capture every detail from thousands of connected devices. We love metrics and measures. In many instances within the higher availability space, we love the high availability metrics that tell us how quickly a system recovered from the failure. We calculate and track the time between detection and remediation, and we obsess over knowing and measuring how much transactional data would be lost in a disaster, system failure, or disk crash.

Ironically, in high availability and disaster recovery (HA/DR) systems, there are some metrics that don’t get enough attention.

Here are eight other high availability metrics you should be watching to manage your environment:

1.  Security alerts

Availability isn’t just about application monitoring and recovery.  Systems that are publicly available are always under attack.  If you aren’t monitoring security alerts and warnings, your applications may be running flawlessly, while your intellectual property is being funneled flawlessly out the door.

2. Idle connections

Idle connections sound harmless, but they are about as harmless as the green leafy kudzu on a southern lawn.  Idle connections take up resources and threaten to fill database pools, congest networks, and stifle performance.  Furthermore, idle connections can indicate a problem in the application layer or database configuration.

3. Long-running queries, commands, or jobs

This applies not just to database queries or jobs, but also to commands and backups.  Long running queries, commands and jobs can be an indicator of poor system health, slow disk speeds, CPU or other resource contention, or deeper systematic, application compatibility or OS problems.

4. Disk IO

Disk IO typically refers to the input/output operations of the system related to disk activity. Measuring disk I/O can help identify bottlenecks, poor hardware configurations, improperly sized disk or poorly tuned disk layouts for a given workload.  Monitoring disk I/O can help tell you if the long running queries are a function of poor sql syntax, poorly coded applications, or latency and access problems.

5. Memory

We all think about how much memory is being used, but memory monitoring goes beyond measuring and looking at free versus used.  Monitoring memory helps you look into bottlenecks, leaks, identify improperly sized systems, understand load, load average, and spikes.  In addition, knowing about memory intensive patterns can help you tune your availability suite to avoid false failures.

6. Disk Space

As VP of Customer Experience I once had the unfortunate experience of waking up early in the morning for an emergency call.  The customer was facing a down production system after a power outage.  When they tried to restart their system their protected applications failed to start.  After a quick check of the error logs it was clear that the root drive was 100% full.  The application could not write to any of the file systems.  Disk space monitoring is available in many forms and ways and having it as a metric can prevent unnecessary problems and costly last-minute scrambles to add more. .

7. Errors and alerts

Errors, alerts, and recovery messages in the logs are another good metric to consider.  Your availability solution may be keeping your clients online and happy, but it may also be masking an issue that will need your attention soon.  Adding log monitoring for FATAL, PANIC, and key ERROR messages can help you identify issues that your availability solution is frequently recovering from, such as database crashes, application panics or core dumps, or fatal errors requiring a cold restart.

8. Recovery numbers

Similar to monitoring errors and alerts, the recovery numbers can tell you a lot about the health of your system’s availability.  If you are averaging more than one application recovery per week, you’re likely experiencing something more than your normal availability protection.  And while the recovery was successful in restarting your application or system, too many of these false or even real recoveries isn’t healthy.

The list of HA/DR metrics that we can monitor and the tools to monitor them are growing by leaps and bounds.  Be sure that you and your team consider expanding your current data capture and analysis to include those that make for the best higher availability system possible.

— Cassius Rhue, VP, Customer Experience

Reproduced with permission from SIOS

Automated recovery for Microsoft IIS Applications running on Amazon EC2

by Leave a Comment

Automated Recovery For Microsoft IIS Applications Running on Amazon EC2

A Better Choice For Reducing IIS Downtime

Microsoft’s IIS (Internet Information Services) is the fourth most popular web server in use today, with a 7.8% market share behind Apache, Nginx, and Cloudflare (source W3Techs.com, 8/12/20). And many IIS customers are running their IIS applications on Amazon EC2.

IIS is a versatile, extensible, and highly configurable web server. IIS includes some important functionality to ensure that applications are running properly, such as Application Pools and remote management capabilities to allow administrators to manage IIS remotely using PowerShell.

Deciding How To Monitor And Manage IIS Applications

When it comes to managing and monitoring IIS applications, customers have a number of options. They are either focused on improving the performance of applications running on IIS, or monitoring and addressing any failures.

Microsoft does include some native functionality to help you optimize and manage your applications running on IIS. If you and your team are very technical, then you may be comfortable using PowerShell or another scripting language to manage IIS Application Pools. Doing this allows you to automatically recycle your pools and virtual memory when certain time or request thresholds are met.

But this does not help you if your IIS applications experience a failure.  To monitor your IIS servers, you need to look to monitoring (“APM”) tools that can alert you to any failures and provide you with details about what failed.  These include commercial solutions such as from SolarWinds, AppDynamics, Dynatrace, Datadog, and New Relic.  How you decide between them depends on your requirements, the scope and sophistication of their features, and the user interface and the simplicity of the set-up process. APM solutions are great at alerting you when something goes wrong and why, but they don’t always help you get back up and running if your IIS servers are down.

A Better Choice For Reducing IIS Downtime

If you are looking for a solution that not only monitors your IIS servers running on Amazon EC2 but also eliminates downtime, then we encourage you to check out SIOS AppKeeper monitoring solutions. AppKeeper continuously monitors and automatically recovers applications, such as those running on IIS, if they experience service interruptions and downtime.

Let’s look at how AppKeeper EC2 monitoring solution helps reduce IIS downtime:

  • AppKeeper monitors your EC2 services and instances. Once you install and configure AppKeeper (which only takes about 10 minutes) you specify which Amazon EC2 instances and services it should monitor, and what actions should be taken if a systems impairment is experienced.
  • AppKeeper alerts you if any systems failures are detected with your IIS webservers.  You receive an alert by email or SMS and can see the details of the failure events and what actions were taken.

  • AppKeeper lauches automatic restarting services and rebooting instances if necessary upon the detection of system failures. You no longer have to respond to any alerts and troubleshoot what happened before restarting. AppKeeper does that automatically for you.

By going beyond simply managing IIS server performance or monitoring to automatic remediation, AppKeeper eliminates downtime and provides the peace of mind you deserve.

Today hundreds of companies rely on AppKeeper to keep their cloud environments running. We invite you to check out the video below see how easy it is to install and use AppKeeper.

Video: Installing AppKeeper and recovering from AWS EC2 failures Demo

And if you like what you see, please feel free to sign up for a free 14-day trial of AppKeeper.

Reproduced with permission from SIOS

How to Deliver High Availability for SQL Server in Linux Environments

by Leave a Comment

How to Deliver High Availability for SQL Server in Linux Environments

How to Deliver High Availability For SQL Server in Linux Environments

If your organization is running business-critical Microsoft SQL Server on Linux, your IT team undoubtedly knows how challenging continually maintaining high availability, performance and security can be. Particularly difficult is how to ensure high availability with robust replication and automatic failover. Using open-source software and an easily configured HA SANless cluster solution can offer a simpler maintenance approach without sacrificing the safety and performance your organization requires.

Limited High Availability Options for Linux

Most Linux distributions give IT departments two inferior choices for high availability: either pay more for the SQL Server Enterprise Edition to implement Always On Availability Groups, or struggle to make complex do-it-yourself HA Linux configurations work well—something that can be extraordinarily difficult to do.

The problem with using the Enterprise Edition is that it undermines the cost-saving strategy for using an open-source operating system on commodity hardware. For a limited number of small SQL Server applications, it might be possible to justify the additional cost. But it’s too expensive for many database applications and will do nothing to provide general-purpose HA for Linux.

Providing HA across all applications running in a Linux environment is possible using open-source software, such as Pacemaker and Corosync, or SUSE Linux Enterprise High Availability Extension. But getting the full software stack to work as desired requires creating (and testing) custom scripts for each application, and these scripts often need to be retested and updated after even minor changes are made to any of the software or hardware being used. Availability-related capabilities that are unsupported in both SQL Server Standard Edition and Linux can make this effort more challenging.

Finding an Alternative High Availability Solution for SQL Server in Linux

To make HA both cost-effective and easy to implement, you may want to consider two different, general-purpose approaches.

One is using storage-based systems that protect data by replicating it within a redundant and resilient storage area networks (SANs). This approach is agnostic with respect to the host operating system, but it requires that the entire SAN infrastructure be acquired from a single vendor and relies on separate failover provisions to deliver high availability.

The other approach is host-based and involves creating a storage-agnostic SANless cluster across Linux server instances. As an HA overlay, these clusters are capable of operating across both the LAN and WAN in private, public and hybrid clouds. The overlay is also application-agnostic, enabling organizations to have a single, universal HA solution across all applications. While this approach does consume host resources, these are relatively inexpensive and easy to scale in a Linux environment.

Most HA SANless cluster options provide a combination of real-time block-level data replication, continuous application monitoring, and configurable failover/failback recovery policies to protect all business-critical applications, including those using Always On Failover Cluster Instances available in the Standard Edition of SQL Server.

SIOS Technology Corp. offers more robust HA SANless cluster solutions for Linux with advanced capabilities that are designed to free IT from the complexity and daily challenges of supporting and optimizing computing infrastructures. The SIOS Protection Suite solution with LifeKeeper provides:

  • Continuous monitoring of the entire Linux application stack
  • Complete Application-Aware Protection with its application recovery kits (ARK) for fast, safe recovery or failover of complex applications and databases
  • Wizard-driven setup for Linux clustering
  • Configuration flexibility, such as using a traditional shared-storage cluster or software to synchronize local storage in a SANless cluster configuration

For example, a SANless cluster can handle two concurrent failures. The basic operation is the same in the LAN and WAN, as well as across private, public, and hybrid clouds.

In a typical two-node cluster server #1 is initially the primary that replicates data to servers #. It experiences a problem, automatically triggering a failover to server #2, which now becomes the primary.

In this situation, the IT department would likely begin diagnosing and repairing whatever problem caused server #1 to fail. Once fixed, it could take over as the primary or server #2 could continue in that capacity replicating data to servers #1.

With most HA SANless clustering configurations, failovers are automatic, and both failovers and failbacks can be controlled by a browser-based console.

For further information about SIOS LifeKeeper and Protection Suite solutions, visit SIOS SAN and SANless High Availability Clusters for Cluster Server Environments.

Reproduced with permission from SIOS