OpenStack needs to solve five major problems in building enterprise private cloud
OpenStack has become a trend, but the release version of OpenStack is not perfect yet. To build a private cloud, enterprises must fully understand the shortcomings of the release version of OpenStack in advance, and seek the help and cooperation of professional OpenStack providers. Only in this way can we take advantage of OpenStack and build a private cloud that maximizes the competitive advantage of enterprises.
How does OpenStack work well in enterprises? What other problems need to be solved? How can OpenStack be used well in enterprises? Developers think it is a problem of using posture; Users think that it should be stable and reliable, and should not be down for long; The boss thinks that the development and operation and maintenance of more cattle can be solved.
In fact, the problems of OpenStack in commercial use are mainly in the following five aspects: stability, integrity, high availability, ease of use, dual live and disaster recovery.
Let's start with stability. For a good product, performance is not the first element, but stability is the most important for the enterprise.
a. OpenStack is far from sufficient in scalability and stability, and needs careful polishing.
From dozens of units to thousands or even tens of thousands of units, can we continue to work steadily without problems? Practice has proved that with the expansion of the scale, the overall architecture needs to do enough work in terms of stability.
For example, it is necessary to design multiple NOVA APIs and multiple images, load balancing, node high availability, and database concurrent responses.
In addition, Nova, Swift, Cinder and Neutron, the most talked about upgrade problem in the community, use their own databases to store configuration information. To upgrade, multiple database schemas need to be modified, and hot upgrade is not possible (the upgrade problem has been improved after version H).
For another example, an enterprise encountered a nightmare experience when deploying a network service (Neutron), and had to rewrite the code of network components to meet the requirements of large-scale applications.
b. OpenStack lacks integrity.
A mature cloud platform should provide computing, storage, network, security, database, big data, middleware, DevOps, monitoring, operation and maintenance and other cloud products. OpenStack can only provide three cloud products: computing, storage, and network. If enterprise customers need information security protection products, they must help themselves with the information security platform and integrate third-party products. Another example is big data analysis. Through Sahara, Hadoop clusters can be rapidly deployed. How can we get through the account, security, management and O&M monitoring systems between OpenStack and Hadoop?
c. OpenStack's virtual machine level high availability is not good.
At present, there is no official statement that OpenStack supports high availability at the virtual machine level. This feature was proposed in the Folsom version, but was subsequently abandoned.
At present, OpenStack has an incubation project, Evaluate, which is used to provide OpenStack with virtual machine level high availability support. At present, Evaluation can only be initiated manually by the administrator. Evaluation does not consider the deployment attributes of the VM, resulting in the failure of the resource scheduling policy. The change of host name will cause all virtual machines to be deleted by mistake during the restart of nova compute. This problem is mainly caused by the cleanup mechanism of Evaluate. This bug was fixed in version L.
d. The ease of use of OpenStack is not good enough.
With FUEL, you can quickly install OpenStack, but many configuration operations still need command lines, which is far from automatic deployment and one click delivery. Another example is the CEPH distributed storage system widely used on OpenStack, which has not yet achieved interface based operation and configuration. In addition, OpenStack lacks a common basic version.
The use of OpenStack will not be locked by the manufacturer, but there are more than 20 customized versions of OpenStack that can be downloaded from the manufacturer. The customer's choice is very important.
e. Double live and disaster recovery.
Large enterprises have high requirements for business continuity, and the key core businesses have the requirements of local dual viability and remote disaster recovery. Live in one city means that the user's key business system runs in two data centers in the same city at the same time and provides services for users. When the application system of one data center has problems, the application of another data center will continue.
Remote disaster recovery, just as its name implies, is to build one or more sets of the same application or database in different regions to take over immediately after a disaster. We can see that although OpenStack also has single site (Smaug+Cinder) and cross site (Smaug+Swift) backup and recovery solutions, it is far from the real business viability and remote disaster recovery of enterprises.
Another example is Tricircle's cross data center cascading, which still requires Cinder to rely on the ability of the storage backend to carry out disaster recovery. Tricircle itself is just a forwarding relay to find the correct site for users to operate. It cannot achieve cross data center disaster recovery function itself, which is different from the SRM of VMWARE.
We can see that there is still a gap between OpenStack and VMware in terms of function support and specific details, and we still need to make continuous progress to do better. But OpenStack, as an open source management framework, is designed with good intentions. With the use and development of OpenStack in enterprises, its maturity will be promoted and accelerated.
The last is the operation and maintenance automation. In the large-scale cloud operation and maintenance scenario, it is necessary to trigger the highly repetitive work based on the intelligent decision of monitoring data to achieve the operation and maintenance capability of unattended automatic operation, which is yet to be explored by OpenStack.
