SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

How To Choose A Cloud When You Need High Availability

by Leave a Comment

How to Choose a Cloud when you need High Availability

How To Choose A Cloud When You Need High Availability

Understand the cloud market

A number of analyst firms are predicting an ever-increasing number of deployments of applications, databases, and solutions in the cloud. According to Gartner, firms are “moving to the cloud at an increasing rate.”[1] In fact, Gartner and other analysts expect the pace of cloud migration and deployment will continue to accelerate, driven in large part by the pace of innovation in the cloud. In a TechTarget article by Kurt Marko, of MarkoInsights, Marko notes that the pace of innovation that is “being undertaken in the cloud likely can’t be replicated on premises due to the elastic, scalable, and on-demand nature of managed public cloud services.”

We see more and more companies that had been using the cloud only for DevOps applications and databases that were not essential to their business, are now moving mission-critical applications, ERPs and databases that require high availability protection to the cloud.

If you are considering a move to the cloud – and it seems likely that you are – there are several keys to understand when you need high availability.

Familiarize yourself with the cloud high availability options

To plan for the proper availability solution for a cloud or hybrid cloud deployment, consider what the pain points are with regards to both availability (99.9% uptime) and high availability (99.99% uptime). You also need to understand the options that are available for high availability with an eye towards your plans to migrate to the cloud. Notable analysts and experts suggest looking for solutions that will not only mitigate and reduce the pain of migrating your workloads, but will also provide a balanced and comprehensive approach to availability throughout the lifespan of your cloud architecture. Note, it is also wise to consider solutions that can provide protection and high availability for portions of your workload that may one day repatriate from the cloud back to your on-premises environment.

Here are ten things to consider when comparing your availability options in the cloud: 

1. The deployment method. Is it possible to deploy the availability solution you are considering  using an image, CLI, UI, or other repeatable solution such as cloud formation template or packaged scripts.

2. The system requirements. Most notably, consider the operating system (OS), disk, CPU, and memory requirements.

3. The deployment environments. Do your availability options support on-premises only, one or more public clouds, or can they support a mixture, and/or hybrid cloud deployment. Is there a SaaS offering available as well?

4. The breadth and depth of application protection. “Breadth” meaning what types of applications, databases, front-ends, networking, and infrastructure components can be protected?  Is there a flexible framework for adding new applications and variants? “Depth” meaning – is the solution application-aware – and able to maintain application-specific best practices throughout the application failover/failback processes?

5. Performance requirements. We often think of RTO and RPO, but what about other performance needs of your solution. Will your availability solution cause performance issues on failover?

6. Resilience requirements. How large a cluster can the availability solution support?, How many faults and failures can it detect and recover from. How will replication be handled while keeping metadata in sync?

7. Supportability and maintenance. Does the availability vendor have experience with a wide range of availability needs and configurations? Do they have longevity, and a support system designed to address issues that may go beyond their solution? Can they help you minimize disruption and planned downtime during your system management and maintenance (patches, upgrades, and general maintenance).

8. Total cost of ownership. There are entire industries and services dedicated to helping you calculate the total cost of ownership, so we won’t cover that here. Suffice it to say, your calculations will be unique to your organization, cloud provider, applications, and IT team. You should consider whether your availability solution vendor can help you identify strategies for saving utilization, licensing, and other costs? Does the solution automate manual tasks, reduce IT labor time?

9. Licensing and pricing model. How do you consume the cost of the software? Is there a subscription fee, subscription model, pay-as-you-go offering, bring your own license (BYOL), or combination of flexible options. How will you enable the product licensing?  Is there a license server, licensing service, or encrypted key based on virtual machine deployment details, such as address, hostname, MAC address.

10. The impact on IT staff. How much training with the solution require? How much manual intervention will be needed in the event of an application failure event or disaster? Will it require specialized scripting that needs to be maintained? Who will be responsible for ongoing maintenance?

Weigh the benefits and trade-offs

Like every important decision, you need to understand your tradeoffs and choose the best balance to meet your needs. For example, I recently asked a friend to recommend a good walking shoe. I bought a pair he raved about – noting how lightweight they were, how strong and durable the fabric, and how stylish they were.  I went for my first long walk-run in them, and I donated my first pair of “one run” shoes immediately thereafter. When I went to ‘Fleet Feet’ to get an expert’s opinion I ended up with a heavier shoe, with more breathable fabric (also less durable), and an unrivaled level of hideousness. I made a tradeoff between appearance and function that worked for my needs and budget.

Like running shoes, there is no silver bullet solution that will be the right fit for every company, every application, every database, and every possible server and architecture. You are officially free to stop looking for it. Instead, settle into the activity of weighing the trade-offs to determine what is the right fit for your company’s needs. Think about your tradeoffs. For example, if you’re sure you will be a full Microsoft shop, the importance of GCP and AWS support should be a little lower in your evaluation process.

Take your IT infrastructure dynamics into account

Think holistically about availability in your entire IT infrastructure – both on premises and in the cloud. The reasons to do so are best explained with another analogy. In 2018, I was the coordinator for an outreach program feeding the homeless and hungry in Columbia, South Carolina. Our group met once a week to serve a meal and a message of hope to over 100 men, women and children. When we considered expanding – adding more days of the week, more hours, or additional services, we had to think well beyond simple scheduling requirements. Knowing that we were providing a critical service to clients who depend on us, we had to consider all the factors that affected our ability to deliver those services consistently for the long-term, such as: cost, ages of our team members, outside obligations, alternative methods to achieve our goals, risk factors, and other dynamics within our parent organization.

When you are choosing your solution, after you’ve understood the market, familiarized yourself with options, and weighed the trade-offs, the last step is to take into account the various other dynamics in your overall environment. Will the solution meet the needs of your business as a whole? Will your critical data be protected from loss? Will your end-user productivity be protected from downtime? What training will be required to move to the cloud and how will that impact your ability to manage or maintain the solution that you choose? What IT roles will be added, removed, or changed in your cloud journey?  Will any responsibilities for application availability move to any line-of-business owners? And how will the shifts in responsibilities, or team make up improve or decrease your overall potential for success. Consider whether your team needs to take a step-by-step approach, migrating smaller workloads first.

As VP of Customer Experience, I have seen a wide range of cloud migrating planning – some straightforward others extremely disruptive. In one instance a customers’ move to the cloud was highly contentious because management saw it as an opportunity to eliminate an entire IT department. I’m not suggesting that you play politics, but you should be aware of all of the factors at play in these complex projects.

Migrating to the cloud is supposed to save money, time and resources while affording improvements in availability and resilience. Regardless of which cloud you choose, make sure that you consider these tips and select the corresponding availability solution that gives you the flexibility to deliver the protection you need in the configuration you want.

Learn more about cloud high availability options with SIOS.

– Cassius Rhue, VP of Customer Experience, SIOS

Reproduced with permission from SIOS

Six Reasons Your Cloud Migration Has Stalled

by Leave a Comment

 

 

Six Reasons Your Cloud Migration Has Stalled

More and more customers are seeking to take advantage of the flexibility, scalability and performance of the cloud. As the number of applications, solutions, customers, and partners making the shift increases, be sure that your migration doesn’t stall.

Avoid the Following Six Reasons Cloud Migrations Stall

1. Incomplete cloud migration project plans

Project planning is widely thought to be a key contributor to project success. The planning plays an essential role in helping guide stakeholders, diverse implementation teams, and partners through the project phases. Planning helps identify desired goals, align resources and teams to those goals, reduce risks, avoid missed deadlines, and ultimately deliver a highly available solution in the cloud.  Incomplete plans and incomplete planning are often a big cause of stalled projects.  At the ninth hour a key dependency is identified. During an unexpected server reboot an application monitoring and HA hole is identified (see below). Be sure that your cloud migration has a plan, and work the plan.

2. Over-engineering on-premises

“This is how we did it on our on-premises nodes,” was the phrase that started a recent customer conversation. The customer engaged with Edmond Melkomian, Project Manager for SIOS Professional Services, when their attempts to migrate to the cloud stalled.  During a discovery session, Edmond was able to uncover a number of over-engineered items related to on-premises versus cloud architecture. For some projects, reproducing what was done on premises can be a resume for bloat, complexity, and delays. Analyze your architecture and migration plans and ruthlessly eliminate over-engineered components and designs, especially with networking and storage.

3. Under-provisioning

Controlling cost and preventing sprawl are an important and critical aspect of cloud migrations.  However, some customers, anxious about per hour charges and associated costs for disks and bandwidth fall into the trap of under-provisioning.  In this trap, resources are improperly sized, be that disks that have the wrong speed characteristics, compute resources with the wrong CPU or memory footprint, or clusters with the wrong number of nodes.  In such under-provisioned cases, issues arise when User Acceptance Test (UAT) begins and expected/anticipated workloads create a log jam on undersized resources.  Or a cost optimization of a target node is unable to properly handle resources in a failover scenario. While resizing virtual machines in the cloud is a simple process, these sizing issues often create delays while architects and Chief Financial Officers try to understand the impact of re-provisioning resources.

4. Internal IT processes

Every great enterprise company has a set of internal processes, and chances are your team and company are no exception.  IT processes are usually key among the processes that can have a large impact on the success of your cloud migration strategy. In the past, many companies had long requisition and acquisition processes, including bids, sizing guides, order approvals, server prep and configuration, and final deployment.  The cloud process has dramatically altered the way compute, storage, and network resources, among others, are acquired and deployed.  However, if your processes haven’t kept up with the speed of the cloud your migration may hit a snag when plans change.

5. Poor High Availability planning

Another reason that cloud migrations can stall involves high availability planning. High availability requires more than a bundle of tools or enterprise licenses.  HA requires a careful, thorough and thoughtful system design.  When deploying an HA solution your plan will need to consider capacity, redundancy, and the requirements for recovery and correction. With a plan, requirements are properly identified, solutions proposed, risks thought through, and dependencies for deployment and validation managed. Without a plan, the project and deployment are vulnerable to risks, single point of failure issues, poor fit, and missing layers and levels of application protection or recovery strategies.  Often when there has been a lack of HA planning, projects stall while the requirements are sorted out.

6. Incomplete or invalid testing

Ron, a partner migrating his end customer to the cloud, planned to go-live over an upcoming three day weekend. The last decision point for ‘go/no-go’ was a batch of user acceptance testing on the staging servers.  The first test failed.  In order to make up for lost time due to other migration snags, Ron and team skipped over a number of test cases related to integrating the final collection of security and backup software on the latest OS with supporting patches. The simulated load, the first on the newly minted servers, tripped a series of issues within Ron’s architecture including a kernel bug, a CPU and memory provisioning issue, and storage layout and capacity issues. The project was delayed for more than four weeks to address customer confidence, proper testing and validation, resizing and architecture, and apply software and OS fixes.

The promises of the cloud are enticing, and a well planned cloud migration will position you and your team to take advantage of these benefits. Whether you are beginning or in the middle of a cloud migration, we hope this article helps you be more aware of common pitfalls so you can hopefully avoid them.

– Cassius Rhue, Vice President, Customer Experience

Reproduced from SIOS

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.

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 more in its availability.  You should consider many of the excellent third-party solutions that offer valuable functionality to the AWS community.  One choice is SIOS AppKeeper, an easy to configure and use solution that monitors your Amazon EC2 instances and automatically restarts services or reboots instances if they experience system failures.  Here’s a quick video of how AppKeeper works

While moving to the cloud for your applications makes a lot of sense, you cannot abandon DevOps best practices.  Amazon AWS provides you with a rich set of functionalities and tools, but you still need to take primary responsibility for the security, backup and availability of your applications.  How you do this depends on your skills and the importance of the applications themselves.

We invite you to join the hundreds of customers who have been taking advantage of AppKeeper to reduce their Amazon EC2 downtime by signing up for a free 14-day trial of the service.

* Note:  To use AWS Trusted Advisor, a contract for business support or higher is required.

Reproduced with permission from SIOS

Why is AWS EC2 Application Monitoring So Hard?

by Leave a Comment

Why is AWS EC2 Application Monitoring So Hard?

Why is AWS EC2 Application Monitoring So Hard?

Congratulations! You’ve migrated your core applications to the AWS cloud.  Or, you are developing new “cloud-native” applications and hosting them in the cloud.  Perhaps you are taking advantage of Amazon EC2’s scalability and its elastic architecture.  Either way, you now want to ensure that those applications stay up and running, or that you are alerted quickly if and when something happens.

Because something will happen.  Our customer data shows that companies using only three EC2 instances experience downtime at least once a month.  That means unhappy users unable to access their applications. You need a monitoring solution to tell you what’s going on.

How to narrow down EC2 application monitoring solutions

The first step in your search for the perfect EC2 monitoring solution should be to understand your requirements and your own technical capabilities.  Monitoring solutions are not all alike.

Are you interested in a feature-rich solution that monitors a wide array of systems?  Or one that focuses on a core set of systems, such as your EC2 environment?

What do you want to do with the output from your application monitoring solution?  Do you want as much information as possible to help your developers’ troubleshoot issues?  Or are you looking for quick alerts and assistance in remediating from any failures?

And what is your technical appetite to install and manage another application?  Do you love scripting?  Or do you want something that is “set-it-and-forget-it”?

A search for “application performance monitoring solutions” on Google returns 1,170,000,000 results!  Jump into the Amazon AWS Marketplace and you’ll find 453 products listed in the DevOps – Monitoring category.  Having a clear sense of your requirements and your own technical capabilities will help you narrow down your search.

Monitoring applications running on Amazon EC2 with Amazon CloudWatch or other APM solutions

If you are hosting your applications on Amazon EC2, then you might consider using Amazon CloudWatch.   How familiar are you with standard and custom metrics?  You should know that you need quite a lot of technical expertise to run Amazon CloudWatch properly. Amazon CloudWatch is a great solution for users who need data and actionable insights to respond to system-wide performance changes, optimize resources and a unified view of their operational health.  But this all comes at a price in terms of the knowledge and experience needed to configure and manage Amazon CloudWatch properly.

Another choice is for you to evaluate and acquire one of the many commercially available application performance monitoring (“APM”) solutions on the market, such as from AppDynamics, Datadog, Dynatrace, or New Relic.  But keep in mind your requirements.  How broadly do you need to monitor?  And what do you intend to do with that information?  Are you ready to be overwhelmed with alerts?  And be aware that many APM solutions do nothing to help you recover beyond pinpointing the issue.  You still have to drop everything to manually restart services or reboot your instances.

Monitor applications running on Amazon EC2 using SIOS AppKeeper

But there is another way.  SIOS AppKeeper is a SaaS service that can be configured to automatically discover any EC2 instances and their services. It then automatically take any number of actions if and when downtime is experienced.  So instead of getting alerts that something is wrong, you get notified that something happened and was automatically addressed.
Why-App_monitoring-hard-2-1024x470

SIOS AppKeeper starts at only US $40 per instance per month. We invite you to view this short video to see how easy it is to install and use AppKeeper.

Why is AWS EC2 Application Monitoring So Hard?

One of our customers, Hobby Japan, a publishing company in Tokyo, was initially using Amazon CloudWatch but their understaffed IT team couldn’t respond fast enough to alerts. They wanted to leverage automation and moved to SIOS AppKeeper.  Since moving to AppKeeper they haven’t experienced any issues or unexpected downtime with their EC2 instance. Here’s a link to a case study on Hobby Japan.

Monitoring your cloud applications shouldn’t be a full-time job.  You want a monitoring solution that is easy to install and use, doesn’t overwhelm you with alerts, and hopefully takes care of systems impairments automatically.  We encourage you to try a 14-day free trial of SIOS AppKeeper by signing up here.

Article reproduced with permission from SIOS