标签：
云计算是一种基于互联网的计算方式，通过这种方式，共享的软硬件资源和信息，可以按需求提供给计算机和其他设备。用户不需要了解”云“中的基础设施细节，不必具有相应的专业知识，也无需直接控制。云计算描述了一种基于互联网的新的IT服务增加、使用和交付模式。
我们举一个例子来理解云计算，云计算中的”云“可以理解为天上的云，天上的云可以变成雨水降落到地上，落到地上的水蒸发后又变成云彩。这样就形成了一个循环。
这里的雨水表示计算资源，比如虚拟机、存储、网络等等。
云变水的过程表示获取资源的过程。
水变云的过程表示资源回收的过程。
云计算就像云水的循环过程一样，按需分配，循环利用。
云计算的本质是希望解决资源利用率、计算能力不足和成本的问题。
云计算有三种模式：
OpenStack是一个由NASA（美国国家航空航天局）和Rackspace合作研发并发起的，以Apache许可证授权的自由软件和开放源代码项目。作为一个开源的云计算管理平台项目，旨在为公共及私有云的建设与管理提供软件的开源项目，帮助服务商和企业内部实现类似于 Amazon EC2 和 S3 的云基础架构服务(Infrastructure as a Service, IaaS)。
组件逻辑关系图
虚拟机创建过程：
keystone 组件
cinder主要组成及其功能:
Cinder-api 是 cinder 服务的 endpoint，提供 rest 接口，负责处理 client 请求，并将 RPC 请求发送至 cinder-scheduler 组件。
Cinder-scheduler 负责 cinder 请求调度，其核心部分就是 scheduler_driver, 作为 scheduler manager 的 driver，负责 cinder-volume 具体的调度处理，发送 cinder RPC 请求到选择的 cinder-volume。
Cinder-volume 负责具体的 volume 请求处理，由不同后端存储提供 volume 存储空间。目前各大存储厂商已经积极地将存储产品的 driver 贡献到 cinder 社区
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：消息发送者，将消息发送的 Exchange 并指明 Routing Key，以便 Message Queue 可以正确的收到消息
Consumer：消息接受者，从 Message Queue 获取消息
消息发布者 Publisher 将 Message 发送给 Exchange 并且说明 Routing Key。Exchange 负责根据 Message 的 Routing Key 进行路由，将 Message 正确地转发给相应的 Message Queue。监听在 Message Queue 上的 Consumer 将会从 Queue 中读取消息。
Routing Key 是 Exchange 转发信息的依据，因此每个消息都有一个 Routing Key 表明可以接受消息的目的地址，而每个 Message Queue 都可以通过将自己想要接收的 Routing Key 告诉 Exchange 进行 binding，这样 Exchange 就可以将消息正确地转发给相应的 Message Queue。
Publisher可以分为4类：
Direct Publisher发送点对点的消息；
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。
AMQP消息模型
RPC 发送请求
Client 端发送 RPC 请求由 publisher 发送消息并声明消息地址，consumer 接收消息并进行消息处理，如果需要消息应答则返回处理请求的结果消息。
OpenStack RPC 模块提供了 rpc.call，rpc.cast, rpc.fanout_cast 三种 RPC 调用方法，发送和接收 RPC 请求。
1.rpc.call 发送 RPC 请求并返回请求处理结果，请求处理流程如图 5 所示，由 Topic Publisher 发送消息，Topic Exchange 根据消息地址进行消息转发至对应的 Message Queue 中，Topic Consumer 监听 Message Queue，发现需要处理的消息则进行消息处理，并由 Direct Publisher 将请求处理结果消息，请求发送方创建 Direct Consumer 监听消息的返回结果
2.rpc.cast 发送 RPC 请求无返回，请求处理流程如图 6 所示，与 rpc.call 不同之处在于，不需要请求处理结果的返回，因此没有 Direct Publisher 和 Direct Consumer 处理。
3.rpc.fanout_cast 用于发送 RPC 广播信息无返回结果
nova-api 接收rest请求
nova-scheduler 负责调度
nova-compute 负责调用虚拟化驱动，建立虚拟机等
nova-conductor 帮助nova-compute 访问数据库，并将查询结果返回给nova-compute
Neutron
在网络这一块，OpenStack经历了由nova-network（早期）到Quantum（F版本）再到Neutron（H版本）的演进过程。
流程图：
neutron-server 接到请求 --> 将请求发送到MQ --> neotron-plugins 得到请求 --> 发送请求到MQ --> neotron-agent 建立网络设备。
neutron包含组件及功能介绍：
neutron-server ：对外提供rest api，接收请求 并将请求分发到不同的 neutron-plugin 上。
neutron-plugin ： 处理 Neutron Server 发来的请求，维护 OpenStack 逻辑网络的状态， 并调用 Agent 处理请求。每个厂商基于Openstack开发了模拟自己硬件的软件，这个软件就是plugin。 在早期，每个厂商开发各自的plugin，功能也是各自实现，有大量的代码是重复的；另外，不同的厂商有不同的开发标准，导致程序的兼容性很差。针对这种情况neutron-plugin 被分为了两部分：Core-plugin 和 Service-plugin 。
- Core-plugin ： Neutron中即为ML2（Modular Layer 2），负责管理L2的网络连接。ML2中主要包括network、subnet、port三类核心资源，对三类资源进行操作的REST API被neutron-server看作Core API，由Neutron原生支持。其中：
- Network ： 代表一个隔离的二层网段，是为创建他的租户而保留的一个广播域。Subnet 和 Port 始终被分配给某个特定的network。 Network 的类型包括Flat、Vlan、VxLan、Gre等等
- Subnet：代表一个IPv4/v6的CIDR地址池，以及与其相关的配置，如网关、DNS等等，该 Subnet 中的 VM 实例随后会自动继承该配置。Subnet 必须关联一个 Network。
- Port：代表虚拟交换机上的一个虚拟交换端口。VM 的网卡连接 VIF 连接Port后，就会拥有 MAC 地址和 IP 地址，Port 的 IP 地址是从Subnet 地址池中分配的。
- Service-plugin ： 即为除core-plugin以外其它的plugin，包括l3 router、firewall、loadbalancer、VPN、metering等等，主要实现L3-L7的网络服务。这些plugin要操作的资源比较丰富，对这些资源进行操作的REST API被neutron-server看作Extension API，需要厂家自行进行扩展。
neutron-agent ： 处理 Plugin 的请求，负责在 network provider 上真正实现各种网络功能。和 plugin 是一一对应的关系，
在架构设计上， Neutron沿用了OpenStack完全分布式的思想，各组件之间通过消息机制进行通信，使得Neutron中各个组件甚至各个进程都可以运行在任意的节点上，如前面的流程图所示。这种微内核的架构使得开发者可以集中精力在网络业务的实现上。目前Neutron提供了众多的插件与驱动，基本上可以满足各种部署的需要，如果这些还难以支撑实际所需的环境，则可以方便地在Neutron的框架下扩展插件或驱动。
Neutron对Quantum的插件机制进行了优化，将各个厂商L2插件中独立的数据库实现提取出来，作为公共的ML2插件存储租户的业务需求，使得厂商可以专注于L2设备驱动的实现，而ML2作为总控可以协调多厂商L2设备共同运行”。在Quantum中，厂家都是开发各自的Service-plugin，不能兼容而且开发重复度很高，于是在Neutron中就为设计了ML2机制，使得各厂家的L2插件完全变成了可插拔的，方便了L2中network资源扩展与使用。
ML2作为L2的总控，其实现包括Type和Mechanism两部分，每部分又分为Manager和Driver。Type指的是L2网络的类型（如Flat、VLAN、VxLAN等），与厂家实现无关。Mechanism则是各个厂家自己设备机制的实现，如下图所示。当然有ML2，对应的就可以有ML3，不过在Neutron中L3的实现只负责路由的功能，传统路由器中的其他功能（如Firewalls、LB、VPN）都被独立出来实现了，因此暂时还没有看到对ML3的实际需求。
一般而言，neutron-server和各neutron-plugin部署在控制节点或者网络节点上，而neutron agent则部署在网络节点上和计算节点上。我们先来简单地分析控制端neutron-server和neutron-plugin的工作，然后再分析设备端neutron-agent的工作。
（注意，以前厂商开发的L2 plugin跟ML2都存在于neutron/plugins目录下，而可插拔的ML2设备驱动则存在于neutron/plugins/ml2/drivers目录下）
控制端的实现 —— 从neutron-server的启动开始说起。neutron-server时，主要就干了两件事，第一是启动wsgi服务器监听Neutron REST API，第二是启动rpc服务，用于core plugin与agent间的通信，两类服务作为绿色线程并发运行。从SDN的角度来看，wsgi负责Neutron的北向接口，而Neutron的南向通信机制主要依赖于rpc来实现（当然，不同厂家的plugin可能有其它的南向通信机制）。
设备端的实现 —— 控制端neutron-server通过wsgi接收北向REST API请求，neutron-plugin通过rpc与设备端进行南向通信。设备端agent则向上通过rpc与控制端进行通信，向下则直接在本地对网络设备进行配置。
OSI七层：
| 层 | 数据单元 | 典型设备 | 功能 |
|---|---|---|---|
| 应用层 | 数据 | 计算机：应用程序 | 直接和应用程序连接并提供常见的网络应用服务 |
| 表示层 | 数据 | 计算机：编码方式 | 将数据按照网络能理解的方案进行格式化 |
| 会话层 | 数据 | 计算机：建立会话 | 负责在网络中的两节点之间建立、维持和终止通信 |
| 传输层 | 数据段 | 计算机：进程和端口 | 提供端到端的交换数据的机制，检查分组编号与次序 |
| 网络层 | 数据包 | 网络：路由器 | 将网络地址转化为对应的物理地址，并且决定如何将数据从发送方传到接收方 |
| 数据链路层 | 数据帧 | 网络：交换机、网桥 | 控制物理层和网络层之间的通讯 |
| 物理层 | 比特 | 网络：集线器、网线 | 产生并检测电压，以便发送和接收携带数据的信号，提供为建立、维护和拆除物理链路所需要的机械的、电气的、功能的和规程的特性 |
应用层：就是应用软件使用的协议，如邮箱使用的POP3，SMTP、远程登录使用的Telnet、获取IP地址的DHCP、域名解析的DNS、网页浏览的http协议等；这部分协议主要是规定应用软件如何去进行通信的。
表示层：决定数据的展现（编码）形式，如同一部电影可以采样、量化、编码为RMVB、AVI，一张图片能够是JPEG、BMP、PNG等。
会话层：为两端通信实体建立连接（会话），中间有认证鉴权以及检查点记录（供会话意外中断的时候可以继续，类似断点续传）。
传输层：将一个数据/文件斩件分成很多小段，标记顺序以被对端接收后可以按顺序重组数据，另外标记该应用程序使用的端口号及提供QOS。（不同的应用程序使用不同计算机的端口号，同样的应用程序需要使用一样的端口号才能正常通信）
网络层：路由选路，选择本次通信使用的协议（http、ftp等），指定路由策略及访问控制策略。（IP地址在这一层）
数据链路层：根据端口与MAC地址，做分组（VLAN）隔离、端口安全、访问控制。（MAC地址在这一层）处理VLAN内的数据帧转发，跨VLAN间的访问，需要上升到网络层。
物理层：将数据最终编码为用0、1表示的比特流，然后传输。
网络模式
根据创建网络的用户的权限，Neutron network 可以分为：
Provider network：管理员创建的和物理网络有直接映射关系的虚拟网络。
Tenant network：租户普通用户创建的网络，物理网络对创建者透明，其配置由 Neutorn 根据管理员在系统中的配置决定
根据网络的类型，Neutron network 可以分为：Local、Flat / Flat Dhcp 、VLan 、Gre 、VxLan
1. Local —— 所有的组件全部安装在一台机器上，多用于测试环境。
2. Flat / Flat Dhcp —— Flat模型最为简单，所有的虚拟机共用一个私有IP网段，IP地址在虚拟机启动时完成注入，虚拟机间的通信直接通过HyperVisor中的网桥转发，公网流量在该网段的网关上进行NAT（Nova-network实现为开启nova-network主机内核的iptables，Neutron实现为网络节点上的l3-agent）。Flat DHCP模型与Flat区别在于网桥中开启了DHCP进程，虚拟机通过DHCP消息获得IP地址（Nova-network实现为nova-network主机中的dnsmaq，Neutron实现为网络节点上的dhcp-agent）。
优点：结构简单，稳定
缺点：全部租户都在一个水平面上，租户之间没有隔离，因为全部租户都在一个子网内，当大规模部署后，其广播风暴将会是不小的负面因素。
3. VLan
LAN 表示 Local Area Network，本地局域网，通常使用 Hub 和 Switch 来连接LAN 中的计算机。一般来说，当你将两台计算机连入同一个 Hub 或者 Switch 时，它们就在同一个 LAN 中。同样地，你连接两个 Switch 的话，它们也在一个 LAN 中。一个 LAN 表示一个广播域，它的意思是，LAN 中的所有成员都会收到 LAN 中一个成员发出的广播包。可见，LAN 的边界在路由器或者类似的3层设备。
VLAN 表示 Virutal LAN。一个带有 VLAN 功能的switch 能够同时处于多个 LAN 中。最简单地说，VLAN 是一种将一个交换机分成多个交换机的一种方法。比方说，你有两组机器，group A 和 B，你想配置成组 A 中的机器可以相互访问，B 中的机器也可以相互访问，但是A组中的机器不能访问B组中的机器。你可以使用两个交换机，两个组分别接到一个交换机。如果你只有一个交换机，你可以使用 VLAN 达到同样的效果。你在交换机上分配配置连接组A和B的机器的端口为 VLAN access ports。这个交换机就会只在同一个 VLAN 的端口之间转发包。
带 VLAN 的交换机的端口分为两类：
一个计算节点上的网络实例
它反映的网络配置如下：
Neutron 在该计算节点上做的事情：
优点：租户有隔离
缺点： 1. VLAN 使用 12-bit 的 VLAN ID，所以 VLAN 的第一个不足之处就是它最多只支持 4096 个 VLAN 网络（当然这还要除去几个预留的），对于大型数据中心的来说，这个数量是远远不够的。
2. VLAN 是基于 L2 的，所以很难跨越 L2 的边界，在很大程度上限制了网络的灵活性。
更多具体内容参考：
http://www.cnblogs.com/sammyliu/p/4626419.html
gre与vxlan请参考
http://www.cnblogs.com/sammyliu/p/4622563.html
http://www.cnblogs.com/xingyun/p/4620727.html
标签：
原文地址：http://www.cnblogs.com/resn/p/5870264.html
