openstack 源代码分析

上传人:suns****4568 文档编号:89212502 上传时间:2019-05-21 格式:PDF 页数:72 大小:1.91MB
返回 下载 相关 举报
openstack 源代码分析_第1页
第1页 / 共72页
openstack 源代码分析_第2页
第2页 / 共72页
openstack 源代码分析_第3页
第3页 / 共72页
openstack 源代码分析_第4页
第4页 / 共72页
openstack 源代码分析_第5页
第5页 / 共72页
点击查看更多>>
资源描述

《openstack 源代码分析》由会员分享,可在线阅读,更多相关《openstack 源代码分析(72页珍藏版)》请在金锄头文库上搜索。

1、 技术预研报告 机密 第 1 页 2015-9-15 OpenStack 源代码分析源代码分析 2014 年年 7 月月 技术预研报告 机密 第 2 页 2015-9-15 作者作者: 王智民王智民 贡献者贡献者: 创建时间创建时间: 2014-7-19 稳定程度稳定程度: 初稿初稿 修改历史修改历史 版本版本 日期日期 修订人修订人 说明说明 1.0 2014-7-19 王智民 初稿 技术预研报告 机密 第 3 页 2015-9-15 目录目录 1 引言引言 1 1.1 编写目的 1 1.2 背景 1 2 框架分析框架分析 . 3 2.1 0 层分解 3 2.1.1 OpenStack 概况

2、 . 3 2.1.2 OpenStack 安装 . 4 2.2 1 层分解 5 2.2.1 子项目与服务 . 5 2.2.2 Conceptual architecture 6 2.2.3 服务组件之间通信 . 7 2.3 2 层分解 8 2.3.1 块存储组件 Cinder . 9 2.3.2 网络组件 Neutron . 14 3 Ceph . 21 3.1 1 级分解 21 3.2 2 级分解 22 3.2.1 RADOS 22 3.2.2 BRD . 25 3.2.3 Ceph client . 25 4 FlashCache . 25 4.1 FlashCache 技术特点 . 25

3、 4.2 FlashCache 实现分析 . 26 4.2.1 工作原理 . 26 4.2.2 Linux 内核层次 . 26 4.2.3 逻辑结构 . 27 4.2.4 缓存算法 . 31 5 网络虚拟化网络虚拟化 . 32 5.1 云对网络的需求 32 5.2 网络虚拟化常见技术 33 5.2.1 SDN 33 5.2.2 隧道技术 . 33 5.3 虚拟化网络并不完全等同于云网络 40 5.3.1 Microsoft 的 NVGRE 40 5.3.2 vMware 的 VXLAN 48 5.3.3 OpenStack 不支持 NVGRE,支持 GRE 50 5.3.4 OpenStack

4、 支持 VXLAN 51 6 FWaaS 52 6.1 FWaaS 应用场景 53 6.2 FWaaS in Openstack(Neutron) . 53 6.2.1 1 级分解 . 54 6.2.2 2 级分解-Linux 如何实现 FWaaS . 55 7 vMware 57 7.1 vMware 与 OpenStack 融合方案探讨 . 57 技术预研报告 机密 第 4 页 2015-9-15 7.1.1 孤岛型解决方案 . 58 7.1.2 异构虚机集成管理解决方案 . 58 7.1.3 混合解决方案 . 59 7.2 vMware 对 OpenStack 在计算虚拟化方面的贡献 .

5、 59 7.3 vMware 对 OpenStack 在网络虚拟化方面的贡献 . 60 7.4 vMware 对 OpenStack 在存储虚拟化方面的贡献 . 62 8 Sahara the security now mirrors the environment, rather than contorting the environment to fit the security. While fully compatible with SDN technologies like OpenFlow, vArmours SDSec solution can be deployed today

6、 in both conventional and virtual networking environments. The result: Intelligent security that works like the rest of your virtual data center. 3.3.3.5 Service Plugin(Router) neutronservices: neutronservicesl3_router: - 20 - 3.3.3.6 Service Plugin(LB) neutronservices: neutronservicesloadbalancer:

7、- 21 - 4 Ceph Ceph 是加州大学 Santa Cruz 分校的 Sage Weil(DreamHost 的联合创始人)专为博士论 文设计的新一代自由软件分布式文件系统。自 2007 年毕业之后,Sage 开始全职投入到 Ceph 开 发之中,使其能适用于生产环境。Ceph 的主要目标是设计成基于 POSIX 的没有单点故障的 分布式文件系统,使数据能容错和无缝的复制。2010 年 3 月,Linus Torvalds 将 Ceph client 合并到内 核 2.6.34 中。 Ceph 的使用场景如下: 4.1 1 级分解级分解 Ceph 1 级分解为 RADOS、ceph

8、client、RADOSGW、RBD 和 CEPH FS 几个模块: - 22 - 4.2 2 级分解级分解 4.2.1 RADOS RADOS (Reliable, Autonomic Distributed Object Store) 是 Ceph 的核心之一,作为 Ceph 分布式文件系统的一个子项目,特别为 Ceph 的需求设计,能够在动态变化和异质结构的存储 设备机群之上提供一种稳定、 可扩展、 高性能的单一逻辑对象(Object)存储接口和能够实现节 点的自适应和自管理的存储系统。事实上,RADOS 也可以单独作为一种分布式数据存储系统, 给适合相应需求的分布式文件系统提供数据存储

9、服务。 RADOS 系统由 OSD(Object Storage Device)、MDS(MetaData Server)和 Monitor 组成,这 三个角色都可以是 Cluster 方式运行。 MDS 负责管理 Cluster Map,其中 Cluster Map 是整个 RADOS 系统的关键数据结构,管理机群 中的所有成员、关系、属性等信息以及数据的分发。 4.2.1.1 Cluster Map 存储机群的管理,唯一的途径是 Cluster Map 通过对 MDS 操作完成。Cluster Map 是整个 RADOS 系统的核心数据结构,其中指定了机群中的 OSDs 信息和所有数据的分

10、布情况。 所有涉及到 RADOS 系统的 Storage 节点和 Clients 都有最新 epoch 的 Cluster Map 副本。 因为 ClusterMap 的特殊性,Client 向上提供了非常简单的接口实现将整个存储机群抽象为单一的 逻辑对象存储结构。 Cluster Map 的更新由 OSD 的状态变化或者其他事件造成数据层的变化驱动,每一次 Cluster Map 更新都需要将 map epoch 增加,map epoch 使 Cluster Map 在所有节点上的副本都保持同 步,同时,map epoch 可以使一些过期的 Cluster Map 能够通过通信对等节点及时更

11、新。 在大规模的分布式系统中,OSDs 的 failures/recoveries 是常见的,所以,Cluster Map 的更 新就比较频繁,如果将整个 Cluster Map 进行分发或广播显然会造成资源的浪费,RADOS 采用 - 23 - 分发 incremental map 的策略避免资源浪费,其中 incremental map 仅包含了两个连续 epoch 之间 Cluster Map 的增量信息。 4.2.1.2 Data Placement 数据迁移数据迁移:当有新的储存设备加入时,机群上的数据会随机的选出一部分迁移到新的设备上, 维持现有存储结构的平衡。 数据分发数据分发:

12、通过两个阶段的计算得到合适的 Object 的存储位置。 1Object 到 PG 的映射 PG (Placement Group)是 Objects 的逻辑集合。相同 PG 里的 Object 会被系统分发到相同的 OSDs 集合中。由 Object 的名称通过 Hash 算法得到的结果结合其他一些修正参数可以得到 Object 所对应的 PG。 2RADOS 系统根据根据 Cluster Map 将 PGs 分配到相应的 OSDs 这组 OSDs 正是 PG 中的 Objects 数据的存储位置。RADOS 采用 CRUSHCRUSH 算法实现了一种稳定、伪 随机的 hash 算法。 CR

13、USH 实现了平衡的和与容量相关的数据分配策略。 CRUSH 得到的一组 OSDs 还不是最终的数据存储目标,需要经过初步的 filter,因为对于大规模的分布式机群,宕机 等原因使得部分节点可能失效,filter 就是为过滤这些节点,如果过滤后存储目标不能满足 使用则阻塞当前操作。 3Map propagate(同步) Cluster Map 在 OSD 之间的更新是通过一种抢占式的方法进行。Cluster Map epoch 的差异只 有在两个通信实体之间有意义,两个通信实体在进行信息交换之前都需要交换 epoch,保证 Cluster Map 的同步。这一属性使得 Cluster Map

14、 在通信实体内部之间的更新分担了全局的 Cluster Map 分发压力。 每一个 OSD 都会缓存最近 Cluster Map 和到当前时刻的所有 incremental map 信息,OSD 的所 有 message 都会嵌入 incremental map,同时侦听与其通信的 peer 的 Cluster Map epoch。当 从 peer 收到的 message 中发现其 epoch 是过期的,OSD share 相对 peer 来说的 incremental map,使通信的 peers 都保持同步;同样的,当从 peer 收到 message 中发现本地 epoch 过期, 从其

15、嵌入到message中的incremental map中分析得到相对本地的incremental map然后更新, 保持同步。 - 24 - 数据复制数据复制(Replication):RADOS 实现了三种不同的 Replication 方案,见下图: Primary-copy:读写操作均在 primary OSD 上进行,并行更新 replicas; Chain:链式读写,读写分离; Spaly:Primary-copy 和 Chain 的折中方案:并行更新 replicas 和读写分离。 数据一致性数据一致性(Consistency):一致性问题主要有两个方面,分别是 Update 和

16、Read: Update:在 RADOS 系统中所有 Message 都嵌入了发送端的 map epoch 以协调机群的一致性。 Read:当 read operation 的发起方还不知道待读的 OSD 已经失效,会导致数据不能从该 OSD 读取从而需转向新的 OSD, 为了解决此问题, 同一个 PG 所在的 OSDs 需要实时交换 Heartbeat。 失效检测(Failure Detection):RADOS 采取异步、有序的点对点 Heartbeat。 数据迁移与数据恢复数据迁移与数据恢复(Data Migration Flashcache_conf.c: int _init flashcache_init(void) . r = dm_register_target( . - 28 - 调度模块调度模块,在代码中对应 flashcache_map 映射函数,它是 flashcache 缓存层次数据入口, 所以到达逻辑设备的读写请求, 最终都会经过 DM 层的处理, 通过 flashcache_map 进入调度模 块。称之为

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 高等教育 > 其它相关文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号