openstack三种网络模式(OpenStack网络)

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云计算的技术门槛。想一想，自己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去修改的。

openstack中的三种基础资源是：计算服务、存储服务、镜像服务。它负责管理OpenStack集群中的镜像，可以创建、删除、编辑镜像基本信息，支持多种虚拟机镜像格式。但是，Glance本身并不存储信息，它只保存描述镜像的元数据和状态信息，存储工作由cinder和swift等项目负责。工作流程：Open Stack的各个服务之间通过统一的REST风格的API调用，实现系统的松耦合。它内部组件的工作过程是一个有序的整体。诸如计算资源分配、控制调度、网络通信等都通过AMQP实现。 Open Stack的上层用户是程序员、一般用户和 Horizon界面等模块。这三者都是采用 Open Stack各个组件提供的API接口进行交互，而它们之间则是通过AMQP进行互相调用，它们共同利用底层的虚拟资源为上层用户和程序提供云计算服务。

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

一、Openstack网络基础 下面对Openstack和Neutron的介绍，要从几个关键词入手。1. 三代网络在网络这一口，OpenStack经历了由nova-network到Quantum再到Neutron的演进过程。我们直观地来看看三代网络的对比分析：出现版本支持组网模式优点缺点适用场景Nova-network早期FlatFlat DhcpVLAN性能出色工作稳定支持multi-host部署以实现HA网络管理不独立功能不够灵活组网方式受限对性能和稳定性要求比较高；中小规模网络；网络运维成本有限；私有云环境QuantumFolsomFlatFlat DhcpVLANOverlay独立的网络管理支持大二层支持多厂商插件缺乏HA机制各厂商插件无法共同运行基本上已经都跟进到了NeutronNeutronHavanaFlatFlat DhcpVLANOverlay继承了Quantum的优点功能上更为丰富网络兼容性强开始引入SDN的思想代码结构复杂工作不够稳定HA机制仍缺乏大规模商用的检验对功能要求比较多或希望向SDN演进；大规模网络或对可扩展性要求高；有专业的网络运维团队；公有云环境Nova-network是隶属于nova项目的网络实现，它利用了linux-bridge（早期，目前也支持OVS）作为交换机，具备Flat、Flat DHCP、VLAN三种组网模式。优点是性能出色，工作稳定，支持multi-host部署以实现HA；缺点是网络模块不独立，功能不够灵活，组网模式也比较受限。Quantum作为独立的网络管理项目出现在F版本，除了linux-bridge外还支持OVS，以及以及其他商业公司的插件，组网模式上增加了对GRE和VxLAN两个Overlay技术的支持。优点是功能灵活，支持大二层组网；缺点是集中式的网络节点缺乏HA，而且各厂商插件无法同时在底层网络中运行。Neutron出现在H版本，由来是Quantum和一家公司的名称冲突而改名。Neutron对Quantum的插件机制进行了优化，将各个厂商L2插件中独立的数据库实现提取出来，作为公共的ML2插件存储租户的业务需求，使得厂商可以专注于L2设备驱动的实现，而ML2作为总控可以协调多厂商L2设备共同运行。Neutron继承了Quantum对大二层的支持，还支持L2 PoP，DVR，VRRP，HA等关键功能，集成了很多L4-L7的网络服务，一些blueprint也正在积极开发中，如SFC等。优点是开始引入SDN思想，功能上更为丰富，网络兼容性强；缺点是代码结构复杂，工作不够稳定，HA机制仍缺乏大规模商用的检验。从应用场景来看，Nova-network组网模式过于简单，一些复杂的网络需求无法实现（比如两个公司合并，有大量IP重合的VM要迁移到一个平台，而且要求迁移后都要用原来的IP）。不过由于其简单稳定的特点，仍适合于中小型企业的生产环境；Quantum的实际部署目前基本都跟进到了Neutron；Neutron的大二层组网，适合于云计算规模的生产环境，但是由于分布式和HA机制仍不够成熟，因此目前多见于私有云和小规模共有云的部署，大规模的公有云仍然难以使用Neutron实现。2. 四种组网模型说完了基本特征与应用场景，下面开始对上述提到的一些网络问题进行详细的描述。我们抛开技术，结合图例来抽象地看看不同的组网模型。当然，以下模型的实现不仅仅局限于三张图中的方式。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）。 VLAN模型引入了多租户机制，虚拟机可以使用不同的私有IP网段，一个租户可以拥有多个IP网段。虚拟机IP通过DHCP消息获取IP地址（Nova-network实现为nova-network主机中的dnsmaq，Neutron实现为