探索openstack.docxVIP

探索OpenStack: 网络组件 Neutron本文将介绍OpenStack Networking (Neutron) 项目，解释它如何融入到整体架构中，并展示它的操作方式。文中在介绍 Neutron 的过程中了解了如何安装、配置和使用 Neutron 的各个组件。查看本系列更多内容?|?PDF：?(711 KB)?|?0?评论：本文将介绍OpenStack Networking，它管理着其他OpenStack项目之间的连接性。可以开发一个不包含任何特定于网络的功能的、可弹性扩展的工作负载管理系统。当然，计算节点需要在彼此之间建立连接，并能访问外部世界，但它也可以利用现有的网络基础架构来分配 IP 地址和在节点之间传输数据。在多租户环境中，这样一种方法的最大问题是，已有的网络管理系统无法高效、安全地在用户之间隔离流量 — 这同时也是构建公共和私有云的组织面临的一个巨大问题。OpenStack解决此问题的一种方式是，构建一个详尽的网络管理堆栈，用它来处理所有网络相关请求。此方法面临的挑战是，每个实现都可能拥有一组独特的需求，包括与其他各种各样的工具和软件的集成。OpenStack因此采取了创建抽象层的方法，这个抽象层被称为OpenStack Networking，可容纳大量处理与其他网络服务的集成的插件。它为云租户提供了一个应用编程接口 (API)，租户可使用它配置灵活的策略和构建复杂的网络拓扑结构 — 例如用它来支持多级 Web 应用程序。OpenStack Networking 支持使用第三方编写插件来引入高级网络功能，比如 L2-in-L3 隧道和端到端服务质量支持。它们还可以创建网络服务，比如负载平衡、虚拟专用网或插入OpenStack租户网络中的防火墙。在过去，OpenStack的网络组件位于OpenStack Nova (Compute) 项目中。其中大部分组件被拆分为一个包含 Folsom 版的单独项目。这个新项目最初称为 Quantum，但后来重命名为 Neutron，以避免与公司 Quantum Corporation 的任何商标混淆。所以，如果看到OpenStack Networking 参考资料中同时出现了名称 Nova、Quantum 和 Neutron，不要感到奇怪。模型OpenStack Networking API 基于一个简单的模型（包含虚拟网络、子网和端口抽象）来描述网络资源。网络是一个隔离的 2 层网段，类似于物理网络世界中的虚拟 LAN (VLAN)。更具体来讲，它是为创建它的租户而保留的一个广播域，或者被显式配置为共享网段。网络也是 Neutron API 的主要目标。换句话说，端口和子网始终被分配给某个特定的网络。子网是一组 IPv4 或 IPv6 地址以及与其有关联的配置。它是一个地址池，OpenStack可从中向虚拟机 (VM) 分配 IP 地址。每个子网指定为一个无类别域间路由 (Classless Inter-Domain Routing) 范围，必须与一个网络相关联。除了子网之外，租户还可以指定一个网关、一个域名系统 (DNS) 名称服务器列表，以及一组主机路由。这个子网上的 VM 实例随后会自动继承该配置。端口是一个虚拟交换机连接点。一个 VM 实例可通过此端口将它的网络适配器附加到一个虚拟网络。在创建之后，一个端口可从指定的子网收到一个固定 IP 地址。API 用户可从地址池请求一个特定的地址，或者 Neutron 可以分配一个可用的 IP 地址。OpenStack还可以定义接口应使用的媒体访问控制地址。在取消分配该端口后，所有已分配的 IP 地址都会被释放并返回到地址池。回页首插件最初的OpenStack Compute 网络实现采用了一种基本模型，通过 Linux? VLAN 和 IP 表执行所有隔离操作。OpenStack Networking 引入了插件的概念，插件是OpenStack Networking API 的一种后端实现。插件可使用各种不同的技术来实现逻辑 API 请求。一些OpenStack Networking 插件可能使用基本的 Linux VLAN 和 IP 表。这些插件对于小型和简单的网络通常已经足够，但更大型的客户可能拥有更复杂的需求，涉及到多级 Web 应用程序和多个私有网络之间的内部隔离。它们可能需要自己的 IP 地址模式（这可能与其他租户使用的地址重复）— 例如，用来允许应用程序在无需更改 IP 地址的情况下迁移到云中。在这些情况下，可能需要采用更高级的技术，比如 L2-in-L3 隧道或OpenFlow。插件架构使云管理员可以非常灵活地自定义网络的功能。第三方可通过 API 扩展提供额外的 API 功能，这些功能最终会成为核心Open