对象存储跨机房容灾调研

概述

随着机房的增加和客户对可靠性的要求提高,我们需要提供数据的跨机房容灾,本文档结合Ceph Radosgw的实现描述对象存储的跨机房容灾。

当前状况

当前应用中,每个机房的Ceph都是独立的cluster,彼此之间没有任何关系。

多个机房都独立的提供对象存储功能,每个Ceph Radosgw都有自己独立的命名空间和存储空间。

这样带来两个问题:

1,针对Radosgw来说,我们的业务没法提供统一的命名空间;

2,没有机房级别的容灾,若一个机房Radosgw无法访问,则机房提供的对象存储瘫痪;

方案

针对上述中的情况和需求,Ceph的Radosgw原生支持的联合架构,支持Region,Zone级别的备份同步,能很好的解决这个问题。

Ceph要求

  • 版本Ceph version 0.67以后即可,我们当前使用的0.94.5支持该feature
  • 每个Ceph cluster必须配置启动RADOSGW

概念解释

  • Region: A region represents a logical geographic area and contains one or more zones. A cluster with multiple regions must specify a master region.
  • Zone: A zone is a logical grouping of one or more Ceph Object Gateway instance(s). A region has a master zone that processes client requests.
    注:Only write objects to the master zone in a region. You may read objects from secondary zones. Currently, the Gateway does not prevent you from writing to a secondary zone, but DON’T DO IT.

应用模式1

同一Region内的不同Zones之间数据同步,如下图所示:

rgw-multi-region1

特点:

  • 主zone支持读写操作
  • 从zone支持读操作
  • 主从zone之间同步数据

用途:

  • 主从zone之间数据备份,提供跨机房容灾
  • 从zone分担主zone的读数据压力,提高集群扩展性

应用模式2

不同Regions之间的数据同步,如下图所示:

rgw-multi-region2

特点:

  • 主从Region都支持读写操作
  • 主从Region之间只同步元数据信息
  • 主从Region之间数据是独立的

用途:

  • 多个Regions一起来提供统一命名空间
  • 不同Region服务不同地区的客户,提高集群扩展性

展望

在10.2 jewel版本中,radosgw增加了一个新特性,也就是多中心同步。

所谓多中心同步,也就是不同radosgw实例之间可以自动进行同步的特性。

为了便于管理,又进行了逻辑上的组织,也即realm、zonegroup、zone和radosgw。这是个从上至下的组织结构,也就是realm包括若干个zonegroup,其中一个是master,其它是secondary。每个zonegroup下包括一个master zone,其它都是secondary zone。

zone可以认为是一个实际上的集群,由至少一个radosgw实例提供服务,但是对外服务地址是一致的。

同步分两种,也就是元数据同步和数据同步。zonegroup之间只会同步元数据,而同一个zonegroup下的zone之间是同步元数据和数据。这里的元数据是指用户和桶,数据是用户的对象数据。

概念:

  • Zone: A zone is logical grouping of one or more Ceph Object Gateway instances. There will be one Zone that should be designated as the master zone in a zonegroup, which will handle all bucket and user creation.
  • Zonegroup: A zonegroup consists of multiple zones, this approximately corresponds to what used to be called as a region in pre Jewel releases for federated deployments. There should be a master zonegroup that will handle changes to the system configuration.
  • Zonegroup map: A zonegroup map is a configuration structure that holds the map of the entire system, ie. which zonegroup is the master, relationships between different zonegroups and certain configurables like storage policies.
  • Realm: A realm is a container for zonegroups, this allows for separation of zonegroups themselves between clusters. It is possible to create multiple realms, making it easier to run completely different configurations in the same cluster.
  • Period: A period holds the configuration structure for the current state of the realm. Every period contains a unique id and an epoch. A period’s epoch is incremented on every commit operation. Every realm has an associated current period, holding the current state of configuration of the zonegroups and storage policies. Any configuration change for a non master zone will increment the period’s epoch. Changing the master zone to a different zone will trigger the following changes: - A new period is generated with a new period id and epoch of 1 - Realm’s current period is updated to point to the newly generated period id - Realm’s epoch is incremented

参考资料

http://docs.ceph.com/docs/master/radosgw/federated-config/

http://qinghua.github.io/ceph-radosgw-replication/

http://www.cnphp6.com/archives/79981

http://lyang.top/2016/01/18/Radosgw-%E5%A4%9A-zone-%E9%83%A8%E7%BD%B2%E4%BB%A5%E5%8F%8A-radosgw_agent-%E5%90%8C%E6%AD%A5/

支持原创