How to upgrade openstack across versions

OpenStack Is the de facto standard of China's private cloud

According to the tripartite statistical report ,2020 year , The scale of China's private cloud market has reached 951.8 One hundred million yuan , Year-on-year growth 42.1%, Private cloud in China IaaS The market share is about 45%. Private cloud providers are expected to continue to benefit from the sustained and rapid development of the cloud computing market .

In the ranking of private cloud enterprises in China , With OpenStack The proportion of open source technologies represented by 70%, Still in the mainstream . As the most widely deployed open source cloud infrastructure software in the world ,OpenStack after 10 The development of , It has formed a stable in China OpenStack Open source cloud ecosystem at the core . Despite the impact of container and other technologies in recent years , But it is becoming more and more abundant in the Chinese market 、 More and more mature user practice cases show that ,OpenStack Open source cloud technology still has enough vitality . However, with the iterative upgrading of product versions , Operation and maintenance of private cloud platforms of enterprises , The pressure of upgrading is gradually increasing .

OpenStack Why is it difficult to upgrade ？

although OpenStack At present, it has become the solution of most private clouds , But I did OpenStack Everyone knows , The version upgrade is OpenStack The biggest pain of commercial application . Two new versions a year, not to mention , With the version upgrade , The old operating system no longer supports , This makes users more afraid to upgrade easily . Although the follow-up OpenStack Try to solve this problem , But in most cases , Commercial version OpenStack In order to stabilize , Often choose a more fixed OpenStack edition , Continuous iteration and optimization , This brings about a big difference from the community version , And can't upgrade .

I've seen it before 360 An article from the company 《 Go across 7 Versions OpenStack Senseless fever upgrade in 360 The landing and practice of 》, Thousands of words describe OpenStack Upgraded history of blood and tears . For an Internet company with strong technical strength, it still costs so much , For traditional enterprise customers , This almost became the eternal pain in my heart . In the actual project , Due to the inability to achieve smooth upgrade , We often see that many customers deploy multiple sets of OpenStack Different versions of the environment , Each set needs to be equipped with a corresponding operation and maintenance team , This has created a dilemma between customers and cloud platform manufacturers .

“ I don't know the truth , Only the body in this mountain ”, Most solutions focus on OpenStack In itself , Today's article brings you a kind of Solutions from different perspectives , get to the root of sth. OpenStack The upgrade problem , No matter how many versions you cross , Can be solved perfectly .

How to break the situation ？

OpenStack The essence of being unable or afraid to rise is that there are business systems running on the cloud platform , So we essentially need to solve the problem in the upgrade process , Business system continuity issues , Then the simplest solution is to smoothly migrate the business system to the new cloud platform , In order to prevent everyone from losing patience to read the whole article , Let me start with the solution ：

1. There is no interruption in the process of business system migration ： Use the incremental migration mode at the host block level （ No OpenStack Native Live Migration）, Migrate the host from the original cloud platform to the new cloud platform ;

2. No agency way ： On the market 90% All the above migration schemes need to install agents on the source side , So if there are too many virtual machine users , The cost of installing agents is too high , For users, an agent-free way is needed to realize the smooth migration between cloud platforms ;

3. Disaster recovery and gradual migration ： Deploy the new version at the minimum size OpenStack, After the host is gradually migrated to the new platform , Rejoin idle compute nodes back to the new resource pool , At the same time, before the formal cut , The business system can perform unified exercises on the new cloud platform , Make sure the business is working properly , Data integrity ;

4. Rebuild management information ： Solved the problem of data , Tenants corresponding to cloud platform 、 The Internet 、 Resources such as security groups can be rebuilt on the new platform through export and import .

How to solve ？

HyperMotion It is a migration product based on cloud native , Business level hot migration based on block level differential replication . When we first designed the product , In addition to focusing on the use of cloud platform cloud native capabilities , Also added to the product “ Software defined storage controller ” layer , This way HyperMotion You can not only use your own data flow capabilities , It can also easily use the open data interface , So as to realize the communication between cloud environments “ The data flow ”. On the other hand ,HyperMotion It's a reverse design from the cloud , Different from traditional disaster recovery products , More in line with the needs of cloud platform regulation .

In this scenario ,HyperMotion utilize OpenStack Interface and Ceph RBD The interface realizes the hot migration of virtual machine , So it solved OpenStack The difficulty of its own version , The basic principle is shown in the figure below ：

First, in the old version OpenStack On , We use the virtual machine to build a source side synchronization proxy node , On the one hand, the node is responsible for calling the source side OpenStack API Interface , On the other hand, be responsible for working with Ceph RBD To communicate , Read block level difference data . Under this scheme , There are certain requirements for the source end network , The source side synchronization agent node needs to be able to access the source side synchronization agent and the server at the same time Ceph Storage networks .

Every time you synchronize , In order not to destroy OpenStack Own management system , Each snapshot should start from OpenStack Level scheduling , Then I'll go to Ceph Layer read data , This will not generate garbage data . After the data is read out , Through encryption 、 Transmit to the target platform by means of compression .

On the target platform , We need to use virtual machine resources to establish another synchronization agent , For receiving data . The received data is not written directly to Ceph in , Instead, the virtual machine is used to write directly Cinder On the disk of , The purpose of doing so is still consistent with OpenStack The need for regulation .

After each write , utilize Cinder Snapshot mechanism , Curing time point data , So we can... Before the formal cut , Conduct repeated migration exercises , Ensure that the business system can be used normally after cutover .

Last , During the cutover window , Complete the last increment , utilize HyperMotion And OpenStack API Deep docking , Specify... At the same time according to the specified specifications IP Address to start , Complete cutover .

In a word, summarize , Through no agency , Gradual migration , solve OpenStack Business continuity problems during version upgrade , It is an effective path we have summarized in a large number of private cloud migration practices , Share with you .

summary

As I am 《 The development trend of cloud migration and cloud disaster tolerance in the era of cloud primordial 》 mention , Based on cloud platform IT System , Data flow will become a normal demand , This flexible approach also effectively prevents manufacturers from locking .

except OpenStack upgrade , The scene can also Applicable to cloud platform replacement storage 、OpenStack Disaster recovery between enterprises and other business scenarios related to data flow . Not used for the bottom layer Ceph Cloud platform , It can also realize the arbitrary flow of data in the agent-free mode through the open data interface .

To paraphrase a famous saying ,“ There was no way in the world , More people are walking, and that's the way ”. Because of the abundant cloudy ecology in China , That makes us in Cross cloud platform data flow Explore some new scenes on , It has solved some pain points that cannot be solved by manufacturers and customers , Here, we also welcome more partners to join our data ecology plan , Share the dividends of the hybrid cloud era .