Six requirements for enterprise-level OpenStack (part I.)

The full text includes three parts:

• The first part
• Part II
• Part III

Introduction

OpenStack is the ideal foundation for building enterprise-class private clouds. It aspires to become the core of the next generation of cloud operating systems. However, it is not a complete cloud operating system at this time. Before it could become a cloud operating system, it would be better to think of it as the core of a cloud operating system.

Today, OpenStack is challenged in key areas to address these challenges, and OpenStack needs to be delivered through robust enterprise-class products. These products from the industry provide support, quick installation, daily management tools, and other essential things. If there are no vendors offering these products, OpenStack will never be widely adopted. OpenStack is not MySQL. It is similar to the Linux kernel, and you need a full operating system to run it, just like the Linux kernel. What exactly does enterprise OpenStack need? There are six key factors to this:

1. 99.999% API availability and scalable control plane
2. Robust management and security model
3. An open architecture
4. Hybrid Cloud Compatibility
5. Scalable, resilient architecture
6. Comprehensive support and services

If your company needs an enterprise-class OpenStack solution, read on to see what a true enterprise-class private cloud can and should offer. For the next two weeks, I'll write a series of blogs that include multiple sections, "6 big needs for enterprise-class OpenStack." Let's start by looking at the locations where OpenStack is located in the enterprise.

OpenStack in the Enterprise data center

Agility is a new keyword in the cloud, and DevOps is seen as the only way to achieve agility. Just as Linux provides a new platform for WEB applications, OpenStack provides an ideal platform for timely delivery of developer output within the enterprise. If OpenStack is simply "cheap VMware", it will be of little value to the business. Instead, OpenStack provides a very good example of how to build an elastic private cloud similar to the main public cloud such as Amazon (AWS) and Google Cloud Platform (GCP). Just as Hadoop pushes Google's MapReduce (plus its Reference architecture) into the public, OpenStack pushes the AWS/GCP model's infrastructure as a service (IaaS) to every user. It is the ultimate platform for DevOps within the enterprise.

Any discussion about DevOps will soon be confined to the quagmire of semantic debates. However, we all agree that barriers between application developers and IT infrastructure ops must be removed. Again and again, I heard a roughly identical story from several clients: "We are looking for our infrastructure OPS team with our long list of requirements for our new application." They told me that it would take 18 months and $10m to deploy the application. So we went to Amazon's website. We can't customize what they do for our app, so we have to change our application model, but we'll publish it right away. " This is because the intrinsic value and cost of Amazon are not really much related, but more to the resilient, developer-centric delivery model that responds to demand immediately.

OpenStack provides a similar platform within the enterprise. A private cloud can be built on a public cloud model, enabling developers to have centralized IT control and domination at the same time. Essentially, it is the best platform for convergence, which is the true value of the private cloud that OpenStack drives.

Why is agility so important?

I think it's obvious that agility is the driving force behind cloud computing. The rapid evolution of business needs has driven AWS to incredible growth:

All of this growth is new Web applications, or Microsoft says next-generation applications. The vast majority of these new applications are focused on new business values, typically including mobile, social, Web applications and big data. In fact, this type of application is growing so fast that both IDC and Gartner have started to track them:

According to this growth rate, the new generation of applications in the 2018 and traditional applications in the number of flat:

  

Next-generation applications will be a source of future competitiveness for most businesses, and they are already leading these companies to accelerate adoption of cloud-adapted processes and rethink their cloud strategy.   It is this phenomenon that has been observed, "said Craig Le Clari, a Forrester analyst." In just 10 years, 70% of the 1000 of Fortune's businesses have disappeared-because they cannot adapt to this change.    We have entered a time when business is at stake, and OpenStack will be the key to adopting agile and successful DevOps. Requirements 1-99.999% available control planes: Applications with high reliability require highly reliable cloud APIs

Continuing our discussion around Enterprise OpenStack, let's discuss how API availability is critical and how the next generation of applications needs to extend the cloud control plane.

The availability of cloud APIs

A key capability to transform into a new cloud and DEVOPS model is to provide the fault tolerance of cloud-native applications in an elastic cloud. These apps know that any server, disk, network device can go wrong at any time. They detect these errors in a timely manner and respond in real time. That's how Amazon and GCP work, and why they can run these services at a lower cost but with greater flexibility. To enable an application to adapt to different components in real time, the cloud API needs to be more available.

The throughput of your cloud Control Panel

The availability of APIs is not the only measure. The throughput of your cloud control plane (Throughoutput) is also critical. The control plane can be imagined chengyun the command center. This is the core of the Central Intelligence and orchestration layer. Your API is part of the control plane, and for OpenStack, it includes all the core projects, as well as the Daily cloud management system (usually part of OpenStack Enterprise Suite), and all the necessary ancillary services such as databases, OpenStack vendor plugins, and so on. The control plane of your cloud must be able to grow as the cloud grows. This means that, overall, you will get more throughput for API operations (object uploads/downloads, image uploads/downloads, metadata update waits).

And that's what a cloud operating system needs to provide.

99.99% API availability and control plane extensibility

Essentially, on the infrastructure of the 99.5% SLA, the cloud API required to use the application requires a 99.99-99.999% SLA if it is to run 99.99-99.999% SLA applications. In fact, you know, it's not easy to deliver 5 9 availability APIs because it allows only 5.26 minutes of unplanned downtime per year. Traditional high-availability methods, such as Master/Standby or multi-master electoral systems, often take a few minutes to failover, during which time your API endpoint (endpoint) is unavailable.

An enterprise-class cloud operating system can provide even seconds of failover in minutes to ensure that 99.999% or even 99.9999% (6 9 means that only 31.5 seconds of downtime per year) is available. Design, at a relatively low cost, using classic load balancing technology, your cloud control plane and API run in N-master mode, it is possible to achieve this availability. The N here is the number needed as the cloud grows:

This reminds me of the other end of the equation: you need your cloud control plane to grow as your cloud grows. You don't want to refactor your system when the cloud grows, and you don't want to use old methods to extend your API endpoints. When your system uses a high-availability scheme for master/standby or multi-master elections, there is actually only one API endpoint available at a time. This means that the server that is delivering the service will be a bottleneck for the system, which is unacceptable in today's scalable cloud world.

Instead, using the load Balancing mode, you can run the multi-master active API endpoint to extend your control plane while achieving high availability. This is the best way to make your cloud-native applications capable of real-time fault tolerance.

Now let's talk about daily cloud management and cloud security.

Requirement 2-Robust management: managing and securing Your cloud is cost-free (managing and securing Your Cloud isn't free)

You may have learned this, but it is very difficult to build a robust, manageable, and secure infrastructure within the enterprise. In theory, an enterprise-class private cloud can be delivered in an afternoon, and then it can be put into production at night. However, if you want your cloud to work smoothly in the future and you want it to be delivered very quickly, it will be helpful to choose an OpenStack version that has been designed to be quickly deployed, managed, and secured. Let's move on to this question in more depth.

Robust management

Installation is just the beginning of managing OpenStack. A true cloud operating system will provide an operations-centric suite of cloud management tools designed to ensure that the infrastructure team can deliver services successfully. These management tools will provide:

• Reusable schema models, typically using a reference network architecture to connect small clusters (pods) or groups (blocks) together
• Initial cloud installation and deployment
• Typical daily cloud operations tools, including logs, system measurements, and correlation analysis
• CLI and API for cloud Ops to use for integration and automation
• Cloud operations graphical interface for visualization and analysis

Many vendors ' attempts to solve the challenges of managing private cloud systems only stay on the installation. Installation is just the beginning of a long process, and if your cloud's daily management is cumbersome, it will be less important no matter how easy it is to install. As we all know, running a production system is usually not easy. In fact, in many ways, private clouds are more complex than traditional infrastructures. To simplify this complexity, cloud pioneers, like Google and Amazon, have adopted the design, deployment, and management of their cloud using multiple small clusters (pods), clusters (cluster), or blocks, on a scale. Google uses multiple clusters; Facebook uses several three reorganizations, but they are essentially the same: building clouds and data centers in a repeatable way like Lego bricks. Enterprise-class OpenStack-driven cloud operating systems will require a similar approach to organizing the cloud.

Once the cloud is installed and running, the cloud Ops people need a lot of tools to do operations, including event logs, system monitoring, and so on. Indeed, in an elastic cloud, events that were often critical in the past are not high-priority (such as server or switch failures). Then, your cloud can't be a black box. You need the data and information about how it will run day in, so you can solve specific problems when you need them, and more importantly, use correlation analysis tools to monitor recurring problems. A single server failure is not a big problem, but any common problems that occur on a large number of devices need to be quickly located and resolved.

And how does your cloud work? Not only do you need to know, but also all your tools need to know. Integration into existing systems is critical to the cloud. Any perfect solution will provide the API and CLI for you to integrate and automate. Just the CLI and APIs needed for OpenStack management are not enough. What if you manage your physical server clusters and cells? How do you get system detection and log data on demand not only from OpenStack, but also from Linux and other non-openstack applications? You need a single, unified interface to do cloud operations and management. Obviously, if you have this API, you also need to provide a GUI to make it easy to see the various styles and network detection data within the system.

Security model

The security model of the cloud is very important. A complete discussion of this topic is far from what this article can cover, but one thing needs to be clear: the enterprise needs the cloud to have an understandable security model, especially for the control plane. As I explained earlier, the API availability and throughput of your cloud control plane is critical to the fault tolerance of next-generation applications, and the security of your cloud control plane cannot simply be taken for granted.

You can easily transition to a go-to-center model, but it's not the same thing to do with centrality and extensibility. You can mix with both centralized and extended technologies, just as Google does. Placing your cloud control plane in one place will allow you to:

• Just need to go to a place to locate the error
• Never use a guess to determine the position of your control plane.
• Apply security Policy/domain to your cloud control plane
• Keep your control plane data completely separate from the data plane data

Among them, the last point may be the most important. You will not put your OpenStack database and the virtual machine on the same storage system. What if someone breaks through the Hypervisor and enters the imaginary opportunity? Or, conversely, what if someone breaks through the API and enters the control plane?

The best practice in the enterprise is to divide the different components into different security domains (often using multiple VLANs) and then configure different security policies for different security domains. The subregion slows down the hacker's intrusion, giving you time to detect them and then respond. Using a similar model in your private cloud security model is critical to ensuring your cloud security.

Cloud Management and security

As I said earlier, your cloud journey starts with the installation. Then you need a series of tools and security models to enable you to manage your cloud on a daily basis with great confidence. An OpenStack-driven enterprise-class cloud operating system needs to deliver these capabilities as much as possible.

Part 1 Summary

OpenStack is a powerful foundation for building next-generation private clouds for next-generation applications. Just, it is not yet a complete cloud OS, you need to have a partner to provide the complete solution. This series of logs will explain the 6 requirements of enterprise-class OpenStack private cloud, and today I talk about the highly available, extensible control plane, and robust security management tools.

In the next article, I'll talk about the open architecture and reduce vendor lock-in. Then, you'll explain extensibility and performance, and how to choose a partner that provides full service and support.

Original: The 6 Requirements of Enterprise-grade openstack,posted on April, by Randy Bias

Six requirements for enterprise-level OpenStack (part I.)