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

9.6.3 安全 Profile 与访问控制列表

        NSX-MH 还可以通过部署与传统物理网络设备中类似的访问控制列表（ACL），实现工作 流之间的安全交互。在 NSX-MH 中， 由于访问控制列表是配置在网络虚拟化环境中，因此配 置方式与传统物理设备中的配置还是有所不同的。 NSX-MH 提供了两种配置方法。

         在连接逻辑交换机端口（VIF）的虚拟工作流之间部署三、四层过滤，一般使用名 为“安全 Profile” 的逻辑结构。  将三、四层过滤应用到 NSX 二/三层网关连接的逻辑交换端口的时候，其配置模式 与传统的 ACL 非常类似。 图 9.37 简单说明了安全 Profile 和 ACL 的部署位置。随后会详细讨论这两种配置方法。 与通过大多数 CMS/CMP（比如 OpenStack）创建的安全组功能非常类似，安全 Profile 可 以提供一基于角色的模型，以定义一组过滤规则，并应用到一个特定的逻辑交换机端口。

         每个安全 Profile 会定义一组出向规则（虚拟机的流量通过逻辑交换机端口去往别的虚 拟机）和入向规则（抵达逻辑交换机的流量，并希望进入逻辑交换机端口连接的虚拟机）。 一个逻辑交换机端口可以关联多个安全 Profile，安全过滤规则会匹配每个 Profile 中的任何 一个条目。对于匹配的安全规则，流量被放行，反之就会丢弃。当逻辑交换机端口没有关 联安全 Profile 的时候，流量过滤机制就不需要在该端口上进行工作。 当安全 Profile 工作时，需要深入理解“入向” 和“出向” 的流量过滤机制是如何在逻 辑交换机的端口上进行的。 下面通过图 9.38 来解释其工作机制。

        逻辑接口出向过滤： 安全 Profile 出向过滤的主要目的是保护不受信任主机的虚拟 机试图连接其他虚拟机。一旦虚拟机连接的 VIF 接口关联了一个安全 Profile，默 认就会执行“deny all”（拒绝全部流量）的流量过滤。这意味着虚拟机完全被隔离， 网络中的其他所有设备都被保护了起来，不会收到这台虚拟机始发的流量，直到安全 Profile 中加入具体的规则，使得虚拟机的特定 IP 地址或某些协议端口的流量 可以在逻辑交换机端口之上被放行， 它才可以与其他虚拟机通信。  逻辑接口入向过滤：安全 Profile 入向过滤的主要目的是限制一组外部的虚拟机连接， 这样就可以防止虚拟机从别的设备收到一些类型的流量。与出向过滤类似，入向过滤 的默认规则同样是“deny all”，这个虚拟机同样被隔离，任何流量都无法穿越其连接 的逻辑交换机端口，除非在端口之上明确允许了一些流量可以被放行。

        在安全 Profile 中有一个重要的特性，叫做白名单（white-list）。它与传统的 ACL 不同， 因为它可以混用“允许” 和“拒绝” 规则，并应用到流量过滤中。 而传统的 ACL 一般是列 出所有允许的流量，再拒绝其他所有流量，或拒绝某些特定的流量，再允许其他所有流量。 因此，使用安全 Profile 进行流量过滤时，配置会变得更加灵活。 在安全 Profile 中，出向和入向流量是自然反射的。 也就是说， 当一个规则应用在虚拟 机与外界建立连接时，对于相同的连接，其回应的流量会自动绕过反方向的过滤规则。 NSX Controller 通过在该传输节点自动设定一个流量入口，允许其反向的 TCP 或 UDP 的五元组 回应流量请求。

         ICMP 流量也能使用类似的行为来处理。图 9.39 就是这样一个自然反射特 性的简单案例。它在逻辑交换机端口的出向允许了 TCP 和 80 和 443 端口，但是在入向拒 绝所有流量，如果没有这样的反射性特性，外界对虚拟机的流量请求（哪怕是 HTTP 或 HTTPS）就无法得到回应。 图 9.39 其实也是当 Web 服务器的虚拟机连接到 VIF 时默认的安全 Profile 配置。这个默 认过滤规则的目标是仅允许 HTTP 和 HTTPS 的流量进入虚拟机，并阻止其他入向流量。而当 一个外部的客户端开始与 Web 服务器进行通信时，安全 Profile 又会自动生成入向的规则，通 过 deny any any（拒绝所有） 的规则，以确保虚拟机所有的出向流量都被拒绝。

        OVS 会通过 NSX Controller 维持这些动态建立的安全 Profile 的流量放行入口策略。当 有一段时间没有原始流量通过时，入口策略就会被暂时移除，以提高系统的效率。超时时 间如下。  SSH 连接（TCP 端口 22）： 60 秒。  其他 TCP 连接： 300 秒。  UDP 连接： 5 秒。 安全 Profile 配置是与一个给定虚拟机连接的 VIF 进行关联的，它会自动跟随虚拟 机（可以随虚拟机迁移而迁移），而不基于 IP 地址或端口。

        当虚拟机从一个物理主机迁 移到了另一个主机时，安全 Profile 配置会随之迁移。同样，当安全 Profile 的一组规则 或一组安全 Profile 发生变化时，其关联的所有逻辑交换机接口上的过滤规则都会自动 更新。但是，连接跟踪状态则不会跟随虚拟机在 Hypervisor 之间迁移而迁移。这意味着 状态（也就是前文所说的自然反射特性）会在虚拟机迁移到了新的 Hypervisor 并发送至 少一个报文后自动刷新。参考图 9.38，当虚拟机 1 迁移到别的 Hypervisor 时，客户端就 不会再从 Web 服务器收到数据， 原因是存在默认的入向 deny all 策略。直到客户端再次 尝试与其连接，被出向流量反射的入向流量（允许了 TCP 的 80 和 443 端口）在新的 Hypervisor 之上可以自动安排。 在生产环境中，如果希望配置安全 Profile，需要在 VMware 官网上参考每个 NSX 版本支持的安全 Profile 的最大数量、每个安全 Profile 的规则数量限制和一个逻辑端口 可应用的规则数量。配置安全 Profile 时，如果配置的策略具有很高的复杂性，也会导 致内存消耗和 NSX Controller 的开销变得很大。这些都是在规划和实施过程中需要注意 的地方。

        安全 Profile 功能虽然有很多优势，但只能运用在 VIF 上，以过滤逻辑交换机内部流量 （虚拟机之间的流量）。传统的 ACL 则可以运用在 NSX 二层或三层网关的接口上，以在逻 辑网络和物理网络之间实现安全通信。其实，使用安全 Profile 和 ACL 功能实现 NSX-MH 中的安全隔离， 与 NSX-V 中的分布式防火墙和 Edge 防火墙相似，它们的实现原理不同， 但目的相同—分别保护东西向流量和南北向流量。 图 9.40 所示为在 NSX 二层或三层网关上配置 ACL 的逻辑示意图。在 NSX Controller 之上配置了 ACL 策略，由它将这些策略信息推送到 NSX 网关，并安装到 OVS 内核中。 这 样， ACL 就可以在 NSX 网关的端口上应用并实现流量过滤。 在图 9.40 所示的例子中，假设需要过滤虚拟机 1 和虚拟机 2 之间的三层 ICMP 流量， 一个具体的 ACL 就需要应用在连接两个不同逻辑交换机的逻辑路由器的端口上，相应的 “丢弃” 策略需要应用在传输节点的 OVS 的内核上，以执行这个过滤。然而，传输节点执 行 ACL 策略的方式还依赖于具体的逻辑路由器的部署方式。

        使用分布式路由模式时，流量在源虚拟机（虚拟机 1） 所在的 Hypervisor 上处理时， 会进入的 OVS 内核空间，这就意味着流量在还没离开 Hypervisor 时，就会被丢弃。 这个特性是非常有意义的，因为虚拟机 2 可能连接到了相同的 Hypervisor。  使用集中路由模式时，流量过滤在活跃（active） 的逻辑路由器实例所处的三层网 关设备之上进行，这就意味着源 Hypervisor 始发的流量会抵达网关，然后才被丢 弃，而不是在没离开 Hypervisor 时就被丢弃。

        在这个例子中，如果还需要将 ACL 应用在二层网关端口上，以使得虚拟机 1 和物理主机 1 之间的通信是安全的，流量过滤策略就需要应用在活跃（active） 的二层网关所处的传输节点上。 部署 ACL 时，还有以下需要考虑的地方。  对于连接了一个给定逻辑交换机的虚拟机， 由该虚拟机发出并被二层或三层网关 所接收的流量，需要在网关上配置入向过滤。对于反方向的流量，即从二层或三 层网关始发并去往逻辑交换机的流量，则需要在网关上配置出向的过滤。

          与在传统物理网络设备上配置 ACL 不同，在 NSX-MH 中配置 ACL 时，并不需要 在 ACL 的末尾书写 deny all（拒绝所有流量）这条规则。 相反，默认规则的最后一 条规则是 permit all（允许所有流量）。 这意味着在 NSX-MH 中，强烈建议配置更 加明细的拒绝策略，而不是简单地使用 deny all 这条规则。  每一条 ACL 规则都有三种可能的执行方式—deny（拒绝）、 allow（允许）和 allow reflexive（允许反射性）。前两种执行方式是显而易见的，而 allow reflexive 则可以 实现安全 Profile 中自动执行的反射功能，对于一个具体的流量（如在图 9.41 中， 连接 LS1 的虚拟机 1 去往连接 LS2 的虚拟机 2 的流量），可以动态允许它按照原路 径返回，而独立于任何一个应用在这个返回路径上的过滤策略。

9.7 总结

 当前开源的虚拟化解决方案主要是 Xen 和 KVM。
 NSX-MH 用于在非纯 VMware 虚拟化环境中实现网络虚拟化。它使用的软件与NSX-V 不同，但解决方案的架构基本相同，只是主要依赖于 OVS 创建逻辑网络。
 OVS 是 Nicira 公司最早开发的虚拟交换机，在 NSX-MH 环境中，它是逻辑网络的核心组件，服务节点、传输节点、传输区域的各种转发行为都与它息息相关。 OVS用于 ESXi 主机时，称为 NVS。
 NSX-MH 中默认的隧道封装类型为 STT。
 NSX-MH 中，逻辑交换的流量复制模型分为节点复制模式和基于源节点的复制。
 NSX-MH 中，路由分为分布式路由和集中路由。
 NSX-MH 中的安全策略有端口隔离、端口安全、安全 Profile 与访问控制列表。

第10章 NSX 与 OpenStack

        介绍了多虚拟化环境下的 NSX，自然要介绍 OpenStack 了，因为 OpenStack 当今是多 虚拟化环境的数据中心中最好的基于开源代码的自动化管理平台。OpenStack 在管理虚拟化 平台时， 能实现与 VMware VRealize 和 vCAC 类似的数据中心自动化管理功能。

        部署 OpenStack 之后，云计算的开发人员就可以使用 OpenStack API、 CLI 和工具来调配和管理 工作负载；云环境的运维人员，也可以使用 OpenStack 平台及其工具，对自己的云计算基 础架构进行全面运维和管理。 OpenStack 因其开源且能进行二次开发的属性，被研发能力极强的各大互联网公司力 捧，希望在其之上开发最适合自己企业应用的平台。

        有人说 OpenStack 将在未来一统天下， 取代 VMware。这个观点可能有些片面了， OpenStack 和 VMware 绝不是竞争关系，而是相 关合作和支持的关系。 本章将先讨论 OpenStack 的起源、发展历程、各大组件的功能， 然后介绍 VMware 集成 OpenStack 的发行版软件，与 VMware NSX 网络虚拟化平台如何集成 OpenStack—VMware 旨在将自己打造成最适合集成 OpenStack 的平台。

10.1 OpenStack 简介

         在介绍 NSX 与 OpenStack 的集成解决方案前， 先来看一下 OpenStack 的发展史和基本 架构。其实， OpenStack 从无到有，从默默无闻到大红大紫，不过 5 年多时间。在这 5 年多 时间里， OpenStack 如火箭般飞速蹿红，无数极客趋之若鹜，多家初创公司也纷纷成立。 OpenStack 之所以如此火热，是因为它开源、免费，且能进行二次开发， 从而为企业的 应用定制化地实现强大的功能。而这些定制化的应用，在当今“互联网+” 的大环境下，是 很多企业急需的，尤其是大型互联网公司、 OTT 行业。 本节将从 OpenStack 的起源和发展历程开始谈起， 然后介绍其每个主要项目的组件与典型的部署，再阐述 VMware 与 OpenStack 的关系，以及 VMware 如何面对这个趋势和潮 流。

        在本节之后，将真正介绍 VMware 与 OpenStack 的集成。 10.1.1 OpenStack 的起源和发展历程 OpenStack 最早是由美国国家航空航天局（ NASA）和托管服务器及云计算提供商 Rackspace 在 2010 年开始合作研发的开源项目，旨在打造易于部署、功能丰富且易于扩展 的云计算平台，使之成为公有云或私有云的管理工具。 OpenStack 是数据中心环境下，用于 编排工作流程和实现自动化的开源软件平台，可以为数据中心中的网络、计算、存储、安 全等功能提供自动化配置、部署、监测和管理。

         典型的 OpenStack 逻辑架构如图 10.1 所示。基于 OpenStack 的底层物理网络和服务器 平台，还可以引入很多服务，这些服务是由 OpenStack 的一些开源项目的组件来实现的， 如计算、网络、存储。在这些服务之上， OpenStack 提供了可编程的 API，可以与最终应用 进行交互。而整个 OpenStack 环境的配置和管理可以通过 OpenStack Dashboard 来完成，它 同样也是 OpenStack 的开源项目的组件提供的。

OpenStack 的开源项目提供了 OpenStack 解决方案的各个组件，而这些组件可以在网络上下载，并运行在多个 Linux 发行版之上。 OpenStack 中的主要组件如下所示。
 计算： Nova。
 网络： Neutron。
 存储： Swift 和 Cinder。
 仪表板 GUI： Horizon。
 身份验证： Keystone。
 镜像服务： Glance。
 数据采集： Ceilometer。
 物理计算配置： Ironic。
 自动化： Heat。

        2010 年 2 月， Rackspace 决定开发开源云软件。 4 月， NASA 启动 Nebula 开放平台项 目。到了 6 月，时任 Rackspace 副总裁的吉姆· 库里（Jim Curry）给时任 NASA 艾姆斯研 究中心 CIO 的克里斯· 坎普（Chris Kemp）发了一封邮件，寻求将 Rackspce 和 NASA 手中 的开源云项目进行整合的可能性， 由此开始， OpenStack 项目的两个创始机构开始连线。同 年的 7 月 19 日，在美国波特兰举办的 OSCON 大会上， OpenStack 开源项目诞生。 虽然当 时只有 25 家机构宣布加入这一项目，但是在此之后， OpenStack 的发展极其迅猛。

         2010 年 10 月 1 日， OpenStack 第一个版本 Austin 发布。 Austin 主要包含 Swift（用于 对象存储） 和 Nova（用于计算） 两个子模块，带有简单的控制台，基于 Web 管理。  2011 年 2 月 1 日， Bexar 版本发布。 Bexar 新增了 Glance 项目，负责镜像管理， Swift 增加了对 S3 的支持， Nova 开始支持 RAW 镜像。  2011 年 4 月 1 日， Cactus 版本发布。在 Cactus 版本中， Nova 支持 LXC 容器、 ESXi， 支持动态迁移， Glance 提供了新的 CLI 工具—OpenStack 非常有远见，第三个版 本就开始支持容器了。  2011年9月1日， Diablo版本发布。在Diablo版本中， Nova和Glance整合了Keystone 认证，并增强对 KVM 的支持。这一年， OpenStack 虽然影响力一般，但两大 IT 巨头 HP 和 AT&T 选择加入了 OpenStack 基金会。

         2012 年 4 月 1 日， Essex 版本发布。 Essex 版本增加了 Horizon 项目，并正式发布 了 Keystone 项目， Nova 的特性进一步丰富。同时，基于 OpenStack 的 Rackspace 开源云平台投入生产运营。  2012 年 9 月 1 日， Folsom 版本发布。 Quantum 项目的推出为 OpenStack 提供了网 络的管理服务，而这个项目主要是由 Nicira 公司主导的。这个版本还正式发布了 Cinder 项目，提供块存储服务。其实在 Folsom 版本发布前的几个月， VMware 就 完成了对 Nicira 的收购。 由于 Quantum 项目在 OpenStack 平台上可以基于 Nicira 开发的 OVS 实现网络虚拟化，此项收购让 VMware 赢得了当时正在筹建的 OpenStack 基金会的信任。

        此后， OpenStack 基金会正式成立，通过投票接纳 VMware、 Intel、 NEC 成为金牌会员，中国厂商华为也加入了 OpenStack 基金会。  2013 年 4 月 1 日， Grizzly 版本发布。 Nova 引入了 Cell 的概念，并开始支持为虚 机实例（CPU、磁盘 I/O、网络带宽）设置配额。 Quantum 中引入了负载均衡服务。 Cinder 中开始支持 FC 设备。  2013 年 9 月 1 日， Havana 版本发布。 同时正式启动可用于监控报警的 Ceilometer 项目、可用于自动化编排的 Heat 项目。

        同时，网络服务 Quantum 更名为 Neutron并增加了 VPN 功能， Nova 对 Docker 容器的支持加强， Cinder 开始支持裸盘。这 一年， Oracle 加入 OpenStack 基金会，中国 OpenStack 创业公司如雨后春笋般出现。  2014 年 4 月， IceHouse 版本发布。在 IceHouse 版本中，平台项目间的整合能力加 强， Swift 性能提升，新项目 Trove 被引入，用于提供数据库服务。这一年， OpenStack 变得炙手可热，出现了一大波标志性事件： RedHat 收购 eNovance，交易金额接近 1 亿美元；开源云项目 Eucalyptus 被 HP 收购；基于 OpenStack 的托管云的初创公 司 MetaCloud 被 Cisco 收购； OpenStack 初创企业 CloudScaling 被 EMC 收购；中 国首个基于 OpenStack 的公有云平台 UnitedStack 正式开放注册。

 2014 年 10 月 1 日， Juno 版本发布。 数据管理 Sahara 项目被正式集成，提供针对 Hadoop和Spark集群管理和监控的自动化服务。对NFV的支持也提上日程。Neutron 开始支持 IPv6 和分布式虚拟路由。 Swift 推出存储策略支持。 3 个月之后的 2015 年年初， PayPal 宣布全面向 OpenStack 云迁移，其物理服务器规模达到 4100 台。

         2015 年 4 月 1 日， Kilo 版本发布。这一版本在用户体验上做了较多努力，开始支 持向导式的虚拟机创建，支持简单的主题（Theme），基础功能日臻完善。 Swift 加 入了纠删码。 Kilo 首次发布了完整版裸机管理模块 Ironic。另外， 在 Neutron 中， NFV 的功能得到进一步增强。这段时间， 最早的 OpenStack 创业公司 Nebula 宣布倒闭，业界哗然。 6 月，两家 OpenStack 初创公司 Blue Box 和 Piston 相继 被 IBM 和 Cisco 收购。同时，拥有 300 多年历史的英国巴克莱银行启动基础设 施更新计划，计划五年内每年以 20%的服务器替代速度向 OpenStack 迁移—计 划在五年迁移的服务器规模达到 10 万台。 7 月 19 日， OpenStack 满五周岁，其 社区已经聚集了 27000 余名开发者，支持企业多达 500 多家，用户遍及 160 多 个国家和地区。

          2015 年 10 月， Liberty 版本发布。 在这个版本中， Magnum 项目被集成了进来，其 主要工作是实现 OpenStack 与集群中的容器管理系统的互动。 Liberty 版本也针对 Nova、 Neutron、 Swift 等项目进行了重点优化，例如 Nova 项目增强了服务器虚拟 化的能力，开放了 Cellv2 版本的接口。此外，可以通过一套 Nova API 接口来管理 多个 Nova 计算单元，从而实现跨数据中心的扩展， 这极大增强了 OpenStack 的可 扩展性。

          2015 年 10 月底，在东京举行的 OpenStack Summit 峰会上，公布了新的 Navigator 项 目，它可以帮助新用户根据自己的使用情况轻松辨别每个 OpenStack 云中最常部署的 6 个项目（具体包括 Nova、 Neutron、 Swift、 Cinder、 Keystone、 Glance 等核心服务） 与可选服务之间的差别。此外，东京峰会上强调了 Neutron 网络项目的地位。业内一 致认为，在 OpenStack 中， 就计算、网络、存储三个方面来说， 计算和存储已经相对成熟稳定，网络则最为复杂，最为难以自动化，但却是最为重要的。 OpenStack 通过 与 SDN 技术的结合来发展 Neutron 项目就变得尤为关键。 Xen、 KVM 和 OpenStack 都使用开源的理念与开发方法，都与 Linux、 RedHat 有着 千丝万缕的关系，但它们还是有很大的差别的，其最大的区别来自于自身的定位— Xen、 KVM 是虚拟化软件，是 Hypervisor，而 OpenStack 是整个数据中心的自动化管理 平台。 OpenStack 几乎支持所有的 Hypervisor，不论是开源的（ Xen 和 KVM）还是厂商 的（ Hyper-V 和 VMware vSphere）。当然，由于 OpenStack 最早是基于 Linux 开发的， 因此 OpenStack 的主要还是部署在大规模 Linux 环境中。如今，多数企业在 IT 环境中 使用了超过一种的虚拟化软件，如同时部署 Xen、 KVM 和 VMware vSphere。

         由于 OpenStack 可以同时管理这些虚拟化软件，因此具有巨大的行业发展推动力，并且拥有 了一个充满活力的社区。 虽然开源在 IT 界都比较受关注，但是它们都存在一定的劣势。比如 OpenStack 引发了 厂商之间的利益冲突，在兼容性方面有待解决，且具成熟度还比不上厂商级别的解决方案。 此外，因为 OpenStack 与 KVM 都是开源的基因，这就导致了企业一旦在自己的 IT 环境内 部署 OpenStack 与 KVM， 就需要二次开发（无论是自身进行二次开发还是请第三方集成商 来完成） 来实现所需的高级功能， 因此开发成本较高，交付周期较长， 而且高级功能可能 不稳定，服务支持也会滞后。但是， OpenStack 和 KVM 都有强大的发展动力，也有各大 IT 厂商的持续支持，它们未来的前景值得期待。