openstack三种网络模式(openstack三种网络包括)

‍本文详细介绍了Openstack的网络原理和实现，主要内容包括：Neutron的网络架构及网络模型还有neutron虚拟化的实现和对二三层网桥的理解。一、Neutron概述Neutron是一个用Python写的分布式软件项目，用来实现OpenStack中的虚拟网络服务，实现软件定义网络。Neutron北向有自己的REST API，中间有自己的业务逻辑层，有自己的DB和进程之间通讯的消息机制。同时Neutron常见的进程包括Neutron-server和Neutron-agent，分布式部署在不同的操作系统。OpenStack发展至今，已经经历了20个版本。虽然版本一直在更替，发展的项目也越来越多，但是Neutron作为OpenStack三大核心之一，它的地位是不会动摇的。只不过当初的Neutron也只是Nova项目的一个模块而已，到F版本正式从中剥离，成为一个正式的项目。从Nova-Network起步，经过Quantum，多年的积累Neutron在网络各个方面都取得了长足的发展。其主要的功能为：（1）支持多租户隔离（2）支持多种网络类型同时使用（3）支持隧道技术（VXLAN、GRE）（4）支持路由转发、SNAT、DNAT技术（5）支持Floating IP和安全组多平面租户私有网络图中同时有VXLAN和VLAN两种网络，两种网络之间互相隔离。租户A和B各自独占一个网络，并且通过自己的路由器连接到了外部网络。路由器为租户的每个虚拟机提供了Float IP，完成vm和外网之间的互相访问。二、Neutron架构及网络模型1、Neutron架构Neutron-sever可以理解为类似于nova-api那样的一个专门用来接收API调用的组件，负责将不同的api发送到不同Neutron plugin。Neutron-plugin可以理解为不同网络功能实现的入口，接收server发来的API，向database完成一些注册信息。然后将具体要执行的业务操作和参数通知给对应的agent来执行。Agent就是plugin在设备上的代理，接受相应的plugin通知的业务操作和参数，并转换为具体的命令行操作。总得来说，server负责交互接收请求，plugin操作数据库，agent负责具体的网络创建。2、Neutron架构之Neutron-Server（1）Neutron-server的本质是一个Python Web Server Gateway Interface（WSGI），是一个Web框架。（2）Neutron-server接收两种请求：REST API请求：接收REST API请求，并将REST API分发到对应的Plugin（L3RouterPlugin）。RPC请求：接收Plugin agent请求，分发到对应的Plugin（NeutronL3agent）。3、Neutron架构之Neutron-PluginNeutron-plugin分为Core-plugin和Service-plugin。Core-plugin：ML2负责管理二层网络，ML2主要包括Network、Subnet、Port三类核心资源，对三类资源进行操作的REST API是原生支持的。Service-plugin：实现L3-L7网络，包括Router、Firewall、VPN。4、Neutron架构之Neutron-Agent（1）Neutron-agent配置的业务对象是部署在每一个网络节点或者计算节点的网元。（2）网元区分为PNF和VNF：PNF：物理网络功能，指传统的路由器、交换机等硬件设备VNF：虚拟网络功能，通过软件实现的网络功能（二层交换、三层路由等）（3）Neutron-agent三层架构如下图：Neutron-agent架构分为三层，北向为Neutron-server提供RPC接口，供Neutron server调用，南向通过CLI协议栈对Neutron VNF进行配置。在中间会进行两种模型的转换，从RPC模型转换为CLI模型。5、Neutron架构之通信原理（1）Neutron是OpenStack的核心组件，官网给出Neutron的定义是NaaS。（2）Naas有两层含义：对外接口：Neutron为Network等网络资源提供了RESTful API、CLI、GUI等模型。内部实现：利用Linux原生或者开源的虚拟网络功能，加上硬件网络，构建网络。Neutron接收到API请求后，交由模块WSGI进行初步的处理，然后这个模块通过Python API调用neutron的Plugin。Plugin做了相应的处理后，通过RPC调用Neutron的Agent组件，agent再通过某种协议对虚拟网络功能进行配置。其中承载RPC通信的是AMQP server，在部署中常用的开源软件就是RabbitMQ6、Neutron架构之控制节点网络模型控制节点没有实现具体的网络功能，它对各种虚拟设备做管理配合的工作。（1）Neutron：Neutron-server核心组件。（2）API/CLI：Neutron进程通过API/CLI接口接收请求。（3）OVS Agent：Neutron通过RPC协议与agent通信。控制节点部署着各种服务和Neutron-server，Neutron-server通过api/cli接口接收请求信息，通过RPC和Agent进行交互。Agent再调用ovs/linuxbridge等网络设备创建网络。7、Neutron架构之计算节点网络模型（1）qbr：Linux Bridge网桥（2）br-int：OVS网桥（3）br-tun：OVS隧道网桥（4）VXLAN封装：网络类型的转变8、Neutron架构之网络节点网络模型网络节点部署了Router、DHCP Server服务，网桥连接物理网卡。（1）Router：路由转发（2）DHCP： 提供DNS、DHCP等服务。（3）br-ex： 连接物理网口，连接外网三、Neutron虚拟化实现功能及设备介绍1、Neutron虚拟化实现功能Neutron提供的网络虚拟化能力包括：（1）二层到七层网络的虚拟化：L2（virtual Switch）、L3（virtual Router 和 LB）、L47（virtual Firewall ）等（2）网络连通性：二层网络和三层网络（3）租户隔离性（4）网络安全性（5）网络拓展性（6）REST API（7）更高级的服务，包括 LBaaS，FWaaS，VPNaaS 等2、Neutron虚拟化功能之二层网络（1）按照用户权限创建网络：Provider network：管理员创建，映射租户网络到物理网络Tenant network：租户创建的普通网络External network：物理网络（2）按照网络类型：Flat network：所有租户网络在一个网络中Local network：只允许在服务器内通信，不通外网VLAN network：基于物理VLAN实现的虚拟网络VXLAN network：基于VXLAN实现的虚拟网络3、Neutron虚拟化实现功能之租户隔离Neutron是一个支持多租户的系统，所以租户隔离是Neutron必须要支持的特性。（1）租户隔离三种含义：管理面隔离、数据面的隔离、故障面的隔离。（2）不同层次租户网络的隔离性租户与租户之间三层隔离同一租户不同网络之间二层隔离同一租户同一网络不同子网二层隔离（3）计算节点的 br-int 上，Neutron 为每个虚机连接 OVS 的 access port 分配了内部的 VLAN Tag。这种 Tag 限制了网络流量只能在 Tenant Network 之内。（4）计算节点的 br-tun 上，Neutron 将内部的 VLAN Tag 转化为 VXLAN Tunnel ID，然后转发到网络节点。（5）网络节点的 br-tun 上，Neutron 将 VXLAN Tunnel ID 转发了一一对应的 内部 VLAN Tag，使得 网络流被不同的服务处理。（6）网络节点的 br-int 上连接的 DHCP 和 L3 agent 使用 Linux Network Namespace 进行隔离。4、Neutron虚拟化实现功能之租户网络安全除了租户隔离以外 Neutron还提供数据网络与外部网络的隔离性。（1）默认情况下，所有虚拟机通过外网的流量全部走网络节点的L3 agent。在这里，内部的固定IP被转化为外部的浮动IP地址（1）Neutron还利用Linux iptables特性，实现其Security Group特性，从而保证访问虚机的安全性（3）Neutron利用网络控制节点上的Network Namespace中的iptables，实现了进出租户网络的网络防火墙，从而保证了进出租户网络的安全性。5、Neutron虚拟化设备（1）端口：Port代表虚拟网络交换机上的一个虚拟交换机端口虚拟机的网卡连接到Port上就会拥有MAC地址和IP地址（2）虚拟交换机：Neutron默认采用开源的Openvswitch，同时还支持Linux Bridge（3）虚拟路由器VR：路由功能一个VR只属于一个租户，租户可以有多个VR一个VR可以有若干个子网VR之间采用Namespace隔离四、Neutron网桥及二三层网络理解1、Neutron-Local-Bridge仅用于测试；网桥没有与物理网卡相连VM不通外网。图中创建了两个local network，分别有其对应的qbr网桥。Vm123的虚拟网卡通过tap连接到qbr网桥上。其中2和3属于同一个network可以通信，1属于另一个网络不能和23进行通信。并且qbr网桥不连物理网卡，所以说local网络虚拟机只能同网络通信，不能连通外网。2、Neutron-Flat-BridgeLinux Bridge直接与物联网卡相连每个Flat独占一个物理网卡配置文件添加响应mappingFlat网络是在local网络的基础上实现不同宿主机之间的二层互联，但是每个flat network都会占用一个宿主机的物理接口。其中qbr1对应的flatnetwork 连接 eth1 qbr2，两个网络的虚机在物理二层可以互联。其它跟local network类似。3、Neutron-VLAN-Bridge在基于linux bridge的vlan网络中，eht1物理网卡上创建了两个vlan接口，1.1连接到qbr1网桥，1.2连接到了qbr2网桥。在这种情况下vm通过eth1.1或者eth1.2发送到eth1的包会被打上各自的vlan id。此时vm2和vm3属于同一个network所以是互通的，vm与vm2和vm3不通。4、Neutron-VXLAN-Bridge这个是以Linux bridge作agent的Vxlan网络：Vxlan网络比Vxlan网络多了个VXLAN隧道，在Openstack中创建好内部网络和实例后，agent就会在计算节点和网络节点创建一对vxlan vtep.组成隧道的两个端点。Vxlan连接在eth0网口。在网络节点多了两个组件dhcp 和router，他们分别通过一对veth与qbr网桥连接在一起，多个dhcp和路由之间使用namesapce隔离，当vm产生ping包时，发往linux 网桥qbr1，通过网桥在vxlan12上封装数据包，数据通过eth0网卡出计算节点到网络节点的eth0，在vxlan12解包。到达路由器之后经过nat地址转换，从eth1出去访问外网，由租户网络到运营商网络再到外部网络。5、Neutron-VLAN-OVS与Linux bridge不同，openvswitch 不是通过eth1.1 eth1.2这样的vlan接口来隔离不同的vlan，而是通过openvswitch的流表规则来指定如何对进出br-int的数据进行转发，实现不同vlan的隔离。图中计算节点的所有虚拟机都连接在int网桥上，虚拟机分为两个网络。Int网桥会对到来的数据包根据network的不同打上vlan id号，然后转发到eth网桥,eth网桥直连物理网络。这时候流量就从计算节点到了网络节点。网络节点的ehx int网桥的功能相似，多了一个ex网桥，这个网桥是管理提前创建好的，和物理网卡相连，ex网桥和int网桥之间通过一对patch-port相连，虚拟机的流量到达int网桥后经过路由到ex网桥。6、Neutron-VXLAN-OVSVxlan的模型和vlan的模型十分相似，从表面上来看，他俩相比只有一个不同,vlan对应的是ethx网桥，而vxlan对应的是tun网桥。在这里ethx和tun都是ovs网桥，所以说两者的差别不是实现组件的差别而是组件所执行功能的差别，ethx执行的是普通二层交换机的功能，tun执行的是vxlan中的vtep的功能，图中俩tun对应的接口ip就是vxlan的隧道终结点ip。所以说虚机的数据包在到达tun网桥之前是打的是vlan tag，而到达tun之后会发生网络类型的转换，从vlan封装为vxlan然后到达网络节点。而之前的vlan类型的网络，虚机数据包的类型一直都是vlan。7、物理的二层与虚拟的二层（VLAN模式)（1）物理的二层指的是：物理网络是二层网络，基于以太网协议的广播方式进行通信。（2）虚拟的二层指的是：Neutron实现的虚拟网络也是二层网络（openstack的vm机所用的网络必须是大二层），也是基于以太网协议的广播方式进行通信，但毫无疑问的是该虚拟网络是依赖于物理的二层网络。（3）物理二层+虚拟二层的典型代表：VLAN网络模式。8、物理的三层与虚拟的二层（GRE模式与VXLAN模式）（1）物理三层指的是：物理网络是三层网络，基于IP路由的方式进行通信。（2）虚拟的二层指的是：Neutron实现的虚拟网络仍然是二层网络（openstack的vm机所用的网络必须是大二层），仍然是基于以太网的广播方式进行通信，但毫无疑问的是该虚拟机网络是依赖于物理的三层网络，这点有点类似于VPN的概念，根本原理就是将私网的包封装起来，最终打上隧道的ip地址传输。（3）物理三层+虚拟二层的典型代表：GRE模式与VXLAN模式。
OpenStack 是一个开源云平台，主要由私有云供应商和提供公共云服务的商业公司使用，这些公共云服务将 OpenStack 作为其基础架构的一部分进行部署。埃科锐的私有云搭建允许企业和应用程序所有者将基础设施作为服务使用，而无需考虑安装服务器、存储和网络的复杂性∞
OpenStack 起源于Rackspace Hosting 和 NASA 的联合项目，它是一个流行的云平台，有超过 740 个组织与开源平台相关联。 它广泛用于提供私有云服务的数据中心。 此外，OpenStack 安装支持基础架构即服务 (IaaS) 模型，例如我们在 Accrets.com 上的 OpenStack IaaS 解决方案提供了一种新的模型∞
openstack.org 网站指出，OpenStack“控制着整个数据中心的大型计算、存储和网络资源池； 所有这些都通过具有通用身份验证机制的 API 进行管理和配置。” OpenStack 还为系统管理员提供了基于 Web 的仪表板、命令行工具和 RESTful API 来管理这些资源。它允许用户通过 Web 界面配置资源。埃科锐国际通过搭建OpenStack云平台对计算、网络、存储和控制服务等进行管理进而加速和优化企业的云之旅∞

对于每一个刚接触到OpenStack的新人而言，安装无疑是最困难的，同时这也客观上提高了大家学习OpenStack云计算的技术门槛。想一想，自己3年前网上偶然接触到OpenStack时，一头茫然，手动搭建一个多节点环境时居然用了3个星期。 时至今日，真是感触颇多，从某种角度而言，也很庆幸当时自己并未因困难而放弃OpenStack，否则，应该是去做其他领域了吧！言归正传，咱们就来数落数落部署OpenStack都有哪些方式吧。这里，我们根据使用者群体的不同类型来进行分类和归纳：个人使用方面DevStack无疑，在可预见的未来时间内，DevStack仍将是众多开发者们的首选安装方式或工具。该方式主要是通过配置参数，执行shell脚本来安装一个OpenStack的开发环境。Github:https://github.com/openstack-dev/devstackWiki:https://wiki.openstack.org/wiki/DevStackRdoRdo是由Red Hat开源的一款部署OpenStack的工具，同DevStack一样，支持单节点和多节点部署。但Rdo只支持CentOS系列的操作系统。需要注意的是，该项目并不属于OpenStack官方社区项目。Docs：https://www.rdoproject.org/install/quickstart手动部署手动部署all-in-one、multi-node、multi-HA-node环境。其他企业、团体方面PuppetPuppet由Ruby语言编写。应当说，Puppet是进入OpenStack自动化部署中的早期一批项目，历史还算悠久。目前，它的活跃开发群体们是Red hat、 Mirantis、UnitedStack等。Redhat自从收购Ansible之后，如今仍然保持强势劲头在PuppetOpenStack项目中的Commit数量和质量，其技术实力不容小觑；Mirantis出品的Fuel部署工具中，大量的模块代码便使用的是Puppet。就国内而言，UnitedStack是Puppet社区贡献和使用的最大用户。Github：https://github.com/openstack/puppet-keystoneGovernance：Wiki：https://wiki.openstack.org/wiki/PuppetAnsibleAnsible是新近出现的自动化运维工具，已被RedHat收购。基于Python开发，集合了众多运维工具（puppet、cfengine、chef、saltstack等）的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能，它一方面总结了Puppet的设计上的得失，另一方面也改进了很多设计。比如是基于SSH方式工作，故而不需要在被控端安装客户端。使得在和OpenStack结合上没有历史包袱，更加能够轻装上阵，未来发展潜力不容小觑号称是“你一直寻找的下一代Iaas”的Zstack，使用到的部署工具也是基于Ansible。Openstack-ansible项目，最早是由老牌Rackspace公司在Launchpad官网上注册。在最新的Ansible OpenStack项目社区Commit贡献中，Rackspace也可谓是遥遥领先，而紧随其后的是Red Hat、国内九州云等公司。Github：https://github.com/openstack/openstack-ansibleSaltStackSaltStack也是一款开源的自动化部署工具，基于Python开发，实现了批量系统配置、批量程序部署、批量运行命令等功能，和Ansible也是挺相近的。不同之一是，由于SaltStack的master和minion认证机制和工作方式，需要在被控端安装minion客户端，在加之其他原因，自然和Ansible相比，其优缺点便很明显了。需要注意的是，使用Saltstack部署OpenStack，并不属于OpenStack社区项目。目前，主要还是处于用户自研自用的阶段。据笔者所知，目前国内的携程应该是使用Saltstack部署OpenStack规模最大的用户。Saltstack部署OpenStack示例：https://github.com/luckpenguin/saltstack_openstackSaltstack部署OpenStack模块：TripleOTripleo项目最早由HP于2013.4在launchpad上注册BP。用于完成OpenStack的安装与部署。TripleO全称“OpenStack OnOpenStack”，意思即为“云上云”，可以简单理解为利用OpenStack来部署OpenStack，即首先基于V2P(和P2V相反，也就是指把虚拟机的镜像迁移到物理机上)的理念事先准备好一些OpenStack节点（计算、存储、控制节点）的镜像，然后利用已有openstack环境的裸机服务Ironic项目去部署裸机，软件安装部分的diskimage-builder，最后通过Heat项目和镜像内的DevOps工具(PuppetOr Chef)再在裸机上配置运行openstack。和其他部署工具不同的是，TripleO利用OpenStack本来的基础设施来部署OpenStack，基于Nova、 Neutron、Ironic和Heat，来自动化部署和伸缩OpenStack集群。应当确切的说，TripleO项目属于当前OpenStack社区主推的“Big Tent”开发模式下的big tentproject（OpenStack下的项目分为三种，core project: nova/neutron等核心项目，big tentproject: 非核心项目，但也被OpenStack 基金会接受；第三种就是其它项目，只是放在OpenStack下，但是社区还没有接受）。在该项目的社区Commit贡献上，Red hat可谓是遥遥领先，而紧随其后的是IBM等公司。Wiki：https://wiki.openstack.org/wiki/TripleOKolla在国内一些互联网资料上，常看到关于kolla是TripleO项目的一部分这样的描述，其实是不准确的。真实的是，Kolla项目起源于Tripleo项目，时至今日，与它没有任何关系（虽然它们的目标都是做自动化部署，但走的道路却不同）。比之于Tripleo和其他部署工具，Kolla走的是docker容器部署路线。kolla项目起源于TripleO项目，聚焦于使用docker容器部署OpenStack服务。该项目由Cisco于2014年9月提出，是OpenStack的孵化项目。当前Kolla项目在Kollagluerepo提供了以下服务的docker镜像。 # docker search kollaglueKolla的优势和使用场景，体现在如下几个方面：原子性的升级或者回退OpenStack部署；基于组件升级OpenStack；基于组件回退OpenStack；这里，我们予以拆分来理解：Kolla的最终目标是为OpenStack的每一个服务都创建一个对应的Docker Image，通过DockerImage将升级的粒度减小到Service级别，从而使升级时，对OpenStack影响能达到最小，并且一旦升级失败，也很容易回滚。升级只需要三步：Pull新版本的容器镜像，停止老版本的容器服务，然后启动新版本容器。回滚也不需要重新安装包了，直接启动老版本容器服务就行，非常方便。Kolla是通过Docker Compose来部署OpenStack集群的，现在主要是针对裸机部署的，所以在部署Docker Container时，默认的网络配置都是Host模式。首先，只需要通过一个命令就可以把管理节点部署完成，这个命令是调用DockerCompose来部署OpenStack的所有服务，然后我们可以在每一个计算节点上通过DockerCompose安装计算节点需要的服务，就能部署一个OpenStack集群。因为Kolla的DockerImage粒度很小，它针对每个OpenStack服务都有特定的Image，所以我们也可以通过DockerRun来操作某个具体的OpenStack服务。目前，我所在的公司九州云的一位同事近日获得提名成为Kolla项目Core。为OpenStack社区中增添了一份来自于中国的力量。FuelFuel是针对OpenStack生产环境目标（非开源）设计的一个端到端”一键部署“的工具，大量采用了Python、Ruby和JavaScript等语言。其功能含盖自动的PXE方式的操作系统安装，DHCP服务，Orchestration服务 和puppet 配置管理相关服务等，此外还有OpenStack关键业务健康检查和log实时查看等非常好用的服务。Fuel，这款让很多人即爱且痛的工具，在国内外都很盛名。爱的原因是，它确实很棒；痛的原因是，要想彻底掌握它，可不是一件容易事（各个模块集成度高、使用技术复杂）。既然提到Fuel，自然不能不提它的父母——Mirantis。Mirantis是一家技术实力非常雄厚的OpenStack服务集成商，他是社区贡献排名前5名中唯一一个靠OpenStack软件和服务盈利的公司。同时，Fuel的版本节奏也很快，平均每半年就能提供一个相对稳定的社区版。 从和笔者接触到的一些情况来看，国内研究、使用Fuel的个人、群体还是为数不少的。不少国内OpenStack初创公司的安装包就是基于Fuel去修改的。

Hi 哥们：做实验的话保持隔离的实验环境，就使用仅主机模式如果要上网，就使用NAT模式如果要跟主机一起测试，分配个IP和主机一个网段并使用桥接模式
OpenStack最初是Rackspace和NASA共同投入的，现在是由开源社区维护。 在9月18日即将在San Diego举行的Openstack Summit上也将有关于最新版本Folsom的消息。值得关注。它就是一个IaaS的云平台软件。实际应用场景非常多，凡是IaaS可以应用的地方Openstack都可以做到。 比如虚拟主机，出售计算资源，公司内部IT云计算解决方案等等。

Neutron能提供虚拟的分布式(这样就可以实现跨物理机虚机在同一个vlan)二层vswitch（提供虚拟的networksubnetport）、三层router、防火墙、负载均衡等抽象网络功能，能为每个租户提供独立的虚拟网络环境，neutron是用来创建虚拟网络的，所谓虚拟网络，就是虚拟机启动的时候会有一个虚拟网卡，虚拟网卡会连接到虚拟switch上，虚拟交换机连接到虚拟router上，虚拟路由器最终和物理网卡联通，从而虚拟网络和物理网络联通起来。 Neutron一般包括三种网络：1、External Network/API Network，这个网络是链接外网的，无论是用户调用OpenStack的API，还是创建出来的虚拟机要访问外网，或者外网要ssh到虚拟机，都需要通过这个网络。2、Data Network，数据网络，虚拟机之间的数据传输通过这个网络来进行，比如一个虚拟机要连接到另一个虚拟机，虚拟机要连接虚拟路由都是通过这个网络来进行3、Management Network，管理网络，OpenStack各个模块之间的交互，连接数据库，连接Message Queue都是通过这个网络来进行。Horizon上创建一个neutron网络的过程：1、为这个Tenant创建一个private network，不同的private network是需要通过VLAN tagging进行隔离的，互相之间广播（broadcast）不能到达，这里我们我们用的是GRE模式，也需要一个类似VLANID的东西，称为Segment ID(当然也可以是FLAT模式，不用vlan)2、为private network创建一个subnet，subnet才是真正配置IP网段的地方，对于私网，我们常常用192.168.0.0/24这个网段3、为这个Tenant创建一个Router,才能够访问外网4、将private network连接到Router上5、创建一个External Network（（就是我们上面设置的192.168.226.138，ens37））6、创建一个External Network的Subnet,这个外网逻辑上代表了我们数据中心的物理网络，通过这个物理网络，我们可以访问外网。因而PUBLIC_GATEWAY应该设为数据中心里面的Gateway，PUBLCI_RANGE也应该和数据中心的物理网络的CIDR一致，否则连不通。之所以设置PUBLIC_START和PUBLIC_END，是因为在数据中心中，不可能所有的IP地址都给OpenStack使用，另外的可能搭建了VMware Vcenter，可能有物理机，所以仅仅分配一个区间给OpenStack来用。7、将Router连接到External Network 更多信息可以参考《Linux就该这么学》

openstack是四层架构。分别是控制节点架构、计算节点架构、网络节点架构、存储节点架构。openstack既是一个社区，也是一个项目和开源软件，建立公共和私有云，帮助组织运行为虚拟计算或存储服务的云。