0.前言
RGW在ceph存储中的主要作用是提供S3和Swift的协议访问支持。Zipper工作主要是将RGW分为协议部分和后端部分。协议部分还是支持S3和Swift协议，包括身份认证、协议参数解析和op操作解析等等；后端部分主要是对接不同的存储，比如rados（zipper中变换为RadosStore，主要通过RADOS访问ceph集群）、DBstore（可以用 SQL，特别是本地 SQLite 数据库来存储数据）、DAOS（intel的存储平台）等。Zipper 还允许中间过滤器层转换操作、执行策略（如将不同对象导向不同存储）或执行数据和元数据缓存。
1.Ceph Zipper Project Overview
provide the feature-rich S3 protocal capabilities of ceph RGW for an array of non-ceph storage backends
-
- ISV storage sources(CORTX,DAOS,etc),Cloud Services(FSx Lustre)
- DB/File driver for compact deployments(Edge,Development)
Provide flexible, composable integration APl/framework based on stackable filter drivers
-
- Cache integration (In Progress)
- lO redirection
- Tiering/transitions across backends (RADOS, S3, CORTX)
2.Zipper project vision
- Bring the power and features of RGW's S3 implementation to other storage backends
- Enable RGW to be the S3 object storage interface across heterogenous storage backends
- Mix and customize functionality cleanly via stacked “filter" drivers (e.g.. caching)
一图胜千言
3.Zipper Architecture
此处主要是数据结构和处理结构的变化，由于rgw中可以选择是否使用RADOS进行存储数据，所以此处的bucket、user、object一同进行变换。
- 个人以为之前的代码写的太乱，尤其是rgw_rados的代码，堆积了几万行。
4.Zipper File Layout
common文件：
- rgw_sal.h,rgw sal.cc：都是一些纯虚函数的定义，包括driver、user、bucket、object等
- rgw_sal_store.h,rgw_sal_filter.h,rgw_sal_filter.cc：定义了一些基础的store和filter。
具体实现文件：
- rgw_sal_<impl>.h rgw_sal_<impl>.cc：具体类的实现。比如bucket、object等。
- store/<impl>：store和filter的具体实现
参考：Ceph.io — Ceph Virtual 2022
