SDN VMware NSX网络原理与实践- NSX 与 OpenStack【4.0】

10.1.2 OpenStack 主要组件

        刚才提到，作为一个开源的平台， OpenStack 包含了很多开源项目，这些项目提供了 OpenStack 解决方案的各个组件。 下面对一些最常用的组件进行阐述。

        1． 计算： Nova Nova 是 OpenStack 中的计算项目，是云计算矩阵控制器。它是 IaaS 系统的主要组件， 用于配置和管理虚拟机，包括服务器计算资源（如 CPU、内存、磁盘和网络接口）的调度、 对虚拟机和操作系统进行镜像化管理。 此外，它还能实现基于角色的访问控制、跨计算组 件的资源池的分配、针对仪表板的操作。 Nova 不仅可以将计算资源分布在多个 KVM 之上， 还能分布在 vSphere、 Hyper-V、 Xen 等其他 Hypervisor 上。这样一来， OpenStack 就可以通 过可编程的 API 同时调度各种 Hypervisor， 并通过 Nova 创建、配置、删除和在线移动虚拟 机，最终在数据中心内部实现计算资源的自动化调度。

        2． 网络： Neutron Neutron 是 OpenStack 中的网络组件，以前称为 Quantum，它为 OpenStack 提供了网络 即服务的接口。 Nova 提供了动态地为各种 Hypervisor 的请求而配置虚拟机的 API，而Neutron 则提供了动态请求和配置虚拟网络的API， OpenStack的其他服务的接口（如 vNIC） 连接到的虚拟机（通过 Nova 创建）组成了这种虚拟网络。换言之， Neutron 与 NSX 一样， 是实现虚拟网络的一种组件。 核心的 Neutron API 主要工作在二层网络中，提供了一个叫做 Modular Layer 2（ML2）的 模块，作为二层消息总线。由于 Neutron 是基于插件模型的架构（就是 OpenStack 中经常提及 的 Plug-in），通过插件，可以包含多个可扩展的服务来提供更多功能，这使得各种网络解决方 案能够基于 OpenStack Neutron 构建。而连接各种网络则需要虚拟交换机的支持，两个流行的 开源虚拟交换的解决方案是 Linux Bridge 和 OVS（Open vSwitch）。 关于 OVS，之前在介绍 SDN 发展历程和 NSX-MH 时已经有所提及，它是由 Nicira 公司 设计开发的开源虚拟交换机。

        Nicira 公司在还没被 VMware 收购的时候，主要通过其自主研 发的 OpenFlow 协议和 OVS 虚拟交换机来创建网络虚拟平台（NVP），为诸多 IT 公司的数据 中心提供服务，实现其数据中心自动化。 OVS 主要运行在开源虚拟化平台（例如 KVM， Xen） 上，实现虚拟交换功能，可以为动态变化的端口提供二层交换，并能很好地控制虚拟网络中 的访问策略、网络隔离、流量监控等。 这个功能现在已经移植到了 NSX 网络虚拟化平台上。 正是因为这个原因，我们才说 NSX 网络虚拟化平台是可以融合 OpenStack 的极佳解决方案。 借助 Linux Bridge， OVS 可以创建网桥接口，将虚拟网络连接在一起，同时可以通过 其创建的上行链路将虚拟网络连接到物理网络。OVS 中使用了称为 OVSDB 的数据库模型， 该模型与 OVS 数据平面进行交互。

        可以通过 CLI 或 API 指令接收虚拟网络的配置，并将 配置保存在本地数据库中。 Neutron 通过插件提供的高级服务功能中，有四个常用服务，即三层网络、负载均衡服 务、 VPN、防火墙。在部署 Neutron 的高级服务时，可能需要设置多个代理，如 L3 代理、 DHCP 插件等。代理可以部署在控制节点上或单独的网络节点上。 3． 存储： Swift 和 Cinder OpenStack 的存储组件是 Swift 和 Cinder。简单来说， Swift 将服务器的本地磁盘统一 调用起来，形成一个虚拟存储资源池， 其实现方式很像 VMware 的 VSAN 或 Nutanix 公司 的分布式存储解决方案。

         Cinder 负责调用传统 SAN 网络中的物理存储资源。 Swift 是分布式对象存储系统，它可以扩展到数千台服务器，并针对多租户的高并发连 接做了优化。它还可以用作备份、增加非结构化数据。 Swift 提供的是基于 REST 的 API。 Cinder 是针对块存储的存储项目，能够创建并集中管理存储服务，这种服务器以“Cinder 卷” 的块设备形式配置存储。 Cinder 组件最常用的场景是为虚拟机提供持久的存储资源。举例来 说， Cinder 支持虚拟机存储资源的在线迁移、快照和克隆，这些功能可以通过向 Cinder 添加第 三方提供的驱动程序来增强，最终实现持久、快速、稳定的存储系统。 Cinder 后台运行的物理存 储系统可以是集中式或分布式部署的，可以使用各种存储连接协议，如 iSCSI、 FC、 NFS 等。

        4． 仪表板 GUI： Horizon GUI 组件 Horizon 是 OpenStack 的仪表板项目，它提供基于 Web 的 GUI 来访问、配置 和自动化部署 OpenStack 的各种资源，如 Nova、 Neutron、 Swift 和 Cinder 等。这个项目的 设计有助于与第三方产品和服务的集成，例如计费、检测和报警等。 最初， Horizon 是管理 Nova 项目的单个应用，仅包含视图、模板和 API 调用。后来， Horizon 的功能得到了扩展，可支持多个 OpenStack 项目和 API，这些项目和 API 被编排在 仪表板和系统面板组中。 这些仪表板涵盖了核心的 OpenStack 应用。它将 OpenStack 项目的核心 API 抽象出来， 形成美观友好的可视化 UI 界面，并通过 API 调用这些项目，为 OpenStack 提供了一致的、 可重复使用的开发和交互手法。有了这些抽象的 API，开发人员不用去熟悉每一个 OpenStack 的 API，就可以直接在仪表板上进行操作了。

        5． 身份验证： Keystone 在 Openstack 中， Keystone 负责身份认证、服务管理、服务规则和服务令牌的功能。 Keystone 类似一个服务总线，或者说是整个 Openstack 架构的注册表，其他服务通过 Keystone 来注册其服务。 任何服务之间相互的调用，都需要经过 Keystone 的身份验证来获 得目标服务。 Keystone 包含两个主要部件：验证（Verification）与服务目录（Service Catalog）。 其中，验证部件提供了一套基于令牌的验证服务，主要包含以下几个概念。

          租户（Tenant）：使用相关服务的一个组织（一个租户可以代表一个客户、账号、 公司、组织或项目），必须指定一个相应的租户才可以申请 OpenStack 服务。在 Swift 中，一个租户可以拥有一定的存储空间，拥有多个容器，这可以理解为一个公司 拥有一块存储空间。  用户（User）：表示拥有用户名、密码、邮箱等信息的个人，用户能够申请并获得 访问资源的授权。用户拥有证书，可以与一个或多个租户关联。经过身份验证后， Keystone 会为每个关联的租户提供一个特定的令牌。一个用户可以在不同的租户 中分配不同的角色。

        以 Swift 为例，可以这样理解：租户是一个公司，拥有一大块 存储空间； 用户是个人，是该公司的员工，能够根据用户的角色访问公司的部分 或全部存储空间，当然这个员工可以同时在其他公司兼职，拥有其他公司的存储 空间。 如果某个公司只有一个员工，即该员工拥有公司的全部存储空间。  证书（Credential）：为了给用户提供一个令牌，需要用证书来唯一标识一个用户的 密码或其他信息。  令牌（Token）：一个令牌是一个任意比特的文本，用于与其他 OpenStack 服务来共享 信息。 Keystone 以此来提供一个中央位置（Central Location）信息，以验证访问 OpenStack 服务的用户。一个令牌可以是范围内的（scoped） 或范围外的（unscoped）。

        一个 scoped 令牌代表为某个租户验证过的用户，而 unscoped 令牌则代表一个未验证 的用户。令牌的有效期是有限的，可以随时被撤回。  角色（Role）：代表特定租户中的用户操作权限，一个角色是应用于某个租户的使 用权限集合，以允许某个指定用户访问或使用特定操作。角色是使用权限的逻辑 分组，它可以对通用的权限进行简单分组， 并绑定到与某个指定租户相关的用户。 服务目录部件提供了一套 REST API 服务端点列表并以此作为决策参考，主要包含以 下几个概念。

         服务（Service）：一个 OpenStack 服务，例如 Nova、 Swift、 Glance 或 Keystone。一个 服务可以拥有一个或多个端点，用户可以通过它与 OpenStack 的服务或资源进行交互。  端点（Endpoint）：一个可以通过网络访问的地址（例如一个 URL），代表了 OpenStack 服务的 API 入口。端点也可以分组为模板，每个模板代表一组可用的 OpenStack 服务， 这些服务是跨区域（Region）可用的，例如将多个 Swift 代理服务器（Proxy Server） 分别配置为不同的域。  模板（Template）：一个端点集合，代表一组可用的 OpenStack 服务端点。 6． 镜像服务： Glance Glance 组件作为 OpenStack 虚拟机的 Image（镜像）服务，提供了一系列的 REST API， 用来管理、查询虚拟机的镜像，支持多种后端存储介质，例如用本地文件系统作为介质、 Swift 作为存储介质等。 Glance 支持下列多种镜像的格式。

         raw： 非结构化的镜像格式。  vhd： 一种通用的虚拟机磁盘格式，可用于 VMware vSphere、 Xen、 KVM、 Hyper-V、 VirtualBox 等。  虚拟机 dk： VMware 的虚拟机磁盘格式。  vdi： VirtualBox、 QEMU 等支持的虚拟机磁盘格式。  iso： 光盘存档格式。  qcow2： 一种支持 QEMU 并且可以动态扩展的磁盘格式。  aki： Amazon Kernel 镜像。  ari： Amazon Ramdisk 镜像。  ami： Amazon 虚拟机镜像。 7． 数据采集： Ceilometer Ceilometer 是 OpenStack 中的数据采集项目，能把 OpenStack 内部发生的几乎所有事件 都收集起来，然后为计费和监控以及其他服务提供数据层面的支持。 8． 物理计算配置： Ironic Ironic 是提供裸机服务的 OpenStack 项目，它使得用户可以配置和管理物理服务设备。

        之前，通过 Nova 可以创建虚拟机、虚拟磁盘，管理电源状态，快速通过镜像启动虚拟机。 但是物理机的管理则一直没有成熟的解决方案，于是， Ironic 诞生了。它可以解决物理机的 添加、 删除、 电源管理和安装部署问题。 Ironic 最大的好处是提供了插件式的部署机制，让 厂商可以开发自己的驱动程序。

         9． 自动化： Heat Heat 是 OpenStack 的编排程序，它创建了一种可访问的服务，用于管理 OpenStack 的 基础架构和应用的整个生命周期。 Heat 的编排引擎用于基于模板而启动的多个组合式的云 应用，这种模板可以使用类似代码样的处理形式进行文本文件式的编辑。 有了这些组件，就可以将它们集成为一个整体，共同为 OpenStack 环境提供服务。这 些组件之间的交互模式如图 10.2 所示。

10.1.3 OpenStack 在企业中的典型部署

        在企业中部署 OpenStack 时，底层物理网络不需要做任何改变， OpenStack 的这个 理念和 NSX 网络虚拟化平台如出一辙。通过将 OpenStack 的计算、存储等各个组件连 接到数据中心 ToR 交换机（或直接连接数据中心核心交换机），就可以实现完整的 OpenStack 环境。 一些企业可能更喜欢用异构的方式为一些额外节点（如 OpenStack 的控制和支持节点， 其中控制节点冗余部署）部署虚拟机，与基础架构中的各个项目组件保持一致。 典型的 OpenStack 部署常常包含至少 200 个节点，使用 Canonical 或 RedHat 的操作系 统发行版，部署可通过手动配置，也可以使用 Puppet、 Juju 或 Turnkey 进行自动化配置。 一个典型的 ToR 式的部署拓扑如图 10.3 所示。

企业在规划 OpenStack 的部署时，需要考虑的因素有下面这些。
 OpenStack 部署在现有 POD（Point of Delivery）中还是新 POD 中。
 清点硬件资产，包括所有机架式服务器、刀片式服务器、虚拟机和其他硬件，以便合理利用资源。
 哪些应用需要新部署，哪些应用可以调用现有资源。
 是否需要考虑多租户场景。
 OpenStack 中的 IP 地址需要慎密规划，是否需要 Overlay 的支持，是否需要 NAT。
 是否需要借助外部路由器来处理三层网络流量。
 负载均衡、安全的实现是否需要借助第三方解决方案。
 是否需要实现完全的自动化或半自动化。
 使用纯 OpenStack 部署，还是混合部署； 如果是混合部署， 如何与其他虚拟化管理平台相互调用和管理。
 需要了解 OpenStack 当前的缺陷，如哪里需要二次开发，哪些应用的部署可能不稳定，企业能否容忍 OpenStack 当前高可用（HA） /灾难恢复（DR）的局限性等。

10.1.4 VMware 与 OpenStack 的关系

        在 OpenStack 兴起之前，开源的虚拟化平台（包括 KVM 和 Xen）并没有像 VMware vCenter 和 vCAC 那样功能强大的管理工具。这就是为什么当今 OpenStack 技术被炒得火热 的真正原因—开源的免费虚拟化平台能够得到有效、统一的管理了。 于是，有人开始说， OpenStack 将逐渐取代非免费的 VMware，尽管它还不成熟，尽管它 的功能还不像 VMware 那样完善。这些人甚至给 OpenStack 起了一个外号，叫作 vSphere killer。 这种观点的核心在于，他们认为在未来，随着云计算的发展，虚拟机数量会越来越多，人们对 虚拟机的管理，无法再像之前 VMware 环境下那样，如同呵护宠物一样管理虚拟机，而是应当 在 OpenStack 环境下，像对待牲口一样管理虚拟机。 这种观点来自于著名的 Pets vs. Cattle 理论。

        一位供职于 OpenStack 技术咨询公司 Mirantis 的工作人员，在 2014 年利用这个理论写了一篇 名为《云计算战争： OpenStack vs VMware》的博文，其部分内容如下所示。 在传统服务模式下，你将虚拟机想象成你的宠物，你给他们取名字，比如 dusty、 cern 等， 它们被精心抚养长大。当它们生病了，你得修复它们。在云计算型应用服务模型中，虚拟 机被看作是农场中的公牛， 它们的名字通常都是编号，牛和牛长得也差不多，当它们生病 了，你就杀掉它，用一头新牛代替。未来的云应用架构应该像对待农场中的公牛一样。 VMware 的保养、保护虚拟机的各种功能较比云计算型应用模式变得越来越不重要了。

        这一篇著名软文被广泛转载。它甚至针对 VMware 和 OpenStack 的各个模块和组件进 行了评分和对比—Vmware 在设计和功能上领先于 OpenStack，但是在用例和价值上则是 OpenStack 领先 VMware，比较总分最终得出 OpenStack 优于 VMware 的片面结论。 鉴于它 是 OpenStack 技术咨询公司 Mirantis 的员工写的， 因此难免有失客观。 首先，这个观点错误地将 OpenStack 当成一个 Hypervisor。 OpenStack 是数据中心自动 化管理平台，不依赖于任何 Hypervisor。 在 Hypervisor 层面任由用户自己选择—用户可 以选择 vSphere，也可以选择 KVM 或 Xen，并且在 VMware 平台之上的 OpenStack 能达到 最佳的用户体验，这么来看， OpenStack 与 vSphere 虚拟化平台何来竞争关系？与 vSphere 竞争的，只有开源且需要二次开发才能实现高级功能的 Xen 和 KVM。

        OpenStack 作为一个 管理软件，仅仅能取代 VMware vCenter 和 vCAC 的部分功能，而且 VMware 还是主要靠vSphere 的 license 来获得利润的。有人认为，那么 OpenStack 搭配免费的 Xen 和 KVM，不 是也能取代 VMware 吗？诚然， OpenStack 结合 Xen、 KVM 后会因为其开源和免费的属性， 带来一定的市场竞争力，但是它的高级功能还是比较缺失的，需要研发人员进行二次开发 来实现。 这样新业务的上线时间将延长，且周期不固定—国内除了 BAT 外还有公司拥有 这样的开发能力吗？另外，每个企业都会针对自己公司应用的特点，对 OpenStack 进行二 次开发，使得 OpenStack 平台仅能用于自己企业内部，无法在行业内横向推广。 这样一来， 对于可能出现的软件 bug， 由于之前企业没有处理类似 bug 的经验， 也没有专门的 OpenStack 全球技术支持中心帮助处理，因此 bug 就无法得到及时的解决。

        一旦企业的关键应用出现 bug，企业的业务将产生严重影响。 其次，这个观点错误理解了 Pets vs. Cattle 理论模型。 Pets vs. Cattle 的理论并不代表 VMware 在虚拟化中的诸多高级功能就无关紧要，而是意味着在大型数据中心或大型云计 算型应用服务模型中，可以编辑诸多虚拟机的模板、快照等自动化部署的策略，这其中包 括创建虚拟机、创建虚拟网络与创建存储资源池。只有通过这样的自动化地配置、管理和 部署模式，才能真正实现数据中心的自动化。这样一来，当然是“牛” 和“牛”都长的差 不多了。而早期的虚拟化技术，或者说现今用于中小型企业的虚拟化技术，只是为了节省 物理服务器硬件成本或节省机房空间而实施，并不是针对云计算环境而提出的。

        由于开启 的虚拟机数量并不多，自然需要 IT 管理人员像维护以前的物理服务器一样维护虚拟机。在 大型云环境中， VMware 的每台虚拟机也可以是一头“公牛”， 而且这个公牛干活的能力更 强，有些活还非它来干不可。只是这些公牛的买入价稍微贵了点，但可以降低维护成本， 提高效率，且这些公牛不会出现什么问题。 那么，纯 OpenStack 环境下，通过 KVM、 Xen 生成的公牛会出现什么问题呢？这些问 题的存在，是 VMware 可以与 OpenStack 进行集成并提出融合解决方案的主要原因。  OpenStack 在自己的控制平面方面，并不具备 vSphere 才具备的高级功能，如 DRS 或 vMotion，这样一来其冗余性就会产生一定问题。因此可以利用 VMware 的高级 功能，实现 OpenStack 控制平面的安全性、稳定性、可靠性。

          原生的 OpenStack 技术在连接虚拟网络时，无法很好地调度网络中的高级功能，这 导致服务链的修改、网络的可扩展性、安全性和向后兼容性都会出现问题。 而 VMware NSX 可以使用网络虚拟化平台完美解决这些问题，带来基于 Hypervisor 内核的 VXLAN、分布式路由、分布式防火墙功能和诸多高级网络服务。  OpenStack 中存在的启动风暴（Start-up Storm）问题可以通过 VMware 的虚拟机模 板、快照、克隆等功能来解决。  OpenStack 的组件非常繁多，部署极其复杂。熟悉 OpenStack 的读者应该知道， OpenStack 在部署中需要通过各种复杂命令行进行操作，而真正部署完之后，有了Horizon 的界面，进行 Nova 等配置反倒简单了。

        而 VMware 可以为 OpenStack 的 部署带来一个向导式、自动化的配置界面， 可以简化 OpenStack 最繁琐的部署过程。 虽然后来 OpenStack 可以通过 Fuel 工具进行快速部署，但部署时仍然无法很好地 实现 OpenStack 控制平面的冗余性，且 OpenStack 的组件无法得到很好的管理— 通过 VIO（VMware Integrated OpenStack，后文会详细阐述）部署的 OpenStack 组 件完全是以虚拟机的形式呈现在 vCenter 管理界面中。  OpenStack因为不同用户开发而导致的bug处理滞后的问题，也能通过VIO来解决。 由于 VIO 成为 vCenter 的一个组件，与 VMware 稳定的平台深度集成，大幅降低 了故障率，且故障事件都可以由 VMware 全球支持中心第一时间提供支持，这样 也有利于 VMware 针对已出现的 bug 进行 VIO 的改进和升级。

         OpenStack 社区每半年都会发布一个新的版本。对于已经上线的 OpenStack 平台， 进行版本升级是非常困难的工作。而使用 VIO，用户则可以非常容易地将正在使 用的 OpenStack 平台升级到最新版本。 当然， OpenStack 也有其优势，它最大的优势就是其开源的属性和多虚拟化环境的统一 管理，这些是 VMware 解决方案中并不具备的属性。这也使得 VMware 与 OpenStack 可以 进行集成并提出融合解决方案。  开发人员在开源的 OpenStack 上可以更好地进行应用的开发，尤其是 SaaS、 Web 应用和移动后端。

        此外， OpenStack 平台还便于对开发环境进行批处理、数据分 析、编码和模拟等操作。这样，即便在纯 vSphere 环境中，也能让开发人员从 中受益。  VMware 有成熟的虚拟化平台，但是企业很可能在其数据中心内部署多虚拟化平台— 可能会同时部署 vSphere、 KVM 和 Xen。这样一来，企业数据中心服务器就不是 纯 VMware 环境，管理非 vSphere 的虚拟机可能就需要 OpenStack。而 VIO 则可以 同时管理 vSphere 和其他的 Hypervisor，并实现一致的体验。 因此， VMware 和 OpenStack 之间不是互相竞争的关系，而是互补的关系。

        现在， VMware 是 OpenStack 基金会的黄金会员，且 VMware 为 OpenStack 项目贡献的代码在全球排在前 十位。 OpenStack 中主推的开源虚拟交换机 OVS，正是来自 VMware 收购的 Nicira 公司。 在 OpenStack Neutron（Quantum）项目刚刚启动时， Nicira 公司还是该项目的发起者并领导 了该项目的开发。 VMware 旨在将 vSphere 打造成最适合运行 Openstack 的平台，使得企业 内部的 OpenStack 和 vSphere 的团队在管理网络、存储、计算方面可以更好地合作， 在这个 融合解决方案平台上，不同团队可以更紧密地进行应用开发工作，快速实现企业云环境的 价值。 为此， WMware 开发了一款专门支持 OpenStack 的发行版软件 VMware IntegratedOpenStack（以下简称 VIO），用于帮助 IT 管理员在现有的 VMware 基础架构之上更加轻松 地部署基于生产级的 OpenStack。

         IT 管理员能够通过基于 VMware 的基础架构，为开发人 员提供不受供应商限制的 OpenStack API，从而让开发人员在 OpenStack 架构上对应用的开发 进行创新。该 OpenStack 发行版软件通过用户早已熟悉的 VMware 管理工具的深度集成来提 供主要的管理功能，包括安装、升级、故障排除，从而加速应用开发，并降低整体成本。可 以使用 VIO 将 VMware 与 OpenStack 集成起来，实现融合解决方案。之后， IT 管理员就可以 在现有 vSphere 中简单、快速、便捷地部署 OpenStack 服务，在部署完成后，也可以通过 VIO 进行资源池的创建和规划，并进行再开发。目前， VIO 的版本是 2.0，它基于 OpenStack 的 Kilo 版本（VIO 的 1.0 版本是基于 Icehouse 版本）。 VIO 软件免费包含在 vSphere 企业加强版 （vSphere Enterprise Plus）中，只有当用户需要 VMware 售后服务时，才收取费用。 当然，对于非纯 VMware 环境，也就是存在 KVM 和 Xen 作为 Hypervisor 的环境，就 不需要 VMware 的 OpenStack 发行版软件进行支持了。 在这样的环境下，在网络方面，可 以直接将 OpenStack 与 NSX-MH 进行集成。