OpenvStorage 架构

    传统的OpenStack利用Cinder在本地虚拟出块设备供虚拟机作为存储卷(创建快照、备份和迁移)来创建虚拟机。通常后端采用SATA盘或者SAS盘提供存储。SATA盘虽然容量较大(3-4T)但是性能较差，而SAS盘虽然性能稍好但是容量有限(1-2T)，带来的问题就是虚拟机数量多了存储容量非常庞大，服务器后端的存储容量将变得极其有限，无法动态扩容，热迁移受限等。而如果我们能够实现将集群所有虚拟机存储共享就可以解决上述这些问题。

    OpenvStorage就以这样的姿态出现了，作为OpenStack块设备管理的module，在原有OpenStack架构的基础上兼容了OpenStack组件，实现了以共享存储的方式来管理块设备(共享存储优点：统一管理虚机块设备、减少数据冗余、超融合架构)，同时实现了动态卷扩容，热迁移，快照和扩容等。并且以SSD缓存的方式来保证虚机的读写性能。

    以下分析OpenvStorage的架构：

一、背景

基于Apache 2.0 license的开源项目
由比利时CloudFounders主导开发，目前稳定版本2.6.1
支持的Hypervisor：KVM（FUSE）、VMware ESXI（NFS）
支持的Linux发行版本：Ubuntu 14.04， Centos 7
Openstack Kilo版本提供原生OVS Cinder driver支持
    通过Cinder给虚机提供块存储，或者通过iscsi方式提供块存储

二、OpenvStorage的优势
开源，和X86/Linux/OpenStack/KVM 亲缘
采用共享存储，支持虚机快照、热迁移、卷扩容
水平伸缩架构，支持融合和超融合部署
支持多种类型后端存储，技术能力和基础设施可复用

    OpenvStorage后端兼容S3以及DFS接口：可选ALBA、Ceph S3、Swift S3、S3 compatible和Gluster FS后端类型。

    超融合(计算和存储合并，启用本地的后端硬盘)也是追求的一个目标，因为采用这样的架构节省服务器资源，同时数据存储速度能够保证

三、OpenvStorage 架构

core
    volume driver
        base
        server
    消息和异步工作
        rabbitmq: message queue
        celery: distributed task queue
        celery workers
    缓存和持久化
        memcached: cache
        arakoon: distributed key-value store
            voldrv
            ovsdb
    监控
        watchers (服务监控)
            volumedriver
            framework
        snmp (可以和其他监控系统集成)
    日志相关
        logstash (logging collector)
        elasticsearch (logging store & indexer)
webapps
    nginx
    logging(kibana)
    api(django gunicorn)
    openvstorage gui(django)
VM management
    openstack + cinder (推荐)
    VMWare ESXi

 

    fuse相当于本地的一个挂载(vpool)，文件的读写操作都是通过fuse接口与volumedriver通信。
    metedata存储元数据(只存储本节点卷的信息：如包括的对象及offset等信息)；
    全局数据(卷的属性权限创建时间等信息)放在arakoon(只有master节点运行)的database(arakoon-ovsdb)；
    虚机的配置信息和状态(arakoon-voldrv)；
    DTL同步到集群里面别的机器里面，通过socket方式进行通信和传输，当本地数据刷入后端完成之后，就通知别的机器不用再保留该份数据。最终还是以TLOGs方式刷入对象存储，最后由Scruber去清除。

四、OpenvStorage 去重机制

    读缓存基于内容(默认content-based支持去重)：需要计算MD5哈希。接着扫描一遍metedata的hash表，判断是否在读缓存里面，如果在的话通过此元数据定位到读缓存的位置。读缓存不命中会访问写缓存。
    写缓存基于位置(location-based也即非去重)(保存了LBA、SCO+offset)，通过metadata可知哪些SCO还在缓存中并且位置在哪里。
    后端采用基于时序的存储，顺序读写，保证读写性能。

五、后端持久化机制

    写的过程：4k小文件过来，封装成SCO对象文件刷入后端，数据的分发和去重(EC)等过程由Swift完成(去重、非去重的区别就是有没有计算hash的过程)，替换出的写缓存按时序合并为SCOs和TLOGs刷回后端(TLOG中记录每一个4k写的<LBA, SCO+offset>对应)。
    读的过程：
去重：首先计算hash，然后在metadata的hash表中查找，找得之后就到对应的地址读取数据
非去重：LBA已经对应了不同的卷了，找到对应的卷的metadata表，在其中查找LBA号，找到对应的地址去读取数据

    快照存的是一些变更的tlog和追加的tlog信息，并不是最新的包括全部的tlog信息。回滚的时候需要扫描所有的快照信息。
TLOGs和SCOs一起刷回后端，tlog存的是<LBA, SCO+offset>(4k块的偏置)(tlog可能是1个SCO对应1个，也有可能是1个4K块对应1个)(tlog只是保存一些历史信息)
    Scruber检测tlog，扫描被更新的4K块，替换和重组SCO

六、去重和非去重

    非去重没有计算hash的过程，因此写性能能提升，读性能也能提升(直接去对应的LBA地址读取)；但是读缓存可能是有重复的内容。
    去重有计算hash的过程(LBA号请求，计算hash值，根据得出来的hash值在metadata的hash表中查找到之后，去读缓存、写缓存和后端读取数据)；读缓存中的内容不可能有重复。
    不管去重还是非去重，需要读取的内容如果read cache中没有的话，都会在read cache中存一份。

    Read cache中存的是一些4k的小文件，如果是去重的话，metadata中会记录哈希值和read cache的位置，直接命中，并且不同的卷可以混合在一块的；如果是非去重的话，则会将read cache分块用于不同的卷，实现隔离。

    Cache on read：写到write cache之后刷入后端；
    Cache on write：写到write cache之后，还会在read cache中存一份(双写过程)，再刷入后端；(Cache on write和去重/非去重没有关系，都会去双写)

    perf工具统计了volume_driver进程：采样和处理时间占了35%左右(主要在用于计算MD5)

七、性能优化
    定位缓存MD5哈希去重极大地影响了写性能
    去重和非去重灵活配置(vPool/vDisk)，应对不同场景
    对后端存储进行优化