2021-7-19-OpenStack基础知识学习

OpenStack基础知识学习

参考文献：Wolf_Coder,百度百科

1，云计算

1.1，出现原因

由亚马逊公司提出。1.随着业务增加公司内部的服务器不够使用，进行虚拟化技术—》2.随着公司组织架构复杂，对虚拟化技术进行二次研发—》3.公司业务要求不同，没有一定的回收策略。虚拟化技术满足不了公司业务，开发一个云计算平台。

OpenStack：是由Rackspace和NASA（美国国家航空航天局）共同开发的云计算平台， 是一个开源的 IaaS（基础设施及服务）云计算平台，让任何人都可以自行建立和提供云端运算服务，每半年发布一次，用Python语言编写

1.2，较传统架构好处

一、有效解决硬件单点故障问题

二、按需增/减硬件资源

三、BGP线路解决南北互通问题

四、按需增/减带宽

五、更有吸引力的费用支付方式

1.3，云计算简介

发展：

IT系统架构的发展到目前为止大致可以分为3个阶段：
1、 物理机架构 这一阶段，应用部署和运行在物理机上。 比如企业要上一个ERP系统，如果规模不大，可以找3台物理机，分别部署Web服务器、应用服务器和数据库服务器。 如果规模大一点，各种服务器可以采用集群架构，但每个集群成员也还是直接部署在物理机上。 我见过的客户早期都是这种架构，一套应用一套服务器，通常系统的资源使用率都很低，达到20%的都是好的。

2、虚拟化架构 决定了物理服务器的计算能力越来越强，虚拟化技术的发展大大提高了物理服务器的资源使用率。 这个阶段，物理机上运行若干虚拟机，应用系统直接部署到虚拟机上。 虚拟化的好处还体现在减少了需要管理的物理机数量，同时节省了维护成本。

3、云计算架构 虚拟化提高了单台物理机的资源使用率，随着虚拟化技术的应用，IT环境中有越来越多的虚拟机，这时新的需求产生了： 如何对IT环境中的虚拟机进行统一和高效的管理。 有需求就有供给，云计算登上了历史舞台。

云计算：计算资源像云水循环一样，按需分配，循环利用。

云服务模式：

IaaS（基础设施即服务）：用户通过网络获取虚机、存储、网络，然后用户根据自己的需求操作获取的资源，如阿里云

PaaS（平台即服务）： 将软件研发平台作为一种服务，如Eclipse

SaaS（软件即服务）： 将软件作为一种服务通过网络提供给用户，如OA系统

云应用形式：

私有云：将基础设施与软硬件资源构建于防火墙内，基于iaas构建私有云平台供企业内部使用，开源组件有：openstackk等

公有云：云平台对外开放，主要以Iaas和Paas为主，较为成熟的是Iaas，如阿里云，腾讯云等

混合云：公有云和私有云的结合，即对企业内部又对企业外部，例如AWS

云存储：云存储系统是一个以数据存储和管理为核心的云计算系统

云游戏：游戏运行云平台服务端，云平台将游戏画面解压缩后传给用户，用户端无需高配置处理器和显卡，只需要基本的视频解压缩能力即可

云物联：基于云平台实现物物相连的互联网

云安全：通过网状的大量客户端检测网络中软件的异常,获取木马，恶意程序的最新信息，推送到云平台服务端自动分析和处理，再把解决方案发送给每一个客户端

1.4，什么是Openstack？

一个开源云操作系统内核，用于构建云平台，主要实现以下五个主要特点：

资源抽象：OpenStack将各类硬件资源，通过虚拟化与软件定义的形式，抽象成虚拟的资源池；

资源调度：OpenStack根据管理员/用户的需求，将资源池中的资源分配给不同的用户，承载不同的应用；

应用生命周期管理：OpenStack可以提供初步的应用部署/撤销、自动规模调整等功能；

系统运维：OpenStack可以提供一定的系统监控能力；

人机交互：OpenStack提供人机接口，外界可通过API、CLI或图形界面的方式与OpenStack进行交互。

2，OpenStack组件

2.1，共享组件

数据库服务（ Database Service ）：MairaDB 及 MongoDB
　　消息传输（Message Queues）：RabbitMQ
　　缓存（cache）： Memcached 时间（time sync）：NTP
　　存储（storge provider）：ceph、GFS、LVM、ISICI等
　　高可用及负载均衡：pacemaker、HAproxy、keepalive、lvs等

2.1.1，消息队列RabbitMQ

1、概念：属于一个流行的开源消息队列系统。属于AMQP( 高级消息队列协议 ) 标准的一个 实现。是应用层协议的一个开放标准，为面向消息的中间件设计。用于在分布式系统中存储转发消息，在 易用性、扩展性、高可用性等方面表现不俗。

​ 消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。
​ AMQP 的主要特征是面向消息、队列、路由（包括点对点和发布 / 订阅）、可靠性、安全。

​ RabbitMQ的特点：
　　　　使用Erlang编写
　　　　支持持久化
　　　　支持HA
　　　　提供C# , erlang，java，perl，python，ruby等的client开发端

2、rabbitmq中的概念名词

Broker：简单来说就是消息队列服务器实体。

Exchange：消息交换机，它指定消息按什么规则，路由到哪个队列。

Queue：消息队列载体，每个消息都会被投入到一个或多个队列。

Binding：绑定，它的作用就是把exchange和queue按照路由规则绑定起来。

Routing Key：路由关键字， exchange根据这个关键字进行消息投递。

vhost：虚拟主机，一个broker里可以开设多个vhost，用作不同用户的权限分离。

producer：消息生产者，就是投递消息的程序。

consumer：消息消费者，就是接受消息的程序。

channel：消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务。

3、rabbitmq工作原理

MQ 是消费 - 生产者模型的一个典型的代表，一端往消息队列中不断写入消息，而另一端则可以读取或者订阅队列中的消息。 MQ 则是遵循了 AMQP协议的具体实现和产品。在项目中，将一些无需即时返回且耗时的操作提取出来，进行了异步处理，而这种异步处理的方式大大的节省了服务器的请求响应时间，从而提高了系统的吞吐量。

（ 1）客户端连接到消息队列服务器，打开一个channel。

（ 2）客户端声明一个exchange，并设置相关属性。

（ 3）客户端声明一个queue，并设置相关属性。

（ 4）客户端使用routing key，在exchange和queue之间建立好绑定关系。

（ 5）客户端投递消息到exchange。

（ 6） exchange接收到消息后，就根据消息的key和已经设置的binding，进行消息路由，将消息投递到一个或多个队列里

4、rabbitmq相关命令：

（1）查看监听的端口：

netstat -lantp | grep 5672

（2）配置文件：

vim /etc/rabbitmq/rabbitmq.config

（3）rabbitmqctl命令：

rabbitmqctl status    #查看节点状态
rabbitmqctl cluster_status      #检查集群状态
rabbitmqctl stop_app    #停止应用
rabbitmqctl join_cluster --ram rabbit@ren3    #以ram的方式加入集群
rabbitmqctl start_app    #启动应用 
rabbitmqctl reset    #重置节点

5、注意事项

（1）保证集群中至少有一个磁盘类型的节点以防数据丢失，在更改节点类型时尤其要注意。

（2）若整个集群被停掉了，应保证最后一个 down 掉的节点被最先启动，若不能则要使用 forget_cluster_node 命令将其移出集群

（3）若集群中节点几乎同时以不可控的方式 down 了此时在其中一个节点使用 force_boot 命令重启节点

（4）rabbitmq启动不起来时可以的操作：检查静态解析、删除/vat/lib/rabbitmq下的所有文件重新搭建

2.1.2，Memcache缓存系统

1、概念（key-value）（端口:11211）

**Memcached 是一个开源的、高性能的分布式内存对象缓存系统。**通过在内存中缓存数据和对象来减少读取数据库的次数，从而提高网站访问速度，加速动态WEB应用、减轻数据库负载。

2、memcache缓存流程

（1）检查客户端请求的数据是否在 Memcache 中，如果存在，直接将请求的数据返回，不在对数据进行任何操作。
（2）如果请求的数据不在 Memcache 中，就去数据库查询，把从数据库中获取的数据返回给客户端，同时把数据缓存一份 Memcache 中
（3）每次更新数据库的同时更新 Memcache 中的数据库。确保数据信息一致性。
（4）当分配给 Memcache 内存空间用完后，会使用LRU(least Recently Used ，最近最少使用 ) 策略加到其失效策略，失效的数据首先被替换掉，然后在替换掉最近未使用的数据。

3、使用Memcached应考虑的因素

• Memcached服务单点故障
  • 在Memcached集群系统中每个节点独立存取数据，彼此不存在数据同步镜像机制，如果一个Memcached节点故障或者重启，则该节点缓存在内存的数据全部会丢失，再次访问时数据再次缓存到该服务器
• 存储空间限制
  • Memcache缓存系统的数据存储在内存中，必然会受到寻址空间大小的限制，32为系统可以缓存的数据为2G，64位系统缓存的数据可以是无限的，要看Memcached服务器物理内存足够大即可
• 存储单元限制
  • Memcache缓存系统以 key-value 为单元进行数据存储，能够存储的数据key尺寸大小为250字节，能够存储的value尺寸大小为1MB，超过这个值不允许存储
• 数据碎片
  • Memcache缓存系统的内存存储单元是按照Chunk来分配的，这意味着不可能，所有存储的value数据大小正好等于一个Chunk的大小，因此必然会造成内存碎片，而浪费存储空间
• 利旧算法局限
  • Memcache缓存系统的LRU算法，并不是针对全局空间的存储数据的，而是针对Slab的，Slab是Memcached中具有同样大小的多个Chunk集合
• 数据访问安全性
  • Memcache缓存系统的慢慢Memcached服务端并没有相应的安全认证机制通过，通过非加密的telnet连接即可对Memcached服务器端的数据进行各种操作

2.2，核心组件：

身份服务（ Identity Service ）：Keystone
　　计算（ Compute ）： Nova
　　镜像服务（ Image Service ）： Glance
　　网络 & 地址管理（ Network ）： Neutron
　　对象存储（ Object Storage ）： Swift
　　块存储 (Block Storage) ： Cinder
　　UI 界面 (Dashboard) ： Horizon
　　测量 (Metering) ： Ceilometer
　　部署编排 (Orchestration) ： Heat

2.2.1，核心

1.控制台

服务名：Dashboard

项目名：Horizon

功能：web方式管理云平台，建云主机，分配网络，配安全组，加云盘

（1）概念

Horizon 为 Openstack 提供一个 WEB 前端的管理界面 (UI 服务 )通过 Horizone 所提供的 DashBoard 服务 , 管理员可以使用通过 WEB UI 对 Openstack 整体云环境进行管理 , 并可直观看到各种操作结果与运行状态。

配置文件（/etc/openstack-dashboard/local_settings）

placement端口：8778

（2）区域（Region）

(1)地理上的概念，可以理解为一个独立的数据中心，每个所定义的区域有自己独立的Endpoint；

(2)区域之间是完全隔离的，但多个区域之间共享同一个Keystone和Dashboard(目前Openstack中的Dashboard还不支持多个区域)；

(3)除了提供隔离的功能，区域的设计更多侧重地理位置的概念，用户可以选择离自己更新的区域来部署自己的服务,选择不同的区域主要是考虑那个区域更靠近自己，如用户在美国，可以选择离美国更近的区域；

(4)区域的概念是由Amazon在AWS中提出,主要是解决容错能力和可靠性；

（3）可用性区域（Availablilty Zone）

AZ是在Region范围内的再次切分，例如可以把一个机架上的服务器划分为一个AZ，划分AZ是为了提高容灾能力和提供廉价的隔离服务；

（4）Host Aggreates

一组具有共同属性的节点集合，如以CPU作为区分类型的一个属性，以磁盘（SSD\SAS\SATA）作为区分类型的一个属性，以OS（Windows\Linux）为作区分类型的一个属性；

（5）Cell

nova为了增加横向扩展以及分布式、大规模（地理位置级别）部署的能力，同时又不增加数据库和消息中间件的复杂度，引入了cell的概念，并引入了nova-cell服务。

(1)主要是用来解决OpenStack的扩展性和规模瓶颈；

(2)每个Cell都有自己独立的DB和AMQP，不与其他模块共用DB和AMQP,解决了大规模环境中DB和AMQP的瓶颈问题；

(3)Cell实现了树形结构（通过消息路由）和分级调度（过滤算法和权重算法），Cell之间通过RPC通讯，解决了扩展性问题；

2.计算

服务名：计算

项目名：Nova

功能：负责响应虚拟机创建请求、调度、销毁云主机

（1）概念

Nova 是 OpenStack 最核心的服务，负责维护和管理云环境的计算资源。OpenStack 作为 IaaS 的云操作系统，虚拟机生命周期管理也就是通过 Nova 来实现的。

在上图中可以看到，Nova 处于 Openstak 架构的中心，其他组件都为 Nova 提供支持： Glance 为 VM 提供 image；Cinder 和 Swift 分别为 VM 提供块存储和对象存储；Neutron 为 VM 提供网络连接。

（2）nova架构

<1>nova-api是整个Nova 组件的门户，接收和响应客户的 API 调用。所有对 Nova 的请求都首先由 nova-api 处理。（端口：8774,8775）

Nova-api 对接收到的 HTTP API 请求会做如下处理：

1）检查客户端传入的参数是否合法有效

2）调用 Nova 其他子服务的处理客户端 HTTP 请求

3）格式化 Nova 其他子服务返回的结果并返回给客户端

<2>nova-scheduler：*虚机调度服务*，负责决定在哪个计算节点上运行虚机。

在 /etc/nova/nova.conf 中，nova 通过 driver=filter_scheduler 这个参数来配置 nova-scheduler。

Filter scheduler 是 nova-scheduler 默认的调度器，调度过程分为两步：

1) 通过过滤器（filter）选择满足条件的计算节点（运行 nova-compute）

2) 通过权重计算（weighting）选择在最优（权重值最大）的计算节点上创建 Instance。

<3>nova-compute 是管理虚机的核心服务，在计算节点上运行。通过调用Hypervisor API实现节点上的 instance的生命周期管理。

Openstack中虚机默认的保存路径在：/var/lib/nova/instances

<4>nova-conductor：nova-compute 经常需要更新数据库，比如更新和获取虚机的状态。 出于安全性和伸缩性的考虑，nova-compute 并不会直接访问数据库，而是将这个任务委托给 nova-conductor。

<5>Console Interface

openstack-nova-api：nova门户
　　openstack-nova-conductor：帮助nova-compute访问数据库的
　　openstack-nova-console：提供多种方式访问虚机的控制台
　　openstack-nova-novncproxy：是基于web浏览器提供虚机的控制台（端口：6080）
　　openstack-nova-scheduler：负责调度虚机启动到哪一个计算节点
　　openstack-nova-placement-api：资源使用情况追踪
　　openstack-nova-spicehtml5proxy： 基于 HTML5 浏览器的 SPICE 访问
　　openstack-nova-xvpnvncproxy： 基于 Java 客户端的 VNC 访问
　　openstack-nova-consoleauth： 负责对访问虚机控制台请求提供 Token 认证
　　openstack-nova-cert： 提供 x509 证书支持

3、nova各组件的额协同工作

1. 客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（nova-api）发送请求：“帮我创建一个虚机”
2. API 对请求做一些必要处理后，向 Messaging（RabbitMQ）发送了一条消息：“让 Scheduler 创建一个虚机”
3. Scheduler（nova-scheduler）从 Messaging 获取到 API 发给它的消息，然后执行调度算法，从若干计算节点中选出节点 A
4. Scheduler 向 Messaging 发送了一条消息：“在计算节点 A 上创建这个虚机”
5. 计算节点 A 的 Compute（nova-compute）从 Messaging 中获取到 Scheduler 发给它的消息，然后在本节点的 Hypervisor 上启动虚机。
6. 在虚机创建的过程中，Compute 如果需要查询或更新数据库信息，会通过 Messaging 向 Conductor（nova-conductor）发送消息，Conductor 负责数据库访问。

以上是创建虚机最核心的步骤， 这几个步骤向我们展示了 nova-* 子服务之间的协作的方式，也体现了 OpenStack 整个系统的分布式设计思想，掌握这种思想对我们深入理解 OpenStack 会非常有帮助。

4、nova创建虚机的详细过程

　  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的信息调用配置的虚拟化驱动来创建虚拟机。

3.网络

服务名：网络(端口9696)

项目名：Neutron

功能：实现SDN（软件定义网络），提供一整套API,用户可以基于该API实现自己定义专属网络，不同厂商可以基于此API提供自己的产品实现

1、概念

Neutron 的设计目标是实现“网络即服务（Networking as a Service）”。为了达到这一目标，在设计上遵循了基于 SDN 实现网络虚拟化的原则。

SDN 模式服务— NeutronSDN( 软件定义网络 )，通过使用它，网络管理员和云计算操作员可以通过程序来动态定义虚拟网络设备。Openstack 网络中的 SDN 组件就是 Quantum。但因为版权问题而改名为Neutron 。

2、neutron网络基本概念

（1）network

Neutron 支持多种类型的 network，包括 local, flat, VLAN, VxLAN 和 GRE。

1）vlan

vlan 网络是具有 802.1q tagging 的网络。vlan 是一个二层的广播域，同一 vlan 中的 instance 可以通信，不同 vlan 只能通过 router 通信。vlan 网络可跨节点，是应用最广泛的网络类型。

2）vxlan

vxlan 是基于隧道技术的 overlay 网络。vxlan 网络通过唯一的 segmentation ID（也叫 VNI）与其他 vxlan 网络区分。vxlan 中数据包会通过 VNI 封装成 UDP 包进行传输。因为二层的包通过封装在三层传输，能够克服 vlan 和物理网络基础设施的限制。

（2）subnet

subnet 是一个 IPv4 或者 IPv6 地址段。instance 的 IP 从 subnet 中分配。每个 subnet 需要定义 IP 地址的范围和掩码。

network namespace 是一种网络的隔离机制。

（3）port

port 可以看做虚拟交换机上的一个端口。port 上定义了 MAC 地址和 IP 地址，当 instance 的虚拟网卡 VIF（Virtual Interface） 绑定到 port 时，port 会将 MAC 和 IP 分配给 VIF。

（Project，Network，Subnet，Port 和 VIF 之间关系）：

Project 1 : m Network 1 : m Subnet 1 : m Port 1 : 1 VIF m : 1 Instance

3、Neutron功能

Neutron 为整个 OpenStack 环境提供网络支持，包括二层交换，三层路由，负载均衡，防火墙和 VPN 等。

（1）二层交换switching：

Nova 的 Instance 是通过虚拟交换机连接到虚拟二层网络的。Neutron 支持多种虚拟交换机，包括 Linux 原生的 Linux Bridge 和 Open vSwitch。 Open vSwitch（OVS）是一个开源的虚拟交换机，它支持标准的管理接口和协议。

利用 Linux Bridge 和 OVS，Neutron 除了可以创建传统的 VLAN 网络，还可以创建基于隧道技术的 Overlay 网络，比如 VxLAN 和 GRE（Linux Bridge 目前只支持 VxLAN）。

（2）三层路由routing：

Instance 可以配置不同网段的 IP，Neutron 的 router（虚拟路由器）实现 instance 跨网段通信。router 通过 IP forwarding，iptables 等技术来实现路由和 NAT。

（3）负载均衡Load-Balancing：

Openstack 在 Grizzly 版本第一次引入了 Load-Balancing-as-a-Service（LBaaS），提供了将负载分发到多个 instance 的能力。LBaaS 支持多种负载均衡产品和方案，不同的实现以 Plugin 的形式集成到 Neutron，目前默认的 Plugin 是 HAProxy。

（4）防火墙Firewalling：

Neutron 通过下面两种方式来保障 instance 和网络的安全性。

1) Security Group

通过 iptables 限制进出 instance 的网络包。

2) Firewall-as-a-Service

FWaaS，限制进出虚拟路由器的网络包，也是通过 iptables 实现。

（5）OpenStack 至少包含下面几类网络类型

1）Management 网络（集群网）

用于节点之间 message queue 内部通信以及访问 database 服务，所有的节点都需要连接到 management 网络。

2）API 网络

OpenStack 各组件通过该网络向用户暴露 API 服务。Keystone, Nova, Neutron, Glance, Cinder, Horizon 的 endpoints 均配置在 API 网络上。通常，管理员也通过 API 网络 SSH 管理各个节点。

3）VM 网络（租户网）

VM 网络也叫 tenant 网络，用于 instance 之间通信。

VM 网络可以选择的类型包括 local, flat, vlan, vxlan 和 gre。

VM 网络由 Neutron 配置和管理。

4）External 网络（外网）

External 网络指的是 VM 网络之外的网络，该网络不由 Neutron 管理。 Neutron 可以将 router attach 到 External 网络，为 instance 提供访问外部网络的能力。 External 网络可能是企业的 intranet，也可能是 internet。

这几类网络只是逻辑上的划分，物理实现上有非常大的自由度。

4、neutron架构（分布式架构）

1）Neutron 通过 plugin 和 agent 提供的网络服务。
　　2）plugin 位于 Neutron server，包括 core plugin 和 service plugin。
　　3）agent 位于各个节点，负责实现网络服务。
　　4）core plugin 提供 L2 功能，ML2 是推荐的 plugin。
　　5）使用最广泛的 L2 agent 是 linux bridage 和 open vswitch。
　　6）service plugin 和 agent 提供扩展功能，包括 dhcp, routing, load balance, firewall, vpn （Virtual Private Network）等。

5、ML2

Moduler Layer 2（ML2）：是 Neutron 在 Havana 版本实现的一个新的 core plugin，用于替代原有的 linux bridge plugin 和 open vswitch plugin。 作为新一代的 core plugin，提供了一个框架，允许在 OpenStack 网络中同时使用多种 Layer 2 网络技术，不同的节点可以使用不同的网络实现机制。

**ML2 对二层网络进行抽象和建模，引入了 type driver 和 mechansim driver。**这两类 driver 解耦了 Neutron 所支持的网络类型（type）与访问这些网络类型的机制（mechanism），其结果就是使得 ML2 具有非常好的弹性，易于扩展，能够灵活支持多种 type 和 mechanism。

mechanism driver 有三种类型：

Agent-based
　　包括 linux bridge, open vswitch 等。

Controller-based
　　包括 OpenDaylight, VMWare NSX 等。

基于物理交换机
　　包括 Cisco Nexus, Arista, Mellanox 等。 比如前面那个例子如果换成 Cisco 的 mechanism driver，则会在 Cisco 物理交换机的指定 trunk 端口上添加 vlan100。

**linux bridge 和 open vswitch 的 ML2 mechanism driver 作用是配置各节点上的虚拟交换机。**linux bridge driver 支持的 type 包括 local, flat, vlan, and vxlan。open vswitch driver 除这 4 种 type 还支持 gre。

L2 population driver 作用是优化和限制 overlay 网络中的广播流量。 vxlan 和 gre 都属于 overlay 网络。

6、Core Plugin/Agent 负责管理核心实体：net, subnet 和 port。而对于更高级的网络服务，则由 Service Plugin/Agent 管理。

7、虚机获取IP

Neutron 通过 dnsmasq 提供 DHCP 服务，而 dnsmasq 通过 Linux Network Namespace 独立的把每个 network 服务都隔离

ip netns list 命令列出所有的 namespace
ip netns exec <network namespace name> <command> 　　 管理 namespace

veth pair 是一种成对出现的特殊网络设备，它们象一根虚拟的网线，可用于连接两个 namespace。

instance 获取 IP 的过程如下：
　　1）vm 开机启动，发出 DHCPDISCOVER 广播，该广播消息在整个 net 中都可以被收到。
　　2）广播到达 veth tap19a0ed3d-fe，然后传送给 veth pair 的另一端 ns-19a0ed3d-fe。dnsmasq 在它上面监听，dnsmasq 检查其 host 文件，发现有对应项，于是dnsmasq 以 DHCPOFFER 消息将 IP（192.168.254.18）、子网掩码（255.255.255.0）、地址租用期限等信息发送给 vm。
　　3）vm 发送 DHCPREQUEST 消息确认接受此 DHCPOFFER。
　　4）dnsmasq 发送确认消息 DHCPACK，整个过程结束。

8、VXLAN

VXLAN 为 Virtual eXtensible Local Area Network。正如名字所描述的，VXLAN 提供与 VLAN 相同的以太网二层服务，但拥有更强的扩展性和灵活性。与 VLAN 相比，
VXLAN 有下面几个优势：

1）支持更多的二层网段。
　　VLAN 使用 12-bit 标记 VLAN ID，最多支持 （2^12）4094 个 VLAN，这对大型云部署会成为瓶颈。VXLAN 的 ID （VNI 或者 VNID）则用 24-bit 标记，支持 （2^24）16777216 个二层网段。

2）能更好地利用已有的网络路径。
　　VLAN 使用 Spanning Tree Protocol 避免环路，这会导致有一半的网络路径被 block 掉。VXLAN 的数据包是封装到 UDP 通过三层传输和转发的，可以使用所有的路径。

3）避免物理交换机 MAC 表耗尽。
　　由于采用隧道机制，TOR (Top on Rack) 交换机无需在 MAC 表中记录虚拟机的信息。

VXLAN 是将二层建立在三层上的网络。通过将二层数据封装到 UDP 的方式来扩展数据中心的二层网段数量。

VXLAN 是一种在现有物理网络设施中支持大规模多租户网络环境的解决方案。VXLAN 的传输协议是 IP + UDP。

VXLAN 包的格式如下：

9、Open vSwitch（东西流向：VM–VM 南北流向：VM–外网）（neutron-openvswitch端口：6633）

Open vSwitch 中的网络设备：（端口：6640）

br-ex：连接外部（external）网络的网桥。
　　br-int：集成（integration）网桥，所有 instance 的虚拟网卡和其他虚拟网络设备都将连接到该网桥。
　　br-tun：隧道（tunnel）网桥，基于隧道技术的 VxLAN 和 GRE 网络将使用该网桥进行通信。
　　tap interface：命名为 tapXXXX。
　　linux bridge：命名为 qbrXXXX。
　　veth pair：命名为 qvbXXXX, qvoXXXX
　　OVS integration bridge：命名为 br-int。
　　OVS patch ports：命名为 int-br-ethX 和 phy-br-ethX（X 为 interface 的序号）。
　　OVS provider bridge：命名为 br-ethX（X 为 interface 的序号）。
　　物理 interface：命名为 ethX（X 为 interface 的序号）。
　　OVS tunnel bridge：命名为 br-tun。

ovs网络的相关命令：

ovs-vsctl add-br br-ex``ovs-vsctl add-port br-ex ens38``ovs-vsctl show

10、虚机通外网（iptables-SNAT）

11、外网访问虚机（floating ip）（iptables-DNAT）

2.2.2，存储

1.对象存储

服务名：对象存储

项目名：Swift

功能：REST风格的接口和扁平的数据组织结构。RESTFUL HTTP API来保存和访问任意非结构化数据，ring环的方式实现数据自动复制和高度可以扩展架构，保证数据的高度容错和可靠性

2.块存储

服务名：块存储

项目名：Cinder

功能：提供持久化块存储，即为云主机提供附加云盘。

（1）block storage

操作系统获得存储空间的方式一般有两种：

（1）通过某种协议（SAS,SCSI,SAN,iSCSI 等）挂接裸硬盘，然后分区、格式化、创建文件系统；或者直接使用裸硬盘存储数据（数据库）
　　（2）通过 NFS、CIFS 等 协议，mount 远程的文件系统

第一种裸硬盘的方式叫做 Block Storage（块存储），每个裸硬盘通常也称作 Volume（卷）

第二种叫做文件系统存储。NAS 和 NFS 服务器，以及各种分布式文件系统提供的都是这种存储。

（2）cinder的具体功能：

（1）提供 REST API 使用户能够查询和管理 volume、volume snapshot 以及 volume type

（2）提供 scheduler 调度 volume 创建请求，合理优化存储资源的分配

（3）通过 driver 架构支持多种 back-end（后端）存储方式，包括 LVM，NFS，Ceph 和其他诸如 EMC、IBM 等商业存储产品和方案

（3）cinder架构

（4）cinder子组件

1）Cinder-api**：**接收 API 请求，调用 cinder-volume ；（端口：8776）

2）Cinder-volume**：**管理 volume 的服务，与 volume provider 协调工作，管理 volume 的生命周期。运行 cinder-volume 服务的节点被称作为存储节点。

3）cinder-scheduler**：**scheduler 通过调度算法选择最合适的存储节点创建 volume。

4）volume provider**：**数据的存储设备，为 volume 提供物理存储空间。 cinder-volume 支持多种 volume provider，每种 volume provider 通过自己的 driver 与cinder-volume 协调工作。

5）Message Queue**：**Cinder 各个子服务通过消息队列实现进程间通信和相互协作。因为有了消息队列，子服务之间实现了解耦，这种松散的结构也是分布式系统的重要特征。

6）Database Cinder **：**有一些数据需要存放到数据库中，一般使用 MySQL。数据库是安装在控制节点上。

（5）cinder各组件的协同工作

1）客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（cinder-api）发送请求：“帮我创建一个 volume”

2）API 对请求做一些必要处理后，向 Messaging（RabbitMQ）发送了一条消息：“让 Scheduler 创建一个 volume”

3）Scheduler（cinder-scheduler）从 Messaging 获取到 API 发给它的消息，然后执行调度算法，从若干计存储点中选出节点 A

4）Scheduler 向 Messaging 发送了一条消息：“让存储节点 A 创建这个 volume”

5）存储节点 A 的 Volume（cinder-volume）从 Messaging 中获取到 Scheduler 发给它的消息，然后通过 driver 在 volume provider 上创建 volume。

2.2.3，共享服务

1.认证服务

服务名：认证服务

项目名：Keystone

功能：为访问openstack各组件提供认证和授权功能，认证通过后，提供一个服务列表（存放你有权访问的服务），可以通过该列表访问各个组件。

（1）概念（端口：5000,35357）

keystone 是OpenStack的组件之一，用于为OpenStack家族中的其它组件成员提供统一的认证服务，包括身份验证、令牌的发放和校验、服务列表、用户权限的定义等等。云环境中所有的服务之间的授权和认证都需要经过 keystone. 因此 keystone 是云平台中第一个即需要安装的服务。

作为 OpenStack 的基础支持服务，Keystone 做下面这几件事情：

1）管理用户及其权限

2）维护 OpenStack Services 的 Endpoint

3）Authentication（认证）和 Authorization（鉴权）

Authentication 是 Keystone 验证 User 身份的过程。User 访问 OpenStack 时向 Keystone 提交用户名和密码形式的 Credentials，Keystone 验证通过后会给 User 签发一个 Token 作为后续访问的 Credential。

安全包含两部分：**Authentication（认证）**和 Authorization（鉴权）

Authentication 解决的是“你是谁？”的问题

Authorization 解决的是“你能干什么？”的问题

Keystone 借助 Role 实现 Authorization：

Openstack对User的验证除了身份验证，还需要鉴别 User 对某个Service是否有访问权限。Policy用来定义什么角色对应什么权限。对Keystone来说，Policy其实是一个JSON文件，默认是 /etc/keystone/policy.json 。通过Policy，Keystone实现了对User的权限管理。

（2）基本框架

Token： 用来生成和管理token

Catalog：用来存储和管理service/endpoint

Identity：用来管理tenant/user/role和验证

Policy：用来管理访问权限

（3）认证流程

2.镜像服务

服务名：镜像服务

项目名：Glance

功能：为云主机安装操作系统提供不同的镜像选择

（1）概念

Glance是Openstack项目中负责镜像管理的模块，其功能包括虚拟机镜像的查找、注册和检索等。 Glance提供Restful API可以查询虚拟机镜像的metadata及获取镜像。 Glance可以将镜像保存到多种后端存储上，比如简单的文件存储或者对象存储。

（2）glance架构

1）glance-api 是系统后台运行的服务进程。 对外提供 REST API，响应 image 查询、获取和存储的调用。（端口：9292）

2）glance-registry 是系统后台运行的服务进程。 负责处理和存取 image 的 metadata，例如 image 的大小和类型。（端口：9191）

glance支持多种格式的 image，包括：Raw，vmdk，ISO，QCOW2等

3）store backend：Glance 自己并不存储 image。 真正的 image 是存放在 backend 中的。 Glance 支持多种 backend。包括：1. A directory on a local file system（这是默认配置）2. GridFS 3. ceph RBD 4. Amazon S3 5. Sheepdog 6. OpenStack Block Storage (Cinder) 7. OpenStack Object Storage (Swift) 8. VMware ESX；具体使用哪种哪种 backend，是在 /etc/glance/glance-api.conf 中配置的

（3）查看保存目录

每个 image 在目录下都对应有一个文件，文件以 image 的 ID 命名。

（4）glance创建镜像

OpenStack 为终端用户提供了 Web UI（Horizon）和命令行 CLI 两种交换界面。

CLI创建image：

openstack image create "cirros"   --file cirros-0.3.3-x86_64-disk.img.img   --disk-format qcow2 --container-format bare --public

3.计费服务

服务名：计费服务

项目名：Ceilometer

功能：收集云平台资源使用数据，用来计费或者性能监控

2.2.4，高层服务

1.编排服务

服务名：编排服务

项目名：Heat

功能：自动化部署应用，自动化管理应用的整个生命周期.主要用于Paas

3，组建详情和运行流程

组件之间逻辑关系：

openstack新建云主机流程图:

虚拟机启动过程如下：

1. 界面或命令行通过RESTful API向keystone获取认证信息。
2. keystone通过用户请求认证信息，并生成auth-token返回给对应的认证请求。
3. 界面或命令行通过RESTful API向nova-api发送一个boot instance的请求（携带auth-token），包含需要创建的虚拟机信息，如CPU、内存、硬盘、网络等。
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发送对应的创建虚拟机请求的消息（调度到选定的nova-compute上创建VM）。
13. nova-compute会从对应的消息队列中获取创建虚拟机请求的消息（新版的openstack，不允许Nova-compute直接连接数据库，只能通过nova-conductor去调用），有多个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的信息调用配置的虚拟化驱动来创建虚拟机。

4，OpenStack支持的网络模式（vlan/gre/vxlan）

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

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

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

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

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

4.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提供一堆路由器，数据包找到自己的路由器，由网络节点提供路由设备转发到外网

4.2，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之间都要建立隧道，开销大；

4.3，Vxlan网络模式

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

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

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

5，OpenStack支持的分布式存储（Ceph）

5.1，Ceph能解决什么问题？

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

从1块disk说起：

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

读写带宽，容量

如果产品经理给你一个需求：把太平洋里的水，装进水瓶里；

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

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

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

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

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

5.2，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上

三大集群相辅相成；

5.3，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块硬盘；

5.4，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关系）

5.5，Ceph的网络架构

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

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

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

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

5.6，客户端（openStack云主机）写入Ceph流程分析

A.文件通过librbd划分为N个二进制块，一个二进制块 成为1个object （文件—【librbd】—>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）

file—[librbd]—》object—[hash]—》pg—[crush算法]—》osddaemon

5.7，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去后台存储上开辟新的存储空间；

对1关系）

[外链图片转存中…(img-OSSF7X9h-1626852078303)]

[外链图片转存中…(img-8TR72feA-1626852078304)]

5.5，Ceph的网络架构

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

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

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

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

[外链图片转存中…(img-BRn1p7zH-1626852078305)]

5.6，客户端（openStack云主机）写入Ceph流程分析

A.文件通过librbd划分为N个二进制块，一个二进制块 成为1个object （文件—【librbd】—>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）

file—[librbd]—》object—[hash]—》pg—[crush算法]—》osddaemon

5.7，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去后台存储上开辟新的存储空间；