分布式存储技术方案 第1篇
分布式存储具有高可用性、高扩展性、高性能和灵活性等优点。
分布式存储适用于大数据存储和处理、云存储和云计算、分布式数据库系统等场景。
分布式文件系统是以文件为单位进行存储和管理，而分布式对象存储是以对象为单位进行存储和管理。
分布式存储可以解决数据存储和处理的可用性、扩展性和性能等问题。
选择适合的分布式存储方式需要考虑应用场景、性能需求、数据模型和可用性等因素。
分布式存储技术方案 第2篇
3.当一致性组实现的时候，我们就可以用一个journal来管理所有的RBD的镜像，可以给一个已经存在image开启journal，ceph将会将你的镜像做一个快照，然后对快照做一个复制，然后开启journal，这都是后台执行的一个任务可以启用和关闭单个镜像或者存储池的mirror功能，
如果启用了journal功能，那么每个镜像将会被复制可以使用 rbd mirror pool enable启用它。
由于核心流程就是先写日志，然后写image需要写两份的逻辑，所以导致性能就会有损失。 根据官方的参数优化也没有明显的效果，建议等待官方更新features。
分布式存储技术方案 第3篇
mirroring是基于存储池进行的peer，ceph支持两种模式的镜像，根据镜像来划分有：
存储池模式
镜像模式
创建一个用于测试的存储池：
开启存储池rbdmirror的镜像功能：
主集群创建一个测试用的RBD：
启动后会才会记录image的事件，才可以被rbd-mirror检测到并同步到从集群：
把local和remote设为同伴，这个是为了让rbd-mirror进程找到它peer的集群的存储池：
查看peer的情况：
a. 先用调试模式启动进程看看情况，在remote的机器上执行
b. 如果确认没问题就用服务来控制启动
c. 在remote机器上启动
a. 查询local集群镜像的同步的状态
b. 检查数据是否同步到remote集群
启动后会才会记录image的事件，才可以被rbd-mirror检测到并同步到从集群
把local和remote设为同伴，这个是为了让rbd-mirror进程找到它peer的集群的存储池：
查看peer的情况：
a. 先用调试模式启动进程看看情况，在remote的机器上执行
b. 如果确认没问题就用服务来控制启动
c. 在remote机器上启动
a. 查询local集群镜像的同步的状态
b. 检查数据是否同步到remote集群
分布式存储技术方案 第4篇
RBD Mirror原理其实和MySQL的主从同步原理非常类似，前者基于journaling，后者基于binlog，简单地说就是利用日志进行回放(replay)：通过在存储系统中增加Mirror组件，采用异步复制的方式，实现异地备份。(此处的journal是指Ceph RBD的journal，而不是OSD的journal)
该能力利用了 RBD image 的日志特性，以确保集群间的副本崩溃一致性。镜像功能需要在同伴集群（ peer clusters ）中的每一个对应的 pool 上进行配置，可设定自动备份某个存储池内的所有 images 或仅备份 images 的一个特定子集。 rbd-mirror 守护进程负责从远端集群拉取 image 的更新，并写入本地集群的对应 image 中。
当RBD Journal功能打开后，所有的数据更新请求会先写入RBD Journal，然后后台线程再把数据从Journal区域刷新到对应的image区域。RBD journal提供了比较完整的日志记录、读取、变更通知以及日志回收和空间释放等功能，可以认为是一个分布式的日志系统。
1、当接收到一个写入请求后，I/O会先写入主集群的Image Journal 2、Journal写入成功后，通知客户端 3、客户端得到响应后，开始写入image 3、备份集群的mirror进程发现主集群的Journal有更新后，从主集群的Journal读取数据，写入备份集群（和上面序号一样，是因为这两个过程同时发生） 4、备份集群写入成功后，会更新主集群Journal中的元数据，表示该I/O的Journal已经同步完成 5、主集群会定期检查，删除已经写入备份集群的Journal数据。 以上就是一个rbd-mirror工作周期内的流程，在现有的Jewel版本中30s为一次工作周期，暂时不能改变这个周期时间。
1、当副本在异地的情况下，减少了单个集群不同节点间的数据写入延时；
2、减少本地集群或异地集群由于意外断电导致的数据丢失。
双向备份：两个集群之间互相同步，两个集群都要运行rbd-mirror进程。 单向备份：分为主集群和从集群，只在从集群运行rbd-mirror进程，主集群的修改会自动同步到从集群。