OpenStack

前言

OpenStack是 模仿亚马逊 AWS 使用python开发的 IssA层实现框架，openstack遵循Apache2.0协议，使我兴奋的是它的WEB管理模块 horizon，是使用Django开发的，站在巨人的肩膀上，也许我可以对其进行二次开发；

 

openstack涉及知识大而全，本文主要介绍openstack以下内容

openstack概念

openstack主要组件的介绍以及组件间的通信流程

openstack支持的几种网络模式（vlam/ gre/ vxlan）

openstack支持的分布式存储（Ceph）

基于openstack搭建一个iaas层私有云环境

 

 

什么是OpenStack 

OpenStack是一个由NASA（美国国家航空航天局）和Rackspace合作研发并发起的，以Apache许可证授权的自由软件和开放源代码项目。

该项目采用了模块化设计 由众多的模块组成1个框架，各个模块负责自己不同的功能；

 

0.核心组件：

Horzion：提供web页面让用户管理主机（创建主机、挂载云盘、绑定浮动IP）

Nova：支持各种虚拟机驱动（Vmware/Zen/KVM）调用虚拟机驱动创建出主机；（硬件资源供应商）

Glance：给虚拟机提供镜像；（操作系统供应商）

Newtron：Neurton实现了SDN(软件定义网络，虚拟出交换机、路由器)，提供一整套API，Nova调用NewtronAPI 帮助虚拟机接入网络；（网络供应商）

Keystone：注册各种组件的功能，为各组件之间的交互提供认证服务；

Cinder（块存储）/Swift（对象存储）：提供存储服务

 

 

可以从Nova那里买硬件-----》Glance那里买镜像装上系统----------》Nweton提供交换机、路由器让我接入网络---------》Cinder/Swift 提供一块硬盘让我 挂载上 -------》1台云主机诞生了

 

1.浅谈3主流中存储模式

文件存储：   相当于1个大的文件夹，以文件为单位去存储，基于POSIX标准对文件进行读写操作；

块存储：      相当于1块大的裸盘，把硬盘上的N个扇区划分为1个逻辑数据块；（降低寻找多个扇区的复杂度）

对象存储：  特点基于resfull api 访问数据，无法在线修改文件（下载到本地修改之后，上传新文件覆盖源文件）

以上2种传统存储方式会逐渐形成目录树结构，目录树结构越深越难以查找；对象存储摒弃目录数据结构，以1个Key《---------》1个Value结构，查询速度快；

对象存储对于用户而言所有数据都是object，
object包含:object id、元数据（key value结构描述相关属性）、源数据、
客户端通过restful api 去访问 object，如我要访问 a.txt 等于访问一个http://api/object
key：就是一个url地址 （http://api/）
value：参数 object

 

OpenStack工作流程

openstack的工作流程是围绕创建1个虚拟机展开的

 虚拟机启动过程如下：

1. 界面或命令行通过RESTful API向keystone获取认证信息。

2. keystone通过用户请求认证信息，并生成auth-token返回给对应的认证请求。

3. 界面或命令行通过RESTful API向nova-api发送一个boot instance的请求（携带auth-token）。

4. nova-api接受请求后向keystone发送认证请求，查看token是否为有效用户和token。

5. keystone验证token是否有效，如有效则返回有效的认证和对应的角色（注：有些操作需要有角色权限才能操作）。

6. 通过认证后nova-api和数据库通讯。

7. 初始化新建虚拟机的数据库记录。

8. nova-api通过rpc.call向nova-scheduler请求是否有创建虚拟机的资源(Host ID)。

9. nova-scheduler进程侦听消息队列，获取nova-api的请求。

10. nova-scheduler通过查询nova数据库中计算资源的情况，并通过调度算法计算符合虚拟机创建需要的主机。

11. 对于有符合虚拟机创建的主机，nova-scheduler更新数据库中虚拟机对应的物理主机信息。

12. nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息。

13. nova-compute会从对应的消息队列中获取创建虚拟机请求的消息。

14. nova-compute通过rpc.call向nova-conductor请求获取虚拟机消息。（Flavor）

15. nova-conductor从消息队队列中拿到nova-compute请求消息。

16. nova-conductor根据消息查询虚拟机对应的信息。

17. nova-conductor从数据库中获得虚拟机对应信息。

18. nova-conductor把虚拟机信息通过消息的方式发送到消息队列中。

19. nova-compute从对应的消息队列中获取虚拟机信息消息。

20. nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求glance-api获取创建虚拟机所需要镜像。

21. glance-api向keystone认证token是否有效，并返回验证结果。

22. token验证通过，nova-compute获得虚拟机镜像信息(URL)。

23. nova-compute通过keystone的RESTfull API拿到认证k的token，并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息。

24. neutron-server向keystone认证token是否有效，并返回验证结果。

25. token验证通过，nova-compute获得虚拟机网络信息。

26. nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息。

27. cinder-api向keystone认证token是否有效，并返回验证结果。

28. token验证通过，nova-compute获得虚拟机持久化存储信息。

29. nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机。

 

 

OpenStack各组件详解

1.KeyStone组件

 openstack组件间的协同工作是通过rest api调用完成的，既然组件间需要相互调用API，那么安全认证是无法避免的对吧？

keystone的主要功能是分发各组件的endpoint并为组件之间的api调用提供认证服务；

 

User:指使用了openstack 服务的对象

Project(Tenant):在openstack资源池，划分一个逻辑资源称之为1个项目

Role：用于权限的划分，user关联了role，使user拥有不同的权限

Policy：默认就是1个/etc/keystone/policy.json的文件，定义角色包含的权限

Tocken：认证完毕之后发放的令牌

Credentials:用于确认用户的身份

Authentucation:认证过程（从普通用户拿到token的认证过程）

Service：openstack中各个组件提供的服务

Endpoint：在openstack中，每一个service(Nova/Glance/Newtron)都有三种不同的 web api end points. Admin, public, internal。

Admin是用作管理用途的，如它能够修改user/tenant(project)。

public 是让客户调用的，比如可以部署在外网上让客户可以管理自己的云。

internal是openstack内部调用的。

以上3种endpoints 在网络上开放的权限一般也不同。Admin通常只能对内网开放，public通常可以对外网开放，internal通常只能对安装有openstack服务的机器开放；

admin url----->面向admin用户 port:3557

internal url ---->面向openstack内部组件间通信 port：5000

public url----->大家都可以访问的api port:5000（与internal url 的端口相同绑定Ip不同）

注意：用户的权限是根据角色赋予的，所以以上3中api能否调用成功是根据用户的角色决定的，只要有权限调用哪个api都可以，但是不要随便走这样配置会比较乱；

keystoneV3版新增概念

• Tenant 重命名为 Project

• 添加了 Domain 的概念：domain包含多个project

• 添加了 Group 的概念：把N个用户加入1个组方便管理

 

1.0.keystone工作流程

 

A.用户发送Credentials 给你 keystone，keystone返回1个temporary token（临时令牌） 和 1个 generic catalog（openstack中 Endpoint，也就是27个url）

B.用户再次拿着 临时令牌再次请求keystone，向kestone索取所有项目列表；

C.用户从项目列表中找到自己期望的项目发送给kestone，keystone颁发该项目的token给用户

D.用户拿着Token 直接访问Endpoint

E.Endpoint所在的service去和kestone验证该token是否正确、过期？如果正确和未过期endpoint则向该用户提供服务

 

Glance组件 

glance组件主要提供镜像服务，架构分为glance api 和glance registry。 

glance api负责接收客户端组件（Nova..）的 api请求，分发给glance registry

glance registry去Maria DB中检索镜像元数据，把镜像的信息返回glance api

glance api 根据glance registry返回的镜像元数据，去存储后端拉取相应的镜像，响应给客户端

 

 

 ps：

 

glance内部组件（glance-api、glance-registry）间的通信不使用消息队列；

所以在glance的配置文件中配置消息队列的socket是画蛇添足；

Cinder 

cinder主要提供块存储功能

cinder包含以下组件

cinder-api：提供rest api接口，接收客户端请求分发给cinder-scheduler（承接业务的）

cinder-scheduler: 通过算法选出合适的cinder-volume， 通过rpc把cinder-api的任务调度分发给后端 cinder-volume （调度员）

cinder-volume：负责处理具体的volume请求，由不同后端存储提供 volume 存储空间。目前各大存储厂商已经积极地将存储产品的 driver 贡献到 cinder 社区（具体干活的）

 

 

RPC机制介绍

openstack组件间通信: 调用各组件api提供的rest接口

组件内通信:基于rpc(远程过程调用)机制，而rpc机制是基于AMQP模型实现的

从rpc使用的角度出发，nova，neutron，和cinder的流程是相似的，我们以cinder为例阐述rpc机制

 

Openstack 组件内部的 RPC（Remote Producer Call）机制的实现是基于 AMQP协议(Advanced Message Queuing Protocol)作为通讯模型，从而满足组件内部架构的松耦合性。

AMQP 是用于异步消息通讯的消息中间件协议，AMQP 模型有四个重要的角色:

 

Exchange:根据 Routing key 转发消息到对应的 Message Queue 中（路由器）

Routing key：用于 Exchange 判断哪些消息需要发送对应的 Message Queue（路由表）

Publisher：消息的生产者者，publish把消息发送到Exchange，并指明Routing key，以保证消息队列（Message Queue）可以接收到消息（服务端）

Customer：消息的消费者/接受者，从消息队列（Message Queue）中取出消息（客户端）

 

 

Publisher和Exchange的类型

Publisher可以分为4类：

    Direct Publisher发送点对点的消息；（发送1对1消息）

    Topic Publisher采用“发布——订阅”模式发送消息；（发送组播）

    Fanout Publisher发送广播消息的发送；（发送广播）

    Notify Publisher同Topic Publisher，发送 Notification 相关的消息。

 

 

Exchange可以分为3类：

    1.Direct Exchange根据Routing Key进行精确匹配，只有对应的 Message Queue 会接受到消息；

    2.Topic Exchange根据Routing Key进行模式匹配，只要符合模式匹配的Message Queue都会收到消息；

    3.Fanout Exchange将消息转发给所有绑定的Message Queue。

 

 

 cinder的工作流程

虚拟机要使用存储资源，于是通过Nova rest full api 调用cinder api 

cinder api 把任务通过Exchange 扔进消息队列1，cinder scheduler从消息队列1拿到到任务

cinder shcheduler 去MariaDB获取所有cinder volume信息通过算法选择出1个最佳的cinder-volume（存储节点）

cinder shcheduler反转为Publisher通过Exchange 把任务扔进消息队列2，最佳cinder-volume（存储节点）从消息队列2拿到到存储任务

volume-backen存储节点（没有存储数据的功能），存储节点只是调用后端真实的存储设备，创建出一块设备；

 

ps:volume-backen存储节点只是在云主机创建时，只是帮助其调用后端真实存储，开辟一块存储空间，让云主机使用，开辟完成之后，云主机和这块块设备完成挂载；

 

 

 

Nova组件

没有虚拟机就没有云计算，Nova是通过调用hypervisor 创建出虚拟机；

nova主要组成:

    nova-api：接收客户请求（控制节点1）

    nova-scheduler：调度nova-api下发的请求，通过算法选择出最适合创建当前虚拟机的计算节点

------------------------------------------------------------------------------------------------------------------------------------------------

    nova-compute：通过调用 hypervisor创建出虚拟机（计算节点N）

    nova-conductor：nova-compute通过 nova-conductor连接MariaDB

ps：为啥会有nova-conductor这个 中间人？

1.Nova-computer 众多他们都要去数据库中获取Nova-api在数据库里存放的虚拟机创建信息，容易给数据库造成压力（性能考量）

2.Nova-compyte被攻破了后，黑客直接通过Nova-compute 从Maria DB中窃取虚拟机信息（安全考量）

 

 

 Nova的工作流程

 

Nova-api接收到创建虚拟机的请求，Nova-api把虚拟机创建详细信息存到Maria DB，Maria DB 把数据创建成后 响应Nova-api创建完成

Nova-api把创建虚拟机消息通过Exchange发到message queue中，Nova-scheduler从队列中获取消息

Nova-scheduler从数据库中获取 计算节点信息（安装了Nova-compute软件的服务器）拿到信息后根据特定算法选择当前最佳创建虚拟机的计算节点

Nova-scheduler把创建虚拟机的任务Exchange发到message queue（连接当前最佳创建虚拟机的计算节点的队列）

当前最佳创建虚拟机的compute接收到创建虚拟机请求，把消息放到消息队列，发送给Nova-condutor

Nova-condutor连接数据库查询到创建详细信息通过消息队列发送给compute

nova-compute调用hypervisor开始创建虚拟机......开始要网络、要镜像.....

 

ps:为什么会花费这么多心思去剖析openstack各组件的流程？

nova-compute和Nova-scheduler和Nova-api 使用同样的配置文件

有些人安装openstack的时候，在控制节点的配置文件里配置访问glance api 和Newtron api信息，你说应该配吗？

 

 

 Neutron组件架构

neutron包含组件：

    neutron-server：专门接收 客户端 rest full api请求，然后讲不通的 rest full api 请求分发到不同的neutron-plugin上

    neutron-plugin：neuton是提供网络资源的，在现实世界中会有很多 网络设备厂商，而neutron-plugin就是各厂商通过plugin插件的形式把自己的网络设备的功能通过软件的实现

    neutron-agent： 和newtron-plugin对应为neutron-plugin实现功能

 

neutron-plugin分类

 openstack刚刚兴起的时候每个网络设备厂商思科、思杰...都开发自己网络设备的插件集成到openstack，其实每个网络设备厂商开发的功能是差不多的，只是开发标准不一样，这就有一个反复造轮子、代码冗余的问题，针对这些问题 newtron-plugin一分为2。

core-plugin：Neutron中即为ML2（Modular Layer 2）提供二层网络核心功能，其他网络设备厂商基于Core-plugin开发自己的 neutron-plugin；

service-plugin：即为除core-plugin以外其它的plugin，包括三层网络 router、firewall、loadbalancer、×××、metering等等，主要实现L3-L7的网络服务。这些plugin要操作的资源比较丰富，对这些资源进行操作的REST API被neutron-server看作Extension API，需要厂家自行进行扩展。

 

core-plugin ML2核心插件

ML2插件包括Type和Mechanism2部分，这2部分又都分为Manager和Driver；

 

所以我们要使用什么网络模式就去ML2配置文件种指定；

neutron-server和各neutron-plugin部署在控制节点或者网络节点上（接收Nova 发送的api请求）

neutron agent则部署在网络节点上和计算节点上（具体实现网络功能，安装一堆交换机、路由器、VPN等Agent）

 

 neutron的工作流程

 

neutron-server接收Nova创建网络的请求，neutron-server根据Nova创建虚拟机的请求分析出 那个neutron-plugin可以干活，通过消息队列发送给该neutron-plugin；

neutron-plugin接收到需求之后又通过消息队列把需求发送给neutron-agent

neutron-agent复杂具体网络创建工作

 

OpenStack的网络模式

我们通过openstack创建出云主机之后（云主机寄生于计算节点），那么这些云主机是如何跨物理节点访问外网的呢？

针对以上问题有下列5种通信方式：

local模式：所有openstack都安装在同一节点上，通常是用于开发测试环境；

flat/dhcp-flat模式：所有云主机都正在一个大二层网络

由于以上2这种模式一般不应用于线上环境，于是着重学习以下3中模式；（vlan、grep、vxlan）

 

OSI七层网络模型复习

 vlan的中文名为"虚拟局域网"。(Virtual Local Area Network)是什么：vlan是为了反正二层交换机的广播风暴，在1个交换机里,把N个端口划分到1个虚拟逻辑网络，把1台交换机当成多个交换机用；

 

什么是OSI七层模型？

如过2台计算机想要通信，就像两个人企业合作一样，既然要一起合作就要有合同、协议的约束，OSI七层模型就是一堆大家要遵循的协议；

 

物理层：2台物理机通信的基础是要通过双绞线、光纤、无线电波在物理层面连接起来，这样就可以在这些物理连接介质中传输 高/低电压（0/1）了；

数据链路层：

那么大一堆单纯的二进制（0101010110111000110101010001000110100111000011000010001010101）发过来了，没有任何意义；

所以需要对一大堆01进行分组为 8个=1比特位=1个字节=数据帧，数据帧规定分为2部分 报头（源mac，目标mac）和数据（传输的数据）.....规定这就是以太网协议，

有了以太网协议就计算机直接就可以了；（个人理解了就是把0和1-------》有规律的东西-------》表示数据）

 

网络层：计算机多了之后在1个以太网中通行进行广播会引起广播风暴，所以利用网络（ip地址）做网络划分；

 

传输层：数据使用什么方式进行传输

 

应用层：发送数据的软件工具

OSI七层模型很复杂，其实就是从0和1开始（太极生两仪两仪生八卦................） 归根结底  就是解决 如何 把一堆0和1一步步得表示为  双方 都能看懂的数据；

 

 

 

vlan网络模式

TAP device ：每1个虚拟机在宿主机中的网卡映射，会连接到自己Linux bridge上

Linux Bridge：基于iptables实现提供端口安全组功能

Veth pair：Linux brige通过 Veth pair 连接到OpenVswitch

br-int OpenVswitch  ：帮你在一台物理服务器上虚拟出交换机功能（为宿主机中云主机划分vlan，最多4096个vlan）

Path port：就相对于1个网线连接 OpenVswitch br-int 和 OpenVswitch br-ex

br-ex OpenVswitch：关联到物理网卡，根据物理网络分配的 van id 范围（100-200），做内部虚拟机网络vlan-id 和 外部网络vlan-id间的转换

 

 

 

PS： PC/Server连接交互机使用access口，交互机之间的连接使用trunk口

access口特点：只允许1个vlan通过

trunk   口特点：运行N个vlan通过

基于以上原因openstack宿主机的连接真实交互机要设置trunk口；

 

大二层概念：

经常听人说openstack的vlan模式就是1个大二层：计算节点的open Vswitch（虽然是虚拟交互机，但也是交互机）连接着真实交互机，真实交互接连接着其他 计算节点的open Vswitch，这样就形成了1个大二层； 

特点：

数据链路层通过广播数据帧通信，产生广播风暴；

可以不使用网络节点

小规模部署（几百台云主机）

 

 

 

 

 vlan网络模式工作流程

 云主机 vm1 发数据包--------》tap设备------>Linux网桥（设置安全组）------------》OpenVswitch交互机 br-int（ 打上vlan id 1）----------------》OpenVswitch交互机 br-ex（把br-int 的vlan id 1 转换为物理交换机真实存在的valn, id vlan id 100）-------->真实交互机trunk口

ps: 如果在真实交互机层面 针对 云主机某个vlan 设置了网关，

那么在vlan网络模式下，数据包不需要经过网络节点（neutron）的虚拟机路由器，就可以访问 外网；

 

 vlan网络模式如何访问外网

在真实交换机上针对某个vlan做网关访问外网是一种访问外网的方式，还有一种方式就是经过 openstack的网络节点；

vm1通过tap设置连接到Linux网桥

网桥检查该云主机是否有安全组规则，如果没有就通过veth对放行数据包到br-int

br-int交换机广播数据帧连接它的设备都在会接收到，立即应答；如果是内网通信到此结束；如不不在同一网络没有应答该数据包，br-int交换机给数据包 打上vllan id 到了br-ex交互机

br-ex交互机把br-int交换机给数据包 打上的vllan id转换为物理网络真是存在的 vlan id，通过 trunk口转发到真实交换机

真实交换机转发到网络节点 l3-agent，l2-agent提供一堆路由器，数据包找到自己的路由器，由网络节点提供路由设备转发到外网

 

 

 

 

Gre网络模式

vlan网络模式就是基于二层包之上封装1个4个字节的vlan标识信息，其中12个bit位标识valn-id(2 的12次方)=4096，所依只能划分4096个vlan，限制了openstack网络规模；

vlan网络就是1个大二层，基于mac地址通信，交换机具有学习mac、arp功能，而主流交换机可以学习的学习的mac地址上限3W，如果一个二层中的机器规模较大交换机也撑不住；

广播风暴

基于以上4点vlan网络模式的缺点，它是无法实现大规模网络需求的；

GRE全称是Generic Routing Encapsulation，是一种协议隧道封装 gre的格式，通过三层网络模拟二层网络,类似于 vpn；

 

Gre网络模式的工作流程

 

 

 

如果两个网络之间的云主机通信

数据包在br-int 虚拟机交换机依然被打上vlan标识

但是达到br-Tunnel虚拟机交互机之后vlan id 被替代为 gre tunnel id（不在使用vlan id通信）

通过eth0网卡的外网ip封装IP包，通过交互机access口-----》互联网----》传到计算机节点2

计算节点2的br-Tunnel虚拟机解包露出gre tunnel id（可分配：24位标识=2的24方个 gre tunnel_id） ，然后根据gre tunnel id 转换成vlan id

计算节点2的br-int根据vlan id选择vlan进行广播

 

 gre网络模式总结

 gre物理上是三层通信，虚拟的二层通信模式，实现机制类似 VPN；

 gre网络模式是点到点传输需要：计算节点 2---2之间都要建立隧道，开销大；

 

 

 Vxlan网络模式

 

原始2层包+原始二层包+（1.vni id 2.组播地址）+UDP报头+IP报头

组播地址：避免了交换机广播风暴

UDP报头：udp协议无状态，无需建立隧道

 

OpenStack的存储

 

Ceph能解决什么问题？

ceph的理念就是用众多廉价的disk，联合起来，形成一套 高性能的分布式存储系统；

从1块disk说起：

如果你要买一块硬盘你会考虑哪几种因素？

读写带宽

容量

如果产品经理给你一个需求：把太平洋里的水，装进水瓶里；（先不要着急自杀.........先分析一下）

纵向扩展：造1个容量可以容纳下整个太平洋的超级水瓶（容量是可以，瓶口也要足够宽啊，否则装到猴年马月？），这就是传统存储面临的2大瓶颈，容量和带宽，既然纵向扩展成本较大，那就考虑横向扩展；

横向扩展：造很多很多很多普通水瓶，把它们联合起来接收太平洋的水（水瓶多了容量自然就大了，联合在一起协同工作带宽自然宽了）

那么如何把这么多的水瓶连接在一起协同工作呢？

所以你需要开发一款软件装在那些水瓶上（osd daemon），然后在上面封装一层管理层，通过TCP协议 对海量osd daemon进行统一调度管理

以上就是ceph存储，可以帮我们解决的问题 海量数据快速得存储和读取；

 

ceph概念

ceph本质上就是1个RADOS（Reliable, Autonomic Distributed Object Store 可靠的、自动的、分布式、对象存储）分布式存储系统；

这个分布式存储系统分为：disK集群、osd集群、Monitor集群3大集群

disk集群：由众多的廉价disk构成

osd-deamon集群：1块disk对应1个osd-daemon进程 ，对其对应的disk进行读/写操作和监控；

Monitor集群：

ceph集群有 Autonomic自动恢复的特性，可是我怎么知道哪个osd-daemon节点坏掉了呢？

于是要有1个监控全局的软件（monitor-daemon集群），monitor-daemon集群通常由众多monitor-daemon节点构成

monitor-daemon节点：（1台服务器上装上monitor-daemon进程）可以有多个？它们的角色有leader/provider/ requester   

monitor-daemon节点Monitor节点之间通过PAXOS进行选举出1个leader， 所以节点个数应该为基数个

osd-daemon相互监控组内其他osd-daemon对应的disk信息， 在disk出现故障时，找Monitor集群中的leader汇报报警信息

Monitor集群中的leader收到某个disk报警信息后，立马更新自己的cluster_map信息，Monitor集群中的provide定期向leader同步cluster_map信息，保持cluster_map信息一致性；

cluster_map信息包含 mon_map、osd_map、pg_map、crush_map 反映了ceph整体的健康状态；

 

所以宏观来讲ceph的工作流程是：

disk集群和osd-deamon集群提供存储、监控自身并向monitor-daemon集群汇报监控信息，

Monitor集群接收到osd-deamon集群的监控信息后，计算和维护crush_map信息，

客户端获取crush_map信息，才可以把数据有objct经过选择PG、os-daemon最终存储到对应得disk上

三大集群相辅相成；

 

ceph的逻辑架构

云主机客户端（qemu）要想使用ceph有2种方式：

方式1.kernel：把ceph直接映射到内核，不稳定

方式2.由调用librdb(librbdos)调用Ceph(以下主要介绍的是这种方式)

 

object：

librbd把数据（例：a.txt）存储到ceph之前，会把数据（a.txt） 切割为N个二进制块，在ceph中每1个二进制块被称为1个object（ceph存储最小单位）；

osd-daemon:

N个osd-daemon可以划为1个PG（组），1个PG里面有1个osd-daemon（组长）负责接收存储任务存储并分发给其他成员进行备份

osd-daemon还有1个重要功能就是相互监控 同1组中osd-daemon对应disk的状态，汇报给Monitor集群

PG:

由多个osd-daemon节点组成的逻辑组，降低寻找对海量osd-daemon节点的时间复杂度，PG中有个叫acting_set的有序列表排名第1位的是组长

pool存储池：

Ceph存储搭建完毕之后，使用ceph客户端命令，创建1个Pool(从逻辑层面把N个PG整合到1个Pool逻辑资源池中)，可以指定包含PG数量；

ceph osd pool create volume 128                     #ps 128 包含多少个PG

Image:

我们openstack的云主机最终想要从ceph中获取的不过是1块硬盘，那么1块硬盘是如从ceph中划分出来，提供给云主机的呢？

首先到ceph存储中，选中1个已经存在的存储池(Pool)，------->在这1个Pool里面------->划分1块逻辑空间；这块逻辑空间称为1个image，1个image就是客户端最终使用的1块硬盘；

 

Object&PG&osdaemon的关系？

1个object只能存储在1个PG上，但1个PG可以为N个object提供存储；（Object 和 PG之间是一个1对多关系）

1个PG后面可对应N个osdaemon，1个osdaemon也可以属于N个PG（PG和osdaemon之间是多对多关系）

1个osdaemon对应1块disk（osdaemon和disk之间是1对1关系）

 

 

 

 

 

ceph的网络架构

ceph集群的网络分为 集群网络和复制网络

集群网络：osd集群向Monitor集群汇报disk监控信息（连接起ceph所有的集群节点 和客户端通信）

复制网络：osd节点之间进行数据复制；

对以上2种网络的要求都必须是万兆的；

 

 

 

客户端 （openstack云主机）写入ceph流程分析

                                                                                                                                librbd 

A.文件通过librbd划分为N个二进制块，一个二进制块  成为1个object （文件----------------->objectd）         

B.Librbd连接到monitor集群中获取最新cluster_map，这就意味着客户端（librbd）掌握了整个ceph集群最新切所有的状态

C.Object通过hash算法，找出（PG）

D.PG通过crush_map找到os_daemon组长

E.OS_os_daemon组长把object存储到disk                                                                                  

F.Object 通过Hash算法在云主机对应的Image中找到PG组的组长 （object--------------->PG）

 

Nova&Cinder&Ceph的关系是什么？

Nova 调用  ------>Cinder-Api调用------>Cinder-volume---->volumen-backend---->后台存储真实存储(Maybe it`s Ceph)------------>在真实后端存储开辟一块存储空间并完成磁盘挂载

Nova---------libvirtd-----------------quem----------------------librados--------------------->后台存储真实存储(Maybe it`s Ceph)--------------->完成数据读取/写入）

ps:有一次面试：如果cinder节点故障，会影响云主机的存储数据吗？

答案：不会的，cinder已经帮助云主机在cinder连接的后端存储里开辟存储空间，只有新的云主机创建时，才会让cinder去后台存储上开辟新的存储空间；

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

安装OpenStack

OpenStack的版本更新很快，每半年更新1次（版本名称首字母顺序A-Z，名称为世界各地的地名），所以Yum仓库中已经对老的版本进行移除，我选择了一键安装的方式；

 

 

 

 

 

OpenStack日常应用

 

 

 

 

 

 

 

 

 

 

 

 

 https://www.cnblogs.com/yaohong/p/7251852.html

瞎驴

 

来源：https://www.cnblogs.com/sss4/p/10675631.html