ceph的压缩、加密、纠删码

ceph的压缩、加密、纠删码

① 压缩（Compression ）
对ceph压缩的一写描述：
（1）The Ceph Object Gateway supports server-side compression of uploaded objects, using any of Ceph’s existing compression plugins.CEPH对象网关支持使用Ceph现有的压缩插件中的任何一种来支持上传的对象的服务器端压缩。

Compression can be enabled on a Zone’s placement target by providing the --compression= option to the radosgw-admin zone placement modify command.通过为radosgw-admin zone placement modify命令提供--compression = <type>选项，可以在区域的展示位置上启用压缩。

The compression type refers to the name of the compression plugin to use when writing new object data. Each compressed object remembers which plugin was used, so changing this setting does not hinder the ability to decompress existing objects, not does it force existing objects to be recompressed.压缩类型是指写入新对象数据时使用的压缩插件的名称。 每个压缩对象都会记住使用了哪个插件，因此更改此设置不会妨碍解压缩现有对象的能力，也不会强制重新压缩现有对象。

This compression setting applies to all new objects uploaded to buckets using this placement target. Compression can be disabled by setting the type to an empty string or none.此压缩设置适用于使用此放置目标上载到存储桶的所有新对象。 可以通过将类型设置为空字符串或none来禁用压缩。

While all existing commands and APIs continue to report object and bucket sizes based their uncompressed data, compression statistics for a given bucket are included in its bucket stats.可以通过bucket stats来查看压缩数据的信息

参考链接：COMPRESSION

（2）v12.2.0 Luminous Released Major Changes from Kraken: BlueStore supports inline compression using zlib, snappy, or LZ4. (Ceph also supports zstd for RGW compression but zstd is not recommended for BlueStore for performance reasons.) 从Luminous开始，ceph支持zlib、snappy、LZ4以及针对rgw的压缩zstd，根据官方文档的描述，这些压缩方法都是以插件的形式提供。

参考链接：v12.2.0 Luminous Released

（3）

1. 目前从k版本开始支持compression，目前支持zlib、snappy、zstd，注意从ceph version 12.0.0开始才加入了zstd插件。

2. 注意配置的时候如果设置的插件不存在或者名称错误，则不启用压缩特性。
3. 目前压缩特性只对data_pool这个pool的数据有效。
4. 可以实时变更插件类型而不影响之前写入的数据访问。（写入object的时候每个object都有一个内置变量标记当前object使用的压缩插件类型。）
5. compression特性对用户透明，用户是无法感知压缩功能是否存在的

参考链接：compression功能测试 by_秦牧羊

总结：压缩是在object上传到bucket时，通过指定压缩插件类型实现对object的压缩。object会专门记录使用的插件类型，不会因为更改压缩插件而被重新压缩。压缩是在服务器端实现的，插件的指定是通过“radosgw-admin zone placement modify”命令实现的

---

② 加密（Encryption）
对ceph加密的描述：

（1）At the moment, none of the Ceph authentication protocols provide secrecy for messages in transit. Thus, an eavesdropper on the wire can hear and understand all data sent between clients and servers in Ceph, even if it cannot create or alter them. Further, Ceph does not include options to encrypt user data in the object store. Users can hand-encrypt and store their own data in the Ceph object store, of course, but Ceph provides no features to perform object encryption itself. Those storing sensitive data in Ceph should consider encrypting their data before providing it to the Ceph system.目前，Ceph身份验证协议没有为传输中的消息提供保密性。 因此，线上的窃听者可以听到并理解Ceph中客户端和服务器之间发送的所有数据，即使它不能创建或更改它们。 此外，Ceph不包括对对象存储中的用户数据进行加密的选项。 当然，用户可以手动加密并将自己的数据存储在Ceph对象存储中，但Ceph本身不提供执行对象加密的功能。 那些在Ceph中存储敏感数据的人应该考虑在将数据提供给Ceph系统之前对其数据进行加密。

疑问：ceph中没有提供加密机制？

参考链接：USER MANAGEMENT

（2）Mirantis在Ceph L版本贡献了加密功能，当前 Ceph 中的加密功能为 Server-Side Encryption，共支持三种加密模式：

• Customer-Provided Keys：对应于 AWS S3 SSE-C 模式，即这种模式下，Client 端负责生成和管理密钥，若要对所上传的对象进行加密/解密处理，需要 Client 在发送操作请求时，在请求头中加入加密/解密相关的请求信息。Server ( 即 RGW )只负责对 Object 进行加密/解密处理，不会对 Client 所传入的密钥进行管理。
• Key Management Service：对应于 AWS S3 SSE-KMS 模式，何为 KMS ？即 Key Management Service。这种模式下，Server 端整合了专门的密钥管理服务，来提供密钥的生成和管理功能。对于 AWS S3 来说，是通过 AWS KMS 来提供服务的；对于 Ceph RGW 来说，当前只整合了 OpenStack 的 Barbican，并结合 Keystone，来提供密钥的生成和管理服务。
• Automatic Encryption(For Testing Only)：此种模式只用于 RGW 加密功能的测试

整合了 Barbican 和 Keystone，RGW SSE-KMS 加密模式的工作流为：

参考链接：涨姿势 | Ceph对象存储加密
（3）Note：The cephx protocol does not address data encryption in transport (e.g., SSL/TLS) or encryption at rest.cephx 协议不解决传输加密（如 SSL/TLS ）、或者存储加密问题。

参考链接：ceph体系架构——HIGH AVAILABILITY MONITORS

（4）The Ceph Object Gateway supports server-side encryption of uploaded objects, with 3 options for the management of encryption keys. Server-side encryption means that the data is sent over HTTP in its unencrypted form, and the Ceph Object Gateway stores that data in the Ceph Storage Cluster in encrypted form.Ceph对象网关支持上传对象的服务器端加密，有3个用于管理加密密钥的选项。 服务器端加密意味着数据以未加密的形式通过HTTP发送，并且Ceph对象网关以加密形式将数据存储在Ceph存储群集中。

与前面的描述一致，有三种服务器端加密。（1）中所提的未提供加密，是指未提供客户端到服务器端的加密，数据从客户端传输到服务器端，是直接未被加密到的。只有数据存储在了ceph集群中，才能按照配置实现数据加密。

• CUSTOMER-PROVIDED KEYS
  In this mode, the client passes an encryption key along with each request to read or write encrypted data. It is the client’s responsibility to manage those keys and remember which key was used to encrypt each object.This is implemented in S3 according to the Amazon SSE-C specification.As all key management is handled by the client, no special configuration is needed to support this encryption mode. 客户端自己为读写加密数据提供密钥，这些密钥都是由客户端自己管理，密钥管理的难度大。

• KEY MANAGEMENT SERVICE
  This mode allows keys to be stored in a secure key management service and retrieved on demand by the Ceph Object Gateway to serve requests to encrypt or decrypt data.This is implemented in S3 according to the Amazon SSE-KMS specification.In principle, any key management service could be used here, but currently only integration with Barbican is implemented.该模式允许密钥存储在安全密钥管理服务中，并由Ceph对象网关根据需要进行检索，以服务请求来加密或解密数据。这在S3中根据Amazon SSE-KMS规范实现。原则上，任何密钥 管理服务可以在这里使用，但目前只与Barbican集成。

• AUTOMATIC ENCRYPTION (FOR TESTING ONLY)
  A rgw crypt default encryption key can be set in ceph.conf to force the encryption of all objects that do not otherwise specify an encryption mode. 直接在ceph.conf中设置

rgw crypt default encryption key = 4YSmvJtBv0aZ7geVgAsdpRnLBEwWSWlMIGnRS8a9TSA=

Important： This mode is for diagnostic purposes only! The ceph configuration file is not a secure method for storing encryption keys. Keys that are accidentally exposed in this way should be considered compromised.此模式仅供诊断之用！CEPH配置文件不是用于存储加密密钥的安全方法。以这种方式意外暴露的密钥应该被认为是妥协的。

参考链接：ENCRYPTION

总结：ceph提供服务器端加密，有三种方式：Customer-Provided Keys、Key Management Service、Automatic Encryption。其中只有第三种方式是通过修改ceph.conf实现的，第二种是整合OpenStack 的 Barbican。

---

③ 纠删码（Erasure Code）
总体描述：
（1）object原本通过副本冗余来实现高可用性和数据一致性，object通过PG映射到一个OSD set中，如果副本数为3，则有3个OSD。object首先被写到主OSD上，再被主OSD写到其他次OSD上。有了纠删码后object被划分成K个数据块，并按照一定的方法计算出M个编码块，然后通过PG映射到OSD set中。原来的Object会产生K+M个chunk。第一个chunk存在Primary ods上，剩下的K+M-1个chunk，Primary osd会依次发送到相应的osd上。（是否使用纠删码，需要命令指定）

$ ceph osd pool create ecpool 12 12 erasure
pool 'ecpool' created
$ echo ABCDEFGHI | rados --pool ecpool put NYAN -
$ rados --pool ecpool get NYAN -
ABCDEFGHI

（2）有纠删码的机制下，对K+M个chunk，只需要读速度最快的k个chunk就好，读到编码块，可以恢复出缺失的数据块。

（3）纠删码是通过Erasure code profiles（配置文件）实现的，通过配置纠删码使用的plugin，可以利用不同类型的纠删码机制实现数据的一致性和高可用性。纠删码插件包括：Jerasure erasure code plugin、ISA erasure code plugin、Locally repairable erasure code plugin、SHEC erasure code plugin。

创建纠删码配置文件，并未某个pool指定纠删码配置文件：

$ ceph osd erasure-code-profile set myprofile \
   k=3 \
   m=2 \
   ruleset-failure-domain=rack
$ ceph osd pool create ecpool 12 12 erasure myprofile
$ echo ABCDEFGHI | rados --pool ecpool put NYAN -
$ rados --pool ecpool get NYAN -
ABCDEFGHI

参考链接：
Ceph中纠删码的读写过程与缓存分层 （最佳参考）
Ceph纠删码编码机制 （存储容错机制简述）
Ceph 纠删码介绍 （官网文档翻译）
体系结构 （纠删编码）
Ceph分层存储分析 （分级缓存的两种模式）
ERASURE CODE