Six requirements for enterprise-class OpenStack (part 3rd): Resilient architecture, global delivery

The full text includes three parts:

• Part I: API high availability and management and security model
• Part II: Open architecture and Hybrid cloud compatibility
• Part III: Resilient architecture and global delivery

Requirements 5-scaling, resiliency, and performance

Enterprise-class content is rich. In the past, enterprise-class was often associated with high-quality systems that were highly reliable, scalable, and performant. Gradually, the enterprise-level implications began to evolve into "cloud-level (Coud-grade)" or "network-scale (Web-scale)". What I want to say is that the need to deliver a high-quality system has changed greatly as the IT era evolves into next-generation applications and companies adopt new IT models.

One of my favorite examples is Hadoop. Hadoop comes with a reference architecture that includes the use of commercial servers, commercial disks, and no RAID. Last time you saw an enterprise infrastructure scenario that didn't use hardware-level data protection or when? Of course, although I have seen it, it is not necessary for us to run Hadoop on the Advanced blade server that connects the fibre storage network. Even Microsoft Exchange began recommending the evolution from RAID to JBOD, which instead relied on the application layer for fault tolerance.

Let's take a closer look at the three requirements of enterprise-class OpenStack.

Scalability and Performance (Scalability & performance)

Scalability is a feature of the system's ability to meet growing system size and load requirements. Performance is a dimension of the throughput of a single resource in the system rather than the system itself. Perhaps Amazon's CTO, Werner Vogels, said the best:

"When we add resources to our systems, their performance increases in proportion to the increased resources, and we can say that their services are extensible." “

In many ways, OpenStack itself is a highly scalable system. It is designed as a loosely coupled, message-based architecture-these technologies are applied and validated in systems that are already available in a variety of intermediate-to-advanced extensions, and they can also be adapted to small-scale deployments. The problem is the design decisions you make when you configure and deploy OpenStack. Some of the default configurations, as well as the plugins and scenarios of many vendors, are not designed with extensibility in mind. As you can see from the previous article, a reference architecture is critical to deploying a hybrid cloud. You need to be sure that the Reference architecture of the enterprise-class product you choose has the scalability and performance in mind when selecting its various components and configuration items.

A complete scale and performance test is beyond the scope of this article; However, we need to be aware of the number one problem that most users encounter: Network performance and scalability.

The network that OpenStack uses by default is a semi-finished product (OpenStack default Networking is a bust OpenStack)

OpenStack Computing (Nova) has three intrinsic default network models: Flat,single_host and Multi_host. These three network models are unacceptable to most businesses. In addition to these default network models, you can also deploy the OpenStack network (Neutron), which uses a highly plug-in architecture that supports a number of different vendor plugins to manage physical network devices and network virtual appliances (so-called software-defined networking SDN).

Next I'll turn to the Nova default network model. I will try to be as simple as possible, but I would be happy to do so if I had the opportunity to elaborate in more detail in the future. All floating IP addresses in the flat and Multi_host network models require a shared VLAN. This requires that your physical network use the STP protocol, which is a dangerous way to be famous when you need a high-speed network. I asked the attendees at several meetings: "How many people think that STP is bad?" "And then almost everyone in the meeting room raised their hands.

Perhaps more importantly, the flat and Multi_host network model requires network traffic to be routed from your public IP address to the Hypervisor node through the boundaries of your network. This is unacceptable in any modern enterprise. Here are the Multi_host:

When you use the Multil_host network model, you need to be able to deploy the code to Hypervisor, and sometimes that may not be a good thing, but you're not so lucky on ESXi or Hyper-V platforms.

In contrast, the problem with the Single_host model is that it takes a x86 server as the hub of the core network, and the network traffic between all VLANs and the Internet passes through it. Basically, you can throw your high-performance switch into the Trash, because your network's maximum bandwidth will depend on that Linux server. Again, this is not a way to be acceptable to the web. But it's fair to say that OpenStack's rivals are in a similar way. The following is the Single_host model:

All of these methods have basic extensibility and performance issues. This is why there was a neutron later.

A timid man does not fit. Neutron (depending on OpenStack Neutron not for the faint of heart)

Until September 2013, as described in the mailing list sent to OpenStack ops by Scott devoid of Argonne national Labs, it seems that Neutron still have serious problems. When I write this article, Neutron supports Single_host and flat modes, but Multi_host mode is not supported. Obviously, we will see the replacement of the Multi_host mode in the Juno version (translator Note: DVR-distributed virtual router), although this feature has been absent for a long time.

It should be said that Neutron has made considerable progress, realistically speaking, many of the problems reported today are derived from poorly programmed plugins. It also means that to successfully use Neutron, you need to use the Neutron core functionality plus those plug-ins that consider extensibility and performance at design time. Plus, your cloud OS vendor should have some proven, large-scale deployment, and use an exhaustive testing framework to try to eliminate some of the potential problems in the network as much as possible.

I can say more about the performance and scalability of enterprise-class OpenStack-driven products. However, the above should make it clear to you that you need to confirm with your supplier that they have understood and resolved these issues.

More importantly, regardless of which vendor you use, they must be able to provide a detailed multi-cabinet reference network architecture. Without this architecture, you have to expand from one cabinet to the next, relying entirely on the effective or ineffective so-called guarantees of your suppliers.

Elasticity (elasticity)

The infrastructure is never really resilient, but its features enable elastic applications to run on it. An elastic cloud that needs to be designed for every resource, such as virtual machines, block storage, and object storage, is as low-cost as possible. This is directly related to the Jevons paradox (Jevon's Paradox), who says that as technology advances, efficiency gains will increase the speed with which the technology is adopted.

Simply put, as the relative cost of each component in the system continues to fall, the application can use more resources to ensure fault tolerance, and more resources can be used to scale on demand. Essentially, if the cost of each component and resource is as low as possible, you can make the resource pool large and buy more capacity. The main elastic cloud, like Google, Amazon, and Microsoft, is already offering this feature, which is what you need to achieve a hybrid cloud within your enterprise.

Enterprise OpenStack will lead you to the future by supporting elastic applications, scalability, and performance at the same time. Beware of the OpenStack-powered cloud operating systems that require you to use fibre storage networks and blade servers. That era has passed, as we have seen on Hadoop.

Requirement 6-Cloud support, training and service model required for global implementation (cloud supports, Training & Services Model for global enablement)

Assuming your business is a global enterprise, planning to deliver next-generation cloud-native applications on your private cloud, public cloud, and hybrid cloud, you'll need vendors who can support your global business, have international operations, and support 24x7x365 environments.

Train your IT administrator to become a new cloud administrator

IT admins are transitioning to cloud admins. This is a deep-seated and continuous change within the enterprise. They need to learn a whole new set of technologies, as well as other skills, to adapt to the cloud era. When you evaluate an enterprise-class private cloud provider, you need to find a company with excellent training capabilities, not only at the OpenStack level, but also at other specific cloud OS product levels. Most importantly, when evaluating a vendor that can help you upgrade your team's technology, be aware that they are not just here to show you how to develop or install OpenStack on OpenStack.

The really needed operations-centric training should focus on:

• A typical OpenStack architecture and a specific product framework
• Advantages and disadvantages of various architectures and plug-in/drive selection
• scalability, compatibility and performance issues and sizing
• Common "All-stack" problem locating and solving method
• Show developers how to use the cloud
• Understanding cloud-Native application models

Cloud Support Model

No matter how good your IT team is, you need a trusted support team-a team that can end-to-end support for your entire system. Please confirm that your supplier has prior experience in supporting high-transaction 24*7 environments. Please make sure they have "full stack" support capability. Do they have the ability to debug Linux kernel issues? Do they have the ability to help with Hypervisor selection, solving network architectures and performance problems? Do they understand storage in depth? The cloud is an integrated system in which compute, storage, and networking are all very fundamental to each other. Your vendor needs to know much more than how to configure and develop OpenStack. They have to be cloud full stack experts. You must make this request to them.

Global service Delivery (Delivery)

Delivering the cloud through global services is not a simple matter, small or large. This delivery is much more than just a deployment requirement. It needs to understand the culture everywhere and needs to be able to understand the unique requirements of each region. For example, do you know that the fear of electricity in most data centers is greater than the fear of space, and the opposite is the case in Japan? There, it is a major advantage to be able to use as little space as possible. Their demand for space is very unique.

Your cloud OS vendor needs to have a record of international deliveries and a global network of partners who can help in specific areas.

Conclusion (conclusion)

OpenStack is an exciting and scalable infrastructure to build the next generation of resilient clouds, but it's not perfect. All open source products that are similar to it are not perfect. Instead, each product is a core of a cloud operating system that can be used to deliver a more complete, proven enterprise-class cloud operating system (Cloudos). You need an experienced business provider to deliver your cloud operating system, whether it's using OpenStack or any other solution, and I want you to take these needs into your heart.

I hope you will enjoy this series of articles. To summarize, we talked about six major needs:

1. 99.999% API availability and Scalable cloud Control Panel
2. Robust management and security model
3. Open architecture
4. Hybrid Cloud Compatibility
5. Extended and resilient architectures
6. Global support and delivery

When you evaluate each supplier, make sure you know exactly how much they can meet these needs.

Original: The 6 Requirements of Enterprise-grade OpenStack, part 3,posted on May 6, by Randy Bias

Six requirements for enterprise-class OpenStack (part 3rd): Resilient architecture, global delivery