As mentioned in the " Ceph Analysis" Series II-Overview of Ceph, one of the reasons for paying attention to Ceph is that the OpenStack community attaches importance to Ceph. Therefore, this article will briefly introduce the value of Ceph in OpenStack, and compare Ceph and Swift.
6.1 Ceph's status in OpenStack
For an IaaS system, the storage-related parts are mainly block storage service module, object storage service module, image management module and computing service module. Specifically for OpenStack, it corresponds to the four projects of Cinder, Swift, Glance and Nova [ 1 ].
In the block storage service part, Ceph is currently the default storage backend for the Cinder project. As mentioned earlier, Red Hat has also used its influence in the KVM / QEMU community to directly integrate the RBD driver into QEMU. In this way, the performance of virtual machine access to block devices based on RBD will be optimized.
In the object storage part, Swift is the object storage implementation solution that comes with OpenStack. But Ceph has also become Swift's strongest competitor. Swift is currently considering using Ceph as its storage backend. The story about Ceph and Swift will be detailed in Section 6.2.
In the image management section, Glance currently supports Ceph as its own local image file cache.
In computing services, United Stack is currently promoting Ceph FS as a local file system for Nova compute nodes.
Overall, Ceph is in fact the most popular open source storage solution in the OpenStack ecosystem. This can be confirmed by the author's personal experience at the OpenStack 2013 HongKong Summit. At present, leading enterprise IT vendors represented by HP, Dell, Intel, etc., as well as several emerging vendors in the OpenStack community represented by Mirantis, eNovance, and United Stack, regard Ceph as an important and even preferred open source storage solution.
The author believes that the reason why Ceph was quickly attracted attention in the OpenStack community after years of tepid birth, in addition to some other obvious advantages, should be related to its ability to support unified storage. This feature is exactly what the OpenStack community needs.
One of the guidelines for the design of the OpenStack project is flexibility and scalability. At the same time, the background of each of its member projects is also different. This leads to differences in the choices made by each project when it comes to storage systems. However, this situation will inevitably lead to certain challenges in the deployment and operation of OpenStack. Especially for some small-scale OpenStack deployment instances, if block storage, object storage, image cache, and local storage of computing nodes are used in three or four different back-end solutions, on the one hand, the deployment is very troublesome, and On the one hand, the follow-up work of the operation and maintenance personnel is also very tedious. In this case, if you can use Ceph as a unified storage backend, you can really alleviate this problem. Of course, this is just the author's blunt statement. Any technology choice will inevitably have complex reasons behind it, and the information here is for reference only.
6.2 Ceph and Swift: stories that must be told and comparisons
First, a brief introduction to the ins and outs of the Swift project, so that everyone can better understand the characteristics of this project and the reasons behind it. The information about Swift here is mainly from [ 2 ].
Swift first originated in 2008. It was originally a back-end system developed internally by Rackspace to support its public cloud object storage business. At that time, Amazon's S3 service was already very popular, so Rackspace decided to develop Swift in response to the corresponding business. It is for this reason that Swift's design goal is very pure, that is, an excellent object storage system comparable to S3. Other requirements are purely redundant, so they are not considered by Swift developers at all.
The development of Swift lasted roughly one year and was successfully launched and operated on Rackspace. Since then, the OpenStack project was officially released in 2010. Rackspace contributed Swift, and NASA contributed Nova, and the two became the first two OpenStack projects. Since then, several core members of the Swift development team have started their own businesses and established SwiftStack, which is still active in the relevant community.
It can be seen that Swift is a typical open source project originated from within the company as a formal product development. From this point of view, Swift is very different from Ceph. It is for this reason that Swift has a unique advantage: there is no shortage of startup users, and there are large-scale deployment application cases in the production environment from the beginning. In fact, the relatively mature and many application cases in the web scenario is an advantage that the Swift community still repeatedly emphasizes.
Technically, the characteristics of Swift are mainly reflected in the clear design goal, which is to be a pure object storage system, so it will not consider the unified storage feature emphasized by Ceph. At the same time, in order to facilitate integration with other projects and applications, Swift chose the Python language for development.
In contrast, Ceph considers object storage, block storage, and file system storage capabilities at the same time, and the most widely used scenario in OpenStack is actually block storage. At the same time, when Ceph chooses the development language, it is likely that the main consideration is the performance factor, so he chose the C ++ language. The fact that it can be used in block storage scenarios also partly confirms that its performance is indeed superior.
It can be seen that the difference between Ceph and Swift is essentially caused by its background and application goals. It is not fair to compare the two and make technical judgments.
In fact, as two excellent representatives of open source distributed storage systems, there are many similarities in the design and features of Ceph and Swift:
First, both emphasize good scalability, so both adopt a centerless structure. It's just that there is a metadata server in Swift's architecture, but it solves its reliability and performance concerns as much as possible through multi-node expansion.
Second, both can provide configurable high reliability. In both clusters, the number of data backups can be selected, and in the common production environment, the three backup method is also used.
Third, both emphasize automated cluster management. Swift also introduces automated cluster maintenance capabilities.
This shows that simply emphasizing that one of the two is better is unreasonable and has no practical significance.
Of course, in actual use, after all, you still need to choose a program. Combining the opinions in [ 3 ], the author believes that the appropriate choice may be as follows:
* If you need a pure object storage system, choose Swift;
* If you need a pure block storage system, you can only choose Ceph;
* If it is a small-scale OpenStack deployment solution that wants to control the complexity of the system, choose Ceph;
* If it is a large-scale system with large business requirements for block storage and object storage, you can consider separating the two and adopting Ceph and Swift respectively.
So far, this series of articles has basically completed the introduction of Ceph technical content. The latter article will mainly focus on some of the thinking of the author in the process of learning Ceph, for interested readers to comment on.
