OpenStack文件服务 Manila & CephFS

为什么云上要有文件系统服务

在云上如何才能支撑文件系统服务

OpenStack的方案：Manila

UnitedStack的方案：Ceph+Manila

Q & A

概述

为什么云上要有文件系统服务

概述

文件系统服务

文件系统服务是企业存储的刚性需求

• 根据IDC 2012数据，65%的数据存储是以文件的形态存在的

• 大量的传统应用需要使用文件系统作为存储媒介

云上支撑企业应用要求文件系统服务

• 企业应用上云，自然对传统的SAN/NAS会有需求

• 连普通家庭用户都用上NAS了，云呢？

在云上如何才能支撑文件系统服务

OpenStack的方案：Manila

概述

Manila项目概况

安全的多租户的文件共享即服务

类似Cinder但是提供的是文件共享服务

现在支持NFS和CIFS

Manila项目概况

• 65%的磁盘空间被用来作为文件存储

• 管理和配置共享文件系统的技术难度较高

• 大部分客户通过脚本、自动化工具等进行配置

客户用例

• NetApp、Mirantis

项目主导者

• 已经有Juno的stable分支

• https://github.com/openstack/manila

项目近况

Manila的几个关键概念

Share（一个共享文件系统的实例）

• 用户指定大小、访问协议、共享类型

• 可被多个实例并行访问

Share Access Rule（ACL）

• 定义哪些客户端可以访问Share

• 根据IP地址进行定义

Share Network（共享网络）

• 定义客户端访问Share使用的Neutron的网络及子网

• 一个Share只能属于一个Share Network

Manila的几个关键概念

Security Service（安全服务）

• 用户安全服务（LDAP、Active Directory、Kerberos等）

• 一个Share可以被关联至多个安全服务

Snapshots（快照）

• 共享文件系统的只读副本

• 可以从快照创建共享文件系统服务

Backend

• Share服务的提供者

• 一个share必然属于一个backend

Driver（驱动）

• 后端文件共享服务的具体实现，例如GPFS、Glusterfs、EMC VNX等

Manila的API概述

Manila的API概述

Manila的架构：进程列表

• 通过WSGI应用实现了REST API

manila-api

• 对share的请求进行配置决策

manila-scheduler

• 每个backend对应一个manager进程

• 与后端的存储子系统进行通信

manila-share

Manila的多租户隔离

Manila的多租户隔离依赖于OpenStack的网络实现

目前看最靠谱隔离方式：使用私有网络隔离。

Manila的Driver支持情况

•NFS/CIFS

Generic Share Driver

•Data ONTAP

NetApp

•VNX

• Islion

EMC

•GPFS

IBM

•GlusterFS

Redhat

•ZFSSA

Oracle

•V3 Storage

Huawei

Manila的Generic Share Driver

创建一个Nova实例，通过Cinder的Volume

来提供NFS/CIFS共享服务

• 每个Share Network创建一个Nova实例

• 连接到已存在Neutron网络及子网中

• 创建Nova实例使用的Nova的flavor、Glance的image、SSH Keypair均是Manila

配置的

• Manila通过 SSH对Nova实例进行配置

Manila项目面临的问题

相对于块存储，文件存储的复杂性更高

• 认证：LDAP、Active Directory

• 网络：依赖Neutron SDN进行保护和隔离

• 协议：NFS/CIFS相对于block device的直接attach

相对于块存储，文件存储对存储和网络的要求更高

• 存储的Throughput要够大，Latency要够低

• 网络的Throughput也要够大, Latency也要够低

相对于块存储，文件存储需要同时满足Scale-out和Scale-up

• 性能要求高

• 空间要求大

在云上如何才能支撑文件系统服务

UnitedStack的方案：Ceph+Manila

概述

除了EMC、IBM、NetApp、Huawei……，Cinder还有Ceph

除了EMC、IBM、NetApp、Huawei……， Manila有什么呢？

UnitedStack的方案

CephFS概述

CephFS：高性能分布式文件系统

• CephFS是Ceph最初的设计目标

• 2010年3月CephFS客户端进入内核

• 0.56版本文件系统基本稳定

解决两个核心问题：

• 如何实现高性能吞吐：

分布式存储系统（RADOS）

• 如何实现高性能OPS

分布式元数据存储（MDS Cluster）

CephFS的三方架构

Clients MDS

RADOS

• 数据路径与元数据路径分离的全分布式设计

• 高并发，高吞吐，高IOPS

• 性能、容量线性横向扩展

CephFS的数据存储

• 所有元数据全部存在RADOS中

• MDS只承担计算任务

• 简化MDS容灾与集群设计

• 充分利用RADOS的容灾特性

Clients MDS

RADOS

• 所有数据都存在于RADOS中

• 客户端直接与RADOS通讯

• 可达到超高吞吐量与横向扩展

• 充分利用RADOS的容灾特性

CephFS的客户端视图

• CephFS Linux提供三种访问方式：

• Kernel client、Fuse Client、libcephFS

• UnitedStack提供Windows原生客户端

• 提供媲美Linux原生客户端的性能

CephFS的客户端IO流程

Client RADOS

metadata request

metadata response

MDS

write metadata object

ack

write data object

ack

CephFS的两个创新

RADOS

• 对象存储

• CRUSH

• 冗余、容灾

• 负载平衡

MDS

• 元数据处理

• 元数据集群

• 动态子树分区

• 目录分片

RADOS对象存储

oid • 用于标示、查找、获取对象

• 全局唯一

data • 二进制数据流

• 可能是任意长度

Attr • 键值对集合

• 用于存储对象相关的元数据

Object

oid

data

attr

ObjectA ObjectB ObjectC ObjectD ObjectX

RADOS

• 对象可以视为一个完整而独立的数据。

• 每一个对象通过其对象id（Object ID/oid）进行标示。

• 对象的内容包含数据和扩展属性两部分。

RADOS对象存储 RADOS提供了以对象为存储单元的存储服务：

每个对象具有一个对象名称（object id）

对象的定位通过对对象名称进行CRUSH实现

对象之间相互独立

RADOS的强一致性支持

RADOS采用了主-从节点的驱动机制，Write-All-Read-One，强一致性

Primary

Replica Replica Replica

写入N1

N2 N3 Nn

Client

Request

• Primary：

• 接受Client请求，

• 执行本地数据操作

• 驱动Replica，并等待Replica操作完成

• 向Client返回响应

• Replica：

• 根据Primary请求，执行本地操作

• 向Primary返回操作完成的响应

CephFS的两个创新

RADOS

• 对象存储

• CRUSH

• 冗余、容灾

• 负载平衡

MDS

• 元数据存储

• 元数据集群

• 动态子树分区

• 目录分片

元数据以目录为单位存储在RADOS中

元数据的存储

优点：

• 与RADOS存储方式结合良好

• 加载目录内容速度快

• 方便实现基于目录的负载平衡

缺点：

• 硬链接的处理逻辑复杂

• 不支持基于Inode的反向查找

元数据的处理实际是对象的修改

元数据集群-动态子树分区

• 初始状态由mds.0管理所有元数据

• 随着目录热度增加，mds.0将目录分散到其它mds

• 客户端在将缓存“目录-mds”映射关系，直接与相关mds通讯

目录仍然不是负载平衡的最小单位 ，目录分片才是

元数据集群-目录分片

4 5 6 7

（k=1，v=0）

（k=2,v=2）

（k=2,v=3）

0 1 2 3

目录可以被拆分为更小单位：目录分片

• 每一个目录分片包含一部分目录项

• 目录分片大小可以不同

• 目录分片可以动态调整

• 目录项：

• {a, b, c, d, e, f, g}

• 目录项树的叶子节点：

• 0 = {g, a}, 1 = {b}, 2 = {d}, 3 = {}, 4 = {}, 5 ={c}, 6= {f}, 7 = {e}

• 目录分片

• Frag1{0, 1, 2, 3} => {a, b, d, g}, Frag2{4, 5} => {c}, Frag3{6, 7} => {e, f}

目录分片的拆分过程：

现状与未来

• 基础特性：动态伸缩、负载平衡、容灾、fuse客户端

• 性能特性：元数据集群、元数据缓存

• 功能特性：快照、配额、ACL(PR)

特性

• 单mds元数据性能：2000+OPS

• 单客户端吞吐量：1GB/s

性能

• 元数据集群模式尚不稳定，未达到生产环境要求

• 快照的设计过于复杂，未达到生产环境的要求

问题

CephFS已被社区作为下一阶段开发重点

Manila的现状

Nova Glance Cinder Manila

LocalFS LocalFS

Swift

Ceph

GlusterFS

LVM

SAN

Ceph

Create A Share = Create A Nova Instance + Create A Cinder Volume

Neutron

UnitedStack的方案

Nova Glance Cinder Manila

Ceph

Create A Share = Create A CephFS Namespace

Neutron

THX