Shulou(Shulou.com)06/01 Report--

This article mainly introduces the example analysis of Ceph, has a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, the following let the editor take you to understand it.

Ceph originated in 2003, and the period from 2003 to 2007 is the research and development period of Ceph. On July 3, 2012, Sage announced the release of Argonaut (version 0.48), which is a very important milestone in the release of Ceph. The application of Ceph in China began to strengthen in 2014, and the architectural design concept of Ceph has been highly sought after in China since then.

Ceph provides back-end storage for cloud platforms, and I think this goal and positioning is very clear. Ceph started out as a back-end storage for OpenStack, which I think is a very good way to cut in. Excerpt from a community interview on the eve of Cephalocon APAC 2018: "although there is no official conclusion on the market size of Ceph, according to Sun Qi, co-founder of Ceph China Community, 70% or 80% of the cloud platforms in the market use Ceph as the underlying storage platform."

Ceph adopts the decentralized design of Crush algorithm, and the underlying layer is based on object storage. Ceph started with the popular object storage in the industry as a starting point, and later provided block and file storage capabilities. Ceph provides object, block, and file storage capabilities in a unified system.

Ingenious design and full-featured features are the highlights of Ceph, but we need to see the potential dangers. As a colleague, I have recently studied and learned about the famous Ceph, and found that the more I know, the less confident I am in the application of Ceph in specific areas, such as databases.

Ceph officially advertises that Ceph has three characteristics: high reliability, high performance and easy expansion. I don't know much about the high reliability of Ceph, so I think it can be achieved in such a harsh scenario as non-database. Easy scalability is an essential feature of distributed systems, and I'm sure Ceph is doing a good job. I have reservations about high performance. Why do you say that? can Ceph run the database as a back-end storage? If we have friends who have run through the database on Ceph, we can have a good exchange. Next, it focuses on the unsatisfactory performance of Ceph.

The underlying layer of Ceph is based on object storage and is just used for object storage function, which is understandable. However, with the addition of block and file storage, the underlying storage is still object-based, and the limitations of this approach are very obvious.

Let me give you an example and you may understand. FastDFS is currently a distributed file storage system similar to Kev-Value, which does not store large files in fragments, but can only be accessed by proprietary API, which is concise and efficient. If FastDFS wants to provide a general file interface (the client can mount to the local standard file system) and store large files in pieces, the most convenient way for server is FastDFS + file directory service (file metadata management). Will the performance of this way of building blocks be good? Please make your own assessment.

Decentralized Crush algorithm or consistent hash algorithm is highly respected in the storage industry, and I think it is better to look at this issue dialectically. Decentralized distributed algorithms will inevitably lead to greater system complexity, which can be confirmed by the time span from the release of the first version of Ceph to the launch of a stable available version. In addition, the decentralized algorithm is more effective for object storage, but for other storage methods, it may be very chick or even inappropriate. For example, the file storage method, because this way is bound to introduce the central node to manage file metadata, at this time through the algorithm to achieve decentralization has lost its original meaning.

Finally, let's talk about the write magnification problem of Ceph. "3 in the case of replicas, when the amount of data writing is large, the WAF (write magnification factor) gradually converges to 6, which is in line with our reasoning above WAF=2*N (N is the number of copies); but when the write object is very small, the WAF will be very large."

Thank you for reading this article carefully. I hope the article "sample Analysis of Ceph" shared by the editor will be helpful to you. At the same time, I also hope that you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.