SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

High Availability Architecture and Best Practices

by Leave a Comment

High Availability Architecture and Best Practices

13 Little Known Facts about High Availability

1. Hypervisor HA is not the Same as Application HA

A key misconception is that I have high availability because I have redundancy in my hardware or hypervisor. However, hardware and hypervisor redundancy does not guarantee high availability for applications. It is also not a guarantee that orchestration of applications will be properly executed in a failure.

2. In High Availability, Bigger Does Not Equal Better

If you are a powerlifter, bigger weights are better and smaller reps are better. Or, if we are talking about hugs. (You remember hugs are the things that we used to do when we saw a friend from a different town, that we hadn’t seen in a while.) But, bigger doesn’t always mean better. A bigger kidney stone, for example, is definitely not better. In higher availability, creating a bigger, more complex solution doesn’t always mean that you’ll have increased your high availability. It might mean you have the same availability or less. It may also mean that you have a bigger, more complex system with a lot of moving pieces to sort through in an outage.

3. Everything fails… sometimes

Application programming languages date back to the 1950’s. And while the languages, processors, IDEs, and quality of the code has improved, the reality is “all applications fail at some point.” Failures due to exceptions, bugs, unhandled terminations, accidental terminations, resource exhaustion, and more happen. Having an active/active, or active/passive application availability strategy is still necessary.

4. Focus on ‘why’ as much as ‘how’

Our natural tendency to jump into task completion mode is a necessary asset, but it needs to be tempered and guided by the answer to our questions of why. Adding a solution to an environment without understanding the business, application, database, and stakeholder requirements will lead to either a:

  • Failure
  • Over expenditures
  • Underperformance
  • Confusion and over architecture
  • All of the above

Instead of focusing solely on getting availability implemented, spend the necessary resources and effort to understand the business needs and answers to “why”

5. Unpatched issues are a common source of regret

If you do or you don’t you will have consequences. The consequence of all unpatched issues is regret. As VP of Customer Experience I have seen firsthand the downtime caused by customers failing to address known issues in a timely manner.

6. Undocumented issues cause downtime too

Picture the scene. A new admin is looking into servers on the network. The usage reports indicate the server is not active and no clients are connected. Not recognizing the server and finding no “tags”, documentation or other identifiers, the new admin believes that it should be shut down. Unfortunately the undocumented and uncommunicated instance is actually a standby server whose removal will cause downtime when the primary crashes unexpectedly. This isn’t a fictional story, this is the true story of a new admin who incorrectly identified a server as an idle QA system and shut it down prior to a patching exercise.

7. Complacency is also an enemy

We’d all love it if availability on premises or in the cloud, or anywhere in between was something that we can “set and forget.” But, few, if anything in life is really as simple as “set it and forget it.” One of the biggest enemies of your availability in the future, is your success with high availability now. When disasters are few and far between, and teams feel confident that they have realized sustained stability, complacency can step in. Success tempts us to think nothing is going to change, and complacency in respect to high availability therefore is an enemy to high availability. Things around your enterprise and within your enterprise are changing. The cloud is changing, your business needs are changing, and the applications and Operating Systems are also changing.

8. Change is hard

Change is hard. Just ask anyone with a sweet tooth who’s been trying to give up that second slice of cake before bedtime. Similar resistance occurs even in high availability. Teams, even those who experience disasters, are often reluctant to change even if the change is good. They need a vision, an understanding of why, and support. Other teams, those with solutions in place, are reluctant to improve high availability with fear of introducing instability or exposing themselves to new risk.

9. All change is not good change

Change is good, when change is good. When considering a change to the higher availability solution and architecture it is critical that changes are analyzed against the goals, the requirements, and within the scope of increasing availability. Changes that increase stability, add protection for critical components, eliminate workarounds, optimize the availability of services and are thoroughly tested are good changes.

10. Cheaper is not always better

Cheaper is not always better. While cheaper solutions typically have a lower price tag, they may also come with a number of limitations that make them less than ideal. When there is a lower price tag, beware of missing features such as a lack of application awareness, limited orchestration, hidden complexity, manual recovery and failover, and limited to no user validation. Cheaper solutions may also fail to include customer support. Be sure to understand whether your cheaper solution includes support, or if the support is an additional, and substantial addon cost.

The same applies to cheaper deployments with reduced compute, disk or storage. While the price tag and monthly cost might be lower, your solution may also be functioning at a less than ideal capacity.

11. Loud does not equal effective

Ever heard the story of the boy that cried wolf. An application monitoring solution that produces an alert storm is sooner than later a solution that gets ignored. Having a solution that provides alerts is great, but if that solution triggers critical alerts in error or in excess, it is ineffective.

12. High Availability is a culture and a mindset, not just a product or hardware solution

Software, hardware, processes, solutions and services are all a part of high availability. However, without a buy-in across IT functions and business units, it will be fraught with frustration and constantly the source of budget discussions instead of discussions on value, business stability, increased customer satisfaction, and diminished risk.

13. Now is not too late

Hope is not a strategy for high availability, nor does hoping that you will not have a critical disaster or application failure need to be a strategy. Designing and architecting a highly available enterprise architecture can be made possible now, even if it has been weeks or months since the last disaster.

Contact SIOS to learn more about high availability solutions for your application.

– Cassius Rhue, VP, Customer Experience

Reproduced from SIOS

12 Questions to Uncomplicate Your Cloud Migration

by Leave a Comment

12 Questions to Uncomplicate Your Cloud Migration

Cloud migration best practices 

The “cloud is becoming more complicated,” it was the first statement in an hour-long webinar detailing the changes and opportunities with the boom in cloud computing and cloud migration.  The presenter continued with an outline of cloud related things that traditional IT is now facing in their journey to AWS, Azure, GCP or other providers.

There were nine areas that surfaced as complications in the traditional transition to cloud:

  • Definitions
  • Pricing
  • Networking
  • Security
  • Users, Roles, and Profiles
  • Applications and Licensing
  • Services and Support
  • Availability
  • Backups

As VP of Customer Experience for SIOS Technology Corp I’ve seen how the following areas can impact a transition to cloud. To mitigate these complications, consumers are turning to managed service providers, cloud solution architects, contractors and consultants, and a bevy of related services, guides, blog posts and related articles. Often in the process of turning to outside or outsourced resources the complications to cloud are not entirely removed.  Instead, companies and the teams they have employed to assist or to transition them to cloud still encounter roadblocks, speed bumps, hiccups and setbacks.

Most often these complications and slowdowns in migrating to the cloud come from twelve unanswered questions:

  1. What are our goals for moving to the cloud?
  2. What is your current on-premise architecture?  Do you have a document, list, flow chart, or cookbook?
  3. Are all of your application, database, availability and related vendors supported on your target cloud provider platform?
  4. What are your current on-premises risks and limitations?  What applications are unprotected, what are the most common issues faced on-premises?
  5. Who is responsible for the cloud architecture and design?  How will this architecture and design account for your current definitions and the definitions of the cloud provider?
  6. Who are the key stakeholders, and what are their milestones, business drivers, and deadlines for the business project?
  7. Have you shared your project plan and milestones with your vendors?
  8. What are the current processes, governance, and business requirements?
  9. What is the migration budget and does it include staff augmentation, training, and services? What are your estimates for ongoing maintenance, licensing, and operating expenses?
  10. What are your team’s existing skills and responsibilities?
  11. Who will be responsible for updating governance, processes, new cloud models, and the various traditional roles and responsibilities?
  12. What are the applications, services, or functions that will move from IaaS to SaaS models?

Know Your Goals for the Cloud

So, how will answering these twelve questions will improve your cloud migration. As you can see from the questions, understanding your goals for the cloud is the first, and most important step.  It is nearly universally accepted that “a cloud service provider such as AWS, Azure, or Google can provide the servers, storage, and communications resources that a particular application will require,” but for many customers, this only eliminates “he need for computer hardware and personnel to manage that hardware.” Because of this fact, often customers are focused on equipment or data center consolidation or reduction, without considering that there are additional cloud opportunities and gaps that they still need to consider. For example, cloud does eliminate management of hardware, but it “does not eliminate all the needs that an application and its dependencies will have for monitoring and recovery,” so if your goal was to get all your availability from the cloud, you may not reach that goal, or it may require more than just moving on premises to an IaaS model.   Knowing your goals will go a long way in helping you map out your cloud journey.

Know Your Current On-Premises Architecture

A second critical category of questions needed for a proper migration to the cloud, (or any new platform) is understanding the current on-premises architecture. This step not only helps with the identification of your critical applications that need availability, but also their underlying dependencies, and any changes required for those applications, databases, and backup solutions based on the storage, networking, and compute changes of the cloud.  Answering this question is also a key step in assessing the readiness of your applications and solutions for the cloud and quantifying your current risks.

A third area that will greatly benefit from working through these questions occurs when you discuss and quantify current limitations.  Frequently, we see this phase of discovery opening the door to limitations of current solutions that do not exist in the cloud.  For example, recently our services team worked with a customer impacted by performance issues in their SQL database cluster.  A SIOS expert assisting with their migration inquired about the solution and architecture, and VM sizing decisions. After a few moments, a larger more application sized instance was deployed correcting limitations that the customer had accepted due to their on-premise restrictions on compute, memory, and storage.  Similarly we have worked with customers who were storage sensitive.  They would run applications with smaller disks and a frequent resizing policy, due to disk capacity constraints. While storage costs should be considered, running with minimal margins can become a limitation of the past.

Understand Business and Governance Changes

The final group of questions help your team understand schedules, business impacts, deadlines, and governance changes that need to be updated or replaced because they may no longer apply in the cloud. Migrating to the cloud can be a smooth transition and journey.  However, failing to assess where you are on the journey and when you need to complete the journey can make it into a nightmare. Understanding timing is important and can be keenly aided by considering stakeholders, application vendors, business milestones, and business seasons.  Selfishly, SIOS Technology Corp. wants customers to understand their milestones because as a Service provider it minimizes the surprises. But, we also encourage customers to answer these questions as they often uncover misalignment between departments and stakeholders. The DBAs believes that the cutover will happen on the last weekend of the month, but Finance is intent on closing the books over the final weekend of the same month; or the IT team believes that cutover can happen on Monday, but the applications team is unavailable until Wednesday, and perhaps most importantly the legal team hasn’t combed through the list of new NDAs, agreements, licensing, and governance changes necessary to pull it all together.

As customers work through the questions, with safety and empathy, what often emerges is a puzzle of pieces, ownership, processes, and decision makers that needs to be put back together using the cloud provider box top and honest conversations on budget, staffing, training, and services.  The end result may not be a flawless migration, but it will definitely be a successful migration.

For help with your cloud migration strategy and high availability implementation, contact SIOS Technology Corp.

– Cassius Rhue, VP, Customer Experience

Learn more about common cloud migration challenges.

Read about some misconceptions about availability in the cloud.

Reproduced from SIOS

Cloud Availability: The Biggest Trap of 2021

by Leave a Comment

Cloud Availability: The Biggest Trap of 2021

Author Carey Nieuwhof hooked me with a blog topic of the biggest trap for 2021. While not directly speaking to HA, the topic alone made me reflect on some of the trends of 2020.  Cloud innovations are numerous and begin at the most fundamental levels of the infrastructure. Not to mention advances in AI, machine learning, compute capacity and algorithms, memory management and sharing, and a battery of others. All of these advances add up to making the current generation cloud the most robust, reliable and available data center. These centers, optimized with redundant power, cooling, a legion of IoT devices for monitoring and alerting, redundant networking, high speed interconnects, massive servers, storage, and disks are impressive– and quite possibly the biggest trap that may be looming in 2021.

The biggest trap of 2021 will be believing that cloud availability alone is the same as or enough for higher availability. This is a complex trap to dissect. The list of named advances that make up the backbone of many data centers is indeed vast and impressive, and it is only a fraction of the technological innovations that exist driving the cloud. So, what makes this massively redundant, high capacity, and AI driven infrastructure a trap? Namely, that hardware and infrastructure availability still leave your enterprise at risk.

The Top Risks of Cloud High Availability

Disks

Disks have gotten faster and more intelligent. New eye-popping advances in chip sets, access technology, manufacturing, storage capacity and raid technology means that cloud vendors are able to put up gaudy numbers for speed, access, and redundancy. This reduces the risk for single points of failure (SPOF’s) for the disk infrastructure and provides confidence that a single disk, or even a momentary loss of power to the disks will not cause a lack of availability.

Storage Arrays

The storage arrays and enclosures housed within the data center providing access to the disks have also greatly improved. No longer the big eye soar of blinking lights and Airboat sized fans, these units are small in size but loaded with capacity and performance enhancements. You’ll be hard pressed to find a modern chassis that isn’t built with redundant power, redundant disk capabilities, and able to provide near zero replication between connected storage units, even between units that are dispersed at greater distances. In addition these units have added the benefits of AI to predict failures, proactively resolve problems, and optimize workloads to reduce performance bottlenecks.

Servers

Remember when it seemed so long ago that big name manufacturers and tech prognosticators were predicting game changing technology that would reshape the landscape of the future. It seems like decades ago when people were predicting server technology advances such as: reduced footprint, faster more complex chipsets, NVMe, battery efficiencies, cooling advances, storage advancements, in-memory and persistent memory advances, GPUs and bare metal provisioning. That future has arrived and been surpassed. Servers are now accelerating the pace of cloud computing capabilities and increasing the ability of the cloud to promote redundancy, reliability and robustness.

Networking

Advances in the networking solutions, tools, software and equipment also make the list of things that make cloud availability stronger in 2020. Over the last few years, vendors have released solutions that have expanded the speed, possible topologies, capacities and distance capabilities of inter- and intra- cloud networks. Like so many other technologies, vendors are automating traffic flow and patterns using AI and Machine Learning, taking advantage of advances in manufacturing to build in device redundancy that can be leveraged for availability and reliability.

Applications

Applications are still a vulnerable part of the cloud architecture when left unprotected. Applications that are not protected by an application aware higher availability module or framework, or SIOS Application Recovery Kit (ARK) run the risk of being down at the most critical time or moment in your business lifecycle. A SIOS ARK provides the application in the cloud with critical application aware monitoring and recovery, as well as failover and disaster recovery orchestration in the event of a failure.

Databases

While numbers of databases have increased their robustness, and some have even jumped in to offer replication enhancements, these databases are still a risk on their own. Databases with replication technology still need orchestration, automation, and the intelligence to make sure that they are highly available to the application components that need them. What good is it if your database continues to hum along in your primary Region and Availability Zone, if your application has actually failed to a different Region or DR site. Supplement databases with replication, such as the SAP HANA database, with the automation and best practices of the SIOS Technology Corp HANA ARK and the SAP certified SAP S/4 HANA ARK. Protect databases that do not have replication technology, or whose technology is limited with the combination of the SIOS Protection Suite, SIOS DataKeeper for Linux and the associated ARK.

Storage

In the realm of disks and storage it can be intriguing to believe that the capacity, redundancy of software and hardware raid mean that you are highly available. However, storage is only available if it is accessible to the applications and Virtual Machines that need them. What technology do you have deployed to monitor and recover mounted cloud shares and volumes such as EFS and ANF. An unplanned downtime and its associated chaos can be as near as an unintended unmount, or offline operation by a well-intentioned user.

Virtual Machines

Hypervisor technology has made your virtual machine push button easy. Integrated cloud solutions promise to monitor if the VM is available and provide options such as restart or migrate. These solutions are not enough to cover issues with your Virtual Machine that may stall, delay, or degrade your availability. In addition to what your cloud vendor provides, you need a monitoring and availability solution that understands how to monitor the VM health such as:

  • Disk capacity.
  • CPU deadlocks
  • Memory contention and errors
  • Resource exhaustion

A VM that runs without the ability to process applications requests may escape the eye of your cloud only monitoring, but shouldn’t escape the watchful monitoring of your higher availability solution.

Data Center

Let’s get real for a moment. All the advances in data center availability, redundancy and reliability does not negate the need for eliminating your data center as a single point of failure (SPOF). As VP of Customer Experience, we have worked with a customer who deployed best in class redundancy within the private cloud data center, much like the major public cloud vendors. And if not for the high availability and data replication solution provided by SIOS Technology Corp, this customer would have experienced major downtime when a tropical storm ripped through their area taking out power, backup generators, cooling, and networking.

However, with SIOS Technology, the customer was able to preemptively failover ahead of the storm to a data center more inland. Cooling failures, construction mishaps, as well as human and natural disasters are continual reminders that a single data center isn’t the same as higher availability.

Don’t fall into the biggest trap of 2021. Make sure you have true high availability by avoiding thinking the cloud has you covered.

– Cassius Rhue, VP, Customer Experience

Reproduced from SIOS

Fifty Ways to Improve Your High Availability

by Leave a Comment

I love the start of another year.  Well, most of it.  I love the optimism, the mystery, the potential, and the hope that seems to usher its way into life as the calendar flips to another year.  But, there are some downsides with the turn of the calendar.  Every year the start of the New Year brings ‘____ ways to do_____.  My inbox is always filled with, “Twenty ways to lose weight.”  “Ten ways to build your portfolio.”  “Three tips for managing stress.”  “Nineteen ways to use your new iPhone.”  The onslaught of lists for self improvement, culture change, stress management, and weight loss abound, for nearly every area of life and work, including “Thirteen ways to improve your home office.”  But, what about high availability?  You only have so much time every week. So how do you make your HA solution more efficient and robust than ever.  Where is your list?  Here it is, fifty ways to make your high availability architecture and solution better:

  1. Get more information from the cluster faster
  2. Set up alerts for key monitoring metrics
  3. Add analytics.  Multiply your knowledge
  4. Establish a succinct architecture from an authoritative perspective
  5. Connect more resources. Link up with similar partners and other HA professionals
  6. Hire a consultant who specializes in high availability
  7. 100x existing coverage. Expand what you protect
  8. Centralize your log and management platforms
  9. Remove busywork
  10. Remove hacks and workarounds
  11. Create solid repeatable solution architectures
  12. Utilize your platforms: Public, private, hybrid or multi-cloud
  13. Discover your gaps
  14. Search for Single Points of Failure (SPOFs)
  15. Refuse to implement incomplete solutions
  16. Crowdsource ideas and enhancements
  17. Go commercial and purpose built
  18. Establish a clear strategy for each life cycle phase
  19. Clarify decision making process
  20. Document your processes
  21. Document your operational playbook
  22. Document your architecture
  23. Plan staffing rotation
  24. Plan maintenance
  25. Perform regular maintenance (patches, updates, security fixes)
  26. Define and refine on-boarding strategies
  27. Clarify responsibility
  28. Improve your lines of communication
  29. Over communicate with stakeholders
  30. Implement crisis resolution before a crisis
  31. Upgrade your infrastructure
  32. Upsize your VM; CPU, memory, and IOPs
  33. Add redundancy at the zone or region level
  34. Add data replication and disaster recovery
  35. Go OS and Cloud agnostic
  36. Get training for the team (cloud, OS, HA solution, etc)
  37. Keep training the team
  38. Explore chaos testing
  39. Imitate the best in class architectures
  40. Be creative.  Innovation expands what you can protect and automate.
  41. Increase your automation
  42. Tune your systems
  43. Listen more
  44. Implement strict change management
  45. Deploy QA clusters.  Test everything before updating/upgrading production
  46. Conduct root cause analysis exercises on any failures
  47. Address RCA and Closed Loop Corrective Action reports
  48. Learn your lesson the first time.  Reuse key learnings.
  49. Declutter.  Don’t run unnecessary services or applications on production clusters
  50. Be persistent.  Keep working at it.

So, what are the ideas and ways that you have learned to increase and improve your enterprise availability? Let us know!

-Cassius Rhue, VP, Customer Experience

Reproduced from SIOS