每天5分钟玩转OpenStack第七章第一节

从今天开始，我们将学习OpenStack的NetworkingService，Neutron。Neutron的难度会比前面所有模块都大一些，内容也多一些。为了帮助大家更好的掌握Neutorn，CloudMan也会分析地更详细一些。Neutron概述传统的网络管理方式很大程度上依赖于管理员手工配置和维护各种网络硬件设备；而云环境下的网络已经变得非常复杂，特别是在多租户场景里，用户随时都可能需要创建、修改和删除网络，网络的连通性和隔离不已经太可能通过手工配置来保证了。如何快速响应业务的需求对网络管理提出了更高的要求。传统的网络管理方式已经很难胜任这项工作，而“软件定义网络（software-definednetworking,SDN）”所具有的灵活性和自动化优势使其成为云时代网络管理的主流。Neutron的设计目标是实现“网络即服务（NetworkingasaService）”。为了达到这一目标，在设计上遵循了基于SDN实现网络虚拟化的原则，在实现上充分利用了Linux系统上的各种网络相关的技术。在这一章，我们将讨论Neutron的功能和它的各个组件，学习部署和配置OpenStack网络的不同方法，会涉及软件和硬件设备多个层面。Neutron功能Neutron为整个OpenStack环境提供网络支持，包括二层交换，三层路由，负载均衡，防火墙和VPN等。Neutron提供了一个灵活的框架，通过配置，无论是开源还是商业软件都可以被用来实现这些功能。二层交换SwitchingNova的Instance是通过虚拟交换机连接到虚拟二层网络的。Neutron支持多种虚拟交换机，包括Linux原生的LinuxBridge和OpenvSwitch。OpenvSwitch（OVS）是一个开源的虚拟交换机，它支持标准的管理接口和协议。利用LinuxBridge和OVS，Neutron除了可以创建传统的VLAN网络，还可以创建基于隧道技术的Overlay网络，比如VxLAN和GRE（LinuxBridge目前只支持VxLAN）。在后面章节我们会学习如何使用和配置LinuxBridge和OpenvSwitch。三层路由RoutingInstance可以配置不同网段的IP，Neutron的router（虚拟路由器）实现instance跨网段通信。router通过IPforwarding，iptables等技术来实现路由和NAT。我们将在后面章节讨论如何在Neutron中配置router来实现instance之间，以及与外部网络的通信。负载均衡LoadBalancingOpenstack在Grizzly版本第一次引入了Load-Balancing-as-a-Service（LBaaS），提供了将负载分发到多个instance的能力。LBaaS支持多种负载均衡产品和方案，不同的实现以Plugin的形式集成到Neutron，目前默认的Plugin是HAProxy。我们也将在后面章节学习LBaaS的使用和配置。防火墙FirewallingNeutron通过下面两种方式来保障instance和网络的安全性。SecurityGroup通过iptables限制进出instance的网络包。Firewall-as-a-ServiceFWaaS，限制进出虚拟路由器的网络包，也是通过iptables实现。我们将在后面章节详细讨论Security和FWaaS。上次我们讨论了Neutron提供的功能，今天我们学习Neutron模块几个重要的概念。Neutron管理的网络资源包括Network，subnet和port，下面依次介绍。networknetwork是一个隔离的二层广播域。Neutron支持多种类型的network，包括local,flat,VLAN,VxLAN和GRE。locallocal网络与其他网络和节点隔离。local网络中的instance只能与位于同一节点上同一网络的instance通信，local网络主要用于单机测试。flatflat网络是无vlantagging的网络。flat网络中的instance能与位于同一网络的instance通信，并且可以跨多个节点。vlanvlan网络是具有802.1qtagging的网络。vlan是一个二层的广播域，同一vlan中的instance可以通信，不同vlan只能通过router通信。vlan网络可以跨节点，是应用最广泛的网络类型。vxlanvxlan是基于隧道技术的overlay网络。vxlan网络通过唯一的segmentationID（也叫VNI）与其他vxlan网络区分。vxlan中数据包会通过VNI封装成UPD包进行传输。因为二层的包通过封装在三层传输，能够克服vlan和物理网络基础设施的限制。gregre是与vxlan类似的一种overlay网络。主要区别在于使用IP包而非UDP进行封装。不同network之间在二层上是隔离的。以vlan网络为例，networkA和networkB会分配不同的VLANID，这样就保证了networkA中的广播包不会跑到networkB中。当然，这里的隔离是指二层上的隔离，借助路由器不同network是可能在三层上通信的。network必须属于某个Project（Tenant租户），Project中可以创建多个network。network与Project之间是1对多关系。subnetsubnet是一个IPv4或者IPv6地址段。instance的IP从subnet中分配。每个subnet需要定义IP地址的范围和掩码。subnet与network是1对多关系。一个subnet只能属于某个network；一个network可以有多个subnet，这些subnet可以是不同的IP段，但不能重叠。下面的配置是有效的：networkAsubnetA-a:10.10.1.0/24{start:10.10.1.1,end:10.10.1.50}subnetA-b:10.10.2.0/24{start:10.10.2.1,end:10.10.2.50}但下面的配置则无效，因为subnet有重叠networkAsubnetA-a:10.10.1.0/24{start:10.10.1.1,end:10.10.1.50}subnetA-b:10.10.1.0/24{start:10.10.1.51,end:10.10.1.100}这里不是判断IP是否有重叠，而是subnet的CIDR重叠（都是10.10.1.0/24）但是，如果subnet在不同的network中，CIDR和IP都是可以重叠的，比如networkAsubnetA-a:10.10.1.0/24{start:10.10.1.1,end:10.10.1.50}networkBsubnetB-a:10.10.1.0/24{start:10.10.1.1,end:10.10.1.50}这里大家不免会疑惑：如果上面的IP地址是可以重叠的，那么就可能存在具有相同IP的两个instance，这样会不会冲突？简单的回答是：不会！具体原因：因为Neutron的router是通过Linuxnetworknamespace实现的。networknamespace是一种网络的隔离机制。通过它，每个router有自己独立的路由表。上面的配置有两种结果：如果两个subnet是通过同一个router路由，根据router的配置，只有指定的一个subnet可被路由。如果上面的两个subnet是通过不同router路由，因为router的路由表是独立的，所以两个subnet都可以被路由。这里只是先简单做个说明，我们会在后面三层路由的章节详细分析这种场景。portport可以看做虚拟交换机上的一个端口。port上定义了MAC地址和IP地址，当instance的虚拟网卡VIF（VirtualInterface）绑定到port时，port会将MAC和IP分配给VIF。port与subnet是1对多关系。一个port必须属于某个subnet；一个subnet可以有多个port。小节下面总结了Project，Network，Subnet，Port和VIF之间关系。Project1:mNetwork1:mSubnet1:mPort1:1VIFm:1Instance前面我们讨论了Neutron的基本概念，今天我们开始分析Neutron的架构。Neutron架构与OpenStack的其他服务的设计思路一样，Neutron也是采用分布式架构，由多个组件（子服务）共同对外提供网络服务。Neutron由如下组件构成：NeutronServer对外提供OpenStack网络API，接收请求，并调用Plugin处理请求。Plugin处理NeutronServer发来的请求，维护OpenStack逻辑网络的状态，并调用Agent处理请求。Agent处理Plugin的请求，负责在networkprovider上真正实现各种网络功能。networkprovider提供网络服务的虚拟或物理网络设备，例如LinuxBridge，OpenvSwitch或者其他支持Neutron的物理交换机。QueueNeutronServer，Plugin和Agent之间通过MessagingQueue通信和调用。Database存放OpenStack的网络状态信息，包括Network,Subnet,Port,Router等。Neutron架构非常灵活，层次较多，其目的是：为了支持各种现有或者将来会出现的优秀网络技术。支持分布式部署，获得足够的扩展性。通常鱼和熊掌不能兼得，虽然获得了这些优势，但这样使得Neutron更加复杂，更不容易理解。后面我们会详细讨论Neutron的各个组件，但在这之前，非常有必要先通过一个例子了解这些组件各自的职责以及是如何协同工作。以创建一个VLAN100的network为例，假设networkprovider是linuxbridge，流程如下：NeutronServer接收到创建network的请求，通过MessageQueue（RabbitMQ）通知已注册的LinuxBridgePlugin。Plugin将要创建的network的信息（例如名称、VLANID等）保存到数据库中，并通过MessageQueue通知运行在各节点上的Agent。Agent收到消息后会在节点上的物理网卡（比如eth2）上创建VLAN设备（比如eth2.100），并创建bridge（比如brqXXX）桥接VLAN设备。关于linuxbridge如何实现VLAN大家可以参考本教程“预备知识-网络虚拟化”的相关章节。这里进行几点说明：plugin解决的是What的问题，即网络要配置成什么样子？而至于如何配置How的工作则交由agent完成。plugin，agent和networkprovider是配套使用的，比如上例中networkprovider是linuxbridge，那么就得使用linuxbridge的plungin和agent；如果networkprovider换成了OVS或者物理交换机，plugin和agent也得替换。plugin的一个主要的职责是在数据库中维护Neutron网络的状态信息，这就造成一个问题：所有networkprovider的plugin都要编写一套非常类似的数据库访问代码。为了解决这个问题，Neutron在Havana版本实现了一个ML2（ModularLayer2）plugin，对plgin的功能进行抽象和封装。有了ML2plugin，各种networkprovider无需开发自己的plugin，只需要针对ML2开发相应的driver就可以了，工作量和难度都大大减少。ML2会在后面详细讨论。plugin按照功能分为两类：coreplugin和serviceplugin。coreplugin维护Neutron的netowrk,subnet和port相关资源的信息，与