盘它!必须要了解的openstack网络服务(Neutron)理论基础

前言

一:Neutron基本架构

  • 与 OpenStack其他服务和组件的设计思路一样, Neutron也采用分布式架构,由多个组件(服务)共同对外提供网络服务, Neutron架构非常灵活,层次多,一方面是为了支持各种先有或者将来会出现的先进网络技术,另一方面支持分布式部署,获得足够的扩展性。示意图如下:

  • mark

  • Neutron仅有一个主要服务进程 Neutron-server,它运行于控制节点上,对外提供OpenStack网络API作为访问 Neutron的入口,收集请求后调用插件( Plugin)进行处理,最终由计算节点和网络节点上的各种代理( Agent)完成请求。

  • 网络提供者( Network provider)是指提供者 OPenStack网络服务的虚拟机或者物理网络设备,如 Linux Bridge、 Open vSwitch或者其他支持 neutron的物理交换机。与其他服务一样, Neutron的各个组件服务之间需要相互协调通信, Neutron- server、插件、代理之间通过消息队列(默认用 RabbitMQ实现)进行通信和相互协调。

  • 数据库(默认使用 Maria DB)用于存放 OpenStack的网络状态信息、包括网络、子网端口、路由器等等。

  • 客户端(Client)是指使用 Neutron服务的应用程序,可以是命令行工具(脚本)、 Horizon
    ( OpenStack图形操作界面)和Nova计算服务等

  • 举列说明:创建一个vlan10虚拟网络的流程

    • 1.Neutron-server收到创建网络( Network)的请求,通过消息队列( RabbitMQ)通知已注册的 Linux Bridge插件,这里架设网络提供者为 Linux Bridge。
    • 2.该插件将要创建的网络信息(如名称、ID值、ⅥANID等)保存到数据库中并通过消息队列通知运行在各个节点上的代理
    • 3.代理收到信息后会在节点上的物理网卡上创建Ⅵan设备(比如物理接口的子接口Eth1.10),并创建一个网桥(比如 brgXXX)来桥接网络设备

二:各个组件(服务)详解

2.1:neutron-server

  • Neutron-server提供一组API来定义网络连接和IP地址,供Nova等客户端调用,它本身也是分层模型设计,其层次结构如下:

  • mark

  • neutron-server包括四个层次

    • (1)Resetful API:直接对客户端API服务,属于最前端的API,包括Core API和Extension API两种类型,Core API提供管理网络,子网和端口核心资源的 Resetful API;Extension API提供给网络管理路由器,负载均衡,防火墙,安全组等扩展资源的Resetful API
    • (2)Common Service:通用服务,负责对API请求进行检验,认证并授权。
    • (3)Neutron Core:核心处理程序,调用相应的API插件来处理API的请求。
    • (4)Plugin API:定义插件的抽象功能集合,提供通用调用插件API的接口,包括Core Plugin API和Extension Plugin API两种类型,Neutron Core通过Core Plugin API调用相应的Core Plugin,通过Extension Plugin API调用相应的Service Plugin

2.2:插件

  • Neutron遵循 OpenStack的设计原则,采用开放架构,通过插件、代理与网络提供者的配合来实现各种网络功能。
  • 插件是 Neutron的一种API的后端实现,目的是增强扩展性。插件按照功能可分为Core Plugin和 Service Plugin两种类型
    • Core pugin提供基础二层虚拟机网络支持,实现网络、子网和端口核心资源的支持。
    • Service plugin是指 Core Plugin之外的其他插件,提供路由器、防火墙、安全组、负载均衡等服务支持
    • 值得一提的是,直到 OpenStack的 Havana版本, Neutron才开始提供一个名为L3 Router Service Plugin的插件支持路由服务。
  • 插件由 Neutron-server的 Core Plugin API和 Extension Plugin API调用,用于确定具体的网络功能,即要配什么样的网络,插件处理 Neutron- Server发来的请求,主要职责是在数据库中维护 Neutron网络的状态信息(更新 Neutron数据库),通知相应的代理实现具体的网络功能。每一个插件支持一组API资源并完成特定操作,这些操作最终由插件通过RPC调用相应的代理( Agent)来完成。

2.3:代理和网络提供者

  • 代理处理插件转来的请求,负责在网络提供者上真正实现各种网络功能。代理使用物理网络设备或者虚拟化技术完成实际的操作任务,如用于路由具体操作L3 Agent
  • 插件、代理与网络提供者配套使用,比如网络提供者是 Linux Bridge,就需要使用 Linux Bridge的插件和代理,如换成 Open vSwitch,则需要改成相应的插件和代理。

三:neutron的物理部署

  • Neutron与其他 OpenStack服务组件系统工作,可以部署在多个物理主机节点上,主要涉及控制节点、网络节点和计算节点,每个节点可以部署多个,典型的主机节点部署介绍如下。

3.1:控制节点和计算节点

  • 控制节点上部署 Neutron- service(API)、 Core Plugin和 Service Plugin的代理,这些代理包括 neutron-plugin-agent、 neutron-medadata-agent、 neutron-dhcp-agnet、 neutro-l3- agent、neutron- lba as-agent等。 Core plugin和 service plugin已经集成到 neutron-server中,不需要运行独立的 plugin服务。
  • 计算节点上可以部署 Core Plugin、 Linux Bridge或 Open vSwitch的代理,负责体提供二层的网络功能
  • 控制节点和计算节点都需要部署 Cere Plugin的代理,因为控制节点与计算节点通过该代理才能建立二层连接。

3.2:控制节点和网络节点

  • 可以通过增加网络节点承担更大的负载,该方案特别适合规模较大的 OpenStack环境
  • 控制节点部署 Neutron-server服务,只负责通过 Neutron-server响应的API请求。
  • 网络节点部署的服务包括 Core Plugin的代理和 service Plugin的代理。将所有的代理从上述控制节点分离出来,部署到独立的网络节点上,由独立的网络节点实现数据的交换,路由以及负责均衡等高级网络服务。
发布了132 篇原创文章 · 获赞 67 · 访问量 2万+

猜你喜欢

转载自blog.csdn.net/CN_TangZheng/article/details/104639545